04-14-2020
Update:
This migration is moving along. @Scrutinizer has been a great help with debugging the bbcode migration, writing Ruby methods to preprocess various bbcode situations which arise in the conversion to markdown.
For examples:
There was some newlines being added to code blocks, so we added some post-processing REGEX search and replace to tidy these up. This was a purely cosmetic change but @Scrutinizer is more annoyed by these cosmetic details than me, and so he wrote some Ruby code to fix it. We are very fortunately to have @Scrutinizer working with me on this.
The same is true for some "bbcode abuse" where in the past over the years, some people copy-and-pasted some bbcode into the forum or others just loved bbcode so much the embedded bbcode everywhere, sometimes nesting bbcode is strange ways. We have also slayed most of those dragons.
We are getting very close. We cannot promise 100% of every possible combination of bbcode-mangles in the vB3 forum will be perfect, but it will be very good, a few orders of magnitude from the initial release, hands down.
Currently I am rebaking all the post again on the staging server. That is a process which takes 12 to 14 hours. For those who may not be familiar with this, here is a short summary:
The vB3 forum (indeed most, if not all, LAMP-based forums) process(es) the pagetext in the database on the fly (when the page is summoned by the client, e.g. the web browser).
However, Discourse stores the pagetext as "raw" and then it cooks the raw into HTML to be rendered. This of course makes the site faster since the code is already rendered and stored in the DB "cooked".
The downside to this, of course, is that it takes longer to "cook all this" during migration testing (reprocessing the raw for bbcode mangling); but lucky for us, after migration is done, it's done.
BTW, this is the same way I serve our forumman pages. Man pages are also cooked and the cooked pages are stored in the DB to make them render faster, so this technique is nothing new.
OBTW, those man pages will stay here in the legacy vB3 forums; until we decide if and/or when to write a plugin to port these to discourse.
That's it for now.
This User Gave Thanks to Neo For This Post:
6 More Discussions You Might Find Interesting
1. Shell Programming and Scripting
Hi All,
We will be doing a Solaris 8 to Solaris 10 migration migration, just wanted to know if there are any known / common issues arise from this migration from Shell script point of view.
I tried searching this site but mostly post are related to SA's question and jumpstart, etc. If there's... (4 Replies)
Discussion started by: arvindcgi
4 Replies
2. HP-UX
All,
We are migrating an application from HP-UX B.11.00 to HP-UX B.11.31 and both of them have the same informix version - 7.25se. However the compilers are different on both servers.
HP-UX B.11.00 - has B3913DB C.03.33 HP aC++ Compiler (S800)
HP-UX B.11.31 - has PHSS_40631 1.0 HP C/aC++... (2 Replies)
Discussion started by: helper
2 Replies
3. Programming
Dear Team
I am using DB2 v10 z/os database . Need expert guidance to figure out best way to track table activities ( Ex Delete, Insert,Update )
Scenario
We have a table which is critical and many developer/testing team access on daily basis . We had instance where some deleted... (1 Reply)
Discussion started by: Perlbaby
1 Replies
4. What is on Your Mind?
First a bit of history ....
A number of years ago one of our admins built a number of plugin systems for moderation, including (1) a voting system, (2) a "user feelings" system and (3) a confidential posting system. During this time, I was busy on other projects, not very active in the forums,... (1 Reply)
Discussion started by: Neo
1 Replies
5. What is on Your Mind?
OK.
Like we all do, we learn a lot from tests, test migrations, and so forth.
Today, I started from scratch on test migration 2, armed with a lot more knowledge,
The main differences are as follows:
Installed discourse plugin ruby-bbcode-to-md before starting the install
Modified... (30 Replies)
Discussion started by: Neo
30 Replies
6. What is on Your Mind?
Test Build 4 on New Server, with changes identified in discourse test builds 2 and 3, primarily:
Insuring ruby-bbcode-to-markdown is enabled.
Removing line breaks from ICODE to markdown in migration script.
Added vbpostid to posts in discourse to setup migrating vb "thanks" to discourse... (28 Replies)
Discussion started by: Neo
28 Replies
LEARN ABOUT DEBIAN
bio::tools::gel
Bio::Tools::Gel(3pm) User Contributed Perl Documentation Bio::Tools::Gel(3pm)
NAME
Bio::Tools::Gel - Calculates relative electrophoretic migration distances
SYNOPSIS
use Bio::PrimarySeq;
use Bio::Restriction::Analysis;
use Bio::Tools::Gel;
# get a sequence
my $d = 'AAAAAAAAAGAATTCTTTTTTTTTTTTTTGAATTCGGGGGGGGGGGGGGGGGGGG';
my $seq1 = Bio::Seq->new(-id=>'groundhog day',-seq=>$d);
# cut it with an enzyme
my $ra=Bio::Restriction::Analysis->new(-seq=>$seq1);
@cuts = $ra->fragments('EcoRI'), 3;
# analyse the fragments in a gel
my $gel = Bio::Tools::Gel->new(-seq=>@cuts,-dilate=>10);
my %bands = $gel->bands;
foreach my $band (sort {$b <=> $a} keys %bands){
print $band," ", sprintf("%.1f", $bands{$band}),"
";
}
#prints:
#20 27.0
#25 26.0
#10 30.0
DESCRIPTION
This takes a set of sequences or Bio::Seq objects, and calculates their respective migration distances using:
distance = dilation * (4 - log10(length(dna));
Source: Molecular Cloning, a Laboratory Manual. Sambrook, Fritsch, Maniatis. CSHL Press, 1989.
Bio::Tools::Gel currently calculates migration distances based solely on the length of the nucleotide sequence. Secondary or tertiary
structure, curvature, and other biophysical attributes of a sequence are currently not considered. Polypeptide migration is currently not
supported.
FEEDBACK
Mailing Lists
User feedback is an integral part of the evolution of this and other Bioperl modules. Send your comments and suggestions preferably to the
Bioperl mailing list. Your participation is much appreciated.
bioperl-l@bioperl.org - General discussion
http://bioperl.org/wiki/Mailing_lists - About the mailing lists
Support
Please direct usage questions or support issues to the mailing list:
bioperl-l@bioperl.org
rather than to the module maintainer directly. Many experienced and reponsive experts will be able look at the problem and quickly address
it. Please include a thorough description of the problem with code and data examples if at all possible.
Reporting Bugs
Report bugs to the Bioperl bug tracking system to help us keep track of the bugs and their resolution. Bug reports can be submitted via the
web:
https://redmine.open-bio.org/projects/bioperl/
AUTHOR - Allen Day
Email allenday@ucla.edu
APPENDIX
The rest of the documentation details each of the object methods. Internal methods are usually preceded with a _
new
Title : new
Usage : my $gel = Bio::Tools::Gel->new(-seq => $sequence,-dilate => 3);
Function: Initializes a new Gel
Returns : Bio::Tools::Gel
Args : -seq => Bio::Seq(s), scalar(s) or list of either/both
(default: none)
-dilate => Expand band migration distances (default: 1)
add_band
Title : add_band
Usage : $gel->add_band($seq);
Function: Calls _add_band with a (possibly created) Bio::Seq object.
Returns :
Args : Bio::Seq, scalar sequence, or list of either/both.
_add_band
Title : _add_band
Usage : $gel->_add_band($seq);
Function: Adds a new band to the gel.
Returns :
Args : Bio::Seq object
dilate
Title : dilate
Usage : $gel->dilate(1);
Function: Sets/retrieves the dilation factor.
Returns : dilation factor
Args : Float or none
bands
Title : bands
Usage : $gel->bands;
Function: Calculates migration distances of sequences.
Returns : hash of (seq_id => distance)
Args :
log10
Title : log10
Usage : log10($n);
Function: returns base 10 log of $n.
Returns : float
Args : float
perl v5.14.2 2012-03-02 Bio::Tools::Gel(3pm)