Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #26843 > unrolled thread

vtm: tiling window manager with drag and drop

Back to article view | Back to comp.misc

Contents

  vtm: tiling window manager with drag and drop Salvador Mirzo <smirzo@example.com> - 2025-03-08 21:31 -0300
    Re: vtm: tiling window manager with drag and drop candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-03-13 21:00 +0000
      Re: vtm: tiling window manager with drag and drop Salvador Mirzo <smirzo@example.com> - 2025-03-14 12:20 -0300
        Re: vtm: tiling window manager with drag and drop candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-03-14 19:50 +0000
          Re: vtm: tiling window manager with drag and drop D <nospam@example.net> - 2025-03-15 22:57 +0100
            Re: vtm: tiling window manager with drag and drop kludge@panix.com (Scott Dorsey) - 2025-03-16 11:32 -0400
              Re: vtm: tiling window manager with drag and drop Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-19 23:53 +0000
          Re: vtm: tiling window manager with drag and drop Salvador Mirzo <smirzo@example.com> - 2025-03-16 22:32 -0300
            Re: vtm: tiling window manager with drag and drop candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-03-21 18:50 +0000
        Re: vtm: tiling window manager with drag and drop D <nospam@example.net> - 2025-03-15 23:00 +0100
          Re: vtm: tiling window manager with drag and drop candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-03-21 18:40 +0000
            Re: vtm: tiling window manager with drag and drop D <nospam@example.net> - 2025-03-21 22:13 +0100
              Re: vtm: tiling window manager with drag and drop candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-03-23 14:20 +0000
                Re: vtm: tiling window manager with drag and drop D <nospam@example.net> - 2025-03-23 22:21 +0100
    Re: vtm: tiling window manager with drag and drop Ian <${send-direct-email-to-news1021-at-jusme-dot-com-if-you-must}@jusme.com> - 2025-03-16 08:52 +0000
      Re: vtm: tiling window manager with drag and drop Salvador Mirzo <smirzo@example.com> - 2025-03-17 14:27 -0300
      Re: vtm: tiling window manager with drag and drop Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-19 06:54 +0000
        Re: vtm: tiling window manager with drag and drop Ian <${send-direct-email-to-news1021-at-jusme-dot-com-if-you-must}@jusme.com> - 2025-04-19 08:20 +0000
          Re: vtm: tiling window manager with drag and drop Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-24 00:20 +0000
            Re: vtm: tiling window manager with drag and drop Ian <${send-direct-email-to-news1021-at-jusme-dot-com-if-you-must}@jusme.com> - 2025-04-24 11:04 +0000

#26843 — vtm: tiling window manager with drag and drop

Has anyone ever tried this?

--8<-------------------------------------------------------->8---
It is a text-based application where the entire user interface is
represented by a mosaic of text cells forming a TUI matrix. The
resulting TUI matrix is ​​just rendered either into its own GUI window or
into a compatible text console.

It can wrap any console application and be nested indefinitely, forming
a text-based desktop environment.
--8<-------------------------------------------------------->8---

Sources:
https://github.com/directvt/vtm
https://www.youtube.com/watch?v=kofkoxGjFWQ

[toc] | [next] | [standalone]

#26896

Salvador Mirzo <smirzo@example.com> wrote at 00:31 this Sunday (GMT):
> Has anyone ever tried this?
>
> --8<-------------------------------------------------------->8---
> It is a text-based application where the entire user interface is
> represented by a mosaic of text cells forming a TUI matrix. The
> resulting TUI matrix is ​​just rendered either into its own GUI window or
> into a compatible text console.
>
> It can wrap any console application and be nested indefinitely, forming
> a text-based desktop environment.
> --8<-------------------------------------------------------->8---
>
> Sources:
> https://github.com/directvt/vtm
> https://www.youtube.com/watch?v=kofkoxGjFWQ


It's certainly a cool idea, but I don't see why you wouldn't just go
full terminal (tmux) or full ui (another wm). Maybe this would be useful
for SSH sessions, though?
-- 
user <candycane> is generated from /dev/urandom

[toc] | [prev] | [next] | [standalone]

#26903

candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
writes:

> Salvador Mirzo <smirzo@example.com> wrote at 00:31 this Sunday (GMT):
>> Has anyone ever tried this?
>>
>> --8<-------------------------------------------------------->8---
>> It is a text-based application where the entire user interface is
>> represented by a mosaic of text cells forming a TUI matrix. The
>> resulting TUI matrix is ​​just rendered either into its own GUI window or
>> into a compatible text console.
>>
>> It can wrap any console application and be nested indefinitely, forming
>> a text-based desktop environment.
>> --8<-------------------------------------------------------->8---
>>
>> Sources:
>> https://github.com/directvt/vtm
>> https://www.youtube.com/watch?v=kofkoxGjFWQ
>
>
> It's certainly a cool idea, but I don't see why you wouldn't just go
> full terminal (tmux) or full ui (another wm). Maybe this would be useful
> for SSH sessions, though?

That's close to what I thought.  I think we've reached a point where a
lot of good stuff is already done and we don't really need more, even
though people can do amazing stuff.

I'm currently reading an article whose title is ``[t]he computer built
to last 50 years'' by Ploum, dated 2021 February 4Th.  (I should post it
here.)  The article has this tone---we don't need to replace computers
all the time.  Most of that ``need'' is actually just distraction.

We suffer a lot from distraction.  If we remove all distraction, what
happens?  We get distracted with what we have left---which is probably a
pretty good deal. :)

Even most of our conversations here on USENET would be classified as
distraction.  But I don't think we should kill conversation because
thinking is important in work and I do think thinking is kind of a
collective thing.  

I've had thoughts of working a lot in offline mode.  I could get USENET
messages every Monday, say, and then spend the rest of the week in
USENET offline mode.  Just that move is already a time saver because
working in batch mode is /usually/ more efficient.

[toc] | [prev] | [next] | [standalone]

#26905

Salvador Mirzo <smirzo@example.com> wrote at 15:20 this Friday (GMT):
> candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
> writes:
>
>> Salvador Mirzo <smirzo@example.com> wrote at 00:31 this Sunday (GMT):
>>> Has anyone ever tried this?
>>>
>>> --8<-------------------------------------------------------->8---
>>> It is a text-based application where the entire user interface is
>>> represented by a mosaic of text cells forming a TUI matrix. The
>>> resulting TUI matrix is ​​just rendered either into its own GUI window or
>>> into a compatible text console.
>>>
>>> It can wrap any console application and be nested indefinitely, forming
>>> a text-based desktop environment.
>>> --8<-------------------------------------------------------->8---
>>>
>>> Sources:
>>> https://github.com/directvt/vtm
>>> https://www.youtube.com/watch?v=kofkoxGjFWQ
>>
>>
>> It's certainly a cool idea, but I don't see why you wouldn't just go
>> full terminal (tmux) or full ui (another wm). Maybe this would be useful
>> for SSH sessions, though?
>
> That's close to what I thought.  I think we've reached a point where a
> lot of good stuff is already done and we don't really need more, even
> though people can do amazing stuff.

Reinventing the wheel can be good for learning, but I definitely agree.

> I'm currently reading an article whose title is ``[t]he computer built
> to last 50 years'' by Ploum, dated 2021 February 4Th.  (I should post it
> here.)  The article has this tone---we don't need to replace computers
> all the time.  Most of that ``need'' is actually just distraction.
>
> We suffer a lot from distraction.  If we remove all distraction, what
> happens?  We get distracted with what we have left---which is probably a
> pretty good deal. :)

Productive distraction :D

> Even most of our conversations here on USENET would be classified as
> distraction.  But I don't think we should kill conversation because
> thinking is important in work and I do think thinking is kind of a
> collective thing.  
>
> I've had thoughts of working a lot in offline mode.  I could get USENET
> messages every Monday, say, and then spend the rest of the week in
> USENET offline mode.  Just that move is already a time saver because
> working in batch mode is /usually/ more efficient.


I use slrnpull, but it's set up to sync every 10 minutes or so. Seeing a
ton of messages piled up makes me kinda nervous.
-- 
user <candycane> is generated from /dev/urandom

[toc] | [prev] | [next] | [standalone]

#26907

On Fri, 14 Mar 2025, candycanearter07 wrote:

>>
>> That's close to what I thought.  I think we've reached a point where a
>> lot of good stuff is already done and we don't really need more, even
>> though people can do amazing stuff.
>
> Reinventing the wheel can be good for learning, but I definitely agree.

Yes, I agree too. It seems computers UIs and tools generally have stagnated. At
least when it comes to operating systems.

[toc] | [prev] | [next] | [standalone]

#26912

D  <nospam@example.net> wrote:
>On Fri, 14 Mar 2025, candycanearter07 wrote:
>
>>>
>>> That's close to what I thought.  I think we've reached a point where a
>>> lot of good stuff is already done and we don't really need more, even
>>> though people can do amazing stuff.
>>
>> Reinventing the wheel can be good for learning, but I definitely agree.
>
>Yes, I agree too. It seems computers UIs and tools generally have stagnated. At
>least when it comes to operating systems.

I disagree.  The commodity "IT" systems have not stagnated, but gone 
backward to a point where actual usability is less than it was a decade
or two ago.
--scott
-- 
"C'est un Nagra. C'est suisse, et tres, tres precis."

[toc] | [prev] | [next] | [standalone]

#27243

On Sun, 16 Mar 2025 11:32:42 -0400 (EDT), Scott Dorsey wrote:

> The commodity "IT" systems have not stagnated, but gone backward to
> a point where actual usability is less than it was a decade or two
> ago.

I would disagree with that. Having recently (actually it was close to 2 
years ago -- doesn’t feel that long) upgraded my main workstation, it was 
a massive jump in usability compared to its decade-old predecessor. The 
comparison is kept fresh by the fact that that old machine now serves 
backup duties, so I do still need to do a few things on it once in a 
while.

[toc] | [prev] | [next] | [standalone]

#26921

candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
writes:

> Salvador Mirzo <smirzo@example.com> wrote at 15:20 this Friday (GMT):
>> candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
>> writes:
>>
>>> Salvador Mirzo <smirzo@example.com> wrote at 00:31 this Sunday (GMT):
>>>> Has anyone ever tried this?
>>>>
>>>> --8<-------------------------------------------------------->8---
>>>> It is a text-based application where the entire user interface is
>>>> represented by a mosaic of text cells forming a TUI matrix. The
>>>> resulting TUI matrix is ​​just rendered either into its own GUI window or
>>>> into a compatible text console.
>>>>
>>>> It can wrap any console application and be nested indefinitely, forming
>>>> a text-based desktop environment.
>>>> --8<-------------------------------------------------------->8---
>>>>
>>>> Sources:
>>>> https://github.com/directvt/vtm
>>>> https://www.youtube.com/watch?v=kofkoxGjFWQ
>>>
>>>
>>> It's certainly a cool idea, but I don't see why you wouldn't just go
>>> full terminal (tmux) or full ui (another wm). Maybe this would be useful
>>> for SSH sessions, though?
>>
>> That's close to what I thought.  I think we've reached a point where a
>> lot of good stuff is already done and we don't really need more, even
>> though people can do amazing stuff.
>
> Reinventing the wheel can be good for learning, but I definitely agree.

Indeed.  When studying something, reinventing the wheel is of primary
importance.  I tend to say ``you don't master until you build it''.
(And, in fact, building once is usually far from enough.)

>> I'm currently reading an article whose title is ``[t]he computer built
>> to last 50 years'' by Ploum, dated 2021 February 4Th.  (I should post it
>> here.)  The article has this tone---we don't need to replace computers
>> all the time.  Most of that ``need'' is actually just distraction.
>>
>> We suffer a lot from distraction.  If we remove all distraction, what
>> happens?  We get distracted with what we have left---which is probably a
>> pretty good deal. :)
>
> Productive distraction :D

That's right. :D

>> Even most of our conversations here on USENET would be classified as
>> distraction.  But I don't think we should kill conversation because
>> thinking is important in work and I do think thinking is kind of a
>> collective thing.  
>>
>> I've had thoughts of working a lot in offline mode.  I could get USENET
>> messages every Monday, say, and then spend the rest of the week in
>> USENET offline mode.  Just that move is already a time saver because
>> working in batch mode is /usually/ more efficient.
>
> I use slrnpull, but it's set up to sync every 10 minutes or so. Seeing a
> ton of messages piled up makes me kinda nervous.

Lol.  How about syncing it daily?

[toc] | [prev] | [next] | [standalone]

#26997

Salvador Mirzo <smirzo@example.com> wrote at 01:32 this Monday (GMT):
> candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
> writes:
>
>> Salvador Mirzo <smirzo@example.com> wrote at 15:20 this Friday (GMT):
>>> candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
>>> writes:
>>>
>>>> Salvador Mirzo <smirzo@example.com> wrote at 00:31 this Sunday (GMT):
>>>>> Has anyone ever tried this?
>>>>>
>>>>> --8<-------------------------------------------------------->8---
>>>>> It is a text-based application where the entire user interface is
>>>>> represented by a mosaic of text cells forming a TUI matrix. The
>>>>> resulting TUI matrix is ​​just rendered either into its own GUI window or
>>>>> into a compatible text console.
>>>>>
>>>>> It can wrap any console application and be nested indefinitely, forming
>>>>> a text-based desktop environment.
>>>>> --8<-------------------------------------------------------->8---
>>>>>
>>>>> Sources:
>>>>> https://github.com/directvt/vtm
>>>>> https://www.youtube.com/watch?v=kofkoxGjFWQ
>>>>
>>>>
>>>> It's certainly a cool idea, but I don't see why you wouldn't just go
>>>> full terminal (tmux) or full ui (another wm). Maybe this would be useful
>>>> for SSH sessions, though?
>>>
>>> That's close to what I thought.  I think we've reached a point where a
>>> lot of good stuff is already done and we don't really need more, even
>>> though people can do amazing stuff.
>>
>> Reinventing the wheel can be good for learning, but I definitely agree.
>
> Indeed.  When studying something, reinventing the wheel is of primary
> importance.  I tend to say ``you don't master until you build it''.
> (And, in fact, building once is usually far from enough.)

Good to know.

>>> I'm currently reading an article whose title is ``[t]he computer built
>>> to last 50 years'' by Ploum, dated 2021 February 4Th.  (I should post it
>>> here.)  The article has this tone---we don't need to replace computers
>>> all the time.  Most of that ``need'' is actually just distraction.
>>>
>>> We suffer a lot from distraction.  If we remove all distraction, what
>>> happens?  We get distracted with what we have left---which is probably a
>>> pretty good deal. :)
>>
>> Productive distraction :D
>
> That's right. :D
>
>>> Even most of our conversations here on USENET would be classified as
>>> distraction.  But I don't think we should kill conversation because
>>> thinking is important in work and I do think thinking is kind of a
>>> collective thing.  
>>>
>>> I've had thoughts of working a lot in offline mode.  I could get USENET
>>> messages every Monday, say, and then spend the rest of the week in
>>> USENET offline mode.  Just that move is already a time saver because
>>> working in batch mode is /usually/ more efficient.
>>
>> I use slrnpull, but it's set up to sync every 10 minutes or so. Seeing a
>> ton of messages piled up makes me kinda nervous.
>
> Lol.  How about syncing it daily?


Maybe I will. It's just programmed using a crontab job anyway. The only
thing is I'd have to remember how to make it not download a max of 20
messages per sync. On the other hand, that would definitely help make it
not be an overwhelming amount of messages :D
-- 
user <candycane> is generated from /dev/urandom

[toc] | [prev] | [next] | [standalone]

#26908

On Fri, 14 Mar 2025, Salvador Mirzo wrote:

> I've had thoughts of working a lot in offline mode.  I could get USENET
> messages every Monday, say, and then spend the rest of the week in
> USENET offline mode.  Just that move is already a time saver because
> working in batch mode is /usually/ more efficient.

This is good thinking! I do my usenet once per day (in offline mode). But I
think it might be wise to perhaps extend it. Well, to a certain degree it
happens naturally. If work increases, my usenetting decreases. ;)

Another thing I'm sometimes struggling with is thread-debt. Some threads, while
interesting, sometimes grow to unsustainable size. At some point they can become
too long to continue, so I must reluctantly abandon them. That feels bad towards
the person who invested a lot of time in writing the post. =(

[toc] | [prev] | [next] | [standalone]

#26996

D <nospam@example.net> wrote at 22:00 this Saturday (GMT):
>
>
> On Fri, 14 Mar 2025, Salvador Mirzo wrote:
>
>> I've had thoughts of working a lot in offline mode.  I could get USENET
>> messages every Monday, say, and then spend the rest of the week in
>> USENET offline mode.  Just that move is already a time saver because
>> working in batch mode is /usually/ more efficient.
>
> This is good thinking! I do my usenet once per day (in offline mode). But I
> think it might be wise to perhaps extend it. Well, to a certain degree it
> happens naturally. If work increases, my usenetting decreases. ;)
>
> Another thing I'm sometimes struggling with is thread-debt. Some threads, while
> interesting, sometimes grow to unsustainable size. At some point they can become
> too long to continue, so I must reluctantly abandon them. That feels bad towards
> the person who invested a lot of time in writing the post. =(


Cheers, I can't focus that well reading through 400 message long
threads.
-- 
user <candycane> is generated from /dev/urandom

[toc] | [prev] | [next] | [standalone]

#27001

On Fri, 21 Mar 2025, candycanearter07 wrote:

> D <nospam@example.net> wrote at 22:00 this Saturday (GMT):
>>
>>
>> On Fri, 14 Mar 2025, Salvador Mirzo wrote:
>>
>>> I've had thoughts of working a lot in offline mode.  I could get USENET
>>> messages every Monday, say, and then spend the rest of the week in
>>> USENET offline mode.  Just that move is already a time saver because
>>> working in batch mode is /usually/ more efficient.
>>
>> This is good thinking! I do my usenet once per day (in offline mode). But I
>> think it might be wise to perhaps extend it. Well, to a certain degree it
>> happens naturally. If work increases, my usenetting decreases. ;)
>>
>> Another thing I'm sometimes struggling with is thread-debt. Some threads, while
>> interesting, sometimes grow to unsustainable size. At some point they can become
>> too long to continue, so I must reluctantly abandon them. That feels bad towards
>> the person who invested a lot of time in writing the post. =(
>
>
> Cheers, I can't focus that well reading through 400 message long
> threads.

We must train hard! Over time, our cognitive abilities can be improved. ;)

[toc] | [prev] | [next] | [standalone]

#27014

D <nospam@example.net> wrote at 21:13 this Friday (GMT):
>
>
> On Fri, 21 Mar 2025, candycanearter07 wrote:
>
>> D <nospam@example.net> wrote at 22:00 this Saturday (GMT):
>>>
>>>
>>> On Fri, 14 Mar 2025, Salvador Mirzo wrote:
>>>
>>>> I've had thoughts of working a lot in offline mode.  I could get USENET
>>>> messages every Monday, say, and then spend the rest of the week in
>>>> USENET offline mode.  Just that move is already a time saver because
>>>> working in batch mode is /usually/ more efficient.
>>>
>>> This is good thinking! I do my usenet once per day (in offline mode). But I
>>> think it might be wise to perhaps extend it. Well, to a certain degree it
>>> happens naturally. If work increases, my usenetting decreases. ;)
>>>
>>> Another thing I'm sometimes struggling with is thread-debt. Some threads, while
>>> interesting, sometimes grow to unsustainable size. At some point they can become
>>> too long to continue, so I must reluctantly abandon them. That feels bad towards
>>> the person who invested a lot of time in writing the post. =(
>>
>>
>> Cheers, I can't focus that well reading through 400 message long
>> threads.
>
> We must train hard! Over time, our cognitive abilities can be improved. ;)


Endurance, more like.. and time management.
-- 
user <candycane> is generated from /dev/urandom

[toc] | [prev] | [next] | [standalone]

#27023

On Sun, 23 Mar 2025, candycanearter07 wrote:

> D <nospam@example.net> wrote at 21:13 this Friday (GMT):
>>
>>
>> On Fri, 21 Mar 2025, candycanearter07 wrote:
>>
>>> D <nospam@example.net> wrote at 22:00 this Saturday (GMT):
>>>>
>>>>
>>>> On Fri, 14 Mar 2025, Salvador Mirzo wrote:
>>>>
>>>>> I've had thoughts of working a lot in offline mode.  I could get USENET
>>>>> messages every Monday, say, and then spend the rest of the week in
>>>>> USENET offline mode.  Just that move is already a time saver because
>>>>> working in batch mode is /usually/ more efficient.
>>>>
>>>> This is good thinking! I do my usenet once per day (in offline mode). But I
>>>> think it might be wise to perhaps extend it. Well, to a certain degree it
>>>> happens naturally. If work increases, my usenetting decreases. ;)
>>>>
>>>> Another thing I'm sometimes struggling with is thread-debt. Some threads, while
>>>> interesting, sometimes grow to unsustainable size. At some point they can become
>>>> too long to continue, so I must reluctantly abandon them. That feels bad towards
>>>> the person who invested a lot of time in writing the post. =(
>>>
>>>
>>> Cheers, I can't focus that well reading through 400 message long
>>> threads.
>>
>> We must train hard! Over time, our cognitive abilities can be improved. ;)
>
>
> Endurance, more like.. and time management.

Hah... true! ;)

[toc] | [prev] | [next] | [standalone]

#26911

On 2025-03-09, Salvador Mirzo <smirzo@example.com> wrote:
> Has anyone ever tried this?
>
> --8<-------------------------------------------------------->8---
> It is a text-based application where the entire user interface is
> represented by a mosaic of text cells forming a TUI matrix. The
> resulting TUI matrix is just rendered either into its own GUI window or
> into a compatible text console.
>
> It can wrap any console application and be nested indefinitely, forming
> a text-based desktop environment.
> --8<-------------------------------------------------------->8---
>
> Sources:
> https://github.com/directvt/vtm
> https://www.youtube.com/watch?v=kofkoxGjFWQ

$ /data/ftp/vtm/vtm
  os: Terminal type: linux
  os: Color mode: xterm truecolor
  os: Mouse mode: VT-style
Segmentation fault (core dumped)

:(

-- 
Ian

"Tamahome!!!" - "Miaka!!!"

[toc] | [prev] | [next] | [standalone]

#26926

Ian
<${send-direct-email-to-news1021-at-jusme-dot-com-if-you-must}@jusme.com>
writes:

> On 2025-03-09, Salvador Mirzo <smirzo@example.com> wrote:
>> Has anyone ever tried this?
>>
>> --8<-------------------------------------------------------->8---
>> It is a text-based application where the entire user interface is
>> represented by a mosaic of text cells forming a TUI matrix. The
>> resulting TUI matrix is just rendered either into its own GUI window or
>> into a compatible text console.
>>
>> It can wrap any console application and be nested indefinitely, forming
>> a text-based desktop environment.
>> --8<-------------------------------------------------------->8---
>>
>> Sources:
>> https://github.com/directvt/vtm
>> https://www.youtube.com/watch?v=kofkoxGjFWQ
>
> $ /data/ftp/vtm/vtm
>   os: Terminal type: linux
>   os: Color mode: xterm truecolor
>   os: Mouse mode: VT-style
> Segmentation fault (core dumped)
>
> :(

Lol.  Such is life. :)

[toc] | [prev] | [next] | [standalone]

#27239

On Sun, 16 Mar 2025 08:52:38 -0000 (UTC), Ian wrote:

> $ /data/ftp/vtm/vtm
>   os: Terminal type: linux os: Color mode: xterm truecolor os: Mouse
>   mode: VT-style
> Segmentation fault (core dumped)

Try running it under GDB and getting a traceback. Is it built with 
debugging symbols?

[toc] | [prev] | [next] | [standalone]

#27240

On 2025-04-19, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sun, 16 Mar 2025 08:52:38 -0000 (UTC), Ian wrote:
>
>> $ /data/ftp/vtm/vtm
>>   os: Terminal type: linux os: Color mode: xterm truecolor os: Mouse
>>   mode: VT-style
>> Segmentation fault (core dumped)
>
> Try running it under GDB and getting a traceback. Is it built with 
> debugging symbols?


$ gdb /data/ftp/vtm/vtm
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /data/ftp/vtm/vtm...(no debugging symbols found)...done.

(gdb) run
Starting program: /data/ftp/vtm/vtm 
  os: Terminal type: xterm-256color
  os: Color mode: xterm truecolor
  os: Mouse mode: VT-style

Program received signal SIGSEGV, Segmentation fault.
0x00000000008d74b7 in ?? ()

(gdb) bt
#0  0x00000000008d74b7 in ?? ()
#1  0x00000000008d6311 in ?? ()
#2  0x00000000008d2889 in ?? ()
#3  0x00000000008d59df in ?? ()
#4  0x00000000008d2889 in ?? ()
#5  0x00000000008d5d82 in ?? ()
#6  0x00000000008b03aa in ?? ()
#7  0x00000000008d2889 in ?? ()
#8  0x00000000008d2939 in ?? ()
#9  0x00000000008b07fe in ?? ()
#10 0x00000000008e6a4f in ?? ()
#11 0x00000000008e6e75 in ?? ()
#12 0x00000000008d25b1 in ?? ()
#13 0x00000000008a585f in ?? ()
#14 0x000000000084b5e8 in ?? ()
#15 0x000000000044703d in ?? ()
#16 0x000000000042e633 in ?? ()
#17 0x00000000008239b8 in ?? ()
#18 0x0000000000825b80 in ?? ()
#19 0x0000000000431f15 in ?? ()

So no :(

To be fair, this is on CentOS7, which seems to have been deprecated
faster than a fast thing. I'll try it on Alma9 at some point.

-- 
Ian

"Tamahome!!!" - "Miaka!!!"

[toc] | [prev] | [next] | [standalone]

#27262

On Sat, 19 Apr 2025 08:20:32 -0000 (UTC), Ian wrote:

>> Is it built with debugging symbols?
>
> ...
> 
> So no :(
> 
> To be fair, this is on CentOS7, which seems to have been deprecated
> faster than a fast thing. I'll try it on Alma9 at some point.

Note that on distros that use prebuilt binary packages, it is common to 
have separate “-dbg” or “-dbgsym” packages that you can install, to add 
back the debugging symbols that are stripped from the release binaries/
libraries.

[toc] | [prev] | [next] | [standalone]

#27263

On 2025-04-24, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

> Note that on distros that use prebuilt binary packages, it is common to 
> have separate “-dbg” or “-dbgsym” packages that you can install, to add 
> back the debugging symbols that are stripped from the release binaries/
> libraries.

The point I was making, obv. too subtly, was that I wasn't interested in
debugging it on an unsupported OS :)


Anyway, for some reason I still have an itch to try this, so on a shiny
new AlmaLinux 9 host, fully updated, we have...


[ian@vm51 vtm]$ cat /etc/system-release
AlmaLinux release 9.5 (Teal Serval)

[ian@vm51 vtm]$ /data/ftp/vtm 
  os: Terminal type: xterm-256color
  os: Color mode: xterm truecolor
  os: Mouse mode: VT-style
Floating point exception (core dumped)


No better.


Ok, now I'm invested, let's try building from source, as we have a suitable
C++20 compiler available on Alma9:

[ian@vm51 ~]$ git clone https://github.com/directvt/vtm.git
Cloning into 'vtm'...
remote: Enumerating objects: 35200, done.
remote: Counting objects: 100% (117/117), done.
remote: Compressing objects: 100% (16/16), done.
remote: Total 35200 (delta 106), reused 101 (delta 101), pack-reused 35083 (from 4)
Receiving objects: 100% (35200/35200), 21.89 MiB | 44.29 MiB/s, done.
Resolving deltas: 100% (25562/25562), done.

[ian@vm51 ~]$ cd vtm

[ian@vm51 vtm]$ cmake . -B bin
-- The C compiler identification is GNU 11.5.0
-- The CXX compiler identification is GNU 11.5.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (0.7s)
-- Generating done (0.0s)
-- Build files have been written to: /home/ian/vtm/bin

[ian@vm51 vtm]$ cmake --build bin
[  2%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lapi.c.o
[  5%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lauxlib.c.o
[  8%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lbaselib.c.o
[ 11%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lcode.c.o
[ 14%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lcorolib.c.o
[ 17%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lctype.c.o
[ 20%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/ldblib.c.o
[ 22%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/ldebug.c.o
[ 25%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/ldo.c.o
[ 28%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/ldump.c.o
[ 31%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lfunc.c.o
[ 34%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lgc.c.o
[ 37%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/linit.c.o
[ 40%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/liolib.c.o
[ 42%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/llex.c.o
[ 45%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lmathlib.c.o
[ 48%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lmem.c.o
[ 51%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/loadlib.c.o
[ 54%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lobject.c.o
[ 57%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lopcodes.c.o
[ 60%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/loslib.c.o
[ 62%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lparser.c.o
[ 65%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lstate.c.o
[ 68%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lstring.c.o
[ 71%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lstrlib.c.o
[ 74%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/ltable.c.o
[ 77%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/ltablib.c.o
[ 80%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/ltm.c.o
[ 82%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lundump.c.o
[ 85%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lutf8lib.c.o
[ 88%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lvm.c.o
[ 91%] Building C object CMakeFiles/lua.dir/_deps/lua-src/src/lzio.c.o
[ 94%] Linking C static library liblua.a
[ 94%] Built target lua
[ 97%] Building CXX object CMakeFiles/vtm.dir/src/vtm.cpp.o
In file included from /home/ian/vtm/src/vtm.cpp:7:
/home/ian/vtm/src/netxs/apps/tile.hpp: In lambda function:
/home/ian/vtm/src/netxs/apps/tile.hpp:338:40: error: expected primary-expression before ‘>’ token
  338 |                     ->plugin<pro::mover>()
      |                                        ^
/home/ian/vtm/src/netxs/apps/tile.hpp:338:42: error: expected primary-expression before ‘)’ token
  338 |                     ->plugin<pro::mover>()
      |                                          ^
/home/ian/vtm/src/netxs/apps/tile.hpp:339:40: error: expected primary-expression before ‘>’ token
  339 |                     ->plugin<pro::focus>(pro::focus::mode::focusable)
      |                                        ^
/home/ian/vtm/src/netxs/apps/tile.hpp:340:21: error: base operand of ‘->’ is not a pointer
  340 |                     ->plugin<pro::keybd>("grip")
      |                     ^~
/home/ian/vtm/src/netxs/apps/tile.hpp:340:40: error: expected primary-expression before ‘>’ token
  340 |                     ->plugin<pro::keybd>("grip")
      |                                        ^
/home/ian/vtm/src/netxs/apps/tile.hpp:341:23: error: request for member ‘plugin’ in ‘("grip")->’, which is of non-class type ‘const char’
  341 |                     ->plugin<pro::luafx>()
      |                       ^~~~~~
/home/ian/vtm/src/netxs/apps/tile.hpp:341:40: error: expected primary-expression before ‘>’ token
  341 |                     ->plugin<pro::luafx>()
      |                                        ^
/home/ian/vtm/src/netxs/apps/tile.hpp:341:42: error: expected primary-expression before ‘)’ token
  341 |                     ->plugin<pro::luafx>()
      |                                          ^
/home/ian/vtm/src/netxs/apps/tile.hpp:343:62: error: expected primary-expression before ‘>’ token
  343 |                     ->plugin<pro::shade<cell::shaders::xlight>>()
      |                                                              ^~
/home/ian/vtm/src/netxs/apps/tile.hpp:343:65: error: expected primary-expression before ‘)’ token
  343 |                     ->plugin<pro::shade<cell::shaders::xlight>>()
      |                                                                 ^
gmake[2]: *** [CMakeFiles/vtm.dir/build.make:76: CMakeFiles/vtm.dir/src/vtm.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:111: CMakeFiles/vtm.dir/all] Error 2
gmake: *** [Makefile:136: all] Error 2


Hmph.

A pity, as I really want to try this, but don't need another project right now...


-- 
Ian

"Tamahome!!!" - "Miaka!!!"

[toc] | [prev] | [standalone]

Back to top | Article view | comp.misc

csiph-web