QnAMaker based chat bot can deployed to MS Teams 2.0.8 with multi-turn feature, however the new version 2.0.10 on iPad can't support that. Anyone encountered such issue pls? how to fix? It's frustrated if the higher version is not compatible.
Related
Can ios apps be compiled on the new M1 chipset?
Is there any schedule for official support?
The short answer is yes.
The latest version of XCode (version 12) is compiled as a universal app. This means that it runs on both Intel-based and Mac Sillicon machines natively. From Apple's website:
Xcode 12 is built as a Universal app that runs 100% natively on Intel-based CPUs and Apple Silicon for great performance and a snappy interface.* It also includes a unified macOS SDK that includes all the frameworks, compilers, debuggers, and other tools you need to build apps that run natively on Apple Silicon and the Intel x86_64 CPU.
This means that you should be able to compile iOS with the latest version of XCode without a problem. It would be kind of crazy for Apple to release professional hardware (MacBook Pro) without this capability.
Keep in mind that a number of third party applications may not work well on the ARM machines yet. VSCode is not currently supported on M1 devices (although Microsoft have said that it's coming). VSCode is an Electron based app which currently can't be emulated with Apple's Rosetta II platform. You might not use VSCode, but keep in mind that any Electron based apps that you use may not work straight away.
If you exclusively use XCode and don't critically rely on any third-party apps you should be ok.
EDIT: I just noticed that you tagged your post for react-native. Information is pretty slim for compatibility at the moment, so I would be cautious. If you need a Macbook Pro to do commercial work or school projects right now then you run the risk of things not working as intended. The M1 MacBooks will undoubtedly support everything that you need as a developer in the future and they're particularly great candidates for iOS development because of the parallels made possible by the shared ARM architecture.
If you're relying on a new machine to get work done right now, going with an Intel-based machine is probably the best option. For reference, I recently got an Intel-based 16" MacBook Pro with work because I need to get things done right now without any issues. The commercial value far outweighs the potential benefits that an M1 machine might bring in a year or two. If you're ok with running into some issues over the next few months, I'm sure that the M1 machines will provide plenty of value for years ahead.
While there are problems that do not allow compiling the application.
brew and cocoapods are installed in the console with rosetta enabled.
pod install / update fails because flipper and some parts of RN are not supported by the platform
if you use expo - without cli then everything is ok
updates: now cli working (after update all - homebrew, cocoapods and other to last version)
from what I know, iOS app only compiles on Mac os, so it should work with whatever macOS uses.
There are multiple versions of IBM mobilefirst platform available. What are the different decision points that need to be considered for choosing a particular IBM mobilefirst version for implementation?
There are only two versions that should be considered at this time: 7.1 and 8.0, and the only reason to choose 7.1 is if you've already invested in a version older than 7.1. The reason I say that is because V8.0 is rearchitected in a number of significant ways that make it more suitable for Cloud deployments and Open development models. Therefore, the cost to migrate from an older version to V8 is somewhat greater than to migrate to 7.1, and 7.1 will continue to support all the latest mobile operating systems. V8 on the other hand has many new features that 7.1 will never have (as you'd expect) If you're looking to play with the technology, go download the free DevKit from https://mobilefirstplatform.ibmcloud.com/.
So bottom line: If this is a new deployment/purchase/etc. then I'd always suggest V8 as the preferred choice. However if you already have an investment in older versions, V8 is still the preferred choice, but migration to V8 may take more time than to migrate to 7.1.
Does that answer your question?
Mobilefirst 7 or 7.1 will be most reliable as of now since it has been in the market for some time and most of the pmr's would already be resolved. Within 7 and 7.1 itself there are few changes like 7 has desktop browser environment which is not present in 7.1. So you would want to check out the differences before chosing 7 or 7.1. But personally I would recommend you to go for mfp8 since there are lots of new features added into it. It might be a bit unstable but eventually everyone would upgrade to 8 is what I feel.
I recently installed the AC6 System Workbench in order
to work with the STM32 OSXMotionFX Library
and I'm experiencing some troubles related
to the sample application shipped with this library.
Let me know if there is a better place to post such question.
It seems that the sample project works with a different
version of the STM32 Cube expansion drivers for the
X-Nucleo-IKS01A1 expansion board of the base
STM32 Nucleo-F401RE board I have.
In particular the sample project links to driver files
that are missing, some of them seem with different names
compared to the existing ones, that's why I guess
the sample project is referring to an old version of the drivers.
Any one does know how to get the previous versions of the
STM32CubeExpansion_MEMS1_V1.4.0 software ?
I did already search the ST Microelectronics web site
but to no avail, the X-CUBE-MEM1 software
is only shipped at version 2.0.0
and it seems I need the previous version.
Thanks in advance for redirecting me to the correct site in case.
You can download the sample application in the software package osxMotionFX v1.4.0. It is aligned to the new version of the X-CUBE-MEMS1 drivers (v2.0.0). Unfortunately osxMotionFX v1.3.0 is not compatible with the new version of the X-CUBE-MEMS1 drivers.
You mean that osxMotionFX v1.4.0 does not work with X-CUBE-MEMS1 v2.0.0? It is very strange. I'm able to use them without any issue. So probably, you are using osxMotionFX v1.4.0 with an old version of X-CUBE-MEMS1 package. Try to uninstall your current osxMotionFX package, download again the X-CUBE-MEMS1 package v2.0.0 and reinstall the osxMotionFX v1.4.0 over the new X-CUBE-MEMS1 package v2.0.0. Let me know if it fixes your issue.
I use sample application of osxMotionFX v1.4.0 with X-CUBE-MEMS1 v2.0.0. I'm sure that you are not using X-CUBE-MEMS1 v2.0.0 because "x_nucleo_iks01a1_accelero.h" and "x_nucleo_iks01a1_gyro.h" are only defined in X-CUBE-MEMS1 v2.0.0 and not in the previous version of the package. You can also cross-check it looking at the installation folder that you are using for osxMotionFX; if it is not "STM32CubeExpansion_MEMS1_V2.0.0", then you are using a previous version of X-CUBE-MEMS1. Please, try to download again X-CUBE-MEMS1 software package.
We are using Worklight enterprise 6.2 with fix packs and we are planning to upgrade to 6.3 in the next month (beginning of May 2015). However, we see now that IBM is about to release MFP 7.
Can you please clarify to me those queries:
What is the impact on the project which has been developed on version 6.2 to be moved to 6.3 or 7?
What is the recommendation for us in terms of upgrading, should we go immediately to WL7 or to 6.3 first?
We are very close to the production and our concern that the WL7 "might" be unstable or contains issues that we might face in a critical time."Feedback would be appreciated"
MobileFirst Platform Foundation 7.0 is not about to be released - it is already released.
Lots of changes in both 6.3 and 7.0. Read the documentation to see what's changed...
6.3: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_6.3.0/com.ibm.worklight.getstart.doc/start/c_release_notes.html
7.0: http://www-01.ibm.com/support/knowledgecenter/SSHS8R_7.0.0/com.ibm.worklight.getstart.doc/start/c_release_notes.html
In terms of your project structure, starting 6.3 the adapter thread pool has been removed and you are now in complete control of it. Your adapter XML will be upgraded to the new structure.
In terms of technology, starting 7.0 there is REST support together with a new authentication mechanism - OAuth. Classic authentication is as before and is still there. There are also now Java adapters in addition to JavaScript adapters, and lots more.
7.0 is indeed new, but provides you with a lot of new possibilities.
6.3 is very stable (that is not to say that 7.0 is not stable, but it's also very new).
We cannot decide for you if to upgrade or not, it sounds like you are already considering the right things to consider.
Read about the two releases.
I am using the Kinect for Xbox and I am planning on using the OpenNI framework along with the Point Cloud Library for processing but I am having trouble getting OpenNI to recognize my Kinect for Xbox and I wanted to make sure that it is actually compatible with the device.
For some reason I haven't been able to find any documentation on this exact topic.
PCL does indeed work with OpenNI. I've managed to easily compile the OpenNI Grabber Sample on Windows (using the All In One installer). I must admit I haven't managed the same on osx (had some issues with various versions of VTK being installed on the machine).
By the looks of it the issue doesn't look like it's on the PCL side, but on the OpenNI driver side. Can you run any of the samples ? If not, what error messages are you getting ?
I recommend cleaning up (uninstalling OpenNI, NITE, SensorKinect) and installing the unstable versions, but try installing in this order:
OpenNI 1.5.4.0
Nite 1.5.2.21
Avin's SensorKinect
Which version of OpenNI that you use?
If you use version 1.5.4, I think there is no problem because OpenNI interact directly with your Kinect Xbox.
However, if you use OpenNI version 2.x, it will interact with your device via Kinect SDK (http://social.msdn.microsoft.com/Forums/en-US/kinectsdk/thread/a11ff6d9-7fbe-4636-8ff0-92d6220ac3f8/) Since there is no Kinect SDK on linux, you can't make OpenNI 2 to recognize your device.