List for cgit developers and users
 help / color / mirror / Atom feed
From: andy at (Andy Green)
Subject: [PATCH] native inline gravatar
Date: Wed, 4 Jul 2018 08:44:18 +0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 07/04/2018 08:34 AM, Jason A. Donenfeld wrote:
> On Wed, Jul 4, 2018 at 2:28 AM Andy Green <andy at> 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.


  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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \

* 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).