Re: Ping Packagers
* Brian Kroth had this to say on [24 Dec 2009, 12:14:43 -0600]: Dustin Kirkland kirkl...@canonical.com 2009-12-22 10:42: On Mon, Dec 21, 2009 at 10:33 AM, Sadrul Habib Chowdhury ima...@gmail.com wrote: I don't think there will be much of a problem using dynamic malloc in the current code. However, it can be problematic for when we merge in the scripting support. For example, a script could store the window pointers somewhere, and use them in a callback. A dynamic malloc will either cause this to crash, or require complicated checks in the script (or the script loaders). So to keep it 'forward-compatible', perhaps increase the default limit to 100, and allow increasing the limit only when creating a new session. How does that sound? I think 100 sounds reasonable. Agreed. I also like the idea of being able to specify it at session creation time. Just an FYI, I have already made this change. Screen already had a command 'maxwin', execpt previously, it was not possible to increase the value of maxwin. Now, the initial value is set to 100, and it can be increased to a higher value, but you would have to do it before any window is created. (so you would put 'maxwin 500' in your .screenrc before any 'screen' command you might have). Cheers, Sadrul ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: Ping Packagers
Oh, and also, the number of text-attribute-changes in the caption/hardstaus has also been increased to 256. http://git.savannah.gnu.org/gitweb/?p=screen.git;a=commitdiff;h=e6a28cf8bfdac15faa6c267bf476ddcaddf48d67;hp=f33e5cdecb7bf3b6ae8e4a5c0ca394dd5a06a416 Cheers, Sadrul ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: Ping Packagers
On Sat, Dec 19, 2009 at 07:29:47PM -0500, Sadrul Habib Chowdhury wrote: http://cvs.fedoraproject.org/viewvc/devel/screen/ screen-4.0.2-maxstr.patch It looks like MAXSTR has been increased to 512. It can still be increased more, of course. Is there a bug-report somewhere that requested for this change? I would like to know exactly what problems the limitations caused. The changelog mentions only the problem with too many windows open. screen-4.0.3-stropts.patch I believe e3b1d2c50a5cc84a0985dbf608b9ee47996b7e47 takes care of this? (i.e. using HAVE_STROPTS_H) It does. Thanks, -- Miroslav Lichvar ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: Ping Packagers
* Dustin Kirkland had this to say on [20 Dec 2009, 21:18:04 -0600]:
[snip]
33increase_max_winmsg_renditions.dpatch
I think 256 is a bit too excessive. I am going to increase it to 128
instead, which I honestly think should be more than enough.
Hmm, what's the actual cost? Some memory? How much? Would it be
realistic to make this dynamically allocated?
The cost of increasing to 256 is not much, in fact, it can be increased
to an even larger value, say 1024, without causing any performance
issues. But it wouldn't make any sense to me.
I maintain a project that provides a layer on top of Screen called
Byobu. We make heavy use of the hard status formatting with a series
of several dozen toggle on/off status scripts. With 1920x1080
displays, and an 8 pitch font, there's a lot of room across the bottom
of the screen.
See for an example this screenshot (with almost everything toggled on):
http://rookery.canonical.com/~kirkland/Byobu.png
uh, ew!
For each color change, I also use \005{-} to undo it, and bring it
back to the native color. This means that each color change costs 2
against that 128 or 256 number. They add up quickly.
I appreciate your bumping it up to 128. We will probably continue to
carry a patch for 256 in Ubuntu. Assuming it's not too expensive, it
would be nice if you would reconsider. Thanks.
Let's put it this way, I will definitely reconsider if someone is trying
to use a caption/hardstatus string that requires more than 128 changes ;)
I am also considering increasing the oft requested window limit. That
will probably require a bit more work than just changing the define.
Definitely would be nice. I'm currently hitting the limit at 40
windows. What are you thinking for a limit? Again, a dynamic malloc
would be nice (haven't looked at the code to judge the feasibility,
though).
I don't think there will be much of a problem using dynamic malloc in the
current code. However, it can be problematic for when we merge in the
scripting support. For example, a script could store the window pointers
somewhere, and use them in a callback. A dynamic malloc will either cause
this to crash, or require complicated checks in the script (or the script
loaders).
So to keep it 'forward-compatible', perhaps increase the default limit to
100, and allow increasing the limit only when creating a new session. How
does that sound?
[snip]
56-source-file-not-found-warning.dpatch
I disagree with this change. I think the error message is appropriate.
Understood. Would you support an additional, new directive that would
source-if-found, but throw no warning if not? Something like
-source or @source a la Makefile syntax?
Perhaps 'source -q'?
I quite like the idea of a generic syntax for suppressing error messages
for all commands, using '@' or somesuch as a prefix, though. So either
'source -q' or all '@command' will suppress the error messages. Sounds
good?
58-show-encoding-hardstatus.dpatch
I don't like this patch. I wouldn't want more string escapes unless they
are really useful. In this case, I am not convinced that showing the
encoding in the caption is all that useful. This information is available
in 'info'. Is there a use case where that's not enough?
I'm not sure. An Ubuntu user complained about this, and provided a
patch that seemed to work for me. It didn't bother me as a packager,
so I included it. If it's ill-advised, or evil somehow, I can drop it
and inform the user that upstream rejected it.
The problem here is this: the caption/hardstatus string is way too
complex as it is. Adding more clutter to it is only going to make things
worse. So unless really necessary, I plan to not add any more escapes. In
this case, if there is a use-case that the user needs to be aware of the
encoding in a particular window frequently enough, then this issue can be
reconsidered.
Eventually, when scripting support comes in, this kind of thing
will be more possible, and users can add anything in there. But for now,
what we have, is what we have :)
Perfection is reached not when there is nothing left to add, but when
there is nothing left to take away. is the philosophy I am trying to
follow.
[snip]
I can't get the rest of them at the moment, setting an Internal Server
Error from launchpad.
Sorry about that. There was a Launchpad maintenance window recently,
maybe you hit that.
Yep, they came back up. But I haven't had a chance to look at them yet.
Thanks for going over these!
In the future, what's the currently preferred mechanism for patch
submission? Devel mailing list, bug tracker, or otherwise?
I think I would prefer the bug-tracker at savannah [1]. That way there's
less chance of a patch getting lost. Any activity in the bug-tracker will
now send mails to the devel mailing list, too.
[1] https://savannah.gnu.org/bugs/?group=screen
Cheers,
Sadrul
___
Re: Ping Packagers
* Miroslav Lichvar had this to say on [10 Dec 2009, 10:35:00 +0100]: On Wed, Dec 09, 2009 at 01:19:00PM -0500, Sadrul Habib Chowdhury wrote: Hello everyone. Are there any screen packagers on this list? I am contemplating a sort of a beta-release somewhat soon-ish (still non-trivial amount of work to do, though, so no ETA yet), and was thinking if this list is the best place to reach the packagers. Hi, I'm the maintainer for Fedora. You can see the patches we are currently using here: http://cvs.fedoraproject.org/viewvc/devel/screen/ Thanks for the link. I looked at a number of them: screen-4.0.1-args.patch Applied after some change (7ac593d74dfd2243cd60c5d848547ebd9971a8b0). I didn't include the change in ansi.c: w_NumArgs should never be negative. If something is causing is to be set to a negative number, then that's a bug and we need to figure where/why/how that happens, so the real bug can be fixed. screen-4.0.2-maxstr.patch It looks like MAXSTR has been increased to 512. It can still be increased more, of course. Is there a bug-report somewhere that requested for this change? I would like to know exactly what problems the limitations caused. screen-4.0.3-libs.patch I plan to take a look at https://savannah.gnu.org/bugs/?27318 first. screen-4.0.3-resize.patch Already in. screen-4.0.3-ipv6.patch Need to take a closer look. screen-4.0.3-stropts.patch I believe e3b1d2c50a5cc84a0985dbf608b9ee47996b7e47 takes care of this? (i.e. using HAVE_STROPTS_H) Cheers, Sadrul ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: Ping Packagers
To Dustin/Sadrul: So long as we're considering some changes, can I petition to have the default MAXWIN increased from 40 to 99 (or higher)? We have a screenrc for our ssh bastion host that sets up 40 ssh sessions by default and we always end up recompiling screen to support this. Thanks, Brian Sadrul Habib Chowdhury ima...@gmail.com 2009-12-09 14:28: * Dustin Kirkland had this to say on [09 Dec 2009, 10:37:17 -0800]: On Wed, Dec 9, 2009 at 10:23 AM, Dustin Kirkland kirkl...@canonical.com wrote: On Wed, Dec 9, 2009 at 10:19 AM, Sadrul Habib Chowdhury ima...@gmail.com wrote: Hello everyone. Are there any screen packagers on this list? I am contemplating a sort of a beta-release somewhat soon-ish (still non-trivial amount of work to do, though, so no ETA yet), and was thinking if this list is the best place to reach the packagers. Hello- I maintain (along with some others) the screen package in Ubuntu, and I do follow this list. We (Ubuntu) as well as Debian are carrying a stack of patches against Screen. Could we see about getting as many of these as possible into your next upstream release? FYI, you can see the patches we're carrying at: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/screen/karmic/files/head%3A/debian/patches/ Great! Thanks (I was about to request for the link) The vast majority of these patches predate my involvement and are merely inherited from Debian. The one that I most importantly want to get upstream is the trivial 33increase_max_winmsg_renditions.dpatch: http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/karmic/screen/karmic/annotate/head%3A/debian/patches/33increase_max_winmsg_renditions.dpatch How would you like to proceed? Should I repost each and every one of these individually to the list? Or can you take a look at each of them, and cherry pick the ones that are immediately acceptable, and we can debate the rest? It's not necessary to post them in the Savannah tracker for now. I will take a look at the patches (hopefully during this weekend) and let you know if I have any questions about any of them. Thanks. :-Dustin Cheers, Sadrul ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: Ping Packagers
On Fri, Dec 11, 2009 at 8:29 AM, Brian Kroth bpkr...@gmail.com wrote: So long as we're considering some changes, can I petition to have the default MAXWIN increased from 40 to 99 (or higher)? We have a screenrc for our ssh bastion host that sets up 40 ssh sessions by default and we always end up recompiling screen to support this. Hi Brian- I have no say in what goes in upstream, but if you can demonstrate (or tell me) that changing this value doesn't cause regression elsewhere, I don't have a problem carrying such a patch in Ubuntu. If you specifically want this in the Ubuntu screen package, please file a bug at https://bugs.launchpad.net/ubuntu/+source/screen/+filebug. But ideally, upstream would sign off on this, and integrate it into the next release, if it's reasonable ;-) Cheers, :-Dustin ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: Ping Packagers
* Miroslav Lichvar had this to say on [10 Dec 2009, 10:35:00 +0100]: On Wed, Dec 09, 2009 at 01:19:00PM -0500, Sadrul Habib Chowdhury wrote: Hello everyone. Are there any screen packagers on this list? I am contemplating a sort of a beta-release somewhat soon-ish (still non-trivial amount of work to do, though, so no ETA yet), and was thinking if this list is the best place to reach the packagers. Hi, I'm the maintainer for Fedora. You can see the patches we are currently using here: http://cvs.fedoraproject.org/viewvc/devel/screen/ Great. Thanks. I plan to take a look at these too during next weekend. Cheers, Sadrul ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: Ping Packagers
On Wed, Dec 9, 2009 at 10:19 AM, Sadrul Habib Chowdhury ima...@gmail.com wrote: Hello everyone. Are there any screen packagers on this list? I am contemplating a sort of a beta-release somewhat soon-ish (still non-trivial amount of work to do, though, so no ETA yet), and was thinking if this list is the best place to reach the packagers. Hello- I maintain (along with some others) the screen package in Ubuntu, and I do follow this list. We (Ubuntu) as well as Debian are carrying a stack of patches against Screen. Could we see about getting as many of these as possible into your next upstream release? :-Dustin ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: Ping Packagers
* Dustin Kirkland had this to say on [09 Dec 2009, 10:37:17 -0800]: On Wed, Dec 9, 2009 at 10:23 AM, Dustin Kirkland kirkl...@canonical.com wrote: On Wed, Dec 9, 2009 at 10:19 AM, Sadrul Habib Chowdhury ima...@gmail.com wrote: Hello everyone. Are there any screen packagers on this list? I am contemplating a sort of a beta-release somewhat soon-ish (still non-trivial amount of work to do, though, so no ETA yet), and was thinking if this list is the best place to reach the packagers. Hello- I maintain (along with some others) the screen package in Ubuntu, and I do follow this list. We (Ubuntu) as well as Debian are carrying a stack of patches against Screen. Could we see about getting as many of these as possible into your next upstream release? FYI, you can see the patches we're carrying at: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/screen/karmic/files/head%3A/debian/patches/ Great! Thanks (I was about to request for the link) The vast majority of these patches predate my involvement and are merely inherited from Debian. The one that I most importantly want to get upstream is the trivial 33increase_max_winmsg_renditions.dpatch: http://bazaar.launchpad.net/%7Eubuntu-branches/ubuntu/karmic/screen/karmic/annotate/head%3A/debian/patches/33increase_max_winmsg_renditions.dpatch How would you like to proceed? Should I repost each and every one of these individually to the list? Or can you take a look at each of them, and cherry pick the ones that are immediately acceptable, and we can debate the rest? It's not necessary to post them in the Savannah tracker for now. I will take a look at the patches (hopefully during this weekend) and let you know if I have any questions about any of them. Thanks. :-Dustin Cheers, Sadrul ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
