Swift and terminal: Using Google Endpoints in an iOS Client - terminal

I am following the tutorial at
https://cloud.google.com/appengine/docs/java/endpoints/calling-from-ios
and when I get to step 5 and Open a new Terminal window to invoke ServiceGenerator. I get the error message in my terminal saying..
Barrys-MacBook-Pro:~ barrymadej$ /Users/barrymadej/Library/Developer/Xcode/DerivedData/ServiceGenerator-avaeguyitgyhxpcnaejpgzvxezei/Build/Products/Debug/ServiceGenerator \
/Users/barrymadej/Documents/AndroidStudioProjects/StudentProgressTrackerDatabaseAndCloud/backend/build/discovery-docs/myApi-v2-rpc.discovery /
ERROR: An output directory is required.
Usage: ServiceGenerator [FLAGS] [ARGS]
Required Flags:
--outputDir PATH
The destination directory for writing the generated files.
Optional Flags:
--discoveryService URL
Instead of discovery's default URL, use the specified URL as the
location to send the JSON-RPC requests. This is useful for running
against a custom or prerelease server.
--gtlFrameworkName NAME
Will generate sources that include GTL's headers as if they are in a
framework with the given name. If you are using GTL via CocoaPods,
you'll likely want to pass "GoogleAPIClient" as the value for this.
--apiLogDir DIR
Write out a file into DIR for each JSON API description processed. These
can be useful for reporting bugs if generation fails with an error.
--httpLogDir PATH
Turn on the HTTP fetcher logging and set it to write to PATH. This can
be useful for diagnosing errors on discovery fetches.
--generatePreferred
Causes the list of services to be collected, and all preferred services
to be generated.
--httpHeader NAME:VALUE
Causes the given NAME/VALUE pair to be added as an HTTP header on *all*
HTTP requests made by the generator. Can be used repeatedly to provide
additional header pairs.
--formattedName SERVICE:VERSION=NAME
Causes the given SERVICE:VERSION pair to override its service name in
files, classes, etc. with NAME. If :VERSION is omitted the override is
for any version of the service. Can be used repeatedly to provide
several maps when generating a few things in a single run.
--addServiceNameDir yes|no Default: no
Causes the generator to add a directory with the service name in the
outputDir for the files. This is useful for generating multiple
services.
--generatedDir yes|no Default: no
Causes a directory in outputDir called "Generated" to be created and
used to contain the generated files.
--removeUnknownFiles yes|no Default: no
By default, the generator will report unknown files in the output
directory, as commonly happens when classes go away in a new API
version. This option causes the generator to also remove the unknown
files.
--rootURLOverrides yes|no Default: yes
Causes any API root URL for a Google sandbox server to be replaced with
the googleapis.com root instead.
--verbose
Generate more verbose output. Can be used more than once.
Arguments:
Multiple arguments can be given on the command line.
service:version
The description of the given [service]/[version] pair is fetched and the
files for it are generated. When using --generatePreferred version can
be '-' to skip generating the name service.
http[s]://url/to/rpc_description_json
A URL to download containing the description of a service to generate.
path/to/rpc_description.json
The path to a text file containing the description of a service to
generate.
ServiceGenerator path:
/Users/barrymadej/Library/Developer/Xcode/DerivedData/ServiceGenerator-avaeguyitgyhxpcnaejpgzvxezei/Build/Products/Debug/ServiceGenerator
ERROR: There was one or more errors; check the full output for details.
Barrys-MacBook-Pro:~ barrymadej$ --outputDir
-bash: --outputDir: command not found
Barrys-MacBook-Pro:~ barrymadej$ /Users/barrymadej/Documents/AndroidStudioProjects/StudentProgressTrackerDatabaseAndCloud/API

You should generate a REST discovery document and use the new Objective C client instead. The client library you're trying to use is deprecated anyway. It looks like it didn't work because you specified the flag without the rest of the command, though.

Related

Argument list too long: recursive header expansion failed at react-native-google-cast

I have a problem with building a app in Xcode. When i try to build the app it gives the following error.
Argument list too long: recursive header expansion failed at /Users/******/Documents/******/******/app/native-app/node_modules/react-native-google-cast/ios/../../../ios/build/Build/Intermediates/RNIap.build/Debug-iphonesimulator.
Checkt the repo but no solution found. Who can help me with this so i can build the app.
Info:
RN version: 0.52.0
react-native-google-cast: 2.10.4.1
Xcode: 9.4.1
Thanks,
Yarno
I ran into a similar issue and had to go in and remove a few header search paths, as described here:
https://facebook.github.io/react-native/docs/0.60/troubleshooting#argument-list-too-long-recursive-header-expansion-failed
Argument list too long: recursive header expansion failed
In the
project's build settings, User Search Header Paths and Header Search
Paths are two configs that specify where Xcode should look for #import
header files specified in the code. For Pods, CocoaPods uses a default
array of specific folders to look in. Verify that this particular
config is not overwritten, and that none of the folders configured are
too large. If one of the folders is a large folder, Xcode will attempt
to recursively search the entire directory and throw above error at
some point.
To revert the User Search Header Paths and Header Search Paths build
settings to their defaults set by CocoaPods - select the entry in the
Build Settings panel, and hit delete. It will remove the custom
override and return to the CocoaPod defaults.
(Also cross-posted on this similar issue: Argument list too long: recursive header expansion failed)
Even I faced the same issue in Xcode 10.1, just move your code folder location from desktop, document etc to home folder.

How do I initialize a new database-path defined in stack.yaml

The sample Docker configuration section of stack.yaml gives:
# Location of database used to track image usage, which `stack docker cleanup`
# uses to determine which images should be kept. On shared systems, it may
# be useful to override this in the global configuration file so that
# all users share a single database.
database-path: "~/.stack/docker.db"
However when I put this in the stack.yaml for a new project and stack setup I get:
Aeson exception:
Error in $.docker['database-path']: failed to parse field 'docker': failed to parse field 'database-path': InvalidAbsFile "~/.stack/docker.db"
See http://docs.haskellstack.org/en/stable/yaml_configuration/
This is the only reference I could find to database-path, without digging in to the code.
Is database-path required?
If so: How do I initialize a .db file (to mitigate InvalidAbsFile "~/.stack/docker.db")?
It is not a matter of initialization of the database. The problem is that it does not expand the ~, so you need to use /home/dukedave/.stack/docker.db

i18n dart library for translation won't run

Hello i run the command
pub run intl:extract_to_arb --output-dir=target/directory
But i take this error message:
Package "intl" is not an immediate dependency.
Cannot run executables in transitive dependencies.
i follow this site https://www.dartdocs.org/documentation/intl/0.11.9/index.html and i use api 1.15.1
There is another way to do that?
Finally i have a solution:
pub run intl:extract_to_arb --output-dir="/Volumes/Case Sensitive Part/Projects/MyProjectFolder/" web/dart/**/*.dart
This generate a file intl_messages.arb (a Json for the translator).
From the translator you can receive some file like this
intl_messages_fr.arb
intl_messages_de.arb
intl_messages_{locale}.arb to generalize.
After this:
pub run intl:generate_from_arb --generated-file-prefix=notneeded web/dart/**/*.dart ./intl_messages_fr.arb ./intl_messages_de.arb ./intl_messages_{locale}.arb
This generate a class dart named: "messages_all.dart" and dart class named "messages_messages_de.dart", "messages_messages_fr.dart", "messages_messages_{locale}.dart".
Only one problem left. I receive some info from last command generate_from_arb:
No ##locale or _locale field found in intl_messages_it, assuming 'messages_it' based on the file name.
No ##locale or _locale field found in intl_messages_de, assuming 'messages_de' based on the file name.
I thing that i should put this tag ##locale (##it) inside the translation arb files.

Front end and back end not compatible - get more linker information

while building a project in VisualStudio 2012 I get the error message
LINK : fatal error C1905: Front end and back end not compatible (must target same processor).
Checking the project manually does not help, all involved (static) libraries have been built for the same processor. I also added
/VERBOSE:lib and /VERBOSE
to command line to get some more information but this does not help, only additional output line I got by this was a stupid
Starting pass 1
So: any ideas how I can find out what causes this strange error message? How can I get more output from the linker?
Thanks!
Old question and I'm not sure whether anyone still need an answer. I had this problem with Visual Studio 2017.
Check paths for generated .obj files, especially when you use some .cpp files in more than one project (within solution) and/or use %(RelativeDir) variable in Properties -> C/C++ -> Output Files -> Object File Name. It happened to me with this path in Object File Name '$(IntDir)\%(RelativeDir)' and this $(ProjectDir)Junk\$(Platform)\ in Intermediate Directory. Error gone when I moved $(Platform) part to Object File Name.
Old paths:
Intermediate Directory: $(ProjectDir)Junk\$(Platform)\.
Object File Name: $(IntDir)\%(RelativeDir).
New paths:
Intermediate Directory: $(ProjectDir)Junk\.
Object File Name: $(IntDir)$(Platform)\%(RelativeDir).
You can also specify Object File Name option for each file, shared between multiple projects to keep using old path (or if new paths configuration isn't working for you) and get rid of that error.

Perl::WSDL. Generated methods in different directory than script

I am trying to write a script for using with op5/nagios.
What it tries to do is to connect to database an get a value there, and then send a request to a webservice and match the response from the webservice with the value from the database.
Now writing the script wasn't the problem. The problem arrises when trying to run it from OP5.
When including the interface to script I use the following syntax
use MyInterfaces::PortalServicesImplService::PortalServicesImplPort;
This works just fine when I execute the script located on the same level as "MyInterfaces".
The problem is that the script itself is located in the folder /opt/plugins/custom/SOAP where both the script and the folders generated by wsdl2perl.pl is located. However when OP5 executes the script is does so from the folder /opt/monitor.
So I tried to include the "PortalServicesImplPort" using this syntax
use lib "/opt/plugins/custom/SOAP/MyInterfaces/PortalservicesImplServices/PortalServicesImplPort
The code compiles but when trying to run it I get an error message saying
Can't locate object method "new" via package "MyInterfaces::PortalServicesImplService::PortalServicesImplPort" (perhaps you forgot to load "MyInterfaces::PortalServicesImplService::PortalServicesImplPort"?)
Am I doing something wrong when importing methods from another location or doesn't SOAP::WSDL support placing the auto generated files in a different directory from where you are executing the script?
Seems I managed to solve this myself by adding use lib "/opt/plugins/custom/SOAP

Resources