zx2c4@thinkpad ~/Projects/cgit/filters $ cat email-gravatar.lua
-- This script may be used with the email-filter or repo.email-filter
settings in cgitrc.
-- It adds gravatar icons to author names. It is designed to be used
with the lua:
-- prefix in filters. It is much faster than the corresponding
This commit filter works for reversing commit messages:
buffer = ""
function filter_open()
buffer = ""
end
function filter_close()
html(string.reverse(buffer))
end
function filter_write(str)
buffer = buffer .. str
end
___
CGit
Initial version committed to jd-jk/filter-infra!
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Welp, I've gotten to work implementing it myself. Will post status soon.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
On Fri, Jan 10, 2014 at 6:20 PM, John Keeping wrote:
> I would have no problem including LuaJIT for this sort of thing.
> I might have a look at the Lua case over the weekend if no one beats me
> to it.
John, Florian --
The infrastructure should be just about complete now, if either of you
want
On Fri, Jan 10, 2014 at 9:56 PM, Florian Pritz wrote:
> Last but not least, it keeps the interface between "exec" and "lua"
> filters the same or at least rather similar. If you can call a lua
> script as if it was execed (setting argv) that would make the handler
> totally transparent, but faster
On Fri, Jan 10, 2014 at 9:03 PM, Florian Pritz wrote:
> How about using the current fork approach but instead of calling execvp
> use lua. I believe forks are pretty cheap on linux, it's the exec that's
> costly.
>
> If we do it like that we could reuse stdin/stdout, we could pass
> arguments via
On 10.01.2014 21:36, John Keeping wrote:
>> Looks rather easy to slurp stdin (from http://www.lua.org/pil/21.1.html):
>
> Interesting. But I think it will be simpler from both side if the
> interface is just a function call
source_filter could potentially get a rather long input and might not
ne
On Fri, Jan 10, 2014 at 09:25:18PM +0100, Florian Pritz wrote:
> On 10.01.2014 21:11, John Keeping wrote:
> > Forking and using Lua in the child is an interesting idea.
> >
> > I need to investigate how Lua generally deals with I/O, but it feels
> > like it will be simpler to use a simple function
On 10.01.2014 21:11, John Keeping wrote:
> Forking and using Lua in the child is an interesting idea.
>
> I need to investigate how Lua generally deals with I/O, but it feels
> like it will be simpler to use a simple function interface than deal
> with slurping in the input in Lua.
Looks rather e
On Fri, Jan 10, 2014 at 09:03:24PM +0100, Florian Pritz wrote:
> On 10.01.2014 18:57, Jason A. Donenfeld wrote:
> > On Fri, Jan 10, 2014 at 6:12 PM, Florian Pritz wrote:
> >>
> >> Isn't this (fast scripting with lots of features) when people normally
> >> start using lua?
> >>
> >
> > This would
On 10.01.2014 18:57, Jason A. Donenfeld wrote:
> On Fri, Jan 10, 2014 at 6:12 PM, Florian Pritz wrote:
>>
>> Isn't this (fast scripting with lots of features) when people normally
>> start using lua?
>>
>
> This would have the same challenges as using .so files, w.r.t. hooking
> write() (or the h
On Fri, Jan 10, 2014 at 6:43 PM, Konstantin Ryabitsev wrote:
> As an administrator, I would be very reluctant from having to use this
> mechanism. Administrators generally hate daemons. :)
Ditto.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.z
On Fri, Jan 10, 2014 at 6:20 PM, John Keeping wrote:
>
> I was also wondering if supporting "unix:/path/to/socket" would be
> useful, then the filter would connect on a Unix socket, run and
> disconnect, on the assumption that the administrator has a daemon
> running to do the filtering.
This has
On Fri, Jan 10, 2014 at 6:12 PM, Florian Pritz wrote:
>
> Isn't this (fast scripting with lots of features) when people normally
> start using lua?
>
This would have the same challenges as using .so files, w.r.t. hooking
write() (or the html functions), but would be very interesting indeed,
becau
On 10/01/14 12:20 PM, John Keeping wrote:
> I was also wondering if supporting "unix:/path/to/socket" would be
> useful, then the filter would connect on a Unix socket, run and
> disconnect, on the assumption that the administrator has a daemon
> running to do the filtering.
As an administrator, I
On Fri, Jan 10, 2014 at 06:12:25PM +0100, Florian Pritz wrote:
> On 10.01.2014 16:57, Jason A. Donenfeld wrote:
> > On Fri, Jan 10, 2014 at 10:06 AM, John Keeping wrote:
> >>
> >> This seems drastically over complicated.
> >
> > So here's the situation. There's a lot of "state" that we're taking
On 10.01.2014 16:57, Jason A. Donenfeld wrote:
> On Fri, Jan 10, 2014 at 10:06 AM, John Keeping wrote:
>>
>> This seems drastically over complicated.
>
> So here's the situation. There's a lot of "state" that we're taking
> advantage of in using processes that terminate, that needs to be
> replic
On Fri, Jan 10, 2014 at 10:06 AM, John Keeping wrote:
>
> This seems drastically over complicated.
So here's the situation. There's a lot of "state" that we're taking
advantage of in using processes that terminate, that needs to be
replicated:
*a* Sending arguments to the program, and distingu
On Fri, Jan 10, 2014 at 03:11:54AM +0100, Jason A. Donenfeld wrote:
> On Fri, Jan 10, 2014 at 2:41 AM, Jason A. Donenfeld wrote:
> > and does its thing per usual. At the end, however, it does not exit.
> > Instead of waitpid()ing on it in close filter, we SIGSTOP it, put the
> > fds back in place,
On Fri, Jan 10, 2014 at 3:11 AM, Jason A. Donenfeld wrote:
> Problems abound. This has race condition issues, where the parent
> process will SIGSTOP the child before the child can write its output.
> This could be fixed with a more complicated signaling protocol, but
> that's more complex than I'
On Fri, Jan 10, 2014 at 2:41 AM, Jason A. Donenfeld wrote:
> and does its thing per usual. At the end, however, it does not exit.
> Instead of waitpid()ing on it in close filter, we SIGSTOP it, put the
> fds back in place, etc. Then the next time that filter is called, we
> SIGCONT it, it reads th
On Thu, Jan 9, 2014 at 11:58 PM, John Keeping wrote:
>
> That interface doesn't really match the way the current filters work.
Yes, hence the post.
> We could swap out write with a function pointer
> into the filter, but I don't think we guarantee that all of the data is
> written in one go whi
On Thu, Jan 09, 2014 at 10:34:26PM +0100, Jason A. Donenfeld wrote:
> I'm thinking about this filtering situation w.r.t. gravatar and
> potentially running multiple filters on one page. Something I've been
> considering is implementing a simple dlopen() mechanism for filters,
> if the filter filena
On 09/01/14 22:34, Jason A. Donenfeld wrote:
Hey folks,
I'm thinking about this filtering situation w.r.t. gravatar and
potentially running multiple filters on one page. Something I've been
considering is implementing a simple dlopen() mechanism for filters,
if the filter filename starts with
Hey folks,
I'm thinking about this filtering situation w.r.t. gravatar and
potentially running multiple filters on one page. Something I've been
considering is implementing a simple dlopen() mechanism for filters,
if the filter filename starts with "soname:" or "lib:" or similar, so
as to avoid th
26 matches
Mail list logo
