We'll probably want to go through and fix anythign pointing to it. The top page served on
lists.tlug.jp has at least one link to it.
Separately, it turns out that https://lists.tlug.jp/MLadm/ is not really private; it's protected with HTTP basic authentication with the name and password shown as graphic images on the top page. Unfortunately, I can't duplicate this on a Netlify free account, nor can I really protect the files served by GitHub if I put them in the repo. I don't really want not to fetch these, though. Are there any objections to at least bringing these files into the repo, in a directory separate from the one I'm getting Netlify to serve on the test site (https://lists-tlug-jp.netlify.com), even though GitHub will be "serving" those files on the web?
Ok, it was interesting getting a 72 Kfile site deployed on Netlify, even with no build at all, but https://lists-tlug-jp.netlify.com is up if anybody wants to look at it. Almost a drop-in replacement for the archive portion of lists.tlug.jp, but I just realized there's no search. Maybe that could be replaced with a Google for DDG search. I'm thinking that if we're going to separate the websites that do the list archive vs. subscription management, the latter should change name so that archive indexes and messages get to keep the consistent URL.
To which I guess I should send a message about the pasword protection, etc. The scraper in the lists.tlug.jp-scrape repo is currently downloading it, but it's not committed and is in
.gitignore. I don't know what we have in the way of a backup for it, beyond a branch on home desktop machine that's not been pushed anywhere.
Oh, I see now why that search is only on
tlug-admin! That part of the site is not indexed by search engines, due to both robots.txt blocking it and password protection.
I assumed admin would be non-searchable.. and the common archives would be, because it's not password protected.
The list search was handled by htdig previously. It was changed to google custom search. But the search box is now disabled...
on ML, that is. I think MLAdmin doesn't need to be searchable..
Well I'm kinda feeling like there should be no issue making tlug-admin fully public, since it's nearly that anyway, and it seems really just about keeping some stuff not of general interest off the main list. (And actually I think it would probably just best be replaced by GitHub repo and associated channel here.) But I'm open to doing whatever with it. We can easily enough keep it off the search engines if served by Netlify by maintaining the current
robots.txt, but unfortunately we can't get password protection there without a paid account.
If I understand correctly https://lists-tlug-jp.netlify.com is generated by scraping lists.tlug.jp.
So we would need a way to generate the original html.
Currently, the html archives are being generated from emails by mhonarc. It's being triggered by one of mailman's cron jobs.
So we would need a way to generate the original html.
Currently, the html archives are being generated from emails by mhonarc. It's being triggered by one of mailman's cron jobs.
So right now I'm thinking of just migrating mailman and mhonarc to a new place. Keep the list archives there and continue to generate the html using mhonarc . We can add functionality to that pipeline to push the archives to git and trigger a web site update (for example).
Yes, the lists.tlug.jp-scrape repo from which the Netlify test site is served is the result of scraping all the public stuff from https://lists.tlug.jp. (The script that does the work is there, too, so updates are trivial.)
It would be great to have a reliable archive of the original list messages, though of course it can't be made public. I had hoped someone would put it into the akari repo (which is private) but that never happened, so I took this scrape as just a way to ensure we have a backup of what we have on the site now. I'm happy to give you access to the akari repo if you want to send me a key, and if you could put the original ML archives in there, that would be brilliant.
I think continuing to use mhonarc to generate the archive sounds great, and having it generate into the
It would be great to have a reliable archive of the original list messages, though of course it can't be made public. I had hoped someone would put it into the akari repo (which is private) but that never happened, so I took this scrape as just a way to ensure we have a backup of what we have on the site now. I'm happy to give you access to the akari repo if you want to send me a key, and if you could put the original ML archives in there, that would be brilliant.
I think continuing to use mhonarc to generate the archive sounds great, and having it generate into the
lists.tlug.jp-scrape repo (which maybe we would want to rename) and serving that from Netlify is something I can help with.
Here goes
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDYMmJnZfmZ2hmG+uN7JbTdHzLlUu10eMK9RuZok7Z0RAEvPTYJbBR+cRQmKZ+TmCXrXMoVFQflFTVNYrCl5POimzlqapjrl//SnCuJzHSnhrClzQ2hhxjjYj5NOsA38fXl0S0sdGjpuEFGd6v1QJ0id4sEnuTBKxKg++nneAtOBpa9X4KOxSgaWFaKUPsq3KrHx2uzQ6ng10N2/WYop6JA7VG2IDPdcA7aJFMmW+ykPuQjL4atsh4A+76C3oBrei92ZUUC3aelqL0gF3xh+JjDiQRmaFiGRAGspHXwPQjxP8xmLHU+pYNZ9Ylfv3vRi4Ue+0AlqFQYyvnZ7/1F2V9F ragga@walkonen.local
@sssjjjnnn Just looking through your parser code; I think you really wanted Either instead of Maybe for handling errors. The convention is that Left is an error and Right is a value with which to continue, and the monad definition encodes this similar to Monad Maybe, by abandoning processing and letting the Left value propagate through to the end when an error occurs:
instance Monad (Either e) where
Left l >>= _ = Left l
Right r >>= k = k rI'm not sure off-hand what the exact type should be, but probably something like Either (String, ParserState) (a, ParserState), String being the error message, because the ParserState will contain the position where the error occurred and we can print that. (Probably we also want to keep line and maybe column number in the state.)
And I don't really understand how that parser works; I'm also a bit mystified by
<$. So I guess I'd better go read up on and figure that out, and maybe complete my little explicatory monadic parser. I have the feeling with yours you've got too many functions touching and extracting the state, rather than leaving that only to the lowest-level combinators.
But on the other hand, if you've got the darn thing working, we should just jam it in and get the site compiler doing transclude substitution, and make it pretty and/or comprehensible and/or whatever else later on.
Oh, and I've taken a branch from the tip of yours and prettied up the names and formatting a bit. We don't need to keep that if you don't want; it was done in part just because I learn code better when I edit it.
If we want to get fancier with reporting errors we could do something like what you're suggesting
function <$> arg1 <*> arg2 <*> arg3
That's kind of the template
You can do that with the star too
function <$ drop_this_arg <*> arg1 <*> arg2
func <$> arg1 <* drop_this_arg <*> arg2
BTW, thanks for taking care of everything while I was gone/sick. Maybe we can get together once more sometime soon
Yeah, I get
<* and *>, too, I think; those seem pretty simple. But the type signature (<$) :: a -> f b -> f a isn't obvious to me, and from what you've said here and elsewhere I think I'm missing an intuition about the relationship between Appicative and Functors. I'll go back and spend an hour on it and I'm sure it will all come clear.
No problem. Yeah, we should definitely get together soon, assuming I don't have measles. :-/ (I'm hoping this is just an alergic reaction to the MMR vaccination I had last Friday. Someone at work apparently came in with measles.)