Closed jpablobr closed 12 years ago
I noticed you're building wmii from the suckless hg, which is out of date. Try the googlecode mirror instead.
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...
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.
I believe I built from http://libs.suckless.org/libixp, so now I tried with the google one. The following is the output:
and this is wmii's current error log when I uncomment tags.yaml
:
https://gist.github.com/1554351/fd96043b3261db8b66d1640821591d77473836ca#file_wmii.log
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?
And a temporary solution would be to add rescue nil
to the end of the line that's causing the error.
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
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 :)
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.
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.
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
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.
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 :)
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
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.
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
Thanks for clarifying @ghedamat. I'm debugging the issue now, seems like a fid
allocation problem in Rumai.
Also, I've just cloned git version of rumai and all tests seems to pass here (?)
pass: 57
time: 0.178013578
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
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 :)
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.
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}
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?
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
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
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...
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?
I removed fs.lbar.clear
from display/tags.yaml:18 and have not seen any breaks yet.
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::Error
s?
@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.
@jpablobr no, my problem are IXP::Error
s, 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
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
).
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
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.
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.
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 Barlet
s 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
Thank you! It works!
Excellent work @niklas! :metal: You're right, we need to collect the list of all imports before expanding them and merging the YAML files.
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:
thanks to everybody! :)
hurray!
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 myconfig.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