When i try to execute nim to run without a garbage collector with --gc:none, i receive the following error message:
Error: system module needs 'initStackBottomWith'
Since i have found 0 references in the manual and nimc documentation, What does it mean and how do i solve it? I have tried putting everything inside a main proc and calling it like this:
proc main =
let noGarbage = 1 + 2
main()
(And i dont know what more i have to write to meet SO's quality standards)
This bug has been solved already here
Related
OK, here is my situation:
I'm making a program with a GUI in rust and I don't want to show the console window to the user.
The easy solution for this is the flag (don't know if that's the actual name for those things) #![windows_subsystem = "windows"]. It works great, the console is gone. Buuut.. The std::process::Command struct is unusable because it flashes a cmd window and not actually runs the command.
So if I have a code like this, I wont be able to use it. (But i need it)
#![windows_subsystem = "windows"]
use std::process::Command;
fn main() {
// GUI stuff that at some point uses the Command like below
Command::new("runas").args(&["/user:MY-COMPANY\\Administrator", "/savecred", path]).spawn().expect("Couldnt start Installer");
}
Does anybody have any idea how I can hide the console window but still be able to use the Command?
An easy workaround for this issue is conhost.
You can use Command::new("conhost").arg("YourCommand")
Came here. Couldn't figure it out either. This is so obscure and nowhere else is there any listed solution. That conhost workaround didn't fix it at all sadly.
Anyways, here's the solution after I finally figured it out.
Import CommandExt on windows from the std library, then set command.creation_flags(CREATE_NO_WINDOW) (you can find the CREATE_NO_WINDOW constant in windows-rs or winapi)
I really don't suggest using the constant manually, but here is the value anyways:
const CREATE_NO_WINDOW: u32 = 134217728u32; (or 0x08000000)
I would like to correct something though
It does actually run the command. It just also flashes the window while doing it. But of course, with the solution above, window flashing is now gone
Here's a list of all of the process creation flags
I get this error every 5 ~ 10 minutes while running my app.
My app doesn't stop or anything, but I think something needs to be done.
What is wrong and what should be done to avoid this error?
Some part of your code is calling registerPlugins, which is no longer needed... We need find out which package calls that and update it.
I am facing a problem with a program i am developing in Python 3.6 under Windows 10.
One particular command generates an unknown error, windows throws a 'program.exe has stopped working' message and the program exits.
The command is a 3d-model loader that is part of another python package (Panda3D). The crash is always associated with this command (and more particularly with a specific dll of the loader) and a particular file that it tries to open.
Since i cannot locate and therefore solve the faults in the dll (probably there is a bug there) i would like to just pass the problematic file and continue to the next one. But since python exits and i do not know the error type, the typical try, except does not work.
So, i would like to know if there is a way to predict this type of behavior in my code and prevent the program from exiting.
Many thanks for any help.
The pop-up "Program.exe has stopped working." can be caused by a variety of things and therefor there is no "one size fits all" type solution. But if you're certain that your problem is cause by a specific line of code you can always try something along the lines of :
try:
loader.loadModel("c/path/to/your/file")
except Exception as e:
print(e.message, e.args)
# your error-handling code here
Make sure the file path that you're giving to loadModel respects the following :
# WRONG:
loader.loadModel("c:\\Program Files\\My Game\\Models\\Model1.egg")
# RIGHT:
loader.loadModel("/c/Program Files/My Game/Models/Model1.egg")
Source : pandas3d official documentation
I've recently switched from chrome to firefox for greasemonkey development. I have some problems with debugging.
The following func
I meant to write:
self = this;
but instead I wrote
this=self;
Self wasn't defined, so the script didn't run, however, nor did I get any javascript error. Why and can I get them somehow? I get some errors.
Unfortunately, Greasemonkey - and javascript in general, along with at least a few other non-compiled languages - do not give very good debugging errors... I can't count the number of times it tells me there is a missing ) at the end of an argument list that doesn't exist, and it turns out my error is elsewhere...
When a script of mine won't run I add an alert after any value assignments and if they don't alert or alert the wrong data I have found the problem... for your example above I would debug by:
this=self;
alert(self);
Although I would probably see the problem when I went to add the alert, but if I didn't notice - the alert either wouldn't pop up or it would have the wrong value... and if it didn't pop up, the error console would likely say self not defined.
Whenever I call readdir before I create a thread, I get an error that looks like this:
perl(2820,0x7fff70c33ca0) malloc: *** error for object 0x10082e600: pointer
being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap
What's strange is that it happens when I call readdir before I create a thread (i.e. readdir is not called in any concurrent code). I don't even use the results from readdir, just making the call to it seems to screw things up. When I get rid of it, things seem to work fine. Some example code is below:
opendir(DIR, $someDir);
my #allFiles = readdir(DIR);
close(DIR);
my $thread = threads->create(\&sub1);
$thread->join();
sub sub1 {
print "in thread\n"
}
You need to use closedir, not close, to close a directory handle.
Fixing that makes this work correctly, though the symtom I see with close() is a little different:
*** glibc detected *** perl: double free or corruption (!prev): 0x09bc7d28 ***
However, this should still be reported as a bug, since it should be perfectly ok to leave the directory handle to be automatically closed at the end of the program.
You will have problems with open dirhandles with all versions of perl up to latest (or two) development version - this problem was fixed recently.
P.S. Use lexical dirhandles.