smug-devel Mailing List for Smug - smugly superior to wikis
Status: Alpha
Brought to you by:
amcnabb
Menu
▾
▴
smug-devel — Smug Development
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
(19) |
Mar
(3) |
Apr
(4) |
May
(2) |
Jun
(10) |
Jul
|
Aug
|
Sep
(22) |
Oct
(58) |
Nov
(2) |
Dec
(1) |
|---|
|
From: Andrew M. <amc...@mc...> - 2008-12-15 22:24:49
|
So, I just started using the ReST filter (yeah, I'm a slacker). It turns out that there were two or three little bugs in the latest version that would give server errors, etc. This is fixed now. More importantly, I switched from using the "body" part to using "html_body" in the rst2html filter. The primary effect is that the title gets put as an <h1 class="title"> at the top of the page. Let me know if you think this was a bad idea (for my page, it definitely works better). Thanks. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Andrew M. <amc...@mc...> - 2008-11-10 14:53:24
|
On Fri, Nov 07, 2008 at 10:07:58PM -0800, Jonathan Wilson wrote: > > http://docs.djangoproject.com/en/dev/ref/contrib/csrf/ > > anyway, I think it'd be good to add to the install doc you have on your > site andrew (and for all the rest of you as well). pretty cool ware That seems like a good idea. I don't see any drawbacks to installing it, and csrf can be a serious problem. Jon, if you would like, feel free to change the docs and either post a patch or a link to a repo with the changes. (all of the docs are in the Smug Git repo) -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Jonathan W. <wi...@er...> - 2008-11-08 06:24:17
|
Hey, while playing with some custom django middleware, I came across this: http://docs.djangoproject.com/en/dev/ref/contrib/csrf/ (it was once custom middleware) - it was added in the pre 1.0 stuff. anyway, I think it'd be good to add to the install doc you have on your site andrew (and for all the rest of you as well). pretty cool ware -- Jonathan Wilson |
|
From: Jeff A. <jef...@pr...> - 2008-10-21 16:14:53
|
Andrew McNabb wrote: > > Describe a bit more what the RSS feed will actually do. Will there be > one RSS entry for each commit, or one entry for each file changed, or > something completely different? What information will go in the feed? > What I have in mind is one diff per commit-- much like git log -p I don't see much benefit in trying to split a particular commit into 2 or 3 entries if 2 or 3 files have been changed. If smug is being used as the frontend to a particular git repository, there will only be one commit per file anyway. Jeff Anderson |
|
From: Andrew M. <amc...@mc...> - 2008-10-21 13:50:17
|
On Mon, Oct 20, 2008 at 02:24:00PM -0600, Jeff Anderson wrote: > > I do see what you mean about there being a difference between diffing a > single file, and diffing a tree. Would it be wrong to implement what the > anonymous patch generation in gitlib? I'm not sure how the git diff > command generates diffs against a working directory, but my guess is > that it more or less creates blob objects, and uses the same diffing > function as it does when diffing between two different git trees > (commits). Maybe that's the "right" way to do things for anonymous > commits? or would it be too complicated? When Git does a diff with the working tree, it's actually much more complicated. They use all sorts of heuristics to determine whether a file has changed without actually looking at the file. I think it would be perfectly reasonable to create a Blob object in the anonymous edit view and diff it with another Blob. > Yeah, the issue never was dropping to a git subcommand. I was more > curious about the code in the anonymous commit view that calls the > python unified diff library-- since that code is in the views, I didn't > want to implement much of the same in a different view. I thought that a > better solution might be to implement diffing in gitlib itself, rather > than in a view. Describe a bit more what the RSS feed will actually do. Will there be one RSS entry for each commit, or one entry for each file changed, or something completely different? What information will go in the feed? -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Jeff A. <jef...@pr...> - 2008-10-20 20:24:47
|
Andrew McNabb wrote: > That being said, what you're talking about is slightly different than > doing a diff on two pieces of content. It sounds like you're talking > about finding all of the differences between two trees, which does seem > like a good thing for gitlib. Maybe the best thing to do would be to > add a difftrees method to Repository and a diff method to Blob. Blob's > diff could compare with another Blob, and Repository's could do a > treewalk and do a diff on each Blob. > I do see what you mean about there being a difference between diffing a single file, and diffing a tree. Would it be wrong to implement what the anonymous patch generation in gitlib? I'm not sure how the git diff command generates diffs against a working directory, but my guess is that it more or less creates blob objects, and uses the same diffing function as it does when diffing between two different git trees (commits). Maybe that's the "right" way to do things for anonymous commits? or would it be too complicated? >> Making diffs seems like a reasonable enough thing to go into gitlib-- >> just thought I'd ask before duplicating or refactoring. >> > > To sum up, I think it would be a good thing to have in Gitlib but that > it should use Python's diff module rather than a Git subcommand. > Yeah, the issue never was dropping to a git subcommand. I was more curious about the code in the anonymous commit view that calls the python unified diff library-- since that code is in the views, I didn't want to implement much of the same in a different view. I thought that a better solution might be to implement diffing in gitlib itself, rather than in a view. Jeff Anderson |
|
From: Andrew M. <amc...@mc...> - 2008-10-20 14:19:18
|
On Sat, Oct 18, 2008 at 07:41:47PM -0600, Jeff Anderson wrote: > So I was trying to figure out the best way to implement the diffs needed > for the RSS feeds, and it looks like the anonymous commit code generates > a patch with the unified diff python module. > > Should I implement the same thing in an RSS view, or should I move that > code into gitlib? The diff module is built into Python, which means that we're reusing code that's available everywhere. With gitlib, I've generally preferred Python implementations to running a git binary since the overhead of a fork-and-exec is pretty heavy and since Python code is much more flexible. That being said, what you're talking about is slightly different than doing a diff on two pieces of content. It sounds like you're talking about finding all of the differences between two trees, which does seem like a good thing for gitlib. Maybe the best thing to do would be to add a difftrees method to Repository and a diff method to Blob. Blob's diff could compare with another Blob, and Repository's could do a treewalk and do a diff on each Blob. > Making diffs seems like a reasonable enough thing to go into gitlib-- > just thought I'd ask before duplicating or refactoring. To sum up, I think it would be a good thing to have in Gitlib but that it should use Python's diff module rather than a Git subcommand. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Jeff A. <jef...@pr...> - 2008-10-19 01:53:40
|
So I was trying to figure out the best way to implement the diffs needed for the RSS feeds, and it looks like the anonymous commit code generates a patch with the unified diff python module. Should I implement the same thing in an RSS view, or should I move that code into gitlib? Making diffs seems like a reasonable enough thing to go into gitlib-- just thought I'd ask before duplicating or refactoring. Jeff Anderson |
|
From: Andrew M. <amc...@mc...> - 2008-10-16 22:56:09
|
On Thu, Oct 16, 2008 at 02:26:51PM -0600, Jeff Anderson wrote: > > What do you mean by basic rendering? > > > Headings, bold, italic, etc... > I figure we'll probably use an external library for this (like how the > ReST/docutils stuff is) > I'm just not so sure as to what extent the syntax has been implemented. > There are also other non-basic rendering aspects of mediawiki markup > like embedding html and other stuff. I get it now. I didn't realize that basic rendering was referring to Mediawiki. That makes sense now. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Jeff A. <jef...@pr...> - 2008-10-16 20:27:13
|
Andrew McNabb wrote: > Good ideas. > > On Thu, Oct 16, 2008 at 08:49:12AM -0600, Jeff Anderson wrote: > >>> >>> >> I'd add "more filters" to this list. >> I already have a ton of filters I'd like to add. >> This includes a mediawiki markup filter/app. I don't think it'd be >> terribly difficult to implement, and I'm planning on working on it >> anyway. I don't necessarily think that we need to support every last >> feature or extension out there, but at least core features like basic >> rendering, categories, talk pages, and maybe math mode. >> > > What do you mean by basic rendering? > Headings, bold, italic, etc... I figure we'll probably use an external library for this (like how the ReST/docutils stuff is) I'm just not so sure as to what extent the syntax has been implemented. There are also other non-basic rendering aspects of mediawiki markup like embedding html and other stuff. |
|
From: Andrew M. <amc...@mc...> - 2008-10-16 18:45:36
|
Good ideas. On Thu, Oct 16, 2008 at 08:49:12AM -0600, Jeff Anderson wrote: > > > I'd add "more filters" to this list. > I already have a ton of filters I'd like to add. > This includes a mediawiki markup filter/app. I don't think it'd be > terribly difficult to implement, and I'm planning on working on it > anyway. I don't necessarily think that we need to support every last > feature or extension out there, but at least core features like basic > rendering, categories, talk pages, and maybe math mode. What do you mean by basic rendering? > Another thing that'd be nice is to add a test suite. Maybe 1.1? That would definitely be nice to have. By the way, gitlib already has a decent amount of tests included. It would be nice to expand this, but it's a start. The rest of Smug is definitely lacking in this area. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Jeff A. <jef...@pr...> - 2008-10-16 14:49:22
|
Andrew McNabb wrote: > On Mon, Oct 13, 2008 at 05:46:40PM -0600, Andrew McNabb wrote: > >> I have a discussion question for everyone. What features would you >> consider critical for a 1.0 release? How about an 0.9 release? >> > > So, here's my attempt to answer the question. > > > 0.9 Features > ------------ > > - anonymous commits, and a page for merging anonymous commits > > - an "add a page" feature (with both anonymous and authenticated modes) > > - chained filters > I think that the sample smug repos could go in 0.9. > > 1.0 Features > ------------ > > - better error messages > > - commit messages using username and email address from Django user > > - math mode in ReST > > - viewing history of a page > > - conflict resolution (e.g., split screen like vimdiff) > I'd add "more filters" to this list. I already have a ton of filters I'd like to add. This includes a mediawiki markup filter/app. I don't think it'd be terribly difficult to implement, and I'm planning on working on it anyway. I don't necessarily think that we need to support every last feature or extension out there, but at least core features like basic rendering, categories, talk pages, and maybe math mode. Another thing that'd be nice is to add a test suite. Maybe 1.1? Jeff Anderson |
|
From: Jeff A. <jef...@pr...> - 2008-10-16 14:38:48
|
Andrew McNabb wrote: > Is there a defacto standard filename extension for ReST files? I know > I've seen .rst, .rest, and .txt, but I was curious if people have > standardized on any particular one. > I read something about that some time ago. I have no idea where it is though. ReST files are supposed to be as close to readable plain-text files as possible. The .txt extension is therefore what it is supposed to be. Like any old text file, it really doesn't matter what the extension is (think .conf for config files), hence the .rst extension. The docutils docs have a .txt extension, but I always use a .rst extension to help differentiate between a truly plain text file. Basically there is no standard-- use whatever you want and works for you. Jeff Anderson |
|
From: Andrew M. <amc...@mc...> - 2008-10-15 23:24:15
|
Is there a defacto standard filename extension for ReST files? I know I've seen .rst, .rest, and .txt, but I was curious if people have standardized on any particular one. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Andrew M. <amc...@mc...> - 2008-10-15 23:17:30
|
On Mon, Oct 13, 2008 at 05:46:40PM -0600, Andrew McNabb wrote: > I have a discussion question for everyone. What features would you > consider critical for a 1.0 release? How about an 0.9 release? I'm surprised I haven't gotten any responses on this yet. It's an easy question--you can share an opinion without committing to do anything. :) -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Andrew M. <amc...@mc...> - 2008-10-15 23:15:38
|
I made a change to the way that the smug menu works, now making it
easier to customize how the menu appears in the template. Here's what
the relevant part of my template now looks like:
<div class="smugmenu">
<ul>
{% for name, url in smugmenu %}
<li><a href="{{ url }}">{{ name }}</a></li>
{% endfor %}
</ul>
<div class="r"> Powered by <a
href="http://www.mcnabbs.org/andrew/smug/">Smug</a> </div>
</div>
--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
|
|
From: Andrew M. <amc...@mc...> - 2008-10-14 14:05:03
|
On Mon, Oct 13, 2008 at 05:46:40PM -0600, Andrew McNabb wrote: > I have a discussion question for everyone. What features would you > consider critical for a 1.0 release? How about an 0.9 release? So, here's my attempt to answer the question. 0.9 Features ------------ - anonymous commits, and a page for merging anonymous commits - an "add a page" feature (with both anonymous and authenticated modes) - chained filters 1.0 Features ------------ - better error messages - commit messages using username and email address from Django user - math mode in ReST - viewing history of a page - sample Smug repositories - conflict resolution (e.g., split screen like vimdiff) -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Andrew M. <amc...@mc...> - 2008-10-13 23:46:49
|
I have a discussion question for everyone. What features would you consider critical for a 1.0 release? How about an 0.9 release? -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Andrew M. <amc...@mc...> - 2008-10-13 23:35:14
|
On Mon, Oct 13, 2008 at 11:49:02AM -0600, Jeff Anderson wrote: > > I have a ReST file that has a fatal error in it. It returns a 500. > That's fine and expected, but it also returns a 500 error when I go to > :edit it. > > Why do we have it running the filter for a :edit? To make your life miserable, of course. :) This should be fixed now. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Andrew M. <amc...@mc...> - 2008-10-13 18:55:28
|
On Mon, Oct 13, 2008 at 11:49:02AM -0600, Jeff Anderson wrote: > So I'm doing some smug testing after Andrew's most recent bug fixes. > > I have a ReST file that has a fatal error in it. It returns a 500. > That's fine and expected, but it also returns a 500 error when I go to > :edit it. > > Why do we have it running the filter for a :edit? > > It seems a little counter-intuitive to possibly cause this error via an > edit and not be able to fix it. :) > > I'll look into it later when I have a bit more time-- I haven't looked > at the code at all at this point. I just wanted to share my bug report. :) Interesting. That's definitely a bug, so I'll have to look into it (just not today). -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Jeff A. <jef...@pr...> - 2008-10-13 17:49:13
|
So I'm doing some smug testing after Andrew's most recent bug fixes. I have a ReST file that has a fatal error in it. It returns a 500. That's fine and expected, but it also returns a 500 error when I go to :edit it. Why do we have it running the filter for a :edit? It seems a little counter-intuitive to possibly cause this error via an edit and not be able to fix it. :) I'll look into it later when I have a bit more time-- I haven't looked at the code at all at this point. I just wanted to share my bug report. :) Jeff Anderson |
|
From: Andrew M. <amc...@mc...> - 2008-10-13 14:48:00
|
On Mon, Oct 13, 2008 at 08:25:15AM -0600, Andrew McNabb wrote: > > Okay. I've pushed a fix for the kwds problem with login/logout. It > would be nicer if this were fixed upstream, but this works for now. I've fixed it for real now by adding back the custom login.py and logout.py. It turns out that Django's auth.login doesn't add any variables to the template, so the template wasn't getting the `basepath` variable. I'm not sure why I wasn't seeing the problem until now, but it's fixed now. Using the generic login form was a nice attempt, but it's looking more and more like it wasn't the right way to go. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Andrew M. <amc...@mc...> - 2008-10-13 14:24:31
|
On Fri, Oct 10, 2008 at 05:37:30PM -0600, Andrew McNabb wrote: > > Hmm. It's pretty annoying that the generic login view is so picky. Is > there any chance that the upstream login view could be changed to ignore > unrecognized keyword args? That would really make our life easier, and > it seems like the right thing to do. Okay. I've pushed a fix for the kwds problem with login/logout. It would be nicer if this were fixed upstream, but this works for now. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Andrew M. <amc...@mc...> - 2008-10-10 23:36:42
|
On Fri, Oct 10, 2008 at 05:14:59PM -0600, Jeff Anderson wrote: > > menu.py still generates a menu that points to a hard-coded :login. The > colon isn't in the urls.py. > After removing the colon from the generated menu, I noticed that the > generic login view breaks because it isn't expecting the 'repo' kwarg. > It looks like splitting the global-level type urls and the repo-level > type urls might be a good idea. Hmm. It's pretty annoying that the generic login view is so picky. Is there any chance that the upstream login view could be changed to ignore unrecognized keyword args? That would really make our life easier, and it seems like the right thing to do. In the meantime, I'll keep thinking about it. By the way, I just changed the signature for filters, which will make it easier to chain filters. It also makes each of the filter functions a little bit shorter. To really see the difference, look at rst2latex2pdf. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 |
|
From: Jeff A. <jef...@pr...> - 2008-10-10 23:15:10
|
Andrew McNabb wrote: > So, multiple repositories support works and is merged in. There have > been some drastic changes, so I wouldn't be surprised if we have any > leftover bugs. We also had to make some backwards incompatible changes > to urls.py and other settings, so I'll see if I can get Jeff to update > the docs. > In my messing with it, I found a couple problems. menu.py still generates a menu that points to a hard-coded :login. The colon isn't in the urls.py. After removing the colon from the generated menu, I noticed that the generic login view breaks because it isn't expecting the 'repo' kwarg. It looks like splitting the global-level type urls and the repo-level type urls might be a good idea. What do you think? Jeff Anderson |
