On Soumith's benchmark there are both CUDNN[R4]-fp16 and CUDNN[R4]-fp32 benchmarks for Torch.
How can I enable floating point 16 on Torch ?
I found discussions such as this one but it's not clear to me what to do with it.
Thank you!
I think you don't have to enable half precision. If cutorch.hasHalf is true, this should work;
require('cutorch')
a = torch.CudaHalfTensor(3)
b = torch.CudaHalfTensor(3)
print(torch.cmul(a,b))
If it doesn't, try updating cutorch to latest version;
luarocks install cutorch
Related
I am refactoring code from python2(RHEL 7.6) to python3(RHEL 8.2) and I have problem with missing library in python3.6.
Problem:
from rpmUtils.miscutils import splitFilename ModuleNotFoundError: No module named 'rpmUtils'
I've tried to install python3-dnf and python3-rpm packages to RHEL8, but still not working. Is there any solution how to use this library in python3.6 and RHEL8 or should I write some custom function by myself?
Thank you for your answer.
This library was indeed removed, but you have several other options you can use.
Please note that these other functions expect to receive a string in the NEVRA (name, epoch, version, release, architecture) format as an input, not a filename. Thus you must remove the '.rpm' extension of the filename, in order to get a NVRA string (epoch normally is not included in the filename of the RPM package).
So basically you have 2 options:
to use dnf as suggested in i.e. https://bugzilla.redhat.com/show_bug.cgi?id=1364504
to use hawkey i.e. :
import hawkey
rpm_base_filename = os.path.basename(rpm_file)
nevra = hawkey.split_nevra(rpm_base_filename[:-len(".rpm")])
name = nevra.name
version = nevra.version
release = str(nevra.release)
epoch = str(nevra.epoch)
arch = nevra.arch
For example here is a patch for such modification that I made for one of the tools we use as part of the oVirt release process:
https://github.com/oVirt/releng-tools/commit/823405e6b261f7ff27ddbba0e8fa2b86dd2a8698
In Robot Framework how do I give the ctrl+c command?
I have tried this line but it does not work
${crtl_c} Evaluate chr(int(3)) SSHLibrary.Write Bare ${crtl_c}
Use imagehorizon as a library :
Press Combination KEY.CTRL C
Use PyAutoGUI
PyAutoGUI works on Windows/Mac/Linux on Python 2 & 3. Install from PyPI with
pip install pyautogui
import pyautogui
def CntrlC():
pyautogui.hotkey('ctrl', 'c') #Performs ctrl+c
Now just import the py file and use CntrlC as the Keyword
${ctrl_c} evaluate chr(int(3))
SSHLibrary.Write Bare ${crtl_c}
Or else you can give the line in variables section:
***variable***
${ctrl_c} evaluate chr(int(3))
Just got this working. The problem with the answers above is that you need an equal sign.
${ctrl-c}= evaluate chr(int(3))
Write Bare ${ctrl-c}
Refering to a previous answer on an SO question where if you're on windows, the SendKeys python library is used to send actual key presses to the system. In case you're on a linux based system it pretty much depends on the GUI you're using and a few other factors. This SO Question has some good content that might help you.
I'm playing with command model binding and I looked at the example github project and I have issues when using the dependency:
"org.scalatra" % "scalatra-data-binding" % "2.2.0-RC1"
Taking the example project code i.e.
abstract class TodosCommand[S](implicit mf: Manifest[S]) extends ModelCommand[S] with ParamsOnlyCommand
class CreateTodoCommand extends TodosCommand[Todo] {
val name: Field[String] = asType[String]("name").notBlank.minLength(3)
}
case class Todo(id: Integer, name: String, done: Boolean = false)
I am unable to compile when I use the command[CreateTodoCommand] method from the CommandSupport trait i.e.
scala: type arguments [au.com.xxx.sapi.seo.CreateTodoCommand] do not conform to method command's type parameter bounds [T <: SeoServlet.this.CommandType]
val cmd = command[CreateTodoCommand]
^
I'm not that clued up with Scala but I would assume that as ParamsOnlyCommand extends Command and there is this line in the command support trait, then there should be no issues:
type CommandType <: org.scalatra.databinding.Command
Any ideas why I am getting this issue?
Cheers, Chris.
It's very likely that the reason you're having problems is that we're still linking to an ancient example version, for which the docs no longer apply. I thought I'd caught all of the example projects in the docs and moved them into https://github.com/scalatra/scalatra-website-examples, but apparently I missed this one. Sorry for the hassle!
I'll see if I can fix this today sometime, and provide a compiling example. In the meantime, you might try updating all your Scalatra-related dependencies to the 2.2.0 release - and see if that fixes anything straight away.
The latest stable release of Scalatra is currently 2.2.1, but you'll need to be careful around commands as I remember #casualjim saying that he'd changed the way things worked to some extent between 2.2.0 and 2.2.1.
In Scalatra 2.2.1, "org.scalatra" %% "scalatra-commands" % "2.2.0" I have no issues. but I don't know scalatra-data-binding is also standalone.
I am looking for a working distribution of SQLite for OpenVMS. I tried building SQLite 3.7.9 from the amalgamation file, using patches I found in a mailing list, but it does not quite work.
I am using HP C V7.1-015 on OpenVMS Alpha 7.3-2.
Since I cannot install python, which seems to include SQLite3, I have to build from sources.
I compile using the following commands:
$ CC /OPTIMIZE -
/DEFINE=(SQLITE_THREADSAFE=0, -
SQLITE_OMIT_LOAD_EXTENSION=1, -
SQLITE_OMIT_COMPILEOPTION_DIAGS=1, -
SQLITE_OMIT_MEMORYDB=1, -
SQLITE_OMIT_TEMPDB=1, -
SQLITE_OMIT_DEPRECATED=1, -
SQLITE_OMIT_SHARED_CACHE=1, -
_USE_STD_STAT=ENABLE) -
/FLOAT=IEEE_FLOAT -
sqlite3.c
$ CC /OPTIMIZE -
/DEFINE=(SQLITE_THREADSAFE=0, -
SQLITE_OMIT_LOAD_EXTENSION=1, -
SQLITE_OMIT_COMPILEOPTION_DIAGS=1, -
SQLITE_OMIT_MEMORYDB=1, -
SQLITE_OMIT_TEMPDB=1, -
SQLITE_OMIT_DEPRECATED=1, -
SQLITE_OMIT_SHARED_CACHE=1, -
_USE_STD_STAT=ENABLE) -
/FLOAT=IEEE_FLOAT -
shell.c
I copied the defines from the mailing list, and added /FLOAT=IEEE_FLOAT to get rid of most warnings regarding floating points (related to overflows due to exponent 308).
During compilation I got some informationals and warnings.
I get the following messages while linking:
$ LINK shell.obj,sqlite3.obj
...
%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM, __STD_FSTAT
%LINK-I-UDFSYM, __STD_STAT
...
Since I am a little bit lost here, I rather have SQLite3 sources which compile on OpenVMS.
The specific problem you're getting from the linker arises from the fact that you've requested capability at compile time that your system doesn't have. I believe the _USE_STD_STAT option first became available in OpenVMS v8.2, yet you're on 7.3-2. Your compiler and your headers know what to do when _USE_STD_STAT is defined, but the functions to process the X/Open-compliant stat structure do not exist in the C run-time (CRTL in VMS parlance) on your system, and your linker is telling you, "ain't got those functions."
Ideally you would be able to upgrade your operating system. Current as of this writing is v8.4. v7.3-2 was released eight and a half years ago and v8.2 over seven years ago. I understand that there are technical, budgetary, and even political reason that upgrades aren't always possible. If it were me, and I were stuck on OpenVMS Alpha v7.3-2, I would try removing the _USE_STD_STAT=ENABLE from the compilation and see what blows up.
One of the side effects of enabling _USE_STD_STAT is that you also get _LARGEFILE along with it. If that's the only reason SQLite needs the option, you may be fine but limited to 4GB databases. I suspect there's more to it than that, i.e., SQLite very likely makes use of elements in the stat structure that do actually require the newer structure.
You can read up on the differences in the traditional and standards-compliant stat structures at http://h71000.www7.hp.com/doc/84final/5763/5763profile_062.html#index_x_1699.
I've recently improved my VMSish patch for SQLite and made it available for SQLite version 3.7.14.1: http://www.mail-archive.com/sqlite-users#sqlite.org/msg73570.html (or http://sqlite.1065341.n5.nabble.com/Building-SQLite-3-7-14-1-for-OpenVMS-td65277.html).
POSIX locking still doesn't work though, and I was unable to find out why.
Well, there was a message on the sqlite-users mailing list on getting SQLite 3.7.9 working on OpenVMS. I don't know how relevant that is to the version you've got (or if the patch was adopted by the SQLite developers; they're a bit picky for legal reasons IIRC) but it looks likely to be useful. Good luck.
VendorString() doesn't work, it's always Sun Microsystems, even if it is Xorg built for Solaris.
$ xdpyinfo | grep vendor
vendor string: The X.Org Foundation
vendor release number: 10601901
This is xorg-server 1.6.1 on Linux. Hopefully XOrg and XSun on Solaris will differ here.
To output these two fields, xdpyinfo calls the ServerVendor macro to determine the vendor, then parses the return of the VendorRelease macro differently depending on what ServerVendor was.
By the way, what's VendorString()? I don't have a function or macro by that name...
It's possibly a little hacky, but if you look at the list of extensions returned from Xsun and Xorg you should see that Xorg has a few extra XFree86-derived extensions.
xdpyinfo can be used to list the extensions via the command-line to check for differences; programmatically you can use XListExtensions() or XQueryExtension().
(I haven't got a Xsun X Server to hand but I'm pretty sure when I've looked in the past they have differed quite abit).
Thank you!
Oops, VendorRelease() string it is.
Anyway, unfortunately we cannot bet on this string. It changes often enough to have a trouble, for Xsun as well as for Xorg. I have found a solution working (hopefully) for them and for various other (derived) servers like Xvfb, Xnest etc.
Xsun does use a third value in an array of the keysyms for KP_ (numpad) keycodes. Xorg uses 1-st or 2-nd. A sniffer should first, obtain a keycode for a KP_ keysym, for instance XK_KP_7,
second, sniff what is in the XKeycodeToKeysym(d,keycode, [0-3]). Our XK_KP_7 will be on the index 2 for Xsun.