Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Curt J. Sampson
    @0cjs
    Ah. Oh! I know what we should do: update our netlify-test site to have subdirs that do all three versions, so that we can demo it.
    I'm throwing together something right now.
    Curt J. Sampson
    @0cjs
    On what URL is netlify-test.git being served?
    Edward Middleton
    @E14n_twitter
    Curt J. Sampson
    @0cjs
    Not so easy to remember. :-) I've created a site in the TLUG Netlify account and put it on https://tlug-netlify-test.netlify.com, serving master, and documented this in the README.
    Curt J. Sampson
    @0cjs
    Ok, bug demonstrated and described in netlify-test. If you want to have a look and let me know if that all looks ok, that would be great. I'm going to report the bug.
    Curt J. Sampson
    @0cjs
    Ok, it's filed. Thanks for doing the hard work on figuring out the problem and solution!
    Curt J. Sampson
    @0cjs
    I've also just created https://github.com/tlug/lists.tlug.jp-scrape and pushed up a scrape of the current contents of https://lists.tlug.jp.
    Henri "Ragga" Servomaa
    @ragga
    Hi all.
    Curt J. Sampson
    @0cjs
    Hey, you made it here! Good to see you.
    Curt J. Sampson
    @0cjs
    So, while I have no opinion about how the mailing lists should be hosted (though I am willing to throw in a few bucks to help cover hosting charges if we decide to go with paid hosting of some sort), I am happy to help out with whatever we need to do to host the website with the list archives.
    One option (I don't know how good it is) is to simply serve the current scrape as a Netlify site, either as the "legacy" archive with another site serving an archive of messages from after that change or continuing on as the main archive with new messages being added to it. (I can help program the means to do that.)
    It would help if someone here could explain how the current archiving system is working. I know it's using MHonArc, but I don't know any more than that.
    Henri "Ragga" Servomaa
    @ragga
    Well, I think there are 3 components to the mailing lists
    1. ability to send and receive via SMTP
    2. list management: (un)subscribe, recipient list, distribution trigger etc
    3. archives
      My feeling is that we need to tackle #2 first. That will determine how to do the archiving going forward. Also, I'm strongly in favor of keeping everything under the tlug.jp domain, so I guess that means either paying for it or hosting ourselves.
    Curt J. Sampson
    @0cjs
    Yes, I agree how we do (3) will depend somewhat on how we do (2). Still, knowing how the current system works would be useful background for me.
    Curt J. Sampson
    @0cjs

    @E14n_twitter Can you have a look at my changes on dev/cjs/190512/wiki-ns-link-fix...

    1. Fix the broken links to namespaced pages....
    2. Redirect /wiki and /wiki/ to the main page, as MediaWiki does.

    Apparently nobody has any comments on this, so I've just put this change on master. You can now see it on https://new.tlug.jp.

    Henri "Ragga" Servomaa
    @ragga
    new.tlug.jp looks fine to me. I assume all the public wiki contents has been scraped as well. Some pages, like "next event", will have to be removed or handled differently, I guess.
    Curt J. Sampson
    @0cjs
    The content, public and private, has all been pulled from the server; it's wiki markup, not scrapes. (Though I think we have some content as scrapes as well.) It's in the akari.tlug.jp repo; send me a PM if you think you should have access to it.
    Very little of that content has been copied over to the tlug.jp repo.
    Oh, and it occurs to me, to help avoid confusion, that repo should be renamed to www.tlug.jp unless we're going to merge lists.tlug.jp into it (which off-hand doesn't strike me as a good idea).
    Curt J. Sampson
    @0cjs
    Anybody up for a hacking meetup this weekend? At Lodge, Co-edo, or just a Starbucks somewhere?
    Curt J. Sampson
    @0cjs
    Oh, huh! We're serving the main site on articles.tlug.jp as well, it seems!
    Henri "Ragga" Servomaa
    @ragga
    I think that's an artifact. It shouldn't be necessary to have it on that domain.
    Curt J. Sampson
    @0cjs
    It does make sense to me to drop it. Or make it like the new tlug.jp site, just always a redirect to the same URL on www.tlug.jp.
    Henri "Ragga" Servomaa
    @ragga
    I suggest we drop it.
    Curt J. Sampson
    @0cjs
    Ok.
    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.
    Henri "Ragga" Servomaa
    @ragga
    Hmm.. maybe we had an idea for "articles", but I can't remember. I don't think it makes sense, so all links can be removed, imho.
    Curt J. Sampson
    @0cjs
    Might be worthwhile to get someone with access to the DNS configuration to give us a list here of all labels being served under our domain and their associated records.
    Curt J. Sampson
    @0cjs
    BTW, we appear to be missing some directories for the MLlingo lists, such as MLlingo/0711/, MLlingo/0709/, etc. They're linked from the top index but don't exist.
    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?
    Curt J. Sampson
    @0cjs
    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.
    Henri "Ragga" Servomaa
    @ragga
    Hmm.. I don't see the search here anymore: https://lists.tlug.jp/ML/index.html
    Curt J. Sampson
    @0cjs
    It's only on tlug-admin: https://lists.tlug.jp/MLadm/index.html.
    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.
    Henri "Ragga" Servomaa
    @ragga
    I see that the search field is commented out for ML
    I assumed admin would be non-searchable.. and the common archives would be, because it's not password protected.
    Curt J. Sampson
    @0cjs
    The top page has an embedded Google search for the site, which seems to me a good way to go for anything we don't mind being in a Google index.
    Henri "Ragga" Servomaa
    @ragga
    Yeah, I think that was the original idea as well.
    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..
    Curt J. Sampson
    @0cjs
    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.
    Henri "Ragga" Servomaa
    @ragga
    True enough. There hasn't been anything sensitive on the admin-list for ages.
    Curt J. Sampson
    @0cjs
    Was there ever? If so, and it's still sensitive, possibly it should be removed from the archive.
    Henri "Ragga" Servomaa
    @ragga
    Well, I agree, but for now would err on the side of caution and keep it out.
    Henri "Ragga" Servomaa
    @ragga
    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.
    Henri "Ragga" Servomaa
    @ragga
    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).
    Curt J. Sampson
    @0cjs
    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 lists.tlug.jp-scrape repo (which maybe we would want to rename) and serving that from Netlify is something I can help with.
    Henri "Ragga" Servomaa
    @ragga
    Allright. I think I missed details about the akari repo. Where should I send my public ssh-key?
    Curt J. Sampson
    @0cjs
    Private message here is fine. Yeah, I don't think the repo was well publicised amongst all the various admins and others.
    Henri "Ragga" Servomaa
    @ragga

    Here goes

    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDYMmJnZfmZ2hmG+uN7JbTdHzLlUu10eMK9RuZok7Z0RAEvPTYJbBR+cRQmKZ+TmCXrXMoVFQflFTVNYrCl5POimzlqapjrl//SnCuJzHSnhrClzQ2hhxjjYj5NOsA38fXl0S0sdGjpuEFGd6v1QJ0id4sEnuTBKxKg++nneAtOBpa9X4KOxSgaWFaKUPsq3KrHx2uzQ6ng10N2/WYop6JA7VG2IDPdcA7aJFMmW+ykPuQjL4atsh4A+76C3oBrei92ZUUC3aelqL0gF3xh+JjDiQRmaFiGRAGspHXwPQjxP8xmLHU+pYNZ9Ylfv3vRi4Ue+0AlqFQYyvnZ7/1F2V9F ragga@walkonen.local

    Curt J. Sampson
    @0cjs

    @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 r

    I'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.)