I'd like to use Pyro.Naming.NameServerStarter.start() but I can't find any documentation, and it is better than 'pyro-ns'.
I also don't know why y can't retrieve Pyro4 module since I've just updated Pyro modules. Only Pyro module is reacheable, so I can't even try Pyro4.naming.startNS()
Sounds like you're stuck with the old, unmaintained, version 3 of Pyro. Upgrade your library to Pyro4 first.
The shell command pyro4-ns is just that; it starts a name server from the shell. Using the API to do it is a different thing because then it is your own code that starts it.
Documentation on how to do that is available here: http://pythonhosted.org/Pyro4/nameserver.html#starting-the-name-server-from-within-your-own-code
Related
With some community support I recently learned how much faster Values.Get() is versus getValues(). I've been upgrading one of my projects code to use these new commands. As I go through and try to change over all of my read/write commands I've found that I use .getBackgrounds(). I haven't been able to find the equivalent API command to get the background colors. I presume it doesn't exist and that I'll need to continue to use .getBackgrounds(). Just wanted to make sure I wasn't missing anything.
Thanks!
There is Sheets.Spreadsheets.get which gives you a spreadsheet json. Backgrounds will be at
sheets[].data[].rowData[].values[].cellData.effectiveFormat.backgroundColor
Note: this is not a dupe of this or this other question. Read on: this question is specific to the Code-Sharing template.
I am doing some pretty basic experiments with NativeScript, Angular and the code sharing templates (see: #nativescript/schematics).
Now I am doing some exploration / poc work on how different "build configuration" are supported by the framework. To be clear, I am searching for a simple -and hopefully official- way to have the application use a different version of a specific file (let's call it configuration.ts) based on the current platform (web/ios/android) and environment (development/production/staging?).
Doing the first part is obviously trivial - after all that is the prime purpose of the code sharing schematics. So, different versions of the same file are identified by different extensions. This page explain things pretty simply.
What I don't get as easily is if the framework/template supports any similar convention-based rule that can be used to switch between debug/release (or even better development/staging/production) versions of a file. Think for example of a config.ts file that contains different parameters based on the environment.
I have done some research in the topic, but I was unable to find a conclusive answer:
the old and now retired documentation for the appbuilder platform mentions a (.debug. and .release.) naming convention for files. I don't think this work anymore.
other sources mention passing parameters during the call to tns build / tns run and then fetching them via webpack env variable... See here. This may work, but seems oddly convoluted
third option that gets mentioned is to use hooks to customize the build (or use a plugin that should do the same)
lastly, for some odd reason, the #nativescript/schematics seems to generate a default project that contains two files called environment.ts and environment.prod.ts. I suspect those only work for the web version of the project (read: ng serve) - I wasn't able to get the mobile compiler to recognize files that end with debug.ts, prod.ts or release.ts
While it may be possible that what I am trying to do isn't just supported (yet?), the general confusion an dissenting opinions on the matter make me think I may be missing something.. somewhere.
In case this IS somehow supported, I also wonder how it may integrate with the NativeScript Sidekick app that is often suggested as a tool to ease the build/run process of NativeScript applications (there is no way to specify additional parameters for the tns commands that the Sidekick automates, the only options available are switching between debug/release mode), but this is probably better to be left for another question.
Environment files are not yet supported, passing environment variables from build command could be the viable solution for now.
But of course, you may write your own schematics if you like immediate support for environment files.
I did not look into sharing environment files between web and mobile yet - I do like Manoj's suggestion regarding modifying the schematics, but I'll have to cross that bridge when I get there I guess. I might have an answer to your second question regarding Sidekick. The latest version does support "Webpack" build option which seems to pass the --bundle parameter to tns. The caveat is that this option seems to be more sensitive to typescript errors, even relatively benign ones, so you have to be careful and make sure to fix them all prior to building. In my case I had to lock the version of #types/jasmine in package.json to "2.8.6" in order to avoid some incompatibility between that and the version of typescript that Sidekick's cloud solution is using. Another hint is to check "Clean Build" after npm dependency changes are made. Good luck!
I have a Cython extension which I've compiled on Ubuntu 14 and uploaded as an Anaconda package. I'm trying to install the package on another machine which is running Scientific Linux (6?) which ships with an older version of glibc. When I try to import the module I get an error that looks (something like) this:
./myprogram: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./myprogram)
When I say "something like" - the "myprogram" is actually the .so name of the extension.
From what I understand this error is because I have a newer version of glibc on the build system which has an updated version of the memcpy function.
This page has a good description of the problem, and some rather impractical solutions: http://www.lightofdawn.org/wiki/wiki.cgi/NewAppsOnOldGlibc
There is also a much simpler answer proposed here: How can I link to a specific glibc version?
My question is: how to I apply this solution to my Cython extension? Assuming the __asm__ solution works (as given in the second link) what's the best way to get it into the C generated by Cython?
Also, more generally, how to other modules avoid this issue in the first place? For example, I installed and ran a pre-built copy of numpy without any issues.
This turned out to be quite simple.
Create the following header, glibc_fix.h:
__asm__(".symver memcpy,memcpy#GLIBC_2.2.5")
Then include it by using CFLAGS="-include glibc_fix.h". This can be set as an environment variable, or defined in setup.py.
Additionally, it turns out numpy doesn't do anything special in this regard. if I compile it myself it links with the newer version on my system.
I was trying to build a simple auth mechanism using madvoc and interceptors but it seems that the tutorial at
http://jodd.org/doc/example/auth-with-interceptors.html
is a little bit outdated.
I think that the tag was removed and I was not able to find the substituent.
How should we use the form in general and what is the recommended auth mechanism?
P.S. - I`m using latest jodd version.
The shortest answer is to check module jodd-joy. Look at the package jodd.joy.auth. It contains latest AuthTag, AuthAction that may be used, etc. This module contains some helpers for build an web-app even faster.
I will update this answer later, with more info - actually, I will try to update the website, too. But in general, the idea behind the auth is not much changed;)
I have downloaded the MySQL Connector/C driver from the official website, the version that I believe is supposed to be released next to 5.6.
I then obviously wanted to use the library so I wrote a small application. During linkage, I however got a strange linker errors saying it cannot find the functions mysql_library_init() and mysql_library_end().
When I use a command to check for the functions inside the library, nm /usr/lib64/mysql/libmysqlclient.a > ~/Desktop/symbols, I indeed cannot find the functions the linker mentioned.
The functions I do find however are mysql_server_init and mysql_server_end, which are according to the documentation, marked as deprecated. (There are more functions in there too)
What am I doing wrong? I am using version 6.1.2 of the driver.
It seems like the problem is that the documentation is ahead of the code.
I am a DBA, not a C programmer, though I dabble in server internals. If the file include/mysql.h in the MySQL Server source files is any indication, the mysql_server_* functions are the ones you're looking for.
/*
mysql_server_init/end need to be called when using libmysqld or
libmysqlclient (exactly, mysql_server_init() is called by mysql_init() so
you don't need to call it explicitely; but you need to call
mysql_server_end() to free memory). The names are a bit misleading
(mysql_SERVER* to be used when using libmysqlCLIENT). So we add more general
names which suit well whether you're using libmysqld or libmysqlclient. We
intend to promote these aliases over the mysql_server* ones.
*/
#define mysql_library_init mysql_server_init
#define mysql_library_end mysql_server_end
"We intend to promote these aliases over the mysql_server* ones."
They promoted them in the documentation, apparently.
It looks like Bug #65887 was a report of the same problem, that they never really got around to doing anything with.
You might also find MariaDB's implementation of the C API "for MariaDB and MySQL" to be a viable and perhaps more agreeably-licensed alternative.