Just-run-the-unittests
Hi! Suppose I have a small .d script that has a main. Is there any simple way to just run the unit tests without running main at all? I thought -main switch was intended for this, but apparently it works only if there's no main defined at all, otherwise, it issues a double main definition error. I could place main into a separate module but its really awkward to create 2 files for a small script.
Re: Just-run-the-unittests
On Sunday, 16 March 2014 at 07:59:33 UTC, Sergei Nosov wrote:
Hi!
Suppose I have a small .d script that has a main. Is there any
simple way to just run the unit tests without running main at
all?
Here's the first thing that came to mind:
If you never want to both unit tests and regular main:
code begins
import std.stdio;
version(unittest) void main(){}
else
void main() { writeln(Hello world!); }
unittest { writeln(Hello unit testing world!); }
code ends
If you sometimes want to have your normal main with unit testing
you can replace version(unittest) with version(nopmain) or
some other custom version identifier and compile with
-version=nopmain when you want the dummy main.
Re: Just-run-the-unittests
On Sunday, 16 March 2014 at 08:22:04 UTC, safety0ff wrote:
On Sunday, 16 March 2014 at 07:59:33 UTC, Sergei Nosov wrote:
Hi!
Suppose I have a small .d script that has a main. Is there any
simple way to just run the unit tests without running main at
all?
Here's the first thing that came to mind:
If you never want to both unit tests and regular main:
code begins
import std.stdio;
version(unittest) void main(){}
else
void main() { writeln(Hello world!); }
unittest { writeln(Hello unit testing world!); }
code ends
If you sometimes want to have your normal main with unit
testing you can replace version(unittest) with
version(nopmain) or some other custom version identifier and
compile with -version=nopmain when you want the dummy main.
Thx! That's better, but I think -main switch could be made to
work like 'add or replace main by stub' instead of just 'add'. I
don't think it'll hurt anybody, what do you think?
Re: Installing D on OSX using .dmg
On Sun, 2014-03-16 at 04:02 +, Joel wrote: I get an access problem (Downloads Tools. link), it saying it's an unidentified developer. Thanks for any help. Apple are trying to impose a rule that all executables on OSX are signed. I am more or less convinced this is a good idea. It at least isn't the you are only allowed to install software that comes from the Apple Store, which is what Apple would really like to do, but which would be a disaster. There is an option in the security menu to say whether you want applications only from the Apple Store, only signed or no restriction. You have to switch this to no restriction to install unsigned DMG. People have convinced me that leaving the setting on signed only is the right thing, escaping out of that for specific DMG you know the total history of. I am away from an OSX machine for a couple more days, so this is entirely from memory The moral of this story is that the DMG should be signed. Actually this goes for the RPM and Deb files as well. Also stuff on Jordi's Debian site and elsewhere. The question is whose signature and whose CA. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Just-run-the-unittests
On 3/16/14, Sergei Nosov sergei.no...@gmail.com wrote: Thx! That's better, but I think -main switch could be made to work like 'add or replace main by stub' instead of just 'add'. I don't think it'll hurt anybody, what do you think? It can't work, because main could be stored in a pre-built object or static library that's passed to DMD.
Re: Ubuntu dmd 2.065 amd64 linkage problem.
On Sunday, 16 March 2014 at 02:12:37 UTC, Carl Sturtivant wrote: Back at 2.062 I was able to force the whole of D's runtime/phobos into an executable which was exactly what I wanted for a specific project containing not just D but around 50,000 lines of C. (This is to do with having dynamic libraries link back to the executable when they're loaded with dlopen, so they don't need their own runtime/phobos on board.) However, at 2.065 this doesn't happen any more. I need this same linkage with 2.065. Previously I used -Wl,--whole-archive -lphobos2 -Wl,--no-whole-archive on a gcc command line to link all the objects in the project along with libphobos2, with -lcurl -lpthread -lm -lrt to satisfy that linkage, and this had the desired effect. But now this doesn't do the job of linking the whole of D's runtime phobos any more. Any suggestions how I can get the old result with 2.065? DMD started to support shared lib on linux from 2.063. This may be useful: http://dlang.org/dll-linux.html Also note that if you are only writting the shared lib and not the client, it would be easyier to bootstrap it using gcc's attributes (see http://stackoverflow.com/questions/9759880/automatically-executed-functions-when-loading-shared-libraries ). Else, there is a Runtime.loadLibrary (which will be improved later), to load and start a D shared library (if you just dlopen, static ctor stuff won't be initialized).
Re: Just-run-the-unittests
On Sunday, 16 March 2014 at 10:15:00 UTC, Andrej Mitrovic wrote: It can't work, because main could be stored in a pre-built object or static library that's passed to DMD. Hmm I really should consider making a DIP for a deferred CTFE block. Could really come in handy for a situation like this. In the format of if -main specified use e.g. -version=D_Main to remove the call to _Dmain symbol. Removes the whole linker issue altogether.
Re: Get Compile Errors - Command Line
On Saturday, 15 March 2014 at 22:48:52 UTC, Adam D. Ruppe wrote: On Saturday, 15 March 2014 at 19:11:38 UTC, Bauss wrote: Note I am not typing the arguments, but rather starting the process. Skip to the bottom of this message if you are doing it in D and don't care how it is done in the lower level api. The CreateProcess API call takes a STARTUPINFO argument which has handles you can use to redirect the output. 2somefile.txt in cmd.exe does something like this: HANDLE hFile = CreateFile(somefile.txt, GENERIC_WRITE, 0, null, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, null); if(hFile == INVALID_HANDLE_VALUE) throw new Exception(couldn't open file); scope(exit) CloseHandle(hFile); STARTUPINFO si; si.cb = si.sizeof; si.dwFlags = STARTF_USESTDHANDLES; si.hStdError = hFile; // redirect to our file si.hStdInput = GetStdHandle(STD_INPUT_HANDLE); si.hStdOutput = GetStdHandle(STD_OUTPUT_HANDLE); // Now, we'll create the process with the file set up and wait for it to finish PROCESS_INFORMATION pi; if(CreateProcessA(dmd.exe, dmd.exe yourfile.d, null, null, true, 0, null, null, si, pi) == 0) throw new Exception(createProcess failed); WaitForSingleObject(pi.hProcess, INFINITE); CloseHandle(pi.hProcess); // At this point, we could check out somefile.txt to see what is there Of course, if we wanted to see the content in our program, instead of going through a regular file, we could use CreatePipe() to make a pair, passing the write handle to it as the hStdOutput, then reading from the read side to collect all the program's output in memory. There's similar Posix functions if you want to do this kind of thing on linux, etc., too. If you're writing this program in D, the standard library contains a nice little function to make this a lot shorter: http://dlang.org/phobos/std_process.html#.execute the example there calls dmd too! So if you wanna try it from D, copy/paste that example and it should get you started. Actually I was doing it through C#. I have tried getting the output of the window but it doesn't seem to redirect it.
Re: Ubuntu dmd 2.065 amd64 linkage problem.
DMD started to support shared lib on linux from 2.063. This may be useful: http://dlang.org/dll-linux.html Also note that if you are only writting the shared lib and not the client, it would be easyier to bootstrap it using gcc's attributes (see http://stackoverflow.com/questions/9759880/automatically-executed-functions-when-loading-shared-libraries ). Else, there is a Runtime.loadLibrary (which will be improved later), to load and start a D shared library (if you just dlopen, static ctor stuff won't be initialized). Thanks, I guess I will have to go that route as my old trickery no longer works; I am building the client, so I'll now use Runtime.loadLibrary. However, http://dlang.org/dll-linux.html says I must link to libphobos.so and not libphobos.a suggesting that my old trickery could work as before by putting libphobos.a in its entirety into the client and none of it in a dynamic library. Yet it does not, as revealed immediately by the client's file size. Which suggests that http://dlang.org/dll-linux.html is out of date. Can anyone tell me if http://dlang.org/dll-linux.html correct for 2.065 ? All of this was a lot easier on Windows, where I was able to make everything work with no significant trouble.
TDPL question: objects may not embed internal pointers, classes too?
On page 249 of TDPL (Andrei's book), in a section on structs and postblits, it says D objects must be relocatable and other similar statements while banning internal pointers. I knew this applies to structs and the context makes that plainly clear, but the word object is a bit ambiguous: does this apply to classes too?
Re: Get Compile Errors - Command Line
On Sunday, 16 March 2014 at 13:57:42 UTC, Bauss wrote: Actually I was doing it through C#. I have tried getting the output of the window but it doesn't seem to redirect it. Did you try the startup info there too? Here's a link with a .net example: http://stackoverflow.com/questions/4291912/process-start-how-to-get-the-output Notice that the answer itself only redirects the output, but dmd I believe uses the error stream for it. The comments discuss it: add to the ctor: RedirectStandardError = true, and read from proc.StandardError afterward.
Memory errors
When using both simpleimage and DWT my program crashes with
core.exception.InvalidMemoryOperationError after I show an
image in a GUI window and then close the window. I'm presumably
misunderstanding something about how the windows deal with memory
deallocation, but this happens even when copying tutorial
examples.
e.g.
module main;
import org.eclipse.swt.SWT;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.graphics.all;
void main ()
{
auto display = new Display;
auto shell = new Shell;
shell.setText(Title);
Label label = new Label (shell, SWT.BORDER);
label.setBounds(shell.getClientArea());
Image image = new Image(display, C:/dev/data/tree.png);
label.setImage(image);
shell.pack();
shell.open();
while (!shell.isDisposed)
if (!display.readAndDispatch())
display.sleep();
display.dispose();
}
This successfully creates the display and shows an image, but
when I close the window the memory error exception is thrown. If
I run the same code without creating the image then there's no
errors. If I create the image without setting it on the label I
still get the error. Any ideas?
Re: Memory errors
Ah, I need to dispose of the image before disposing of the
display.
On Sunday, 16 March 2014 at 19:33:09 UTC, PhilE wrote:
When using both simpleimage and DWT my program crashes with
core.exception.InvalidMemoryOperationError after I show an
image in a GUI window and then close the window. I'm presumably
misunderstanding something about how the windows deal with
memory deallocation, but this happens even when copying
tutorial examples.
e.g.
module main;
import org.eclipse.swt.SWT;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Label;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.graphics.all;
void main ()
{
auto display = new Display;
auto shell = new Shell;
shell.setText(Title);
Label label = new Label (shell, SWT.BORDER);
label.setBounds(shell.getClientArea());
Image image = new Image(display, C:/dev/data/tree.png);
label.setImage(image);
shell.pack();
shell.open();
while (!shell.isDisposed)
if (!display.readAndDispatch())
display.sleep();
display.dispose();
}
This successfully creates the display and shows an image, but
when I close the window the memory error exception is thrown.
If I run the same code without creating the image then there's
no errors. If I create the image without setting it on the
label I still get the error. Any ideas?
Re: Memory errors
On 3/16/14, PhilE theotherp...@hotmail.com wrote: When using both simpleimage and DWT my program crashes with core.exception.InvalidMemoryOperationError It's likely something is trying to allocate in a destructor.
Re: Just-run-the-unittests
On Sunday, 16 March 2014 at 12:57:04 UTC, Rikki Cattermole wrote: On Sunday, 16 March 2014 at 10:15:00 UTC, Andrej Mitrovic wrote: It can't work, because main could be stored in a pre-built object or static library that's passed to DMD. Hmm I really should consider making a DIP for a deferred CTFE block. Could really come in handy for a situation like this. In the format of if -main specified use e.g. -version=D_Main to remove the call to _Dmain symbol. Removes the whole linker issue altogether. Linker will still complain about duplicate symbols. This issue can't be solved within existing C-compatible object file toolchain.
Re: Ubuntu dmd 2.065 amd64 linkage problem.
DMD started to support shared lib on linux from 2.063. This may be useful: http://dlang.org/dll-linux.html Also note that if you are only writting the shared lib and not the client, it would be easyier to bootstrap it using gcc's attributes (see http://stackoverflow.com/questions/9759880/automatically-executed-functions-when-loading-shared-libraries ). Else, there is a Runtime.loadLibrary (which will be improved later), to load and start a D shared library (if you just dlopen, static ctor stuff won't be initialized). Thanks for all that information. I did some work, and formed the following conclusions. I can now confirm that the part of the document http://dlang.org/dll-linux.html about loading D dynamic libraries from a D main program is experimentally apparently correct with a real world largish executable. The machinery to initialize the runtime in the dynamic library in http://stackoverflow.com/questions/9759880/automatically-executed-functions-when-loading-shared-libraries is apparently unnecessary in this case, though I have seen some hints it may be necessary when having a C main program load a D dynamic library. If you want a D dynamic library to call-back functions in the D main program that loaded it, you may need to supply the linker with the -export-dynamic flag (on the dmd command line with -L-export-dynamic ) so as to expose symbols in the main program for automatic linkage to the dynamic library at the point it is loaded. This worked nicely for me.
Re: Installing D on OSX using .dmg
On Sunday, 16 March 2014 at 04:02:13 UTC, Joel wrote: I get an access problem (Downloads Tools. link), it saying it's an unidentified developer. Thanks for any help. If you are using Homebrew you can simply do brew install dmd.
Re: TDPL question: objects may not embed internal pointers, classes too?
On Sunday, 16 March 2014 at 18:41:51 UTC, Adam D. Ruppe wrote: On page 249 of TDPL (Andrei's book), in a section on structs and postblits, it says D objects must be relocatable and other similar statements while banning internal pointers. I knew this applies to structs and the context makes that plainly clear, but the word object is a bit ambiguous: does this apply to classes too? And object is an instantiation of a class. I guess it could be ambiguous but generally I think object = class(misnomer but simple). Structs can exist on the heap and be very similar to objects and I suppose it is possible to allocate classes on the stack so theoretically I guess it is ambiguous but in programming parlance it is not.
Re: Installing D on OSX using .dmg
Thanks Russel! I've gotten past the security problem! There's options under Security Privacy (and what can be downloaded): O-MacApp Store O-idetinified developers @-Anywhere. Though this (Anywhere) lowers the security of what to download. I've been Recommended this OS. I can use Windows 7 as native too. Mengu, I don't know Homebrew. On Sunday, 16 March 2014 at 09:53:16 UTC, Russel Winder wrote: On Sun, 2014-03-16 at 04:02 +, Joel wrote: I get an access problem (Downloads Tools. link), it saying it's an unidentified developer. Thanks for any help. Apple are trying to impose a rule that all executables on OSX are signed. I am more or less convinced this is a good idea. It at least isn't the you are only allowed to install software that comes from the Apple Store, which is what Apple would really like to do, but which would be a disaster. There is an option in the security menu to say whether you want applications only from the Apple Store, only signed or no restriction. You have to switch this to no restriction to install unsigned DMG. People have convinced me that leaving the setting on signed only is the right thing, escaping out of that for specific DMG you know the total history of. I am away from an OSX machine for a couple more days, so this is entirely from memory The moral of this story is that the DMG should be signed. Actually this goes for the RPM and Deb files as well. Also stuff on Jordi's Debian site and elsewhere. The question is whose signature and whose CA.
Re: Just-run-the-unittests
On Sunday, 16 March 2014 at 20:22:15 UTC, Dicebot wrote: On Sunday, 16 March 2014 at 12:57:04 UTC, Rikki Cattermole wrote: On Sunday, 16 March 2014 at 10:15:00 UTC, Andrej Mitrovic wrote: It can't work, because main could be stored in a pre-built object or static library that's passed to DMD. Hmm I really should consider making a DIP for a deferred CTFE block. Could really come in handy for a situation like this. In the format of if -main specified use e.g. -version=D_Main to remove the call to _Dmain symbol. Removes the whole linker issue altogether. Linker will still complain about duplicate symbols. This issue can't be solved within existing C-compatible object file toolchain. I was inferring that no stub _Dmain would be added. Since it would no longer be called.
