slashcode-development — This list is for development of slashcode, no install questions please.

Re: [Slashcode-development] Request for Comments: Automated Schema Updates for Slash

[Peter W. <pe...@op...>]

Brian Aker wrote:
> Used the template-tool -U bit?

Yes, I did a quick test ( I've not had time to check the code yet to see
what it actually does ). It updates the templates to the latest version
of the templates that are installed, right?

But what if I do a default slash site using the slashcode theme .. does
a lot of changes to the templates .. I launch the site .. and a couple
of months later I decide that I want to upgrade to a newer version of
slash cvs. I install the new version of slash cvs .. if I run
template-tool -U now .. doesn't I end up with the default slashcode
template again ( even if it's the latest version of the slashcode
templates )?.

peter

Re: [Slashcode-development] Request for Comments: Automated Schema Updates for Slash

[Brian A. <br...@ta...>]

On Wed, 2003-07-30 at 12:24, Peter Winnberg wrote:
> I think that a tool like this would certainly make life easier when you
> run several slash sites ( hell even if you just run one ). 
I am attaching the current version of it. No promises about its state at all.
I had a feature in it to allow someone to take a text like file and
insert the entry from it parsed, but personally I am going to pull it
since I had no interest in it.

> Is anyone thinking about a tool to help upgrading templates as well?
> Because it can be a lot of work.
Used the template-tool -U bit?
	-Brian
-- 
_______________________________________________________
Brian "Krow" Aker, br...@ta...
Seattle, Washington
http://krow.net/
http://askbrian.org/
_______________________________________________________
You can't grep a dead tree.

Re: [Slashcode-development] Request for Comments: Automated Schema Updates for Slash

[Peter W. <pe...@op...>]

Brian Aker wrote:
> When I looked at this, I wanted to make a patch tool.
> My tool works off a data file that looks like this:
> <updates>
>         <patch>
>                 <id>2322</id>
>                 <comment>Sample Comment</comment>
>                 <author>Brian</author>
>                 <sql>SELECT now()</sql>
>         </patch>
>         <patch>
>                 <id>2322</id>
>                 <comment>Sample Comment</comment>
>                 <author>Brian</author>
>                 <sql>SELECT now()</sql>
>                 <sql>ALTER MORE CRAP</sql>
>         </patch>

I think that a tool like this would certainly make life easier when you
run several slash sites ( hell even if you just run one ). 

We at Openflows are interested in a tool like this, so we'll help out to
make sure that one gets developed. We've developed and host a number of
slash sites using various cvs versions, as well as 2.2.6. 

Krow's XML syntax (above) for the upgrades file makes a lot of sense, at
least to me. 

Is anyone thinking about a tool to help upgrading templates as well?
Because it can be a lot of work.

I'll now go back to upgrading yet another Slash site. :P

Re: [Slashcode-development] Request for Comments: Automated Schema Updates for Slash

[Clifton W. <cl...@sl...>]

On Wednesday 30 July 2003 06:10, shane wrote:

> No no no. The THEME and PLUGIN file would need to have a new line
> that'd take someting like
>
> VERSION = blah
>
> But it'd be stored in the db.

OIC!

That's an idea, definitely.

- Cliff

Re: [Slashcode-development] Request for Comments: Automated Schema Updates for Slash

[Brian A. <br...@ta...>]

On Tue, 2003-07-29 at 21:02, Clifton Wood wrote:
> On Tuesday 29 July 2003 18:55, shane wrote:
> > Wasn't someone from OSDN working on such a beast a few months ago?
> I think that was Brian, who now works for MySQL, and I don't think 
> OSDN is willing to pick this task up at this time.
Yep, that was me, and I have the basics of such a tool that I am willing
to share with someone (the tool). My version of Slash is a fork, but
this tool should be able to work for both.

A more general sql diff tool might be of interest for MySQL, but it
would need to be written in C.

> I'd rather not put the versions in the files. I'd prefer to have them
> in the database, however this is not a hard and fast rule. If 
> someone can come up with a better system that uses
> files than I'm interested.
Personally I think that plugins and the core do need versions, but that these should work like the perl ones and be more for "minimum" support.

> > Oh bless the Lord wouldn't such a tool be sweet to have.
> Yes, and hence my attempts at drumming up some support
> for it. =)
Good, needs to be done :)

	-Brian
-- 

Re: [Slashcode-development] Request for Comments: Automated Schema Updates for Slash

[Clifton W. <cl...@sl...>]

On Tuesday 29 July 2003 18:55, shane wrote:

> Wasn't someone from OSDN working on such a beast a few months ago?

I think that was Brian, who now works for MySQL, and I don't think 
OSDN is willing to pick this task up at this time.

> How about expanding the THEME, PLUGIN, and site_info table to
> hold version #'s? Or version tags? or something.
>
> But that would give an upgrade-tool app/script something to key
> off of.
>
> It might also simplify support - in that when you ask someone what
> version of Slash, or some plugin, they are running, and they go
> 'oh, uh, i installed that last year, I don't know'.

I'd rather not put the versions in the files. I'd prefer to have them
in the database, however this is not a hard and fast rule. If 
someone can come up with a better system that uses
files than I'm interested.

> Oh bless the Lord wouldn't such a tool be sweet to have.

Yes, and hence my attempts at drumming up some support
for it. =)

> I can devote a list serve to the cause, if needed.

Well, we're good here for a bit, but I might take you up on that.

- Cliff

Re: [Slashcode-development] Request for Comments: Automated Schema Updates for Slash

[shane <sh...@lo...>]

On Saturday 26 July 2003 15:02, Cliff Wood wrote:
> For those interested, I'd like to propose the following and open
> up the floor for comments. If anyone is interested in this
> subject, please speak up!
>
>
> Automated Schema Updates for Slash
> ----------------------------------
>
> While the current system for updating the Slash schema isn't all that
> complex, it is a bit tedious, and as the number of Slash sites to
> maintain increases, this tedium can then become an updating
> nightmare. Currently, all updates must be done by hand, for each
> site: this includes core updates, core plugin updates, core theme
> updates, third party plugin updates and third party theme updates.
> Rigth now, most of the core changes are tracked in
> slash/sql/mysql/updates (since MySQL is the only backend really
> being supported, at the moment). This is good, but what happens when
> site administrators have to worry about updates for third party
> add-ons? And for multiple Slash sites?

Yes, tedious is one of the words I've referred to it as. It's not bad when you 
have one, or two sites. But get 5 or more and... ugh.

A lot of the work, for me, is the templates. If a site has highly customized 
looknfeel, the works exponential to make sure everything in the templates is 
updated to match the stock slashcode theme's templates.

Now, IMHO, this will be lessened if/when the standard slashcode them uses CSS. 
Cosmetic changes? Change the stylesheet, and no need to change a lof of the 
templates. (Ok, I'm getting OT here)

> What is proposed is a community effort to design and implement an
> automated tool that can determine, parse, and apply any changes that
> need to be made to a Slash backend to bring it current with the
> updates in database schema and data storage methods employed by
> Slash, to reduce the hassle and the problems that occur with Slash
> software updates.

Wasn't someone from OSDN working on such a beast a few months ago?

> To simplify this problem, I have broken the issue up into 4 phases,
> including a "prep" phase:
>
> 	0. Prep
>
> 	I. Determining Current Schema Characteristics
>
> 	II. Parsing Schema Changes
>
> 	III. Applying Schema Changes
>
> 	IV. Updating Data
>
> 	V. Schema Verification
>
> Now, to discuss the issues surrounding each phase:
>
> 0. Prep
>
> This is basically the "housekeeping" step that needs to be done to
> the codebase. There are two major concerns: converting the current
> upgrades file into something that is both human and machine readable.
> The second is providing a system where third-party themes and
> plugins can specify their own updates, as a working system will need
> to consider those changes as well. This tool might also assist
> developers in keeping their changes aligned with changes in Slash
> (by providing warnings and errors when their changes fall out of
> date and conflict with the core), especially if the developer is
> following Slash development from CVS. (For the sake of argument,
> "third-party" is used to define anything not included with core
> Slash, and the determination of what is, and is not "core" is left
> up to the Slash Development Team).
>
> Much of the work has been done, since the upgrades file is heavily
> commented (including notations of the updates for T_ and R_ release
> flags, and plugins specific updates). If we can standardize on such
> notations, we can parse them out.

How about expanding the THEME, PLUGIN, and site_info table to 
hold version #'s? Or version tags? or something.

But that would give an upgrade-tool app/script something to key off of.

It might also simplify support - in that when you ask someone what version of 
Slash, or some plugin, they are running, and they go 'oh, uh, i installed 
that last year, I don't know'.

> I. Determining Current Schema Characteristics
>
> Before updating a schema, it must be analyzed for validity. The
> analysis doesn't necessarily have to be expensive, but checks
> bypassed here, may be necessary (and more expensive to
> implement) if put off to a later phase (most likely to the
> verification phase).
>
> Analysis here could be as simple as a variable (one for the core
> code, and a variable each for every third party plugin AND theme).
> Or it could be as complex, involving a thorough (and processor
> intensive) analysis of the current schema for validity.
>
> Regardless of the implementation, we must be able to provide some
> kind of starting point for the update tool to work from.
>
>
> II. Parsing Schema Changes
>
> From said starting point, a list of changes needs to be constructed
> from the given update data, from the core and from third party
> addons.

Ya know, I recall a few weeks ago seeing someone on, I think, freshmeat, that 
someone wrote - that would go through a mysql db and come up with a diff for 
that schema. That might be worth looking into.

> III. Applying Schema Changes
>
> Changes are then applied to the site, with core changes being applied
> first and third-party changes applied last.

How would you handle relevance, or dependance? Especially with foreign keys?

> IV. Updating Data
>
> In the event that schema changes from one version to the next,
> involve updating data in some manner, than these changes need to be
> done in this stage.
>
>
> V. Schema Verification
>
> The entire schema may then need to be verified. It might be wise to
> take the existing schema (both core and third party) and compare it
> to what's currently live and note the differences.
>
>
> Note, that in the event of a multi-version update, the tool will run
> the phases in the following order (say from version x, thru y, to z):
>
> 	  Start     Vx -> Vy 	 Vy -> Vz   Fin
> 	I -> II -> III -> IV -> III -> IV -> V
>
> Such a tool, once developed to handle a single site, automatically.
> Can then be applied to update Slash clusters, via "glue"-methods
> like shell scripts or Perl, cutting down on the laber necessary to
> prepare a Slash site for a software update, and minimizing the
> chance of human error in the update
> process.

Oh bless the Lord wouldn't such a tool be sweet to have.

> Now I don't have a complete answer to this entire problem, so this
> is where the community gets involved. If you are interested in
> working on this problem, I'd be very interested in hearing your
> thoughts. If enough like minded individuals are interested in
> putting their heads together, maybe we can come up with a workable
> solution that everyone can use.

I can devote a list serve to the cause, if needed. 

 Shane

Re: [Slashcode-development] Request for Comments: Automated Schema Updates for Slash

[Brian A. <br...@ta...>]

When I looked at this, I wanted to make a patch tool.
My tool works off a data file that looks like this:
<updates>
        <patch>
                <id>2322</id>
                <comment>Sample Comment</comment>
                <author>Brian</author>
                <sql>SELECT now()</sql>
        </patch>
        <patch>
                <id>2322</id>
                <comment>Sample Comment</comment>
                <author>Brian</author>
                <sql>SELECT now()</sql>
                <sql>ALTER MORE CRAP</sql>
        </patch>

The thing is that is that each plugin should have its own XML update
file that can be used, which is something that mine does not do yet.

For what it is worth, the livejournal code base uses a really cool tool
to diff schema and then apply patches.

	-Brian

-- 
_______________________________________________________
Brian "Krow" Aker, br...@ta...
Seattle, Washington
http://krow.net/
http://askbrian.org/
_______________________________________________________
You can't grep a dead tree.

[Slashcode-development] thoughts about slash wiki

[<par...@de...>]

Hello

I'm playing with the slash wiki and i think it could be a great idea
that every user can have a personal page in the slash site using wiki.

I think it should not be difficult to call the routine for generating
this page when the user is created, but i wonder about some things:

- is this plugin stable?
- have you thought about uploading images on the wiki? (perfect for a
personal page)
- have you thought about a few configuration variables? (like one for
the back color of the page)
- have you thought about a way of deleting revisions from the admin
interface?
- can i help to develop some of this things? is anyone interested?

Yes, i know that there are bigger wikis that do many thinks, but it's
good to integrate fairly with slash, and we can think in a few utilities
of this.

Thanks


-- 
par...@de... <par...@de...>
deporteyciencia.com

Re: [Slashcode-development] OT: mysqldump and auto_increment (for the list)

[Clifton W. <cl...@sl...>]

On Wednesday 23 July 2003 06:17, shane wrote:
> Anyone know how to make mysqldump ignore the auto_increment field?
>
> There's a mention from Sinisa Milivojevic from TcX saying that it
> was to be put on the TODO list - from 04/2000.
>
> <URL:
> http://groups.google.com/groups?q=mysqldump+auto_increment&ie=ISO-
>8859-1&hl=en&btnG=Google+Search
>
>
>
> As far as I can tell, w/ mysql 4.x mysqldump doesn't yet have the
> cabability.
>
> So... does anyone know how to do it?

[ It appears that this didn't make it to the list, so I reprint it 
here for all interested parties. ]

Here you go, shane.

See what happens when I get bored?

All comments, corrections, constructive criticisms, and most
importantly, patches accepted.

- Cliff

[Slashcode-development] Request for Comments: Automated Schema Updates for Slash

[Cliff W. <cl...@lr...>]

For those interested, I'd like to propose the following and open
up the floor for comments. If anyone is interested in this
subject, please speak up!


Automated Schema Updates for Slash
----------------------------------

While the current system for updating the Slash schema isn't all that
complex, it is a bit tedious, and as the number of Slash sites to
maintain increases, this tedium can then become an updating 
nightmare. Currently, all updates must be done by hand, for each 
site: this includes core updates, core plugin updates, core theme 
updates, third party plugin updates and third party theme updates. 
Rigth now, most of the core changes are tracked in 
slash/sql/mysql/updates (since MySQL is the only backend really 
being supported, at the moment). This is good, but what happens when 
site administrators have to worry about updates for third party 
add-ons? And for multiple Slash sites?

What is proposed is a community effort to design and implement an 
automated tool that can determine, parse, and apply any changes that 
need to be made to a Slash backend to bring it current with the 
updates in database schema and data storage methods employed by 
Slash, to reduce the hassle and the problems that occur with Slash 
software updates.

To simplify this problem, I have broken the issue up into 4 phases, 
including a "prep" phase:

	0. Prep

	I. Determining Current Schema Characteristics

	II. Parsing Schema Changes

	III. Applying Schema Changes

	IV. Updating Data

	V. Schema Verification

Now, to discuss the issues surrounding each phase:

0. Prep

This is basically the "housekeeping" step that needs to be done to 
the codebase. There are two major concerns: converting the current 
upgrades file into something that is both human and machine readable. 
The second is providing a system where third-party themes and 
plugins can specify their own updates, as a working system will need 
to consider those changes as well. This tool might also assist 
developers in keeping their changes aligned with changes in Slash 
(by providing warnings and errors when their changes fall out of 
date and conflict with the core), especially if the developer is 
following Slash development from CVS. (For the sake of argument, 
"third-party" is used to define anything not included with core 
Slash, and the determination of what is, and is not "core" is left 
up to the Slash Development Team). 

Much of the work has been done, since the upgrades file is heavily 
commented (including notations of the updates for T_ and R_ release 
flags, and plugins specific updates). If we can standardize on such 
notations, we can parse them out.


I. Determining Current Schema Characteristics

Before updating a schema, it must be analyzed for validity. The 
analysis doesn't necessarily have to be expensive, but checks 
bypassed here, may be necessary (and more expensive to 
implement) if put off to a later phase (most likely to the 
verification phase).

Analysis here could be as simple as a variable (one for the core 
code, and a variable each for every third party plugin AND theme). 
Or it could be as complex, involving a thorough (and processor 
intensive) analysis of the current schema for validity.

Regardless of the implementation, we must be able to provide some 
kind of starting point for the update tool to work from.


II. Parsing Schema Changes

From said starting point, a list of changes needs to be constructed 
from the given update data, from the core and from third party 
addons.


III. Applying Schema Changes

Changes are then applied to the site, with core changes being applied 
first and third-party changes applied last.


IV. Updating Data

In the event that schema changes from one version to the next, 
involve updating data in some manner, than these changes need to be 
done in this stage.


V. Schema Verification

The entire schema may then need to be verified. It might be wise to 
take the existing schema (both core and third party) and compare it 
to what's currently live and note the differences.


Note, that in the event of a multi-version update, the tool will run
the phases in the following order (say from version x, thru y, to z):
                     
	  Start     Vx -> Vy 	 Vy -> Vz   Fin
	I -> II -> III -> IV -> III -> IV -> V

Such a tool, once developed to handle a single site, automatically. 
Can then be applied to update Slash clusters, via "glue"-methods 
like shell scripts or Perl, cutting down on the laber necessary to 
prepare a Slash site for a software update, and minimizing the 
chance of human error in the update 
process.


Now I don't have a complete answer to this entire problem, so this
is where the community gets involved. If you are interested in 
working on this problem, I'd be very interested in hearing your 
thoughts. If enough like minded individuals are interested in 
putting their heads together, maybe we can come up with a workable 
solution that everyone can use.

I'm looking forward to reading the thoughts from this list.

- Cliff

Re: [Slashcode-development] OT: mysqldump and auto_increment

[Clifton W. <cl...@sl...>]

On Wednesday 23 July 2003 06:17, shane wrote:
> Anyone know how to make mysqldump ignore the auto_increment field?
>
> There's a mention from Sinisa Milivojevic from TcX saying that it
> was to be put on the TODO list - from 04/2000.
>
> <URL:
> http://groups.google.com/groups?q=mysqldump+auto_increment&ie=ISO-
>8859-1&hl=en&btnG=Google+Search
>
>
>
> As far as I can tell, w/ mysql 4.x mysqldump doesn't yet have the
> cabability.
>
> So... does anyone know how to do it?
>
> Or is everyone, including OSDN, using a custom script to pull data
> out of the db to create dump files such as datadump.sql for
> themes?

Shane,

Right now, I think you are limited to either writing a script to do 
it or editing by hand. It would be a nice feature to be sure.

Makes an interesting problem, though. I can see one way a
general script could be written that would take a field and an 
optional table and would then go through the output of a
"mysqldump -c" and remove all values that match. That would
be rather easy for me to do, I think. If you want, I can try and
crank it out by the end of the weekend.

'twould be a fun excercise.

- Cliff

[Slashcode-development] misc_user_opts

[shane <sh...@lo...>]

Can someone please explain what misc_user_opts is for? it looks like this:

mysql> describe misc_user_opts;
+-------------+-----------------------+------+-----+---------+-------+
| Field       | Type                  | Null | Key | Default | Extra |
+-------------+-----------------------+------+-----+---------+-------+
| name        | varchar(32)           |      | PRI |         |       |
| optorder    | mediumint(5)          | YES  |     | NULL    |       |
| seclev      | mediumint(8) unsigned |      |     | 0       |       |
| default_val | text                  |      |     |         |       |
| vals_regex  | text                  | YES  |     | NULL    |       |
| short_desc  | text                  | YES  |     | NULL    |       |
| long_desc   | text                  | YES  |     | NULL    |       |
| opts_html   | text                  | YES  |     | NULL    |       |
+-------------+-----------------------+------+-----+---------+-------+
8 rows in set (0.00 sec)


There's a call in Slash::DB::Mysql called 

getMiscUserOpts 

it seems to where it against the current user's seclev.

I did a quick grep for a corresponding "setMiscUserOpts" - no dice.

I found this looking at users.pl, and saw users.pl?op=editmiscopts 

I threw this in as a quickndirty impatient test:

insert into misc_user_opts 
(name,optorder,seclev,default_val,vals_regex,short_desc,long_desc,opts_html) 
values ('test',1,1,'no value','','Test data','Data for a test','');

When I hit users.pl it does show up as a radio box.

Slashdot seems to use it to control the OSDN Navbar:

<URL: http://slashdot.org/users.pl?op=editmiscopts >

I guess what I'm wondering is how is this different from users_params and the 
string_params -- ie:

<URL: http://www.lottadot.com/faqster.pl?op=view&faqid=2&section=software#q7 >

Thanks,
 Shane

[Slashcode-development] OT: mysqldump and auto_increment

[shane <sh...@lo...>]

Anyone know how to make mysqldump ignore the auto_increment field?

There's a mention from Sinisa Milivojevic from TcX saying that it was to be 
put on the TODO list - from 04/2000.

<URL: 
http://groups.google.com/groups?q=mysqldump+auto_increment&ie=ISO-8859-1&hl=en&btnG=Google+Search 
>


As far as I can tell, w/ mysql 4.x mysqldump doesn't yet have the cabability.

So... does anyone know how to do it?

Or is everyone, including OSDN, using a custom script to pull data out of the 
db to create dump files such as datadump.sql for themes?

Thanks,
 Shane

Re: [Slashcode-development] Problems getting user data

[shane <sh...@lo...>]

On Friday 18 July 2003 11:06, Christopher Winn wrote:
> Hi all,
>
> I'm relatively new to Slash and just recently getting back into Perl..
>
> Let's say I need more information to be stored with a user beyond things
> like their homepage, email, signature, etc.
>
> Let's say I want to add "State" information, or City.
>
> Well, I understand that you can simply add the fields to newUserForm or
> editUser, and the extra data will be saved into user_params.
>
> But how do I access the data thereafter?  I can get their homepage by using
> [% useredit.homepage %] -- but I certainly can't do [% useredit.state %] in
> the templates.
>
> Any help would be GREATLY appreciated.
>
> Chris.

It used to be that the code would save any extraneous form fields (that aren't 
in the schema) into the table users_param as a user param.

I used it a while back. Haven't for a while though.

I tried doing something similar yesterday:

<URL: http://www.lottadot.com/comments.pl?sid=35&cid=131 >

It doesn't seem to be working.

Anyone know if this functionality was taken out? Or is this a bug?

 Shane

[Slashcode-development] Problems getting user data

[Christopher W. <cc...@ps...>]

Hi all,

I'm relatively new to Slash and just recently getting back into Perl..

Let's say I need more information to be stored with a user beyond things like
their homepage, email, signature, etc.

Let's say I want to add "State" information, or City.

Well, I understand that you can simply add the fields to newUserForm or
editUser, and the extra data will be saved into user_params.

But how do I access the data thereafter?  I can get their homepage by using [%
useredit.homepage %] -- but I certainly can't do [% useredit.state %] in the
templates.

Any help would be GREATLY appreciated.

Chris.
-
Chris Winn
Penn State University
International Politics & German
AIM: cwinnpdc

RE: [Slashcode-development] Forced post previewing?

[Howell, M. <ho...@ra...>]

Here's how you would alter the behavior for your site:
(re-sending to include slashcode list)

1. Create a var called 'require_comment_preview' and give it a value of '1'

2. Edit template default;comments;edit_comments

  Change the lines that says:

  <INPUT TYPE="SUBMIT" NAME="op" VALUE="Submit">
  <INPUT TYPE="SUBMIT" NAME="op" VALUE="Preview">

  To say:

  [% IF !constants.require_comment_preview || form.op = "Preview" %]
  <INPUT TYPE="SUBMIT" NAME="op" VALUE="Submit">
  [% END %]
  <INPUT TYPE="SUBMIT" NAME="op" VALUE="Preview">

After those two mods, you'll be able to just change the
require_comment_preview var to '0' to disable this new feature.

I'm just shooting from the hip, here, and haven't actually looked at any
existing feature set.  The actual solution will depend on the version of
slashcode that you're using and any mods that you've already made.

Good luck,
-Mark

-----Original Message-----
From: Jeremy Morton [mailto:je...@ru...]
Sent: Wednesday, July 16, 2003 6:24 PM
To: sla...@li...
Subject: [Slashcode-development] Forced post previewing?


Hi.  I'm new to this list, but would like to suggest a very simple idea for
SLASH: forced post previewing.  All we need is a checkbox option added for
'forced post previewing'.  If this was checked, it would remove the 'Submit'
button from the initial post submit form, but leave it on the preview page.
Obviously, this would have the effect of requiring at least one preview
before posting, much like is required for submitting a story.  I think this
would be a very useful feature that I, amongst many other users, would like,
and it would improve the quality of many posts too.  Less typos!

BTW how many people are on this list?  I haven't received a *single* e-mail
yet!

Best regards,
Jez



-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Slashcode-development mailing list
Sla...@li...
https://lists.sourceforge.net/lists/listinfo/slashcode-development
[ALERT] -- Access Manager: This email is intended only for the person or
entity to which it is addressed and may contain information that is
privileged, confidential or otherwise protected from disclosure.
Dissemination, distribution or copying of this e-mail or the information
herein by anyone other than the intended recipient, or an employee or agent
responsible for delivering the message to the intended recipient, is
prohibited. If you have received this e-mail in error, please immediately
notify us by calling our North American Help Desk at (972)506-3939.

[Slashcode-development] Forced post previewing?

[Jeremy M. <je...@ru...>]

Hi.  I'm new to this list, but would like to suggest a very simple idea for
SLASH: forced post previewing.  All we need is a checkbox option added for
'forced post previewing'.  If this was checked, it would remove the 'Submit'
button from the initial post submit form, but leave it on the preview page.
Obviously, this would have the effect of requiring at least one preview
before posting, much like is required for submitting a story.  I think this
would be a very useful feature that I, amongst many other users, would like,
and it would improve the quality of many posts too.  Less typos!

BTW how many people are on this list?  I haven't received a *single* e-mail
yet!

Best regards,
Jez

Re: [Slashcode-development] release plan

[shane <sh...@lo...>]

On Friday 20 June 2003 11:47, Vl...@ge... wrote:
> August?!

I just picked a date a few months from now. It was a random thing - it's not 
based on anything - just to get the thought across.

>  The problem I see with that (as someone on the outside looking
> in) is the upgrade stuff. 

Well, I don't agree with you there. If you're waiting on an upgrade tool, then 
you wait. But there is absolutely nothing holding you back from upgrading 
now. The sql changes are in the upgrades file. It works. There's just a lot 
of work involved to do it.

> The T_ and R_ tags are,
> IM(NS)HO annoying, sure.  But, with tallented people like you submitting
> patches, and the team cranking out code on this, I think we can put up with
> it a while longer.  :-)

The t&r things are hard because to release something that's compatible with 
slash, that's relatively current, is hard, because there's been no point 
release (imho). That's the point I'm trying to get across.

And yes, maybe that's because I'm lazy, and not picking a T or R tag to code 
against to make a release. I fully conceed that - it'd just easier if there 
were a release planned sometime for this year.

 Shane

RE: [Slashcode-development] release plan

[<Vl...@ge...>]

August?!  The problem I see with that (as someone on the outside looking in)
is the upgrade stuff.  Not only is that a short period of time to declare a
feature freeze, fix all outstanding bugs, and what not, but the upgrade
stuff isn't ready yet from what I understand.  Sure, it would be nice to
have a 2.2.7, or a 2.4.0, but at the rate slash is evolving, it might be
more like 3.0 in December or next year.  The T_ and R_ tags are, IM(NS)HO
annoying, sure.  But, with tallented people like you submitting patches, and
the team cranking out code on this, I think we can put up with it a while
longer.  :-)

Scott

--

 /"\                         / For information and quotes, email us at
 \ /  ASCII RIBBON CAMPAIGN / in...@lr...
  X   AGAINST HTML MAIL    / http://www.lrsehosting.com/
 / \  AND POSTINGS        / vl...@lr...
-------------------------------------------------------------------------

> -----Original Message-----
> From: sla...@li...
> [mailto:sla...@li...]On Behalf Of
> shane
> Sent: Friday, June 20, 2003 7:24 AM
> To: sla...@li...
> Subject: [Slashcode-development] release plan
>
>
> What's OSDN's plans for releasing Slash?
>
> Will we ever see a 2.2.7 or 2.3?
>
> Is the plan to 'go by cvs' for the forseeable future?
>
> I ask because it is extremely hard to tell people, that
> inorder to use a
> plugin, they need to be using CVS. Is that CVS from this
> morning? yesterday?
> 5 days ago? 3 months?
>
> Yes, I understand about T_ tags, and R_tags. I've used both.
> The point I want
> to make is that with 'going by cvs' seemingly being the way
> it'll be for a
> while, it makes it really hard to release a plugin that is
> compatible with
> current slash - unless you go by 2.2.6 or a T or R tag. (and
> people don't
> always seem to understand the tagging, and/or take the time
> to read the
> information that's out there about how t_ and r_ tags are used).
>
> Personally, it would be far easier for me if it were decided,
> and released,
> that the next version will be 2.2.7 and you'll try to put it
> out in august.
> Atleast that way we can release code that's compatible with
> it. Releasing
> code that works with 2.2.6... well, that's almost over a year old now.
>
> I don't want to rile any feathers, just find out what the
> plan of attack is.
>
> Thanks,
>  Shane
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU
> Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly
> Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Slashcode-development mailing list
> Sla...@li...
> https://lists.sourceforge.net/lists/listinfo/slashcode-development
>

[Slashcode-development] release plan

[shane <sh...@lo...>]

What's OSDN's plans for releasing Slash?

Will we ever see a 2.2.7 or 2.3?

Is the plan to 'go by cvs' for the forseeable future?

I ask because it is extremely hard to tell people, that inorder to use a 
plugin, they need to be using CVS. Is that CVS from this morning? yesterday? 
5 days ago? 3 months?

Yes, I understand about T_ tags, and R_tags. I've used both. The point I want 
to make is that with 'going by cvs' seemingly being the way it'll be for a 
while, it makes it really hard to release a plugin that is compatible with 
current slash - unless you go by 2.2.6 or a T or R tag. (and people don't 
always seem to understand the tagging, and/or take the time to read the 
information that's out there about how t_ and r_ tags are used).

Personally, it would be far easier for me if it were decided, and released, 
that the next version will be 2.2.7 and you'll try to put it out in august. 
Atleast that way we can release code that's compatible with it. Releasing 
code that works with 2.2.6... well, that's almost over a year old now.

I don't want to rile any feathers, just find out what the plan of attack is.

Thanks,
 Shane

[Slashcode-development] databases

[shane <sh...@lo...>]

got a coding question - what's the logic that's generally used for when the 
'reader' db is used instead of normally calling either the var pointing to 
the db (generally $slashdb) or in the case of a plugin $someplugindbname).

and is it generally wanted that we put code into our code for slash such that 
it'll use the reader db, if defined?

Just curious. I've seen the code now in slash countless times, but don't 
recall any discussion of it.

thanks,
 shane

RE: [Slashcode-development] Running multiple Slash versions on a single box

[Howell, M. <ho...@ra...>]

To make this work, I modified my build process as such:

1. I created a directory named /usr/local/slashVERSION/perl

2. I created a build script that runs (from the slash source directory):
$ make install PREFIX=/usr/local/slashVERSION/perl
SLASH_PREFIX=/usr/local/slashVERSION

This will make the build process install perl modules into the
/usr/local/slashVERSION/perl directory.  Each subsequent site that I have
from a different source code version will have it's own value for VERSION
and thus, it's own set of Slash perl modules.

3. I modified each Apache startup script to contain the following line:
PERL5LIB="/usr/local/slashVERSION/perl/lib/perl5/site_perl/5.6.1"

Unfortunately, mod_perl will only load the first instance of a module found
in @INC, and there is no way to separate different versions of Slash from
within the same instance.  I toyed around with the 'only' module, but that
was not the solution that I was looking for.  Therefore, in order to run
multiple versions of Slash, there must be multiple instances of
Apache/mod_perl running, one for each version.



My conclusions are based on findings from the perl faq.

In perlfaq8 (see: 'man perlfaq8'), near the bottom, I found:

  How do I keep my own module/library directory?

       When you build modules, use the PREFIX option when generating
Makefiles:

           perl Makefile.PL PREFIX=/u/mydir/perl

       then either set the PERL5LIB environment variable before you run
scripts that
       use the modules/libraries (see the perlrun manpage) or say

           use lib '/u/mydir/perl';

       This is almost the same as

           BEGIN {
               unshift(@INC, '/u/mydir/perl');
           }

       except that the lib module checks for machine-dependent
subdirectories.  See
       Perl's the lib manpage for more information.

  How do I add the directory my program lives in to the module/library
search
  path?

           use FindBin;
           use lib "$FindBin::Bin";
           use your_own_modules;

  How do I add a directory to my include path at runtime?

       Here are the suggested ways of modifying your include path:

           the PERLLIB environment variable
           the PERL5LIB environment variable
           the perl -Idir command line flag
           the use lib pragma, as in
               use lib "$ENV{HOME}/myown_perllib";

       The latter is particularly useful because it knows about machine
dependent
       architectures.  The lib.pm pragmatic module was first included with
the 5.002
       release of Perl.



So far, both sites appear to be running fine.

-Mark

-----Original Message-----
From: Vl...@ge... [mailto:vl...@ge...]
Sent: Thursday, May 01, 2003 7:18 PM
To: Howell, Mark
Subject: RE: [Slashcode-development] Running multiple Slash versions on
a single box



> -----Original Message-----
> From: sla...@li...
> [mailto:sla...@li...]On Behalf Of
> Howell, Mark
> Sent: Thursday, May 01, 2003 2:29 PM
> To: sla...@li...
> Subject: [Slashcode-development] Running multiple Slash versions on a
> single box
>
>
> Hello All,
>
> I am attempting to install and run multiple versions of
> Slashcode on the
> same machine.


Good luck.  I for one do not believe this can be done.  We have just 2
versions of perl on our box, and have a large number of problems as a result
(Psst!  Jamie, are you still willing to log in and look at that for us?  :-)
and are trying to get down to JUST the version that slash is supposed to be
using.

I think the only way you could really do this would be to jail perl, apache,
mysql, etc - in short, you'd have to waste a BOAT LOAD of space for each
site.

Scott



--

 /"\                         / For information and quotes, email us at
 \ /  ASCII RIBBON CAMPAIGN / in...@lr...
  X   AGAINST HTML MAIL    / http://www.lrsehosting.com/
 / \  AND POSTINGS        / vl...@lr...
-------------------------------------------------------------------------

[ALERT] -- Access Manager: This email is intended only for the person or
entity to which it is addressed and may contain information that is
privileged, confidential or otherwise protected from disclosure.
Dissemination, distribution or copying of this e-mail or the information
herein by anyone other than the intended recipient, or an employee or agent
responsible for delivering the message to the intended recipient, is
prohibited. If you have received this e-mail in error, please immediately
notify us by calling our North American Help Desk at (972)506-3939.

[Slashcode-development] Error in Humanconf under latest T tag (T_2_3_0_92)

[<Vl...@ge...>]

Anyone else have this problem?  We've updated to the latest T tag.

Mon May  5 20:40:14 2003 hc_maintain_pool.pl begin (4324)
Error in
library:main:/usr/local/slash/site/geekizoid.com/tasks/hc_maintain_pool.pl:1
8:Can't locate GD.pm in @INC (@INC contains:
/usr/local/lib/perl5/5.8.0/i386-freebsd /usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd
/usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl/5.005 /usr/local/lib/perl5/site_perl .) at
/usr/local/lib/perl5/site_perl/5.8.0/Slash/HumanConf/Static.pm line 11.
BEGIN failed--compilation aborted at
/usr/local/lib/perl5/site_perl/5.8.0/Slash/HumanConf/Static.pm line 11.
Compilation failed in require at (eval 67) line 3.

Which was called by:main:/usr/local/slash/sbin/slashd:745:Can't locate GD.pm
in @INC (@INC contains: /usr/local/lib/perl5/5.8.0/i386-freebsd
/usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i386-freebsd
/usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl/5.005 /usr/local/lib/perl5/site_perl .) at
/usr/local/lib/perl5/site_perl/5.8.0/Slash/HumanConf/Static.pm line 11.
BEGIN failed--compilation aborted at
/usr/local/lib/perl5/site_perl/5.8.0/Slash/HumanConf/Static.pm line 11.
Compilation failed in require at (eval 67) line 3.

Mon May  5 20:40:14 2003 hc_maintain_pool.pl: could not instantiate
Slash::HumanConf::Static object, is GD.pm properly installed?
Mon May  5 20:40:14 2003 hc_maintain_pool.pl end (4324) (2.76s;
message_delivery.pl 14s late)

--

 /"\                         / For information and quotes, email us at
 \ /  ASCII RIBBON CAMPAIGN / in...@lr...
  X   AGAINST HTML MAIL    / http://www.lrsehosting.com/
 / \  AND POSTINGS        / vl...@lr...
-------------------------------------------------------------------------

[Slashcode-development] Running multiple Slash versions on a single box

[Howell, M. <ho...@ra...>]

Hello All,

I am attempting to install and run multiple versions of Slashcode on the
same machine.  I'm finding that different versions of various perl modules
are in conflict when I do a build, and the most recently built slash source
tree is the only one that works.  Does anybody else run multiple versions of
Slash or have any idea how to deal with these multiple versions of perl
modules?

My current strategy is:

Alter Makefiles to place newly built perl modules into a completely separate
directory.
Alter mod_perl and apache so that they look in this directory for the
modules that they want to use.
Change the #!/bin/perl -w to be #!/bin/perl -I /path/to/mods -w in every
*.pl file.

Is this feasible or practical?  Does anybody have a better way?

Any help would be greatly appreciated,
-Mark
(oh, please pardon the corporate panic block that automatically follows this
message)

[ALERT] -- Access Manager: This email is intended only for the person or
entity to which it is addressed and may contain information that is
privileged, confidential or otherwise protected from disclosure.
Dissemination, distribution or copying of this e-mail or the information
herein by anyone other than the intended recipient, or an employee or agent
responsible for delivering the message to the intended recipient, is
prohibited. If you have received this e-mail in error, please immediately
notify us by calling our North American Help Desk at (972)506-3939.