notion-general — General discussion about the notion window manager

Re: [Notion-general] Alt-Tab keymap

[Arnout E. <no...@bz...>]

On Sun, Feb 23, 2014 at 9:12 PM, Jeff Abrahamson <je...@pu...> wrote:

> I'd like to push most of notion's key bindings into a submap under
> META-tab.  Since the docs say to use the names in xkeysym.h (xkeysymdef.h),
> I tried
>
> defbindings("WScreen", {
>     submap(META..KB_Tab, {
>
>
> and, since that didn't work,
>
> defbindings("WScreen", {
>     submap(META..Tab, {
>
>
Hi Jeff,

Looks like this should be 'Tab' (I guess the docs could be improved there).

I think the problem you're running into, though, is that "Tab" should be in
quotes there. The error message is probably saying 'Tab' (which without
quotes is a variable name) is 'nil'.


Kind regards,

Arnout

[Notion-general] Notion donations

[Arnout E. <no...@bz...>]

Hello,

We've been honored to receive several requests to allow donations to the
Notion project, and following that I now added a 'Donations' section to
http://notion.sf.net , supporting paypal and bitcoin.

I feel strongly that Notion is a community project, so donations will not
be used to 'compensate time' (as that wouldn't be fair to other
contributors), but to cover costs related to Notion or other projects in
the broader FLOSS space.

If you'd like to associate your donation with a particular
support/documentation request, bug or other goal, please make a note of
that.


Kind regards,

Arnout

Re: [Notion-general] Release 2014052800

[Thomas K. <tk...@gi...>]

Hi Arnout!

On Fri, May 30, 2014 at 04:28:33PM +0200, Arnout Engelen wrote:
> META now defaults to the 'windows' key (where it previously defaulted to
> Mod1/'alt'). ALTMETA defaults to nothing, this has not changed. AFAIK the
> 'ALT' in 'ALTMETA' really just means 'alternative', and has nothing to do
> with the 'alt' key...
> 
> Thus in the default configuration:
> 
> etc/cfg_notioncore.lua:    kpress(ALTMETA.."F3", "mod_query.query_exec(_)"),
> etc/cfg_notioncore.lua:    kpress(META.."F3", "mod_query.query_lua(_)"),
> 
> .. simply pressing F3 opens query_exec, and 'windows'-F3 opens query_lua.
> 
> It looks like you have configured ALTMETA to be the windows key.
> 
> In the default configuration, ALTMETA is only used for the F-keys. If you
> prefer to leave the F-keys free for client apps, it'd make sense to either:
> 
> * configure ALTMETA to be the 'alt' key (Mod1+), or
> * configure META to be 'alt'/Mod1+ and ALTMETA to be 'windows'/Mod4+.

You're of course right, I had defined ALTMETA to have F2 etc. free for
libreoffice etc.
I'll go with your last suggestion, thank you!
 Thomas

Re: [Notion-general] Release 2014052800

[Arnout E. <no...@bz...>]

Hi Thomas,

META now defaults to the 'windows' key (where it previously defaulted to
Mod1/'alt'). ALTMETA defaults to nothing, this has not changed. AFAIK the
'ALT' in 'ALTMETA' really just means 'alternative', and has nothing to do
with the 'alt' key...

Thus in the default configuration:

etc/cfg_notioncore.lua:    kpress(ALTMETA.."F3", "mod_query.query_exec(_)"),
etc/cfg_notioncore.lua:    kpress(META.."F3", "mod_query.query_lua(_)"),

.. simply pressing F3 opens query_exec, and 'windows'-F3 opens query_lua.

It looks like you have configured ALTMETA to be the windows key.

In the default configuration, ALTMETA is only used for the F-keys. If you
prefer to leave the F-keys free for client apps, it'd make sense to either:

* configure ALTMETA to be the 'alt' key (Mod1+), or
* configure META to be 'alt'/Mod1+ and ALTMETA to be 'windows'/Mod4+.


Kind regards,

Arnout


On Fri, May 30, 2014 at 4:15 PM, Thomas Klausner <tk...@gi...> wrote:

> On Wed, May 28, 2014 at 08:07:58AM +0200, Arnout Engelen wrote:
> > Thanks to Dima for support and peer pressure, today marks the release of
> > Notion 2014052800. Notable changes include:
> >
> > * Improvement: 'windows' key is now the default META key (thanks to Dima
> > Kogan)
>
> Thanks for the release, and the mail.
>
> Are meta and altmeta now the same? I used to press Windows+F3 to get
> mod_query.query_exec and ALT+F3 to get mod_query.query_lua, but now
> Windows+F3 gives me mod_query.query_lua.
>  Thomas
>

Re: [Notion-general] Release 2014052800

[Thomas K. <tk...@gi...>]

On Wed, May 28, 2014 at 08:07:58AM +0200, Arnout Engelen wrote:
> Thanks to Dima for support and peer pressure, today marks the release of
> Notion 2014052800. Notable changes include:
> 
> * Improvement: 'windows' key is now the default META key (thanks to Dima
> Kogan)

Thanks for the release, and the mail.

Are meta and altmeta now the same? I used to press Windows+F3 to get
mod_query.query_exec and ALT+F3 to get mod_query.query_lua, but now
Windows+F3 gives me mod_query.query_lua.
 Thomas

[Notion-general] Release 2014052800

[Arnout E. <no...@bz...>]

Hello,

Thanks to Dima for support and peer pressure, today marks the release of
Notion 2014052800. Notable changes include:

* Improvement: 'windows' key is now the default META key (thanks to Dima
Kogan)

* Bugfix: seldomly triggered crash in memory pool (thanks to Matthieu Moy)
* Bugfix: save the session atomically (thanks to Matthias Lederhofer)
* Bugfix: various fixes to contributed scripts, notably more lua5.2 support
(thanks to several contributors)

* Improvement: various code cleanups (thanks to Campbell Barton)
* Improvement: various build/packaging improvements (thanks to Dima Kogan)

* Feature: Workspace indicator (thanks to Dima Kogan)
* Feature: Delayed population of the focuslist (thanks to Dima Kogan)

* Improvement: improved kludges/focus behavior (IntelliJ IDEA, xeyes)
* Improvement: expose 'warp_pointer' to lua
* Improvement: lock using i3lock when available

Enjoy!


Kind regards,

Arnout

Re: [Notion-general] collapse.lua causes segfault since last Debian update

[Matthieu M. <Mat...@gr...>]

Arnout Engelen <no...@bz...> writes:

> I think this should now be fixed on git master HEAD, can you verify it indeed
> works for you, too?

It seems to be fixed, indeed. Thanks a lot!

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [Notion-general] lua-5.2?

[Jeff B. <jef...@gm...>]

Hi Thomas,

On Thu, May 15, 2014 at 11:28 AM, Thomas Klausner <tk...@gi...> wrote:

>
> I'm packaging notion for pkgsrc, and recently updated to 2014010900
> (it would have been nice if that version had been announced). Around
> the same time pkgsrc grew support for parallel installation of lua51
> and lua52. The notion package pulled in lua52 (which provides
> /usr/pkg/bin/lua5.2 and the corresponding library
> /usr/pkg/lib/liblua5.2.la). NetBSD itself comes with /usr/bin/lua,
> which is lua-5.1.5.
>
> When I started notion, it complained about
> /usr/pkg/lib/notion/lc/ioncore_ext.lc being compiled for the wrong lua
> version.
>
>
I've changed the package to use lua-5.1 for now.
>
> Perhaps the problem is just that I need to tell notion more explicitly
> that it should only use /usr/pkg/bin/lua5.2?
>  Thomas
>
>
Ahh - yes, Notion's build setup can get confused if you have multiple
versions of Lua installed. Please take a look at system-autodetect.mk.
There is a section in there regarding the Lua compiler and interpreter. It
sounds like you will need to explicitly tell it where to find the compiler
and interpreter for 5.2.

Regards,
Jeff

-- 
Jeff Backus
jef...@gm...
http://github.com/jsbackus

Re: [Notion-general] lua-5.2?

[Thomas K. <tk...@gi...>]

On Thu, May 15, 2014 at 11:20:40AM -0400, Jeff Backus wrote:
> Yes, in fact I am currently using Notion on several machines w/ Lua 5.2.
> Unfortunately, have been some changes in the language that have broken some
> parts of Notion and are being dealt with as they come up. Are you currently
> having problems? If so, could you provide more details?

I'm packaging notion for pkgsrc, and recently updated to 2014010900
(it would have been nice if that version had been announced). Around
the same time pkgsrc grew support for parallel installation of lua51
and lua52. The notion package pulled in lua52 (which provides
/usr/pkg/bin/lua5.2 and the corresponding library
/usr/pkg/lib/liblua5.2.la). NetBSD itself comes with /usr/bin/lua,
which is lua-5.1.5.

When I started notion, it complained about
/usr/pkg/lib/notion/lc/ioncore_ext.lc being compiled for the wrong lua
version.

I've changed the package to use lua-5.1 for now.

Perhaps the problem is just that I need to tell notion more explicitly
that it should only use /usr/pkg/bin/lua5.2?
 Thomas


> Regards,
> Jeff
> 
> 
> On Thu, May 15, 2014 at 10:20 AM, Thomas Klausner <tk...@gi...> wrote:
> 
> > Hi!
> >
> > Is notion supposed to work with lua-5.2?
> >  Thomas
> >
> >
> > ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform
> > available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> > _______________________________________________
> > Notion-general mailing list
> > Not...@li...
> > https://lists.sourceforge.net/lists/listinfo/notion-general
> >
> 
> 
> 
> -- 
> Jeff Backus
> jef...@gm...
> http://github.com/jsbackus

Re: [Notion-general] lua-5.2?

[Jeff B. <jef...@gm...>]

Hi Thomas,

Yes, in fact I am currently using Notion on several machines w/ Lua 5.2.
Unfortunately, have been some changes in the language that have broken some
parts of Notion and are being dealt with as they come up. Are you currently
having problems? If so, could you provide more details?

Regards,
Jeff


On Thu, May 15, 2014 at 10:20 AM, Thomas Klausner <tk...@gi...> wrote:

> Hi!
>
> Is notion supposed to work with lua-5.2?
>  Thomas
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Notion-general mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-general
>



-- 
Jeff Backus
jef...@gm...
http://github.com/jsbackus

[Notion-general] lua-5.2?

[Thomas K. <tk...@gi...>]

Hi!

Is notion supposed to work with lua-5.2?
 Thomas

Re: [Notion-general] collapse.lua causes segfault since last Debian update

[Wojciech A. <ani...@co...>]

Salut,

I got as far as:
/collapse.lua:23: <name> expected near 'goto'

so I guess I'm way off:)
regards
w


On Wed, May 14, 2014 at 11:44:27PM +0200, Arnout Engelen wrote:
> Hi Matthieu,
> 
> Thanks for the pointer. I've been to run the script and kind of reproduce
> the problem: for me notion didn't crash outright but ended up in an
> infinite loop - not much better :).
> 
> Upon inspection this seems to be a bona fide pointer arithmetic bug that's
> been lurking there since before 2005.
> 
> I think this should now be fixed on git master HEAD, can you verify it
> indeed works for you, too?
> 
> 
> Kind regards,
> 
> Arnout
> 
> 
> On Tue, May 13, 2014 at 8:35 AM, Matthieu Moy
> <Mat...@gr...>wrote:
> 
> > Arnout Engelen <ar...@bz...> writes:
> >
> > > On Sun, May 4, 2014 at 7:47 PM, Matthieu Moy <
> > Mat...@gr...> wrote:
> > >
> > >     I'm using notion from Debian, and collapse.lua from here:
> > >
> > https://github.com/dkogan/notion-scripts/blob/master/scripts/collapse.lua
> > >     (move all clients to the same frame and close all other frames, like
> > C-x
> > >     1 in Emacs)
> > >
> > >     The last upgrade broke collapse.lua: using it now causes notion to
> > >     segfault.
> > >
> > > Can you explain how exactly you invoke this script? I can't really seem
> > to reproduce the crash (or make the
> > > script do anything useful, actually).
> >
> > A looong time I wrote this config, and I don't remember how it
> > works ;-).
> >
> > I use emacs-bindings.lua and collapse.lua together:
> >
> >
> > https://github.com/dkogan/notion-scripts/blob/master/keybindings/emacs_bindings.lua
> >
> > (essentially, I get the same split/join/... behavior for notion and for
> > Emacs, just shifting my thumb from the Alt_L key to the Super_L key)
> >
> > The relevant part is:
> >
> > Emacs.WTiling_X = {
> >    kpress ("AnyModifier+1", "collapse.collapse(_)"),
> > }
> >
> > Emacs.WTiling = {
> >     submap(META.."x", Emacs.WTiling_X),
> > }
> >
> > defbindings("WTiling", Emacs.WTiling)
> >
> > Then, split your workspaces in any way, type Control-x 1 and you'll get
> > a single split with all frames attached to it.
> >
> > > In the mean time, can you try and reproduce the problem with
> > > the debug_defer_crash git branch? This should no longer crash notion,
> > > but spew out all kinds of diagnostics.
> >
> > No time today, but I'll try when I get time.
> >
> > --
> > Matthieu Moy
> > http://www-verimag.imag.fr/~moy/
> >

> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs

> _______________________________________________
> Notion-general mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-general


-- 
Wojtek Aniszewski
[Eng: voyteck aanishevsky]
[Fr:  vôytek anichévsky]

 /^..^\      ,-------------------------------------,
( (••) ) ----| My public GPG key ID: AC66485E      |
(|)_._(|)~   | please use email encryption!        |
             `-------------------------------------"

Re: [Notion-general] collapse.lua causes segfault since last Debian update

[Arnout E. <no...@bz...>]

Hello Wojciech,

The version of collapse.lua you appear to be using doesn't work with lua
5.2.

You can either downgrade lua or get an updated version of the script from
https://sourceforge.net/p/notion/notion/ci/master/tree/contrib/scripts/


Kind regards,

Arnout


On Thu, May 15, 2014 at 12:04 PM, Wojciech Aniszewski
<ani...@co...>wrote:

> Salut,
>
> I got as far as:
> /collapse.lua:23: <name> expected near 'goto'
>
> so I guess I'm way off:)
> regards
> w
>
>
> On Wed, May 14, 2014 at 11:44:27PM +0200, Arnout Engelen wrote:
> > Hi Matthieu,
> >
> > Thanks for the pointer. I've been to run the script and kind of reproduce
> > the problem: for me notion didn't crash outright but ended up in an
> > infinite loop - not much better :).
> >
> > Upon inspection this seems to be a bona fide pointer arithmetic bug
> that's
> > been lurking there since before 2005.
> >
> > I think this should now be fixed on git master HEAD, can you verify it
> > indeed works for you, too?
> >
> >
> > Kind regards,
> >
> > Arnout
> >
> >
> > On Tue, May 13, 2014 at 8:35 AM, Matthieu Moy
> > <Mat...@gr...>wrote:
> >
> > > Arnout Engelen <ar...@bz...> writes:
> > >
> > > > On Sun, May 4, 2014 at 7:47 PM, Matthieu Moy <
> > > Mat...@gr...> wrote:
> > > >
> > > >     I'm using notion from Debian, and collapse.lua from here:
> > > >
> > >
> https://github.com/dkogan/notion-scripts/blob/master/scripts/collapse.lua
> > > >     (move all clients to the same frame and close all other frames,
> like
> > > C-x
> > > >     1 in Emacs)
> > > >
> > > >     The last upgrade broke collapse.lua: using it now causes notion
> to
> > > >     segfault.
> > > >
> > > > Can you explain how exactly you invoke this script? I can't really
> seem
> > > to reproduce the crash (or make the
> > > > script do anything useful, actually).
> > >
> > > A looong time I wrote this config, and I don't remember how it
> > > works ;-).
> > >
> > > I use emacs-bindings.lua and collapse.lua together:
> > >
> > >
> > >
> https://github.com/dkogan/notion-scripts/blob/master/keybindings/emacs_bindings.lua
> > >
> > > (essentially, I get the same split/join/... behavior for notion and for
> > > Emacs, just shifting my thumb from the Alt_L key to the Super_L key)
> > >
> > > The relevant part is:
> > >
> > > Emacs.WTiling_X = {
> > >    kpress ("AnyModifier+1", "collapse.collapse(_)"),
> > > }
> > >
> > > Emacs.WTiling = {
> > >     submap(META.."x", Emacs.WTiling_X),
> > > }
> > >
> > > defbindings("WTiling", Emacs.WTiling)
> > >
> > > Then, split your workspaces in any way, type Control-x 1 and you'll get
> > > a single split with all frames attached to it.
> > >
> > > > In the mean time, can you try and reproduce the problem with
> > > > the debug_defer_crash git branch? This should no longer crash notion,
> > > > but spew out all kinds of diagnostics.
> > >
> > > No time today, but I'll try when I get time.
> > >
> > > --
> > > Matthieu Moy
> > > http://www-verimag.imag.fr/~moy/
> > >
>
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos.
> > Get unparalleled scalability from the best Selenium testing platform
> available
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
>
> > _______________________________________________
> > Notion-general mailing list
> > Not...@li...
> > https://lists.sourceforge.net/lists/listinfo/notion-general
>
>
> --
> Wojtek Aniszewski
> [Eng: voyteck aanishevsky]
> [Fr:  vôytek anichévsky]
>
>  /^..^\      ,-------------------------------------,
> ( (••) ) ----| My public GPG key ID: AC66485E      |
> (|)_._(|)~   | please use email encryption!        |
>              `-------------------------------------"
>

Re: [Notion-general] collapse.lua causes segfault since last Debian update

[Arnout E. <no...@bz...>]

Hi Matthieu,

Thanks for the pointer. I've been to run the script and kind of reproduce
the problem: for me notion didn't crash outright but ended up in an
infinite loop - not much better :).

Upon inspection this seems to be a bona fide pointer arithmetic bug that's
been lurking there since before 2005.

I think this should now be fixed on git master HEAD, can you verify it
indeed works for you, too?


Kind regards,

Arnout


On Tue, May 13, 2014 at 8:35 AM, Matthieu Moy
<Mat...@gr...>wrote:

> Arnout Engelen <ar...@bz...> writes:
>
> > On Sun, May 4, 2014 at 7:47 PM, Matthieu Moy <
> Mat...@gr...> wrote:
> >
> >     I'm using notion from Debian, and collapse.lua from here:
> >
> https://github.com/dkogan/notion-scripts/blob/master/scripts/collapse.lua
> >     (move all clients to the same frame and close all other frames, like
> C-x
> >     1 in Emacs)
> >
> >     The last upgrade broke collapse.lua: using it now causes notion to
> >     segfault.
> >
> > Can you explain how exactly you invoke this script? I can't really seem
> to reproduce the crash (or make the
> > script do anything useful, actually).
>
> A looong time I wrote this config, and I don't remember how it
> works ;-).
>
> I use emacs-bindings.lua and collapse.lua together:
>
>
> https://github.com/dkogan/notion-scripts/blob/master/keybindings/emacs_bindings.lua
>
> (essentially, I get the same split/join/... behavior for notion and for
> Emacs, just shifting my thumb from the Alt_L key to the Super_L key)
>
> The relevant part is:
>
> Emacs.WTiling_X = {
>    kpress ("AnyModifier+1", "collapse.collapse(_)"),
> }
>
> Emacs.WTiling = {
>     submap(META.."x", Emacs.WTiling_X),
> }
>
> defbindings("WTiling", Emacs.WTiling)
>
> Then, split your workspaces in any way, type Control-x 1 and you'll get
> a single split with all frames attached to it.
>
> > In the mean time, can you try and reproduce the problem with
> > the debug_defer_crash git branch? This should no longer crash notion,
> > but spew out all kinds of diagnostics.
>
> No time today, but I'll try when I get time.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
>

Re: [Notion-general] collapse.lua causes segfault since last Debian update

[Arnout E. <no...@bz...>]

Hi Matthieu,

I only managed a quick look, and this does seem to be something in Notion
that's not working as indended. I created a ticket at
https://sourceforge.net/p/notion/bugs/77/ and noted some preliminary
thoughts there.

To be continued!


Kind regards,

Arnout


On Tue, May 6, 2014 at 10:05 AM, Matthieu Moy
<Mat...@gr...>wrote:

> Arnout Engelen <ar...@bz...> writes:
>
> > Have you tried the latest git version? I suspect this won't have
> > the frame_size_hints valgrind errors, though the actual crash you
> > describe doesn't sound familiar, so
> > that's likely still there.
>
> It is. The valgrind trace (with freshly git-cloned notion) is below.
>
> ==15052== Conditional jump or move depends on uninitialised value(s)
> ==15052==    at 0x41E90E: region_may_dispose (region.c:479)
> ==15052==    by 0x41ED61: region_rqdispose (region.c:512)
> ==15052==    by 0x4349AF: mainloop_execute_deferred_on_list (defer.c:191)
> ==15052==    by 0x416D44: ioncore_mainloop (event.c:228)
> ==15052==    by 0x41519B: main (notion.c:281)
> ==15052==
> ==15052== Jump to the invalid address stated on the next line
> ==15052==    at 0x0: ???
> ==15052==    by 0x41E916: region_may_dispose (region.c:479)
> ==15052==    by 0x41ED61: region_rqdispose (region.c:512)
> ==15052==    by 0x4349AF: mainloop_execute_deferred_on_list (defer.c:191)
> ==15052==    by 0x416D44: ioncore_mainloop (event.c:228)
> ==15052==    by 0x41519B: main (notion.c:281)
> ==15052==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> ==15052==
> ==15052==
> ==15052== Process terminating with default action of signal 11 (SIGSEGV)
> ==15052==  Bad permissions for mapped region at address 0x0
> ==15052==    at 0x0: ???
> ==15052==    by 0x41E916: region_may_dispose (region.c:479)
> ==15052==    by 0x41ED61: region_rqdispose (region.c:512)
> ==15052==    by 0x4349AF: mainloop_execute_deferred_on_list (defer.c:191)
> ==15052==    by 0x416D44: ioncore_mainloop (event.c:228)
> ==15052==    by 0x41519B: main (notion.c:281)
> ==15052==
> ==15052== HEAP SUMMARY:
> ==15052==     in use at exit: 1,707,258 bytes in 13,962 blocks
> ==15052==   total heap usage: 42,694 allocs, 28,732 frees, 5,525,276 bytes
> allocated
> ==15052==
> ==15052== LEAK SUMMARY:
> ==15052==    definitely lost: 224 bytes in 1 blocks
> ==15052==    indirectly lost: 176 bytes in 2 blocks
> ==15052==      possibly lost: 0 bytes in 0 blocks
> ==15052==    still reachable: 1,706,858 bytes in 13,959 blocks
> ==15052==         suppressed: 0 bytes in 0 blocks
> ==15052== Rerun with --leak-check=full to see details of leaked memory
> ==15052==
> ==15052== For counts of detected and suppressed errors, rerun with: -v
> ==15052== Use --track-origins=yes to see where uninitialised values come
> from
> ==15052== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 3 from 3)
> ==15067== Memcheck, a memory error detector
> ==15067== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==15067== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
> ==15067== Command: /home/moy/local/usr/bin/notion
> ==15067==
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
>

Re: [Notion-general] collapse.lua causes segfault since last Debianupdatee

[Matthieu M. <Mat...@gr...>]

Dima Kogan <no...@di...> writes:

> Matthieu Moy <Mat...@gr...> writes:
>
>> I'm using notion from Debian
>>
>> The last upgrade broke collapse.lua: using it now causes notion to
>> segfault.
>
> Hi. I haven't looked at this yet. But to be clear, are you saying that
> the latest Debian upgrade (to package version 3+2014010901-1) introduced
> this regression?

That's it, yes.

Note that the previous version was 3+2012042300-1 (it seems I missed one
upgrade for some reason).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [Notion-general] collapse.lua causes segfault since last Debianupdatee

[Dima K. <no...@di...>]

Matthieu Moy <Mat...@gr...> writes:

> I'm using notion from Debian
>
> The last upgrade broke collapse.lua: using it now causes notion to
> segfault.

Hi. I haven't looked at this yet. But to be clear, are you saying that
the latest Debian upgrade (to package version 3+2014010901-1) introduced
this regression?

dima

[Notion-general] collapse.lua causes segfault since last Debian update

[Matthieu M. <Mat...@gr...>]

Hi,

I'm using notion from Debian, and collapse.lua from here:
https://github.com/dkogan/notion-scripts/blob/master/scripts/collapse.lua
(move all clients to the same frame and close all other frames, like C-x
1 in Emacs)

The last upgrade broke collapse.lua: using it now causes notion to
segfault.

Below is a valgrind trace. It seems notion doesn't like
ioncore.defer( rqclose ) and ioncore.defer( move the managed clients)
being called concurrently (my guess is that the order in which ioncore
executes stuff changed, and it now tries to close the region before or
concurrently to moving clients).

I managed to somehow fix detach.lua like this:

collapse={}

function win_goto(w) return w['goto'](w) end

function collapse.take_frame_to_here (region, current)
   if region ~= current then
      close_requested = false
      region:managed_i(function (cwin)
                          io.stderr:write("attach " .. cwin:name() .. " to " .. current:name() .. "\n")
                          ioncore.defer(function()
                                           current:attach(cwin)
                                           ioncore.defer(function ()
                                                            io.stderr:write("close " .. region:name() .. ".\n")
                                                            region:rqclose()
                                                         end)
                                           close_requested = true
                                        end)
                          return true
                       end)
      if not close_requested then
         ioncore.defer(function ()
                          io.stderr:write("close empty " .. region:name() .. ".\n")
                          region:rqclose()
                       end)
      end
   end
   return true
end

function collapse.collapse(ws)
   local current = ws:current()
   ws:managed_i (function (region)
                    return collapse.take_frame_to_here(region, current)
                 end)
   win_goto(current)
end

(not really happy with my nested ioncore.defer() ...)

Can notion be fixed not to segfault in this case?

Any lua/notion guru to help me do a cleaner fix? Or is it already the
less ugly possible?

Or is there a simpler way to achieve the same result?

Thanks,


And the valgrind trace:

==7319== Conditional jump or move depends on uninitialised value(s)
==7319==    at 0x427147: frame_size_hints (in /usr/bin/notion)
==7319==    by 0x422332: region_size_hints (in /usr/bin/notion)
==7319==    by 0x4229D8: region_size_hints_correct (in /usr/bin/notion)
==7319==    by 0x431BC6: sizepolicy (in /usr/bin/notion)
==7319==    by 0x433A5F: group_do_attach_final (in /usr/bin/notion)
==7319==    by 0x422021: ??? (in /usr/bin/notion)
==7319==    by 0x434F06: group_do_load (in /usr/bin/notion)
==7319==    by 0x436C1E: groupws_load (in /usr/bin/notion)
==7319==    by 0x426534: create_region_load (in /usr/bin/notion)
==7319==    by 0x42200D: ??? (in /usr/bin/notion)
==7319==    by 0x42C282: mplex_load_contents (in /usr/bin/notion)
==7319==    by 0x41B301: screen_init_layout (in /usr/bin/notion)
==7319== 
==7319== Conditional jump or move depends on uninitialised value(s)
==7319==    at 0x427157: frame_size_hints (in /usr/bin/notion)
==7319==    by 0x422332: region_size_hints (in /usr/bin/notion)
==7319==    by 0x4229D8: region_size_hints_correct (in /usr/bin/notion)
==7319==    by 0x431BC6: sizepolicy (in /usr/bin/notion)
==7319==    by 0x433A5F: group_do_attach_final (in /usr/bin/notion)
==7319==    by 0x422021: ??? (in /usr/bin/notion)
==7319==    by 0x434F06: group_do_load (in /usr/bin/notion)
==7319==    by 0x436C1E: groupws_load (in /usr/bin/notion)
==7319==    by 0x426534: create_region_load (in /usr/bin/notion)
==7319==    by 0x42200D: ??? (in /usr/bin/notion)
==7319==    by 0x42C282: mplex_load_contents (in /usr/bin/notion)
==7319==    by 0x41B301: screen_init_layout (in /usr/bin/notion)
==7319== 
==7319== Conditional jump or move depends on uninitialised value(s)
==7319==    at 0x427147: frame_size_hints (in /usr/bin/notion)
==7319==    by 0x422332: region_size_hints (in /usr/bin/notion)
==7319==    by 0x433DEC: group_size_hints (in /usr/bin/notion)
==7319==    by 0x422332: region_size_hints (in /usr/bin/notion)
==7319==    by 0x4229D8: region_size_hints_correct (in /usr/bin/notion)
==7319==    by 0x431806: ??? (in /usr/bin/notion)
==7319==    by 0x431D67: sizepolicy (in /usr/bin/notion)
==7319==    by 0x42B303: mplex_do_attach_final (in /usr/bin/notion)
==7319==    by 0x422021: ??? (in /usr/bin/notion)
==7319==    by 0x42C282: mplex_load_contents (in /usr/bin/notion)
==7319==    by 0x41B301: screen_init_layout (in /usr/bin/notion)
==7319==    by 0x42674C: ioncore_init_layout (in /usr/bin/notion)
==7319== 
==7319== Conditional jump or move depends on uninitialised value(s)
==7319==    at 0x427157: frame_size_hints (in /usr/bin/notion)
==7319==    by 0x422332: region_size_hints (in /usr/bin/notion)
==7319==    by 0x433DEC: group_size_hints (in /usr/bin/notion)
==7319==    by 0x422332: region_size_hints (in /usr/bin/notion)
==7319==    by 0x4229D8: region_size_hints_correct (in /usr/bin/notion)
==7319==    by 0x431806: ??? (in /usr/bin/notion)
==7319==    by 0x431D67: sizepolicy (in /usr/bin/notion)
==7319==    by 0x42B303: mplex_do_attach_final (in /usr/bin/notion)
==7319==    by 0x422021: ??? (in /usr/bin/notion)
==7319==    by 0x42C282: mplex_load_contents (in /usr/bin/notion)
==7319==    by 0x41B301: screen_init_layout (in /usr/bin/notion)
==7319==    by 0x42674C: ioncore_init_layout (in /usr/bin/notion)
==7319== 
attach WGroupCW<1> to WFrame<5>
attach WGroupCW<2> to WFrame<5>
==7319== Conditional jump or move depends on uninitialised value(s)
==7319==    at 0x4204F5: region_may_dispose (in /usr/bin/notion)
==7319==    by 0x420A78: region_rqdispose (in /usr/bin/notion)
==7319==    by 0x43B874: mainloop_execute_deferred_on_list (in /usr/bin/notion)
==7319==    by 0x4172EA: ioncore_mainloop (in /usr/bin/notion)
==7319==    by 0x414F12: main (in /usr/bin/notion)
==7319== 
==7319== Jump to the invalid address stated on the next line
==7319==    at 0x0: ???
==7319==    by 0x4204FD: region_may_dispose (in /usr/bin/notion)
==7319==    by 0x420A78: region_rqdispose (in /usr/bin/notion)
==7319==    by 0x43B874: mainloop_execute_deferred_on_list (in /usr/bin/notion)
==7319==    by 0x4172EA: ioncore_mainloop (in /usr/bin/notion)
==7319==    by 0x414F12: main (in /usr/bin/notion)
==7319==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==7319== 
notion: Caught fatal signal 11. Dying without deinit.
p==7319== 
==7319== HEAP SUMMARY:
==7319==     in use at exit: 1,781,500 bytes in 14,449 blocks
==7319==   total heap usage: 43,029 allocs, 28,580 frees, 5,543,173 bytes allocated
==7319== 
==7319== LEAK SUMMARY:
==7319==    definitely lost: 224 bytes in 1 blocks
==7319==    indirectly lost: 176 bytes in 2 blocks
==7319==      possibly lost: 0 bytes in 0 blocks
==7319==    still reachable: 1,781,100 bytes in 14,446 blocks
==7319==         suppressed: 0 bytes in 0 blocks
==7319== Rerun with --leak-check=full to see details of leaked memory
==7319== 
==7319== For counts of detected and suppressed errors, rerun with: -v
==7319== Use --track-origins=yes to see where uninitialised values come from
==7319== ERROR SUMMARY: 6 errors from 6 contexts (suppressed: 10 from 3)


-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

[Notion-general] Alt-Tab keymap

[Jeff A. <je...@pu...>]

I'd like to push most of notion's key bindings into a submap under
META-tab.  Since the docs say to use the names in xkeysym.h (xkeysymdef.h),
I tried

defbindings("WScreen", {
    submap(META..KB_Tab, {


and, since that didn't work,

defbindings("WScreen", {
    submap(META..Tab, {


In both cases, notion claims the binding is nil.  (META is correctly set to
Alt, which I verify by not trying to set this keymap.)

Am I missing something straightforward?

Thanks.

Jeff Abrahamson

http://jeff.purple.com/
http://blog.purple.com/jeff/

Re: [Notion-general] Switching workspaces independently

[Tilman B. <ti...@ba...>]

On 05/02/14 15:55, Arnout Engelen wrote:

>     The ~/.notion directory was from that version and nothing really
>     got changed in any of the files. Except that I disabled a few
>     modules like the statusbar.
>
>
> Sounds good... perhaps move it away just to be absolutely sure...
>  
>
>     I have notion version 3-2012042300 (Debian jessie)
>     But if you say this should be default, perhaps I should try the
>     latest upstream version. That Debian version obviously isn't the
>     freshest. Looking at the date...
>
>
> There's a more recent .deb for amd64 in the sf.net <http://sf.net> files.
>
Oh, cool. They work just fine. Since I wasn't on Debian stable I wasn't
really expecting to run on a prehistoric version. But I should have
known. :)

Re: [Notion-general] Switching workspaces independently

[Tilman B. <ti...@ba...>]

On 05/02/14 15:44, Arnout Engelen wrote:
> On Wed, Feb 5, 2014 at 4:21 PM, Tilman Baumann <ti...@ba...
> <mailto:ti...@ba...>> wrote:
>
>     the behaviour of notion to switch the workspaces on both screens
>     is driving me insane.
>     I loaded wrap_workspace_or_screen.lua and hooked the shortcuts up,
>     but it did not seem to do what I expected.
>
>     Short question, is there  way to switch workspaces independently
>     on different screens? And how is it done?
>
>
> If I'm understanding you correctly, notion should do this by default
> already. You should not need wrap_workspace_or_screen.lua .
>
> To make things a bit more explicit: when I start notion with 2
> monitors attached, notion will create a WScreen for each monitor. Each
> WScreen may contain several workspaces (showing one at a time).
>
> So when I hit Mod1+1 and Mod1+2 when the focus is on the left monitor,
> it switches the workspace on the left monitor.
> When I hit Mod1+1 and Mod1+2 when the focus is on the right monitor,
> it switches the workspace on the right monitor.
I thought it should. But it does not for me. Both screens always switch
in union.
>
> To be sure, perhaps check whether you have a recent version of Notion
> and move away your ~/.notion for a minute to check it's not your local
> configuration messing things up? Or am I perhaps misunderstanding you?

I have notion version 3-2012042300 (Debian jessie)
The ~/.notion directory was from that version and nothing really got
changed in any of the files. Except that I disabled a few modules like
the statusbar.

But if you say this should be default, perhaps I should try the latest
upstream version. That Debian version obviously isn't the freshest.
Looking at the date...

Cheers
 Tilman

[Notion-general] Switching workspaces independently

[Tilman B. <ti...@ba...>]

Hi,

I have been a ion3 and notion user for a while. Way back when I used a
dual head setup I actually ran two screens because of broken xinerama
back then.
Since then I only used one screen. But now I got two monitors again. And
the behaviour of notion to switch the workspaces on both screens is
driving me insane.
I loaded wrap_workspace_or_screen.lua and hooked the shortcuts up, but
it did not seem to do what I expected.

Short question, is there  way to switch workspaces independently on
different screens? And how is it done?

Thanks
 Tilman Baumann

[Notion-general] Fwd: [Notion-devel] Getting notion out of Debian/non-free

[Arnout E. <no...@bz...>]

On Sat, Jan 18, 2014 at 11:17 AM, Dima Kogan <no...@di...>wrote:

> First off, in 2009 Tuomo updated the license, removing the 28-day
>  clause. Notion's LICENSE file did not have this change. I'm attaching a
> patch with the update. The mailing list post is
>
>
> https://lists.berlios.de/pipermail/ion-general/2009-September/001730.html[1]
>

Interesting, thanks for the heads-up.

Generally it is of course very strange to 'patch in' a license change into
a software - normally you can't legally do that. However in this case Tuomo
clearly expresses his intent and GPG-signed the updated license, to it
seems justified here. Unless someone objects, I'll probably apply the patch.



> [[the Ion license]] clearly states that if 'Ion(tm)' can be associated
> with the
>
> software, then the software must be renamed (i.e. an association comes
> from the name). I think a strong case can be made that this is
> DFSG-compliant. Ben's personal communication with Tuomo seems to
> indicate a stronger condition than the text, but the text is what
> defines the license, as you say.
>

Exactly, good summary.


> When did you bring this up with debian-legal? Possibly we should bring
> this up again. I can do this, if you like. Doing lots of debian things
> these days...


I'll try and look it up.


Arnout

Re: [Notion-general] Cannot configure Dolphin Emulator on Notion

[Arnout E. <no...@bz...>]

Hello Robin,

The crash you describe should be fixed in notion git.


Kind regards,

Arnout


On Wed, Nov 27, 2013 at 10:35 AM, Arnout Engelen <no...@bz...> wrote:

> Hi,
>
> I compiled dolphin-emu from https://dolphin-emu.org git and for me it
> briefly pops up a window and then immediately crashes with BadAlloc.
>
> Attaching a debugger I get:
>
> Reading symbols from
> /home/arnouten/dev/dolphin-emu/Binaries/dolphin-emu...(no debugging symbols
> found)...done.
> (gdb) break main
> Breakpoint 1 at 0x469070
> (gdb) run --sync
> Starting program: /home/arnouten/dev/dolphin-emu/./Binaries/dolphin-emu
> --sync
> warning: Could not load shared library symbols for linux-vdso.so.1.
> Do you need "set solib-search-path" or "set sysroot"?
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
> Breakpoint 1, 0x0000000000469070 in main ()
> (gdb) break exit
> Breakpoint 2 at 0x7ffff3334b10: file exit.c, line 99.
> (gdb) continue
> Continuing.
> 27:23:520
> /home/arnouten/dev/dolphin-emu/Source/Core/DiscIO/Src/NANDContentLoader.cpp:216
> W[DIO]: CreateFromDirectory: error opening
> /home/arnouten/.dolphin-emu/Wii/title/00000001/00000002/content/title.tmd
> 27:23:613
> /home/arnouten/dev/dolphin-emu/Source/Core/DiscIO/Src/NANDContentLoader.cpp:216
> W[DIO]: CreateFromDirectory: error opening
> /home/arnouten/.dolphin-emu/Wii/title/00000001/00000002/content/title.tmd
>  The program 'dolphin-emu' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadAlloc (insufficient resources for operation)'.
>   (Details: serial 11264 error_code 11 request_code 53 minor_code 0)
>   (Note to programmers: normally, X errors are reported asynchronously;
>    that is, you will receive the error a while after causing it.
>    To debug your program, run it with the --sync command line
>    option to change this behavior. You can then get a meaningful
>    backtrace from your debugger if you break on the gdk_x_error()
> function.)
>
> Breakpoint 2, __GI_exit (status=status@entry=1) at exit.c:99
> 99      exit.c: No such file or directory.
> (gdb) where
> #0  __GI_exit (status=status@entry=1) at exit.c:99
> #1  0x00007ffff6f62c3f in gdk_x_error (display=<optimized out>,
> error=<optimized out>) at
> /tmp/buildd/gtk+2.0-2.24.22/gdk/x11/gdkmain-x11.c:490
> #2  0x00007ffff5a24cdb in _XError (dpy=dpy@entry=0x5042630, rep=rep@entry=0x5404680)
> at ../../src/XlibInt.c:1463
> #3  0x00007ffff5a21d57 in handle_error (dpy=0x5042630, err=0x5404680,
> in_XReply=<optimized out>) at ../../src/xcb_io.c:213
> #4  0x00007ffff5a21e05 in handle_response (dpy=dpy@entry=0x5042630,
> response=0x5404680, in_XReply=in_XReply@entry=1) at ../../src/xcb_io.c:325
> #5  0x00007ffff5a22d00 in _XReply (dpy=dpy@entry=0x5042630, rep=rep@entry=0x7fffffffd330,
> extra=extra@entry=0, discard=discard@entry=1) at ../../src/xcb_io.c:627
> #6  0x00007ffff5a1e83d in XSync (dpy=0x5042630, discard=discard@entry=0)
> at ../../src/Sync.c:44
> #7  0x00007ffff5a1e8cb in _XSyncFunction (dpy=<optimized out>) at
> ../../src/Synchro.c:35
> #8  0x00007ffff5a02a50 in XCreatePixmap (dpy=0x5042630, d=67109319,
> width=width@entry=65535, height=height@entry=65535, depth=depth@entry=24)
>     at ../../src/CrPixmap.c:58
> #9  0x00007ffff6f63908 in _gdk_pixmap_new (drawable=0x5355360,
> width=width@entry=65535, height=height@entry=65535, depth=24, depth@entry
> =-1)
>     at /tmp/buildd/gtk+2.0-2.24.22/gdk/x11/gdkpixmap-x11.c:175
> #10 0x00007ffff6f31e8a in IA__gdk_pixmap_new (drawable=drawable@entry=0x5355360,
> width=width@entry=65535, height=height@entry=65535, depth=depth@entry=-1)
>     at /tmp/buildd/gtk+2.0-2.24.22/gdk/gdkpixmap.c:249
> #11 0x00007ffff6f4085d in gdk_window_begin_implicit_paint
> (rect=0x7fffffffd440, window=0x5355360) at
> /tmp/buildd/gtk+2.0-2.24.22/gdk/gdkwindow.c:2779
> #12 gdk_window_process_updates_internal (window=window@entry=0x5355360)
> at /tmp/buildd/gtk+2.0-2.24.22/gdk/gdkwindow.c:5580
> #13 0x00007ffff6f412fd in IA__gdk_window_process_updates
> (window=0x5355360, update_children=1) at
> /tmp/buildd/gtk+2.0-2.24.22/gdk/gdkwindow.c:5768
> #14 0x00007ffff6b1529a in gtk_window_move_resize (window=0x5162ab0) at
> /tmp/buildd/gtk+2.0-2.24.22/gtk/gtkwindow.c:6246
> #15 gtk_window_check_resize (container=0x5162ab0) at
> /tmp/buildd/gtk+2.0-2.24.22/gtk/gtkwindow.c:5408
> #16 0x00007ffff73e5157 in _g_closure_invoke_va (closure=0x50a2a50,
> return_value=0x0, instance=0x5162ab0, args=0x7fffffffd788, n_params=0,
> param_types=0x0)
>     at /tmp/buildd/glib2.0-2.36.4/./gobject/gclosure.c:840
> #17 0x00007ffff73fd248 in g_signal_emit_valist (instance=0x5162ab0,
> signal_id=<optimized out>, detail=0, var_args=var_args@entry
> =0x7fffffffd788)
>     at /tmp/buildd/glib2.0-2.36.4/./gobject/gsignal.c:3234
> #18 0x00007ffff73fdf32 in g_signal_emit (instance=<optimized out>,
> signal_id=<optimized out>, detail=<optimized out>)
>     at /tmp/buildd/glib2.0-2.36.4/./gobject/gsignal.c:3384
> #19 0x00007ffff697f620 in gtk_container_idle_sizer (data=<optimized out>)
> at /tmp/buildd/gtk+2.0-2.24.22/gtk/gtkcontainer.c:1357
> #20 0x00007ffff6f20b77 in gdk_threads_dispatch (data=0x538d980) at
> /tmp/buildd/gtk+2.0-2.24.22/gdk/gdk.c:512
> #21 0x00007ffff766cea6 in g_main_dispatch (context=0x5064d70) at
> /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3054
> #22 g_main_context_dispatch (context=context@entry=0x5064d70) at
> /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3630
> #23 0x00007ffff766d1f8 in g_main_context_iterate (context=0x5064d70,
> block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
>     at /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3701
> #24 0x00007ffff766d5fa in g_main_loop_run (loop=0x5379390) at
> /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3895
> #25 0x00007ffff69f52e7 in IA__gtk_main () at
> /tmp/buildd/gtk+2.0-2.24.22/gtk/gtkmain.c:1257
> #26 0x00000000009fe1c5 in wxGUIEventLoop::DoRun() ()
> #27 0x00000000007c9acf in wxEventLoopBase::Run() ()
> #28 0x00000000009f58c9 in wxDialog::ShowModal() ()
> #29 0x000000000099c3af in
> wxLogGui::DoShowMultipleLogMessages(wxArrayString const&, wxArrayInt
> const&, wxArrayLong const&, wxString const&, int) ()
> #30 0x000000000099cd93 in wxLogGui::Flush() ()
> #31 0x000000000074a19c in wxAppConsoleBase::ProcessIdle() ()
> #32 0x0000000000754b3f in wxAppBase::ProcessIdle() ()
> #33 0x00000000009cc65e in wxApp::DoIdle() ()
> #34 0x00000000009cc730 in wxapp_idle_callback ()
> #35 0x00007ffff766cea6 in g_main_dispatch (context=0x5064d70) at
> /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3054
> #36 g_main_context_dispatch (context=context@entry=0x5064d70) at
> /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3630
> #37 0x00007ffff766d1f8 in g_main_context_iterate (context=0x5064d70,
> block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
>     at /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3701
> #38 0x00007ffff766d5fa in g_main_loop_run (loop=0x513b2d0) at
> /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3895
> #39 0x00007ffff69f52e7 in IA__gtk_main () at
> /tmp/buildd/gtk+2.0-2.24.22/gtk/gtkmain.c:1257
> #40 0x00000000009fe1c5 in wxGUIEventLoop::DoRun() ()
> #41 0x00000000007c9acf in wxEventLoopBase::Run() ()
> #42 0x00000000007529ec in wxAppConsoleBase::MainLoop() ()
> #43 0x000000000083b2d1 in wxEntry(int&, char**) ()
> #44 0x0000000000469098 in main ()
>
> .. looks like it creates a pixmap of size 65535x65535, which is probably a
> bug: that's -1 by -1. Strange that this doesn't pop up on blackbox. when I
> run 'xwininfo -root -tree', I see a number of nameless X11 windows with
> size -1x-1. I wonder what those are - if they're 'dummy' windows created by
> Notion that could be where the -1x-1 comes from, though I thought we're
> naming all the windows we create now.
>
>
> Kind regards,
>
> Arnout
>
>
> On Sat, Aug 10, 2013 at 3:20 PM, Robin Chew <rob...@gm...> wrote:
>
>> Hello there,
>>
>> The Dolphin Wii Emulator crashes immediately after clicking on Config,
>> Graphics, DSP, GCPad or Wiimote button, and probably others as well. I'm
>> using the notion window manager of course, but if I use blackbox window
>> manager instead, there is no problem. I'm using dual monitor as well, in
>> case it is relevant.
>>
>> See following error. Anyone can reproduce it?
>>
>> ~$ dolphin-emu
>> Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
>> configurations from ~/.fonts.conf is deprecated.
>> The program 'dolphin-emu' received an X Window System error.
>> This probably reflects a bug in the program.
>> The error was 'BadAlloc (insufficient resources for operation)'.
>>   (Details: serial 9056 error_code 11 request_code 53 minor_code 0)
>>   (Note to programmers: normally, X errors are reported asynchronously;
>>    that is, you will receive the error a while after causing it.
>>    To debug your program, run it with the --sync command line
>>    option to change this behavior. You can then get a meaningful
>>    backtrace from your debugger if you break on the gdk_x_error()
>> function.)
>>
>> Anyway, great window manager, won't use any other, except blackbox of
>> course for launching the emulator.
>>
>> Robin
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Notion-general mailing list
>> Not...@li...
>> https://lists.sourceforge.net/lists/listinfo/notion-general
>>
>>
>
>

[Notion-general] Fwd: Cannot configure Dolphin Emulator on Notion

[Arnout E. <no...@bz...>]

Hi,

I compiled dolphin-emu from https://dolphin-emu.org git and for me it
briefly pops up a window and then immediately crashes with BadAlloc.

Attaching a debugger I get:

Reading symbols from
/home/arnouten/dev/dolphin-emu/Binaries/dolphin-emu...(no debugging symbols
found)...done.
(gdb) break main
Breakpoint 1 at 0x469070
(gdb) run --sync
Starting program: /home/arnouten/dev/dolphin-emu/./Binaries/dolphin-emu
--sync
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x0000000000469070 in main ()
(gdb) break exit
Breakpoint 2 at 0x7ffff3334b10: file exit.c, line 99.
(gdb) continue
Continuing.
27:23:520
/home/arnouten/dev/dolphin-emu/Source/Core/DiscIO/Src/NANDContentLoader.cpp:216
W[DIO]: CreateFromDirectory: error opening
/home/arnouten/.dolphin-emu/Wii/title/00000001/00000002/content/title.tmd
27:23:613
/home/arnouten/dev/dolphin-emu/Source/Core/DiscIO/Src/NANDContentLoader.cpp:216
W[DIO]: CreateFromDirectory: error opening
/home/arnouten/.dolphin-emu/Wii/title/00000001/00000002/content/title.tmd
The program 'dolphin-emu' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 11264 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Breakpoint 2, __GI_exit (status=status@entry=1) at exit.c:99
99      exit.c: No such file or directory.
(gdb) where
#0  __GI_exit (status=status@entry=1) at exit.c:99
#1  0x00007ffff6f62c3f in gdk_x_error (display=<optimized out>,
error=<optimized out>) at
/tmp/buildd/gtk+2.0-2.24.22/gdk/x11/gdkmain-x11.c:490
#2  0x00007ffff5a24cdb in _XError (dpy=dpy@entry=0x5042630,
rep=rep@entry=0x5404680)
at ../../src/XlibInt.c:1463
#3  0x00007ffff5a21d57 in handle_error (dpy=0x5042630, err=0x5404680,
in_XReply=<optimized out>) at ../../src/xcb_io.c:213
#4  0x00007ffff5a21e05 in handle_response (dpy=dpy@entry=0x5042630,
response=0x5404680, in_XReply=in_XReply@entry=1) at ../../src/xcb_io.c:325
#5  0x00007ffff5a22d00 in _XReply (dpy=dpy@entry=0x5042630,
rep=rep@entry=0x7fffffffd330,
extra=extra@entry=0, discard=discard@entry=1) at ../../src/xcb_io.c:627
#6  0x00007ffff5a1e83d in XSync (dpy=0x5042630, discard=discard@entry=0) at
../../src/Sync.c:44
#7  0x00007ffff5a1e8cb in _XSyncFunction (dpy=<optimized out>) at
../../src/Synchro.c:35
#8  0x00007ffff5a02a50 in XCreatePixmap (dpy=0x5042630, d=67109319,
width=width@entry=65535, height=height@entry=65535, depth=depth@entry=24)
    at ../../src/CrPixmap.c:58
#9  0x00007ffff6f63908 in _gdk_pixmap_new (drawable=0x5355360,
width=width@entry=65535, height=height@entry=65535, depth=24, depth@entry
=-1)
    at /tmp/buildd/gtk+2.0-2.24.22/gdk/x11/gdkpixmap-x11.c:175
#10 0x00007ffff6f31e8a in IA__gdk_pixmap_new
(drawable=drawable@entry=0x5355360,
width=width@entry=65535, height=height@entry=65535, depth=depth@entry=-1)
    at /tmp/buildd/gtk+2.0-2.24.22/gdk/gdkpixmap.c:249
#11 0x00007ffff6f4085d in gdk_window_begin_implicit_paint
(rect=0x7fffffffd440, window=0x5355360) at
/tmp/buildd/gtk+2.0-2.24.22/gdk/gdkwindow.c:2779
#12 gdk_window_process_updates_internal (window=window@entry=0x5355360) at
/tmp/buildd/gtk+2.0-2.24.22/gdk/gdkwindow.c:5580
#13 0x00007ffff6f412fd in IA__gdk_window_process_updates (window=0x5355360,
update_children=1) at /tmp/buildd/gtk+2.0-2.24.22/gdk/gdkwindow.c:5768
#14 0x00007ffff6b1529a in gtk_window_move_resize (window=0x5162ab0) at
/tmp/buildd/gtk+2.0-2.24.22/gtk/gtkwindow.c:6246
#15 gtk_window_check_resize (container=0x5162ab0) at
/tmp/buildd/gtk+2.0-2.24.22/gtk/gtkwindow.c:5408
#16 0x00007ffff73e5157 in _g_closure_invoke_va (closure=0x50a2a50,
return_value=0x0, instance=0x5162ab0, args=0x7fffffffd788, n_params=0,
param_types=0x0)
    at /tmp/buildd/glib2.0-2.36.4/./gobject/gclosure.c:840
#17 0x00007ffff73fd248 in g_signal_emit_valist (instance=0x5162ab0,
signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffd788)
    at /tmp/buildd/glib2.0-2.36.4/./gobject/gsignal.c:3234
#18 0x00007ffff73fdf32 in g_signal_emit (instance=<optimized out>,
signal_id=<optimized out>, detail=<optimized out>)
    at /tmp/buildd/glib2.0-2.36.4/./gobject/gsignal.c:3384
#19 0x00007ffff697f620 in gtk_container_idle_sizer (data=<optimized out>)
at /tmp/buildd/gtk+2.0-2.24.22/gtk/gtkcontainer.c:1357
#20 0x00007ffff6f20b77 in gdk_threads_dispatch (data=0x538d980) at
/tmp/buildd/gtk+2.0-2.24.22/gdk/gdk.c:512
#21 0x00007ffff766cea6 in g_main_dispatch (context=0x5064d70) at
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3054
#22 g_main_context_dispatch (context=context@entry=0x5064d70) at
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3630
#23 0x00007ffff766d1f8 in g_main_context_iterate (context=0x5064d70,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3701
#24 0x00007ffff766d5fa in g_main_loop_run (loop=0x5379390) at
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3895
#25 0x00007ffff69f52e7 in IA__gtk_main () at
/tmp/buildd/gtk+2.0-2.24.22/gtk/gtkmain.c:1257
#26 0x00000000009fe1c5 in wxGUIEventLoop::DoRun() ()
#27 0x00000000007c9acf in wxEventLoopBase::Run() ()
#28 0x00000000009f58c9 in wxDialog::ShowModal() ()
#29 0x000000000099c3af in wxLogGui::DoShowMultipleLogMessages(wxArrayString
const&, wxArrayInt const&, wxArrayLong const&, wxString const&, int) ()
#30 0x000000000099cd93 in wxLogGui::Flush() ()
#31 0x000000000074a19c in wxAppConsoleBase::ProcessIdle() ()
#32 0x0000000000754b3f in wxAppBase::ProcessIdle() ()
#33 0x00000000009cc65e in wxApp::DoIdle() ()
#34 0x00000000009cc730 in wxapp_idle_callback ()
#35 0x00007ffff766cea6 in g_main_dispatch (context=0x5064d70) at
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3054
#36 g_main_context_dispatch (context=context@entry=0x5064d70) at
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3630
#37 0x00007ffff766d1f8 in g_main_context_iterate (context=0x5064d70,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3701
#38 0x00007ffff766d5fa in g_main_loop_run (loop=0x513b2d0) at
/tmp/buildd/glib2.0-2.36.4/./glib/gmain.c:3895
#39 0x00007ffff69f52e7 in IA__gtk_main () at
/tmp/buildd/gtk+2.0-2.24.22/gtk/gtkmain.c:1257
#40 0x00000000009fe1c5 in wxGUIEventLoop::DoRun() ()
#41 0x00000000007c9acf in wxEventLoopBase::Run() ()
#42 0x00000000007529ec in wxAppConsoleBase::MainLoop() ()
#43 0x000000000083b2d1 in wxEntry(int&, char**) ()
#44 0x0000000000469098 in main ()

.. looks like it creates a pixmap of size 65535x65535, which is probably a
bug: that's -1 by -1. Strange that this doesn't pop up on blackbox. when I
run 'xwininfo -root -tree', I see a number of nameless X11 windows with
size -1x-1. I wonder what those are - if they're 'dummy' windows created by
Notion that could be where the -1x-1 comes from, though I thought we're
naming all the windows we create now.


Kind regards,

Arnout


On Sat, Aug 10, 2013 at 3:20 PM, Robin Chew <rob...@gm...> wrote:

> Hello there,
>
> The Dolphin Wii Emulator crashes immediately after clicking on Config,
> Graphics, DSP, GCPad or Wiimote button, and probably others as well. I'm
> using the notion window manager of course, but if I use blackbox window
> manager instead, there is no problem. I'm using dual monitor as well, in
> case it is relevant.
>
> See following error. Anyone can reproduce it?
>
> ~$ dolphin-emu
> Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 14: reading
> configurations from ~/.fonts.conf is deprecated.
> The program 'dolphin-emu' received an X Window System error.
> This probably reflects a bug in the program.
> The error was 'BadAlloc (insufficient resources for operation)'.
>   (Details: serial 9056 error_code 11 request_code 53 minor_code 0)
>   (Note to programmers: normally, X errors are reported asynchronously;
>    that is, you will receive the error a while after causing it.
>    To debug your program, run it with the --sync command line
>    option to change this behavior. You can then get a meaningful
>    backtrace from your debugger if you break on the gdk_x_error()
> function.)
>
> Anyway, great window manager, won't use any other, except blackbox of
> course for launching the emulator.
>
> Robin
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Notion-general mailing list
> Not...@li...
> https://lists.sourceforge.net/lists/listinfo/notion-general
>
>