From: andy at warmcat.com (Andy Green)
Subject: [PATCH] native inline gravatar
Date: Wed, 4 Jul 2018 08:44:18 +0800 [thread overview]
Message-ID: <569ca21d-c5f7-a273-d5eb-f5fed50f5f0a@warmcat.com> (raw)
In-Reply-To: <CAHmME9ohf=m0FGUpm0Pvo_-toyd+2b=o4rPaGn+y01GpsuHvaA@mail.gmail.com>
On 07/04/2018 08:34 AM, Jason A. Donenfeld wrote:
> On Wed, Jul 4, 2018 at 2:28 AM Andy Green <andy at warmcat.com> wrote:
>> I looked at it, but there's no md5 api in JS... you have to do it by
>> hand in JS. It's possible but I think it might be slow if it hits a
>> page of 50 different email addresses.
>
> MD5 is really fast and fits easily into javascript's integer types.
> There should be reasonably fast implementations available.
> Alternatively, you could generate asm.js and web assembly code using
> something like emscripten.
>
>> Is it supported to do the job of pygments in Lua?
>
> You can do any type of text processing you want from Lua. If you'd
> like to contribute a Lua highlighter, that'd be quite nice.
>
>> What it does today is spawn the python runtime, start that up etc.
>
> Have you measured latency issues with this?
Nope, but it's obviously more efficient to not be spawning python apps.
Don't you think?
>> I know... bandwidth and server compute time.
>>
>> Also there's no reason (other than not enough care taken with frees atm)
>> cgit should only be buildable as a cgi starting up its own process each
>> time.
>
> You're talking about FastCGI support? I have no idea how this is
> related to the current line of discussion -- perhaps just by being
> another gripe or something -- but this is actually something we've
What was the first gripe? I am providing patches for all these things
not moaning about them.
I mention it because starting up cgit as a process each time is also
overhead, I think it would be interesting also to look at eliminating that.
> looked at in depth. (See the list archives.) Our last conclusion from
> examining it was that so much of libgit is not re-entrant, and so we'd
> need to move to something like libgit2 for this to be feasible. Too
> many globals, etc.
Let me guess, not enough people around working on this project, for some
reason, to move to libgit2.
>> It could optionally link against OpenSSL then :-) It can optionally
>> link against lua.
>>
>> If you're not interested in going where this stuff is going, you can
>> save us both a lot of time by just saying it now, and I'll stop trying
>> to sell it here.
>
> I made that clear in my very first message to you:
>
> "Sorry, but not a chance something like this can be accepted."
If that's your feeling about the whole stack of clientside stuff, I
understand you don't want to cooperate on it.
No worries I'll leave you to it then.
-Andy
next prev parent reply other threads:[~2018-07-04 0:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-01 3:20 andy
2018-07-03 23:49 ` Jason
2018-07-04 0:00 ` andy
2018-07-04 0:14 ` Jason
2018-07-04 0:28 ` andy
2018-07-04 0:34 ` Jason
2018-07-04 0:44 ` andy [this message]
2018-07-04 1:05 ` Jason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=569ca21d-c5f7-a273-d5eb-f5fed50f5f0a@warmcat.com \
--to=cgit@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).