I've copied Rebol3 to my computer under windows. I am running it from the download not a full install, and it and seemed ok.
I tried using some very simple sample code for the GUI in the console and it fails with various error messages.
If I put in view [ and type enter it tells me its a syntax error (this works in reb/view 2).
Its a win 7 machine.
Version of Rebol3 is 2014-03-04 04:54
When I used help and typed the command what, view wasn't listed as a command.
Note the runtime support for the Rebol3 GUI dialect is not available in the "core" builds available at http://rebolsource.net.
Currently the GUI dialect is available in Linux/Android and Windows builds from Atronix Engineering:
http://atronixengineering.com/downloads.html
Or from Saphirion AG:
http://development.saphirion.com/rebol/saphir/
Note that the GUI behaviors in Rebol3 are similar to Rebol2's VID but has some differences, and is called R3-GUI. For a tutorial you might try Cross Platform App Development with Rebol 3 Saphir
Also notice that before invoking VIEW you will have to LOAD-GUI.
If I put in view [ and type enter it tells me its a syntax error (this works in reb/view 2).
The Rebol3 console is more basic than the Rebol2 console, and unfortunately doesn't support multi-line input at this time. You can only enter complete expressions before hitting enter, not partial ones. So hitting enter while there is still an unclosed bracket will give you an error. However if the code you're putting in is coming from the clipboard you can use do clipboard:// (via #GrahamChiu)
While Rebol3 currently lacks the behavior, it's encouraging that the Red console handles multi-line input in the Rebol2 way.
I am running it from the download not a full install
And the good thing is that you can run it from the download with no install. Because there is no install. :-)
Related
I can not run any program.
As per the instruction I went to vscode dev.
Open up my repository to run a test program.
However, unfortunately, I can not run any of my programs.
I have checked the doctrine which said that only chrome and edge are supported.
But I can not run my program on the terminal window because it tells the code can only run on environments such as codespaces, and local vs code.
What do I miss so that the problem is occurring?
As VSCode(.dev) issue 166506 illustrates, you cannot access terminal from your browser probably because that menu entry was hidden/removed on purpose.
With VSCode 1.75 (Jan. 2023), it will be restored with an explanation.
I'm guessing we intentionally suppressed it because terminals can't run in the web, but participants were simply confused that it wasn't there without connecting its absence to the fact that vscode.dev was a browser application.
Additionally, RemoteHub contributes a welcome view for the terminal which is one of the primary ways we explain that users must continue working elsewhere to run or debug code, and the fact that the terminal is completely suppressed means one less opportunity for users to organically learn the limitations of vscode.dev through our welcome views.
The message is the one you saw:
Terminal are not available in the web editor.
To use the terminal, you will need to continue in an environment that can run code, like a codespace or local VS Code.
You can develop remotely, but you need to execute locally.
I ran into the following issue using Pascal/FPC/Lazarus, but I think it is universal to all Windows .exe files, regardless of the IDE/compiler they are created with:
I created a Windows GUI application and wanted to display some debugging infos in a simple text console. Usually in a Pascal console application Write and WriteLn are used to write to a console/StdOut, but without additional measures in the project configuration this crashes because in a GUI exe (at least if created with Lazarus) a console window does not exist, I get a "file not open" exception.
There are multiple ways in Lazarus (centered around controlling the -WG switch during the build process) to get a console attached "write /writeln" can write text to, this is not the question. My question is, whether support for a console device (StdIn, StdOut, StdErr) is a Windows feature, which is part of the Windows Runtime, probably controlled by some metadata embedded in the exe, which in turn is controlled by this -WG switch, or whether it is a feature of a runtime environment added by a specific development environment, in this case by the Lazarus IDE or a runtime coming with the underlying FPC compiler.
Thnx!
Yes, consoles are generally not used for Windows GUI apps, though you can afaik instantiate some with allocconsole manually. Very early versions of Lazarus did this.
As David says, in general on Windows Outputdebugstring() is used or a logging library.
Technical details: afaik all windows processes (so also console) must actively activate the console, a task typically done by the runtime. The -WG switch suppresses this by setting a special IsConsole boolean variable to false.
The console io initialization is in rtl/win/syswin.inc procedure SysInitStdIO around line 515.
In there you can see that if not IsConsole a dummy file description is made (assignerror), and errors are redirected to message boxes(and might pass by GUI users unnoticed).
I installed ghostscript on windows and added it to path variable but I'm still getting
gs is not recognizes as internal or external command
I tried to run the .exe file to check the installation and it says
This software us supplied under the GNU AGPLv3 and comes with NO WARRANTY: see the file COPYING for details.
Unrecoverable error: invalidfileaccess in .addcontrolpath
Close this window with the close button on the title bar or the system menu.
On Windows the Ghostscript executable is not called 'gs', it's called one of gswin32/gswin32c/gswin64/gswin64c, depending on whether you are using the 32 or 64-bit version and the command line or windowed executable.
So the error message doesn't make a lot of sense, unless it's coming from some other application. In which case you are presumably running something written for, or ported from, Linux. Or, of course, you are trying to run it from the shell by executing 'gs' when you should be using the actual executable name. If that's the case, try using the correct name.
More puzzling still is that the title of this question doesn't appear anywhere in your question body. You don't mention an invalidfileaccess, nor do you quote the back channel from Ghostscript which would give some clue what you are doing.
We really need to know more about what you are doing that doesn't work.
I've written a program in Haskell that's going to be run on a Windows 7 machine. It's not my machine. I don't get to choose the OS.
It's been written using the ncurses package, and compiles just fine on my (Ubuntu) machine. Unfortunately, it won't compile on Windows, even under Cygwin. It gives me a very unhelpful error (Process exited with code: ExitFailure 1) when it tries to build the ncurses package.
I've tried specifying the exact locations of the header and dll files for ncurses to no avail.
Is there anything I can do, short of re-writing the software to use a different package?
In hindsight, I should've checked that it would compile under Windows some time ago, but since I've successfully used ncurses in C on Windows in the past, I had no reason to believe it wouldn't work.
My current code is available on GitHub.
Edit: If I were to re-write the IO parts using something else (as an absolute last resort) I would need to be able to do the following things:
determine the number of rows and columns in the terminal
be notified if the terminal is resized
be notified when a key is pressed (including arrow keys and function keys, without line buffering)
control the position and visibility of the cursor
disable echoing of standard input
change text/background colour
...and I would need to be able to do these things in both Windows and Linux.
I'm running a test script from batch file.
Because it is test, the programs are expected to fail once in a while. It is file as long as error code is returned so I can continue and mark specific test as failed.
However there is very annoying behavior of executable files under Microsoft Windows - if something fails it pop-ups window like:
This application has failed to start because foo.dll was not found, Re-installing the application may fix the problem
<OK>
Or even better:
The instruction at "..." referenced to memory at "..." ..
Click on OK to terminate the program
Click on CANCEL to debug the program
The result is known - the script execution blocks till somebody presses "Ok" button. And when we talk about automatic scripts that may run automatically at night in some headless virtual machine, it may be very problematic.
Is there a simple way to prevent such behavior and just make an application to exit with failure code - without changing the code of the program itself?
Is this possible at all?
The answer is following: You need to disable WER.
Simplest description for this I found at http://www.noktec.be/archives/259
Simply (ON XP): Right Click on My Computer > Advanced > Error Reporting > Disable
Voila - programs crash silently!
This does not solves problem when DLL is missing, but this is much rare case and this is good enough for me.
You can suppress AV's and such from showing a dialog box by running your application, or the script (the script engine, like cscript.exe), under a debugger.
Use Gflags.exe, or modify the registry directly, and set Image File Execution Options for the image in question. See this article for details on how to use the appropriate registry keys. You can set it up using a debugger commandline like "C:\Debuggers\ntsd.exe -g -G -c'command'", where you can pass commands to ignore certain types of exceptions in the -c"commmand" argument. This will effectively give you a tool to suppress interactive dialogs as a result of exceptions like AV, and will let the process continue (presumably to immediate end after the exception has occured).
This article explains the commands you can use to control exceptions and events from withing the debugger.
The -g and -G flags make sure that the process won't break into the debugger automatically during process start and end respectively. You'll have to play with the various exception suppression options to make sure that you 'eat' all possible first and second chance exceptiosn that might cause the process to break into the debugger.
Also, if you can tolerate a process being broken into the debugger (as against being stuck showing a dialog box), perhaps that would be a better option overall. You can evaluate each debug break in batch mode at a later time and decide which bugs you care to fix.
It is possible. We used to use IBM's Rational Robot product which could monitor the screen for specific items and, if found, send keystrokes to windows and other sorts of things.
We actually used it for fully automated unit and system testing, much like you're trying to do.
Now I thought that Robot has been through quite a few name changes so it may be hard to find but there it is, right on IBM's web page and with a free downloadable trial for you. It's not cheap, clocking in at a smidgeon under USD5,000 but it was worth it for us.
There's also TestComplete where you could get a licence for just unedr USD1,000 - it touts "Black-box testing - Functional testing of any Windows application" as one of its features and also has a downloadable demo to see if it's suitable before purchase.
However, you may be able to find another product to do the same sort of thing.
I initially thought of Expect but the ActiveState one seems to concentrate on console applications which leads me to believe it may not do graphics well.
The only other option I can suggest is to write your own program in VBScript. I've done this before to automate the starting of many processes (log on to work VPN, start mail, log in and so on) so I could be fully set up with one mouseclick instead of having to start everything manually.
You can use AppActivate to bring a window to the foreground and SendKeys to send arbitrary keypresses to it after that. It's possible you may be able to cobble together something from that if you want a cheaper solution.