Re: Anybody mind if I remove this piece of strange code?

2003-10-20 Thread Jon Steinhart
Robert Elz writes:
   | Anyone have a problem if I remove this test?
 
 Yes.
 
 It is that test that makes folder run in manageable time, without it,
 every message in every folder has to be stat'd to see if it happens to
 be a directory - with it, folders with no sub-folders (which almost all
 folders with many messages count as) can simply be skipped.
 
 kre

How about if I change the test so that it is only ignored for the top
level directory?

Jon



Re: Anybody mind if I remove this piece of strange code?

2003-10-20 Thread Jon Steinhart
Robert Elz wrote:
   | How about if I change the test so that it is only ignored for the top
   | level directory?
 
 That would do much less harm, but is unlikely to be so easy (that function
 gets called for any level in the hierarchy, if I recall correctly).
 
 An alternative would be a try really hard option (inverse of folder -fast)
 that made it ignore the test.
 
 But for your purposes, wouldn't just making a dummy sub-directory in your new
 (symlinks only) Mail directory, until it gets a real folder sub-dir of its own
 do just as well?
 
 kre

OK, I give up.  I guess that this is a special case.  But I found it real
annoying to have to resort to the source code in order to find out why the
command mysteriously didn't work.  I think a warning on the manual page
would suffice.

Jon



Re: A semi-annual poke about progress

2003-06-03 Thread Jon Steinhart
I have it working on Solaris (albeit an old 2.6) and Linux RH9.

 Hi.  Seems like we've had a 1.1 release candidate sitting for a long
 time.  Can we make it a release yet?  It would be nice to have something
 newer than 1.0.4 going into things like Linux distributions.
 
 Hm, well ... how about everyone (including me) makes sure what's on the
 1.1 branch compiles on all of the major platforms that they have access
 to, and if the answer is yes, then we call the head of the 1.1 branch
 1.1 final ?
 
 --Ken



Re: Improving attachment viewing

2002-11-20 Thread Jon Steinhart
 Where we're had to move away from nmh towards gnus is in MIME
 composition (e.g. for the ability to specify inline/attachment).

You might want to look at the attachment stuff that I checked in a while
back.  I implemented it in such a way that it could easily be incorporated
into MH-E.  The short summary is that you can specify the names of attachments
using a header field, and send handles invoking mhbuild as required to
package everything up before sending.  Anno has been extended to assist in
managing the header fields.

 It might be nice to be able to output a character in a scan column if
 attachments are present.  MH-E could even replace that character with a
 paperclip glyph or something to pretty it up.

Seems to me that my notion of scanning attachments is getting the most
attention here, even though it's not the most important part to me.  My
main interest is in being able to read attachments in a more consistent
way.  Maybe an example would help...

Right now, a session looks like this:

% inc
 scan output

% show
 (oh, this looks like a multipart message)

% mhlist
% mhshow -part 1
% mhshow -part 1.1
% mhshow -part 2
 (...)
% next
...

What I'd like to be able to do is:

% inc
 scan output
% show
% next
 (show first part of current message)
% next
 (show next part of current message)
% next
 (...)
% next
 (show first part of next message)

Jon




Re: Improving attachment viewing

2002-11-20 Thread Jon Steinhart
 Hmm. I'm afraid I disagree about this redefinition of next.  Currently, I 
 don't need to do individual mhshows if I just want to sequence through all 
 the parts:  just show, and keep hitting Return, or Ctrl-C to skip a part.
 
 Cheers,
 Dave

Disagreement is good.  I do it too!  If I get a message with 20 photos
attached, I hate having to hit Ctrl-C 20 times just to get to the next
message.  And I also have problems with multiple text parts since the
way things get exec'd I haven't found a reasonable way to pipe the whole
pile through a pager; short body parts that come before long ones scroll
off the top of the screen.

I guess that I just feel that it's bad user interface to have the
behavior depend on the number and type of body parts.

Jon




Re: Improving attachment viewing

2002-11-19 Thread Jon Steinhart
   I've changed the Subject and included [EMAIL PROTECTED]
   since we've spent the last year improving MIME handling in Gnus since
   raw MH wouldn't work for us. We should be able to provide some
   suggestions which would allow us to use more MH and less Gnus. Peter?
   Satyaki?

Yeah, should have changed the subject myself.

What I have in mind is twofold.  First, I'd like to be able to optionally
scan with message parts listed.  Second, I'd like to be able to have an
option to show/next/prev that says show the cur/next/prev message part.
If the next/prev message part doesn't exist, then it should show the
first/last part of the next/prev message.

In other words, I just want to be able to read using a consistent
interface, and the existing next/prev would let me skip attachments if
I didn't want to see them.

Also, I'd like to be able to show message.part  file rather than have
to do the clunky mhstore thing.

Jon




Re: install-mh location

2002-11-18 Thread Jon Steinhart
 Neil W Rickert [EMAIL PROTECTED] writes:
 
  But, install-mh is not likely to be in the user's path;
  it's in the lib directory.  Should I change the
  installation to move this to the bin directory or to
  make a link from the bin to the lib directory?
  
  Make a sym-link, or put in a shell script.
 
 Why?  It's an obvious end-user program, especially now.  It
 belongs in bindir.  I doubt much if anything uses the old path
 (mh-e might, but note that it is still alive and kicking,
 arguably more so than nmh itself), so i say don't even bother
 with a backwards compatability symlink, but if you must have one
 the link goes in libexecdir.
 
 --  
 Eric Gillespie * [EMAIL PROTECTED]

Well, I already checked in a change to make it a link.  Feel free to change it.
By the way, should the manual page be changed from section 8 to section 1?

Jon




Re: Working on the install-mh change questions

2002-11-18 Thread Jon Steinhart
 Jon Steinhart [EMAIL PROTECTED] writes:
 
  3.  If the $HOME environment variable is set, mypath is copied from the
  getenv return.  Why?  It's never changed.
  
  4.  If the $HOME environment variable is not set, mypath is copied from the
  pw_dir member of the returned passwd structure.  Now, I understand that
  this is a static structure, but getpwuid is never called again so I
  don't see why the copy is needed.
  
  4.  If the $HOME environment variable is not set, the pw_dir member of the
  passwd structure returned by getpwuid() is checked for a NULL pointer.
  This can never happen in a non-error return, which is already checked.
  So why the superfluous check?
 
 These checks are not superflous, they are for maintainability.
 Two years from now someone will add a second getenv(3) call and
 waste their (probably volunteer) time trying to figure out how
 they busted the home dir variable.  That is why, unless you are
 writing super-tight-must-be-the-best-performing-code-ever
 applications (which mh is not), it is necessary always to make a
 copy of the static buffer pointed to by the return values of such
 functions.
 
 --  
 Eric Gillespie * [EMAIL PROTECTED]

This is one of those places where we'll have to respectfully disagree.  I'm
obviously in the minority given the quality of software that I see these days,
but I think that programming is still something that should be done by
professionals.  I don't want someone hacking on code that doesn't take the time
to figure out what's going on first.  Protecting against the really silly
mistakes allows such people to make really complex ones.  As I said in my
earlier email, I'm not going to write slow and sloppy  code just because
computers are fast.  Matter of fact, I keep on trying to get up the courage
to tackle m_getfld().

Oh, some details.

 1.  A second getenv() call would not break the code.  The copy was really
 unnecessary.

 2.  It's hard for me to imagine a situation where getpwuid() would #1 get
 called a second time and #2 for a different uid, which is the only that
 a problem would occur.

 3.  If there's a NULL passwd-pw_dir then libc is broken and should be fixed.
 Better that this gets pointed out and fixed rather than covered up so that
 it stays unnoticed and broken.

Oh, and I've wasted some of my volunteer time trying to figure out what the
code did before changing it.  I'd waste less if there was less code.  Best way
to accomplish this is to get rid of the code that doesn't do anything.

Jon




install-mh location

2002-11-17 Thread Jon Steinhart
Well, here's a minor detail that could cause problems.
I have a version of nmh here that has sbr/context_read
modified to give a run install-mh message if mh
isn't installed rather than doing it for the user as
per yesterday's discussion.

But, install-mh is not likely to be in the user's path;
it's in the lib directory.  Should I change the
installation to move this to the bin directory or to
make a link from the bin to the lib directory?

Jon




Appropriateness of new program/feature

2002-11-16 Thread Jon Steinhart
Howdy.  I've been working on a companion mail reading system
for nmh.  In short, this is a system that builds a database
from mail in folders, allowing it to be searched quickly.  It
includes a ranking mechanism, and allows messages to be searched
by rank.  Sort of like the current fad of Bayesian spam filters,
but more general.

I have already checked in external hook modifications to nmh that
allow it to invoke external programs when mail is added, removed, or
refiled.

But, there's one more sticky point.  There's no good way to test whether
or not nmh is installed.  When I set up my program, I want to fail with
an error message if the user hasn't set up a mail directory, etc.

I need to do this because my program needs to invoke some nmh commands
via pipes, like folder -fast to get the current folder, or mhpath +
to get the mail folder.  If there is no mail folder, nmh commands prompt
the user for installation as opposed to failing with an error code.  This
is nice for a user but a real nuisance for a program.

I currently have an is_nmh_installed() function as part of my program.
I really don't like doing it this way because things like how the MH
environment variable works and where to find the mail folder in the profile
seem to me like nmh internals that belong in nmh, not in some other program.

So, I'd like to add something to nmh to allow for installation testing.  I
think that the best way to do this would be to add a report-only option to
install-mh.

Any objections if I do this?

Jon




Re: Appropriateness of new program/feature

2002-11-16 Thread Jon Steinhart
  But, there's one more sticky point.  There's no good way to test whether
  or not nmh is installed.  When I set up my program, I want to fail with
  an error message if the user hasn't set up a mail directory, etc.
 
 Is test -d `mhparam Path` sufficient for your needs?
 
 --  
 Eric Gillespie * [EMAIL PROTECTED]

No.  If mh isn't installed, mhparam will prompt for installation just like
every other mh program.

Jon




Working on the install-mh change questions

2002-11-16 Thread Jon Steinhart
I've started working on the changes for the mh installation thing discussed
earlier.  My plan is to modify context_read() to print a message instead of
invoking install-mh, and to add a -check option to install-mh that allows it
to silently check for installation, returning the status via the exit code.

There's a bunch of strange stuff in context_read() that seems unnecessary.
I'd like to get rid of it, but want to check with y'all in case there's some
undocumented historic necessity of which I'm unaware.  I know that these are
picky things, but I'm just not in the write-sloppy-and-slow-software-camp even
though computers are pretty darned fast these days.

1.  The program starts by checking to see whether or not defpath has been
set, and bails if it has.  Apparently a test in case it's called more
than once.  I've checked all of the other programs, and it never is.

defpath is unnecessarily checked in a number of other places:
sbr/context_del.c
sbr/context_find.c
sbr/context_replace.c
sbr/seq_read.c
sbr/seq_save.c
uip/flist.c
uip/folder.c
uip/rmf.c

I'd prefer to see asserts used to check for dumb programming errors.

2.  Next there's a test to see if mypath is set, and setting it is skipped
if it's already set.  Again, I don't see any way that this could occur.

3.  If the $HOME environment variable is set, mypath is copied from the
getenv return.  Why?  It's never changed.

4.  If the $HOME environment variable is not set, mypath is copied from the
pw_dir member of the returned passwd structure.  Now, I understand that
this is a static structure, but getpwuid is never called again so I
don't see why the copy is needed.

4.  If the $HOME environment variable is not set, the pw_dir member of the
passwd structure returned by getpwuid() is checked for a NULL pointer.
This can never happen in a non-error return, which is already checked.
So why the superfluous check?

5.  There's code that removes a trailing / from mypath if mypath is more
than one character long.  Seems completely unnecessary; the definition
of path names means that // is interpreted as /.  And if that wasn't
the case, this code wouldn't catch multiple trailing slashes anyway.

6.  If an MH environment variable is set and doesn't begin with a / the
MH environment variable is changed to the profile path.  Why bother?
It's never used by anything.  Exec'd programs can get figure this out
if they need to - any exec'd nmh program does that anyway.

Jon




Another working on the install-mh change question

2002-11-16 Thread Jon Steinhart
sbr/context_read does a complicated check for installation involving first
the MH environment variable and second the default profile.  I was surprised
to discover that uip/install-mh does not perform identical tests.  It just
looks for the default profile.  This seems wrong to me.  Should I fix it?

Jon




Re: Questions about nmh 1.1

2002-07-08 Thread Jon Steinhart

 On July 8, 2002 at 11:05, Jon Steinhart wrote:
 
  And I agree, downloading the entire message is the way to go.  Most spam is
  very small compared to even slow V90 speeds which is what I'm stuck with out
  in the country here, so it's no big deal.
 
 Well, I would have to disagree about spam being small and no big deal
 over V90 modem.  Spam messages have been increasing in size since many
 are HTML messages and some with attachments or images.  Also, if you
 are flooded with alot of messages, they add up.
 
 Of course, the annoyance factor is relative for any given person, but
 when I was using dialup, I definitely considered writing my own
 POP filtering tool with interactive capabilities to avoid downloading
 crap (and sometimes the messages may not be spam but from friends and/or
 relatives sending huge-assed attachments that I did not care about).
 
 However, once I got cable modem, my need for such a tool dropped
 considerably.
 
 
 A side note: I considering spam filtering, and other filtering needs,
 mainly delivery issue.  Hence, I think it is best solved done before
 nmh even sees the mail (the boundary is somewhat lose when dealing
 with automatic filing of messages to different folders).  This keeps
 the filtering job independent of the MUA and prevent developers
 re-implementing the wheel for every MUA.
 
  I have a set of changes that I'll submit at an appropriate time.
  These changes allow .mh_profile entries that name programs that are
  executed whenever a piece of mail is incorporated, removed, or refiled.
 
 A nice feature.
 
 --ewh

This has the potential to go way off topic for this mailing list, but...

I agree that a fair number of bytes are consumed by spam.  It isn't a
huge problem for me because even though V90 is the best that I can do
out here in the sticks, it's a full time connection so I'm not waiting
on mail delivery.

I find it hard to see filtering as a delivery issue, but that's probably
because I read my mail on my machine which uses sendmail to deliver mail;
I'm not dialing in somewhere to pick up mail.  If I need to read mail on
the road, I ssh into my machine and read it there.

The big issue on filtering is that everybody wants to filter different
things.  Strange as it seems, some people even like to collect spam for
study.  One of the big difficult issues on filtering is that, while an
occasional false positive can be tolerated, false negatives are completely
unacceptable.  A system that keeps all of your mail and only shows you
interesting messages doesn't lose anything, which helps that problem.  But
it requires sucking down all messages.

Another example, I remember Gosling telling me that especially since he's
become embroiled in the Sun/MS suits that a mirror copy of all of his
incoming and outgoing mail is kept for legal reasons.  This wouldn't work
if incoming mail was rejected based on headers.

Jon




Re: nmh status

2002-05-10 Thread Jon Steinhart

Hey folks, nothing is served by this increasingly heated bickering.

There seems to be a general consensus on the following:

 o  People would like to see work continue on nmh in a timely fashion,

 o  People would like to get a new release together,

 o  CVS is a good tool and people would like to be using it,

 o  The current repository and maintainer are perceived as a roadblock, and

 o  People have been patient for a long time.

So how about we put the egos aside and get to work?

It sound like moving the repository is a good way to get this going, or at
least a way to move the burden to someone else.  As an alternative, how about
the current maintainer giving a firm date, such as June 10, by which time the
repository issues will be resolved.  If they're not resolved by then, it'll
be time to move it.

Jon




Re: nmh status

2002-05-03 Thread Jon Steinhart

I too would like to see work continue on nmh.  I'd like to see the
stuff that I contributed to integrated in to a new release.  It seems
clear that Doug is no longer able to be the maintainer for this, so
someone else should pick it up.  If that means forking the CVS, so
be it.  Let's get something done!

Jon




Re: my attachment code

2001-12-07 Thread Jon Steinhart

Well, since Chad just reposted my attachment code, let me tell you
what's wrong with it.  I'll update it if work is really going to
happen on a new release.

I use anno to add attachment headers.  Anno works by prepending
headers to a message.  Unfortunately, this means that if you add
several attachments to a message, they'll come out in reverse
order.

I am planning to change anno to append header fields instead.
Can't see how this would break any existing applications.  If
anyone is worried about this, I can add a prepend/append option
but that seems unnecessarily complex to me.

Jon




Re: IETF-Announce messages that nmh doesn't like...

2001-10-18 Thread Jon Steinhart

   Jon Notice that the boundary specified on the content-type
   Jon line is NextPart.  This means that --NextPart lines
   Jon are boundary markers.  But, in the remainder of the
   Jon document they're - --NextPart.
 
 It's not clear from the mangled copy attached just WHAT it 
 looked like originally.  The - -- was probably done by nmh in 
 forwarding the message.

OK, OK enough already.  Regardless of whether or not the boundaries
were mangled in the original or by some forwarding program, there
were no parts in the multipart message which is probably what was
causing the message.

Jon




Odd bug, has anyone else seen this?

2001-08-18 Thread Jon Steinhart

I have noticed that mail from one of the mailing lists that I subscribe
to often gets mangled on inc, splitting a message into two.  I can't
tell what's going on for sure because by the time I see the mail, it's
too late.  My suspicion is that somehow one of the headers in the
message body is triggering problems.  There are headers in the body
because the message is a collection of other messages.  Oh, I don't
recall seeing this running the stock nmh, just on the stuff from the
CVS.  Here's what I'm seeing:

(Message inbox:3135)

 Return-Path: [EMAIL PROTECTED]
 Delivery-Date: Fri Aug 17 15:07:17 2001
 Received: from fedney.cdc.nextlink.net (fedney.cdc.nextlink.net [208.177.199.21])
   by darkstar.fourwinds.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id 
f7HM7Abg011851
   for [EMAIL PROTECTED]; Fri, 17 Aug 2001 15:07:11 -0700 (PDT)
 Message-Id: [EMAIL PROTECTED]
 Received: (qmail 26091 invoked by alias); 17 Aug 2001 21:50:12 -
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 Precedence: bulk
 X-No-Archive: yes
 list-help: mailto:[EMAIL PROTECTED]
 list-unsubscribe: mailto:[EMAIL PROTECTED]
 list-post: mailto:[EMAIL PROTECTED]
 Delivered-To: mailing list [EMAIL PROTECTED]
 From: Digestifier [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Date: Fri, 17 Aug 01 17:50:01 EDT
 Subject:  DAT-heads Digest #10
 Content-Length: 15813
 
 DAT-heads Digest #10, Volume #6  Fri, 17 Aug 01 17:50:01 EDT
 
 Contents:
   taping Los Lobos (Bill Shaw)
 
   ...
 
 From: Bob Ramstad [EMAIL PROTECTED]
 Subject: Brad taping (Breakroom Seattle 9/1 9/2 9/3)
 Date: Fri, 17 Aug 2001 10:06:49 -0700

(Message inbox:3136)

 Return-Path: speaking
 Delivery-Date: with the drummer for Bra
 
 Brad allows taping for private noncommercial use only i.e. you are
 
   ...




Odd bug, has anyone else seen this? - another instance

2001-08-18 Thread Jon Steinhart

Here's another instance of the previously posted bug:

(Message inbox:3107)

 Return-Path: [EMAIL PROTECTED]
 Delivery-Date: Wed Aug 15 20:07:07 2001
 Received: from fedney.cdc.nextlink.net (fedney.cdc.nextlink.net [208.177.199.21])
   by darkstar.fourwinds.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id 
f7G36wbg008312
   for [EMAIL PROTECTED]; Wed, 15 Aug 2001 20:07:01 -0700 (PDT)
 Message-Id: [EMAIL PROTECTED]
 Received: (qmail 10960 invoked by alias); 16 Aug 2001 02:50:12 -
 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
 Precedence: bulk
 X-No-Archive: yes
 list-help: mailto:[EMAIL PROTECTED]
 list-unsubscribe: mailto:[EMAIL PROTECTED]
 list-post: mailto:[EMAIL PROTECTED]
 Delivered-To: mailing list [EMAIL PROTECTED]
 From: Digestifier [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Date: Wed, 15 Aug 01 22:50:01 EDT
 Subject:  DAT-heads Digest #8
 Content-Length: 20438
 
 DAT-heads Digest #8, Volume #6   Wed, 15 Aug 01 22:50:01 EDT
 
 Contents:
   Re: Junior Brown (Dan Witt)
 
   ...
 
 From: Bas Ruesink [EMAIL PROTECTED]
 Subject: NEED: U2 radio-broadcast DAT taper for this weekend
 Date: Wed, 15 Aug 2001 16:22:50 +0200
 
 

(Message inbox:3108)

 BAD MSG:
 Definitive’ U2 Radio Documentary to Air in UK
 
   ...




Re: Odd bug, has anyone else seen this?

2001-08-18 Thread Jon Steinhart

 | I have noticed that mail from one of the mailing lists that I subscribe
 | to often gets mangled on inc, splitting a message into two.
 
 Are you running Solaris?  Solaris' mail.local uses Content-Length
 to delimit messages, and leaves From  alone.  That can confuse MH.
 There was an old patch for m_getfld.c for this (which should have been
 integrated after all these years.)

Well, I am running Solaris.  But I can't see why that would make a
difference since I'm using sendmail and nmh, not any of the stock
Solaris stuff.  Also, since this is all in the body of the message
I can't see why this would happen as it shouldn't be looking for
headers anymore.




Is anybody there?

2001-07-23 Thread Jon Steinhart

I posted some patches to improve the user interface for handling
attachments with mail drafts several weeks ago and haven't heard
a thing since.  Was this stuff great?  Terrible?  Need some changes
before merging it with the code base?  Or is nobody there with the
time to look at it?

Jon




Recap on mail message compatibility with RFC822 [and it's successor]

2001-04-26 Thread Jon Steinhart

Thanks for all the responses.  Here's a recap of what I think I heard...

RFC822 [and possibly RFC2822 when I can find a copy since it's not on the ietf
web site, where does one get a copy?] allows single NL characters in header
field bodies, which are supposed to be treated as normal characters, distinct
from the CR-NL pair that indicates the end of a line.  The receiving
transformation will probably preserve these, but the result on a *N[IU]X system
is likely to be an illegal header since the NL will start another line which
is not likely to be a valid header field.  Hey, this could be a great spam hack;
put a NL in, for example, the subject field, followed by a legal looking but
completely bogus received field.

RFC822 allows NUL character in header field bodies.  This probably will break
most *N[IU]X mail programs.

Neither of these are problems at the moment because nobody is doing this stuff.
But if, for example, Microsoft decided to being every mail header field name
with a NUL it would be legal while breaking lots of things.

Is this a correct recap?

Jon Steinhart




Question on compatibility of nmh mail messages with RFC822

2001-04-25 Thread Jon Steinhart

Hi.  I'm working on some mail filtering software that will work with
nmh.  I've noticed a few conflicts between the way messages are stored
in folders and RFC822.  I figure that y'all know something about this,
so just wanted to check to make sure that this is really the case and
that it isn't a problem or might be a problem in the future.

 1.  RFC822 says that header fields end with a CR-LF pair.  That might
 be true on a Microsoft system but not on Linux of any of the other
 UNIX-like systems.  Single CR or LF characters are allowed in
 header field-bodies.  Does this ever occur in real life or might
 it happen some day?

 2.  RFC822 allows the NUL character in header field-bodies.  Code
 written around the C string functions won't handle this of course.
 Does this ever occur in real life or might it happen some day?

Now, I recognize that this stuff is sort of covered by the NETWORK-SPECIFIC
TRANSFORMATIONS section of RFC822 but I have trouble believing that any
*NIX mail system actually does it.  Is this true?

Thanks,
Jon Steinhart




How does one become a nmh-worker?

2000-09-06 Thread Jon Steinhart

I have made a modification to whatnow to support an "attach"
request, and an associated mhattach program.  There are a few other
minor changes to support an "attachproc" in the context.  This all
allows MIME attachments to drafts with a decent user interface.

I'd like to get this into the nmh code base.  I wrote Doug
Morris about this a while ago, and he suggested checking out the
code, making the changes, and mailing the patches to him.  Did this,
and haven't heard back from him despite pinging him a few times.

So, I'm assuming that Doug is on vacation or too busy.  Since
there's been a lot of traffic on the mailing list recently I was hoping
that one of you could help.  My question is how does one get to be a
nmh worker so that one can commit changes to the cvs?  And what's the
etiquette for proposing/making changes?  Thanks.