file not found - tags.yaml

[jpablobr]

Hi, I'm new to wmii and wmiirc and I'm getting the following error:

https://gist.github.com/1554351

The rest seems to work fine if I comment out tags.yaml in my config.yaml:

https://github.com/jpablobr/wmiirc/blob/personal/config.yaml

I'm I missing something obvious? :/ I build wmii from:

http://hg.suckless.org/wmii/rev/f3d88385ea7c

$ ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [i686-linux]

$ gem list
*** LOCAL GEMS ***
barometer (0.7.3)
bundler (1.0.21 ruby)
httparty (0.8.1)
kwalify (0.7.2)
librmpd (0.1.1)
multi_json (1.0.4)
multi_xml (0.4.1)
nokogiri (1.5.0)
rake (0.9.2)
rumai (4.1.3)
tzinfo (0.3.31)

$ uname -a
Linux dell-17 3.1.5-1-ARCH #1 SMP PREEMPT Sun Dec 11 06:26:14 UTC 2011 i686 Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz GenuineIntel GNU/Linux

[sunaku]

I noticed you're building wmii from the suckless hg, which is out of date. Try the googlecode mirror instead.

[jpablobr]

Same problem with:

hg clone https://code.google.com/p/wmii/

I updated my previews gist to include the build output:

https://gist.github.com/1554351/efaaddb1224ef956f0b0d8ccdf12217bf28e749d#file_wmii_build.log

I also had to change the PYTHON var in wmii config.mk to:

PYTHON = python2

https://gist.github.com/1554351/efaaddb1224ef956f0b0d8ccdf12217bf28e749d#L569

kind of a known issue in Arch Linux.

What I did notice though, was like a general performance boost! no sure...

[sunaku]

Hmm, what about libixp? Are you building that from the googlecode mirror also?

Regarding the perf boost, it might just be the internal improvements in Ruby 1.9.3.

[jpablobr]

I believe I built from http://libs.suckless.org/libixp, so now I tried with the google one. The following is the output:

https://gist.github.com/1554351/fd96043b3261db8b66d1640821591d77473836ca#file_libixp_from_google_code_build.log

and this is wmii's current error log when I uncomment tags.yaml:

https://gist.github.com/1554351/fd96043b3261db8b66d1640821591d77473836ca#file_wmii.log

[sunaku]

Sorry to ask you about the compilation again but wmii needs to be rebuilt with your new libixp. Try following these instructions completely.

By the way, when you comment-out the tags.yaml, does your status bar still work correctly? Clicks and all?

[sunaku]

And a temporary solution would be to add rescue nil to the end of the line that's causing the error.

[jpablobr]

Np, here is the new output:

https://gist.github.com/1554351#file_libixp_and_wmii_build.log

$ wmii -v
wmii-hg2811+, ©2010 Kris Maglione

And yes, when I comment-out tags.yaml everything kind of works fine... I can even "sort of" use the tags like; if I hit MOD4-3, it seems to switch me to my "tag 3 space"... again, not sure :D (the status bar is not displaying the tags) but if I then hit MOD4-1 it will switch me back to my "tag 1 space".

I'm now testing a simple status item I'm building which seems to be working fine as well. :)

Finally, the resque nil did work as a temp fix. Here is my last commit to my wmii configs which has the resque nil and the simple status item I built.

https://github.com/jpablobr/wmiirc/commit/00532a5fcc6dee649bc2366adec13dbd4477c0c9

[jpablobr]

I was testing your rumai lib by following the USAGE document:

https://github.com/sunaku/rumai/blob/master/USAGE

and again, most of it works fine, but some of the tag related stuff was blowing out. I added that log to my previews gist. Also in the red.untag "bar" code example section I got the following wmiirc rescue message:

https://gist.github.com/1554351#file_red_untag_bar_section_message.log

P.S mind = blowend :)

[sunaku]

Thanks for reporting those errors, I'll look into it this weekend. I haven't updated that tutorial in a long time, so it may have outdated instructions or examples. By the way, that USAGE document is also available in a web-friendly format.

[sunaku]

Thanks for reporting the bugs in Rumai documentation. The red.next bug was an actual bug in my non-released (present on github, but not released as gem yet) code. The push terms was incorrect usage in the tutorial: it doesn't make sense to push an array does it? And the bar button example was just an updated file format in newer wmii versions. I have pushed the fixes accordingly. Cheers.

[ghedamat]

Hi sunaku! Always ghedamat here :)

As usual one or twice a year I upgrade my local wmiirc conf to your master branch :)

this time I've noticed quite a lot of changes so I've decided to pull directly your master branch and your personal config to give it a try and I've occurred in a problem similar to jpablobr's...

https://gist.github.com/1611534

In this Gist you can find wmiirc.log.1 that contains the error raised when I first launch wmii

adding a couple of rescue nil as jpablobr did leads to wmiirc.log.2 when I try to change view.

In both cases the /lbar does not contains any tag to see or click..

I've also updated to last wmii (patched) and libixp as you suggested in this Issue

so i'm running

wmii-hg2811+, ©2010 Kris Maglione

and 

rumai 4.1.3

Not sure of what's happening here, my fault as I never had the time to dig deeper in rumai and try to understand its internals a bit better...

Hope that you can help me as you've always did, I the meanwhile I'll try to dig a bit too and I hope to be of some sort of help :D

Many thanks as usual!

Ghedamat

[sunaku]

I wonder why there's no error on my system. Maybe you are launching different apps at startup? Please post your .xinitrc file also; here is mine for comparison.

[jpablobr]

I was actually trying to debug this the other day without much success... However, the following is what I've found (I might be completely wrong though :D).

Basically, it seems like Rumai is not being able to generate the correct Rumai::IXP type. When Rumai::IXP::Agent#recv tries to set the msg via msg = Fcall.from_9p(@stream) which then will call Rumai::IXP::Fcall#from_9p and which in turn (and based on the provided @stream) requests Rumai::IXP::Struct#from_9p for a proper Rumai::IXP type. It is actually returning an exception since the Rumai::IXP type is getting is a Rumai::IXP::Rerror.

That's just based on the stack trace... However, and here is where I'm really confused, I notice that this Rumai::IXP::Rerror only occurs when Rumai::IXP::Agent#recv tag variable is =4 and the Rumai::IXP::Fcall#from_9p size and type variables set to 23 and 107 (which is the Rumai::IXP::Fcall::CLASS_TO_TYPE Rerror) respectively.

So again, seems like Rumai is not being able to generate the proper primitives out of the 9P2000 protocol (I guess... :/). Here is the log file I was using (with a bunch of DBG: puts statements). Maybe @sunaku will be able to make more sense out of it.

And my ~/.xinitrc :)

[ghedamat]

My .xinitrc is REALLY simple,

here you are

xmodmap .Xmodmap
xinput set-int-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation" 8 1
xinput set-int-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation Button" 8 2
xinput set-int-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation Axes" 8 6 7 4 5

/home/tha/.dropbox-dist/dropbox &
# launch wmii ( no loop )
exec /usr/local/bin/wmii -r /home/tha/.wmii/wmiirc

[sunaku]

Thanks for debugging @jpablobr. I ran Rumai's test suite and noticed that many tests fail due to 107 (Rerror) responses. Something must have changed in the wmii codebase itself to break things.

[ghedamat]

Mmm, don't know if it can be helpful but @sunaku notice that I was having the same error also using an older version of wmii ( don't remember exactly but was around r2750) installed last summer, and also last rumai version is working perfectly with my old wmiirc using both old and newest wmii

[sunaku]

Thanks for clarifying @ghedamat. I'm debugging the issue now, seems like a fid allocation problem in Rumai.

[ghedamat]

Also, I've just cloned git version of rumai and all tests seems to pass here (?)

pass: 57
time: 0.178013578

[sunaku]

You're right. I'm converting the test suite to use minitest and it fails there. Sigh, I don't know anymore. Maybe it's time to break away from the computer and enjoy the weekend? :P

[ghedamat]

maybe you're right :) also because here it's 3.00 in the morning :D time to go to bed :P

I'll back on this tomorrow :)

[sunaku]

I got the test suite working again under minitest/spec and pushed it to Rumai. Anyway, @ghedamat is right about that not being the issue. But it's hard to debug the issue when I can't reproduce it on my system.

Try adding the following lines to the top of your CreateTag handler in display/tags.yaml:

lbar = Rumai.fs.lbar
p lbar: lbar
p exist: lbar.exist?
p entries: lbar.entries
test = lbar.testing123
p test: test
p exist: test.exist?
p create: test.create
p exist: test.exist?
p write: test.write("label testing 123\n")
p remove: test.remove
p exist: test.exist?

Let's see what you get on your systems. The output should appear in the log file.

[jpablobr]

This is what I get:

{:lbar=>#<Rumai::Node:0x932baf0 @path="/lbar">}
{:exist=>true}
{:entries=>[]}
{:test=>#<Rumai::Node:0x94b94d0 @path="/lbar/testing123">}
{:exist=>false}
{:create=>#<Rumai::IXP::Rcreate:0x94c6a7c @fields=[#<Rumai::IXP::Struct::Field:0x8e12e60 @name=:tag, @format=2, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::ClassField:0x8e02e98 @name=:qid, @format=Rumai::IXP::Qid, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Field:0x8e02268 @name=:iounit, @format=4, @countee=nil, @counter=nil>], @values={:tag=>9, :qid=>#<Rumai::IXP::Qid:0x94c6a2c @fields=[#<Rumai::IXP::Struct::Field:0x8e18b80 @name=:type, @format=1, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Field:0x8e18644 @name=:version, @format=4, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Integer8Field:0x8e18158 @name=:path, @format=8, @countee=nil, @counter=nil>], @values={:type=>0, :version=>0, :path=>30064771074}>, :iounit=>8168}>}
{:exist=>true}
{:write=>nil}
{:remove=>#<Rumai::IXP::Rremove:0x94c3ac0 @fields=[#<Rumai::IXP::Struct::Field:0x8e12e60 @name=:tag, @format=2, @countee=nil, @counter=nil>], @values={:tag=>0}>}
{:exist=>false}

[sunaku]

Thanks @jpablobr. So the very first time CreateTag is called, the lbar is indeed empty. This proves the fs.lbar.clear line is working. What about the rest of the CreateTag handler? Does it still raise the error if you remove the rescue nil workaround?

[jpablobr]

Yes, it still raises an error, however this one is a bit different (see below). What's really weird is that you can't reproduce it, and I even installed it on a different computer and got the same behavior o.O

I just pushed my current configuration to github in case you also want to check that out (I also ran a make rumai before commenting-out the resque nil).

Actually I was thinking, that maybe for the future it would be nice to set up like a Vagrant box (with a working version) just so everybody can use it as a reference. Might make thing easier to troubleshoot.

I, [2012-01-15T20:17:04.271457 #10089]  INFO -- : Lost connection to wmii.  Attempting to reconnect...
I, [2012-01-15T20:17:04.271510 #10089]  INFO -- : reload
I, [2012-01-15T20:17:04.273583 #10089]  INFO -- : stop
I, [2012-01-15T20:17:07.199466 #2001]  INFO -- : start
{:lbar=>#<Rumai::Node:0xa6806b4 @path="/lbar">}
{:exist=>true}
{:entries=>[]}
{:test=>#<Rumai::Node:0xa30041c @path="/lbar/testing123">}
{:exist=>false}
{:create=>#<Rumai::IXP::Rcreate:0xa324650 @fields=[#<Rumai::IXP::Struct::Field:0x9dd9dd0 @name=:tag, @format=2, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::ClassField:0x9dc9cdc @name=:qid, @format=Rumai::IXP::Qid, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Field:0x9dc8f58 @name=:iounit, @format=4, @countee=nil, @counter=nil>], @values={:tag=>9, :qid=>#<Rumai::IXP::Qid:0xa324600 @fields=[#<Rumai::IXP::Struct::Field:0x9ddfb18 @name=:type, @format=1, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Field:0x9ddf5c8 @name=:version, @format=4, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Integer8Field:0x9ddf0dc @name=:path, @format=8, @countee=nil, @counter=nil>], @values={:type=>0, :version=>0, :path=>30064771074}>, :iounit=>8168}>}
{:exist=>true}
{:write=>nil}
{:remove=>#<Rumai::IXP::Rremove:0xa321694 @fields=[#<Rumai::IXP::Struct::Field:0x9dd9dd0 @name=:tag, @format=2, @countee=nil, @counter=nil>], @values={:tag=>0}>}
{:exist=>false}
E, [2012-01-15T20:17:07.666740 #2001] ERROR -- : file not found -- in reply to #<Rumai::IXP::Twalk:0xa70af80 @fields=[#<Rumai::IXP::Struct::Field:0x9dd9dd0 @name=:tag, @format=2, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Field:0x9dd3278 @name=:fid, @format=4, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Field:0x9dd29f4 @name=:newfid, @format=4, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Field:0x9dd238c @name=:nwname, @format=2, @countee=#<Rumai::IXP::Struct::ClassField:0x9dd1b80 @name=:wname, @format=String, @countee=nil, @counter=#<Rumai::IXP::Struct::Field:0x9dd238c ...>>, @counter=nil>, #<Rumai::IXP::Struct::ClassField:0x9dd1b80 @name=:wname, @format=String, @countee=nil, @counter=#<Rumai::IXP::Struct::Field:0x9dd238c @name=:nwname, @format=2, @countee=#<Rumai::IXP::Struct::ClassField:0x9dd1b80 ...>, @counter=nil>>], @values={:fid=>0, :newfid=>6, :wname=>["lbar", "1"], :tag=>3}> (Rumai::IXP::Error)
/home/jpablobr/.wmii-hg/rumai/lib/rumai/ixp/transport.rb:158:in `block in recv'
/home/jpablobr/.wmii-hg/rumai/lib/rumai/ixp/transport.rb:121:in `loop'
/home/jpablobr/.wmii-hg/rumai/lib/rumai/ixp/transport.rb:121:in `recv'
/home/jpablobr/.wmii-hg/rumai/lib/rumai/ixp/transport.rb:176:in `talk'
/home/jpablobr/.wmii-hg/rumai/lib/rumai/ixp/transport.rb:452:in `walk_fid'
/home/jpablobr/.wmii-hg/rumai/lib/rumai/ixp/transport.rb:440:in `walk'
/home/jpablobr/.wmii-hg/rumai/lib/rumai/ixp/transport.rb:210:in `open'
/home/jpablobr/.wmii-hg/rumai/lib/rumai/ixp/transport.rb:376:in `write'
/home/jpablobr/.wmii-hg/rumai/lib/rumai/fs.rb:116:in `write'
/home/jpablobr/.wmii-hg/rumai/lib/rumai/wm.rb:1170:in `label='
/home/jpablobr/.wmii-hg/display/tags.yaml:script:before:4:in `initialize'
/home/jpablobr/.wmii-hg/display/tags.yaml:control:event:CreateTag:13:in `new'
/home/jpablobr/.wmii-hg/display/tags.yaml:control:event:CreateTag:13:in `block (3 levels) in control'
/home/jpablobr/.wmii-hg/lib/wmiirc/handler.rb:20:in `call'
/home/jpablobr/.wmii-hg/lib/wmiirc/handler.rb:20:in `block in handle'
/home/jpablobr/.wmii-hg/lib/wmiirc/handler.rb:19:in `each'
/home/jpablobr/.wmii-hg/lib/wmiirc/handler.rb:19:in `handle'
/home/jpablobr/.wmii-hg/lib/wmiirc/handler.rb:38:in `event'
/home/jpablobr/.wmii-hg/display/tags.yaml:script:after:3:in `block (2 levels) in script'
/home/jpablobr/.wmii-hg/display/tags.yaml:script:after:3:in `each'
/home/jpablobr/.wmii-hg/display/tags.yaml:script:after:3:in `block in script'
/home/jpablobr/.wmii-hg/lib/wmiirc/config.rb:38:in `instance_eval'
/home/jpablobr/.wmii-hg/lib/wmiirc/config.rb:38:in `block in script'
/home/jpablobr/.wmii-hg/lib/wmiirc/config.rb:37:in `each'
/home/jpablobr/.wmii-hg/lib/wmiirc/config.rb:37:in `script'
/home/jpablobr/.wmii-hg/lib/wmiirc/config.rb:17:in `apply'
/home/jpablobr/.wmii-hg/lib/wmiirc/loader.rb:118:in `load_user_config'
/home/jpablobr/.wmii-hg/lib/wmiirc/loader.rb:23:in `run'
/home/jpablobr/.wmii-hg/wmiirc:6:in `<main>'
I, [2012-01-15T20:17:22.790593 #2001]  INFO -- : stop

[niklas]

I currently have the same problem and I'm trying to debug it. What's the path of your XPI_SOCK_ADDR? is it set to ENV[WMII_ADDRESS] or the generic one in /tmp?

edit: does not matter, ignore this comment

[jpablobr]

Weird, I don't have anything regarding wmii or xpi in my env. If I do an $ env | grep -i xpi or for wmii would not return a thing.

the following is what I get if I do a p ENV in my tags.yaml (I removed some thing not very relevant):

{"SHELL"=>"/bin/bash", "TERM"=>"xterm", "GTK2_RC_FILES"=>"/etc/gtk-2.0/gtkrc:/home/jpablobr/.gtkrc-2.0", "QT_XFT"=>"true", "IRBRC"=>"/home/jpablobr/.rvm/rubies/ruby-1.9.3-p0/.irbrc", "WMII_CONFPATH"=>"/home/jpablobr/.wmii-hg:/usr/local/etc/wmii-hg", "HUSHLOGIN"=>"FALSE", "MY_RUBY_HOME"=>"/home/jpablobr/.rvm/rubies/ruby-1.9.3-p0", "rvm_verbose_flag"=>"0", "rvm_trust_rvmrcs_flag"=>"1", "USER"=>"jpablobr", "GDK_USE_XFT"=>"1", "ACK_PAGER"=>"less -FirSwX", "__array_start"=>"0", "escape_flag"=>"1", "LSCOLORS"=>"ExGxBxDxCxEgEdxbxgxcxd", "XDG_CONFIG_DIRS"=>"/etc/xdg", "rvm_prefix"=>"/home/jpablobr", "PATH"=>"/usr/lib/jvm/java-7-openjdk/bin:/home/jpablobr/.rvm/gems/ruby-1.9.3-p0/bin:/home/jpablobr/.rvm/gems/ruby-1.9.3-p0@global/bin:/home/jpablobr/.rvm/rubies/ruby-1.9.3-p0/bin:/home/jpablobr/.rvm/bin:/home/jpablobr/.cabal/bin:/usr/local/sbin:/usr/sbin:/sbin:/bin:/usr/bin:/usr/local/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl", "_"=>"/home/jpablobr/.wmii-hg/wmiirc", "HG"=>"/usr/bin/hg", "GIT_COMMITTER_EMAIL"=>"xjpablobrx@gmail.com", "PWD"=>"/home/jpablobr", "JAVA_HOME"=>"/usr/lib/jvm/java-7-openjdk", "EDITOR"=>"emacsclient -c --alternate-editor emacs", "LANG"=>"en_US.utf8", "_second"=>"1", "GIT_PS1_SHOWUNTRACKEDFILES"=>"true", "HISTIGNORE"=>"&:ls:[bf]g:exit", "rvm_make_flags"=>"-j 7", "rvm_env_string"=>"ruby-1.9.3-p0", "rvm_version"=>"1.10.0", "SHLVL"=>"5", "HOME"=>"/home/jpablobr", "XDG_CONFIG_HOME"=>"/home/jpablobr/.config", "rvm_ruby_string"=>"ruby-1.9.3-p0", "GIT_PS1_SHOWSTASHSTATE"=>"true", "XDG_CACHE_HOME"=>"/home/jpablobr/.cache", "LESS"=>" -R ", "_first"=>"0", "LOGNAME"=>"jpablobr", "VISUAL"=>"emacsclient -c", "GEM_PATH"=>"/home/jpablobr/.rvm/gems/ruby-1.9.3-p0:/home/jpablobr/.rvm/gems/ruby-1.9.3-p0@global", "XDG_DATA_DIRS"=>"/usr/share/:/usr/local/share/", "WINDOWPATH"=>"7", "DISPLAY"=>":0", "GIT_AUTHOR_EMAIL"=>"xjpablobrx@gmail.com", "RUBY_VERSION"=>"ruby-1.9.3-p0", "G_BROKEN_FILENAMES"=>"1", "WMII_FONT"=>"xft:proggynormal-8", "WMII_FOCUSCOLORS"=>"#111111 #EEF3E2 #ECF1EF", "WMII_NORMCOLORS"=>"#111111 #F8F8F8 #ECF1EF"}

I'm quite new to wmii so not sure if that's what you are asking for...

[niklas]

seems like the lbars do not exist. running the following code from rumai console "fixes" this.

x.times { |i|  Rumai.fs.lbar[i+1].create }

where x is the number of screens. I am new to wmii, but shouldn't this wmiirc create the lbars for the screens?

[niklas]

I removed fs.lbar.clear from display/tags.yaml:18 and have not seen any breaks yet.

[jpablobr]

If I do the:

x.times { |i|  Rumai.fs.lbar[i+1].create }

the lbars get created... but If I then click on one of them, it errors out with the following:

E, [2012-01-17T09:27:33.887240 #26907] ERROR -- : bad color string -- in reply to #<Rumai::IXP::Twrite:0x8bcf054 @fields=[#<Rumai::IXP::Struct::Field:0x8496e7c @name=:tag, @format=2, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Field:0x8483ad4 @name=:fid, @format=4, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Integer8Field:0x8483570 @name=:offset, @format=8, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Field:0x8482fa8 @name=:count, @format=4, @countee=#<Rumai::IXP::Struct::Field:0x8482990 @name=:data, @format=nil, @countee=nil, @counter=#<Rumai::IXP::Struct::Field:0x8482fa8 ...>>, @counter=nil>, #<Rumai::IXP::Struct::Field:0x8482990 @name=:data, @format=nil, @countee=nil, @counter=#<Rumai::IXP::Struct::Field:0x8482fa8 @name=:count, @format=4, @countee=#<Rumai::IXP::Struct::Field:0x8482990 ...>, @counter=nil>>], @values={:fid=>27, :offset=>0, :count=>13, :data=>"colors normal", :tag=>6}> (Rumai::IXP::Error)

I also tried removing the fs.lbar.clear from the tags.yaml (without the rescue nil statments) and it still errors out:

E, [2012-01-17T09:37:54.187572 #28340] ERROR -- : file not found -- in reply to #<Rumai::IXP::Twalk:0x997b20c @fields=[#<Rumai::IXP::Struct::Field:0x94b1e60 @name=:tag, @format=2, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Field:0x94ab380 @name=:fid, @format=4, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Field:0x94aaa98 @name=:newfid, @format=4, @countee=nil, @counter=nil>, #<Rumai::IXP::Struct::Field:0x94aa430 @name=:nwname, @format=2, @countee=#<Rumai::IXP::Struct::ClassField:0x94a9c24 @name=:wname, @format=String, @countee=nil, @counter=#<Rumai::IXP::Struct::Field:0x94aa430 ...>>, @counter=nil>, #<Rumai::IXP::Struct::ClassField:0x94a9c24 @name=:wname, @format=String, @countee=nil, @counter=#<Rumai::IXP::Struct::Field:0x94aa430 @name=:nwname, @format=2, @countee=#<Rumai::IXP::Struct::ClassField:0x94a9c24 ...>, @counter=nil>>], @values={:fid=>0, :newfid=>2, :wname=>["lbar", "1"], :tag=>7}> (Rumai::IXP::Error)

@niklas so, your problem is just that the lbars are not getting displayed? everything else works fine? no Rumai::IXP::Errors?

@sunaku, in this comment I mentioned that everything (besides the tags not showing) was working fine. However, not sure if I was wrong or something changed, but as you can see from above now it's not :/ If I try to switch windows it errors out.

[niklas]

@jpablobr no, my problem are IXP::Errors, too. But I refactored rumai a bit so it catches them all and logs them. Look at my fork https://github.com/niklas/rumai/commit/0ea121d282c86d537ddf556e2c4e374f806520a2 here. The log shows more concise which path was accessed.

Still not everything working fine, my wmii (standard oneiric 3.9.2+debian-3ubuntu) seems to be missing /rules, independently of the configuration.

Regarding the Env var: man wmii claims to export $WMII_ADDRESS to the running environment. This should contain the path to the control socket. wmiirc uses this if present, but falls back to the standard /tmp/ns.$USER.$DISPLAY/wmii. My first thought was that wmiirc does not connect to the right socket (suggested by the missing WMII_ADDRESS), but the connection wto wmii seems to be working properly

[sunaku]

Hey folks, I'm sorry to say that I still can't reproduce this bug under both the vanilla wmii-hg source tree and under my personal branch. Maybe it's because I run Arch Linux whereas you folks seem to be running Ubuntu/Debian?

@jpablobr the "bad color string" error is caused by display/barlet.yaml:17 not being able to find the display:color:normal key (perhaps it's not defined in your configuration? check config.dump).

[jpablobr]

Nah, I'm on Arch as well :)

jp@d: ~ uname -a
Linux dell-17 3.1.9-2-ARCH #1 SMP PREEMPT Sat Jan 14 08:11:41 UTC 2012 i686 Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz GenuineIntel GNU/Linux

[sunaku]

Let's see if wmiir(1) hits the same error, since it's really WMII raising that "file not found" error via IXP:

system "echo 'label testing' | wmiir create /lbar/1"
system "wmiir ls /lbar"

Add that above the spots in display/tags.yaml where you hit the error.

[jpablobr]

Yes, that works fine. I guess I'm gonna play a bit more with wmii(1) and test a bit further the tags mechanism. So far I've only play with it via rumai.

[niklas]

Got it. display/barlet.yaml was loaded to late, thus inheriting TagBarlet from Rumai::Barlet instead of <Sandbox>::Barlet. So the implicit create of the Barlets wasn't called and the later write failed.

Adding the former to the imports in config.yaml before the glob display/*provides me with a nice tag list.

This shouldn't happen (TM), right? The YAMLs should require their depending imports immediatly before executing the before code. Too tired to find this now, but maybe it helps

[jpablobr]

Thank you! It works!

[sunaku]

Excellent work @niklas! :metal: You're right, we need to collect the list of all imports before expanding them and merging the YAML files.

[sunaku]

There was a bug in the importing logic. Data from import N was being merged with data from import N-1 instead of being merged with import 0 (the top-level config). Now you can import tags before barlet safely:

diff --git a/config.yaml b/config.yaml
index 4d805ea..81e1048 100644
--- a/config.yaml
+++ b/config.yaml
@@ -3,6 +3,8 @@ import:
   - status/music/mpd.yaml
   - control/*.yaml
   - control/action/*.yaml
+  - display/tags.yaml
+  - display/barlet.yaml
   - display/*.yaml
   - display/color/zukitwo-dark.yaml
   - display/desktop/feh.yaml

Thanks to @niklas and everyone else involved for not giving up and squashing this bug! :sparkles:

[ghedamat]

thanks to everybody! :)

[niklas]

hurray!