9front - general discussion about 9front
 help / color / mirror / Atom feed
* [9front] Nail: embrace, extend, extinguish
@ 2020-12-29  3:42 ori
  2020-12-29 10:45 ` julien
  2020-12-29 10:46 ` Daniel Moch
  0 siblings, 2 replies; 9+ messages in thread
From: ori @ 2020-12-29  3:42 UTC (permalink / raw)
  To: 9front

Nail was designed from the start as a replacemnt
for Acme mail. I think it's ready.

The default view will chagne -- it's  compact and
threaded, but those who want the old appearance can
get it:

	Nail -T -f'%F %{WWW DD MM hh:mm}\n%s'

Are there any objectons our outstanding bugs that
need to be fixed before this goes in?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9front] Nail: embrace, extend, extinguish
  2020-12-29  3:42 [9front] Nail: embrace, extend, extinguish ori
@ 2020-12-29 10:45 ` julien
  2020-12-29 15:55   ` ori
  2020-12-29 10:46 ` Daniel Moch
  1 sibling, 1 reply; 9+ messages in thread
From: julien @ 2020-12-29 10:45 UTC (permalink / raw)
  To: 9front

I've been using Nail daily since a few weeks and so far I can say it
works very well.
I have a weird behaviour though, selecting a mail in the list and
clicking Delmesg duplicates it (in the list) with the new one marked
for deletion.

Looks like:

83/		  ...
82/   	  Mail title                             <some@email.com>
82/   	∉ Mail title                             <some@email.com>
81/		  ...

Putting the changes only removes the marked one and the remaining one
can't be opened.

--
julienxx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9front] Nail: embrace, extend, extinguish
  2020-12-29  3:42 [9front] Nail: embrace, extend, extinguish ori
  2020-12-29 10:45 ` julien
@ 2020-12-29 10:46 ` Daniel Moch
  2020-12-29 11:17   ` telephil9
  2020-12-29 21:09   ` Lyndon Nerenberg
  1 sibling, 2 replies; 9+ messages in thread
From: Daniel Moch @ 2020-12-29 10:46 UTC (permalink / raw)
  To: ori, 9front

Quoth ori@eigenstate.org:
> Nail was designed from the start as a replacemnt
> for Acme mail. I think it's ready.
> 
> The default view will chagne -- it's  compact and
> threaded, but those who want the old appearance can
> get it:
> 
> 	Nail -T -f'%F %{WWW DD MM hh:mm}\n%s'
> 
> Are there any objectons our outstanding bugs that
> need to be fixed before this goes in?

Two comments, one question.

First, the question: How are you going to handle the manual?  9front
already has a mail(1).  (I'm assuming Nail becomes Mail when it gets
merged.)

Now the comments:

- The manual doesn't document the format specification you mention
  above for the default view.  In fact, the above example *seems* to
  link the format string to the -f flag, but the manual says -f is
  used to specify the maildir (which I believe matches Mail).  I
  basically can't make sense of what's going on there.

- The font set I use (which are all provided in the base system)
  doesn't support the glyph you're using to indicate new messages.  I
  wouldn't consider this a blocker, but I think that needs to get
  resolved at some point, either by patching the glyph into all
  system-provided fonts, or by using one already there.  In my opinion
  the system will feel pretty janky if the base font set doesn't
  support the base utilities.

That's all I have at the moment.  I'm looking forward to seeing Nail
get merged.  The threading alone is a great value-add, and the code
seems a lot cleaner too.  Thanks for taking this on!

-- 
Daniel Moch
https://djmo.ch

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9front] Nail: embrace, extend, extinguish
  2020-12-29 10:46 ` Daniel Moch
@ 2020-12-29 11:17   ` telephil9
  2020-12-29 21:09   ` Lyndon Nerenberg
  1 sibling, 0 replies; 9+ messages in thread
From: telephil9 @ 2020-12-29 11:17 UTC (permalink / raw)
  To: 9front

Quoth Daniel Moch <daniel@danielmoch.com>:
> - The manual doesn't document the format specification you mention
>   above for the default view.  In fact, the above example *seems* to
>   link the format string to the -f flag, but the manual says -f is
>   used to specify the maildir (which I believe matches Mail).  I
>   basically can't make sense of what's going on there.
> 
This is my fault, I did the format patch but totally forgot to follow-up with
the man page update. I will get to it quickly.

And to answer Ori's original question, I have been using Nail daily since it was
made public and do not have any issue with it.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9front] Nail: embrace, extend, extinguish
  2020-12-29 10:45 ` julien
@ 2020-12-29 15:55   ` ori
  2020-12-30 14:03     ` Shawn Nock
  0 siblings, 1 reply; 9+ messages in thread
From: ori @ 2020-12-29 15:55 UTC (permalink / raw)
  To: 9front

Quoth julien@typed-hole.org:
> I've been using Nail daily since a few weeks and so far I can say it
> works very well.
> I have a weird behaviour though, selecting a mail in the list and
> clicking Delmesg duplicates it (in the list) with the new one marked
> for deletion.
> 
> Looks like:
> 
> 83/		  ...
> 82/   	  Mail title                             <some@email.com>
> 82/   	∉ Mail title                             <some@email.com>
> 81/		  ...
> 
> Putting the changes only removes the marked one and the remaining one
> can't be opened.
> 
> --
> julienxx
> 

Does this happen consistently? This is what happens when
mesglineno() computes the incorrect line number and replaces
the wrong line.

I'm guessing that there's a message somewhere between the most
recnet message and message 82 that's somehow incrementing the
line count by 2.

would you be able to send me a dump of the mailbox flags the
next time you see this happen?

This is how I do it:

	% mk mbox.acid
	% acid -l mbox.acid $nailpid
	acid; defn dumpmesg(n){
		complex Mbox mbox;
		local m, p;
	
		p = mbox.mesg;
		loop 0,n do{
			m = *p;
			complex Mesg m;
			print("=== ", *p, " ", *(m.name\s), " flags=", m.flags\x, " state=", m.state\x, " ", *(m.subject\s), "\n");
			p = p + 8;
		}
	}

	acid; dumpmesg(100)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9front] Nail: embrace, extend, extinguish
  2020-12-29 10:46 ` Daniel Moch
  2020-12-29 11:17   ` telephil9
@ 2020-12-29 21:09   ` Lyndon Nerenberg
  1 sibling, 0 replies; 9+ messages in thread
From: Lyndon Nerenberg @ 2020-12-29 21:09 UTC (permalink / raw)
  To: 9front; +Cc: ori

Daniel Moch writes:

> [...]  (I'm assuming Nail becomes Mail when it gets
> merged.)

Yes, please lets merge this as 'Mail' and not 'Nail'.  There's no
need to inflict rcpu on us again.

--lyndon

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9front] Nail: embrace, extend, extinguish
  2020-12-29 15:55   ` ori
@ 2020-12-30 14:03     ` Shawn Nock
  2020-12-30 17:20       ` ori
  2020-12-31  4:49       ` ori
  0 siblings, 2 replies; 9+ messages in thread
From: Shawn Nock @ 2020-12-30 14:03 UTC (permalink / raw)
  To: 9front

I've noticed an issue in a mailing list folder that frequently updates (lots of incoming messages). It seems to occur when I've marked more than one message for deletion, then run Put. During the Put, messages start going away... then I think I see the message list jump (like a new message was added), then I get a crash when it continues to delete messages.

This is the +Errors buffer:
mem user overflow
pool sbrkmem block 4139b0
hdr 0a110c09 00000040 002003e3 00205430 00413320 00000000
tail 00413320 00000000 00000000 00000000 00000000 00000000 | ef2800be 00000040
user data 20 33 41 00  00 00 00 00 | 20 33 41 00  00 00 00 00
panic: pool panic
Nail 9802: suicide: sys: trap: fault read addr=0x0 pc=0x20fb0a
Nail 9802: sys: trap: fault read addr=0x0 pc=0x20fb0a

Here's the output of the dumpmesg on the box after the crash:

=== 0x000000000041a540 38/ flags=0x0000 state=0x0000 Re: [tech] default response?
=== 0x0000000000419ea0 37/ flags=0x0000 state=0x0002 [tech] default response?
=== 0x000000000041ae20 40/ flags=0x0000 state=0x0000 Re: [tech] default response?
=== 0x000000000041a940 39/ flags=0x0000 state=0x0000 Re: [tech] default response?
=== 0x000000000041b8c0 42/ flags=0x0000 state=0x0000 Re: [tech] default response?
=== 0x000000000041bde0 43/ flags=0x0000 state=0x0000 Re: [tech] default response?
=== 0x000000000041b360 41/ flags=0x0000 state=0x0000 Re: [tech] default response?
=== 0x0000000000416d00 27/ flags=0x0000 state=0x0000 Re: [tech] Proposed reversed Gemini for uploads to servers - Feedback wanted
=== 0x0000000000419ac0 36/ flags=0x0000 state=0x0000 Re: [tech] Proposed reversed Gemini for uploads to servers - Feedback wanted
=== 0x0000000000416020 25/ flags=0x0000 state=0x0000 Re: [tech] Proposed reversed Gemini for uploads to servers - Feedback wanted
=== 0x0000000000414000 20/ flags=0x0000 state=0x0002 [tech] Proposed reversed Gemini for uploads to servers - Feedback wanted
=== 0x0000000000414540 21/ flags=0x0000 state=0x0000 Re: [tech] Proposed reversed Gemini for uploads to servers - Feedback wanted
=== 0x0000000000414a40 22/ flags=0x0000 state=0x0000 Re: [tech] Proposed reversed Gemini for uploads to servers - Feedback wanted
=== 0x0000000000417e40 \x01 flags=0x0000 state=0x0003 \x01
=== 0x0000000000416700 \x01 flags=0x0000 state=0x0003 \x01
=== 0x0000000000418400 32/ flags=0x0000 state=0x0000 Re: [tech] Proposed reversed Gemini for uploads to servers - Feedback wanted
=== 0x0000000000417360 29/ flags=0x0000 state=0x0000 Re: [tech] Proposed reversed Gemini for uploads to servers - Feedback wanted
=== 0x0000000000415ba0 \x01 flags=0x0000 state=0x0003 \x01
=== 0x0000000000415540 24/ flags=0x0000 state=0x0000 Re: Hello all
=== 0x0000000000414f80 23/ flags=0x0000 state=0x0000 Re: [tech] Proposed reversed Gemini for uploads to servers - Feedback wanted
=== 0x0000000000412ae0 \x01 flags=0x0000 state=0x0003 \x01
=== 0x00000000004134a0 18/ flags=0x0008 state=0x0000 Re: [tech] doubts (was Re: [spec] [rfc] SEDR 300 VOLUME I)
=== 0x0000000000413a60 19/ flags=0x0008 state=0x0000 Re: [tech] doubts (was Re: [spec] [rfc] SEDR 300 VOLUME I)
=== 0x000000000040ff40 16/ flags=0x0008 state=0x0000 Re: [tech] doubts (was Re: [spec] [rfc] SEDR 300 VOLUME I)
=== 0x0000000000413320 17/ flags=0x0008 state=0x0000 Re: [tech] doubts (was Re: [spec] [rfc] SEDR 300 VOLUME I)
=== 0x0000000000000000 <stdin>:14: (error) indir: can't read address 0xc9a5bc: bad arg in system call

Here's the stack trace:
abort()+0x0 /sys/src/libc/9sys/abort.c:6
ppanic(fmt=0x4048fb)+0x14b /sys/src/libc/port/malloc.c:166
	pv=0x406f48
	msg=0x40bd20
	v=0x4618c0
	n=0x4618c00000000a
panicblock(msg=0x404a0c,p=0x4061b8,b=0x4139b0)+0x52 /sys/src/libc/port/pool.c:718
blockcheck(b=0x4139b0,p=0x4061b8)+0x3f6 /sys/src/libc/port/pool.c:796
	t=0x4139e8
	n=0x90047a920
	i=0x4139e800000009
	q=0x4139d0
	a=0x4139b0
	dsize=0x4139d400000018
	bq=0x4139d0
	eq=0x4139d4
poolreallocl(ndsize=0x18,v=0x4139b8,p=0x4061b8)+0x61 /sys/src/libc/port/pool.c:982
	a=0x4139b0
	odsize=0x461990
	obsize=0x46199038312069
	nbsize=0x2075a000000000
	right=0x0
	left=0x416f70
	nv=0x47206574656c6564
	newb=0x406f48
poolrealloc(p=0x4061b8,v=0x4139b8,n=0x18)+0x46 /sys/src/libc/port/pool.c:1264
	nv=0x4061b8
realloc(size=0x10,v=0x4139b8)+0x58 /sys/src/libc/port/malloc.c:267
	nv=0x416f68
erealloc(p=0x4139c0,n=0x10)+0x1b /usr/glenda/src/Nail/util.c:27
	v=0x207600
addchild(m=0x413a60,p=0x40ff40)+0xd1 /usr/glenda/src/Nail/mbox.c:187
	q=0x412ae0
removemesg(m=0x4134a0)+0x79 /usr/glenda/src/Nail/mbox.c:676
	i=0x0
	p=0x40ff40
mbflush()+0x14e /usr/glenda/src/Nail/mbox.c:708
	i=0x2022ce00000015
	path=0x40f970
	fd=0xe
	m=0x4134a0
	j=0x1500000001
doevent(ev=0x40f0f0)+0x11f /usr/glenda/src/Nail/mbox.c:910
	f=0x40f108
	nf=0x40f10800000001
	p=0x406a40
mbmain(cmd=0x40fc60)+0x20d /usr/glenda/src/Nail/mbox.c:959
	a=0x40fd80
	ev=0x40f0f0
	psee=0xfefefefefefefefe
	pshow=0xfefefefefefefefe
	psend=0xfefefefefefefefe
launcheramd64(arg=0x40fc60,f=0x20238f)+0x10 /sys/src/libthread/amd64.c:11
0xfefefefefefefefe ?file?:0

A perhaps related issue, several times per day I see 'address out of range' Errors. Mostly it's not a nuisance; but perhaps it's related / prerequisite to the main issue?


Thanks,
S
-- 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9front] Nail: embrace, extend, extinguish
  2020-12-30 14:03     ` Shawn Nock
@ 2020-12-30 17:20       ` ori
  2020-12-31  4:49       ` ori
  1 sibling, 0 replies; 9+ messages in thread
From: ori @ 2020-12-30 17:20 UTC (permalink / raw)
  To: 9front

Quoth Shawn Nock <shawn@provisoire.ca>:
> I've noticed an issue in a mailing list folder that frequently
> updates (lots of incoming messages).  It seems to occur when I've
> marked more than one message for deletion, then run Put.  During the
> Put, messages start going away...  then I think I see the message list
> jump (like a new message was added), then I get a crash when it
> continues to delete messages.

Alright, this looks like it's probably related to julien's issue too.
The traces are useful, thanks.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [9front] Nail: embrace, extend, extinguish
  2020-12-30 14:03     ` Shawn Nock
  2020-12-30 17:20       ` ori
@ 2020-12-31  4:49       ` ori
  1 sibling, 0 replies; 9+ messages in thread
From: ori @ 2020-12-31  4:49 UTC (permalink / raw)
  To: 9front

Quoth Shawn Nock <shawn@provisoire.ca>:
> I've noticed an issue in a mailing list folder that frequently
> updates (lots of incoming messages).  It seems to occur when I've
> marked more than one message for deletion, then run Put.  During the
> Put, messages start going away...  then I think I see the message list
> jump (like a new message was added), then I get a crash when it
> continues to delete messages.

I can reproduce this. I'm guessing the bug is in removemsg, but
I don't see anything obvious. Debugging.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2020-12-31  4:50 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-29  3:42 [9front] Nail: embrace, extend, extinguish ori
2020-12-29 10:45 ` julien
2020-12-29 15:55   ` ori
2020-12-30 14:03     ` Shawn Nock
2020-12-30 17:20       ` ori
2020-12-31  4:49       ` ori
2020-12-29 10:46 ` Daniel Moch
2020-12-29 11:17   ` telephil9
2020-12-29 21:09   ` Lyndon Nerenberg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).