I have developed a TideSDK application and am now ready to package it, but I'm having problems with the network type installer.
It always gives me code 404 on the Application first run:
Could not query info: Invalid HTTP Status Code (404)
I presume the installer is having difficulty with reaching the correct servers and downloading the needed runtime, but I have run through most solutions on this forum, and none have worked.
So I tried a bundle packaging, as it should include such runtime, but I must be doing something wrong, since it does not bundle within the MSI.
The code I'm executing is as follows:
C:\TideSDK\sdk\win32\1.2.0.RC6d\tibuild.py -p --type=BUNDLE --os=win32 "C:\path_to_app\app_dir"
I also tried:
C:\TideSDK\sdk\win32\1.2.0.RC6d\tibuild.py -p -t bundle --os=win32 "C:\path_to_app\app_dir"
And all the uppercase/lowercase combinations. Also tried version 1.2.0.4, without sucess. Am I doing something wrong?
the network type installer is not available anymore, since appcelerator has canceled their services for titanium desktop.
So you can only do bundle packaging. Try the following command:
python tibuild.py --dest=. --type=bundle --package=. "c:\path\to\your\app\dir"
This should build and package your app and create a installer for it.
Change "dest" and "package" to the directories where you want to have the built app and installation package.
You can omit the OS parameter, since the builder can only generate builds for the current OS.
Related
If want to run dotnet-trace on Linux, against an application that ships with its own .NET Core runtime. When I run it, however, I get:
A fatal error occurred. The required library libhostfxr.so could not be found.
If this is a self-contained application, that library should exist in [/home/user/.net/dotnet-trace/RMBGJOBRwpkX5Kvpq_FShF5s1UmJMO8=/].
If this is a framework-dependent application, install the runtime in the global location [/usr/share/dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [/etc/dotnet/install_location].
I located the libhostfxr.so library at /home/user/app/libhostfxr.so, then executed DOTNET_ROOT=/home/user/app/ dotnet-trace, but got the same error.
How do I go from the path of this library to the correct setting for DOTNET_ROOT?
According to strace, it is looking for the file /home/user/app/host/fxr which does not exist.
I ended up installing the .NET version that matched the application I was trying to debug using the install script. (I found this by using strings libhostfxr.so; perhaps there's a better way.)
A little confusingly, the runtime version 3.1.28 is not the same as the corresponding SDK version 3.1.422, which I installed with:
$ wget -O - https://dot.net/v1/dotnet-install.sh | bash /dev/stdin --version 3.1.422
It can also be downloaded from versionsof.net which is not an official site, but it links to the files hosted by Microsoft.
This process installed /home/user/.dotnet/host/fxr/3.1.28/libhostfxr.so and I could then run DOTNET_ROOT=/home/user/.dotnet/ dotnet-trace.
I am trying to run a simple GRPC client-server code in raspberri Pi running Raspbian os.
Language that i am using -C# dotnet core (2.1)
I downloaded a sample project from here.
This is a dotnet core project . I am able to run it in Windows environment, i am also able to modify .proto file in this code and run successfully.
I published the solution as it is with command
{ dotnet publish -r linux-arm }
When tried running same on Rpi, i am getting exception. Attached screenshot has the details of it.
Any help to get through this would be of great use
tl;dr The problem is the libgrpc_csharp_ext native library which currently does not get compiled and built for the arm7 processor. I've compiled it (on a pi) for arm7 and released a nuget package to bridge the gap until they support it all the way: https://www.nuget.org/packages/libgrpc_csharp_ext.arm7/
I'll update with a link to a blog post when I finish getting the rest of the tooling and template finished I'm working on.
fuller explanation: the Grpc.Core nuget package contains the native libgrpc_csharp_ext library that the dotnet implementation of grpc loads in NativeExtensions.cs then maps with PInvoke in NativeMethods.Generated.cs. Inspecting that package, you'll see a version of that library in each /runtimes/[win, osx, linux]/native folder. Unfortunately, no linux-arm version of the library is included. However, in the code, if the platform is linux, it will try to load the static library using the name as formatted here. Dissect that a little and you'll see that as of right now, any 'linux' platform that isn't '64bit' (which despite the proc on the pi being 64 bit, the distro of linux you're using on there, including raspbian, likely isn't) will look for libgrpc_csharp_ext.x86.so. When you dotnet publish -r linux-arm, you'll see that library there in the build output, but unfortunately, it's the wrong one (I think publish just grabs 'the closest one' when it can't find a specific library in the runtimes folder).
The nuget package I created above is compiled for arm7 - I actually cloned the grpc repo onto a pi and peeled away enough of the /csharp build to just cmake the libgrpc_csharp_ext. The 'trick' the package uses is to put the library in runtimes/linux-arm/native folder within the package, which dotnet core recognizes when publishing and pulls into the build output - but the library is still named libgrpc_csharp_ext.x86.so because of the way NativeMethods.cs formats the library name.
I'm using JBDS 11.3.0.GA on Ubuntu 16.04 LTS. I'm generating a Fuse project for Fuse 7.1.0 on standalone Karaf platform, using the camel-spring-cxf-code-first template. The project generates correctly but, trying to run it as described by the ReadMe.txt file fails. For example, after installing the bundle as follows:
karaf#root()> install -s mvn:com.mycompany/camel-spring-cxf-code-first/1.0.0-SNAPSHOT
Bundle ID: 223
karaf#root()>
trying to go to http://localhost:8181/cxf/report/?wsdl (of course, after having replaced in the generated code 9292 by 8181) displays "No service was found." in the browser and shows the following in the log file:
16:33:36.209 WARN [XNIO-4 task-1] Can't find the the request for http://localhost:8181/cxf/report/'s Observe
meaning that the generated project is not valid.
Kind regards,
Nicolas
The deployment of this kind of projects is not working at the moment - see the following statement in the Readme.txt file.
Note: This project does not currently work. It has some issues. It is based
on the archetype.
I raised an issue for developers - https://issues.jboss.org/browse/FUSETOOLS-3177.
I followed the installation guide at https://www.cloudcontrol.com/dev-center/Add-on%20Documentation/Data%20Storage/MemCachier. The memcachier server is up and running, I tested it from the command line. But my cloudcontrol app isn't able to access it.
Here's the error in our logs:
Info MemcachedError: error 40 from memcached_set: FAILED TO SEND AUTHENTICATION TO SERVER, no mechanism available, host: [my-memcachier-server-url]:11211 -> libmemcached/sasl.cc:221
Notice No worthy mechs found
This seems to be a SASL-related issue. Is it possible that cctrl does not have the correct sasl2 libraries installed? Did anyone else experience this problem?
Further info:
django-pylibmc==0.5.0 and pylibmc==1.4.1 in requirements.txt
url and credentials are read from the cctrl environment correctly
This is caused by the libmemched version bundled with the buildpack missing a patch (https://bugs.launchpad.net/libmemcached/+bug/1381160). Because it is a stackoverflow bug, it can work systematically on your machine while it systematically breaks in the container. I will update the python buildpack to use the patched libmemcached library from the stack.
In the meantime you can try to achieve this manually by setting the LD_LIBRARY_PATH environment variable to /usr/local/lib either via config add-on or web: env LD_LIBRARY_PATH=/usr/local/lib <your_command> in the Procfile.
I posted this on the Kobold2d forums but haven't received any replies yet. I'm hoping the larger audience here at SO can help.
I'm trying to get our Kobold2d project working with our Hudson CI server. I'd like to have a script that executes the proper command line build instructions using xcodebuild, but I'm running into a problem with any Kobold2d project.
As a test I created a Orthogonal-Tilemap template project and built/ran it in the xcode 4.4.1 gui successfully. Building the projects individually from the command line the Kobold2D-Libraries.xcodeproj reports a successful build (though I have no idea where any products are stored), but the tilemap project fails with the message:
ld: file not found: <path>/Kobold2D/Kobold2D-2.0.3/BuildTest/build/Release-iphoneos/libkobold2d-ios.a
The only information I can find on this message talks about errors from building in the xcode gui, which is not the problem.
I also tried having xcodebuild build the workspace file but that failed with multiple dependency errors.
Has anyone found a way to successfully build Kobold2d projects from the command line?
Thanks!
Actually I use Hudson to automate Kobold2D builds. Here's the build script for Hudson.
I can see from your path that you changed Xcode's default build locations (Advanced, next to Derived Data in Preferences -> Locations). There's one setting (legacy) that doesn't work at all with Kobold2D, and should actually open a browser window explaining the issue should you have used that setting.
I think your setting is "relative to project" or something similar. Try changing the build location to Xcode default (Unique) and try again. You can use a custom location for derived data if you want to.
In any case, if the output location path of build products ends up being somewhere in the app project folder (in this case: BuildTest) then ld won't be able to find dependencies because they're not all in the same folder. If you do require this you could add a pre-link step that copies the .a files to the correct location. But it's best to avoid this because it'll be prone to breaking.
My script includes
xcodebuild -workspace Bulge.xcworkspace -scheme Bulge-iOS -sdk ${sdk} archive || die "Archive failed"