On Monday, January 13, 2014, Jason A. Donenfeld wrote:
> On Tue, Jan 14, 2014 at 3:37 AM, Andrew Starks
> >
> wrote:
> >
> > I don't have LuaJit installed and would not install it (and migrate
> > everything I do over to it) just to use a library. By way of example,
> your
> > library may as well
On Monday, January 13, 2014, Jason A. Donenfeld wrote:
> On Tue, Jan 14, 2014 at 3:37 AM, Andrew Starks
> >
> wrote:
> >
> > I don't have LuaJit installed and would not install it (and migrate
> > everything I do over to it) just to use a library. By way of example,
> your
> > library may as well
On Tue, Jan 14, 2014 at 3:37 AM, Andrew Starks wrote:
>
> I don't have LuaJit installed and would not install it (and migrate
> everything I do over to it) just to use a library. By way of example, your
> library may as well have been written for Python, for as much good as it
> would be to me.
>
On Tue, Jan 14, 2014 at 3:34 AM, William Ahern
wrote:
> The 2GB memory limit on 64-bit was a huge blocker at my work. We almost
> immeditely ran afoul of it and have chosen to stabilize on Lua 5.2 for one
> of our cloud services. (On 16-way SMP, 32GB RAM boxes it's more important to
> be able to s
On Monday, January 13, 2014, Jason A. Donenfeld wrote:
> On Tue, Jan 14, 2014 at 3:12 AM, Tim Hill >
> wrote:
> > LuaJIT is currently compatible with Lua 5.1, not 5.2 or the upcoming
> 5.3, and my understanding is the LuaJIT project has now forked from
> mainstream Lua and will not be staying in s
On Tue, Jan 14, 2014 at 3:12 AM, Tim Hill wrote:
> LuaJIT is currently compatible with Lua 5.1, not 5.2 or the upcoming 5.3, and
> my understanding is the LuaJIT project has now forked from mainstream Lua and
> will not be staying in sync with anything past 5.1, so I would expect over
> time th
On Tue, Jan 14, 2014 at 3:10 AM, demetri wrote:
> 1) PUC Lua works on more machines/architectures (though Mike has
> substantially closed the gap for most architectures people care about in a
> non-embedded non-mobile environment)
Do you know what the gap is?
LuaJIT supports x86, x86_x64, arm, p
Personally, I think the trac colors are a bit ugly. I like pastie
best. But this is just preference.
Here's a comparison site:
http://blog.favrik.com/2011/02/22/preview-all-pygments-styles-for-your-code-highlighting-needs/
If folks want to take some kind of vote, I'll go with majority opinion.
p
Merged, thanks.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
Hi folks,
Over at the cgit project [1], we're in the process of adding Lua
support. Things are going swimmingly, and I've just merged to the
master tree some commits adding full lua support [2] to our filter API
[3] and an example script [4]. At the moment we've got some moderately
messy logic in
I've gone ahead and merged the lua work to master, for testing and
subsequent cleanup before release.
Regarding "to jit or not to jit", I currently have this fancy autodetection
logic:
http://git.zx2c4.com/cgit/commit/?id=3488d124052f5c3ddef303ed5306ad6a458794c1
John -- I'm waiting for your input
Mention that the snapshot setting only specifies the formats that links
are generated for and not the set of formats that are accessible via
HTTP.
Signed-off-by: Lukas Fleischer
---
cgitrc.5.txt | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/cgitrc.5.txt b/cgit
Am 13.01.2014 23:16, schrieb Jason A. Donenfeld:
> On Mon, Jan 13, 2014 at 11:13 PM, Stefan Tatschner
> wrote:
>> Why did you apply my patch with tabs instead of spaces? I was wondering
>> because I adjusted the python script according to pep8 [1] and I'm sure
>> the patchfile was with spaces. Ma
On Mon, Jan 13, 2014 at 11:13 PM, Stefan Tatschner wrote:
> Why did you apply my patch with tabs instead of spaces? I was wondering
> because I adjusted the python script according to pep8 [1] and I'm sure
> the patchfile was with spaces. Maybe you have an automatic convert script?
I like tabs. T
Am 13.01.2014 22:50, schrieb Jason A. Donenfeld:
> Perfect! Applied. Thanks for going through all the revisions.
thanks as well. :)
I have one simple question (just out of curiosity; I do not want to bash
anybody).
Why did you apply my patch with tabs instead of spaces? I was wondering
because I
Perfect! Applied. Thanks for going through all the revisions.
___
CGit mailing list
CGit@lists.zx2c4.com
http://lists.zx2c4.com/mailman/listinfo/cgit
- Switched back to python2 according to a problem in pygments with python3.
With the next release of pygments this problem should be fixed.
Issue see here:
https://bitbucket.org/birkenfeld/pygments-main/issue/901/problems-with-python3
- Just read the stdin, decode it to utf-8 and ignore unkno
Using trac theme for pygments. It is very clean and not as
intrusive as the default or pastie theme. Especially I do
not like the the 'pastie' theme very much because of the
very strange illustration of multiline strings (the red
background thing).
Signed-off-by: Stefan Tatschner
---
filters/syn
Hi,
What reasons do we have for supporting lua at all? Why not just go
with luajit? It's faster and just as widely supported. The motivation
for not supporting vanilla lua is this luajit library:
http://luajit.org/ext_ffi.html . This would be a nice way of being
able to ship scripts without a big
Am 13.01.2014 15:50, schrieb Jason A. Donenfeld:
> On Mon, Jan 13, 2014 at 3:47 PM, Stefan Tatschner
> wrote:
>> No, that's not the issue. By default 'pygments' adds a > style="line-height: 125%"> tag so I had to change the line-height of the
>> other column as well.
>
> Strange. It doesn't do t
On Mon, Jan 13, 2014 at 3:47 PM, Stefan Tatschner wrote:
> No, that's not the issue. By default 'pygments' adds a style="line-height: 125%"> tag so I had to change the line-height of the
> other column as well.
Strange. It doesn't do that on the current script. Is this because of
the inline styl
Am 13.01.2014 15:21, schrieb Jason A. Donenfeld:
> On Mon, Jan 13, 2014 at 12:02 PM, Stefan Tatschner
> wrote:
>> - Using inline CSS instead of this sys.stdout.print() hack.
>
> Please don't do this. Inline CSS makes for much bigger files, and
> there's nothing in the HTML5 spec that forbids us
On Mon, Jan 13, 2014 at 3:18 PM, Christian Hesse wrote:
> Your avatar (and mine as well) are fine when scaled down. But if there is no
> avatar on gravatar you get the "arcade-style pixelated faces", which look
> very fuzzy when scaled by the browser...
Good point. Excuse me while I make a trivia
Thanks for all your hard work on this. Sorry for the extended back and
forth. More comments, alas alas, below.
On Mon, Jan 13, 2014 at 12:02 PM, Stefan Tatschner wrote:
> - Using inline CSS instead of this sys.stdout.print() hack.
Please don't do this. Inline CSS makes for much bigger files, and
"Jason A. Donenfeld" on Thu, 2014/01/09 16:19:
> On Thu, Jan 9, 2014 at 10:18 AM, Christian Hesse wrote:
> > You modified the code to make the icon match the font size, which is 10pt
> > by default. This is hard coded to the css file. Please note the URL
> > includes a size argument. Does it make
Signed-off-by: Jason A. Donenfeld
---
cgit.mk | 22 ++-
cgitrc.5.txt | 29 ++
filter.c | 186 +++
3 files changed, 234 insertions(+), 3 deletions(-)
diff --git a/cgit.mk b/cgit.mk
index 9d6dea8..25f2eab 100644
--- a/c
From: John Keeping
Change the existing cgit_{open,close,fprintf}_filter functions to
delegate to filter-specific implementations accessed via function
pointers on the cgit_filter object.
We treat the "exec" filter type slightly specially here by putting its
structure definition in the header fil
Signed-off-by: Jason A. Donenfeld
---
cgit.c | 6 ++
cgit.h | 4 +++-
cgitrc.5.txt | 18 ++
filter.c | 3 +++
shared.c | 1 +
ui-commit.c | 4
ui-log.c | 2 ++
ui-refs.c| 9 -
ui-tag.c | 2 ++
9 files changed, 47 insertions
So that we don't have to include the if(filter) open_filter(filter)
block everywhere, we introduce the guard in the function itself. This
should simplify quite a bit of code.
Signed-off-by: Jason A. Donenfeld
---
filter.c | 4
ui-commit.c | 18 ++
ui-repolist.c | 6
From: John Keeping
This allows different filter implementations to be specified in the
configuration file. Currently only "exec" is supported, but it may now
be specified either with or without the "exec:" prefix.
Signed-off-by: John Keeping
---
cgitrc.5.txt | 9 +
filter.c | 33
The lua one is hugely faster than the python one, but both are included
for comparison.
Signed-off-by: Jason A. Donenfeld
---
filters/email-gravatar.lua | 25 +
filters/email-gravatar.py | 33 +
2 files changed, 58 insertions(+)
create mo
Filters can now call hook_write and unhook_write if they want to
redirect writing to stdout to a different function. This saves us from
potential file descriptor pipes and other less efficient mechanisms.
We do this instead of replacing the call in html_raw because some places
stdlib's printf func
At some point, we're going to want to do lazy deallocation of filters.
For example, if we implement lua, we'll want to load the lua runtime
once for each filter, even if that filter is called many times.
Similarly, for persistent exec filters, we'll want to load it once,
despite many open_filter an
In this second installment I've squashed things down and cleanly separated
the framework commits from the lua commits. It should be much easier to
comprehend.
The weakest part is still the Makefile changes, which might not be very
portable and could probably be more configurable somehow. If anybod
From: John Keeping
This stops the code in cgit.c::print_repo needing to inspect the
cgit_filter structure, meaning that we can abstract out different filter
types that will have different fields that need to be printed.
Signed-off-by: John Keeping
---
cgit.c | 6 +++---
cgit.h | 1 +
filte
- Switched back to python2 according to a problem in pygments with python3.
With the next release of pygments this problem should be fixed.
Issue see here:
https://bitbucket.org/birkenfeld/pygments-main/issue/901/problems-with-python3
- Just read the stdin, decode it to utf-8 and ignore unkno
On 13.01.2014 05:11, Jason A. Donenfeld wrote:
> Signed-off-by: Jason A. Donenfeld
> ---
> cgit.h | 2 +-
> cgit.mk | 13 ++-
> filter.c | 284
> ---
All those *_lua_filter functions look rather self contained, maybe they
should b
On Mon, Jan 13, 2014 at 05:11:13AM +0100, Jason A. Donenfeld wrote:
[snip]
> +static int html_lua_filter(lua_State *lua_state)
> +{
> + size_t len;
> + const char *str;
> +
> + str = lua_tostring(lua_state, 1);
> + if (!str)
> + return 0;
> + len = strlen(str);
> +
On Mon, Jan 13, 2014 at 09:31:39AM +0100, Lukas Fleischer wrote:
> This patch is quite messy and hard to read. I read your cover-letter but
> maybe you still want to clean this up when dealing with the other
> suggestions during a rebase -- shouldn't be too hard when using an
> editor with good Git
On Mon, 13 Jan 2014 at 05:11:13, Jason A. Donenfeld wrote:
> Signed-off-by: Jason A. Donenfeld
> ---
> cgit.h | 2 +-
> cgit.mk | 13 ++-
> filter.c | 284
> ---
> 3 files changed, 230 insertions(+), 69 deletions(-)
>
> [...]
> +
This patch is quite messy and hard to read. I read your cover-letter but
maybe you still want to clean this up when dealing with the other
suggestions during a rebase -- shouldn't be too hard when using an
editor with good Git integration (like fugitive for Vim).
On Mon, 13 Jan 2014 at 05:11:13, J
On Mon, 13 Jan 2014 at 05:11:12, Jason A. Donenfeld wrote:
> Filters can now call hook_write and unhook_write if they want to
> redirect writing to stdout to a different function. This saves us from
> potential file descriptor pipes and other less efficient mechanisms.
>
> We do this instead of re
42 matches
Mail list logo
