Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Inner Scriptorium

( #389873=superdoc: print w/ replies, xml ) Need Help??

This section is used by the Cabal in plotting improvements to the inner workings of the Monastery's raw sewage macerator, boiler room, nuclear reactor, and cold fusion pump. Cabal only may post root nodes to this section. But fresh thought often spawns progress, so any Perl Monk may add comments to existing discussion threads within this section.

Please remember that Monastery related discussions of global interest to the general PerlMonks population should be entertained in the Perl Monks Discussion section. gods can and will remove off-topic content from the Inner Scriptorium.

Inner Scriptorium
old development version of perlmonks still online
1 direct reply — Read more / Contribute
by LanX
on Sep 20, 2015 at 07:36

    a google search for another monk led me to a profile page saying he hasn't been here for more than 7 years!?!

    After investigating the URL (which I hesitate to disclosure here) I realized that this must be a development version of the monastery accessing an old DB instance.

    Changing the topdomain produced different results, sometimes I had to change to index.cgi, sometimes I was able to read the scripts source, sometimes got just 404s for links which worked before and vice versa.

    Not sure if this might be related to my privileges ...

    I think either this has to be taken offline or password protected, in any case it shouldn't be indexed by google.

    Cheers Rolf
    (addicted to the Perl Programming Language and ☆☆☆☆ :)
    Je suis Charlie!


    this post was initially written for PMD, till I found this pmdevtopic board.

    I think it should be safe to post links here

    links deleted

    if you are getting errors, please try to switch to .com or .net or change .pl to .cgi, it seems like different servers in the background react inconsistently.


    ) why is this branch called "inner scriptorium" but publicly readable? I deleted the links again, google didn't cache them yet.

Define "On Topic" for the Monastery
6 direct replies — Read more / Contribute
by jdporter
on Jul 17, 2015 at 15:28

    There's been a fair amount of discussion lately about how to designate off-topic posts (i.e. whether to set up a separate section for them, or not). (I think a good place to start getting familiar with the subject is here.)

    The implicit underpinning of these discussions is what "off topic" means at PerlMonks. Indeed, part of the difficulty in arriving at a solution of which a plurality of monks would approve is that "off topic" is not well defined, and seems to mean different things in different contexts. I am starting to think it might be a good idea, then, to establish definitions for the following:

    1. What is so far off topic for PerlMonks that it simply won't be acceptable? A post that is beyond this pale would be reaped, or possibly moved to the offtopicroot "section". (Note: not a section.)
    2. What is off-topic enough to warrant not being approved into a section?
    3. What is off-topic enough to warrant being designated (labeled, binned, etc.) as "OT"?
    4. And indeed, what is the relative "severity" of the latter two criteria?

    These definitions would be documented for all to see, and in particular would be incorporated into the Janitors' Guidelines, as well as the moderation and consideration guidelines.

    Question #1 is: Do we agree that having something written down would be a good idea? I get a vague feeling that the answer to this question, historically, was "No". But it could just be that we never got around to it...

    I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
Considerations History
1 direct reply — Read more / Contribute
by jdporter
on Jul 07, 2015 at 11:31

    Is there a complete log of consideration events anywhere? By complete, I mean including the logging of events such as unconsideration. I don't know of any such; and what that means is that if a monk puts on a consideration, and then a janitor removes it, there is no trace of that consideration at all anywhere. Am I just missing something? Thanks...

    I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
E2 site code about to take an incompatible change
No replies — Read more | Post response
by JayBonci
on Sep 28, 2012 at 11:04
    Hey monks,

    Over at E2, we are about to take what is going to be an very incompatible change and forever move away from Perlmonks: we're going to be getting rid of the $VARS hash, and replacing it with a $DB->getNodeParam($NODE, "paramname") type setup where we have a large, indexed key-value store for each node. We'll be caching the contents of the vars in the nodeCache, but the goal is to not have to rewrite $VARS every time, and to be able to expand the code so that any type of node can have a key/value parameter.

    The goal is to move some non-index-needing, non-primary columns over to it, and be able to add arbitrary metadata to any type of node, without having to muck with types and database schemas. If you guys are interested in syncing up, drop me an email or a message here, and we'll try and figure out what our engine deltas look like. In ecore terms, it is like every node would virtually join on setting.

    I'd like to continue to be on the same rough engine branch, and be able to share performance improvements with you guys, but it's going to require a bit of engineering work.

    Also, we've had some great success moving to AWS, so if you're thinking about picking up stakes and moving anywhere, please let me know and i'll have happy to share my recipes and practices getting E2 up and cooking on a modern web platform. Having S3 and RDS available has been a huge boon for our performance. I don't know what the state of the site is now that Perl foundation has it.

refactor newlistapproved to absorb newmoderatelist
2 direct replies — Read more / Contribute
by jdporter
on Jul 13, 2012 at 09:31

    Update: The below has been done. You may disregard. :-)

    If you take a look at the code of each of the sections, you'll see a fairly common pattern. SoPW is the canonical case; it looks like this:

    [{get_sitedoclet}] [{votehead}] [{newlistapproved:perlquestion,perlquestion approved linktype,User Que +stions,10,navbaron,showunapproved}] [{votefoot}] [{newmoderatelist:perlquestion,perlquestion approved linktype,Unapprov +ed Questions}] [{addnewform:perlquestion,Add your question,Your question:}]

    Examining newlistapproved and newmoderatelist, we find that the latter is logically a part of the former, but it seems to have been split out merely in order to "jump over" a call to votefoot.

    I propose merging the code of newmoderatelist back into newlistapproved, and add an option parameter which would tell newlistapproved whether to call votefoot at the appropriate point. There is already an option parameter, showunapproved, which controls whether to show the unapproved list.

    In order to grasp all the ramifications across the site, I prepared the following table, which summarizes the code of each place newlistapproved is currently used (excluding test nodes and such).

    Table is presented in a reply below.

    Based on this data, I believe this change would be safe and straightforward to make. The only real oddball we'd have to worry about is Editor Requests, but I think we could handle that.

    I think this change will make the code simpler, but perhaps more importantly, more efficient. The overhead cost of calling an htmlcode is substantial. It includes the cost of (a) retrieving the node from the database, and (b) executing a perl eval.

    I reckon we are the only monastery ever to have a dungeon stuffed with 16000 zombies.
Github repo up, bootstrap partially working
1 direct reply — Read more / Contribute
by JayBonci
on Mar 18, 2012 at 20:31
    Hey everybody, I've put together some basic utilities to bootstrap a raw perlmonks from the XML available here on the server. It'll improve as patches get applied to correct missing pieces and as more people take a look at it. I've got a wider goal to unify the codebase with E2, and so that the improvements we are making over there can wash back with you guys.
    What's working:
    • vagrant up, environment similar to E2, based on squeeze and perl 5.10
    • Bootstrap, however lots of server errors on the page (go to http://localhost:8888/?node=Login once it is up).
    What's missing:
    • Pieces to generate cachedgates.html
    • A few needed dependency modules need to be added to the chef recipes. I saw one, but forgot to jot it down. I'll add it once we work through a few of the errors.
    • The script stupidly scrapes Node Lister for every category, because it's a dumb comparion. Also, my username is hardcoded in.

    Going forward, I'd like to know how the administration would like to handle patches to the core libraries. I've made two small ones to Everything::NodeBase to handle conditions that won't come up in production, only bootstrapping, but after we're settled and bootstrappable w/o errors, I'm going to see what we can do to merge the codebases, and move forward.

    As a note, the vagrant environment is VERY convenient for Devel::NYTProf and Apache::DB so it makes really digging into the code quite easy. Happy hacking!

Everything2 github repository and being of value to perlmonks
2 direct replies — Read more / Contribute
by JayBonci
on Feb 21, 2012 at 14:47
    Hey folks,

    Some of you may or may not remember me, but I'm Jay Bonci, a longtime perlmonks semi-lurker, and the new owner of Everything2, the PM sister-site. Even though it diverged a long time ago, I'm hoping that things are still similar enough I'm back around actively developing and improving the core engine underneath E2 with a huge push to clean up a lot of old practices and bring the code forward to the modern era. I'd love to see if Perlmonks can get some use out of the tools that we're developing.

    I've got a somewhat active repository going at github with our tools. Looking ahead to where I'd like to be:

    • The development community should be developing inside of a bootstrapped sandbox machine running inside of a Vagrant virtual machine. This allows us to develop Chef recipes for box deployment as well
    • Nodes are stored in git(hub) as XML with export, and are instantiated with import (or bootstrap). This allows for a sanitized environment and source control of the underlying nodes
    • We're working towards compilation of the underlying htmlcodes, containers, htmlpages, opcodes, superdocs, etc that run the site and I've developed an execution environment using some symbol table muckery to make it think that it's running inside of Everything::HTML. This is going to reduce our apache footprint and our database load pretty significantly. It also allows for Devel::NYTProf to not get lost inside of evals

    I'd be greatly interested in working with the PM staff to see what tools you can can lift or vice versa. Check out the github repository and message me here or over email on my homenode. The goal is to rapidly improve our body of in-database software and to get out of the performance bottlenecks that are increasing how much it costs to run the site (or conversely, how much capacity we get out of our current hardware).

Context-Sensitive Rejection
No replies — Read more | Post response
by jdporter
on Jul 20, 2011 at 10:04

    Idea: Let the Permission Denied page contain information on the node you're not allowed to see.

    In particular, I want the page to display the sitedoclet associated with the denied node, if any. This will be useful to SiteDocClan as it will facilitate the maintenance of sitedoclets associated with nodes they're not allowed to "run". A well-written sitedoclet might also allay some of the confusion to which newbies are heir, when they hit a forbidden page.

    Technical Implementation

    The code of Permission Denied needs to know which node the user requested and was rejected. Currently, that information is lost (afaict) as soon as the engine decides to redirect to Permission Denied. Therefore, I propose the following patch in order to preserve that info:

    In Everything/, insert the following line before line 1408:

    $HTMLVARS{requested_node} = $NODE;

    When this has been done, the Permission Denied - (patch) can be applied.

    Update: Done!

    I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
RFC: brig
3 direct replies — Read more / Contribute
by jdporter
on Jul 15, 2011 at 17:33

    You know how being /borged prevents one from talking in the cb but doesn't prohibit one from posting... I'm thinking we maybe could use an op of the opposite behavior as well — preventing one from posting (or editing their already-posted nodes), but not stopping them from talking in the cb. (I'd call it the "brig".) Seems to me we could have used this recently. Instead, an all-or-nothing solution was used, and that in turn drove the aggrieved monk to create a new account. What say ye?

    I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
"New XP" may report at inappropriate times
2 direct replies — Read more / Contribute
by davido
on Jul 11, 2011 at 23:57

    Update: Please see the update at the bottom. I think I was mistaken in assessing my observation.

    It's probably been this way for awhile, but I've been wondering why when a person gains XP the notification message in the XP Nodelet sometimes may report the new XP gain several times in a row before the message stops showing up.

    Here is the relevant code, I think:

    1: my( $shownumbers )= @_; 2: # send FALSE if you want people to see gain/loss w/o exact numbe +rs 3: 4: return "" 5: if getId($USER) eq $HTMLVARS{default_user}; 6: 7: my $curexp= $USER->{experience}; 8: my $oldexp= $VARS->{oldexp}; 9: $oldexp= $curexp 10: if ! defined $oldexp; 11: my $difexp= $curexp - $oldexp; 12: $VARS->{oldexp}= $curexp; 13: return "" 14: if 0 == $difexp; ....... lots more below dealing with quips.

    It seems that the desired behavior is to have a new XP gain reported exactly one time, not several. I can't prove that it's not just a matter of being upvoted several times, but my feeling that the upvote clusers don't fit my posting habits. For example, maybe I've gone several days between new posts. When I come back to PerlMonks, I find 6xp added. Then upon hitting, "Newest Nodes" or "Talk", I get the same six-point report. It's unlikely in that event that I really gained 6 over the course of a couple days, and then six in the matter of a few seconds again..

    I don't want to put out a theory as to why it's happening in the absence of solid evidence, but it seems that $VARS->{oldexp}= $curexp; is taking several reloads to propagate to all the servers.

    I guess I would be looking for confirmation that (1) There is a problem, ie, the behavior is as I describe: That the first two reloads (even via 'talk button') sometimes fail to clear the New XP message by setting $VARS{oldxp}=$curxp, and (2) That it's supposed to work as I expect: The report is supposed to show only once. A third question would be what possibilities exist as to why it's happening.

    Update: Now that I finally gather the courage to suggest there might be a problem I find it impossible to duplicate the behavior I thought was happening. So perhaps $VARS->{oldexp}= $curexp; is doing exactly what it ought to, and I've been incorrect in my casual observation of the anecdotal evidence I thought was supporting my hunch. ;)


Log In?

What's my password?
Create A New User
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (4)
As of 2015-11-25 06:27 GMT
Find Nodes?
    Voting Booth?

    What would be the most significant thing to happen if a rope (or wire) tied the Earth and the Moon together?

    Results (671 votes), past polls