Re: When will OpenBSD become a friendly place for bug reporters?

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

STeve Andre'-2


On 7/8/19 10:57 PM, [hidden email] wrote:

> Hi!
>
> We all know that bugs don't get fixed without backtraces.
>
> After few years of using OpenBSD I am annoyed to get mocked for not
> sending backtraces, but why I don't send them? The answer is: OpenBSD
> doesn't provide software packages with debugging symbols.
>
> Do I look like a Gentoo user? It's not cool to leave no choice to bug
> reporters but to make them rebuild all ports they use with:
> $ env CFLAGS='-pipe -g' DEBUG=-g make -j $(sysctl -n hw.ncpu) reinstall
>
> The current OpenBSD is definetely not friendly to bug reporters, so
> don't blame me when I refuse to send backtraces, I am simply not in mood
> to rebuild software when it shouldn't be necessary, I value my time.

For heavens sake, why don't you compile the code with symbols?  If you
have the ability to go inside and look for problems, you can compile
stuff yourself.  If you're going to submit a patch you have to build
to test the fix!

--STeve Andre'

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

Christopher Turkel
Stop it now. You are being a troll.

On Tue, Jul 9, 2019 at 1:09 PM Leonid Bobrov <[hidden email]> wrote:

> > It is definately not a friendly place for people with a tone like yours.
>
> Theo, your excuse that OpenBSD is not more popular than Linux because AT&T
> sued BSD in 90's is ridiculous, that's your own fault for being so
> terrible in technical field, also you are terrible person, just like
> me you can't communicate, so why do you think you can teach me
> communication? If my tone is that important you prefer ignoring important
> topic then you are even more terrible in terms of both personality and
> technical field.
>
> > An all-arches package snapshot currently runs at 200GB and adding
> > symbols across the board would add a lot to this.
>
> Stuart and Espie, have you ever heard of compression?
>
> Again, what's wrong with my tone? I can't elaborate my thoughts in
> different ways, also my tone only bothers people in this community,
> most other communities don't see anything wrong about my way of speaking.
>
> Anyway, Stuart suggests a really good solution: detaching symbols into
> subpackages, this practice is already used in Void Linux, I downloaded
> 1 GB of compressed archives and they expanded to 27 GB, so maybe you
> can learn how to use compression or at least switch packages to proper
> compression method.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

Roderick
In reply to this post by STeve Andre'-2

On Tue, 9 Jul 2019, [hidden email] wrote:

> Perhaps rather than whining that OpenBSD lacks some specific feature,
> those who want it could write it?

Or perhaps better not. All depends on what is a feature and for whom.

I, as normal user, am glad that packages are not inflated with debugging
symbols.

Rod.

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

Nathan Hartman
In reply to this post by STeve Andre'-2
On Tue, Jul 9, 2019 at 2:43 PM Marc Espie <[hidden email]> wrote:

> - we do use gzip because other compression systems won't work with little
> memory/don't have the right licence.


You might find this interesting:

https://github.com/silentbicycle/heatshrink
Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

ropers
In reply to this post by STeve Andre'-2
On 09/07/2019, [hidden email] <[hidden email]> wrote:
> Perhaps rather than whining that OpenBSD lacks some specific feature, those
> who want it could write it? A novel idea, I know, but it IS specifically a
> development platform and there are precisely zero restrictions.
>
> Or if you don't wish to start with code, at least try a tack such as "I
> intend to write feature $foo and would like advice for how to go about it".

I intend to write feature "altnumd" and would like advice for how to
go about it.

To elaborate:
  Many older DOS/Windows users still have an old special character
input method in muscle memory that goes back all the way to the IBM
5150[0]: Alt+Numpad[1].
Meaning, hold Alt, and then on the number pad, type a decimal code for
a character in order to insert that character into the (originally
BIOS-)keyboard buffer, from which it is off to the races, to be picked
up by whoever is grabbing characters off the keyboard buffer.
I'm explaining this, because AFAIK that feature has never existed on
Unix-like OSes, and I think--corrections welcome--the BIOS isn't even
involved when OpenBSD talks to the keyboard or vice versa.
I am very aware of the Compose key support in X11, and this isn't
about that. This isn't about inputting characters in a good or better
way. This is about inputting characters in exactly THAT way
(Alt+Numpad), "just like mammy used to".
  Alt+Numpad was originally a BIOS feature for the Single-Byte
Character Set[2] DOS code pages[3] where--unlike in UTF-8 today--there
was no difference between code units and code points[4]. Every one of
the then at most 256 characters on the currently configured code page
was at users' fingertips with Alt+0 thru Alt+255.[5]
  At least part of reimplementing Alt+Numpad support on OpenBSD (as
3rd-party software; I don't expect this to become an OS feature)
should be possible in that these hotkey programs seem able to perform
fairly arbitrary actions in response to configurable key sequences:
<http://ports.su/x11/sxhkd>, <http://ports.su/x11/xbindkeys>. I have
not yet explored this enough and not yet gotten them to respond to
Alt+Numpad, but I suspect that may be possible.
  However, I don't have a sufficient understanding of the basics of
OpenBSD/console/X11 keyboard support yet. I would like "altnumd" to
work the same or as similar as possible on both console and X11. My
very deficient understanding of OpenBSD non-BIOS keyboard support is
this: I. keypresses on the physical (USB/PS2) keyboard. I think the
actual keyboard has an internal microcontroller and small buffer, but
I don't think that's accessible to write back to. --> II. Low-level OS
keyboard device support. Presumably there's some sort of buffer there
that could be written to, given permission? --> III. At some point
things connect to console and/or X11, and then programs themselves
have their buffers too. Is wscons always involved? Is that the lowest
one can go and can that be written back to? I'm unsure. Essentially,
after registering the keypress sequence, which existing hotkey
programs seem up to, I would need to write something similar to a
software keyboard emulator. Apparently there used to be this TIOCSTI
thing that maybe could help, but this was removed for security
reasons?[6] Is there an alternative?
  Also, it's not even quite clear to me where along the line from
keyboard to program, the scan codes turn into code units/code points
and characters. I.e., assuming the use of UTF-8 at the end of the day,
once I've registered the right code for, say, the NOT character
(Alt+170 on DOS CP437 or Alt+172 on Win/CP1252 and OpenBSD's old
ISO-8859-1), once I've registered that, what goes into the buffer?
0xAA (170) or 0xAC (172), or UTF-8's ready-made 0xC2 0xAC (=U+00AC)?
(Speaking of multiple bytes, a "stretch goal" might be the option to
insert an entire string in response to an Alt code, but that's gravy
and not the old muscle memory.)

Yes, I seriously would like to do this if I can get good enough, from
zero to not-quite-hero. Yes, I would very much appreciate help and any
useful pointers. On-list, off-list, elsewhere, anything, from anyone.

Ian

PS: That said, nobody bet on me succeeding, unless you like losing money.

[0] <https://en.wikipedia.org/wiki/IBM_Personal_Computer>
[1] <https://en.wikipedia.org/wiki/Alt_code>
[2] <https://en.wikipedia.org/wiki/SBCS>
[3] <https://en.wikipedia.org/wiki/Code_page#DOS_code_pages>
[4] <https://en.wikipedia.org/wiki/Character_encoding#Terminology>:
"The compromise solution that was eventually found and developed into
Unicode was to break the assumption (dating back to telegraph codes)
that each character should always directly correspond to a particular
sequence of bits. Instead, characters would first be mapped to a
universal intermediate representation in the form of abstract numbers
called __code points__. Code points would then be represented in a
variety of ways and with various default numbers of bits per character
(__code units__) depending on context. To encode code points higher
than the length of the code unit, such as above 256 for 8-bit units,
the solution was to implement variable-width encodings where an escape
sequence would signal that subsequent bits should be parsed as a
higher code point."
[5] This was later extended, e.g. to bigger code pages and longer (or
even alphanumeric) sequences, and while I don't want to support
alphanumeric, I too would hope to support
Alt+near-arbitrarily-long-nums, i.e. specifically I want to support
users typing anything from Alt+0 through Alt+18446744073709551615,
i.e. ull, i.e. unsigned long long int. (That's provided the sequence
in question is included in a config file--.altnumrc?--listing
sequences and the bytes to be inserted into the keyboard buffer in
response to the respective sequence.) The emphasis would be on
supporting existing Alt+0 thru Alt+255 muscle memory though.
[6] <https://undeadly.org/cgi?action=article&sid=20170701132619>

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

Consus-2
In reply to this post by Roderick
On 18:56 Tue 09 Jul, Roderick wrote:

>
> On Tue, 9 Jul 2019, [hidden email] wrote:
>
> > Perhaps rather than whining that OpenBSD lacks some specific feature,
> > those who want it could write it?
>
> Or perhaps better not. All depends on what is a feature and for whom.
>
> I, as normal user, am glad that packages are not inflated with debugging
> symbols.

That's why redhat and others offer *-debuginfo packages with DWARF
symbols. It's really helpful. It would be nice to have such in OpenBSD,
especially for base, because rebuilding something on my router is not
something I would like to do.

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

Ingo Schwarze
In reply to this post by ropers
Hi Ian,

ropers wrote on Wed, Jul 10, 2019 at 03:03:08AM +0200:

> I intend to write feature "altnumd" and would like advice for how to
> go about it.

My opinion is that we don't have too few methods for entering
characters.  One could argue that we already have too many,
and the existing ones are too complicated.  So writing yet
another system or daemon sounds like a bad idea to me.

What might be useful is understanding all the details of how
all the existing methods in ws* and X* (and possibly elsewhere?)
work, then simplify them.

I'm not aware of a simple method of entering Unicode codepoints
numerically that works everywhere, and i find that lack annoying.

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

Juan Francisco Cantero Hurtado
In reply to this post by Consus-2
On Wed, Jul 10, 2019 at 09:30:56AM +0300, Consus wrote:

> On 18:56 Tue 09 Jul, Roderick wrote:
> >
> > On Tue, 9 Jul 2019, [hidden email] wrote:
> >
> > > Perhaps rather than whining that OpenBSD lacks some specific feature,
> > > those who want it could write it?
> >
> > Or perhaps better not. All depends on what is a feature and for whom.
> >
> > I, as normal user, am glad that packages are not inflated with debugging
> > symbols.
>
> That's why redhat and others offer *-debuginfo packages with DWARF
> symbols. It's really helpful. It would be nice to have such in OpenBSD,
> especially for base, because rebuilding something on my router is not
> something I would like to do.

The symbols are included in the base libraries. We only strip the
symbols in the packages. Try this on your router:
objdump -x /usr/lib/libedit.so.* (just an example)


--
Juan Francisco Cantero Hurtado http://juanfra.info

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

Consus-2
On 17:14 Wed 10 Jul, Juan Francisco Cantero Hurtado wrote:

> On Wed, Jul 10, 2019 at 09:30:56AM +0300, Consus wrote:
> > On 18:56 Tue 09 Jul, Roderick wrote:
> > >
> > > On Tue, 9 Jul 2019, [hidden email] wrote:
> > >
> > > > Perhaps rather than whining that OpenBSD lacks some specific feature,
> > > > those who want it could write it?
> > >
> > > Or perhaps better not. All depends on what is a feature and for whom.
> > >
> > > I, as normal user, am glad that packages are not inflated with debugging
> > > symbols.
> >
> > That's why redhat and others offer *-debuginfo packages with DWARF
> > symbols. It's really helpful. It would be nice to have such in OpenBSD,
> > especially for base, because rebuilding something on my router is not
> > something I would like to do.
>
> The symbols are included in the base libraries. We only strip the
> symbols in the packages. Try this on your router:
> objdump -x /usr/lib/libedit.so.* (just an example)

Yeah, but it's still stripped for tools (try gdb $(which smtpd) for
example).

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

ropers
In reply to this post by Ingo Schwarze
On 10/07/2019, Ingo Schwarze <[hidden email]> wrote:

> Hi Ian,
>
> ropers wrote on Wed, Jul 10, 2019 at 03:03:08AM +0200:
>
>> I intend to write feature "altnumd" and would like advice for how to
>> go about it.
>
> My opinion is that we don't have too few methods for entering
> characters.  One could argue that we already have too many,
> and the existing ones are too complicated.  So writing yet
> another system or daemon sounds like a bad idea to me.
>
> What might be useful is understanding all the details of how
> all the existing methods in ws* and X* (and possibly elsewhere?)
> work, then simplify them.
>
> I'm not aware of a simple method of entering Unicode codepoints
> numerically that works everywhere, and i find that lack annoying.
>
> Yours,
>   Ingo

While I'm personally only or mainly interested in Alt+numeric input,
if altnumd existed, it would probably be comparatively easy to then
extend it and add support for Alt+u0000 thru Alt+u10ffff, with the U
becoming a reserved keyword unambiguously signifying that what follows
will be a Unicode code point between U+0000 and U+10FFFF.
Maybe this is the hubris born of inexperience and ignorance speaking,
but I think that would be the easiest part. [1]

I think capturing keypresses would be harder, but the existence of
sxhkd, etc. suggests this is solvable, at least on X11 (though I'd
love to have something that works just the same on console).

The hardest part that I'm comprehensively clueless about is how or
where or what exactly to insert into the, or what, keyboard buffer.

So I think maybe our interests are aligned for the moment. There's a
huge competence gap between us, but I think on this part of the
possible journey, we'd have to go the same way.

Any hints on how to even start with that hardest part, or what to read
or where to look would be MORE than welcome.

Cheers,
Ian

[1] Okay, sorry, I lied: What'd be somewhat easy would be putting the
*plumbing* for Alt+u<codept> in place ONCE the plumbing for
Alt+<decimal> exists. I imagine the latter as being based on a simple
.altnumrc that's a configurable list of key-value pairs. Creating a
list of keys from 0 thru 255 with the corresponding values for e.g.
code page 437 would be relatively easy, HOWEVER creating or
maintaining anything close to a semi-comprehensive list for just about
every Unicode character you can think of would actually be very hard.
  My thinking is to more or less leave that work to users: altnumd
would read .altnumrc on (re)launch, and users could create and swap
out different versions of .altnumrc e.g. to switch from CP437 to
WinCP1252 or ISO-8859-1 or whatever. A thinly populated .altnumrc for
initially just the lowest Unicode blocks[2] in the Basic Multilingual
Plane[3] would still be easy to make, but with higher expectations of
how comprehensive an .altnumrc you want to support and maintain, the
difficulty goes up exponentially. And that's not even mentioning font
support, etc.[4] The trick is not to include every combination but
only those Alt codes (or code points) you'll actually use.

[2] https://en.wikipedia.org/wiki/Unicode_block
[3] https://en.wikipedia.org/wiki/Plane_(Unicode)#Basic_Multilingual_Plane
[4] Also, the console would only support a small subset anyway; I have
some questions and thoughts on that too, but that's really another
issue for another day, perhaps.

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

Matthew Graybosch-2
On Thu, 11 Jul 2019 00:41:45 +0200
ropers <[hidden email]> wrote:

> Any hints on how to even start with that hardest part, or what to read
> or where to look would be MORE than welcome.

Hi, ropers. I've been reading this thread about altnumd and using
alt+000 to enter arbitrary Unicode characters like people did on DOS
and Windows. I noticed that nobody mentioned that X11 already has a
method for entering arbitrary Unicode characters using pre-defined key
sequences. It's called the "Compose" key (aka the Multi_Key in X11
header files).

https://en.wikipedia.org/wiki/Compose_key

PC and Mac keyboards don't provide a physical compose key, but you can
remap a key you don't usually use (like Caps Lock or the right-hand ALT
or CTRL keys) using setxkbmap(1).

Here's the command I use in my ~/.xsession file:

setxkbmap -option compose:caps &

Hopefully this helps somebody.

--
Matthew Graybosch
https://matthewgraybosch.com | gopher://asgartech.com:70
xmpp: [hidden email]
"'Out of order'? Even in the future nothing works!"

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

ropers
On 11/07/2019, Matthew Graybosch <[hidden email]> wrote:

> On Thu, 11 Jul 2019 00:41:45 +0200
> ropers <[hidden email]> wrote:
>
>> Any hints on how to even start with that hardest part, or what to read
>> or where to look would be MORE than welcome.
>
> Hi, ropers. I've been reading this thread about altnumd and using
> alt+000 to enter arbitrary Unicode characters like people did on DOS
> and Windows. I noticed that nobody mentioned that X11 already has a
> method for entering arbitrary Unicode characters using pre-defined key
> sequences. It's called the "Compose" key (aka the Multi_Key in X11
> header files).

I mentioned that, somewhat near the top of my earlier email:

>> I am very aware of the Compose key support in X11, and this isn't
>> about that. This isn't about inputting characters in a good or better
>> way. This is about inputting characters in exactly THAT way
>> (Alt+Numpad), "just like mammy used to".

However, I didn't go into details, and though Compose doesn't solve
what I want to do, you're right that these details may help somebody,
so thanks anyway.

> https://en.wikipedia.org/wiki/Compose_key
>
> PC and Mac keyboards don't provide a physical compose key, but you can
> remap a key you don't usually use (like Caps Lock or the right-hand ALT
> or CTRL keys) using setxkbmap(1).
>
> Here's the command I use in my ~/.xsession file:
>
> setxkbmap -option compose:caps &
>
> Hopefully this helps somebody.

(Personally, I like to use compose:rwin, though that right Windows key
doesn't exist on some (old or laptop) keyboards.)

I'm pretty damn sure Ingo knows about Compose too. His complaint was
subtly different also:

> > I'm not aware of a simple method of entering Unicode codepoints
> > numerically that works everywhere, and i find that lack annoying.

Emphasis on "that works everywhere".

I am aware of the "Ctrl+Shift U <codept>" Unicode input method too,
but this again does not work everywhere:
<https://en.wikipedia.org/wiki/Unicode_input#In_X11_(Linux_and_Unix_variants)>

However (this also from my above email):

>> [4] Also, the console would only support a small subset anyway; I have
some questions and thoughts on that too, but that's really another
issue for another day, perhaps.

Plus, Ingo wrote:

> > What might be useful is understanding all the details of how
> > all the existing methods in ws* and X* (and possibly elsewhere?)
> > work, then simplify them.

Even if Ingo's interest in understanding and simplifying existing
methods, --and arguably Alt codes *are* an existing method, albeit one
that works "elsewhere" but not on Unix-likes thus far--, could be
partially aligned with what I want to do, and would hopefully be
simplifying things instead of being like the invention of another text
editor <http://www.catb.org/esr/writings/unix-koans/editor-wars.html>,
Unicode support on console would necessarily be limited.  I alluded to
that in my [4] footnote, and maybe I should write up my extensive
thoughts on that, Real Soon Now.  The major limitation there is that
console font support is limited to 256 characters, or hackishly 512,
and the ways around that are not pretty.  So while Alt+<numpad>, and
*perhaps* also Alt+u<codept> could possibly be made to work the same
throughout X11 and console, Alt+u<codept> would be limited on console.
I am aware that Alt+u<codept> would compete with Ctrl+Shift U<codept>
(which latter doesn't work everywhere).
Either way, actual Unicode character input methods like this, and
let's include Compose here, could perhaps only *input* characters
like, say, the ☃ U+2603 SNOWMAN, but the console would at best
*display* \xE2\x98\x83 in place of that, because the Unicode snowman
is not in any console font.
If we want to be precise about it, console "support" for *displaying*
a character that was typed is a different issue than inputting it
though, and being limited to a subset here and there shouldn't count
against the idea of installing universal plumbing.

And again, to me the hardest part of that is figuring out
>> how or where or what exactly to insert into the, or what, keyboard buffer.
>> (...)
>> Any hints on how to even start with that hardest part, or what to read
or where to look would be MORE than welcome.

Many thanks in advance,
Ian

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

Ingo Schwarze
In reply to this post by ropers
Hi Ian,

ropers wrote on Thu, Jul 11, 2019 at 12:41:45AM +0200:

> While I'm personally only or mainly interested in Alt+numeric input,
> if altnumd existed, it would probably be comparatively easy to then
> extend it and add support for Alt+u0000 thru Alt+u10ffff, with the U
> becoming a reserved keyword unambiguously signifying that what follows
> will be a Unicode code point between U+0000 and U+10FFFF.

There is no reason to make it different.  ASCII is a subset of Unicode,
with the same numbering.  So the "U" looks redundant to me.

> There's a huge competence gap between us,

Quite likely.  I'm so clueless that right now, i can't even seem to get
Compose to work even though i'm sure i had it working in the past.
This is on amd64-current, inside xterm(1) and ksh(1):

   $ locale
  LANG=
  LC_COLLATE="en_US.UTF-8"
  LC_CTYPE="en_US.UTF-8"
  LC_MONETARY="en_US.UTF-8"
  LC_NUMERIC="en_US.UTF-8"
  LC_TIME="en_US.UTF-8"
  LC_MESSAGES="en_US.UTF-8"
  LC_ALL=en_US.UTF-8
   $ setxkbmap -query -v -v -v                    
  Setting verbose level to 8
  locale is en_US.UTF-8
  Trying to load rules file ./rules/base...
  Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
  Success.
  Applied rules from base:
  rules:      base
  model:      pc105
  layout:     de
  Trying to build keymap using the following components:
  keycodes:   xfree86+aliases(qwertz)
  types:      complete
  compat:     complete
  symbols:    pc+de+inet(pc105)+terminate(ctrl_alt_bksp)
  geometry:   pc(pc105)
  rules:      base
  model:      pc105
  layout:     de

At this point, the caps key toggles caps lock, i.e. pressing

  caps a caps a

results in the input "Aa".

   $ setxkbmap -option compose:caps -v -v -v      
  Setting verbose level to 8
  locale is en_US.UTF-8
  Trying to load rules file ./rules/base...
  Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
  Success.
  Applied rules from base:
  rules:      base
  model:      pc105
  layout:     de
  options:    compose:caps
  Trying to build keymap using the following components:
  keycodes:   xfree86+aliases(qwertz)
  types:      complete
  compat:     complete
  symbols:    pc+de+inet(pc105)+terminate(ctrl_alt_bksp)+compose(caps)
  geometry:   pc(pc105)

Now, the caps key no longer toggles caps lock and becomes a dead key,
i.e. pressing

  caps , c caps " a

results in the input "ca".  However, the resulting input is really
ASCII-c ASCII-a rather than the expected c-cedille a-umlaut.
It looks like Compose works well enough to discard the , and ",
but not well enough to actually generate non-ASCII characters.

Somewhat grumpy today,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

NilsOla Nilsson
I am using cwm and ksh and at present my compose key
work in st and in gvim, but not in xterm.
I am on current updated a few weeks ago.

/NilsOla

On Thu, Jul 11, 2019 at 09:18:41PM +0200, Ingo Schwarze wrote:

> Hi Ian,
>
> ropers wrote on Thu, Jul 11, 2019 at 12:41:45AM +0200:
>
> > While I'm personally only or mainly interested in Alt+numeric input,
> > if altnumd existed, it would probably be comparatively easy to then
> > extend it and add support for Alt+u0000 thru Alt+u10ffff, with the U
> > becoming a reserved keyword unambiguously signifying that what follows
> > will be a Unicode code point between U+0000 and U+10FFFF.
>
> There is no reason to make it different.  ASCII is a subset of Unicode,
> with the same numbering.  So the "U" looks redundant to me.
>
> > There's a huge competence gap between us,
>
> Quite likely.  I'm so clueless that right now, i can't even seem to get
> Compose to work even though i'm sure i had it working in the past.
> This is on amd64-current, inside xterm(1) and ksh(1):
>
>    $ locale
>   LANG=
>   LC_COLLATE="en_US.UTF-8"
>   LC_CTYPE="en_US.UTF-8"
>   LC_MONETARY="en_US.UTF-8"
>   LC_NUMERIC="en_US.UTF-8"
>   LC_TIME="en_US.UTF-8"
>   LC_MESSAGES="en_US.UTF-8"
>   LC_ALL=en_US.UTF-8
>    $ setxkbmap -query -v -v -v                    
>   Setting verbose level to 8
>   locale is en_US.UTF-8
>   Trying to load rules file ./rules/base...
>   Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
>   Success.
>   Applied rules from base:
>   rules:      base
>   model:      pc105
>   layout:     de
>   Trying to build keymap using the following components:
>   keycodes:   xfree86+aliases(qwertz)
>   types:      complete
>   compat:     complete
>   symbols:    pc+de+inet(pc105)+terminate(ctrl_alt_bksp)
>   geometry:   pc(pc105)
>   rules:      base
>   model:      pc105
>   layout:     de
>
> At this point, the caps key toggles caps lock, i.e. pressing
>
>   caps a caps a
>
> results in the input "Aa".
>
>    $ setxkbmap -option compose:caps -v -v -v      
>   Setting verbose level to 8
>   locale is en_US.UTF-8
>   Trying to load rules file ./rules/base...
>   Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
>   Success.
>   Applied rules from base:
>   rules:      base
>   model:      pc105
>   layout:     de
>   options:    compose:caps
>   Trying to build keymap using the following components:
>   keycodes:   xfree86+aliases(qwertz)
>   types:      complete
>   compat:     complete
>   symbols:    pc+de+inet(pc105)+terminate(ctrl_alt_bksp)+compose(caps)
>   geometry:   pc(pc105)
>
> Now, the caps key no longer toggles caps lock and becomes a dead key,
> i.e. pressing
>
>   caps , c caps " a
>
> results in the input "ca".  However, the resulting input is really
> ASCII-c ASCII-a rather than the expected c-cedille a-umlaut.
> It looks like Compose works well enough to discard the , and ",
> but not well enough to actually generate non-ASCII characters.
>
> Somewhat grumpy today,
>   Ingo
--
Nils Ola Nilsson, 🐞 email [hidden email], tel +46-70-374 69 89

signature.asc (465 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

Ingo Schwarze
Hi NilsOla,

NilsOla Nilsson wrote on Thu, Jul 11, 2019 at 11:24:24PM +0200:

> I am using cwm and ksh and at present my compose key
> work in st and in gvim, but not in xterm.
> I am on current updated a few weeks ago.

Oh.  Thank you for the hint.  Given my clumsiness with X keyboard
configuration, i assumed it was just me, but your additional data
indicates there may actually be a regression in xterm(1).

Who knows what a GTK leviathan like gvim is doing.  But suckless
software is about the opposite of bloatware and i would be quite
surprised if it internally re-implemented the Compose mechanism.
So the fact that Compose works in the x11/st(1) port (which i
can confirm) means that i probably do have Compose correctly
configured and that xterm(1) is somehow breaking the characters
it receives from X - not all of them, but those where Compose
was involved.

The above suspicion is supported by the fact that Compose also
works in xedit(1).  It even works in xclipboard(1), xman(1),
nedit(1), except that these programs don't support UTF-8 but
appear to be hardcoded to Latin-1, such that the entered UTF-8
characters appear as garbage two-character sequences.

To me, this looks suspiciously like a bug now.  :-(

Yours,
  Ingo


> On Thu, Jul 11, 2019 at 09:18:41PM +0200, Ingo Schwarze wrote:
> > Hi Ian,
> >
> > ropers wrote on Thu, Jul 11, 2019 at 12:41:45AM +0200:
> >
> > > While I'm personally only or mainly interested in Alt+numeric input,
> > > if altnumd existed, it would probably be comparatively easy to then
> > > extend it and add support for Alt+u0000 thru Alt+u10ffff, with the U
> > > becoming a reserved keyword unambiguously signifying that what follows
> > > will be a Unicode code point between U+0000 and U+10FFFF.
> >
> > There is no reason to make it different.  ASCII is a subset of Unicode,
> > with the same numbering.  So the "U" looks redundant to me.
> >
> > > There's a huge competence gap between us,
> >
> > Quite likely.  I'm so clueless that right now, i can't even seem to get
> > Compose to work even though i'm sure i had it working in the past.
> > This is on amd64-current, inside xterm(1) and ksh(1):
> >
> >    $ locale
> >   LANG=
> >   LC_COLLATE="en_US.UTF-8"
> >   LC_CTYPE="en_US.UTF-8"
> >   LC_MONETARY="en_US.UTF-8"
> >   LC_NUMERIC="en_US.UTF-8"
> >   LC_TIME="en_US.UTF-8"
> >   LC_MESSAGES="en_US.UTF-8"
> >   LC_ALL=en_US.UTF-8
> >    $ setxkbmap -query -v -v -v                    
> >   Setting verbose level to 8
> >   locale is en_US.UTF-8
> >   Trying to load rules file ./rules/base...
> >   Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
> >   Success.
> >   Applied rules from base:
> >   rules:      base
> >   model:      pc105
> >   layout:     de
> >   Trying to build keymap using the following components:
> >   keycodes:   xfree86+aliases(qwertz)
> >   types:      complete
> >   compat:     complete
> >   symbols:    pc+de+inet(pc105)+terminate(ctrl_alt_bksp)
> >   geometry:   pc(pc105)
> >   rules:      base
> >   model:      pc105
> >   layout:     de
> >
> > At this point, the caps key toggles caps lock, i.e. pressing
> >
> >   caps a caps a
> >
> > results in the input "Aa".
> >
> >    $ setxkbmap -option compose:caps -v -v -v      
> >   Setting verbose level to 8
> >   locale is en_US.UTF-8
> >   Trying to load rules file ./rules/base...
> >   Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
> >   Success.
> >   Applied rules from base:
> >   rules:      base
> >   model:      pc105
> >   layout:     de
> >   options:    compose:caps
> >   Trying to build keymap using the following components:
> >   keycodes:   xfree86+aliases(qwertz)
> >   types:      complete
> >   compat:     complete
> >   symbols:    pc+de+inet(pc105)+terminate(ctrl_alt_bksp)+compose(caps)
> >   geometry:   pc(pc105)
> >
> > Now, the caps key no longer toggles caps lock and becomes a dead key,
> > i.e. pressing
> >
> >   caps , c caps " a
> >
> > results in the input "ca".  However, the resulting input is really
> > ASCII-c ASCII-a rather than the expected c-cedille a-umlaut.
> > It looks like Compose works well enough to discard the , and ",
> > but not well enough to actually generate non-ASCII characters.
> >
> > Somewhat grumpy today,
> >   Ingo
>
> --
> Nils Ola Nilsson, 🐞 email [hidden email], tel +46-70-374 69 89


Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

ropers
In reply to this post by Ingo Schwarze
On 11/07/2019, Ingo Schwarze <[hidden email]> wrote:
> Hi Ian,

Hi Ingo,

I've just noticed yet another false positive where Gmail has
classified your email as spam here for the n-th time.  I'm not sure if
that's just happening to my mailbox, or if it's Gmail-wide or, worse,
if lots of MTAs out there treat your emails as spam.
(There seems to be a trend where big corps are quite happy to
discourage people from running their own MTAs and increasingly throw
their weight around rejecting anything that isn't credentialled up the
wazoo with SPF, DKIM, DMARC or whatever, and of course there are
powerful interests who want to deanonymise the Net, which may be
related.)
Either way, maybe this is something you'll want to look into from your end?

> ropers wrote on Thu, Jul 11, 2019 at 12:41:45AM +0200:
>
>> While I'm personally only or mainly interested in Alt+numeric input,
>> if altnumd existed, it would probably be comparatively easy to then
>> extend it and add support for Alt+u0000 thru Alt+u10ffff, with the U
>> becoming a reserved keyword unambiguously signifying that what follows
>> will be a Unicode code point between U+0000 and U+10FFFF.
>
> There is no reason to make it different.  ASCII is a subset of Unicode,
> with the same numbering.  So the "U" looks redundant to me.

There are several reasons why it isn't redundant:

1. Alt codes are decimal, but Unicode code points are hexadecimal.
Alt+73, Alt+78, Alt+71, Alt+79 "INGO" would become "sxqy" if treated as hex.

2. Unicode code points (format: U+xxxx, mostly, though it goes up to U+10FFFF)
are NOT character bytes. I quoted Wikipedia on this in my email two days ago:

>> [4] <https://en.wikipedia.org/wiki/Character_encoding#Terminology>:
>> "The compromise solution that was eventually found and developed into
>> Unicode was to break the assumption (dating back to telegraph codes)
>> that each character should always directly correspond to a particular
>> sequence of bits. Instead, characters would first be mapped to a
>> universal intermediate representation in the form of abstract numbers
>> called __code points__. Code points would then be represented in a
>> variety of ways and with various default numbers of bits per character
>> (__code units__) depending on context. To encode code points higher
>> than the length of the code unit, such as above 256 for 8-bit units,
>> the solution was to implement variable-width encodings where an escape
>> sequence would signal that subsequent bits should be parsed as a
>> higher code point."
You are correct that in the case of the variable-length UTF-8 and for
the 128 (non-extended/7-bit) ASCII characters only, this isn't a
problem, because with them, code points (U+xxxx) and code units
(bytes) actually ARE still substantially identical. That saving grace
pretty much does not exist with other, non-UTF-8 Unicode encodings.
Okay, maybe it still does if you drop all the leading zeroes over
multiple bytes. However:

3. I would be wary of dropping leading zeroes in the case of Unicode
code point support. With Alt codes, the precedent of optionally
allowing the dropping of leading zeroes has been set, but pretty much
all Unicode documentation I'm aware of consistently prints code points
in the U+xxxx format (or longer, up to U+10FFFF where applicable).
There's a good argument for supporting code point entry exactly as
written, and nobody writes U+0 through U+FFF.
If you install the gucharmap package
<http://ports.su/x11/gnome/gucharmap>, it has a Character Details tab
where you can not only see how much UTF-8 code units (bytes) can
differ from code points (U+xxxx), but you can also see that even for
those low code points where both match, the U+xxxx is still not
printed with leading zeroes omitted.

4. One also should be as restrained and conservative as is practical
in terms of "claiming" key combinations, especially claiming them
system-wide. Yes, users could set up some hotkey somewhere that kills
and relaunches altnumd (I'm not even sure if that belongs in altnumd
itself), but you don't want to do that all the time just to type a key
combo that collides with altnumd. "Hold down Alt while typing U,
<x>,<x>,<x>,<x>, then release Alt" is quite specific, and could reduce
cases where a sequence in .altnumrc collides with something else.
"Hold down Alt while typing up to three digits on the number pad, then
release Alt" is also relatively specific, though perhaps one might
accept non-numpad digit entry too, or make that choice configurable.
Alt+<n> single digit is more likely to collide with something, though
the long-standing precedent of Alt codes existing at least on some
platforms may make that less likely.

5. Perhaps there could be an opportunity for simplifying and unifying
Alt+U<codept> and existing iffy Ctrl+Shift U+xxxx support? OTOH, maybe
it's better to deliberately not collide with that other method and
maybe that's a good reason for a universal Unicode code point method
to reside at its own key combo. Remember, my actual goal is Alt code
support, not Alt+U<codept> support. The opportunity to tack on
U<codept> support once Alt+<numpad> support exists was more of an
outgrowth showing that at least for now, our desires seem to point in
the same direction.

I'll pause here, because this has gotten long.
"Further bulletins as events warrant." Or when I get around to it, rather.

All the best now,
Ian

>> There's a huge competence gap between us,
>
> Quite likely.  I'm so clueless that right now, i can't even seem to get
> Compose to work even though i'm sure i had it working in the past.
> This is on amd64-current, inside xterm(1) and ksh(1):
>
>    $ locale
>   LANG=
>   LC_COLLATE="en_US.UTF-8"
>   LC_CTYPE="en_US.UTF-8"
>   LC_MONETARY="en_US.UTF-8"
>   LC_NUMERIC="en_US.UTF-8"
>   LC_TIME="en_US.UTF-8"
>   LC_MESSAGES="en_US.UTF-8"
>   LC_ALL=en_US.UTF-8
>    $ setxkbmap -query -v -v -v
>   Setting verbose level to 8
>   locale is en_US.UTF-8
>   Trying to load rules file ./rules/base...
>   Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
>   Success.
>   Applied rules from base:
>   rules:      base
>   model:      pc105
>   layout:     de
>   Trying to build keymap using the following components:
>   keycodes:   xfree86+aliases(qwertz)
>   types:      complete
>   compat:     complete
>   symbols:    pc+de+inet(pc105)+terminate(ctrl_alt_bksp)
>   geometry:   pc(pc105)
>   rules:      base
>   model:      pc105
>   layout:     de
>
> At this point, the caps key toggles caps lock, i.e. pressing
>
>   caps a caps a
>
> results in the input "Aa".
>
>    $ setxkbmap -option compose:caps -v -v -v
>   Setting verbose level to 8
>   locale is en_US.UTF-8
>   Trying to load rules file ./rules/base...
>   Trying to load rules file /usr/X11R6/share/X11/xkb/rules/base...
>   Success.
>   Applied rules from base:
>   rules:      base
>   model:      pc105
>   layout:     de
>   options:    compose:caps
>   Trying to build keymap using the following components:
>   keycodes:   xfree86+aliases(qwertz)
>   types:      complete
>   compat:     complete
>   symbols:    pc+de+inet(pc105)+terminate(ctrl_alt_bksp)+compose(caps)
>   geometry:   pc(pc105)
>
> Now, the caps key no longer toggles caps lock and becomes a dead key,
> i.e. pressing
>
>   caps , c caps " a
>
> results in the input "ca".  However, the resulting input is really
> ASCII-c ASCII-a rather than the expected c-cedille a-umlaut.
> It looks like Compose works well enough to discard the , and ",
> but not well enough to actually generate non-ASCII characters.
>
> Somewhat grumpy today,
>   Ingo
>

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

ropers
In reply to this post by Ingo Schwarze
On 12/07/2019, Ingo Schwarze <[hidden email]> wrote:

> Hi NilsOla,
>
> NilsOla Nilsson wrote on Thu, Jul 11, 2019 at 11:24:24PM +0200:
>
>> I am using cwm and ksh and at present my compose key
>> work in st and in gvim, but not in xterm.
>> I am on current updated a few weeks ago.
>
> Oh.  Thank you for the hint.  Given my clumsiness with X keyboard
> configuration, i assumed it was just me, but your additional data
> indicates there may actually be a regression in xterm(1).
>
> Who knows what a GTK leviathan like gvim is doing.  But suckless
> software is about the opposite of bloatware and i would be quite
> surprised if it internally re-implemented the Compose mechanism.
> So the fact that Compose works in the x11/st(1) port (which i
> can confirm) means that i probably do have Compose correctly
> configured and that xterm(1) is somehow breaking the characters
> it receives from X - not all of them, but those where Compose
> was involved.
>
> The above suspicion is supported by the fact that Compose also
> works in xedit(1).  It even works in xclipboard(1), xman(1),
> nedit(1), except that these programs don't support UTF-8 but
> appear to be hardcoded to Latin-1, such that the entered UTF-8
> characters appear as garbage two-character sequences.
>
> To me, this looks suspiciously like a bug now.  :-(

Oh -- thank you both for that. I hadn't noticed, but that could have
really bitten me, as I'm currently using xterm more, chiefly for its
UTF-8 support that the console doesn't have, especially ever since
I've belatedly figured out Ctrl+right-click and Ctrl+left-click in
xterm. Look at all these choices I didn't know I had. :)

Ian

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

Ingo Schwarze
In reply to this post by ropers
Hi Ian,

ropers wrote on Fri, Jul 12, 2019 at 01:37:16AM +0200:
> On 11/07/2019, Ingo Schwarze <[hidden email]> wrote:

>> There is no reason to make it different.  ASCII is a subset of Unicode,
>> with the same numbering.  So the "U" looks redundant to me.

> There are several reasons why it isn't redundant:

Your reasons are not part of the solution but part of the problem.

Logically, the task is very simple:

 1. Only UTF-8 input is needed because ASCII is a subset of that,
    and no other character set or encoding must be supported.
    (Of course, a method to input arbitrary bytes that do not form
    characters is also needed but that is rather tangential to this
    discussion).

 2. Physical keys must produce the characters printed on them.

 3. One method is needed to input codepoints numerically, but not
    more than one.

 4. One method may be convenient to enter often-needed characters
    quickly (like Compose in X) and likely one mathod for languages
    that need very large numbers of characters (i don't know much
    about those).

Items 1 to 3 are really the meat of the matter.  Item 4 is more like
an add-on for convenience.

That said, i think i'll retire from this thread because we are just
talking.  Besides, i have a strong suspicion that you shold pick a
simpler project, in particular as your first project.  This one
seems seriously difficult conceptionally, exceedingly difficult
technically, in particular regarding the complex kernel-xenocara-userland
interactions, and *terrifyingly* complicated from a system integration
perspective - and you know, when the goal is to make something fit
for practical use (and commit), the system intergration part is
often the most dangerous obstacle in the first place, often challenging
even for seasoned developers.  Nothing wrong with picking a project
that is *technically* difficult if you feel adventurous (as long
as it is cleanly self-contained), but do try to start with projects
where system integration is easy, or expect almost certain eventual
failure - quite likely after already having invested lots of work.

Yours,
  Ingo


P.S. about broken spam filters:

> I've just noticed yet another false positive where Gmail has
> classified your email as spam here for the n-th time.  I'm not sure if
> that's just happening to my mailbox, or if it's Gmail-wide or, worse,
> if lots of MTAs out there treat your emails as spam.

So far, i have heard about outlook.com (which obviously nobody
should use anyway) occasionally classifying all mail coming from
the University of Karlsruhe (kit.edu) as spam, and about gmail.com
doing the same in rare cases.  Both of these appear to sometimes
consider that university - which is among the dozen or so most
important technical research universities in Germany - as a spam
site.  There is nothing much that i can do about that.

> (There seems to be a trend where big corps are quite happy to
> discourage people from running their own MTAs

Not just running their own MTAs, also using non-commercial .edu
infrastructure.

> and increasingly throw their weight around rejecting anything that
> isn't credentialled up the wazoo with SPF, DKIM, DMARC or whatever,

Of course large advertising corporations do what it takes to grab
market share, and vendor-lock in by breaking compatibility is a classic
method for doing that.

If your spam filter is broken, fix it.  I can hardly help with that.
If your ISP won't let you fix it, get a better provider.

Even if i wanted to contact the kit.edu postmasters to ask whether
they can do anything about your problem, you didn't provide any
information whatsoever - like for which exact reason which receiving
Google mail server classified which sending kit.edu mailserver as
a spam site, and at which exact time.  Such information should be
sent privately, not to public lists.

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

Roderick

On Fri, 12 Jul 2019, Ingo Schwarze wrote:

>> (There seems to be a trend where big corps are quite happy to
>> discourage people from running their own MTAs
>
> Not just running their own MTAs, also using non-commercial .edu
> infrastructure.

Not only that.

Here you see the developer of cyrus-imap moving to MS Exchange
and G Suite:

https://www.cmu.edu/computing/services/comm-collab/email-calendar/cyrus/decommission.html

The same for the developer of UW imap:

https://itconnect.uw.edu/connect/email/google-apps/
https://itconnect.uw.edu/connect/email/exchange-online/

And the same from the house of exim:

https://help.uis.cam.ac.uk/service/email

And sure they are not an exception, it seems to be a trend.

Rod.

Reply | Threaded
Open this post in threaded view
|

Re: When will OpenBSD become a friendly place for bug reporters?

Christian Weisgerber
In reply to this post by Ingo Schwarze
On 2019-07-11, Ingo Schwarze <[hidden email]> wrote:

> Quite likely.  I'm so clueless that right now, i can't even seem to get
> Compose to work even though i'm sure i had it working in the past.

I use "setxkbmap -option compose:ralt" and compose works as expected
for me in xterm.

Zwölf Boxkämpfer jagen Viktor quer über den großen Sylter Deich.

Dès Noël où un zéphyr haï me vêt de glaçons würmiens je dîne d'exquis
rôtis de bœuf au kir à l'aÿ d'age mûr & cætera !

Pójdźże, kiń tę chmurność w głąb flaszy!

(Yes, I entered those in an OpenBSD xterm.)

--
Christian "naddy" Weisgerber                          [hidden email]

12