I want to create a console application that makes use of FSharp.Plotly (charts) to show statistics. However, FSharp.Plotly seems only able to run in a .fsx file (documentation didn't mentioned .fs) I tried it in a .fsx file and it was a success, i was able to load a chart.
However, I want to be able to call the graphs (so a pop up appears) with a console application, how to achieve this?
I needed to use: open Fsharp.Plotly (it needs first to be seen in the references list).
Related
Trying to use MergExtDropBox for the first time in Livecode for iOS. I've copied the external into the Copy Files pane but I'm getting a "Can't Find Handler" error when I try to run mergDropboxSetup.
It's most likely that there's some issue with the way you have added the external to your app. Take a look at this video where I explain how to do that
EDIT
Based on the comments I'm not sure this is the most likely issue. I'm wondering if you are executing the command on desktop instead of iOS? If that's the problem then you will need to wrap your code in something like this:
if the platform is "iPhone" then
mergDropboxSetup ...
end if
Is there any way to delete a file when its using by any program or other process in windows?
I searched and found this 2 ways:
1- using RunOnce key in Registry;
I'm not gonna use this because i dont want to wait for windows restart or anything else... prefer to do it ontime!
2- using the way declared in this page: http://www.delphipages.com/forum/showthread.php?t=201190
the problem here is its useful under NT windows, i need a way works on all Windowses!
Thank you.
the problem here is its useful under NT windows, i need a way works on all Windowses!
All modern desktop Windowses (XP, Vista, 7) are also NT. Do you really need to work with NT<4 or Win98? Or even Win CE/Mobile/Phone? Probably not.
If you need to delete an open file straight away, about the only thing you can do is attach to each process using debugger privileges, see if it has any handles open on the file, and if so close them underneath it. You can do this the manual way using eg Process Explorer. Many applications won't react well to having their files closed on them; expect them to exception out when they try to do something with the dead handle.
Unfortunately there is no option in Windows to have Unix-style files that can exist attached to a file handle independently of being stored under a filename on disc.
You cant delete a file when someone is using it. No matter how hard you try, windows will not let you. It can work with some files, but in general it does not work.
What you can try is postpone the deletion, when no one is using the file. You can:
1 - use RunOnce, but you dont want that.
2 - Wait in a loop, trying to delete the file. Pseudo code:
DeleteFile
Check if you was able to delete or if file still exists.
if you are able to delete, then exit loop.
That is the best you can do, and what i could remeber.
Try MoveFileEx with MOVEFILE_DELAY_UNTIL_REBOOT flag. Will postpone move or delete action until reboot.
Edit:
If you don't whant to restart the only option is to close those handles. ProcessExplorer does that and works all the time and I have not seen any process to crash. See more info about enumeration handles in a process at
http://www.codeguru.com/forum/archive/index.php/t-176997.html. But keep in mint that you should enumerate all processes in the system and behave different on Vista+ (you need to be elevated)
Your files are most likely locked because some process has a handle open to them. That is the most common reason for the Access denied result when deleting or moving a file.
A really blunt way is to close that handle.
Then Handles tool from SysInternals (you can download the sources too) can do that for you: I have been successfully using that.
Note 1: You need administrative privileges to use it.
Note 2: Closing a handle from another process is considered very rude, and can make that process unstable.
My idea is that it's much easier to edit related code when it sits in single "work" file. E.g. in Rails application when you implementing some functionality you may edit 1 function per file in the following files: integration test, controller test, controller, model, controller helper. So if it would be possible to 1) mark this code fragments 2) automatically collect them in "work" file 3) edit them togather 4) the tool synchronizes (puts back) the changes; it could simplify development process in many cases. Especially if you need to go through many tweek-and-try iterations.
Vim works fine for this. Install the Rails.vim(1) plugin and with the command :AV you can open a vertical split with the accompanied tests/specs, or :RV to open related files like migrations and views (depending on whether you're viewing model or controller). When you're workspace becomes to cluttered, use :only to go back to one file. Splits are the best way to manage multiple related files IMHO. You can even open the same file twice to see two parts of the same file. It's not exactly the same as you are describing, but it comes close.
1: http://rails.vim.tpope.net/
Just open up Vim and open some windows. What's the problem?
I'm on a Mac and when I am in TextMate editing a ruby file I can simply hit Command-R to execute the file and see the results in a new window. Is there something similar to this using MacVim?
It's really important that I be able to open up a NEW window. Reason is because in the current window I might have more than one full page of info. If that happens I can't scroll through it.
You could create your own mapping to do it:
map <D-r> :w<CR>:!ruby %<CR>
% is the current file. If your file starts with #!/path/to/ruby you can omit the explicit call to ruby in your mapping.
Haven't tested the <D-r> mapping - no mac here. It's likely configuration dependent.
The following question has the answer to exactly what I was looking for
https://superuser.com/questions/133886/vim-displaying-code-output-in-a-new-window-a-la-textmate
This question already has answers here:
Can one executable be both a console and GUI application?
(9 answers)
Closed 6 years ago.
Is it possible to (and if so, how do I) make a single program work both as a console application and a GUI version using Delphi 2007?
What I am after is that if the program is run with the appropriate command-line options, it should function as a console program, printing output to the console using WRITELN, but if no command line arguments are given it should run as a normal Delphi GUI application?
The catch is that when running as a console application, the command line interpreter waits for the application to terminate before allowing you to enter a new command, whereas a GUI application started from the command line immediately returns you to the command line and the GUI application is started in a detached process. I want this behaviour retained.
I don't mind something like this:
IF GUI THEN StartApplicationAsGUI(ParamStr(0))
ie. I don't mind that I'll have to restart the application using some form of EXECUTE call to start it in GUI mode if needed, as long as the command line interface returns to the command line input when the GUI version is started.
I'd prefer a solution/suggestion that is along the lines of:
<Parse Comnand Line>
IF ConsoleMode THEN
RunConsole(Parameters)
ELSE BEGIN
Application.Initialize;
Application.CreateForm(...)
Application.Run;
END
(or vice-versa, ie. doing things a special way if GUI mode)
so that I can still use Delphi's IDE and VCL when making the GUI interface...
On Windows this is a little bit tricky. Actually the distinction between a console application and a GUI one is a single flag in the PE header. You can easily write console applications that create windows but that way you always have the console window around (you could hide it, though, but that wouldn't be nice when people run your program from cmd).
You can, however write a GUI application that creates a console if it needs to, using the AllocConsole function:
A process can be associated with only one console, so the AllocConsole function fails if the calling process already has a console. A process can use the FreeConsole function to detach itself from its current console, then it can call AllocConsole to create a new console or AttachConsole to attach to another console.
If the calling process creates a child process, the child inherits the new console.
AllocConsole initializes standard input, standard output, and standard error handles for the new console. The standard input handle is a handle to the console's input buffer, and the standard output and standard error handles are handles to the console's screen buffer. To retrieve these handles, use the GetStdHandle function.
This function is primarily used by graphical user interface (GUI) application to create a console window. GUI applications are initialized without a console. Console applications are initialized with a console, unless they are created as detached processes (by calling the CreateProcess function with the DETACHED_PROCESS flag).
However, when run from cmd this will likely cause another console window to appear instead of re-using the existing one. I don't know whether a good solution exists there.
IMO, the best approach here is to have non-visual classes that actually do the work of the program. Then you can call that from a GUI program, and you can also call it from a separate command line program. Both programs are just wrappers around the functionality of your class(es).
This forces the design to be clean too - your classes necessarily are separated from the GUI layer of your application.
http://blogs.msdn.com/oldnewthing/archive/2009/01/01/9259142.aspx
Windows has different values in executable's header for console and UI application (see more details here). So it seems to be impossible to make the same executable to work in both modes.
As an alternative, you can open a console in you UI app, but it will be new console, not the one you've started app from.
AttachConsole() may be used to get a hold of the parents console.
E.g. if the application is started from a cmdline shell, AllocConsole() can be avoided:
if not AttachConsole(ATTACH_PARENT_PROCESS)
then AllocConsole;
More info here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681952(v=vs.85).aspx