It seems the ENCRYPT function works very differently on Linux from on macOS. I wonder why?
set #salt := SHA2(RAND(), 512);
select ENCRYPT('abc', CONCAT('\$6\$rounds=5000$', #salt));
Linux 5.4.174-2-pve / Mariadb 10.7
$6$rounds=5000$36fcf04d0f759de9$eZedOjHbDve6bomhxF95pzFUajCzFGgnNxh8JapGZlCb5NzzT2ze96hhO8s803zpPGMP4L48hhBm.6cHAv6Op/
macOS 12.4 / Mariadb 10.8
$6G/aJp5H5PCs
MariaDB's ENCRYPT() function uses the crypt() function of the libcrypt library. The implementation of crypt() is different on Mac and Linux: While Linux uses SHA512, the Mac variant uses DES.
Related
I had a working connection to a DB2 server from R. Then I ungraded to R v4.2 and it no longer works.
This is my connection string:
con_DB2 = DBI::dbConnect(odbc::odbc(),
Driver = "IBM DB2 ODBC DRIVER - C_PROGRA~2_IBM_V111~1.4FP_CLIDRI~1",
Database='DB2Q',
Hostname='usddcs',
Port=3700,
PROTOCOL='TCPIP',
UID= rstudioapi::askForPassword("Database username"),
PWD=rstudioapi::askForPassword("Database password"))
I get the following error message:
Error: nanodbc/nanodbc.cpp:1021: IM004: [Microsoft][ODBC Driver Manager] Driver's SQLAllocHandle on SQL_HANDLE_ENV failed
This seems to have been raised in this issue: https://github.com/rstudio/rstudio/issues/10509
It was NOT solved, but suggestions are that the encoding might be impacting this. Are there any arguments to the dbConnect() function that can be changed to fiddle with encoding to make it work in the new R version?
> sessionInfo()
R version 4.2.2 (2022-10-31 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19042)
Works for me with R4.2.2 on Win10 pro(19045) and Rstudio 2022.07.02-576 and
IBM clidriver version 11.5.6.0 (or higher). It may also work with older driver versions.
The key detail is that you need to have the system environment variable DB2CODEPAGE=1208 set before starting Rstudio. This tells the clidriver to use utf-8 as the application code page.
If you only want the change to impact Rstudio and R (but not separate command-line based programs, for perl, python, php, clp etc ) then set that variable in the Rstudio script via Sys.setenv(DB2CODEPAGE=1208) or equivalent configuration/startup file.
Note that if you are not using clidriver, and instead you are using a larger footprint Db2 client (for example, the fat client, or the runtime client) then you may also use the db2set DB2CODEPAGE=1208 method of setting the variable, and the consequence should be the same.
Then the database connection to Db2-LUW succeeds (the target database is also utf-8 encoded).
You can also ignore the cli driver and instead try accessing the database via rJDBC and a jdbc driver (there is no shared code between the jdbc driver and the cli driver).
After positive creation of the shared context between OpenGL and OpenCL using following:
cl_context_properties cps[] = {
CL_GL_CONTEXT_KHR,
(cl_context_properties)glXGetCurrentContext(),
CL_GLX_DISPLAY_KHR,
(cl_context_properties)glXGetCurrentDisplay(),
CL_CONTEXT_PLATFORM,
(cl_context_properties)platform_id,
0
};
// Create an OpenCL context
m_contextCL = clCreateContext( cps, 1, &device_id, NULL, NULL, &err);
I try to create a shared texture:
cl_mem mem = clCreateFromGLTexture(
m_contextCL ,
CL_MEM_READ_ONLY ,
GL_TEXTURE_2D ,
0 ,
qt_fbo->texture() ,
&err
);
Now the call is successful only on xubuntu 16.04 with NVIDIA Quadro K620 using proprietary driver version 387.26 and OpenCL delivered with CUDA implementation package.
However when trying it on Toshiba laptop with Intel HD Graphics 520 on Manjaro OS and Beignet OpenCL implementation. The clCreateFromGLTexture(...) is failing by returning CL_INVALID_CONTEXT,
Additionally I tried another platform with Ubuntu 16.04 and Intel Iris IGP (Integrated Graphics Processor) using both Intel SDK and Beignet OpenCL. It fails at the same point of shared texture creation.
I created minimum working example for comparison two GPU techniques (OpenGL and OpenCL) and its interoperability with Qt:
https://github.com/pietrzakmat/opengl-opencl-qt-interop.
All the steps are derived from two tutorials:
1. https://www.codeproject.com/Articles/685281/OpenGL-OpenCL-Interoperability-A-Case-Study-Using
2. https://software.intel.com/en-us/articles/opencl-and-opengl-interoperability-tutorial
Anyone could point out what am I doing wrong and why the creation of shared texture fails on the platforms with integrated graphics or IGP Intel cpu? Is this some problem with drivers or OpenCL implementations? I managed to build and run the samples included in Beignet or intel_ocl_examples so I think the installation is correct.
1) is supported cl_khr_gl_sharing extension? Did you try to use this code on Windows Platform/macOS for Intel GPU ?
2) Did you try to use texture without attached to FBO ?
any way, i think this is problem in OpenCL implementation on Linux platform.
When I call a Java Stored Procedure in c-treeACE SQL Explorer, for example: call myProc(), an error happened:
Error : -20160 Error Description : Java SP/T Feature not supported.
My environment:
OS: Win 10 64bit
c-treeACE: V11.0.0 32bit
JDK/JRE: jdk1.6.0_31 64 bit, or jdk 1.8 64 bit, or jdk 1.6 32 bit
Also, I have already Setting in ctsrvr.cfg for Java Stored Procedure
Support(also restart the c-treeACE service):
SETENV CLASSPATH=D:\Work\Db\d3dxsapi\Java\jre6\lib\rt.jar;C:\FairCom\V11.0.0\win32\bin\ace\sql\classes\ctreeSQLSP.jar
SETENV JVM_LIB=D:\Work\Db\d3dxsapi\Java\jre6\bin\client\jvm.dll
SETENV JAVA_COMPILER=D:\Work\Db\d3dxsapi\Java\jdk1_6_0_31\bin\javac.exe
Any one know this, could you please help me? Thanks!
I used another jdk 1.6(32 bit) to figure it out.
We have an OpenCL program that works fine on my OS X machine. We just set up a machine with a Xeon Phi and Intel MPSS. However, even when not using the Phi but the Xeon CPU, the CL_PROGRAM_BUILD_STATUS we get is CL_BUILD_NONE.
Unfortunately, we cannot find any documentation on what might cause CL_BUILD_NONE. Do you have any suggestion on how to debug this?
Thank you in advance!
Versions:
[#memphis:~] $ cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 2
[#memphis:~] $ uname -a
Linux memphis 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012 (d73692b) x86_64 x86_64 x86_64 GNU/Linux
[#memphis:~] 1 $ rpm -qa |grep intel
intel-mic-2.1.6720-15.suse
intel-mic-mpm-2.1.6720-15.suse
opencl-1.2-intel-mic-3.0.67279-1
intel-mic-sysmgmt-2.1.6720-15.suse
intel-mic-kmod-2.1.6720-15.3.0.13.0.suse
intel-mic-gdb-2.1.6720-15.suse
intel-mic-flash-2.1.386-3.suse
intel-mic-cdt-2.1.6720-15.suse
opencl-1.2-intel-devel-3.0.67279-1
intel-mic-micmgmt-2.1.6720-15.3.0.13.0.suse
opencl-1.2-intel-cpu-3.0.67279-1
intel-mic-gpl-2.1.6720-15.suse
intel-mic-crashmgr-2.1.6720-15.suse
The documentation for clGetProgramBuildInfo seems pretty straightforward:
CL_BUILD_NONE. The build status returned if no clBuildProgram, clCompileProgram or clLinkProgram has been performed on the specified program object for device.
You mention that your program worked on other platforms, but maybe you ended up with a slightly different flow between platforms which led to those methods not being properly invoked in the new flow? I'd suggest carefully verifying the return value from the earlier invoked functions to see you get what you expect to get.
Found it. I am not sure why I had &ret (cl_int return value) as the last parameter instead of having it as the return value of clBuildProgram. Moving it and setting the last parameter to NULL fixes the problem:
wrong:
clBuildProgram(*program, 1, &device_id, opts.str().c_str(), NULL, &ret);
correct:
ret = clBuildProgram(*program, 1, &device_id, opts.str().c_str(), NULL, NULL);
I do understand why this problem occured - apparently the compiler / the OpenCL libraries understood that I wanted to use pfn_notify and asynchronously build my kernel. I am, however, not sure if this behavior is fully conformant to the OpenCL documentation:
If pfn_notify is NULL, clBuildProgram does not return until the build has completed.
In my code, the pfn_notify argument was actually NULL, however user_data was (erroneously) not. While my code didn't make any sense, I believe that user_data should be ignored when pfn_notify is NULL.
I posted this on the Intel forums to see if they agree with my interpretation of the documentation.
I'm running R 2.11 64-bit on a WinXP64 machine with 8 processors. With R 2.10.1 the following code spawned 6 R processes for parallel processing:
require(foreach)
require(doSNOW)
cl = makeCluster(6, type='SOCK')
registerDoSNOW(cl)
bl2 = foreach(i=icount(length(unqmrno))) %dopar% {
(Some code here)
}
stopCluster(cl)
When I run the same code in R 2.11 Win64, the 6 R processes are not spawning, and the code hangs. I'm wondering if this is a problem with the port of SNOW to 2.11-64bit, or if any additional code is required on my part. Thanks
BTW, this works just fine on my multicore machine at home running Ubuntu Karmic 64-bit and R 2.11. Unfortunately I have to work on Win64 at work
The code seems to be working here.
R version 2.11.0 (2010-04-22)
x86_64-pc-mingw32
other attached packages:
[1] doSNOW_1.0.3 snow_0.3-3 foreach_1.3.0 codetools_0.2-2
[5] iterators_1.0.3
loaded via a namespace (and not attached):
[1] tools_2.11.0
Check your sessionInfo() to make sure your versions match mine. One thing I noted is that on my Windows 7 machine the first attempt to makeCluster made a request for a firewall exception. If you did not explicitly make allowances for the socket communication that could be why it is hanging. The defaults it opened (ugly as it is) was all TCP and UDP ports when operating under the private profile.
It is an old question, but I encountered the same problems with R-2.13.1 64 on Win 64 bits.
doSNOW was working fine with R 32-bits but not with R 64-bits, and was hanging at "cl = makeCluster(6, type='SOCK')" as well.
To resolve the problem I eventually added "C:\Program Files\R\R-2.13.1\bin\x64" to the %PATH% environment variable (win+pause/advanced system settings/advanced/environment variables/system variables). Make also sure to allow the R connections in Windows Firewall, and that C:\Program Files\R\R-2.13.1\bin contains copy of the 32-bits version of R.exe and Rscript.exe (not the x64 ones).
After doing this, when running makeCluster() 12 processes are started, 6 32 bits and 6 64 bits, but during the calculations only the 64 bits one are used.