From frederikeriksen at get2net.dk  Tue Nov  7 19:46:00 2006
From: frederikeriksen at get2net.dk (Frederik Eriksen)
Date: Tue Nov  7 19:46:14 2006
Subject: [Logiweb] Transitively referenced pages
Message-ID: <4550D468.80708@get2net.dk>

An HTML attachment was scrubbed...
URL: http://lists.diku.dk/mailman/private/logiweb/attachments/20061107/c653a237/attachment.html
From grue at diku.dk  Wed Nov  8 09:25:13 2006
From: grue at diku.dk (Klaus Ebbe Grue)
Date: Wed Nov  8 09:25:14 2006
Subject: [Logiweb] Transitively referenced pages
In-Reply-To: <4550D468.80708@get2net.dk>
References: <4550D468.80708@get2net.dk>
Message-ID: <Pine.LNX.4.61.0611080903110.8166@tyr.diku.dk>

Hi Frederik,

You describe a situation with the following references:
   B -> A
   C -> B
   C -> A
Then you update A to A2 and C to C2, which creates
   B -> A
   C2 -> B
   C2 -> A2
That gives problems because lemmas in B reference constructs in A whereas 
lemmas in C2 reference constructs in A2. That essentially makes lemmas in 
B useless in C2.

There is no counter to this problem except recompiling B after 
recompiling A and before recompiling C. Sorry. And there is basically no 
way to change the situation.

The problem a consequence of the immutability of Logiweb pages. It is much 
like the problem in functional programming that if one wants to change the 
last element of a list, then one has to reconstruct the entire list. 
Immutability has its drawbacks, but Logiweb depends completely on it. 
Without immutability, there would be worse problems.

My suggestion until further is one of
1) recompile B manually whenever A is recompiled.
2) set up make files for recompiling referenced pages when .lgw
    is older than .pyk.
3) work on one big page.

Option 3) is obviously a bad choice if the page is very big. I suggest 
(I suppose you already do this, so it is not much of a help) that you put 
very stable things in page A so you rarely need to recompile A, that you 
put less stable things in B so you occasionally need to recompile B and 
that you put you experimental proofs in C. I have never bothered to set 
up make files myself.

If possible, run Logiweb on a fast machine of your own. Diku's computers 
are often saturated, and a standard gaming computer with dual boot and
Linux/Logiweb works fine for me.

Klaus
-------------- next part --------------
_______________________________________________
Logiweb mailing list
Logiweb@diku.dk
http://lists.diku.dk/mailman/listinfo/logiweb
(Web access from inside DIKUs LAN only)
From frederikeriksen at get2net.dk  Sun Nov 12 21:20:03 2006
From: frederikeriksen at get2net.dk (Frederik Eriksen)
Date: Sun Nov 12 21:20:04 2006
Subject: [Logiweb] Referencing faulty pages
Message-ID: <455781F3.6030901@get2net.dk>

Hi logiweb@diku.dk

Suppose you're working on a page called B, which references a page 
called A. Page A is faulty; that is, it wasn't deemed correct by the 
proof checker. In contrast, page B in itself is not faulty. Now you let 
the proof checker verify page B. What happens? Will the checker take the 
correctness of page A for granted, or will it deem page B faulty because 
it references faulty lemmas from page A?

Best Regards
Frederik Eriksen.
From grue at diku.dk  Mon Nov 13 14:28:58 2006
From: grue at diku.dk (Klaus Ebbe Grue)
Date: Mon Nov 13 14:29:06 2006
Subject: [Logiweb] Referencing faulty pages
In-Reply-To: <455781F3.6030901@get2net.dk>
References: <455781F3.6030901@get2net.dk>
Message-ID: <Pine.LNX.4.61.0611131422010.8731@tyr.diku.dk>

Hi Frederik

> Suppose you're working on a page called B, which references a page called A. 
> Page A is faulty; that is, it wasn't deemed correct by the proof checker. In 
> contrast, page B in itself is not faulty. Now you let the proof checker 
> verify page B. What happens? Will the checker take the correctness of page A 
> for granted, or will it deem page B faulty because it references faulty 
> lemmas from page A?

If a proof on page B references a lemma proved on page A, and page A was 
deemed faulty, then page B is deemed faulty. Apart from that, errors on 
page A does not affect the correctness of page B. For that reason, one can 
freely use definitions available on faulty pages as long as one does not 
use lemmas from A.

As an additional remark, if page A was deemed correct, but was checked by 
a different proof checker, then the present proof checker does not allow 
references to lemmas on page A. In other words, the proof checker trusts 
itself, but does not trust any other proof checker.

Klaus
From frederikeriksen at get2net.dk  Thu Nov 16 16:42:10 2006
From: frederikeriksen at get2net.dk (Frederik Eriksen)
Date: Thu Nov 16 16:42:17 2006
Subject: [Logiweb] Restoring your cache
Message-ID: <455C86D2.1050901@get2net.dk>

Hi logiweb@diku.dk

Today I compiled one of my .pyk files using the options
  level=submit   cache=[a cache directory of mine].
As expected, pyk generated a file in the cache directory. However, 
subseqently I deleted this file by accident (I was trying to delete an 
obsolete cache file, but got the names wrong). Is there a way to restore 
the cache file from the submitted Logiweb page without having to recompile?

Best Regards
Frederik Eriksen.
From grue at diku.dk  Thu Nov 16 17:07:11 2006
From: grue at diku.dk (Klaus Ebbe Grue)
Date: Thu Nov 16 17:07:14 2006
Subject: [Logiweb] Restoring your cache
In-Reply-To: <455C86D2.1050901@get2net.dk>
References: <455C86D2.1050901@get2net.dk>
Message-ID: <Pine.LNX.4.61.0611161653310.14372@tyr.diku.dk>

Hi Frederik

> Today I compiled one of my .pyk files using the options
> level=submit   cache=[a cache directory of mine].
> As expected, pyk generated a file in the cache directory. However, 
> subseqently I deleted this file by accident (I was trying to delete an 
> obsolete cache file, but got the names wrong). Is there a way to restore the 
> cache file from the submitted Logiweb page without having to recompile?

Don't worry. The pyk compiler repairs the cache automatically. You don't 
have to do anything. You will just see that the pyk compiler uses more 
time on a compilation next time you reference the page whose cache entry 
was deleted.

If your cache grows too big, try deleting the entire cache. Then only the 
entries you actually need will be regenerated.

Klaus
