I have been trying Hyperapp.
For a number of reasons I want to use the h function rather than JSX, I won't get into the whys and wherefores here but no JSX please!
Thing is when I create an instance of a component by using JSX everything is fine.
Example component (both this and the JSX equivalent work the same in examples below):
const Examp = (props) => (
h("p",{},["this is an example"])
)
Example view using JSX, this loads the Examp component as expected (I see 'this is an example'):
const view = (state, actions) => (
<main>
<h1>JSX Example</h1>
<p>Begin</p>
<Examp/>
<p>End</p>
</main>
)
Example view using h, this doesn't work, I get an empty "examp" node (note the case):
const view = (state, actions) => (
h("main",{},[
h("h1",{},["H Example"]),
h("p",{},["Begin"]),
h("Examp",{},[]),
h("p",{},["End"])
])
)
It looks like h is changing the capitalisation of the node and this is causing it not be load the component.
Am I doing something wrong, if so, how should I deal with this?
Edit: having looked at the Hyperapp source code; hyperapp uses document.createElement to create nodes and will always create a lowercase node, as component functions need a capital, have components ever worked with h or has this been overlooked? In which case hyperapp needs JSX :/
As Examp is a component, "h" function should be called using this syntax (without quotes):
...
h(Examp, {}, [])
...
only HTML base elements should be defined as string.
Related
I have an SVG object like that:
<svg class="class-a color-green marker" .../>
In Playwright I want to get an exact list of classes of this element. I use the following code to locate it:
page.locator(".status-marker").first
The node is located properly, but when I call evaluate("node => node.className") on it, I get an empty dict, like the locator stripped all information about classes at all.
In general, it doesn't matter how I get the handle of this element, I always get an empty dict on evaluate("node => node.className").
Calling page.locator(".status-marker").first.is_visible() returns True, so the object exists.
Also if I run page.locator(".status-marker").first.evaluate("node => node.outerHTML") I'll get the full HTML of that node, that does have the class name included. I could parse that, but it would be pretty clunky solution.
I found out that I could use expect(locator).to_have_class(), but If the node has more than one class I need to put all of them for it to pass, when I care only on one of them (the other classes are dynamically generated, so I can't even know about them during tests).
Edit:
Here's some additional sample:
assert page.locator(".marker").first.evaluate("node => node.className") == {}
expect(page.locator(".marker").first).to_have_class("text-green-1")
The first assert passes - the evaluate("node => node.className") returns an empty dict. The expect() fails with the following error:
AssertionError: Locator expected to have class 'text-green-1'
E Actual value: inline pr-2 text-green-1 marker svelte-fa s-z-WEjw8Gh1FG
I've found a way to reproduce it (it happens to me in font awesome plugin for svelte):
def test_svelte_fa(page):
page.goto("https://cweili.github.io/svelte-fa/")
item = page.locator(".svelte-fa").first
assert item.is_visible()
assert "svelte-fa" in item.evaluate("node => node.className")
In your example, the className of an SVG is an SVGAnimatedString object. Which is not serializable.
If you do JSON.stringify($('.svelte-fa').className) on the browser, you will see that the value is {}.
Values returned by the evaluate function needs to be serializable.
The wiktionary entry for faint lies at https://en.wiktionary.org/wiki/faint
The wikitext for the etymology section is:
From {{inh|en|enm|faynt}}, {{m|enm|feynt||weak; feeble}}, from
{{etyl|fro|en}} {{m|fro|faint}}, {{m|fro|feint||feigned; negligent;
sluggish}}, past participle of {{m|fro|feindre}}, {{m|fro|faindre||to
feign; sham; work negligently}}, from {{etyl|la|en}}
{{m|la|fingere||to touch, handle, usually form, shape, frame, form in
thought, imagine, conceive, contrive, devise, feign}}.
It contains various templates of the form {{xyz|...}}
I would like to parse them and get the text output as it shows on the page:
From Middle English faynt, feynt (“weak; feeble”), from Old French
faint, feint (“feigned; negligent; sluggish”), past participle of
feindre, faindre (“to feign; sham; work negligently”), from Latin
fingere (“to touch, handle, usually form, shape, frame, form in
thought, imagine, conceive, contrive, devise, feign”).
I have about 10000 entries extracted from the freely available dumps of wiktionary here.
To do this, my thinking is to extract templates and their expansions (in some form). To explore the possibilites I've been fiddling with the lua scripting facility on mediawiki. By trying various queries inside the debug console on edit pages of modules, like here:
https://en.wiktionary.org/w/index.php?title=Module:languages/print&action=edit
mw.log(p)
>> table
mw.logObject(p)
>> table#1 {
["code_to_name"] = function#1,
["name_to_code"] = function#2,
}
p.code_to_name("aaa")
>>
p.code_to_name("ab")
>>
But, I can't even get the function calls right. p.code_to_name("aaa") doesn't return anything.
The code that presumably expands the templates for the etymology section is here:
https://en.wiktionary.org/w/index.php?title=Module:etymology/templates
How do I call this code correctly?
Is there a simpler way to achieve my goal of parsing wikitext templates?
Is there some function available in mediawiki that I can call like "parse-wikitext("text"). If so, how do I invoke it?
To expand templates (and other stuff) in wikitext, use frame.preprocess, which is called as a method on a frame object. To get a frame object, use mw.getCurrentFrame. For instance, type = mw.getCurrentFrame():preprocess('{{l|en|word}}') in the console to get the wikitext resulting from {{l|en|word}}. That currently gives <span class="Latn" lang="en">[[word#English|word]]</span>.
You can also use the Expandtemplates action in the MediaWiki API ( https://en.wiktionary.org/w/api.php?action=expandtemplates&text={{l|en|word}}), or the Special:ExpandTemplates page, or JavaScript (if you open the browser console while browsing a Wiktionary page):
new mw.Api().get({
action: 'parse',
text: '{{l|en|word}}',
title: mw.config.values.wgPageName,
}).done(function (data) {
const wikitext = data.parse.text['*'];
if (wikitext)
console.log(wikitext);
});
If the mw.api library hasn't already been loaded and you get a TypeError ("mw.Api is not a constructor"):
mw.loader.using("mediawiki.api", function() {
// Use mw.Api here.
});
So these are some of the ways to expand templates.
I would like to create a keybinding to switch focus to the master client. Profjim on this forum thread notes:
To get the master client on the current tag:
c = awful.client.getmaster()
I have tried the following, but it causes my ~/.config/rc.lua file to be ignored, which is the behavior if there is an error in the file. Does anyone know the correct syntax?
awful.key({ modkey, , "e", awful.client.getMaster()),
Note: "e" shouldn't cause any conflicts if you have the default key bindings.
Edit: Someone on /r/awesomewm knew the syntax to solve my problem:
awful.key({ modkey, }, "e", function() client.focus = awful.client.getmaster(); client.focus:raise() end),
Lets start with the syntax errors; from the documentation it seems that awful.key is a table, not a function. and it would presumably contain keys...which are hash tables, not sequences.
Finally your table syntax is wrong; a field may not be syntactically empty, it must have a listed value, even if that value is nil.
So basically you are trying to pass the wrong kind of value to something that can't be called.
As for how to do it correctly...the documentation is confusing, and apparently I'm not the only one that thinks so.
*deep breath*
okay, awful.new(...) creates key binders(?), and awful.key contains key bindings, so clearly we have to put the results of the first into the second.
the code on your link is but a pointer, and only covers focusing the window, not creating a keybinding.
It seems like you want something like this:
function do_focus()
current = client.focus
master = awful.client.getmaster()
if current then
client.focus = master
master:raise()
end
end
table.insert(awful.key, awful.new (modkey, 'e', nil, do_focus) )
Bare in mind that I have no way of testing the above code.
My understanding is that inside of a coffeescript function, "this" or "#" is equal to "window" (at least in the context of Rails). Why is it then that I can get this code to work:
window.googletag = window.googletag or {}
window.googletag.cmd = window.googletag.cmd or []
window.googletag.cmd.push ->
window.googletag.defineSlot('/1003175/ad-name-here', [336, 280], 'div-gpt-ad-1349373630997-0').addService(window.googletag.pubads())
window.googletag.pubads().enableSingleRequest()
window.googletag.enableServices()
but not this code
#googletag = #googletag or {}
#googletag.cmd = #googletag.cmd or []
#googletag.cmd.push ->
#googletag.defineSlot('/1003175/ad-name-here', [336, 280], 'div-gpt-ad-1349373630997-0').addService(#googletag.pubads())
#googletag.pubads().enableSingleRequest()
#googletag.enableServices()
When I place in my code alert(# == window) I get true.. if they are the same then why would one work but not the other? Is there not a more graceful way to write this code then appending window to every instance of the word googletag?
In coffeescript, the # is equivalent to this, but the value of this is dependent on your current scope within the code. In your example, alert(# == window) returns true because in that context this is the window. But when you use it in another context, for example inside a function definition (#googletag.cmd.push -> ...) then it will get the context of whatever scope that function is called from.
In the end this is not a coffeescript issue but a Javascript issue. I'd recommend reading up a bit more on this, it's a somewhat confusing concept at first.
Here's one article that helped me understand the concept better: http://yehudakatz.com/2011/08/11/understanding-javascript-function-invocation-and-this/
I'm generating some (non-html) documentation for a Lua library that I developed. I will generate the documentation by hand, but I'd appreciate some kind of automation if possible (i.e. generating skeletons for each function so I can fill them in)
I'd like to know if there's a way for lua to know the names of the parameters that a function takes, from outside it.
For example, is there a way to do this in Lua?
function foo(x,y)
... -- any code here
end
print( something ... foo ... something)
-- expected output: "x", "y"
Thanks a lot.
ok,here is the core code:
function getArgs(fun)
local args = {}
local hook = debug.gethook()
local argHook = function( ... )
local info = debug.getinfo(3)
if 'pcall' ~= info.name then return end
for i = 1, math.huge do
local name, value = debug.getlocal(2, i)
if '(*temporary)' == name then
debug.sethook(hook)
error('')
return
end
table.insert(args,name)
end
end
debug.sethook(argHook, "c")
pcall(fun)
return args
end
and you can use like this:
print(getArgs(fun))
Try my bytecode inspector library. In Lua 5.2 you'll be able to use debug.getlocal.
Take a look at debug.getinfo, but you probably need a parser for this task. I don't know of any way to fetch the parameters of a function from within Lua without actually running the function and inspecting its environment table (see debug.debug and debug.getlocal).
function GetArgs(func)
local args = {}
for i = 1, debug.getinfo(func).nparams, 1 do
table.insert(args, debug.getlocal(func, i));
end
return args;
end
function a(bc, de, fg)
end
for k, v in pairs(GetArgs(a)) do
print(k, v)
end
will print
1 bc
2 de
3 fg
Basically we use debug.getinfo to retrieve the nparams attribute (which gives us the information of how many parameters the function takes) and debug.getlocal to access the name of the parameters.
Tested and working with Lua 5.4
Take a look at the luadoc utility. It is sort of like Doxygen, but for Lua. It is intended to allow the documentation to be written in-line with the source code, but it could certainly be used to produce a template of the documentation structure to be fleshed out separately. Of course, the template mechanism will leave you with a maintenance issue down the road...