I am attempting to replicate what I see in PartyClickerSample in a fresh project, and am having difficulty with the pod and using it from Swift to set up the unit tests.
Based on PartyClickerSample, AFAICT, what I am supposed to do is put a Podfile like this in the iosTest/ directory (that contains a newly-created Xcode project):
platform :ios, '9.0'
target 'iosTest' do
use_frameworks!
pod 'testdoppllib', :path => '../app/build'
end
Then:
In AppDelegate.swift, import testdoppllib and call DopplRuntime.start() from the application() func
In ViewController.swift, import testdoppllib and call runResource() on... something that I can't quite figure out what it maps to
However, I can't even get to the latter bullet, as things start going sideways from the outset.
pod install seems to work as expected:
Analyzing dependencies
Fetching podspec for `testdoppllib` from `../app/build`
Downloading dependencies
Installing testdoppllib (0.1.0)
Generating Pods project
Integrating client project
[!] Please close any current Xcode sessions and use `iosTest.xcworkspace` for this project from now on.
Sending stats
Pod installation complete! There is 1 dependency from the Podfile and 1 total pod installed.
However, when I re-open the workspace:
In the Xcode tree thingy, Pods/Products/ shows testdoppillib.framework in red (which doesn't look good) and also shows Pods_iosTest.framework in black
If I try import testdoppillib, I get a message saying that Xcode does not recognize that name
If I try import Pods_iosTest, Xcode seems to find it, but then it does not recognize DopplRuntime.start()
So, what are the steps, in a Cocoapods-based Doppl setup, for starting the Doppl-created unit tests in Xcode?
Running pod install with set up the testdoppllib framework, but doesn't actually build it. One of the frustrating parts of the cocoapods process is you'll need to run build in Xcode, which should first build testdoppllib, then your Swift code.
To summarize, testdoppllib shows up as red, but it's most likely OK and just needs to be built. Once it's build, your Swift code should see "import testdoppllib"
For runResource, that's a little more complicated.
The Doppl gradle plugin writes a file called dopplTests.txt to the build/j2objcSrcGenTest directory. That's a listing of all the test classes. You need to add that file to Xcode, then pass in that name to DopplJunitTestHelper.runResource.
There's probably a way to set that up with cocoapods, but we haven't done that yet.
Related
I'm pretty new to the yocto project so bear with me if these are trivial problems.
I followed this(https://hub.mender.io/t/preparing-the-yocto-project-environment-from-scratch/801) tutorial and was able to compile a minimal yocto image, flash that image to a SD card and run it on a raspberrypi3.
My next goal is to add the azure device update layer(https://github.com/hiroyha1/meta-azure-device-update)
I cloned the repository to the sources directory and tried to add this layer via bitbake. Since LAYERSERIES_COMPAT was set to "warrior" this failed. I changed that variable to "kirkstone" and updated the syntax in all bb files, basically changing _append/_prepend to :append/:prepend.
Now when I try to run bitbake adu-image-base I get this error:
ERROR: No recipes in default available for:
$MYWORKDIR/sources/meta-azure-device-update/recipes-bsp/u-boot/u-boot-fw-utils_%.bbappend
I searched for this error and found out that sometimes there are "dangling appends". As I found out a fix for that could be to set "BB_DANGLINGAPPENDS_WARNONLY ?= "true"" in the layer.conf.
After running bitbake adu-base-image again the next error is:
ERROR: adu-base-image-1.0-r0 do_rootfs: Could not invoke dnf. [...]
No match for argument: adu-agent-service Error: Unable to find a
match: adu-agent
So I'm pretty stuck here. I think that the dangling appends are the reason for that error - the adu-agent-service isnt build so cannot be packed in the image, for me this makes sense since the root_fs is part of the OTA functionality. My approach would be to revert the "BB_DANGLINGAPPENDS_WARNONLY" change and get this layer to build properly, but I'm struggling to debug this further.
So how can I get this layer to work with the kirkstone release?
P.S if the proposed layer is utterly broken and there is no easy way to get this to work with the kirkstone release a hint would be great.
I have managed to build my angular app out as a dev build. I haven't done it as a production build yet as it gives me a few errors and i just need to test the dev build.
The dev build process goes fine, no errors or anything. I then use the files from the dist folder in a nginx docker container to host the files.
The problem is nothing is displayed but a white page and in the console i get an error saying 'Uncaught TypeError: Cannot read property 'id' of undefined'. The full message below doesn't seem to point to anything i have written and i've spent several hours searching online but can't find anything on this problem.
I've tried a few different things such as running 'npx ivy-ngcc' which i read manually compiles some stuff. Is there anyway i can get more details on the error to see if it's something i have done?
UPDATE
So i have restored the line that i commented out in main.ts as mentioned in the comments below. I have also tried 'ng build --aot' as suggested which presents me with a series of errors that all seem to relate to devextreme components that are used. I find this strange as i started the project with the devextreme angular starter project from github.
i get messages such as:
'dx-scroll-view is not a valid HTML element'
'node_modules/devextreme-angular/ui/drawer.d.ts - error: appears in
the NgModule.imports of SideNavOuterToolbarModule, but could not be resolved to an NgModule class'
If you go in the devtools and click on Sources, "Don't pause on exceptions" and check "Pause on caught expecptions" and continue until you get the "id error" you will find what module the error is thrown. In my case was a third party library called 'ngx-card/ngx-card' and it's module was the cause of the error (CardModule). Hope this will help find at least the cause of the error
I managed to solve the problem by disabling ivy in the angular compilation options. As soon as i did that it worked building both dev and production versions and is now working perfectly within Nginx.
Thanks to everyone who offered help :)
In tsconfig.json of your Angular project, put this to disable Ivy, the new Angular template engine
{
...
"angularCompilerOptions": {
"enableIvy": false
}
}
Typically, if it's not something that you've written, it tends to be an issue w/ your implementation - i.e. "Visiting a food vendor and ordering a food item they don't provide".
I know it's not a specific answer, but ensuring that you have appropriately configured things in your app.module would be a good first step. Perhaps attempting to build w/ AOT will also give you some more verbose failures that stem from attempting to build out.
Hopefully this helps another poor soul.
To anyone using devextreme, make sure you update your version to at least 19.2.5
https://github.com/DevExpress/devextreme-angular/issues/975#issuecomment-580172291
Starting with version 19.2.5 we support the IVY compiler.
I had the same issue and fixed it by changing from
loadChildren: './app/page/account/account.module#AccountModule'
to
loadChildren: () =>
import('./app/page/account/account.module').then(
(m) => m.AccountModule
)
in app-router.module.ts
The root cause of your error is very likely to be a module that you needed to load explicitly but didn't, or a circular reference in your own modules. Rodrigo has a good answer but to be more specific, you need to find the registerNgModuleType function in Angular's core.js and set a conditional breakpoint on the first line. The condition should be !ngModuleType || !ngModuleType.ɵmod. (You can set a conditional breakpoint in most modern browsers by right-clicking the line number.)
Once you've paused execution just before the exception happens, you can look at the value of ngModuleType if it's not undefined, or walk up a frame or two in the scope and see what the value of imports was.
For me, this issue occurred while using Storybook.
The reason it happened was because of the way I was precompiling the node modules. I was doing:
Incorrect
ngcc --properties es2015 browser module main --first-only
Correct
ngcc
Using this approach fixed it
I've been trying for hours, but can't build and use Light Table. Every time I try to run deploy/LightTable, it hangs on a screen that simply says "Light Table". I receive this error*:
[14381:0519/204037:INFO:CONSOLE(27860)] "Uncaught TypeError: Cannot read property 'thread_STAR_' of undefined", source: file:///home/zaz/Desktop/LightTable/builds/lighttable-0.8.0-linux/resources/app/core/node_modules/lighttable/bootstrap.js (27860)
Here's what I've tried:
git clone https://github.com/LightTable/LightTable.git
cd LightTable
bash linux_deps.sh
./deploy/LightTable # creates frozen window, throws the error above
cd deploy
./LightTable # creates frozen window, throws the error above
./ltbin # creates frozen window, throws the error above
I also tried similar things after checking out the atom-shell branch and the 0.7.2 tag (and cleaning up all the files from the previous build). Each time, I received the error above.
Does anyone know what's going on here?
Has Light Table been completely abandoned? It seems the last commit was in March.
* Depending on the version I was trying to run, I also received other errors, but I don't think they're relevant (the error above was the only one that appeared for all versions):
[18593:0519/222845:INFO:gpu_info_collector_x11.cc(80)] NVCtrl extension does not exist.
[18593:0519/222845:ERROR:browser_main_loop.cc(226)] Gdk: gdk_window_set_icon_list: icons too large
Fontconfig warning: FcPattern object size does not accept value 11(i)
[14413:0519/204035:INFO:renderer_main.cc(212)] Renderer process started
A year later (question was written in May 2015, now is June 2016), LightTable 0.8.1 is out, and I tried both Linux binary and cloned it from git, and it works fine.
For complete info, I'm using also Atom, and although I had not problems with "Cannot read property 'something' of undefined"" in Atom core, I met such problems in two or three Atom packages.
Both editors are based on same electron platform, LightTable is beautiful eye candy with quite revolutionary REPL integration, but it needs more polish to be usable to same extent as Atom.
For example, LightTable does not have workspace saving by default, that is done via plugin. That's ridiculous.
But although Atom looks so nice and powerful compared to simple editors, with realy huuuge number of available packages/plugins, LightTable is more elegant.
As I don't want to start new semi-religious war Atom vs LightTable resembling vi-vs-emacs, I'll stop here. :)
I can't replicate your problems in LightTable v0.8.1, so I think that answers this question. If not, please add errors you get with v0.8.1.
For info about releases, please check: https://github.com/LightTable/LightTable/releases
I have installed RedHawk 1.10.0 using Ubuntu 14.0.4LTS as described in appendix F of the RedHawk documentation. I also installed standalone IDE from SourceForge
again, as specified in appendix F, chapter 2.5. The IDE comes up looking ok, but here are the problems:
The components list is empty (there are supposed to be a set of pre-defined components). The directory is empty as well on the file system.
When attempting to generate C++ component, I get:
"Exception running "/bin/redhawk-codegen" /bin/redhawk-codegen - template=redhawk.codegen.jinja.cpp.component.pull --checkSupport
In detail, it said: bin/redhawk-codegen":error=2 no such file or directory. The /bin/redhawk-codegen is there under OSSIEHOME. The "pull" template is under: /usr/local/lib/python2.7/dist-packages/redhawk/codegen/jinja/cpp/component.
If I attempt to start Domain Manager I get an error "no domain configuration available".
So for all these problems it is obvious that I need to get a better picture of the expected file layout of all IDE and core RedHawk components. This is not clear from the documentation. Is there a starting point where I can begin debugging "where to find things"?
Regarding your first issue:
When installing for CentOS using the RPMs, a number of components, and devices are pre-packaged into the yum repository. When installing from source, as one must do for Ubuntu in 1.10, the pieces of Redhawk are modular and are installed individually.
The directions from Appendix F walk the user through installing each of the parts that make up the framework. The core, a GPP, bulkio, bustio, and the code generator. This does not include any components or devices (other than the GPP). To install these, you'll need to clone them from their respective git repositories and build and install from source either from the command line, or through the REDHAWK IDE. Building and installing the components from the command line follows the same pattern as the framework, there is a reconf script, which creates the configure script which creates the makefile script. eg. ./reconf; ./configure; make; sudo make install
Regarding your second issue:
These symptoms seem to point to the OSSIEHOME and SDRROOT variables not being set. Make sure that the OSSIEHOME and SDRROOT variables are set in the terminal using "echo $SDRROOT" and "echo $OSSIEHOME" prior to running the IDE. Keep in mind that the environments are unique to each session so, for example, having them set in one bash terminal does not guarantee they are set when launching the IDE from a desktop shortcut. Confirm they are set in your terminal, then launch the IDE from the same terminal.
Regarding your last issue:
This is likely also caused by your second issue. However, if it is not resolved following the above steps, take a look within $SDRROOT/dom/domain There should be two files. One DomainManager.dmd.xml.template and one DomainManager.dmd.xml. If all you have is the template then you need to create the DomainManager.dmd.xml file by copying the template. Then edit it and fill in the id and name fields. The default name is generally REDHAWK_DEV and the id should be a UUID.
I have an app that has been running fine on the iPhone simulator for some time. Recently, I decided I wanted to re-use the data model and related classes in another project - so I dragged them from this project window to the other then told Xcode not to copy, just to make references. At first this didn't work so I jumped through a number of hoops to try to fix it (I may be asking more about that in another post). After all this, I re-compiled and tried to run the original app -- and it's not working any more. On further investigation, I discovered that when I re-compile the original app, I end up with a bundle that contains a .momd package but it contains only a Versioninfo.plist file - no .mom file, no .omo file like I'm expecting to see. I don't recall making any changes to the original app. I don't get any warnings. I just get an incomplete .momd package (and, not surprisingly, my app now crashes).
What's going on here?
BTW, the app now crashes with this message:
Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '* -[__NSArrayM insertObject:atIndex:]: object cannot be nil'
Which I get when executing this line of code:
self.productRegistry = [[UIManagedDocument alloc] initWithFileURL:self.productRegistryURL];
I figured this out by looking more closely at the file locations in the project directory using Finder. In the Xcode window, everything looks normal but in the actual project directory I found that the .datamodeld package had ended up at the top level of the project directory -- at the same level as the project package itself. Xcode apparently did not like this but unfortunately it did not complain -- it just created a partial build output. Once I moved the .datamodeld package into the same folder as the rest of the project's code, everything worked just fine.
This would appear to be just a quirk. I would expect that Xcode would either see that all is well and build correctly OR it would see that things weren't quite as they should be and fail. In this case, it did not build correctly but was silent about it.
Hope this answer helps someone else someday.