NME Compile HTML 5 Error - haxe

I've been working on a NME application and when I compile it I receive the following error:
"C:\Program Files\Haxe\haxe/lib\nme/3,5,5/nme/errors/EOFError.hx:25: characters 0-18 : Class not found : browser.errors.EOFError
Build halted with errors (haxelib.exe)."
I check and the corresponding class does not appear to exist. I've tried reinstalling NME, however the problem remains.
I'm using Flash Develop, NME 3.5.5 and Haxe 2.10.
I verified that a hello world program would compile properly in both flash and html 5, before starting this project and it still does.

If you haven't gotten too far along in your project, I would recommend switching to the latest Haxe 3 and NME (or OpenFL, which is still very new).
I know that's not a specific solution to that issue, but the issue may go away, and it's worth upgrading. There is a Windows binary available:
http://haxe.org/download

Related

LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in

I have been using a graphics library from Smaller Animals Software called ImgSource. Unfortunately, Smaller Animals Software has closed and is no longer available to answer questions. Recently, I had a system failure that deleted my only up-to-date copy of the library (I thought I had a backup but was wrong). I did, however, have the source code. I recompiled the library, both release and debug. (Both are static .lib files) I am also using MSVS 2019 Community edition and the project is an MFC project. The problem, and why I'm posting here, is that when I link the new release library with a previous project, the project compiles properly. However, when I build the debug version, it will compile, but not link and produces the linker error discussed LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease' in file.obj
A reasonable conclusion is that there is something wrong with the debug library. However, if I build a new project and link the debug library, everything works fine. So, the error does not appear to be in the library. It seems I could start from scratch and completely redo these projects, but they do reflect a tremendous amount of work.
I can't figure out how to modify the settings in the existing projects so that they will compile in debug mode. I have tried the suggestions offered in the article referenced above. Further suggestions would be greatly appreciated.

MPS error when rebuilding projects: "no output location for x#descriptor"

I am new to JetBrains MPS and am trying to get a feel for Jetbrains MPS applications that others have built. However, I am finding that I am unable to build most applications I download from GitHub. Mostly, I get errors when trying to rebuild the project. One common error I get is:
no output location for x#descriptor
...
Error executing target jetbrains.mps.make.facets.Make.reconcile : no input. Stopping
where x is the name of the language.
what must I update to fix it?
Extra Details:
OS: Windows 10
MPS: 2020.2
example git repo: https://github.com/DSLFoundry/mps-examples/Sorting
Another cause could be that for some reason the Java Facet has not been enabled. AFAIK between 2020.1 and 2020.3 (haven't checked 2020.2) this has become necessary for some/most languages.
The easy fix is to enable the Java Facet in the Module properties for the Language/Generator which reports "No output location for.../behaviour" etc.

"Module openfl.display.Shader does not define type Shader" when trying to do a release for neko or windows [Flash Develop/Haxe]

this is somenthing I was trying to solve for HOURS, but I don't get why this is not working.
First of all, I'm trying to do a release for neko or windows in Flash Develop. My project is a OpenFl one, and the language is Haxe 3.
What I have installed:
actuate: [1.8.6]
flixel-addons: [2.3.0]
flixel: [4.2.1]
hxcpp: [3.4.64]
lime: [2.9.1]
nape: [2.0.20]
openfl: [3.6.1]
And yes; I'm using haxeFlixel.
When I try to do a release in windows or neko, these errors appear:
-E:/HaxeToolkit/haxe/lib/openfl/3,6,1/openfl/_internal/renderer/opengl/utils/SpriteBatch.hx:12: characters 7-28 : Module openfl.display.Shader does not define type Shader
-E:/HaxeToolkit/haxe/lib/openfl/3,6,1/openfl/_internal/renderer/opengl/utils/SpriteBatch.hx:12: characters 7-28 : For function argument 'ax'
-src/skill/SkillLogicProjectil.hx:13: lines 13-54 : Defined in this class
-E:/HaxeToolkit/haxe/lib/openfl/3,6,1/openfl/_internal/renderer/opengl/shaders2/Shader.hx:11: characters 7-28 : Module openfl.display.Shader does not define type Shader
The most funny thing is: I'm not even using Shader in SkillLogicProjectil. That class only creates a sprite that follows a Player and has a var with the sprite that represents the skill.
If I comment this class, the error is in another class, and finally ends in my GameState.
This error doesn't appear when I do a release in html5. In html5 there are no problems with the release, but I canĀ“t make the game load without Flash Develop running the process in http://localhost:2000/. I need to make a release that can be opened with a computer, without using Flash Develop to open it.
What can I do?.
The new version of Flixel supports Haxe 3.4.3 and OpenFL 8, have you given these versions a try?

Program Not Responding after clean compile?

I've had to move my stuff from a failing hard drive, so I've had to set up and reinstall everything again. And I've run into a couple problems.
So I've got two errors here. The first error that I get is when I open flashdevelop to begin working. I get the error of:
Can't Find Haxelib.exe
And of course, I've installed haxe and haxelib and everything else that's needed pre-setup. However, when I run, the flash and html5 targets work fine regardless. I don't know why that error shows up. Any ideas?
My second problem is that I've installed the necessary stuff for the windows runtime. However, when I try to run the exe in or outside of flashdevelop, the program freezes and gives me the:
This program is not responding.
error that you sometimes see when you crash a program. However, I have my neko stuff set up and it compiles fine, it just crashes on start. I have the background set to neko. I have just a sample hello world FlxText object like this:
hello = new FlxText(0, 0, 100, "Hello World!");
#if neko
hello.color = 0xffffff;
#else
hello.color = 0xffffffff;
#end
add(hello);
Any idea what could be causing the start crashes? It also has me wondering if the two aren't related some how.
Thanks in advance!
Using windows 8, haxe, haxeflixel, windows & neko runtimes.
I had this posted on another forum. The not responding error is fixed easily by adding:
<window allow-shaders="false"/>
In the projects xml file. The haxelib error still shows but it may be a non issue.
Things to try:
Make sure you use Haxe 3 and OpenFL (I think there is no sense of using Haxe 2 or NME).
Check if Haxe on PATH is Haxe 3 and check that OpenFL work fine. (Just open "cmd" and type "haxe" there to see version of Haxe available and type "openfl" there to test if it works, also check "haxelib")
Check FlashDevelop Haxe SDK
Trace your haxelibs here(use haxelib list in cmd)
This program is not responding.
This may mean, that you don't have some .dll in bin folder.(Depending on what you use in your project).
Or this may be connected somehow with your GPU drivers. Or it can be anything other. To get more info about that crash, try compiling to neko, and print output here.
Make sure you have latest haxelibs installed (haxelib upgrade and haxelib selfupdate)
To help you I need more info, print FlashDevelop output here.

fatal error C1084: Cannot read type library file: 'Smegui.tlb': Error loading type library/DLL

I am trying to build an old version of an application which consists of VC++ projects that were written in Visual Studio 2003.
My OS is Windows 7 Enterprise (64-bit).
When I try and build the solution I get the following errors:
error C4772: #import referenced a type from a missing type library; '__missing_type__' used as a placeholder
fatal error C1084: Cannot read type library file: 'Smegui.tlb': Error loading type library/DLL.
They both complain about the following import statement:
#import "Smegui.tlb" no_implementation
This is not a case of the file path being incorrect as renaming the Smegui.tlb file causes the compiler to throw another error saying it cannot find the library.
Smegui is from another application that this one depends on. I thought perhaps I was missing a dll but there is no such thing as Smegui.dll.
All I know about .tlb files is that they are a type library and you can create them from an assembly using tlbexp.exe or regasm.exe (the later also registers the assembly with COM)
There is also an Apache Ant build script which uses a custom task to invoke devenv.com to build the projects. This is the same script that the build server originally used to build the application. It gives me the same errors when I try and run it.
The strangest thing about this is that I knew it ought to work seeing as it is all freshly checked out from subversion. I tried many different combinations of admin vs user elevation, VS vs Ant build, cleaning, release.
I have got it to build successfully about 5 times but the build seems to be non-deterministic.
If anyone can shed some light on how this tlb stuff even works or what this error might mean I would greatly appreciate it.
I found a far more reliable solution: open the tlb with oleview.exe and then close it.
Not sure what this actually does but it works every time.
I think oleview is actually one of the samples included with Visual Studio but I haven't had the time to debug it and see what it is doing.
I ran into this error because one type library was trying to load a dependent type library, which it could not find. Even though the dependent type library was in the same directory, and even though that directory was in the searchable path, the compiler would error loading the first type library, but not mention the dependent type library in the error.
To find the pseudo-missing type library, I ran Process Monitor (procman64.exe) during the compile. This showed that after the reported type library had successfully loaded, a dependent type library could not be found. It even showed all of the places that it was looking for the dependent type library, none of which were where it should have been looking (e.g.: ).
The fix was to add a <PreBuildEvent> to the project to copy the dependent .tlb file to one of the directories that was actually being searched.
<PreBuildEvent>
<Command>copy /Y ..\Lib\Interop\CWSpeechRecLib.tlb .\</Command>
</PreBuildEvent>
http://msdn.microsoft.com/en-us/library/sce74ah7%28VS.71%29.aspx
smegui.tlb is referencing some other tlb that the compiler can't find. If you have the .idl for smegui you might be able to figure out what the other is. I suspect the missing tlb is something that original build machine had registered but that your machine doesn't have registered.
A type library is a binary description of a set of interfaces, coclasses and enums. They're usually generated for COM components, in the case of tlbexp and regasm the tlb is created from the assembly metadata. For native COM components they are usually generated from an idl (Interface Description Language) file by the midl tool.
Edit:
I just noticed you're on x64 Windows. Are you building the project with a new version of Visual Studio? If so, are you targeting x86 or x64? If the latter, it may simply be a 32bit component that the compiler can't find (or less likely, a x64 component the x86 compiler can't find if you are targeting x86), for WOW64 the registry is virtualized for x86 vs. x64 applications.
Well I finally found out why I managed to get it to build sometimes and not others... sort of.
So long as I ran the build script with elevated administrator permissions and let that get as far as it could until that error occurred, then run the build script again as a protected administrator succeeded. Those steps must be done in that exact order with no other steps in between. If I try build in Visual Studio it does not work (although I did get it to succeed once). Probably some kind of virtualisation issue although it still doesn't quite make sense.
Well I don't need help on this any more and I know it's probably impossible to fully answer this question without knowing exactly what the build is doing. However if anyone does have any more thoughts I would happily receive them.
Cheers,
Steiny

Resources