Does anyone know what version of node is used by meteor galaxy?
I just tried to deploy and got the following error:
SyntaxError: Block-scoped declarations (let, const, function, class) not yet supported outside strict mode
Therefore I assume that an old version of node is used.
The same code worked fine a couple of days ago.
Each version of Meteor is linked to a given version of Node. Galaxy probably uses the one linked to your project. You can see which version it is by running meteor node --version within your project directory (on your local computer), and (potentially) update it by running meteor update.
Related
I'm having problem with the infamous:
"/Users/n/Library/Developer/Xcode/DerivedData/Build/Intermediates/XCBuildData/build.db":
database is locked Possibly there are two concurrent builds running in
the same filesystem location
How do I fix broken "modern" build system getting stuck with a locked database?
I tried:
Cleaning the project
Deleting derived data
Updating cocoapods (sudo gem...) and pod install
Full nuking of Xcode folder with a fresh reinstall from App Store
Now I'm with a fresh Xcode installation, the project worked for a dozen builds(real device and simulator) and the problem comes back, making me unable to work on a project. How I can reset the locks on build.db or delete it?
I see this question asked multiple times, and the answers do not solve my problem. I'm not using build scripts, all I have is a couple cocoapods. Please do not close this question, as I'm asking specifically about lack of:
NO CUSTOM SCRIPTS
NO CONSOLE BUILDS
NO COMPOSITE TARGETS
The only thing that lets me continue working is turning to the legacy build system:
How can I use the legacy build system with Xcode 10's `xcodebuild`?
Xcode 10: unable to attach DB error
I encountered this when tinkering with cli, swift run democli. The error I got was:
unable to attach DB: error: accessing build database "/Users/xman/Desktop/democli/.build/x86_64-apple-macosx/build.db": database is locked Possibly there are two concurrent builds running in the same filesystem location.
I just remove the build.db, and the DB error is gone.
So far the only way to fix this is to turn the "Legacy Build system" on in File > Workspace settings. After certain number of computer restarts (or time elapsed?) the setting can be changed to the "new" build system again and it will build.
I managed to compile my project by adding to the xcodebuild command line:
OBJROOT="${OBJROOT}/DependentBuilds"
Thanks to this post: https://github.com/mattgallagher/CwlSignal/issues/24#issuecomment-396931001
I encountered the same issue while using Fastlane and the New Build System.
After switching from xcodebuild( ) to build_app( ), the issue was resolved.
The legacy build solution is too temporary. You can only use that from within XCode. You can't use it within VSCode, so you lose the Hot Reload sweetness.
I have a Java 9 app that I'm trying to package for the Windows Store. The strange thing is that it works as expected when I run the exe-launcher directly, but I get the following strange error when I run the launcher via the APPX package:
Exception in thread "Swing-Shell" java.lang.InternalError: Could not
initialize COM: HRESULT=0x80010106
at java.desktop/sun.awt.shell.Win32ShellFolderManager2.initializeCom(Native Method)
at java.desktop/sun.awt.shell.Win32ShellFolderManager2$ComInvoker$1.run(Unknown Source at java.base/java.lang.Thread.run(Unknown Source)
HRESULT=0x80010106 means RPC_E_CHANGED_MODE which I guess means that COM is somehow already initialized in MTA mode. But why is this only an issue in the Windows Bridge sandbox? Does the Windows Bridge somehow pre-initialize COM somehow for some reason?
I'm not sure if this is a Java 9 issue, or a Desktop Bridge issue, or both. Does anybody have any ideas on how to identify the cause of the issue or workaround?
I have made a minimal Sample Project to reproduce the issue
The application works when executed directly, but not when executed via the APPX launcher. Why?
Analysis
The JDK parts, that rely on COM being initialized (D3DPipeline, Sound and windows shellfolder access) all follow the same pattern:
the run the code in a separate thread
for this thread CoInitialize is called
at the end of the user level code CoUnitialize is called
This is in line with the documentation the MSDN holds for COM and the analysis is correct, the error indicates, that the COM subsystem is already initialized to be MTA threaded.
So I modified the java launcher (jvm.dll) and inserted
debugging statements into some of the native methods in os_windows.cpp.
I focused on the threading methods. What I found was this:
create_main_thread, create_os_thread, pd_start_thread all
run with COM not yet initialized
the native thread initializer (thread_native_entry) is already
running with COM initialized
I looked more into in _beginthreadex and indeed I finally found a lead
on stackoverflow. That pointed me to the sourcecode of threadex.c,
which is part of the Visual Studio 2013 Express Installation.
There you find, that _beginthreadex does not directly start the
supplied thread function, but runs a library initializer
(_threadstartex) first. Part of this initializer reads:
_ptd->_initapartment = __crtIsPackagedApp();
if (_ptd->_initapartment)
{
_ptd->_initapartment = _initMTAoncurrentthread();
}
_callthreadstartex();
_crtIsPackagedApp detects via a kernel function if the application is
run as a "PackagedApp" (i.e. AppX package) and if so, then the
RoInitialize function is called, which from my understanding acts like the big
brother of CoInitialize.
Long story short: If your application is build with Visual Studio 2013
and run as a packaged application, you get a broken environment.
It was confirmed, that the working versions of the Oracle JDK were build with VS2010 SP1 and the broken version was build with VS2013SP4.
Workaround
With the above information google finally found a reference, that supports the analysis:
https://blogs.msdn.microsoft.com/vcblog/2016/07/07/using-visual-c-runtime-in-centennial-project/
Quote from that article:
Note that the existing VC++ 12.0 libraries created during the
Windows 8 timeframe have runtime checks to determine whether the
app is running under the app container or not. When running
desktop apps as a packaged app, these checks might limit the
functionality of the desktop app or cause it to behave like a UWA
(Universal Windows Application) (limited file system access or
create thread initializing MTA etc.). We have fixed this behavior
in the VC++ libraries contained in these framework packages and
thus removing the modern app limitations from your desktop
applications.
So I see to options to fix applications, that shall be distributed as AppX packages:
either force the users to have the updates VC++ 12.0 binaries installed (by introducing the dependency cited in the blog post) or
replace the msvcr120.dll that is bundled with Java 9 (and I assume also Java 10) with the fixed version from the update packages
I would go with the second version and I tested this. Starting with a clean up-to-date Windows 10 System, I installed JDK 9.0.4, I cloned the supplied testcase, modified it use the locally installed JRE (not the JDK!) and build the appx package. Running this, I reproduced the problem. I then replaced the msvcr120.dll's in the JRE folder of my systems installation with the one contained in the APPX container from:
https://www.microsoft.com/en-us/download/details.aspx?id=53176
Hint: *.appx are just ZIP files with additional signatures, so you can
just rename them and extract the contents.
I rebuild the testcase and it is working as it should (no COM
initialization errors anymore).
we are currently trying to run asp.net core 2.0 (latest preview) on Linux arm (Raspberry Pi - Ubuntu Mate) and we were able to solve almost all the issues so application works very well.
Not we are trying to run it with SQL Db (Sqlite) and on Windows, everything works fine, we can connect and read the DB but on the linux, we are getting following error:
System.DllNotfoundException: Unable to load DLL 'e_sqlite3': The specified module or one of its dependencies could not be found. (Exception from HRESULT: 0x8007007E).
I think I already tried everything, installed sqlite on linux, but nothing helped.
Any idea what might be wrong?
Thanks a lot
Rado
i changed the library that I used to connect to sqlite to this one
https://www.nuget.org/packages/sqlite-net-pcl/
and then (and not sure why), on linux, i had to take their implementation of SQLite.cs and manually add it to the project.
So for Linux, i had to have that CS included and for windows, i just excluded it so the one which was part of DLL works. Didn't do more investigation, but it works on Windows and Linux as well.
If you need more help just let me know.
https://github.com/oysteinkrog/SQLite.Net-PCL
This file:
https://github.com/praeclarum/sqlite-net/blob/master/src/SQLite.cs
Thanks
Rado
I think we'll have to wait, the issue isn't closed.
UPDATE:
this issue is closed and launched new version. You only need install the last version 1.1.8 of the package SQLitePCLRaw.bundle_green and SQLite in ARM works fine.
I am having the same issue and I after some investigation I think this happens because e_sqlite3.dll for ARM is not (yet) included the SQLitePCLRaw.bundle_green package.
This package contains the dll for different architectures but linux-arm is not yet mentioned in the dependencies (linux, osx and v110xp (win7) are).
We probably have to wait until the .NET Core ARM team adds it properly...
I am learning meteor to build an app. I am finding things pretty unstable with Meteor. I am using Ubuntu 14.04 and Meteor 1.0.3
Everything is working fine and I had finished couple of Modules. And Suddenly one day, I get this error:
Can't find npm module 'mailcomposer'. Did you forget to call 'Npm.depends' in package.js within the 'email' package?
I know that 'mailcomposer' package is not there and installed it and worked well.
And again, projects work fine and again one day suddenly I get this error:
Cannot find module 'fibers'.
I really want to know what is happening. I have not removed any module nor did I add one. My project was running fine, but later when I opened the system I got the error. Does meteor remove or update modules automatically in the backend? Rather than fixing these errors, I want to know why modules are suddenly being removed.
I am novice in Meteor, apologies if the question is stupid.
I had this issue when I was deploying an Meteor app on Digital Ocean, for some reason I had to reinstall nodejs and fibers package to make it work again.
Are you switching from 1 node version to another?
If you are on the server:
get meteor's node version meteor node -v
verify if the server is using the same node version by node -v
Let me know...
So I'm just having a look at someone's code and downloaded it to try and run locally. The problem is that they last updated the project in April so they're not using the latest version of meteor but my localhost is trying to do just that.
I read there was a way to specify what version of Meteor would run locally (and subsequently package) but I can't find it again for some reason.
To set the version for the current project only, write the number in .meteor/release text file.
meteor update --release 0.6.4.1