How to change AwesomeWM tag names? - debugging

I am trying to customize my Awesome Window Manager to change the tag numbers into Roman numbers (changing 1 for I, 2 for II...). In order to achieve this, I am modifying my /etc/xdg/awesome/rc.lua file, specially the {{tags}} section.
I have found this blog post, in which he manages to edit the tag names at will, have a look at the top left corner:
I also read the rc.lua file attached to the theme, and realized the technique used for what I want to do is a for loop in combination with some tables.
This is the code snippet of interest in the file:
-- {{{ Tags
-- Define a tag table which hold all screen tags.
tags = {}
tagnames = { "irc", "mpd", "net", "usr", "png", "msg", }
taglayouts = {
awful.layout.suit.tile.top,
awful.layout.suit.tile.bottom,
awful.layout.suit.floating,
awful.layout.suit.fair,
awful.layout.suit.floating,
awful.layout.suit.floating }
for s = 1, screen.count() do
-- Each screen has its own tag table.
tags[s] = {}
for tagnumber = 1, 6 do
-- Add tags and name them.
tags[s][tagnumber] = tag(tagnames[tagnumber])
-- Add tags to screen one by one, giving them their layouts at the same time.
tags[s][tagnumber].screen = s
awful.layout.set(taglayouts[tagnumber], tags[s][tagnumber])
end
-- I'm sure you want to see at least one tag.
tags[s][1].selected = true
end
-- }}}
...and this is my rc.lua file:
-- {{{ Tags
-- Define a tag table which hold all screen tags.
tags = {}
tagnames = { "I", "II", "III", "IV", "V", "VI", "VII", "VIII", "IX", }
taglayouts = {
awful.layout.suit.tile.top,
awful.layout.suit.tile.bottom,
awful.layout.suit.floating,
awful.layout.suit.fair,
awful.layout.suit.floating,
awful.layout.suit.floating }
for s = 1, screen.count() do
-- Each screen has its own tag table.
-- tags[s] = awful.tag({ "1", "2", "3", "4", "5", "6", "7", "8",$
tags[s] = {}
for tagnumber = 1, 9 do
tags[s][tagnumber] = tag(tagnames[tagnumber])
tags[s][tagnumber].screen = s
awful.layout.set(taglayouts[tagnumber], tags[s][tagnumber])
end
tags[s][1].selected = true
end
--- }}}
As you can see, they are pretty the same, with the difference that I have nine tags instead of six (I changed the code according to it). When I try to debug the setup using Xephyr, an error appears in the console and I am only able to see my wallpaper:
error while running function
stack traceback:
[C]: in global 'tag'
/etc/xdg/awesome/rc.lua:100: in main chunk
error: /etc/xdg/awesome/rc.lua:100: bad argument #2 to 'tag' (table expected, got string)
error while running function
stack traceback:
[C]: in global 'tag'
/etc/xdg/awesome/rc.lua:100: in main chunk
error: /etc/xdg/awesome/rc.lua:100: bad argument #2 to 'tag' (table expected, got string)
E: awesome: main:605: couldn't find any rc file
I can't see where the error is, as I am not able to detect any language violation in the error line tags[s][tagnumber] = tag(tagnames[tagnumber]): it's just filling the tags array with my custom names, telling it to treat them as a tag and not as a random string.
UPDATE: I have just realized that there are six layouts in taglayouts, the same number as tags in the original Lua file. I think I should have nine tag layouts, but I don't know which one should I add. Also, I don't see this as a critical impediment for the code to compile properly, as the error line does not have anything to do with the layout list.
UPDATE 2: Added three more awful.layout.suit.floating to taglayouts. Same error.

Following another answer, I replaced my {Tags} section with:
-- {{{ Tags
-- Define a tag table which hold all screen tags.
tagnum = { "I", "II", "III", "IV", "V", "VI", "VII",
"VIII", "IX" }
for i = 1, 9 do
awful.tag.add((tagnum[i]), {
layout = awful.layout.suit.tile,
master_fill_policy = "master_width_factor",
gap_single_client = true,
gap = 15,
screen = s,
})
end
-- }}}
This creates i number of tags, their name defined in the tagnum table. This is only useful if you want to create identical tags, but it will always be much cleaner than having to type i definitions.
A MUCH BETTER, CLEANER WAY:
The initial solution was useful, but it had a problem: when starting AwesomeWM, you won't appear in a defined tag, but in all of them at the same time. That is, if you open a terminal, you will open it in every tag you have unless you previously selected one with Mod4+TagNum (following default conf.).
Trying to solve this problem, I compared the default configuration file with the modded one, and I realized it all worked well in the default one. So I started modifying the code in order to find a solution. In all, I have discovered that with a minimal modification of the default code you are able to customize your tag names at will. This is how I did it:
-- {{{ Tags
tags = {}
-- Generates tags with custom names
for s = 1, screen.count() do
tags[s] = awful.tag({ "I", "II", "III", "IV", "V", "VI", "VII", "IX" }),
end
-- }}}
P.S. I keep the old solution in case someone would wish to use the code for another purpose.

Not an official answer yet, but yesterday I wrote more doc about this:
https://github.com/awesomeWM/awesome/pull/1279/files#diff-df495cc7fcbd48cd2698645bca070ff9R39
It is for Awesome 4.0, but in this case not much changed, so the example is almost valid (the gap property is not available in 3.4/3.5).
Also, if you wish to setup complex tags, I would suggest my Tyrannical module (Awesome 3.5+) or Shifty (Awesome 3.2-3.4). It is designed to make this much easier.

Related

Access variable hash depth values with square brackets notation

Given this hash:
hash1= { node1: { node2: { node3: { node4: { node5: 1 } } } } }
We access inside nodes with square brackets like this:
hash1[:node1][:node2][:node3][:node4]
Now I have a hash that I know will always be nested as it is an XML response from a SOAP webservice, but neither the depth of the hash nor the names of the nodes stay the same. So it would be nice if I could ask the user of my application for the hash depth and store it in a variable. And then be able to do hash1[:hash_depth] and achieve the same result as above.
I have accomplished what I want by the following code:
str = 'node1,node2,node3,node4'
str_a = str.split(',')
hash_copy = hash1
str_a.each { |s| hash_copy = hash_copy.[](s.to_sym) }
hash_copy
=> {:node5=>1}
hash1[:node1][:node2][:node3][:node4]
=> {:node5=>1}
that is asking the user to enter the hash depth separated by commas, store it in a string, split it, make an array, clone the original hash, go down each level and modify the hash till I get to the desired node. Is there a way to do it with the square brackets notation and using a variable to store the depth without modifying the hash or needing to clone it?
Edit:
someone answered with the following (can't see his post anymore???)
hash_depth="[:node1][:node2][:node3][:node4]"
eval "hash1#{hash_depth}"
Although eval does everything you need, there is another approach, since you already have the working code for comma-separated list:
hash_depth="[:node1][:node2][:node3][:node4]"
csh = hash_depth.gsub(/\A\[:|\]\[:|\]\Z/, { '][:' => ',' })
#⇒ "node1,node2,node3,node4"
And now you are free to apply your existing function to csh.
If this is a webapp, I think you should prepare a list of short textareas, which starts with a single text item, and the user can keep adding a new item to the list by clicking on a button. The areas will be filled by the user, and will be sent.
Then, you will probably receive this through some serialized form. You decode this to get an array of strings:
str_a = ["node1", "node2", "node3", "node4"]
and you can reach the inner element by doing:
str_a.inject(hash1){|h, s| h[s.to_sym]} #=> {:node5 => 1}

Specifying styles for portions of a PyYAML dump

I'm using YAML for a computer and human-editable and readable input format for a simulator. For human readability, some parts of the input are mostly amenable to block style, while flow style suits others better.
The default for PyYAML is to use block style wherever there are nested maps or sequences, and flow style everywhere else. *default_flow_style* allows one to choose all-flow-style or all-block-style.
But I'd like to output files more of the form
bonds:
- { strength: 2.0 }
- ...
tiles:
- { color: red, edges: [1, 0, 0, 1], stoic: 0.1}
- ...
args:
block: 2
Gse: 9.4
As can be seen, this doesn't follow a consistent pattern for styles throughout, and instead changes depending upon the part of the file. Essentially, I'd like to be able to specify that all values in some block style sequences be in flow style. Is there some way to get that sort of fine-level control over dumping? Being able to dump the top-level mapping in a particular order while not requiring that order (eg, omap) would be nice as well for readability.
It turns out this can be done by defining subclasses with representers for each item I want not to follow default_flow_style, and then converting everything necessary to those before dumping. In this case, that means I get something like:
class blockseq( dict ): pass
def blockseq_rep(dumper, data):
return dumper.represent_mapping( u'tag:yaml.org,2002:map', data, flow_style=False )
class flowmap( dict ): pass
def flowmap_rep(dumper, data):
return dumper.represent_mapping( u'tag:yaml.org,2002:map', data, flow_style=True )
yaml.add_representer(blockseq, blockseq_rep)
yaml.add_representer(flowmap, flowmap_rep)
def dump( st ):
st['tiles'] = [ flowmap(x) for x in st['tiles'] ]
st['bonds'] = [ flowmap(x) for x in st['bonds'] ]
if 'xgrowargs' in st.keys(): st['xgrowargs'] = blockseq(st['xgrowargs'])
return yaml.dump(st)
Annoyingly, the easier-to-use dumper.represent_list and dumper.represent_dict don't allow flow_style to be specified, so I have to specify the tag, but the system does work.

Displaying Docbook section titles in TextMate's function popup

I'm working on a bundle for DocBook 5 XML, which frequently includes content like:
<section>
<title>This is my awesome Java Class called <classname>FunBunny</classname></title>
<para>FunBunny is your friend.</para>
</section>
I want the titles for sections to appear in the function popup at the bottom of the window. I have this partially working using the following bundle items.
Language Grammar:
{ patterns = (
{ name = 'meta.tag.xml.docbook5.title';
match = '<title>(.*?)</title>';
/* patterns = ( { include = 'text.xml'; } ); */
},
{ include = 'text.xml'; },
);
}
Settings/Preferences Item with scope selector meta.tag.xml.docbook5.title:
{ showInSymbolList = 1;
symbolTransformation = 's/^\s*<title\s?.*?>\s*(.*)\s*<\/title>/$1/';
}
The net effect of this is that all title elements in the document are matched and appear in the function popup, excluding the <title></title> tag content based on the symbolTransformation.
I would be happy with this much functionality, since other interesting things (like figures) tend to have formal titles, but there is one issue.
The content of the title tags is not parsed and recognized according to the rest of the text.xml language grammar. The commented-out patterns section in the above language grammar does not have the desired effect of fixing this issue -- it puts everything into the meta.tag.xml.docbook5.title scope.
Is there a way to get what I want here? That is, the content of the title elements, optionally just for section titles, in the function popup and recognized as normal XML content by the parser.
In TextMate grammars you need to use the begin/end type rules instead of match type rules, if you want to 'match within a match'. (You can actually use a match as well, but then you need to use currently undocumented behavior, available only for TextMate 2)
{ patterns = (
{ name = 'meta.tag.xml.docbook5.title';
begin = '<title>';
end = '</title>';
patterns = ( { include = 'text.xml'; } );
},
{ include = 'text.xml'; },
);
}
This has the added benefit of allowing <title>...</title> that span more than one line.

Read image IPTC data

I'm having some trouble with reading out the IPTC data of some images, the reason why I want to do this, is because my client has all the keywords already in the IPTC data and doesn't want to re-enter them on the site.
So I created this simple script to read them out:
$size = getimagesize($image, $info);
if(isset($info['APP13'])) {
$iptc = iptcparse($info['APP13']);
print '<pre>';
var_dump($iptc['2#025']);
print '</pre>';
}
This works perfectly in most cases, but it's having trouble with some images.
Notice: Undefined index: 2#025
While I can clearly see the keywords in photoshop.
Are there any decent small libraries that could read the keywords in every image? Or am I doing something wrong here?
I've seen a lot of weird IPTC problems. Could be that you have 2 APP13 segments. I noticed that, for some reasons, some JPEGs have multiple IPTC blocks. It's possibly the problem with using several photo-editing programs or some manual file manipulation.
Could be that PHP is trying to read the empty APP13 or even embedded "thumbnail metadata".
Could be also problem with segments lenght - APP13 or 8BIM have lenght marker bytes that might have wrong values.
Try HEX editor and check the file "manually".
I have found that IPTC is almost always embedded as xml using the XMP format, and is often not in the APP13 slot. You can sometimes get the IPTC info by using iptcparse($info['APP1']), but the most reliable way to get it without a third party library is to simply search through the image file from the relevant xml string (I got this from another answer, but I haven't been able to find it, otherwise I would link!):
The xml for the keywords always has the form "<dc:subject>...<rdf:Seq><rdf:li>Keyword 1</rdf:li><rdf:li>Keyword 2</rdf:li>...<rdf:li>Keyword N</rdf:li></rdf:Seq>...</dc:subject>"
So you can just get the file as a string using file_get_contents(get_attached_file($attachment_id)), use strpos() to find each opening (<rdf:li>) and closing (</rdf:li>) XML tag, and grab the keyword between them using substr().
The following snippet works for all jpegs I have tested it on. It will fill the array $keys with IPTC tags taken from an image on wordpress with id $attachment_id:
$content = file_get_contents(get_attached_file($attachment_id));
// Look for xmp data: xml tag "dc:subject" is where keywords are stored
$xmp_data_start = strpos($content, '<dc:subject>') + 12;
// Only proceed if able to find dc:subject tag
if ($xmp_data_start != FALSE) {
$xmp_data_end = strpos($content, '</dc:subject>');
$xmp_data_length = $xmp_data_end - $xmp_data_start;
$xmp_data = substr($content, $xmp_data_start, $xmp_data_length);
// Look for tag "rdf:Seq" where individual keywords are listed
$key_data_start = strpos($xmp_data, '<rdf:Seq>') + 9;
// Only proceed if able to find rdf:Seq tag
if ($key_data_start != FALSE) {
$key_data_end = strpos($xmp_data, '</rdf:Seq>');
$key_data_length = $key_data_end - $key_data_start;
$key_data = substr($xmp_data, $key_data_start, $key_data_length);
// $ctr will track position of each <rdf:li> tag, starting with first
$ctr = strpos($key_data, '<rdf:li>');
// Initialize empty array to store keywords
$keys = Array();
// While loop stores each keyword and searches for next xml keyword tag
while($ctr != FALSE && $ctr < $key_data_length) {
// Skip past the tag to get the keyword itself
$key_begin = $ctr + 8;
// Keyword ends where closing tag begins
$key_end = strpos($key_data, '</rdf:li>', $key_begin);
// Make sure keyword has a closing tag
if ($key_end == FALSE) break;
// Make sure keyword is not too long (not sure what WP can handle)
$key_length = $key_end - $key_begin;
$key_length = (100 < $key_length ? 100 : $key_length);
// Add keyword to keyword array
array_push($keys, substr($key_data, $key_begin, $key_length));
// Find next keyword open tag
$ctr = strpos($key_data, '<rdf:li>', $key_end);
}
}
}
I have this implemented in a plugin to put IPTC keywords into WP's "Description" field, which you can find here.
ExifTool is very robust if you can shell out to that (from PHP it looks like?)

no implicit conversion from nil to integer - when trying to add anything to array

I'm trying to build a fairly complex hash and I am strangely getting the error
no implicit conversion from nil to integer
when I use the line
manufacturer_cols << {:field => 'test'}
I use the same line later in the same loop, and it works no problem.
The entire code is
manufacturer_cols=[]
manufacturer_fields.each_with_index do |mapped_field, index|
if mapped_field.base_field_name=='exactSKU'
#this is where it is breaking, if I comment this out, all is good
manufacturer_cols << { :base_field=> 'test'}
else
#it works fine here!
manufacturer_cols << { :base_field=>mapped_field.base_field_name }
end
end
------- value of manufacturer_fields --------
[{"base_field":{"base_field_name":"Category","id":1,"name":"Category"}},{"base_field":{"base_field_name":"Description","id":3,"name":"Short_Description"}},{"base_field":{"base_field_name":"exactSKU","id":5,"name":"Item_SKU"}},{"base_field":{"base_field_name":"Markup","id":25,"name":"Retail_Price"}},{"base_field":{"base_field_name":"Family","id":26,"name":"Theme"}}]
Implicit Conversion Errors Explained
I'm not sure precisely why your code is getting this error but I can tell you exactly what the error means, and perhaps that will help.
There are two kinds of conversions in Ruby: explicit and implicit.
Explicit conversions use the short name, like #to_s or #to_i. These are commonly defined in the core, and they are called all the time. They are for objects that are not strings or not integers, but can be converted for debugging or database translation or string interpolation or whatever.
Implicit conversions use the long name, like #to_str or #to_int. This kind of conversion is for objects that are very much like strings or integers and merely need to know when to assume the form of their alter egos. These conversions are never or almost never defined in the core. (Hal Fulton's The Ruby Way identifies Pathname as one of the classes that finds a reason to define #to_str.)
It's quite difficult to get your error, even NilClass defines explicit (short name) converters:
nil.to_i
=> 0
">>#{nil}<<" # this demonstrates nil.to_s
=> ">><<"
You can trigger it like so:
Array.new nil
TypeError: no implicit conversion from nil to integer
Therefore, your error is coming from the C code inside the Ruby interpreter. A core class, implemented in C, is being handed a nil when it expects an Integer. It may have a #to_i but it doesn't have a #to_int and so the result is the TypeError.
This seems to have been completely unrelated to anything that had anything to do with manufacturer_cols after all.
I had arrived at the manufacturer_cols bit because if I commented that out, it ran fine.
However, if I commented out the part where I ran through the csv further down the page, it ran fine also.
It turns out the error was related to retrieving attempting to append the base_field when it was nil.
I thought I could use
manufacturer_cols.each do |col|
base_value = row[col[:row_index].to_i]
if col[:merges]
col[:merges].each do |merge|
base_value += merge[:separator].to_s + row[merge[:merge_row_index]]
end
end
end
unfortunately, that caused the error. the solution was
base_value = base_value + merge[:separator].to_s + row[merge[:merge_row_index]]
I hope this helps somebody, 'cause as DigitalRoss alluded to, it was quite a wild goose chase nailing down where in the code this was being caused and why.
I got this error when parsing through an API for "tag/#{idnum}/parents"...Normally, you'd expect a response like this:
{
"parents": [
{
"id": 8,
"tag_type": "MarketTag",
"name": "internet",
"display_name": "Internet",
"angellist_url": "https://angel.co/internet",
"statistics": {
"all": {
"investor_followers": 1400,
"followers": 5078,
"startups": 13214
},
"direct": {
"investor_followers": 532,
"followers": 1832,
"startups": 495
}
}
}
],
"total": 1,
"per_page": 50,
"page": 1,
"last_page": 1
}
but when I looked up the parents of the market category "adult" (as it were), I got this
{
"parents": [ ],
"total": 0,
"per_page": 50,
"page": 1,
"last_page": 0
}
Now ruby allowed a number of interactions with this thing to occur, but eventually it threw the error about implicit conversion
parents.each do |p|
stats = p['statistics']['all']
selector << stats['investor_followers'].to_i
end
selected = selector.index(selector.max)
parents[selected]['id'] ***<--- CODE FAILED HERE
end
This was a simple fix for me.
When I was getting this error using the Scout app, one of my mapped folders was header-1, when I removed the hyphen from the folder name and made it header1, the error went away.
It didn't like the hyphen for some reason...

Resources