Re: [diff] selectable curves in smtpd ?
On Sat, Aug 12, 2023 at 03:21:00PM +, gil...@poolp.org wrote: > August 12, 2023 4:34 PM, "Theo Buehler" wrote: > > > On Sat, Aug 12, 2023 at 02:29:45PM +, gil...@poolp.org wrote: > > > >> Hello, > >> > >> Someone asked about selectable curves in the OpenSMTPD portable tracker, > >> and it turns out I had a diff for that among a few others. > > > > Why do they need this? > > I suspect for the same reason people have needed ciphers selection in the > past, > being able to comply with the requirements of some certification (iirc, > medical > mail systems, for example, have strict requirements regarding their setup). > > Anyways, I've written this a long time ago and I'm providing it in case it's > of > any interest, feel free to discard. > This is moving *backwards* from best practices. Notice that TLS 1.3 did remove EC parameters choice, because this could lead to downgrade MIT attacks.
Re: standardize and simplify GitHub submodule handling in ports?
Some comments already. I haven't looked very closely.
On Sat, Aug 05, 2023 at 03:12:18PM -0400, Thomas Frohwein wrote:
> The current draft hijacks post-extract target, but it would be easy to
> add this to _post-extract-finalize in bsd.port.mk similar to how the
> post-extract commands from modules are handled, if this is of interest.
Please do that.
> # where submodule distfiles will be stored
> GHSM_DIST_SUBDIR ?= gh-submodules
Please keep to the GH_* subspace.
Already, modules usually use MOD* variable names, but in the GH case, that
would be a bit long.
> .for _ghaccount _ghproject _ghtagcommit _targetdir in ${GH_SUBMODULES}
> DISTFILES +=
> ${GHSM_DIST_SUBDIR}/{}${_ghaccount}/${_ghproject}/archive/${_ghtagcommit}${GH_SUFX}:${GHSM_MASTER_SITESN}
> .endfor
>
> # post-extract target for moving the submodules to the target directories
> GHSM_post-extract =
> .for _ghaccount _ghproject _ghtagcommit _targetdir in ${GH_SUBMODULES}
> GHSM_post-extract += \
> test -d ${GHSM_WRKSR}/${_targetdir} || rm -rf
> ${GHSM_WRKSRC}/${_targetdir} ; \
That line is weird.
> mv ${WRKDIR}/${_ghproject}-${_ghtagcommit} ${GHSM_WRKSRC}/${_targetdir}
> ;
> .endfor
Please do a single loop. That's slightly more readable for me.
> # XXX: would best belong in _post-extract-finalize in bsd.port.mk rather than
> # hijacking post-extract here
> post-extract:
> @${ECHO_MSG} "moving GitHub submodules to ${GHSM_WRKSRC}" ;
> mkdir -p ${GHSM_WRKSRC} ;
> ${GHSM_post-extract}
Also please draft a diff for port-modules(5)
I'm also wondering if keeping the main GH_* stuff in bsd.port.mk makes a lot
of sense, instead of grouping everything in github.port.mk
Re: standardize and simplify GitHub submodule handling in ports?
On Sat, Aug 05, 2023 at 09:50:57PM -0400, Thomas Frohwein wrote:
> On Sat, Aug 05, 2023 at 11:27:24PM +0200, Marc Espie wrote:
> > Some comments already. I haven't looked very closely.
>
> > On Sat, Aug 05, 2023 at 03:12:18PM -0400, Thomas Frohwein wrote:
> > > The current draft hijacks post-extract target, but it would be easy to
> > > add this to _post-extract-finalize in bsd.port.mk similar to how the
> > > post-extract commands from modules are handled, if this is of interest.
> >
> > Please do that.
>
> Thanks, I updated the draft. Realized that including it with
> MODULES=github is easiest and then this can just use
> MODGITHUB_post-extract and doesn't need any custom code in bsd.port.mk.
> I had a thinko in post-extract (needs to be '||', not '&&') which is
> also corrected.
>
> > > # where submodule distfiles will be stored
> > > GHSM_DIST_SUBDIR ?= gh-submodules
> >
> > Please keep to the GH_* subspace.
> >
> > Already, modules usually use MOD* variable names, but in the GH case, that
> > would be a bit long.
>
> I renamed GHSM_* to GH_*. I wouldn't mind using MODGH_* if that's an
> option, but MODGITHUB_* would be pretty unwieldy, especially if we were
> to make the existing GH_{ACCOUNT,PROJECT,TAGNAME} etc. part of this.
>
> [...]
>
> > Please do a single loop. That's slightly more readable for me.
>
> yes, done.
>
> [...]
>
> > Also please draft a diff for port-modules(5)
>
> I'm attaching a diff for port-modules.5, along with the updated
> github.port.mk.
>
> > I'm also wondering if keeping the main GH_* stuff in bsd.port.mk makes a lot
> > of sense, instead of grouping everything in github.port.mk
>
> I'm for it, maybe as a second step after the module for just the
> submodule handling is done because there would be a lot of ports churn
> with moving the main GH_* stuff out of bsd.port.mk.
Probably not. We have a few "big" modules that don't depend on explicitly
adding to modules, but on some variable triggering it (historic imake stuff
or configure), having github.port.mk brought in from one of the GH_* variables
(probably don't need to test them all) would be acceptable.
PATCH: a bit of introspection in make
I think it could be occasionally useful to know which variables have
been defined in make.
Incidentally, this DOES exist in GNU make, so I've reused the same name
for basically the same functionality.
I haven't checked whether NetBSD/FreeBSD introduced something similar.
This is a fairly straightforward patch, introduces .VARIABLES corresponding
to the full list of global variables (from the command line and the Makefile)
that have been defined.
(^ says the guy who had to remember a few details from his own(!) var.c
implementation from a few years ago)
I just took var_get_value offline from the old macro, for readability,
even though it's likely the compiler may still decide to inline it.
For efficiency, that list is only computed as needed, since it is
somewhat long.
For debugging purposes, this can come in fairly handy, and I see at
least another application in ports.
Comments and nits welcome.
Note that the list is completely unsorted. This could be sorted through
since we already have the code for dumping purposes, but it would be even
more expensive (the order will be "random", as per the hash)
Index: var.c
===
RCS file: /cvs/src/usr.bin/make/var.c,v
retrieving revision 1.104
diff -u -p -r1.104 var.c
--- var.c 9 Jun 2022 13:13:14 - 1.104
+++ var.c 7 Aug 2023 14:33:42 -
@@ -104,6 +104,8 @@ static char varNoError[] = "";
bool errorIsOkay;
static boolcheckEnvFirst; /* true if environment should be searched for
* variables before the global context */
+ /* do we need to recompute varname_list */
+static boolvarname_list_changed = true;
void
Var_setCheckEnvFirst(bool yes)
@@ -228,9 +230,12 @@ typedef struct Var_ {
*/
#define POISONS (POISON_NORMAL | POISON_EMPTY | POISON_NOT_DEFINED)
/* Defined in var.h */
+#define VAR_IS_NAMES 1024/* Very expensive, only defined when needed */
char name[1]; /* the variable's name */
} Var;
+/* for GNU make compatibility */
+#define VARNAME_LIST ".VARIABLES"
static struct ohash_info var_info = {
offsetof(Var, name),
@@ -245,10 +250,11 @@ static void fill_from_env(Var *);
static Var *create_var(const char *, const char *);
static void var_set_initial_value(Var *, const char *);
static void var_set_value(Var *, const char *);
-#define var_get_value(v) ((v)->flags & VAR_EXEC_LATER ? \
- var_exec_cmd(v) : \
- Buf_Retrieve(&((v)->val)))
-static char *var_exec_cmd(Var *);
+static char *var_get_value(Var *);
+static void var_exec_cmd(Var *);
+static void varname_list_retrieve(Var *);
+
+
static void var_append_value(Var *, const char *);
static void poison_check(Var *);
static void var_set_append(const char *, const char *, const char *, int,
bool);
@@ -423,6 +429,7 @@ var_set_initial_value(Var *v, const char
len = strlen(val);
Buf_Init(&(v->val), len+1);
Buf_AddChars(&(v->val), len, val);
+ varname_list_changed = true;
}
/* Normal version of var_set_value(), to be called after variable is fully
@@ -440,6 +447,16 @@ var_set_value(Var *v, const char *val)
}
}
+static char *
+var_get_value(Var *v)
+{
+ if (v->flags & VAR_IS_NAMES)
+ varname_list_retrieve(v);
+ else if (v->flags & VAR_EXEC_LATER)
+ var_exec_cmd(v);
+ return Buf_Retrieve(&(v->val));
+}
+
/* Add to a variable, insert a separating space if the variable was already
* defined.
*/
@@ -628,6 +645,7 @@ Var_Deletei(const char *name, const char
ohash_remove(_variables, slot);
delete_var(v);
+ varname_list_changed = true;
}
/* Set or add a global variable, either to VAR_CMD or VAR_GLOBAL.
@@ -687,7 +705,7 @@ Var_Appendi_with_ctxt(const char *name,
var_set_append(name, ename, val, ctxt, true);
}
-static char *
+static void
var_exec_cmd(Var *v)
{
char *arg = Buf_Retrieve(&(v->val));
@@ -699,7 +717,27 @@ var_exec_cmd(Var *v)
var_set_value(v, res1);
free(res1);
v->flags &= ~VAR_EXEC_LATER;
- return Buf_Retrieve(&(v->val));
+}
+
+static void
+varname_list_retrieve(Var *v)
+{
+ unsigned int i;
+ void *e;
+ bool first = true;
+
+ for (e = ohash_first(_variables, ); e != NULL;
+ e = ohash_next(_variables, )) {
+ Var *v2 = e;
+ if (v2->flags & VAR_DUMMY)
+ continue;
+
+ if (first)
+ var_set_value(v, v2->name);
+ else
+ var_append_value(v, v2->name);
+ first = false;
+ }
}
/* XXX different semantics for Var_Valuei() and Var_Definedi():
@@ -1339,6 +1377,19 @@ set_magic_shell_variable()
v->flags = VAR_IS_SHELL | VAR_SEEN_ENV;
}
+static void
+set_magic_name_list_variable()
+{
+ const
Re: PATCH: a bit of introspection in make
On Mon, Aug 07, 2023 at 10:05:37PM -0400, Thomas Frohwein wrote:
> I looked through the file and it seems that varname_list_changed is
> never set to anything but true. Is there a bit missing, like down lower
> in varname_list_retrieve()?
Yep, I removed it at some point because it looked like some extra
unneeded work, and then I did change my mind because actual patterns
require it several times. So, yeah, it should be set to false there.
As for patterns, well, it will allow to write loops like
.for v in ${.VARIABLES:MMASTER_SITES*}
instead of having to look at MASTER_SITES0...9 manually, just as a for
instance.
Re: PATCH: a bit of introspection in make
Here's a revised diff (reordered plus actual use of the boolean)
plus concrete example use for bsd.port.mk (disregarding the fact
_ALL_VARIABLES would have to move *after* all MASTER_SITES have been defined.
Index: var.c
===
RCS file: /cvs/src/usr.bin/make/var.c,v
retrieving revision 1.104
diff -u -p -r1.104 var.c
--- var.c 9 Jun 2022 13:13:14 - 1.104
+++ var.c 8 Aug 2023 10:48:05 -
@@ -104,6 +104,8 @@ static char varNoError[] = "";
bool errorIsOkay;
static boolcheckEnvFirst; /* true if environment should be searched for
* variables before the global context */
+ /* do we need to recompute varname_list */
+static boolvarname_list_changed = true;
void
Var_setCheckEnvFirst(bool yes)
@@ -222,6 +224,7 @@ typedef struct Var_ {
#define VAR_FROM_ENV 8 /* Special source: environment */
#define VAR_SEEN_ENV 16 /* No need to go look up environment again */
#define VAR_IS_SHELL 32 /* Magic behavior */
+#define VAR_IS_NAMES 1024/* Very expensive, only defined when needed */
/* XXX there are also some flag values which are part of the visible API
* and thus defined inside var.h, don't forget to look there if you want
* to define some new flags !
@@ -231,6 +234,8 @@ typedef struct Var_ {
char name[1]; /* the variable's name */
} Var;
+/* for GNU make compatibility */
+#define VARNAME_LIST ".VARIABLES"
static struct ohash_info var_info = {
offsetof(Var, name),
@@ -245,10 +250,11 @@ static void fill_from_env(Var *);
static Var *create_var(const char *, const char *);
static void var_set_initial_value(Var *, const char *);
static void var_set_value(Var *, const char *);
-#define var_get_value(v) ((v)->flags & VAR_EXEC_LATER ? \
- var_exec_cmd(v) : \
- Buf_Retrieve(&((v)->val)))
-static char *var_exec_cmd(Var *);
+static char *var_get_value(Var *);
+static void var_exec_cmd(Var *);
+static void varname_list_retrieve(Var *);
+
+
static void var_append_value(Var *, const char *);
static void poison_check(Var *);
static void var_set_append(const char *, const char *, const char *, int,
bool);
@@ -423,6 +429,7 @@ var_set_initial_value(Var *v, const char
len = strlen(val);
Buf_Init(&(v->val), len+1);
Buf_AddChars(&(v->val), len, val);
+ varname_list_changed = true;
}
/* Normal version of var_set_value(), to be called after variable is fully
@@ -440,6 +447,16 @@ var_set_value(Var *v, const char *val)
}
}
+static char *
+var_get_value(Var *v)
+{
+ if (v->flags & VAR_IS_NAMES)
+ varname_list_retrieve(v);
+ else if (v->flags & VAR_EXEC_LATER)
+ var_exec_cmd(v);
+ return Buf_Retrieve(&(v->val));
+}
+
/* Add to a variable, insert a separating space if the variable was already
* defined.
*/
@@ -628,6 +645,7 @@ Var_Deletei(const char *name, const char
ohash_remove(_variables, slot);
delete_var(v);
+ varname_list_changed = true;
}
/* Set or add a global variable, either to VAR_CMD or VAR_GLOBAL.
@@ -687,7 +705,7 @@ Var_Appendi_with_ctxt(const char *name,
var_set_append(name, ename, val, ctxt, true);
}
-static char *
+static void
var_exec_cmd(Var *v)
{
char *arg = Buf_Retrieve(&(v->val));
@@ -699,7 +717,30 @@ var_exec_cmd(Var *v)
var_set_value(v, res1);
free(res1);
v->flags &= ~VAR_EXEC_LATER;
- return Buf_Retrieve(&(v->val));
+}
+
+static void
+varname_list_retrieve(Var *v)
+{
+ unsigned int i;
+ void *e;
+ bool first = true;
+
+ if (!varname_list_changed)
+ return;
+ for (e = ohash_first(_variables, ); e != NULL;
+ e = ohash_next(_variables, )) {
+ Var *v2 = e;
+ if (v2->flags & VAR_DUMMY)
+ continue;
+
+ if (first)
+ var_set_value(v, v2->name);
+ else
+ var_append_value(v, v2->name);
+ first = false;
+ }
+ varname_list_changed = false;
}
/* XXX different semantics for Var_Valuei() and Var_Definedi():
@@ -1339,6 +1380,19 @@ set_magic_shell_variable()
v->flags = VAR_IS_SHELL | VAR_SEEN_ENV;
}
+static void
+set_magic_name_list_variable()
+{
+ const char *name = VARNAME_LIST;
+ const char *ename = NULL;
+ uint32_t k;
+ Var *v;
+
+ k = ohash_interval(name, );
+ v = find_global_var_without_env(name, ename, k);
+ var_set_initial_value(v, "");
+ v->flags = VAR_IS_NAMES;
+}
/*
* Var_Init
* Initialize the module
@@ -1348,11 +1402,10 @@ Var_Init(void)
{
ohash_init(_variables, 10, _info);
set_magic_shell_variable();
-
+ set_magic_name_list_variable();
errorIsOkay = true;
Re: PATCH: a bit of introspection in make
Actually, as far as bsd.port.mk, it doesn't need to
move too much stuff around thanks to make's lazyness.
Note that having a list of defined MASTER_SITES variables simplifies
the check.
I've also added a check for the right MASTER_SITES to be defined,
since currently we do not error out until actually using it, which
means that fiddling around with MASTER_SITES before committing may
often go unnoticed.
(That final part is meant to go in sooner rather than later)
Index: bsd.port.mk
===
RCS file: /cvs/ports/infrastructure/mk/bsd.port.mk,v
retrieving revision 1.1592
diff -u -p -r1.1592 bsd.port.mk
--- bsd.port.mk 13 Jun 2023 10:28:40 - 1.1592
+++ bsd.port.mk 8 Aug 2023 10:59:38 -
@@ -118,9 +118,8 @@ _ALL_VARIABLES_PER_ARCH =
# consumers of (dump-vars) include sqlports generation and dpb
# dpb doesn't need everything, those are speed optimizations
.if ${DPB:L:Mfetch} || ${DPB:L:Mall}
-_ALL_VARIABLES += DISTFILES PATCHFILES SUPDISTFILES DIST_SUBDIR MASTER_SITES \
- MASTER_SITES0 MASTER_SITES1 MASTER_SITES2 MASTER_SITES3 MASTER_SITES4 \
- MASTER_SITES5 MASTER_SITES6 MASTER_SITES7 MASTER_SITES8 MASTER_SITES9 \
+_ALL_VARIABLES += DISTFILES PATCHFILES SUPDISTFILES DIST_SUBDIR \
+ ${_ALL_MASTER_SITES} \
CHECKSUM_FILE FETCH_MANUALLY MISSING_FILES PERMIT_DISTFILES
.endif
.if ${DPB:L:Mtest} || ${DPB:L:Mall}
@@ -1280,19 +1280,15 @@ MASTER_SITES ?=
# sites for distfiles, add them to MASTER_SITE_BACKUP
_warn_checksum = :
-.if !empty(MASTER_SITES:M*[^/])
-_warn_checksum += ;echo ">>> MASTER_SITES not ending in /:
${MASTER_SITES:M*[^/]}"
-.endif
-.for _I in 0 1 2 3 4 5 6 7 8 9
-. if defined(MASTER_SITES${_I})
-.if !empty(MASTER_SITES${_I}:M*[^/])
-_warn_checksum += ;echo ">>> MASTER_SITES${_I} not ending in /:
${MASTER_SITES${_I}:M*[^/]}"
-.endif
+_ALL_MASTER_SITES = ${.VARIABLES:MMASTER_SITES*:NMASTER_SITES_*}
+
+.for _S in ${_ALL_MASTER_SITES}
+. if !empty(${_S}:M*[^/])
+_warn_checksum += ;echo ">>> ${_S} not ending in /: ${${_S}:M*[^/]}"
. endif
.endfor
-
EXTRACT_SUFX ?= .tar.gz
.if !empty(GH_COMMIT)
@@ -1322,6 +1318,9 @@ _FILES=
. if !empty($v)
.for e in ${$v}
. for f m u in ${e:C/:[0-9]$//:C/^(.*)\{.*\}(.*)$/\1\2/}
MASTER_SITES${e:M*\:[0-9]:C/^.*:([0-9])$/\1/}
${e:C/:[0-9]$//:C/^.*\{(.*)\}(.*)$/\1\2/}
+.if !defined($m)
+ERRORS += "Fatal: $m is not defined but referenced by $e in $v"
+.endif
.if empty(_FILES:M$f)
_FILES += $f
. if empty(DIST_SUBDIR)
Re: distexpand for autogenerated upstream distfile resources (was: standardize and simplify GitHub submodule handling in ports?)
On Wed, Aug 09, 2023 at 12:54:12AM -0400, Thomas Frohwein wrote: > - It includes logic that finds the first MASTER_SITESn that isn't > otherwise used, and throws an ERROR if it overruns past > MASTER_SITES9. That logic will hopefully be soon 100% obsolete. I need some okays on the .VARIABLES make patch. I have code to be able to use more or less arbitrary suffixes in MASTER_SITES in bsd.port.mk, and the corresponding stuff for sqlports and dpb ought to be fairly trivial.
Re: posix_spawn(3): explain that handling NULL envp is an extension
On Sun, Jun 25, 2023 at 07:07:33PM -0300, Lucas de Sena wrote: > The manual already describes how posix_spawn(3) behaves when passing it > a NULL envp, but does not make it clear that it is an OpenBSD extension: > > > If envp is NULL, the environment is passed unchanged from the parent > > process. > > That differs from GNU/Linux, for example, where a NULL envp gives the > child an empty environment rather than a copy. Note that a NULL environment is undefined behavior according to POSIX. If you read the OpenGroup description, it very clearly states that envp is a pointer to a NULL terminated array. Does GNU/Linux at least document that passing a NULL pointer means no environment for them ?
pkg_add optional behavior "like syspatch"
Use-case: some people want to branch automated installs based on whether
pkg_add -u (or some other variation) actually did something.
As usual we ignore quirks. This adds a flag (-DSYSPATCH_LIKE)
which governs the behavior. Code is fairly self-explanatory.
I had no better idea for the flag name so far, suggestions welcome.
Index: OpenBSD/PkgAdd.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PkgAdd.pm,v
retrieving revision 1.142
diff -u -p -r1.142 PkgAdd.pm
--- OpenBSD/PkgAdd.pm 27 Jun 2023 11:11:46 - 1.142
+++ OpenBSD/PkgAdd.pm 2 Jul 2023 13:49:03 -
@@ -861,6 +861,9 @@ sub really_add($set, $state)
if ($state->{received}) {
die "interrupted";
}
+ if (!$set->{quirks}) {
+ $state->{did_something} = 1;
+ }
}
sub newer_has_errors($set, $state)
@@ -1163,6 +1166,8 @@ sub process_parameters($self, $state)
{
my $add_hints = $state->{fuzzy} ? "add_hints" : "add_hints2";
+ $state->{did_something} = 0;
+
# match against a list
if ($state->{pkglist}) {
open my $f, '<', $state->{pkglist} or
@@ -1178,7 +1183,6 @@ sub process_parameters($self, $state)
# update existing stuff
if ($state->{update}) {
-
if (@ARGV == 0) {
@ARGV = sort(installed_packages());
}
@@ -1239,6 +1243,16 @@ sub main($self, $state)
$self->process_setlist($state);
}
+sub exit_code($self, $state)
+{
+ my $rc = $self->SUPER::exit_code($state);
+ if ($rc == 0 && $state->defines("SYSPATCH_LIKE")) {
+ if (!$state->{did_something}) {
+ $rc = 2;
+ }
+ }
+ return $rc;
+}
sub new_state($self, $cmd)
{
Re: converting perl stuff to v5.36
On Sun, May 07, 2023 at 07:21:11PM -0700, Philip Guenther wrote: > Yeah, the downside of signatures is that by default it makes adding > parameters a breaking change and can thus calcify the interface. Something > for authors of shared modules that have callbacks to carefully consider. :/ So far, my stance on my code is that only stuff that's already in-tree matters. If people have external code, I'll be glad to fix things for them. "Bugs" in current code have been few and resulted in improvements in either documentation or interface in 99% of the cases. (and opening a constructor to extra params takes about 5 minutes)
Re: converting perl stuff to v5.36
On Mon, May 08, 2023 at 01:23:25AM -0400, George Koehler wrote:
> On Sun, 7 May 2023 19:21:11 -0700
> Philip Guenther wrote:
>
> > On Sun, May 7, 2023 at 6:13 AM Marc Espie
> > wrote:
> >
> > > I'm actually wondering whether keeping the prototype is worth it.
> > ...
> > For plain subs, I would only keep them if they _really_ help the calls look
> > for more perl-ish, by whatever scale you currently measure that. Maybe a
> > (&@) prototype so you can do "mysub { s/implicit/sub here/ } qw(args here)"
> > ala map and grep, but...eh.
>
> I wrote some (&@) prototypes before v5.36,
>
> | use v5.28;
> | use warnings;
> | use experimental 'signatures';
> |
> | sub bsearch :prototype(&@) ($block, @list) { ... }
> | sub bsearch_range :prototype(&@) ($block, $low, $high) { ... }
>
> The signature checks that bsearch_range has exactly 3 arguments.
>
> I sometimes call subs with the wrong number of arguments. My other
> frequent mistakes in Perl are syntax errors, strict(3p) errors, and
> warnings(3p) of uninitialized values.
>
>
I was always using strict and warnings unless I forgot.
I've got a few (very few) tricky uses on prototypes.
I might fix them as a switch to v5.36 before doing anything else!
(so far, the main abuser of perl funky syntax is the system stuff in State...
Not convinced about any other "regular" way of doing things, though I might
decide to try for a hash with names as first part, since the part that's run
in child/parent isn't obvious)
(the other sticky part is native sig handlers not having clear signatures
thanks in parts to WARN/DIE)
Re: cwm: add fvwm and tvm as default wm entries
On Tue, May 16, 2023 at 02:33:34AM +, Klemens Nanni wrote: > On Mon, May 15, 2023 at 09:42:47AM -0400, Bryan Steele wrote: > > On Mon, May 15, 2023 at 09:17:00AM -0400, Okan Demirmen wrote: > > > On Mon 2023.05.15 at 10:41 +0200, Matthieu Herrb wrote: > > > > On Mon, May 15, 2023 at 06:26:41AM +, Klemens Nanni wrote: > > > > > Both fvwm(1) and twm(1) have a restart menu that contains other window > > > > > managers by default, which is useful if you want to switch around > > > > > without restarting X and/or custom window manager config. > > > > > > > > > > cwm(1) only offers to restart into itself by deafult. > > > > > Add the other two we ship by default so users can round trip between > > > > > them. > > > > > > > > > > Feedback? OK? > > > > > > > > Last year I mentionned that I think we should retire twm. It's really > > > > too old and missing support for the modern window managers hints. > > > > > > > > People still using it should switch to cwm or maybe ctwm from ports > > > > (to keep the same configurarion system), or someone should step up to > > > > maintain it and enhance it with exwmh support. (but this is somehow > > > > just wasting time imho). > > I don't know anything about twm, so I'll leave that to others. > > > > > > > > > Otherwise ok to add this and fix the other WM menus for other window > > > > managers (those parts of the configs are already local changes in > > > > Xenocara) > > > > > > I might argue the opposite, to remove cwm from fvwm and twm restart > > > menus, if > > > this inconsistency is a real concern. The entries in fvwm/twm are in the > > > (shipped) example config files, where-as below it is, well, there for > > > good with > > > no user choice. Heck, how often to do people even use this restart wm to > > > another WM outside of playing around? Most window managers handle restarts > > > differently, regardless of what ICCCM/EWMH says) and even then, crossing > > > window > > > managers like this introduces inconsistencies. It's fine for playing > > > around I > > > suppose, but is it really a demanded "workflow"? > > It is convenient for testing because you keep all your windows and don't > have to login out and in again; that's about it for me. I have to side with kn on this. Actually, it would be cool if ywe could register more wm and switch on runtimes (a bit like @shell ?)
Re: cwm: add fvwm and tvm as default wm entries
As another rant: we old farts know which window manager we want to use. But for newer users, there might be a chance to find something cool before they get totally fossilized. And secondary rant: X is a failure, in that there is a *choice* of window managers, but so many of them haven't been really upgraded and thus are "useless" because they don't support modern hints. It looks like a very interesting line to die on.
converting perl stuff to v5.36
It is generally a good thing, I'm mostly talking about
the "signatures" stuff that allows functions with stuff that looks like
usual languages.
Other benefits include somewhat "cheap" check for correct number of parameters
and generally making code shorter.
Basically this converts very perlish code like
package OpenBSD::PackingElement::DirlikeObject;
sub process_dependency
{
my ($self, $mtree) = @_;
$mtree->{dir}{$self->fullname} = 1;
}
into
package OpenBSD::PackingElement::DirlikeObject;
sub process_dependency($self, $mtree)
{
$mtree->{dir}{$self->fullname} = 1;
}
which is
- shorter
- more readable for people not used to perl
- actually errors out on runtime if you use more parameters than expected,
thus tightening the actual usage.
(I also hope that the binding is/will become more efficient than writing
stuff manually)
Stuff to watch out for:
- it supersedes the syntax for prototypes. So if you had prototypes
(I did!), you need to explicitly write :prototypes in front of them.
For instance, constant methods like
package X;
sub is_okay()
{
1;
}
would become:
package X;
sub is_okay :prototype() ($)
{
1;
}
under the new rules.
I'm actually wondering whether keeping the prototype is worth it.
- it's still possible to not add any signature when you don't know.
- use v5.36; implies "use strict;" "use warnings;" and "use feature qw(say);"
which is cool
- beware that calling code without parenthesis, e.g., stuff like
&$code;
*will* not create a new context (and thus reuse @_ implicitly, which doesn't
mesh well with signatures)
- parameters which aren't used can use a single $ or something, which leaves
the question of documentation.
After fiddling a bit with it, I've settled on documenting the method
fully in comments, e.g., for instance:
# $class->recognize($filename, $fsobj, $data):
# called for each class in order until the "default" file
# some retrieved data such as file's contents are cached for
# efficiency
sub recognize($, $, $, $)
{
return 1;
}
(which is very useful for any base class that actually does nothing)
- lambdas (anonymous subs) can use signatures. Note that stuff like
File::Find explicitly takes 0 parameters, whereas stuff like signal handler
is woefully underspecified !
