Description of the problem:
I'm testing the irisVR Beta and I'm trying to launch some cranium.obj 3D model I have. I dragged and dropped the model directly on irisVR launch window and clicked launch. A terminal opens up for half a second and closes. Then nothing happens.
Image 1 -- Iris launch window -- indefinite progress bar
Image 2 -- irisVR console.log
Here is the error I am getting in the console.log:
Question:
What is causing this error, and how do I fix it?
Nate here from IrisVR. Just wanted to let you know that for the next few versions (next few weeks), we have removed OBJ support. Your question makes me realize that our documentation needs some TLC and is misleading - I have added updating it to my task list and it should be amended by EOD tomorrow. Thanks for that!
You'll notice that the drop-zone graphic only includes the SketchUp and Revit icons. This won't last long, I promise! We are building a new system for handling the model geometry and optimizing it for VR and it broke part of the OBJ code. Ultimately, these changes are going to lead to some terrific improvements. Given our limited programming bandwidth right now, we had to pick two file formats to carefully maintain throughout this migration process and we'll pick up the pieces with OBJ ASAP
Thanks again for your patience and for using the app! In the meantime, give a SketchUp model a try :)
Another tester here - ran into the same issue on a fresh Bootcamp install, it's not isolated to the *.obj support that Nate mentioned as was able to recreate with both Sketchup and Revit models.
The current release (v0.2.4) appears to have some dependencies on the Microsoft Visual C++ 2010 redistributable. If you don't have this installed, it will block the associated IrisVR ModelConverter from running and that statistics.ivr file from being generated. Unfortunately there is nothing logged to this effect, so took a bit of digging to find. You will however see a window flash up briefly, then close. This is the ModelConverter attempting to launch and quit.
To resolve, download and install the redistributable from here.
Related
I'm trying to use LabView to operate a ThorLab CS235CU camera. However, so far I haven't had any success using LabView to operate it, despite searching the provided thorlabs and national instruments documentation and google for an answer all week. I started by trying ThorLab's VIs that came with their software, but anytime I run a script it returns the following error:
Error 1386 has occurred at Invoke Node. In the provided "simple image aquisition" VI, this error occurs at 3 locations (steps 2, 3, and 4) before deleting the rest of the script, if run with execution highlighted. National Instruments has 3 suggested fixes on their website: unblocking DLLs manually, which seems unrealistic given I don't know what is causing this error; running LabView as an administrator, which I had been doing from the beginning and didn't help the issue; and creating a configuration file, which I tried but did not work. I put it in C:\ProgramFiles\National Instruments\LabView 2020 as well as C:\ProgramFiles(x86)\National Instruments\LabView 2020, but the error still occurs. I'm very new to using LabView and couldn't begin to explain why this error is occurring, so anyone that can or knows how to help, please do.
It seems that you didn't set up the ThorLabs driver properly one way or another. Often it is the manufacturer's installer that must be run first (with LabVIEW turned off) and eventually you'll find the according driver/dll wrapper VIs (also referred to as LabVIEW-Driver) in some arcane subdirectory like <Program Files>\ThorLabs\<Product>\Drivers\Labview\...
It might make sense to copy that directory to your myProject\drivers\ Folder and the simple image acquisition.vi to something like myProject\examples and work your way from there. Also make sure you're using LabVIEW 32bit since few third-party drivers come in 64bit.
My WiX bundle behaves very badly on a specific XP machine (x86). It stalls for six minutes during the "initializing" phase (before any bundled installers are run). From the logs it seems extremely likely it is due to the dodgy state of windows update on the machine:
[090C:0FC0][2018-03-27T19:31:17]i358: Pausing automatic updates.
[090C:0FC0][2018-03-27T19:37:23]w308: Automatic updates could not be paused due to error: 0x80080005. Continuing...
[090C:0FC0][2018-03-27T19:37:23]i360: Creating a system restore point.
I am using WiX v3.10 to make the bundle. I can find very similar situations from google search but the solution always revolves around updating the target machine. I need this installer to work as expected regardless. When I test a regular msi on the same machine it goes through fine.
Is there any way I can mitigate this issue? E.g. can I stop the WiX bundle from trying to pause windows update or something similar? The fact that the installer doesn't even notify what the issue is is extremely problematic, any user is likely to be confused.
The whole point of this WiX installer is to make an install package portable and simple but this actually seems LESS portable than just the msi...
Update: Also tried building the bundle with WiX 3.11 but got same problem. Though now it produces an actual error rather than installing regardless, which I suppose is an improvement.
UPDATE: after looking in the WiX source code it looks like WiX's Burn feature is making a few calls to Microsoft.Update.AutoUpdate (%SystemRoot%\System32\usoapi.dll - %SystemRoot%\SysWOW64\wuapi.dll) and a few other COM objects here and there.
See towards the bottom (screenshot) for a hot COM tip to quickly get an overview of different COM object models.
It must be this AutoUpdate call which hangs causing a timout along the lines of what is described in this blog. I believe you can find the exact source code location by searching for hr = WuaPauseAutomaticUpdates(); in the elevation.cpp WiX Burn source file (Github link). The actual calls to the COM object are in wuautil.cpp.
I am not familiar with the Windows Update Agent Object Model, but I suppose you could try to call the Pause function in a test VBScript just to see what kind of error you get on your problem system (if any). I can't see how you would get anything but a lockup on your problem system, so maybe try first on your main box? This is obviously at your own risk. I would assume a reboot or a call to Resume will continue the process as normal. I also see a call to SystemInformation.RebootRequired in the C++ code, which I have also added to the VBScript:
Set autoupdate = CreateObject("Microsoft.Update.AutoUpdate")
autoupdate.Pause()
MsgBox Err.Number & " " & Err.Description
Set sys = CreateObject("Microsoft.Update.SystemInfo")
MsgBox sys.RebootRequired
' autoupdate.Resume() ' Enable to resume AutoUpdate
Set sys = Nothing
Set autoupdate = Nothing
Let's face it: Windows Update is broken on your XP machine - isn't it? Maybe the WiX guys can add a shorter timeout? I am not sure what is better - 1) to shorten the timeout, 2) to remove the whole call or 3) to just bomb out telling the user that Windows Update is broken? Frankly the latter would probably alert the user to something very serious (often malware).
UPDATE: as you state yourself, Windows Update is almost certainly broken on this particular machine. I would try the MSI properties suggested below for testing, and then zap Windows Update as suggested here (same link as below) (techical).
But wait, maybe a malware check is in order, before wasting time on anything else?
Maybe try this free Sysinternals tool? Checks all running processes by hash using almost 70 scanning engines (no heuristics though). Fire up all you got (only running processes are checked)
Go File => Show Details for All Processes and then elevate to get to scan system processes as well. Now click "System" to scan drivers for example (*.sys files).
Often a great way to get your system admin to agree to rebuild a problematic machine for everyone. Suddenly you go from "deployment problem" to "machine specific problem" - and it is out of your hair. GIGO problem.
Nicely formatted and phrased question BTW. And just for reference: Sysinternals.
Workaround?
I have never seen this, but I have seen some MSI files suddenly pausing for a long time whilst installing whereas they would install quickly during test installs just minutes before.
My guess is that this could be related to system restore and the creation of a restore point at certain "intervals". I am not sure what algorithm is used to determine when such a restore point is created and not, but I wrote an answer many years ago on the issue of speeding up MSI installations: How can I speed up MSI package install and uninstall?
As you will see, you can disable the creation of a restore point for your setup by setting an appropriate command line involving the property MSIFASTINSTALL (and a few other tweaks - please just read the linked serverfault.com answer). I would try this to see if your setup stops locking up / hanging.
Causes?
Some hits from the web:
Could it be that Windows Updates is also trying to create a restore point at the same time as your MSI-package? Setup hang when trying to disable windows updates (PhilDW)
Could it be that the Windows Update feature is corrupted?
Similar issue: WiX Toolset installs VC++ redistributable (x86) 2015 too slowly
I would first try the MSI properties mentioned as a "workaround" above, and if that doesn't work, I would try to see if fixing Windows Update as explained in the link directly above works. Crucially I would also let Windows Update complete its task of installing all available updates before running your bundle again.
Hot Tip (COM)
I don't like to recommend commercial tools, but we all need some quick tricks and quick wins at times - which is what this is about. Get hold of VbsEdit and use its light weight object browser to quickly see details from any COM object model. Just do a CreateObject and you will instantly see the object model in the object browser to the right in the application window (View => Object Browser if it is not there).
Just type in something like this:
Set installer = CreateObject("WindowsInstaller.Installer")
I find this to be a time-saver when I need to deal with legacy COM stuff and Visual Studio is very sluggish. I just have the VbsEdit trial version, and it allows basic editing. And let's throw in a rant: why on earth do they not make a Javascript version? I am missing something - as usual :-).
Throwing in a second screen shot to show a more interesting object model information tidbit:
Should you want to try it, here are some other CreateObject statements you can try:
Set autoupdate = CreateObject("Microsoft.Update.AutoUpdate")
Set fso = CreateObject("Scripting.FileSystemObject")
Set scriptshell = CreateObject ("WScript.Shell")
Set dictionary = CreateObject("Scripting.Dictionary")
Set shell = CreateObject("Shell.Application")
Context
As a university project we want to change the the pharo vm to use an object-table and see what happens.
We use a pharo-vm clone from github and VMMaker. Building the VM works fine.
To get started we added a primitive that returns an incremented Integer:
InterpreterPrimitives>>primitiveIntegerIncrement
"increments an integer"
self pushInteger: self popInteger + 1 .
and modified StackInterpreter class>>initializePrimitiveTable accordingly
MaxPrimitiveIndex := 576.
"... and so on ..."
(575 primitiveFail)
(576 primitiveIntegerIncrement))
And it works.
Problem
When we make changes to the VM we want to test-run already in the SmalltalkImage so we do not need to compile and see it did not work.
Something like:
StackInterpreter test: '1 inc'
And then I can debug if the primitive is wrong or an error occurs. Of course there needs to be done much more but how can I achieve this?
What we tried
category VMMaker-InterpreterSimulation class StackInterpreterSimulator. Trying the code in the comments
DoIt
^ (StackInterpreterSimulator new openOn: Smalltalk imageName) test
errors:
displayForm := 'Display has not yet been installed' asDisplayText form.
the ByteString does not understand asDisplayText
(CogVMSimulator new openOn: Smalltalk imageName) test
(InterpreterSimulator new openOn: Smalltalk imageName) test
error:
PrimitiveFailed: primitive #basicNew: in Array class failed
I also found this screen cast but it only debugs the VM from outside using gbd: http://vimeo.com/22485382#
Our project is hosted here: http://smalltalkhub.com/#!/~kirstin/PharoObjectTable
Current Status
We started implementing an object table. The lookup of attributes can go throught the object table. Full object table support and no usage of direct pointes is very tricky since pointers are expected everywhere. So we use pointers into the object table to identify when a lookup should go through the OT. We also found all object creation primitives and add new objects to the table.
How long is your project and how many people are you ? To me what you try to do is quite some work. Do you have good knowledge about low level behavior ?
To answer your question, the main problem here is that the cog simulator is not maintained in the pharo vm fork. This is because no one in the pharo crew use the simulator. We only use external debugging from gdb. In fact the pharo folks work mostly on VM plugins, the core of the VM is mainly maintained and developed by Eliot Miranda which works on Squeak. Therefore we report to him when there's a bug in the VM core.
For your project you would have to split it in at least 2 steps:
step 1: make the object table work with the stack VM
step 2: make the JIT work with your object table
Note that for step 2 I would recommend not to change the way an object access its header, therefore having a VW-like object table where you have the fixed size header on the one in the the object table, and the fields of the objects (and maybe header extensions) in the heap.
So use the StackVMSimulator and build the StackVM first. When everything will work (including context), you can think about hacking the JIT. Recently Guillermo Polito ported the Stack VM to the build process (see PharoSVMBuilder instead of PharoVMBuilder), a guy reported problems with this builder but you could hack it a bit to make it work.
Now to make the simulator work on Pharo 2.0 (which is the Pharo version of the generator image you have), you have to open the monticello browser and merge from Eliot's branch the Cog package (repo MCHttpRepository location: 'http: //source. squeak. org/VMMaker'), but not the latest Cog, the one at around the same date as the current VMMaker package of pharo-vm because the latest Cog and VMMaker of Eliot's branch are not stable.
The alternative being to start from Eliot's build image and merge things from the pharo branch. Here are infos about how to build the squeak development image (http://www.mirandabanda.org/cogblog/build-image/).
Then Eliot gave me this script once:
| cos |
cos := CogVMSimulator newWithOptions: #(Cogit SistaStackToRegisterMappingCogit).
cos desiredNumStackPages: 8.
cos openOn: 'my/favourite.image'.
cos openAsMorph; toggleTranscript; halt; run
You don't need the SistaStackToRegisterMappingCogit option. I guess some similar script with the StackVMSimulator should work.
Lastly there are some documentation about the simulator but it is only for the CogSimulator (these documentations expects you already knows how the StackSimulator works, and just give you hints about how to use it with the JIT):
http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/
and in one of the video named "Cog VM (part x)", x being from 1 to 6, Eliot shows how he uses the simulator to disassemble x86, print the stack and inspect the heap.
Another tip, ask your questions on the pharo mailing list (pharo users or pharo dev), because here no one may notice your question (fortunately someone pointed me out your question this time).
And tell on the pharo mailing list if you managed to run the simulator in Pharo 2.0, some people (as me) are very interested in it. I was planning to do it at some point.
Good luck ! Nice project anyway.
The last time I tried to use the simulator is roughly a year ago, and I did not make it work.
However, there are a few patches, which I assume never got integrated that might be of help:
https://code.google.com/p/cog/issues/detail?id=106
https://code.google.com/p/cog/issues/detail?id=107
https://code.google.com/p/cog/issues/detail?id=108
Issue 107 includes a patch for your asDisplayText issue.
I know this is a site more for coding questions, but I have been having a problem with my game crashing for about two weeks now, and Apple hasn't even begun to be helpful in solving the issue or even identifying what it could be. I was hoping maybe someone has experienced something similar and could at least get me pointed in the right direction.
For about a week I had a problem with Xcode crashing every time i accessed a current file (gameboard.m) in my game. This file had existed in my game for months and NEVER caused a crash and never did until a few days after I installed Xcode 5. Whenever I would be working, and click on my gameboard.m, it would, with increasing frequency, crash xcode. When looking at activity monitor, my free ram would go from 5gigs to about 10 mbs, and I would have to force-quit xcode.
After gameboard.m would crash xcode, it would crash xcode upon opening every time after that. I found a temporary fix for the issue by duplicating my file, going into it and deleting the gameboard.m file, then copy and pasting it from the previous version and re-importing it.
Sometimes I could click on gameboard.m and it would open just fine, but then if i press Cmd+Opt+Shift+Left to collapse all my methods, THAT would crash xcode. Every time xcode crashes its the same thing, Ram goes to 0, freezes until force-quitted. After the first week and about 30 copy-pastes fo my game, my quick fix stopped working and I couldnt open ANY file on my desktop, including files I havent opened in months.
So far I've submitted a bug ticket, to which i have gotten no replys besides asking for additional crash reports, I've reinstalled xcode MANY times, created a new user and tried working on that, and am about to reinstall my OS. I'm trying to figure out if it is a code related problem, or a hardware problem that needs to get fixed. I know I have some memory leaks in my game which I am trying to address right now (I've been teaching myself how to program since the start and this has been a gaping hole in my education until now. Any good source material you guys know of point it my way!!)
Side question: If you have a memory leak, when does the computer take back over the allocated ram? Exiting simulator? Restarting computer?
Again, i know this is a bit of an unusual question for SO, but I've been unable to do any work for 2 weeks now and I cant see any end in sight, so any help or ideas i can get from you guys would be very helpful. Thank you!!
The most common way to resolve Xcode crashes is to clear out the derived data directory. Go to Preferences>Locations to find out where it is. Delete the whole directory tree. The default is ~/Library/Developer/Xcode/DerivedData but it may be different for you.
That said, the fact that this continued even when you were working as a different user is troubling, since by default the derived data directory is per-user, but it is possible you've set it to a single place.
I'm assuming by 'bug ticket' you mean the RADAR system (with its new facelift). If this is really preventing you from working on your app and that is critical, what you need to do is file a Technical Support Incident. You get 2 with your developer account, and you can buy 2 more at any time. This will put you in touch with an apple engineer that will focus on finding a solution to your problem as quickly as possible. I've only had to use it twice, and both times they had a solution for me within 48 hours.
I solved this by closing the project, then opening only the offending file in Xcode 5. Then 'Save' and the project then opened fine!
My Xcode was crashing every time I opened it for the last opened project. I got the issue resolved by following the following steps took from here.
Open a Finder window and navigate to your project
Right-click on the .xcodeproj file (it’s a package actually)
Select Show Package Contents
A new window appears
Delete a folder called xcuserdata
Also, delete scuserdata folder from project.xcworkspace inside the .xcodeproj file
I'm new to VB6 but i'm currently in charge of maintaining a horror of editor like tool with plenty of forms, classes, modules and 3rd party tools all chunk together like the skin faces on that guy in the texas chainsaw massacre...
What i don't understand is why i get different results when i run the app in debugging mode, vs when i compiled it and run it on my devevelopment pc vs when i installed it on a different pc.
Yes i know i'm dumb, so please direct me to where i can find out more about this. I'm hoping to find out something like different linking, registry related etc connection that i'm simply not getting right now, i.e. something like wax on, wax off :P
The main pain in the neck is when i'm trying to debug some errors from my QA and i need to find a spare pc to test this on plus i can't directly debug because i don't know where the code is if i do it that manner.
Thanks.
i run the app in debugging mode vs when i compiled it and run it on my
devevelopment pc
When you compile you have the option of compiling to native code or pcode. The debugger runs using pcode only. Under rare circumstances when you compile to native code there will be a change in behavior. This particular is really rare. I used VB6 since it's release and I may get it once or twice a year. My application is a complex CAD/CAM creating shapes and running metal cutting machine and has two dozen DLLs. Not a typical situation. At home with my hobby software I never ran into this problem.
There are another class of errors that result from event sequencing problems. While VB6 isn't truly multi-tasking it has the ability to jump out of the current code block to process a event. If it re-enters the same block for the new event interesting things (to say the least) can result. I think this is the likely source of your problems as you software is an editor which is a highly interactive type of software.
In general the problem is fixed by reordering the effected areas. You find the effected area by inserting MsgBox or write to a text file to log where you are. I recommend logging to a text file as MsgBox tend to alter behavior that are timing or multi-tasking related.
Remember if a event fire while VB6 in the middle of a code block and there a DoEvents floating around then it will leave the code block process the event and return to the original code block. If it re-enters the same code block and you didn't mean for this to happen then you will have problems. And you will have different problems on different computers as the timing will be different for each.
The easiest way to deal with this type of issues is create some flag variables. In multi-tasking parlance they are known as semaphores or mutexes. WHen you enter a critical section of code, you set it true. When you leave the routine you set it to false. If it is already true when you enter that section of code you don't execute it.
when i installed it on a different pc.
These are usually the result of the wrong DLL installed. Most likely you have an older version while the target has a newer version. I would download the free Virtual PC and create a clean Window XP install to double check this.
If your problem is event timing this too can be different on different computers. This is found by logging (not MsgBox) suspect regions.
If you can display a screen shot or the text of your specific errors then I can help better.
The first thing to check would be the versions of all the dlls that your app depends on - including the service pack version of the VB6 dll.
Have you any more specific details about what's behaving differently?