podwiki-devel Mailing List for PodWiki
Brought to you by:
zarahg
Menu
▾
▴
podwiki-devel — PodWiki Development
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(31) |
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Charles G. <ch...@ve...> - 2005-01-03 09:49:18
|
Hey, We're been using PodWiki for www.vexi.org and it's great! However, I'm having issues with P<state:toc> which just doesn't seem to work outside of the PodWikiSample page. The specific page is: http://wiki.vexi.org/ADDocumentation Any tips or pointers on how to get P<state:toc> working would be much appreciated. Also, you should probably make the 'Show Source' page wrap text: http://wiki.vexi.org/podwiki.pl?page=ADDocumentation&state=src Thanks for the great software! -- - Charlie Charles Goodwin <ch...@ve...> Online @ http://charlie.vexico.com |
|
From: Charles G. <ch...@ve...> - 2004-06-05 00:02:46
|
On Sat, 2004-06-05 at 01:19 +0200, Thomas Linden wrote: > Summary: one section starts with an =head<1-4> command and ends at the > next =head command of the same level (e.g. =head1 til the next =head1) > or at document end (=cut). I don't know if =end is also usable as > "section-end" command, because the =end command already exists and > requires an =begin command somewhere above. Let me rephrase. =head1/head2 are identifiers that have a visible output; you get to see the heading. What if you don't want the heading, if you just want to reuse bodies of text? -- - Charlie Charles Goodwin <ch...@ve...> Online @ www.charlietech.com |
|
From: Thomas L. <to...@co...> - 2004-06-04 23:34:11
|
On Fri, Jun 04, 2004 at 10:11:32PM +0000, Charles Goodwin wrote: > On Fri, 2004-06-04 at 22:53 +0200, Thomas Linden wrote: > > The only issue with this is that how do you differentiate between h1, > h2, h3 and how do you use H2s with spaces inbetween? h1, h2, .. are differentiated using =head1, =head2, .. POD commands. And I don't see any problems with witespaces: P<Page?Section Foo>. > What might be more useful would be an additional syntax for defining > sections, which could be nestable. I tend to use existing commands, whereever possible, in this case I would write: =head1 Section FOO appears in FOO only =head2 Section BAR appears in FOO and BAR =cut Summary: one section starts with an =head<1-4> command and ends at the next =head command of the same level (e.g. =head1 til the next =head1) or at document end (=cut). I don't know if =end is also usable as "section-end" command, because the =end command already exists and requires an =begin command somewhere above. - Tom -- Thomas Linden (http://www.daemon.de/) tom at co dot daemon dot de $_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7* ($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{ ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print; |
|
From: James H. T. <jh...@lj...> - 2004-06-04 23:21:31
|
> What might be more useful would be an additional syntax for defining > sections, which could be nestable. While it might make implementation more difficult, non-nesting but overlapping sections would be useful too: <content> section a start <content> in section a section b start <content> in section a and b section a end <content> in section b section b end <content> |
|
From: David A. B. <Br...@ac...> - 2004-06-04 23:18:31
|
On Fri, 4 Jun 2004, Thomas Linden wrote: > Hallo, > > On Wed, Jun 02, 2004 at 10:49:47PM -1000, James H. Thompson wrote: >> When thinking about changing the structure of the formatters, >> and if you have any plans to someday support Transclusion - > > However - my current idea is: What if we completely move to the > tree-parsing technique, also for external formatters? If every renderer Oh, oh, oh! This exactly what I have been thinking, too! I got started implementing, but family life and work intruded (funny how that happens, eh?). I was thinking that rather than a PodWiki::Formatter->format() method, there would be a PodWiki::Formatter->parse() method. The parse method would return a tree that is then merged into the existing tree in place of the former result of the parse of =begin formatter ...text... =end > could even render XML directly, or: we could create several output > renderers, one for "online html" (which we are using currently in the > Wiki), or one for "offline xml", e.g. RSS feed, or for site-backup. Oooo, I like that idea, too! Welcome back, Tom! -- David A. Bright Br...@ac... dab...@us... |
|
From: Charles G. <ch...@ve...> - 2004-06-04 22:09:47
|
On Fri, 2004-06-04 at 22:53 +0200, Thomas Linden wrote: > If I think about it, then I realize that implementing transclusion in > PodWiki seems to be *very* easy. Why? Because it uses POD (and this > means: I don't think it will be possible with "foreign" formatters). Please do implement it. This would be invaluable, and make podwiki a much more effective content management tool. > Now I could include part of this document like this: > > P<BlahDoc?INTRO> The only issue with this is that how do you differentiate between h1, h2, h3 and how do you use H2s with spaces inbetween? What might be more useful would be an additional syntax for defining sections, which could be nestable. =section FOO appears in FOO only =section BAR appears in FOO and BAR =end BAR appears in FOO only =end FOO -- - Charlie Charles Goodwin <ch...@ve...> Online @ www.charlietech.com |
|
From: Thomas L. <to...@co...> - 2004-06-04 21:08:55
|
Hallo, On Wed, Jun 02, 2004 at 10:49:47PM -1000, James H. Thompson wrote: > When thinking about changing the structure of the formatters, > and if you have any plans to someday support Transclusion - at the moment there are no thoughts about transclusion. In my case this is because I just didn't know about this idea :-) If I think about it, then I realize that implementing transclusion in PodWiki seems to be *very* easy. Why? Because it uses POD (and this means: I don't think it will be possible with "foreign" formatters). Say, I have a document "BlahDoc": =head2 INTRO This tells about fish and chips =head2 RECEIPT .. =cut Now I could include part of this document like this: P<BlahDoc?INTRO> which includes the content (unrendered!) between the "=head2 INTRO" and the next "*head" command. This works, because the Pod::Tree parser used in PodWiki already divides a POD document into sections (internally called nodes), which makes it very easy to pick out a particular section. Of course this section must exist otherwise it would not work. I am unsure how this could to be implemented for external formatters. The problem (and that's what David mentioned earlier) is the totally different way that external Formatters and the POD parser are working. The POD parser generates a tree of nodes from the document and PodWiki then walks recursive over the tree while rendering each single node. An external formatter on the other hand does a big search/replace action over the whole document. This way is of course somewhat simpler to implement, but it does not allow to divide the document into sections, at least it makes it more complicated. However - my current idea is: What if we completely move to the tree-parsing technique, also for external formatters? If every renderer works the same way, it would be much easier to implement new features for both "worlds". To be frank: ok, we could also do the reverse, we could re-implement the POD formatter using the search/replace technique. And to be honest, I already tried to write such a formatter some months ago (when I started with PodWiki), but I were unsuccessful :-| The POD format is well suited for regex-parsers. So, perhaps it would be a good idea to write a generic tree parser, which is used by PodWiki for actually rendering stuff. But behind the scenes, there are specialized parsers which are overwriting some or all of the methods of the "Super" parser, one for POD, one for Twiki and so on, PodWiki doesn't know what type of document it is rendering. The Super parser could provide methods similar to XML tree parsers, in fact, if someone of you ever worked with XML parsers - they "feel" much like the POD::Tree parser. This would provide some more possibilities: we could even render XML directly, or: we could create several output renderers, one for "online html" (which we are using currently in the Wiki), or one for "offline xml", e.g. RSS feed, or for site-backup. Much stuff to think about :-) regards, Tom -- Thomas Linden (http://www.daemon.de/) tom at co dot daemon dot de $_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7* ($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{ ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print; |
|
From: James H. T. <jh...@lj...> - 2004-06-03 08:49:53
|
When thinking about changing the structure of the formatters, and if you have any plans to someday
support Transclusion -
definitions and examples:
http://c2.com/cgi/wiki?TransClusion
http://www.burningchrome.com:8000/~cdent/wiki.cgi?TransClusion
You might want to consider the a structure to make this easier to implement in the future.
There is a discussion of how Transclusion might be implemented in Owiki (a fork of Twiki) here:
http://www.owiki.org/twiki/bin/view/Openwiki/NamedIncludeSections
Jim
James H. Thompson
jh...@la...
|
|
From: Thomas L. <to...@co...> - 2004-05-27 22:35:34
|
On Thu, May 27, 2004 at 11:59:40AM -0500, David A. Bright wrote: > Anyway, assuming that is the case, the only problem I see with that is that > it would happen on each read of a page, which would mean there would be a > lot of (redundant) updates to the Storable. Unless, of course, we can > somehow restrict that mode to only the rendering of the page immediately > after the save. the function could have a simple flag indicating that it should now update the storable file. I think this must be a global flag or something, its default value is 0 and the save() function sets it to 1 after the rcs check-in, because after that it just calls the render function for the new page so that a user gets the new page displayed after saving it. The only problem left is to generalize pod_link so that each formatter and the pod walker's are using it. Well - have fun playing around with this :-) Tom -- Thomas Linden (http://www.daemon.de/) tom at co dot daemon dot de $_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7* ($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{ ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print; |
|
From: David A. B. <Br...@ac...> - 2004-05-27 17:00:03
|
On Thu, 27 May 2004, Thomas Linden wrote: > at first: please do not send such mails To: me and Cc: to the list, > because SF's mailman seems to ignore Cc:'ed mails to the list and > therefore does not set a reply-to field. That causes me to rewrite the > mailheader of my ansers manually. Sorry about that. That is what happens when I reply to your emails (such as this one). I'll just try to remember to whack the Cc:. > On Thu, May 27, 2004 at 10:07:30AM -0500, David A. Bright wrote: >> - Different formatters make this a potentially a little more difficult, as >> the linking form is different for each one. We probably need an interface >> in each formatter to handle the conversion. > > What if we centralize the pod_link() function (which is afaik on the > todo list anyway) and let it register each link?, e.g. you call it this > way: pod_link($from, $to), where $from is the page which contains the > link and $to is the destination. We could use a Storable for this, the > same way as attributes or users are saved. The current implementaition > seems to be lock-save and stable (at least I had no attribute lost on > daemon.de since I updated it to 0.8.0). What do you think? Interesting idea; this might minimize the impact of making the change and that is always attractive. Of course, we have to figure out how to utilize pod_link for links in the POD formatter (or vice-versa), which is kind of what my other message on unification of formatters (not really markup) was about. Anyway, assuming that is the case, the only problem I see with that is that it would happen on each read of a page, which would mean there would be a lot of (redundant) updates to the Storable. Unless, of course, we can somehow restrict that mode to only the rendering of the page immediately after the save. Maybe I'll find some time to play with it a bit while you're away. There's a scary thought! -- David A. Bright Br...@ac... dab...@us... |
|
From: Thomas L. <to...@co...> - 2004-05-27 16:30:09
|
Hello David, at first: please do not send such mails To: me and Cc: to the list, because SF's mailman seems to ignore Cc:'ed mails to the list and therefore does not set a reply-to field. That causes me to rewrite the mailheader of my ansers manually. On Thu, May 27, 2004 at 10:07:30AM -0500, David A. Bright wrote: > - Different formatters make this a potentially a little more difficult, as > the linking form is different for each one. We probably need an interface > in each formatter to handle the conversion. What if we centralize the pod_link() function (which is afaik on the todo list anyway) and let it register each link?, e.g. you call it this way: pod_link($from, $to), where $from is the page which contains the link and $to is the destination. We could use a Storable for this, the same way as attributes or users are saved. The current implementaition seems to be lock-save and stable (at least I had no attribute lost on daemon.de since I updated it to 0.8.0). What do you think? regards, Tom -- Thomas Linden (http://www.daemon.de/) tom at co dot daemon dot de $_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7* ($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{ ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print; |
|
From: David A. B. <Br...@ac...> - 2004-05-27 15:08:11
|
I've been giving page rename/move some thought. I'm not sure how to do it yet. A few issues: - Different formatters make this a potentially a little more difficult, as the linking form is different for each one. We probably need an interface in each formatter to handle the conversion. - Direct HTML links (i.e., directly coding a <a href=...>) are probably not worth trying to handle. - It may be desirable to leave a "redirect" page with the old name. - How do we know which pages have links to the page to be renamed? One possibility is to keep track of the links that each page has. This would be updated on each save of the page and then that could be consulted. I think this would require the formatters to return information about links as they render the page. The danger here is that this record of links could get out of sync; there might need to be a way to force it to be reconstructed. If that is the case, should we even bother with it at all? Another question is where would this information be kept? Keeping it in a central location might lead to locking problems. Keeping it one a page by page basis would alleviate that, but, again, where to store it (e.g., a .PageName.links file?). Another possibility is that we search at the time of rename. This could be time consuming, but would eliminate the problem of keeping link lists in sync. Since rename is a relatively infrequent operation (I'm making an assumption here!), maybe the time penalty is not too serious. Again, this probably requires a "rename" interface in the formatters. With either of these approaches, there is the question of what to do when a page that is currently locked has references that need to be renamed. Just a start on some thoughts here. Let me know if you have any comments or other ideas. I'm sure there are things I haven't thought of yet. Thanks. -- David A. Bright Br...@ac... dab...@us... |
|
From: Thomas L. <to...@co...> - 2004-05-27 14:40:53
|
On Thu, May 27, 2004 at 08:46:30AM -0500, David A. Bright wrote:
> What if both forms were changed to, instead of printing (either as-they-go
> or at the tail end), simply return a string. The strings can be accumulated
> as the processing continues and then printed at the end of Runner::run.
>
> This would be a pretty big change, so I thought I'd run it by you first.
> What do you think?
I thought about it too, but I'm unsure if this makes things better.
I already maintain an (commercial) application written in perl too,
which works this way. There are some other problems coming up, e.g.
if at some point an error occurs. When will it be printed? Will it
be visible (destroyed tables and stuff)? So, what I did in my commercial
application: the whole rendering happens within an eval { } block and
every failure uses die() to tell about it, this will be catched by the
core engine, which in turn then is able to render a proper failure
page.
But in the case of PodWiki this method is unusable, because PodWiki does
not build the page at all (as you know, it just calls "AutoLoad" which
includes the rest). If we would do it this way, error messages will not
occur inside the existing site design but in a "native" build-in design
:-|
So, I'm unsure if we shall do that work (which is really a lot of it).
Tom
PS: btw - I'll be in vacation for one week starting tomorrow, so I will
not respond til next saturday..
--
Thomas Linden (http://www.daemon.de/) tom at co dot daemon dot de
$_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7*
($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{
ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print;
|
|
From: David A. B. <Br...@ac...> - 2004-05-27 13:42:13
|
Tom, I've been thinking for a while about the behavior of the different formatters. What got me started on this is the fact that we have two different pieces of code to produce links, one for POD and one for the other formatters. They can't be combined due to the behavior of the non-POD formatters. POD first parses everything into a tree and then runs through the tree, "print"ing every node in the tree. The other formatters, however, do a "search and replace" style of formatting within the input text. After everything is formatted, then they print (some doing minimal post-processing to form paragraphs). What if both forms were changed to, instead of printing (either as-they-go or at the tail end), simply return a string. The strings can be accumulated as the processing continues and then printed at the end of Runner::run. This would be a pretty big change, so I thought I'd run it by you first. What do you think? -- David A. Bright Br...@ac... dab...@us... |
|
From: Thomas L. <to...@co...> - 2004-05-25 06:58:51
|
On Mon, May 24, 2004 at 09:47:07PM -0500, David A. Bright wrote: > >there is a problem with lists (or I misunderstand it): If I use 3 spaces > >followed by an asterisk, nothing happens, it renders to "* blah". The > >formatter seems only to recognize TABs, so, if I use "\t* blah" it > >renders as expected. > > Shoot. TWiki converts the 3, 6, 9, ... leading spaces into tab characters > upon saving a file. I was working with pages migrated from TWiki, so of > course this conversion was already done. PodWiki won't do that conversion, > however. I just checked in a change to pre-convert the spaces into tabs so > the rest of the regexps match properly. ah, I see. > Unfortunately, I didn't get it done fast enough to make the 0.8 release. > Bummer. that's no problem, usually I like to make releases in smaller steps as I did this time, 0.8.0 has really too many changes :-) Tom -- Thomas Linden (http://www.daemon.de/) tom at co dot daemon dot de $_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7* ($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{ ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print; |
|
From: David A. B. <Br...@ac...> - 2004-05-25 02:46:56
|
On Mon, 24 May 2004, Thomas Linden wrote: > On Mon, May 24, 2004 at 08:08:12PM +0200, Thomas Linden wrote: >> On Mon, May 24, 2004 at 09:54:13AM +0200, Thomas Linden wrote: >>> I've detected a major bug in the PodWiki Authentication code which >>> affects user-based authorization. If a page ise read or write protected >>> by user (write = user:scip) then any logged in user will be granted >>> permission. The authorization code ignores the "user:" stuff completely. >> >> fixed in latest CVS, I'll release 0.8.0 today or tomorrow.. > > well - finally I released 0.8.0. By the way, the conversion to the new Storable format wasn't working on my site. My installation of perl doesn't have MLDBM, so when the conversion script was called it bombed on "use MLDBM;". The solution was to call the script as: perl -Ilib support/dbm2storable ... The -Ilib allowed perl to find MLDBM in the distribution tree. -- David A. Bright Br...@ac... dab...@us... |
|
From: David A. B. <Br...@ac...> - 2004-05-25 02:43:40
|
On Mon, 24 May 2004, Thomas Linden wrote: > On Mon, May 24, 2004 at 08:28:26AM -0500, David A. Bright wrote: >> I added the TWiki formatter to CVS this morning. There is an accompanying >> page in docs/ too. > > there is a problem with lists (or I misunderstand it): If I use 3 spaces > followed by an asterisk, nothing happens, it renders to "* blah". The > formatter seems only to recognize TABs, so, if I use "\t* blah" it > renders as expected. Shoot. TWiki converts the 3, 6, 9, ... leading spaces into tab characters upon saving a file. I was working with pages migrated from TWiki, so of course this conversion was already done. PodWiki won't do that conversion, however. I just checked in a change to pre-convert the spaces into tabs so the rest of the regexps match properly. Unfortunately, I didn't get it done fast enough to make the 0.8 release. Bummer. -- David A. Bright Br...@ac... dab...@us... |
|
From: Thomas L. <to...@co...> - 2004-05-24 21:46:44
|
On Mon, May 24, 2004 at 08:08:12PM +0200, Thomas Linden wrote: > On Mon, May 24, 2004 at 09:54:13AM +0200, Thomas Linden wrote: > > I've detected a major bug in the PodWiki Authentication code which > > affects user-based authorization. If a page ise read or write protected > > by user (write = user:scip) then any logged in user will be granted > > permission. The authorization code ignores the "user:" stuff completely. > > fixed in latest CVS, I'll release 0.8.0 today or tomorrow.. well - finally I released 0.8.0. Thanks to David :-) regards, Tom -- Thomas Linden (http://www.daemon.de/) tom at co dot daemon dot de $_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7* ($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{ ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print; |
|
From: Thomas L. <to...@co...> - 2004-05-24 20:02:13
|
On Mon, May 24, 2004 at 08:28:26AM -0500, David A. Bright wrote: > I added the TWiki formatter to CVS this morning. There is an accompanying > page in docs/ too. there is a problem with lists (or I misunderstand it): If I use 3 spaces followed by an asterisk, nothing happens, it renders to "* blah". The formatter seems only to recognize TABs, so, if I use "\t* blah" it renders as expected. regards, Tom -- Thomas Linden (http://www.daemon.de/) tom at co dot daemon dot de $_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7* ($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{ ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print; |
|
From: Thomas L. <to...@co...> - 2004-05-24 18:22:47
|
On Mon, May 24, 2004 at 09:54:13AM +0200, Thomas Linden wrote: > I've detected a major bug in the PodWiki Authentication code which > affects user-based authorization. If a page ise read or write protected > by user (write = user:scip) then any logged in user will be granted > permission. The authorization code ignores the "user:" stuff completely. fixed in latest CVS, I'll release 0.8.0 today or tomorrow.. Tom -- Thomas Linden (http://www.daemon.de/) tom at co dot daemon dot de $_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7* ($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{ ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print; |
|
From: David A. B. <Br...@ac...> - 2004-05-24 13:24:49
|
I added the TWiki formatter to CVS this morning. There is an accompanying page in docs/ too. -- David A. Bright Br...@ac... dab...@us... |
|
From: Thomas L. <to...@co...> - 2004-05-24 08:08:45
|
Hi, this my very first security advisory (he he).. I've detected a major bug in the PodWiki Authentication code which affects user-based authorization. If a page ise read or write protected by user (write = user:scip) then any logged in user will be granted permission. The authorization code ignores the "user:" stuff completely. The bug can be observed here: http://sourceforge.net/tracker/index.php?func=detail&aid=959294&group_id=107739&atid=649244 There is currently only one workaround possible: do not use user-based authentication. And, make regular backups of your data/ directory, just in case someone edits pages, who is not allowed to do so. I'll try my best to fix this BUG asap. Thanks, and kind regards, Tom -- Thomas Linden (http://www.daemon.de/) tom at co dot daemon dot de $_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7* ($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{ ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print; |
|
From: Thomas L. <to...@co...> - 2004-05-19 06:30:34
|
Hi, On Wed, May 19, 2004 at 12:42:05AM -0500, DAB...@us... wrote: > I am working on a TWiki formatter, which I needed for a wiki at work. > Actually, it is pretty much code complete; I am just waiting for some > communication with the TWiki lead to make sure it is OK to include their it should be ok, since it is GPLed, as long as we keep the copyright of the module, I don't see an issue.. > code in PodWiki. It was easier to just take their rendering code and modify > it a bit for PodWiki than to write it from scratch. yes, good idea of course :-) regards, Tom -- Thomas Linden (http://www.daemon.de/) tom at co dot daemon dot de $_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7* ($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{ ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print; |
|
From: <DAB...@us...> - 2004-05-19 05:38:59
|
I am working on a TWiki formatter, which I needed for a wiki at work. Actually, it is pretty much code complete; I am just waiting for some communication with the TWiki lead to make sure it is OK to include their code in PodWiki. It was easier to just take their rendering code and modify it a bit for PodWiki than to write it from scratch. -- David A. Bright dab...@us... |
|
From: Thomas L. <to...@co...> - 2004-05-16 23:02:07
|
Finally I released PodWiki version 0.7.4. Should really be 0.8.0, however.. let's see it as pre-0.8.0 instead :-) regards, Tom -- Thomas Linden (http://www.daemon.de/) tom at co dot daemon dot de $_=`perl -v`;s;^.*ll;;s;$^=unpack"u", "'8V]D;')E<```";s;\W;;gs;$/=7* ($^=~s;.;;g);%^=map{$_=>1}split//,lc;$_=join$\, (sort keys(%^))[map{ ord($_)-$/}split//,'1I7E13?@E:7C1A7C=1:35<7C'];s"0(.)" \U$1"g;print; |
