Re: [Radiant] MySQL SystemStackError: stack level too deep:
On 20 Sep 2007, at 00:47, Daniel Sheppard wrote: The following will show how deep your ruby stack can go: ruby -e '$x=0;def r;$x+=1;r;end;r rescue puts $x'; That command doesn't work for me My system can go 5050 levels. Ruby relies on the system limit on the C stack to limit its own stack. ulimit -s will show your current stack limit. My system has a limit of 8192. i set ulimit -s 8192 and it runs fine now. Thanks i've been banging my head for days over this one. Mark Kirby ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Page Versioning
Anyone? Thanks, Mohit. Mohit Sindhwani wrote: Hi Everyone, As I understand it, Radiant doesn't seem to support page versions and comments for the page versionsdirectly.. is there any extension that does? It seems that it should be easy enough to have support for comments about the different page versions. That would allow me to add something like: RECENT CHANGES Version 8: Sep 12, 2007 - Added detailed explanation for Installation. Version 7: Sep 10, 2007 - Minor changes; corrected punctuation errors. Version 6: Sep 2, 2007 - Global revision change. [Click here for earlier changes] The comments can be done by adding a 'has_many CommentsAbtversions' to the Page and then adding a small text input that allows the comment to be input. Q1: In an extension, how do I tell the difference between a 'Save' and 'Save Continue Editing' - I thought it may be better to save comments only when one does a 'Save' as against when he does a 'Save Continue Editing'. But I'm a bit more hesitant about how to actually add in the versions themselves without changing the page rendering system too much. Cheers, Mohit. 9/16/2007 | 6:46 PM. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Page Versioning
I asked this back in May. Here's the link to Sean's response: http://lists.radiantcms.org/pipermail/radiant/2007-May/005038.html I'm wondering with facets maturing if this is more feasible now than it was then? The problem I still see is more of a conceptual one: what I (and I think you) want is a history of changes at the Page level. However, changes are done at the PagePart level. But keeping a version history for each page part separately wouldn't make sense to the end user, and it probably wouldn't help admins either. Also, version control is a solved problem (or at least one with a lot of good work already put in), whereas versioning inside of a relational database is a little tougher and solutions tend to be more one-off (at least in my experience). Alternatively, something I've been toying with (and I'd love to get feedback) would be to use a variation of the import/export extension to serialize the page tree (or a subtree of it) and then put that tree in version control. I was thinking of creating directories for pages and representing each part as a file within that directory (instead of the single file format that Import/Export does, so that changesets will be more meaningful). Reverting would be a matter of loading a previous revision into the database (or you could keep other revisions in separate databases). Some pros would be: 1) We don't have to make structural changes to pages or page_parts 2) We don't have to reinvent the wheel 3) We can use proven tools that already work with repositories, such as a) Capistrano for deploying from an internal staging server to a production one, b) Meld (or any other diff tool) for viewing diffs Cons: 1) If you actually want the revision data to be viewable, that might take a little bit of work to get it from the version control system to Radiant (I think it's possible though) 2) Database reload time when moving to different revisions will probably be high. There would probably be an easy way to only load changed pages based on the changeset, which would cut down on this, at least for moving forward in the history. Any comments? -Andrew On 9/20/07, Mohit Sindhwani [EMAIL PROTECTED] wrote: Anyone? Thanks, Mohit. Mohit Sindhwani wrote: Hi Everyone, As I understand it, Radiant doesn't seem to support page versions and comments for the page versionsdirectly.. is there any extension that does? It seems that it should be easy enough to have support for comments about the different page versions. That would allow me to add something like: RECENT CHANGES Version 8: Sep 12, 2007 - Added detailed explanation for Installation. Version 7: Sep 10, 2007 - Minor changes; corrected punctuation errors. Version 6: Sep 2, 2007 - Global revision change. [Click here for earlier changes] The comments can be done by adding a 'has_many CommentsAbtversions' to the Page and then adding a small text input that allows the comment to be input. Q1: In an extension, how do I tell the difference between a 'Save' and 'Save Continue Editing' - I thought it may be better to save comments only when one does a 'Save' as against when he does a 'Save Continue Editing'. But I'm a bit more hesitant about how to actually add in the versions themselves without changing the page rendering system too much. Cheers, Mohit. 9/16/2007 | 6:46 PM. ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] [ANN] share_layouts extension
One of the most requested features for Radiant is to be able to reuse layouts in your standard Rails controllers. Well, it's here! With the help of John, I was able to write this extension from scratch today, and it is pretty well tested. I invite you to try it out and give me your feedback. You can download the extension from the main Radiant repository: http://dev.radiantcms.org/svn/radiant/trunk/extensions/share_layouts The README has a little more detail, but here's the basic way to use it: class MyController ApplicationController radiant_layout 'Main' end This will make all your actions from that controller be rendered within the Radiant Layout named 'Main'. 'content_for' blocks are mapped to page parts, e.g. a content_for :sidebar block will be accessed via r:content part=sidebar / in the Layout. The total result of your template, a.k.a. @content_for_layout, maps to the 'body' part, or r:content /. If your Layout has r:title / or r:breadcrumbs / invocations in it, you can assign these in your controller/view with @title and @breadcrumbs respectively. You may also use content_for :title/:breadcrumbs if you prefer. Cheers! Sean ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Updated benchmarks
I decided to do a quick run at writing a mongrel handler to do the work of the radiant cache - turns out there is zero performance gain in doing so. Modifying the mongrel handler to serve up html files using xsendfile, I get: 2014 bytes534.96 [#/sec] (mean) 2916 bytes532.33 [#/sec] (mean) 11918 bytes517.82 [#/sec] (mean) 101920 bytes414.64 [#/sec] (mean) 1001922 bytes189.68 [#/sec] (mean) Adding in the overhead of reading the cache metadata however, slows the handler back down: 2014 bytes160.34 [#/sec] (mean) 2916 bytes151.10 [#/sec] (mean) 11918 bytes159.20 [#/sec] (mean) 101920 bytes147.14 [#/sec] (mean) 1001922 bytes104.51 [#/sec] (mean) Those are pretty much exactly the same figures as I could pump out of radiant without a custom mongrel handler. So it looks like there's no advantage in moving the cache logic into mongrel. (I also tried changing from yaml metadata to Marshall metadata, but that also made no difference). And just for comparison, figures for radiant where mod_x_sendfile is not used: 2014 bytes161.23 [#/sec] (mean) 2916 bytes151.79 [#/sec] (mean) 11918 bytes147.70 [#/sec] (mean) 101920 bytes110.64 [#/sec] (mean) 1001922 bytes 35.62 [#/sec] (mean) And serving up the same pages as raw html with apache: 2014 bytes 2264.03 [#/sec] (mean) 2916 bytes 2341.65 [#/sec] (mean) 11918 bytes 2251.93 [#/sec] (mean) 101920 bytes 1609.84 [#/sec] (mean) 1001922 bytes565.91 [#/sec] (mean) (Note these figures are for my hardware - AMD Sempron 3000, 1gb RAM, 7200rpm SATA disks in a raid1 array - the actual figures aren't important here, just the differences) ___ Radiant mailing list Post: Radiant@lists.radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
