Not a question but a information.
If you are having issues with processor ATOS failing because of the lack of the cavvAlgorithm not being send then check that the module WSDL is updated to the latest version, current version i can find is 1.111 not 1.26
Url is in 2 files:
app\code\core\Mage\Cybersource\Model\Soap.php
If using CybersourceAuth extension:
CybersourceAuth\Model\Api.php
change the constants from
const WSDL_URL_TEST = 'https://ics2wstest.ic3.com/commerce/1.x/transactionProcessor/CyberSourceTransaction_1.26.wsdl';
const WSDL_URL_LIVE = 'https://ics2ws.ic3.com/commerce/1.x/transactionProcessor/CyberSourceTransaction_1.26.wsdl';
to
const WSDL_URL_TEST = 'https://ics2wstest.ic3.com/commerce/1.x/transactionProcessor/CyberSourceTransaction_1.111.wsdl';
const WSDL_URL_LIVE = 'https://ics2ws.ic3.com/commerce/1.x/transactionProcessor/CyberSourceTransaction_1.111.wsdl';
If you are having issues with processor ATOS failing because of the lack of the cavvAlgorithm not being send then check that the module WSDL is updated to the latest version, current version i can find is 1.111 not 1.26
Url is in 2 files:
app\code\core\Mage\Cybersource\Model\Soap.php
If using CybersourceAuth extension:
CybersourceAuth\Model\Api.php
change the constants from
const WSDL_URL_TEST = 'https://ics2wstest.ic3.com/commerce/1.x/transactionProcessor/CyberSourceTransaction_1.26.wsdl';
const WSDL_URL_LIVE = 'https://ics2ws.ic3.com/commerce/1.x/transactionProcessor/CyberSourceTransaction_1.26.wsdl';
to
const WSDL_URL_TEST = 'https://ics2wstest.ic3.com/commerce/1.x/transactionProcessor/CyberSourceTransaction_1.111.wsdl';
const WSDL_URL_LIVE = 'https://ics2ws.ic3.com/commerce/1.x/transactionProcessor/CyberSourceTransaction_1.111.wsdl';
Related
I have downloaded the latest version of Lua and included the source in to my project in c++builder from Embarcadero. All went rather well. Compiles perfectly.
But when I run my script, that's when it stops working correctly.
This script is ok
-- Script
Tp = tonumber( Temp )
Sp = tonumber( Setpoint )
Clr = "0xFF00FF00"
Db = 0.5
Hi = (Sp+Db)+1
Lo = (Sp-Db)-1
f = Hi
--
This script fails
-- Script
Tp = tonumber( Temp )
Sp = tonumber( Setpoint )
Clr = "0xFF00FF00"
Db = 0.5
Hi = (Sp+Db)+1
Lo = (Sp-Db)-1
f = math.floor( Hi )
--
It also fails if I try to use string.format, so it looks like the libs have not loaded correctly.
I use luaL_openlibs() to load the libraries.
I have come to the conclusion that there must be a compiler directive that I need to use. But I can't find anything that makes any difference.
If anyone has any info on building the source into their own application, I would love to know.
The main reason I have done it this way is for speed.
My Application is a data server that runs scripts against incoming data, and I expect to have several hundred data connections, both in and out.
The Answer is to call
lua_openlibs( state );
and not this code
static const luaL_reg lualibs[] =
{
{"base", luaopen_base},
{"table", luaopen_table},
{"io", luaopen_io},
{"string", luaopen_string},
{"math", luaopen_math},
{"debug", luaopen_debug},
{"loadlib", luaopen_loadlib},
/* add your libraries here */
{NULL, NULL}
};
static void openstdlibs( lua_State *l )
{
const luaL_reg *lib = lualibs;
for (; lib->func; lib++)
{
lib->func(l); /* open library */
lua_settop(l, 0); /* discard any results */
}
}
I can only assume that there is some path information missing that openlibs has.
Sorry about the formatting, couldn't get it to look right
I am finishing off building an mvc web application using .net core 2.0 with vs2017 on Win10.In writing an 'About' page I looked to put in the current project version number (at present still set at 1.0.0). I would have thought that pretty straightforward!
The only reference I could find suggested:
AppVersion = typeof(RuntimeEnvironment).GetTypeInfo ().Assembly
.GetCustomAttribute<AssemblyFileVersionAttribute> ().Version;
However, this returns, in my case, '4.6.25814.01' - not what is required.
Can anyone suggest how to retrieve the version in code, please?
I assume that I want the 'Package Version' but admit I am not clear on the distinction between/how one would use 'Package Version', 'Assembly Version' and 'Assembly File Version'.
When you call typeof(RuntimeEnvironment).Assembly, you're querying the containing assembly of that type. In this case this would be System.Runtime.InteropServices.dll or Microsoft.Dotnet.PlatformAbstractions.dll, depending on the namespace you've imported.
To get the information of your own assembly, you could simply replace RuntimeEnvironment with one of your own types, for example
var appVersion = typeof(Program).Assembly
.GetCustomAttribute<AssemblyFileVersionAttribute>().Version;
or even
var appVersion = typeof(HomeController).Assembly
.GetCustomAttribute<AssemblyFileVersionAttribute>().Version;
This would return "6.6.7.0" if the Package version if your project is set as follows:
You were close!
Here you can find more information on reflection for .NET in general, but it should work fine for .NET Core.
Tried on version 2.0
using System.Reflection;
var appVersion = string.Empty;
var customAttribute = typeof(Program).Assembly.GetCustomAttributes(false).SingleOrDefault(o => o.GetType() == typeof(AssemblyFileVersionAttribute));
if (null != customAttribute)
{
if (customAttribute is AssemblyFileVersionAttribute)
{
var fileVersionAttribute = customAttribute as AssemblyFileVersionAttribute;
appVersion = fileVersionAttribute.Version;
}
}
AssemblyFileVersionAttribute type is in System.Reflection namespace.
I'm trying to build libgrpc as a nixpkg on OS X.
It depends on zlib, protobuf >= 3.0 and openssl >= 1.0.2.
How can I specify these versions as the minimum? Both are contained in the official channel and both built successfully.
I'm pretty new to nix and this is my attempt to get my feet wet.
For now, this is what I have for default.nix:
{ stdenv, fetchurl, zlib, openssl, protobuf }:
stdenv.mkDerivation rec {
name = "libgrpc-0.10.1";
src = fetchurl {
url = "https://github.com/grpc/grpc/archive/release-0_10_1.tar.gz";
sha256 = "2da8deef4fcc421ce8e9102e8531261b3c23073ab4d2bf459e549ed4e37b5ba1";
};
buildInputs = [zlib "openssl-1.0.2d" "protobuf-3.0.0-alpha-3.1"];
meta = {
homepage = "https://github.com/grpc/grpc/";
version = "0.10.1";
description = "A library for a RPC service based on HTTP/2 and protobuf";
license = stdenv.lib.licenses.bsd3;
platforms = [
"i686-linux"
"x86_64-linux"
"x86_64-darwin"
"i686-cygwin"
"i686-freebsd"
"x86_64-freebsd"
"i686-openbsd"
"x86_64-openbsd"
];
downloadPage = "https://github.com/grpc/grpc/archive/release-0_10_1.tar.gz";
};
}
I'm either looking for a way to either build libgrpc > 0.10 under nix - or for a wayto define minimum versions for requirements so I can try to fix this myself.
Thanks!
A look inside all-packages.nix showed that these versions are available as openssl_1_0_2 and protobuf3_0.
I'm still stuck at a zlib-dependency problem, but the problem I asked about is solved.
I'm working on migrating code from Visual Basic 6 to Visual Basic.NET, but before I can do that I need to get it to build. Currently I cannot get it to build because of a missing reference in an MSHTML for an IDocHostUIHandler. Specfically I get the error on the line using DOCHOSTUIFLAG_DIALOG. I've tried added different references, but the error stays the same. If it makes any difference, I'm running XP with IE8.
MSDN says that the IDocHostUIHandler interface is defined in mshtmhst.idl which is in the Platform SDK. I can't find this defined in any DLL or type library so you may need to compile the IDL into your own library to register.
You will also need to make sure that there are no references listed as "(MISSING)" as these cause random object reference problems.
Try this in a module
Public Enum DOCHOSTUIFLAG
DOCHOSTUIFLAG_DIALOG = 1
DOCHOSTUIFLAG_DISABLE_HELP_MENU = 2
DOCHOSTUIFLAG_NO3DBORDER = 4
DOCHOSTUIFLAG_SCROLL_NO = 8
DOCHOSTUIFLAG_DISABLE_SCRIPT_INACTIVE = &H10
DOCHOSTUIFLAG_OPENNEWUI = &H20
DOCHOSTUIFLAG_DISABLE_OFFSCREEN = &H40
DOCHOSTUIFLAG_FLAT_SCROLLBAR = &H80
DOCHOSTUIFLAG_DIV_BLOCKDEFAULT = &H100
DOCHOSTUIFLAG_ACTIVATE_CLIENTHIT_ONLY = &H200
DOCHOSTUIFLAG_OVERRIDEBEHAVIORFACTORY = &H400
DOCHOSTUIFLAG_CODEPAGELINKEDFONTS = &H800
DOCHOSTUIFLAG_URL_ENCODING_DISABLE_UTF8 = &H1000
DOCHOSTUIFLAG_URL_ENCODING_ENABLE_UTF8 = &H2000
DOCHOSTUIFLAG_ENABLE_FORMS_AUTOCOMPLETE = &H4000
DOCHOSTUIFLAG_ENABLE_INPLACE_NAVIGATION = &H10000
DOCHOSTUIFLAG_IME_ENABLE_RECONVERSION = &H20000
DOCHOSTUIFLAG_BROWSER = &H12
DOCHOSTUIFLAG_DESKTOP = &H2E
End Enum
I want to write a program which can read core files in Linux. However i cannot find any documentation which can guide me in this respect. Can someone please guide me as to where to do find some resources?
You can also take a look at GDB source code, gdb/core*.
For instance, in gdb/corelow.c, you can read at the end:
static struct target_ops core_ops;
core_ops.to_shortname = "core";
core_ops.to_longname = "Local core dump file";
core_ops.to_doc = "Use a core file as a target. Specify the filename of the core file.";
core_ops.to_open = core_open;
core_ops.to_close = core_close;
core_ops.to_attach = find_default_attach;
core_ops.to_detach = core_detach;
core_ops.to_fetch_registers = get_core_registers;
core_ops.to_xfer_partial = core_xfer_partial;
core_ops.to_files_info = core_files_info;
core_ops.to_insert_breakpoint = ignore;
core_ops.to_remove_breakpoint = ignore;
core_ops.to_create_inferior = find_default_create_inferior;
core_ops.to_thread_alive = core_thread_alive;
core_ops.to_read_description = core_read_description;
core_ops.to_pid_to_str = core_pid_to_str;
core_ops.to_stratum = process_stratum;
core_ops.to_has_memory = core_has_memory;
core_ops.to_has_stack = core_has_stack;
core_ops.to_has_registers = core_has_registers;
The struct target_ops defines a generic interface that the upper part of GDB will use to communicate with a target. This target can be a local unix process, a remote process, a core file, ...
So if you only investigate what's behing these functions, you won't be overhelmed by the generic part of the debugger implementation.
(depending of what's your final goal, you may also want to reuse this interface and its implementation in your app, it shouldn't rely on so many other things.
Having a look at the source of gcore http://people.redhat.com/anderson/extensions/gcore.c might be helpful.
Core files can be examined by using the dbx(1) or mdb(1) or one of the proc(1) tools.