I want to install a "pastie" in our local intranet. What are the alternatives to RaPaste and pastie.org? (the latter can't even be installed locally b/c it doesn't seem to be open source?)
Edit: Doesn't have to be Ruby btw.
Edit: What I mean with pastie is an app where you can share source code pastes instead of pasting it in an irc chat.
There is for instance LodgeIt by the Pocoo guys.
Your request isn't very clear. Starting by defining what are "pasties" in your mind might help (I knew pasties from deviantART, which are very different beasts...). I had to go to the indicated sites to have an idea.
It isn't clear either if it must be Ruby only or not (I see only a tag, no clear requirement).
I know the old and reputed pastebin.org, its (PHP) source is available.
Related
I got several Go projects which is documented compatibly with godoc. We use godoc to share doc and code internally as a doc server without significant problem. However we need more control on opening code when we want to share doc with 3rd party. Is there a way to run godoc in a special mode that showing types and docs but never link to or showing source code?
I've tried
godoc -http=0.0.0.0:8090 -links=false -src=false
but not working, still can link to type definition code. Just wondering if missed sth. Go version, 1.3.
The src file only refers to command line mode, not to server mode, so it won't help you. The way I see it there are a few options:
Rewrite godoc for your needs and use your own fork.
Don't use the server mode, render the docs in command line mode and just create a server out of that.
Better yet (I'm not entirely sure 2 will work) - rewrite the templates a bit so the source code won't be linked. But you'll still need to make sure people who enter the path manually won't see the code so it will require fudging the source templates as well. or...
Maybe the simplest thing - run it behind nginx or a similar reverse proxy, and make sure the /src path in the server is closed to outside visitors, or password protected or whatever. That way your internal team can still use it.
Personally I'd go with 4, it's a couple minutes of work and will be the most robust and flexible solution.
If your writing a go command (not a package) that is large how do you layout its internals? I would love to have some utility packages etc but not have those exposed for anything except the command's code. If it's all in the same repo I don't see whats stopping someone from importing those internal use packages.
You might make your utility packages internal to your package — like this. This won't prevent anyone from using them but a) why would you care anyway? b) the package's structure would give a clear hint on that these "subpackages" are internal to the project.
The answer is simple (but most probably not what you'd like to hear): Do whatever you like and is allowed. Having utility packages living somewhere is perfectly fine, either in the same repo as a "sub-package" or in a different repo.
Regarding
I don't see whats stopping someone from importing those internal use packages
Why do you care? If the packages encapsulate distinct and usable functionalities someone might benefit from importing them. Keeping those function together with the command does not "protect" them in the sense of "nobody should be able to look at my code". Just make it clear in the docs that you'll feel free to do incompatible changes at any time. Go is not about preventing each and any stupidity and protecting the lazy and incapable ones who deliberately ignore any documentation from shooting their foot.
Do Magneto CE extensions work in PE? The extensions I've tried installing in PE aren't working (they install but yield blank screens) and I can't find a straight answer; don't know if it's a problem on my end or if it's built in to Magento. Thanks in advance!!
Short answer is yes. CE modules can function correctly as part of PE, but it will depend greatly on what parts of the functionality it touches.
Things to do for any Magento issues like this:
Ensure the extension is enabled (check to ensure it's output is enabled and it's active) - see this post for reference (the post is how to turn off an extension, but it will point you in the right direction)
Refresh your cache
Ensure logging is on and check your logs for errors
Check your web server logs - where these are will depend on which web server you are running. Apache logs are generally in the error.log file under /var/logs/apache2 or /var/log/httpd
If all else fails, start debugging, by putting Mage::log() entries into the code and seeing what is logged and what isn't
Any extension could possibly work in any version, even if it isn't listed as such. Generally developers of extensions just list the versions that it has been tested in, but that doesn't mean it cant be used in others.
Best way to find out is install the module in your dev environment, and test to make sure it isn't overwriting/breaking any of the existing functionality.
I'm writing a web-crawler using Chickenfoot and need to save PDF files. I can either click the link on the page or grab the PDF's URL and use
go("http://www.whatever.com/file.pdf")
and I get the firefox "Opening file.pdf" dialog box, but can't click the "OK" button to actually save the file.
I've tried using other means to download the files (wget, python's urllib2, twill), but the PDF files are gated so none of those will work.
Any help is appreciated.
This example of how to save a target in the Mozilla developer documents looks like it should do exactly what you want. I've tested a Chickenfoot example that is very similar that gets the temp environment variable, and that worked well for me in Chickenfoot.
https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIWebBrowserPersist#Example
You might have to play with the application associations in Tools, Options, Applications to make sure the action is set to Save File, but those settings might not apply to these functions.
End Answer, begin related grumblings...
I sure wish someone would fix the many bugs in Chickenfoot, and write a nice Cookbook programming guide. I've been using it for years, and there are still many basic things I've not been able to figure out how to do. I finally broke down and subscribed to the mailing list, as the archives have some decent script examples. It takes a lot of searching through the pdf references, blogs, etc. as the web API reference is very sparse.
I love how simple Chickenfoot can make automating some tasks, but it takes me days of searching javascript, DOM, and Firefox documents to find ways to do some of the things it can't, since I'm not really a web programmer. The goal of Chickenfoot seems to be that I shouldn't have to be, but unfortunately few are refining the proof of concept, as MIT has dropped the project.
I tried to do this several ways using only Chickenfoot commands and confirmed they don't work with the latest Firefox 3 and Chickenfoot 1.0.7.
I hope this helps! Good luck. Sorry I only ran across your question yesterday, but found it too interesting to leave alone.
You won't be able to click on Firefox dialogs for the sake of security.
The best way to download the content of a URL is to read then write the content of the URL.
// Chickenfoot 1.0.7 Javascript Code to download the content of a url.
include( "fileio.js" ); // enables the write function.
var url = "http://google.com",
saveFileTo = "c://chickenfoot-google.com";
write( saveFileTo, read( url ) );
You might find it helpful to use jquery with chickenfoot.
http://groups.csail.mit.edu/uid/chickenfoot/scripts/index.php?title=Using_jQuery,_jQuery_UI_and_similar_libraries
This has worked for me to save Excel files from NCES portal.
http://muaz-khan.blogspot.com/2012/10/save-files-on-disk-using-javascript-or.html
I was using Firefox 3.0 and the "old syntax" version of the code. I also stripped code intended for IE and "(window.URL || window.webkitURL).revokeObjectURL(save.href);" which generated an error.
I'm using Magento 1.4.1.1 for my webstore. The payment processor supports only 1.4.0.0. I realized this only just now when I was dreaming up of opening the store. Duh! Poor planning.
What's the way out?
Will downgrading help? Wat are the implications of that?
Thanks for any and all inputs.
I am not aware of anyone ever having successfully downgraded Magento. That said, a few considerations:
Are you using version control like you should be? If so, you should have a copy of the site and database from just before the upgrade. You should be able to use this as a starting point. This is your most optimistic route by far.
If no version control, you can download both of the versions and use diff to get the changes. Doing this in reverse theoretically creates a backwards patch.
If you've stayed out of the core code entirely, the code change could be nearly as simple as replacing app/code/core.
Even if you do downgrade the code, the data structures between versions have probably changed, so you'll need someone experienced to find those changes and tell you have to back-patch your database. This is, to say the least, perilous.
Overall, I wouldn't want to undertake this task. As Anton said in the comments, you'll probably have an easier time getting integration done than reverting the changes.
Best of luck!
Thanks,
Joe