Awesome WM 4 run_or_raise function - configuration

I start to use Awesome 4.0 afters many years on awesome 3.5.
I used aweror lib (you can see it here: https://github.com/lkonga/awesomewm-config) for have a "run or raise" functionality, but I don't find how can I have it with the version 4.0.
Anybody knows how have it?

It seems to be available via the awful.client.run_or_raise function:
https://awesomewm.org/apidoc/classes/client.html#awful.client.run_or_raise
Usage from the documentation:
-- run or raise urxvt (perhaps, with tabs) on modkey + semicolon
awful.key({ modkey, }, 'semicolon', function ()
local matcher = function (c)
return awful.rules.match(c, {class = 'URxvt'})
end
awful.client.run_or_raise('urxvt', matcher)
end);

Related

ScriptControl doesn't work on VBA json parser in 64bit excel? [duplicate]

Is there any msscript control in 64 bit?
I google a bit and all say no 64-bit yet
The reason that I need 64bit msscript.ocx is that I want to compile delphi projects in 64-bit using XE3.
It compiles OK in XE3 and I have obtained a 64-bit exe but when it executes to the following line,
script := TScriptControl.Create(nil);
It gives me a 'Class Not Registered' error. I only found msscript.ocx under C:\windows\SysWOW64 but there is no such file under System32 folder.
I really want this to work so any quick replacement for this?
This is an old post. but I just found a very good alternative to 64-bit MSScript Control (Microsoft does not have 64-bit msscript.ocx)
http://www.eonet.ne.jp/~gakana/tablacus/scriptcontrol_en.html
and I have changed only a few lines of code in my application and it works in 64-bit based on this ScriptControl64.
The msscript component was not ported to 64 bit. It's a legacy component and MS chose not to put the effort into migrating it to 64 bit. You'll simply need to find another way to do whatever it is you do with that component.
I faced the same issue porting an c++ application from 32 to 64 Bit.
I know that this question was raised on Delphi but I hope someone can make use of this information or transfer it to other languages.
We where initiating the "ScriptControl" (MSScriptControl.ScriptControl.1) via CreateDispatch.
The control info is located in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ScriptControl
and we executed VBS or JScript with this MS control in 32 Bit:
COleDispatchDriver* m_dispScriptControl = new COleDispatchDriver();
if (m_dispScriptControl)
{
if (m_dispScriptControl->CreateDispatch(_T("ScriptControl")))
{
...
.... setting language to be used and other proteries .. then execute script code:
_variant_t varResult;
VariantClear(&varResult);
EXCEPINFO excepinfo;
VARIANT parameters;
parameters.vt = VT_BSTR;
parameters.bstrVal = strScriptCodeWCHAR;
DISPPARAMS dispparams;
dispparams.rgdispidNamedArgs = NULL;
dispparams.cNamedArgs = 0;
dispparams.cArgs = 1;
dispparams.rgvarg = &parameters;
unsigned int uArgErr = 0;
if (S_OK != m_dispScriptControl->m_lpDispatch->Invoke(0x7d2, IID_NULL, LOCALE_SYSTEM_DEFAULT, DISPATCH_METHOD, &dispparams, &varResult, &excepinfo, &uArgErr))
...
}
After some research it seems not to be possible to create the
ScriptControl in 64 bit application as of a MSDN query:
Question was: I have window forms application currently working fine
on 32 Bit Application and i am investigation so we can install it on a
64 bit computer but getting on lauching the application as below.
Class not registered (Exception from HRESULT: 0x80040154
(REGDB_E_CLASSNOTREG))
The error is located on AxInterop.MSScriptControl.dll
Awnser is: If it ONLY lives in C:\Windows\SysWOW64, then your .Net
application cannot run in 64-bit mode. Make sure you compile it for
x86 instead of Any CPU. Then you'll be able to use it in 64-bit
Windows, but it will be a 32-bit process.
https://social.msdn.microsoft.com/Forums/windows/en-US/1e9ddfe4-3408-4a34-ba43-a1a0931daebd/64-bit-windows-7?forum=clr
With which we where not happy as we want to run as 64-bit process
Our solution was to use the Microsoft IActiveScript Interface. And implemented the same on our main window:
BEGIN_INTERFACE_PART(ActiveScriptSite, IActiveScriptSite)
STDMETHOD(GetLCID)(LCID*);
STDMETHOD(GetItemInfo)(LPCOLESTR, DWORD, LPUNKNOWN*, LPTYPEINFO*);
STDMETHOD(GetDocVersionString)(BSTR*);
STDMETHOD(OnScriptTerminate)(const VARIANT*, const EXCEPINFO*);
STDMETHOD(OnStateChange)(SCRIPTSTATE);
STDMETHOD(OnScriptError)(IActiveScriptError*);
STDMETHOD(OnEnterScript)();
STDMETHOD(OnLeaveScript)();
END_INTERFACE_PART(ActiveScriptSite)
Now when we have to execute script code we do the following, which works fine in 64 and 32 BIT versions of our built:
CString strLanguage;
if (nLanguage == 1)
{
strLanguage = _T("VBScript");
}
else
{
strLanguage = _T("JScript");
}
CComPtr<IActiveScript> m_pAxsScript;
HRESULT hr = m_pAxsScript.CoCreateInstance(CT2W(strLanguage), NULL, CLSCTX_INPROC_SERVER | CLSCTX_INPROC_HANDLER);
m_pAxsScript->SetScriptSite(&m_xActiveScriptSite); //m_xActiveScriptSite is a member of the interface
CComQIPtr<IActiveScriptParse> m_pAxsScriptParse = m_pAxsScript;
m_pAxsScriptParse->InitNew();
EXCEPINFO pException = { 0 };
hr = m_pAxsScriptParse->ParseScriptText(_bstr_t(strCode), 0, NULL, NULL, dw, 0, 0, NULL, &pException);
//execute script
m_pAxsScript->SetScriptState(SCRIPTSTATE_CONNECTED);
m_pAxsScriptParse.Release();
m_pAxsScriptParse = nullptr;
hr = m_pAxsScript->SetScriptState(SCRIPTSTATE_DISCONNECTED);
ASSERT(hr == S_OK);
m_pAxsScript->Close();
m_pAxsScript.Release();

VS Code Dynamic Import syntax error statement expected

Any idea how to get rid of this warning in VS Code
const loadAnalytics = () => {
import(
/* webpackChunkName: "chunk-analytics" */ './analytics'
).then(page => page.init());
};
"Declaration or Statement expected", the code actually compiles file just annoying to keep seeing this warning in VS code.
Update - November 3, 2017
VS Code 1.14+ fully supports import expressions. You should no longer run into this issue
Original Answer
Import expressions are not supported in VSCode 1.13 but we just added support for them in VScode 1.14. You can try this today in the current insiders builds
If need to stay on 1.13, #Steffen's suggestion about setting "javascript.validate.enable": false is the way to go

How to check if a function is defined in Octave?

How can I check if octave recognises a function that I have defined in the command line (or a script file)?
For example, how could I check that the function below, vl, is defined in octave?
function retval = vl(t)
retval = vl0()+al()*t;
endfunction
I found only this post about how to check variables
There, someone uses the command exist("varname","var") but there is no option "func" so that I can make exist("vl","func"); I found only the option "builtin" for built-in functions.
I will answer myself. I hope it will be useful.
In the manual of octave I found that you can call exist("function name") without option—that's the point— and the return value for an existing function defined through script or in terminal is 103 (See return codes of "exist").
Example: In my case
exist("vl")
103

Fat free framework Missing argument 1 for {closure}()

while following this bit of code
$f3=require('lib/base.php');
$f3->route('GET /brew/#count',
function($f3) {
echo $f3->get('PARAMS.count').' bottles of beer on the wall.';
}
);
$f3->run();
from Fat-Free Framework examples at https://github.com/bcosca/fatfree#routing-engine I get this error in my browser:
Internal Server Error
Missing argument 1 for {closure}()
* /var/www/f3/index.php:36 Base->{closure}
* /var/www/f3/lib/base.php:972
* Base->call(Closure::__set_state(),NULL,'beforeroute,afterroute')
* /var/www/f3/index.php:40 Base->run()
I know the problem is that $f3 is not passed to function as parameter but i don't understand why. Can anybody help me?
I just the same situation! I was using version 3.0.1 from SourceForge. I tried the following, which worked, but created other issues:
$f3=require('lib/base.php');
$f3->route('GET /brew/#count',
function() use ($f3) {
echo $f3->get('PARAMS.count').' bottles of beer on the wall.';
}
);
$f3->run();
The use clause (which isn't very well documented in php) allows you to use variables from the parent scope from an anonymous function. Read more here: Closure vs Anonymous function (difference?)
Try upgrading the F3 core to the latest release. One of the developers recommended to upgrade to the 3.0.2 release from here: https://github.com/bcosca/fatfree. It was a very quick fix!

IronPython Memory Leak When Calling Function With More Than 13 Parameters

I'm using IronPython 2.6.2 for .NET 4.0 as a scripting platform within a C#/WPF application. Scripts can include their own function definitions, class definitions, etc. I'm not restricting what can be written.
A memory leak appeared in the scripting piece recently after a script change. After commenting out more and more code, we determined that defining and calling a function with more than 13 parameters causes a memory leak. So if you call a function with 14 parameters IronPython will leak.
Here is some sample code on a timer running every 100ms:
_Timer.Enabled = false;
try
{
var engine = Python.CreateEngine();
engine.Execute("def SomeFunc(paramI, paramII, paramIII, paramIV, paramV, paramVI, paramVII, paramVIII, paramIX, paramX, paramXI, paramXII, paramXIII, paramXIV):\r\n\tpass\r\nSomeFunc(1,2,3,4,5,6,7,8,9,10,11,12,13,14)");
//engine.Execute("def SomeFunc(paramI, paramII, paramIII, paramIV, paramV, paramVI, paramVII, paramVIII, paramIX, paramX, paramXI, paramXII, paramXIII):\r\n\tpass\r\nSomeFunc(1,2,3,4,5,6,7,8,9,10,11,12,13)");
// With and without the following line makes no difference
engine.Runtime.Shutdown();
this.Dispatcher.Invoke((Action)delegate()
{
this.Title = DateTime.Now.ToString();
});
}
catch (Exception)
{
}
_Timer.Enabled = true;
Note that I have a 14-parameter version of the script and below it is a commented-out 13-parameter version. The Python script is basically this:
def SomeFunc(paramI, paramII, paramIII, paramIV, paramV, paramVI, paramVII, paramVIII, paramIX, paramX, paramXI, paramXII, paramXIII, paramXIV):
pass
SomeFunc(1,2,3,4,5,6,7,8,9,10,11,12,13,14)
I've tried with and without engine.Runtime.Shutdown() but it makes no difference. The 14-parameter version's memory will climb rapidly and the 13-parameter version's memory will climb slightly and then stabilize.
Any thoughts?
Thanks
- Shaun
There's a magic number of parameters in IronPython - less than that is a different (faster) code path than more. It sounds like there are still some bugs in the fallback code. Can you please open an issue with a self-contained test case?
Looking at the latest code I would think the boundary would be at 15. Can you try again on 2.7 Beta 2 and see if the results are the same?