headers
awesome | 4 Oct 2011 18:44
Gravatar

[awesome bugs] #929 - thunderbird doesn't react on layout changes

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#929 - thunderbird doesn't react on layout changes
User who did this - Gino Heusdens (ginoheusdens)

----------
This indeed solves the weird behaviour. It it possible the state remembered from an other window manager?
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=929#comment2742

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

--

-- 
To unsubscribe, send mail to awesome-devel-unsubscribe <at> naquadah.org.
Permalink | Reply | 0 comments |
headers
awesome | 4 Oct 2011 19:51
Gravatar

[awesome bugs] #929 - thunderbird doesn't react on layout changes

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#929 - thunderbird doesn't react on layout changes
User who did this - Uli Schlachter (psychon)

----------
Yeah, that's possible. It's also possible that thunderbird remembered that state by itself.
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=929#comment2743

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

--

-- 
To unsubscribe, send mail to awesome-devel-unsubscribe <at> naquadah.org.
Permalink | Reply | 0 comments |
headers
awesome | 4 Oct 2011 19:51
Gravatar

[awesome bugs] #929 - thunderbird doesn't react on layout changes

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task is now closed:

FS#929 - thunderbird doesn't react on layout changes
User who did this - Uli Schlachter (psychon)

Reason for closing: Not a bug
More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=929

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

--

-- 
To unsubscribe, send mail to awesome-devel-unsubscribe <at> naquadah.org.
Permalink | Reply | 0 comments |
headers
awesome | 6 Oct 2011 17:58
Gravatar

[awesome bugs] #844 - Awesome does not work with FreeNX

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task is now closed:

FS#844 - Awesome does not work with FreeNX
User who did this - Uli Schlachter (psychon)

Reason for closing: Not a bug
Additional comments about closing: $ grep nxagent /var/log/*
Oct  6 15:10:48 orzechmac kernel: [ 8793.623211] nxagent[25376]: segfault at 0 ip 00000000004a7c56 sp
00007fff233004d0 error 4 in nxagent[400000+4d1000]

Come back when the NULL pointer dereference in nxagent is fixed.

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=844

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

--

-- 
To unsubscribe, send mail to awesome-devel-unsubscribe <at> naquadah.org.
Permalink | Reply | 0 comments |
headers
awesome | 7 Oct 2011 17:13
Gravatar

[awesome bugs] #890 - Luajit support

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

The following task has a new comment added:

FS#890 - Luajit support
User who did this - Grygoriy Fuchedzhy (gry)

----------
While using it for a month with a lot of widgets haven't discovered any issues at all.
----------

More information can be found at the following URL:
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=890#comment2744

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you
did not expect this message or don't want to receive mails in future, you can change your notification
settings at the URL shown above.

--

-- 
To unsubscribe, send mail to awesome-devel-unsubscribe <at> naquadah.org.
Permalink | Reply | 0 comments |
headers
awesome | 9 Oct 2011 10:03
Gravatar

[awesome bugs] #930 - Focus lost when window moves itself between screens

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened.  Details are below. 

User who did this - Adam Nielsen (Malvineous) 

Attached to Project - awesome
Summary - Focus lost when window moves itself between screens
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Low
Priority - Normal
Reported Version - 3.4.10
Due in Version - Undecided
Due Date - Undecided
Details - When a focused window moves itself to another screen, the focus jumps to the last window on that
screen.  It should stay with the original window.

To reproduce:

1. Load the "xv" viewer with a small image (wide images work better)
2. Make the xv window free floating, and place it on your right-most screen.
2. Press '>' a number of times to enlarge the image, until the xv window is wider than your screen.
3. Observe that the instant the xv window grows wider than the screen, your '>' keypresses end up going into a
different window, even though you never changed the focus.

Possibly related issue:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Uli Schlachter | 9 Oct 2011 20:55
Picon
Gravatar

Different behavior of lua_setmetatable with luajit


Hi,

people are annoying me that they want luajit support in awesome[1]. Attached is
a reduced test case of the problem that we face. Running this against lua 5.1.4
works while luajit 5.1 (debian testing version) hits the following lua error:

  PANIC: unprotected error in call to Lua API (bad argument #1 to '?'
  (screen expected, got userdata))

Could you take a look? Thanks.

Uli

[1] https://awesome.naquadah.org/bugs/index.php?do=details&task_id=890

P.S.: You really should add the contact link to the sidebar, it took me a while
to find it.
--

-- 
"Do you know that books smell like nutmeg or some spice from a foreign land?"
                                                  -- Faber in Fahrenheit 451
Attachment (t.c): text/x-csrc, 314 bytes
Attachment (t.c.sig): application/octet-stream, 287 bytes
Permalink | Reply | 6 comments |
headers
Daniel Silverstone | 10 Oct 2011 08:46
Favicon
Gravatar

Re: Different behavior of lua_setmetatable with luajit

On Sun, Oct 09, 2011 at 08:55:14PM +0200, Uli Schlachter wrote:
> Could you take a look? Thanks.
[snip]
> #include <lua.h>
> #include <lauxlib.h>
> #include <stdio.h>
> 
> int main()
> {
> 	lua_State *L = luaL_newstate();
> 
> 	/* Just some random light user data */
> 	lua_pushlightuserdata(L, L);
> 	luaL_newmetatable(L, "screen");
> 	lua_setmetatable(L, -2);
> 
> 	printf("%p\n", luaL_checkudata(L, 1, "screen"));
> 
> 	puts("Done");
> 	return 0;
> }

This appears to try and set the metatable for the LIGHTUSERDATA type.
(Remember light userdata don't get their own metatables in Lua 5.1)

As a result, it seems like quite a nonsensical test case, but let's explore it.
This is flow of consciousness as I explore the codebases so skip to the end if
you want the final answer, or read on if you want to see how I explored the
codebases to find the answer...
(Continue reading)

Permalink | Reply | 5 comments |
headers
Uli Schlachter | 10 Oct 2011 09:34
Picon
Gravatar

Re: Different behavior of lua_setmetatable with luajit

Hi,

for completeness, here is the reply that I got from the luajit author: (Since he 
was quicker at replying, this is only half a top post ;-) ):

> Uli Schlachter wrote:
>> people are annoying me that they want luajit support in awesome[1].
> A JIT compiler for a window manager? What a quaint idea.
>
> Not surprisingly, nobody has benchmarked whether this is actually
> helpful (I seriously doubt this). The X11 API and the C/Lua
> bindings probably waste much more CPU time, anyway.
>
>> 	/* Just some random light user data */
>> 	lua_pushlightuserdata(L, L);
>> 	luaL_newmetatable(L, "screen");
>> 	lua_setmetatable(L, -2);
> Lightuserdata doesn't have per-object metatables. This is setting
> the per-type metatable for _all_ lightuserdata objects. Doing this
> more than once is rather pointless.
>
> A quick look at luaA_pushscreen() in the (not so) awesome sources
> confirms my suspicion that someone doesn't know what they are
> doing ...
>
> In fact, since you're mutating special global state, the JIT compiler
> flushes all compiled code. For every call (!) -- this is costly.
>
>> 	printf("%p\n", luaL_checkudata(L, 1, "screen"));
> The Lua manual states that luaL_checkudata() checks for userdata.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Daniel Silverstone | 10 Oct 2011 10:02
Favicon
Gravatar

Re: Different behavior of lua_setmetatable with luajit

On Mon, Oct 10, 2011 at 09:34:22AM +0200, Uli Schlachter wrote:
> for completeness, here is the reply that I got from the luajit
> author: (Since he was quicker at replying, this is only half a top
> post ;-) ):
[snip Mike's reply]

Mike is usually quick and thorough.  His reply essentially says similar to
mine.

> Why "remember"? After I got the other reply, I checked lua's doc and
> I couldn't find this anywhere.

Sorry.  I'm a very very long-time Lua/C programmer and it sometimes is hard for
me to remember people don't know things like I do :-)  I remember metatables as
"for tables and full userdata only" from 5.0, and then 5.1 added "oh and a
global one for each type" so we could have shortcuts like foo = "hello world",
bar = foo:gsub("world", "bar")

[snip]
> IMHO this fact is a little hidden inside lua's doc and apparently
> neither me nor JD knew this.

I can see why you found it hard to find.

> This test case comes from awesome's screen code. Since awesome
> handles screen changes via restarts, the set of screen objects never
> changes while awesome is running. So when lua asks for a screen with
> screen[1], it just gets our internal screen_t* as a light user
> datum. (see luaA_pushscreen)
>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane