Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

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
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.

    https://github.com/perlmonks/perlmonks.
    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 pmscrape.pl 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!


        --jaybonci
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 ecoretool.pl export, and are instantiated with ecoretool.pl 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).



        --jaybonci
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/HTML.pm, 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. ;)


    Dave

bringing nodelets out of the shed
No replies — Read more | Post response
by jdporter
on Jan 18, 2011 at 10:50

    Thinking about how to blur the distinction between nodelets and regular nodes, so that you could, for example — theoretically — embed a regular node into your page like a nodelet, or — more practically — view a nodelet as a standalone ("regular") node.

    Nodelets are special in the following ways:

    • they have a designated "container", which is essentially HTML template code which gets wrapped around the nodelet's contents at display time;
    • they have the concept of periodic updating, with caching of contents in between updates.
    • they can be selectable for inclusion in your list of displayed nodelets.

    Aside from that, they are essentially superdocs: documents which can contain code for performing various functions. There is no technical reason why a nodelet could not be viewed standalone, just like any other superdoc.

    Therefore, as a proof of concept, I created nodelet view page, a displaypage which does exactly that. To try it, view any nodelet and add ;displaytype=view to the URL. For example, your XP Nodelet.

    It works. However, there are obviously some caveats. For example, viewing your Free Nodelet in this way is likely to cause mayhem if you have any javascript going on in it.

    Now, if we can get this code to be ready for prime time, I would recommend making this the default view for nodelets, and migrating the current default view into the viewcode htmlpage. That is:

    1. rename nodelet display page as nodelet viewcode page, then
    2. rename nodelet view page as nodelet display page.

    Then a pmdev simply clicks on the "code" link which will appear at the top of the nodelet display page to get to a point where its code can be examined/patched.

    One further kewlosity: add /bare/ to the path part of the URL to get a nifty little ticker-like form (html, not xml) of any given nodelet. Example: your XP Nodelet. (It's not really a ticker; it doesn't auto-refresh.)

    I also have a patch (expandfreenodelet - (patch)) for embedding any given nodelet's contents into your Free Nodelet. I'd like to know if this might have potential problems. It seems like a cool idea to me.

    What is the sound of Windows? Is it not the sound of a wall upon which people have smashed their heads... all the way through?
Password shtuff
1 direct reply — Read more / Contribute
by ysth
on Dec 30, 2010 at 14:55
    Rough notes on a chatterbox discussion.

    How about md5 crypts instead of password in the cookie? That would allow passwords > 8 chars (with a user table change).

    md5 may be too CPU expensive; needs to be tested.

    An md5 crypt certainly takes more time than a des crypt: one some machine the md5 crypt seems to take 5e-4 second, the des takes 1.3e-5 seconds.

    (comments about $3$/NT-hash)

    Instead of comparing hashed password in cookie to hash of clear password in database, store the hashed password in the database and the non-salt part of it in the cookie; authenticate cookies via string compare.

    Later, unhashed password will be eliminated.

    update user edit page to require the previous password in order to change the password

    have a real "password reset e-mail" feature

    --
    A math joke: r = | |csc(θ)|+|sec(θ)|-||csc(θ)|-|sec(θ)|| |
    Online Fortune Cookie Search
New pmdev-only documentation infrastructure
4 direct replies — Read more / Contribute
by jdporter
on Dec 03, 2010 at 13:01

    Following up on previous thread Pmdev documentation...

    I've been cogitating a bunch upon this idea of using sitedoclets to document code, i.e. infrastructure nodes.

    Currently, sitedoclets can be attached to infrastructure nodes of the following types:

            Update '10/12/22; see below

    Anyway, I've come up with what I think is a pretty good idea, so I'd like to run it by you all, see what you think.

    My idea essentially is this: have a new nodetype, devdoclet, which would be used to document the purpose and usage of infrastructure nodes. In particular, it would be a great place to note the status of nodes such as dead, live, experimental, and not-yet-live htmlcodes .

    devdoclet is like sitedoclet in most ways, except that,

    1. It is owned (creatable, editable) by pmdev rather than SiteDocClan, and would not be intended for general public consumption.
    2. More importantly — there is an explicit policy which supports bi-directional links, implicitly by title, between an infrastructure node and its devdoclet.

    That is, the doclet for (say) parselinksinchatter is necessarily parselinksinchatter devdoclet. (It would therefore be slightly different from the sitedoclet situation, where this nomenclature is conventional but not universal nor enforced.)

    This enables certain very convenient things — most obviously, that a pmdevil can navigate from a devdoclet to its associated code node simply by stripping off the " devdoclet" part of the title. (Of course, we'd automate this for you by means of a link in your pmdev nodelet.)

    I also envision a structure, perhaps somewhat like the sitefaqlet/faqlist nested-listy thing, for knitting all the devdoclets into a whole "site infrastructure document"... as touched on in the earlier thread. And note that it would also be possible to make devdoclets which are not linked to specific infrastructure nodes; these could be used to document overarching concepts and like such as.

    Thanks...

    What is the sound of Windows? Is it not the sound of a wall upon which people have smashed their heads... all the way through?
Dup Nodes/Server Glitches?
2 direct replies — Read more / Contribute
by ww
on Mar 17, 2010 at 07:32
    Server glitches implicated in some dup posts? hasn't attracted much comment in the thread itself, but /me has received several private replies which seem to support the hypothesis therein.

    In brief, my notion is that one symptom/by-product/whatever occuring when pm is overloaded/slowed-for-whatever-reason, users tend to experience inadvertent creation of dup posts.

    Perhaps this note will intrigue a more highly skilled dev to confirm (and fix?) or refute my suspicion.

Create new [pmdev]-only section "Pmdev Discussion"
2 direct replies — Read more / Contribute
by jdporter
on Aug 21, 2009 at 17:25

    The idea would be to create a section, rather like Perl Monks Discussion, but which would be accessible (both read and write) only to pmdev, for the purpose of discussing ... well, anything pmdev wants to discuss internally. This is to get away from using the wiki for such discussions, since — as has been pointed out on several occasions — wikis are not a good medium for discussion. Looking at the history of wiki rollovers, it's clear that a lot more has gone on in the pmdev wiki than any other, and undoubtedly most of that volume was for discussions.

    What do y'all think of this idea?

    It would be pretty easy to do. The steps involved would be as follows:

    1. Clone pmdevtopic into pmdevroot as a subnodetype of pmdevtopic, setting Creator=Updater=pmdev.

    2. Make a pmdevroot display page like so:

    <p><i> [% linkNode $$NODE{author_user}; %] has initiated the following pmde +v topic: </i></p> <p> [{parselinks:doctext}] </p> <p> [{editinvote:Your Topic}] [{shownote}] </p> <p><center> Back to [% linkNodeTitle('Pmdev Discussion') %] </center></p>

    3. Make a new section superdoc like so:

    [{get_sitedoclet}] [{newlistapproved:pmdevroot,perlquestion approved linktype,Pmdev Discu +ssion,15,navbaron,showall}] [{addnewform:pmdevroot,Initiate Pmdev Discussion}] [{showhints}]

    4. Other ancillary things, such as adding awareness of the new section/nodetype to Newest Nodes (for pmdev only, of course).

    It might be nice to name this new type "pmdevtopic", but that nodetype name is already used, by root posts of the Inner Scriptorium. We could rename that nodetype, to something like "manuscript" (in keeping with that section's name), freeing up "pmdevtopic" for the present purpose. tye says that such a renaming would take about 12 patches.

    Note that the reply node type already exists: pmdevnote.

Log In?
Username:
Password:

What's my password?
Create A New User
Chatterbox?
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (6)
As of 2017-12-14 00:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What programming language do you hate the most?




















    Results (381 votes). Check out past polls.

    Notices?