Do I need to specify the experimental scope hoisting/tree shaking flag (in parcel 2.0) to use tree shaking?
parcel build entry.js --experimental-scope-hoisting
Or tree shaking is not longer a experimental feature in parcel 2.0?
As mentioned in this article regarding Parcel v2 beta 1 (which was released on June 18th, 2020), tree shaking is enabled by default
Related
It looks like Google has changed the App Engine Ruby Standard runtime in some way that has messed up GAE deploys for a large number of people so I am reporting it here. Deploys that were working two days ago now fail when deployed.
The error is always:
Bundler::GemNotFound: Could not find nokogiri-1.10.7 in any of the sources
This occurs regardless of the local state of your code and seems to have nothing to do with bundler configuration, gem versions, or anything like that. If nokogiri is in your app, it won't deploy to gae ruby standard environment right now, period.
This issue has been reported on Japanese stackoverflow but has not yet received any attention from Google.
We've finished root cause investigation. For the curious, here is what happened:
The Ruby runtime for the App Engine Standard Environment uses ruby-build to build/install MRI (the standard "Matz" Ruby runtime). On Oct 30, ruby-build changed its behavior to set --enable-shared when building recent versions of MRI. However, MRI built with the --enable-shared setting is not binary-compatible with MRI built without. This can manifest when loading C extensions (such as Nokogiri)... C extensions compiled against MRI built with one setting, will not load successfully in MRI built with the opposite setting.
Prior to the week of Dec 9, the live Ruby runtime was from a build prior to Oct 30, and was thus not built with --enable-shared. Then, that week, App Engine started rolling out a new Ruby runtime build that was built with --enable-shared. The new runtime was incompatible with the old runtime, and thus also with existing applications that included C extensions that were originally compiled against the old runtime, resulting in the symptoms described.
On Dec 11 we rolled the release back as soon as we determined that there was an issue with it. If anyone is still seeing issues, just redeploying your app should resolve them.
To retain compatibility with your existing apps, we will disable --enable-shared for all future updates of the ruby25 runtime, and we've put in tests to detect future changes to the runtime compile flags to prevent this from happening again. Note that this does mean that the ruby25 runtime will always be compiled without dynamic libraries. We are aware that there are a few gems that require dynamic library support, and these will not be supported under the ruby25 runtime. However, any upcoming ruby26, ruby27, and later Ruby runtimes, will be built with --enable-shared.
Finally, just a note that the official channel for reporting App Engine issues (assuming you do not have a GCP support plan) is to file an issue in the App Engine Issue Tracker. (You can find a link from https://cloud.google.com/support/docs/issue-trackers). We're not always checking stack overflow, but the issue trackers feed directly into the internal queues at Google.
updating all the bundle things... Could solve this kind of
could not find _______ v ___ in any of the sources error
Just try to run ....
bundle update --all
Thinking may this solve all bundle problems accordingly..
Hello? I am a Korean developer who is developing using the Tango Unity SDK.
I'm using the GanKino version and are now updating to the IKarioTikos version.
Is there a specific reason to use TangoCamera instead of Tango ARCamera in IKarioTikos's Demo Sence, AreaLearning?
Actually the change has been made since Gankino's update in may 2017. If you look at the release notes, it says:
SDK updates: The Tango Unity SDK now has a single TangoCamera prefab
that supports the TangoARCamera and TangoDeltaCamera use cases.
What I understand is that they just grouped the different prefabs they used to have (TangoARCamera, TangoDeltaCamera) into one single prefab called TangoCamera. The point is that they didn't update the examples so AreaLearning example still uses the now deprecated TangoARCamera.
Except the fact that they say it is now deprecated, I personnally have no problem of still using TangoARCamera prefab in my app. I might change when the examples and tutorials will be fully updated.
TangoARCamera and TangoDeltaCamera have been deprecated in the latest release. You can just use TangoCamera now. Just remember to enable the TangoARScreen script component in order to enable AR functionality.
I've successfully built and run AR apps with TangoSDK_Ikariotikos_Unity5 on Unity 5.6.3f1 using the above approach. Do note that initial releases of Unity 2017 does not support the Tango downloaded package so best to use 5.6.xxx
I want to know the loss for my w2v model and I upgrade gensim to the latest version, but still can't use the argument compute_loss, am I miss something??
No released version of gensim (through 2.2.0 of June 2017) yet has that feature. It is a work-in-progress in the develop branch, which should appear in a future release.
I'm trying to use the Debugger with elm-reactor but I get this error:
`Debug` does not expose `watch`.
I'm importing the Debug package:
import Debug
as per the mouse example
As of 0.17.0 release, Debug package no longer exposes watch function.
Debug.watch only makes sense in the context of Time-Travel Debugging, which is not available in 0.17.0 release.
The example you are referring to is written using Elm 0.16.0, any examples using Signal package are not relevant anymore.
See more details on the latest release in the official blog post from Evan: A Farewell to FRP
watch was removed from Debug prior to the release of 0.17.
Here is a discussion about the decision which oscillates between moving watch and watchSummary to a new Reactor module (since they were only useful within elm-reactor), or replacing them altogether with log and logSummary. Neither of these resolutions have happened as of 0.17, so we are left without them for now.
I see each cfx tools always produce xpi with its own minVersion and maxVersion. However, those are limited to the versions which the SDK is compatible with, e.g. SDK 1.14 only for FF 21 - 25.0a1 , SDK 1.17 only for FF 26 - 30. My questions are:
Do I need to package my extension with new SDK everytime new version comes out ?
How do I maintain and update my extension in the future? Does Addon Developer Hub provides a way to submit the same extension for multiple SDK versions ? I tried to look around but couldn't find a way to submit multiple versions.
I want to make FF 21 as the minimum version, since that's the version which has SDK built-in. My extension currently compiles with both SDK 1.14 and SDK 1.17 with only cosmetic(syntax) adjustment.
The developer hub lets you choose which versions of Firefox the add-on is compatible with. This is just a GUI for setting the minVersion and maxVersion in the install.rdf. As long as you don't use modules or methods that require Firefox 22+, it shouldn't matter which version of the SDK you use, as the version of the SDK being run is determined by the version on your user's browser.
It's hard to find module specific compatibility (you can always go to the docs for the specific module and look at the edit history), but have a look at the SDK API Lifecycle to understand which modules can be used. Some notable example are:
The new UI modules require FF29 and some of their features require FF30.
The widget module is deprecated from FF 29 onwards, being replaced by the above.
One way to handle the above for backward compatibility is to do the following:
const { version } = require('sdk/system/xul-app');
if (version < 29) var widget = require("sdk/widget").Widget({...});
else var button = require("sdk/ui/button/action")({...});
So, to be clear:
It doesn't matter which version of the SDK you use unless you want to use new modules.
No, you shouldn't make multiple versions of your add-on. If you want to use new modules for new browsers, follow the code example above.
It's true that you must use valid existing application versions but you generally don't need to repackage your addons, unless of course a change in the SDK directly affects your addons.
The reason for this is that by default the max target version is not going to be checked.
From the install manifest documentation:
strictCompatibility
A Boolean value indicating if the add-on should be enabled when the version of the application is greater than its max version. By default, the value of this property is false meaning that the compatibility checking will not be performed against the max version.
<em:strictCompatibility>true</em:strictCompatibility>
Usually, there is no need to restrict the compatibility: not all new releases will break your extension and, if it is hosted on AMO, you'll get notice several weeks in advance if a potential risk has been detected. Moreover, an extension being disabled, even for a short period, leads to a bad experience for the user. About the only time you should need to set this if your add-on does things that are likely to be broken by Firefox updates. You do not need to set this flag if your add-on has a binary component, since add-ons with binary components are always subject to strict compatibility checking (because binary components need to be rebuilt for every major application release anyway).
There is also is a recommendation for choosing version ranges.
minVersion and maxVersion should specify the range of versions of the application you have tested with. In particular you should never specify a maxVersion that is larger than the currently available version of the application since you do not know what API and UI changes are just around the corner. With compatibility updating it is not necessary to release a whole new version of the extension just to increase its maxVersion.
Technically you can use wildcards, but the documentation mentions several times that AMO verifies and possibly rejects addons with incorrect versions.