How do you allow a C-extension to use rb_f_require to require a file from outside the ext directory (e.g. requiring lib/foo/foo.rb from ext/foo.so).
Not really sure why this isn't converted into html like the rest of the ruby hacking guide that had been translated, but perhaps some portion of this would be helpful?
http://rhg.rubyforge.org/svn/en/chapter18.txt
Given that rb_f_require appears to do a normal load path search, it would seem it would search out into lib/foo if that is in the search path. However, if you are looking for another foo.rb I would imagine you would have name problems if foo.so appears first. Perhaps using a different name for foo.rb could solve the problem?
Related
Could anyone tell me if there's some way of "hooking in" to DotNetNuke so that I can, for example, search and replace text for ALL HTML modules on the site?
e.g. if I use an HTML editor and enter the text {{replace_me}}, then I could have some code that detects "{{replace_me}}" every time a page is rendered and replace it with something else.
Please note that this is a simple example - there may be other ways of "replacing" text - however the actual use case we have is very specific and there will be some significant processing to decide what to replace :) - so whatever solution we implement should basically be:
Get HTML from DB -> Process it however we wish in full C# -> Deliver the modified string.
Thanks!
I believe you can do this with the use of an HTTPModule. Ifinity.com.au used to sell a module that did this, looks like you might be able to download it now for free (maybe?) at http://www.ifinity.com.au/Products/Inline_Link_Master/Product_Details
I'm going through Lift's basics in Section 3.2 SiteMap of Simply Lift and one thing struck me.
Using the default SiteMap code, you can ask for, say, info view in three ways:
GET /info,
GET /info.html,
GET /info.xml (why?).
What is more, you can request index view in four different ways:
GET /,
GET /index,
GET /index.html,
GET /index.xml.
How can I limit this behaviour to GET / for directories and GET /info for files?
P.S. All of these return 200 OK:
foursquare.com/,
foursquare.com/index,
foursquare.com/index.html,
foursquare.com/index.xml.
Shouldn't one resource have one URL only?
There are actually more than four ways that it can be parsed. The full list of known suffixes (any of which can be used to access the page) can be found here.
I think the reason for that is that lift can be used to serve any resource, so most are explicitly added by default.
I think you could disable Lift's processing of all extensions by adding this to Boot.scala:
LiftRules.explicitlyParsedSuffixes = Nil
However, I wouldn't recommend that as there may be some side-effects.
Using Req with RestHelper you can specify the suffix explicitly, but I don't know if there is such a construct to do so with Sitemap.
Actually, the code to determine whether Lift should handle the request or not is here. You can see the default extensions in the liftHandled method directly above, but they can all be overridden with LiftRules.liftRequest. Something like:
LiftRules.liftRequest append {
case r => Full(r.path.suffix.trim == "")
}
Should do the trick.
As far as why it works that way, Jason is right that Lift is designed to handle multiple types of dynamic resource.
I am using the Drupal 7 Migrate module to create a series of nodes from JPG and EPS files. I can get them to import just fine. But I notice that when I am done importing them if I look at the nodes it creates, none of the attached filefield and thumbnail files contain filename information.
Upon inspecting the file_managed table I see that both the filename and filemime fields are empty for ONLY the files that I attached via the migrate module. This also creates an issue with downloading the files.
Now I think the problem has to do with the fact that I am using "file_link" instead of "file_copy" as the file operation I specify. The problem is I am importing around 2TB (thats Terabytes) of image files. We had to put in a special request with Rackspace just to get access to that much disk space on our server. So I can't go around copying from one directory to the next because of space issues. So "file_link" seems like the obvious choice.
Now you probably want to see how I am doing this exactly, so here is the code snippet:
$jpg_arguments = MigrateFileFieldHandler::arguments(NULL,
'file_link', FILE_EXISTS_RENAME, 'en', array('source_field' => 'jpg_name'),
array('source_field' => 'jpg_filename'), array('source_field' => 'jpg_filename'));
$this->addFieldMapping('field_image', 'jpg_uri')
->arguments($jpg_arguments);
As you can see I am specifying no base path (just like the beer.inc example file does). I have set file_link, the language, and the source fields for the description, title, and alt.
It is able to generate thumbnails from the JPGs. But still missing those columns of data in the db table. I traced through the functions the best I could but I don't see what is causing this. I tried running the uri in the table through the functions that generate the filename and the filemime and they output just fine. It is like something is removing just those segments of data.
Does anyone have any idea what this could be? I am using the Drupal 7 Migrate module version 2.2. It is running on Drupal 7.8.
Thanks,
Patrick
Ok, so I have found the answer to yet another question of mine. This is actually an issue with the migrate module itself. The issue is documented here. I will be repealing this bounty (as soon as I figure out how).
I need to write a small R script for people who never used R before that imports a file and does some things with it. I would like to minimize user input as much as possible, and since assigning the file-path is basically all the user input required I was wondering, is it possible to get a popup screen (basically your usual "open file" screen) allowing someone to select a file (import the name as string in R or something)?
The file.choose function performs this, eg:
fname <- file.choose()
source(file.choose())
You may also want to look at choose.files (for multiple files) and choose.dir (for just selecting a directory path).
The tcltk package gives you tk_choose.files.
If you want to go beyond file choosers then you can use the package to build user interfaces.
It's worth mentioning rChoiceDialogs::rchoose.files. I'm not completely sold yet, but they advertise it as being completely cross platform and fixing the annoying problem common to choose.files and tk_choose.files of popping up behind other windows. See their vignette here.
I'm just beginning the process of exploring i18n in CakePHP and I can't seem to find the right combination of files and functions that will allow me to use multiple po files. If I want to use a single po file (default.po) for every bit of translatable text, that works fine, but I see that becoming an unmaintainable hairball very, very quickly. I've read the docs and the few articles I can find, but none really dive into i18n beyond the trivial use of one .po file.
Here's where I am right now:
I've "baked" my po templates (.pot files) and copied those into app/locale/eng/LC_MESSAGES (I'm not going to be using the default text as the key so that I can easily spot missing keys). For now, I have -views-layouts-default.po and -views-pages-index.po.
In those .po files, I've entered the text I want to use for each key.
In my homepage (views/pages/index.ctp) and default layout (views/layouts/default.ctp) I've wrapped the text key I want to translate with the __() function.
When I load the homepage, though, all I see are they keys. No text has been translated. If I throw up a default.po file, though, any keys I drop in there are populated just fine. I'm clearly missing some piece of the puzzle, but I can't find it. Any help would be much appreciated.
Thanks.
I found the piece I was missing thanks to the CakePHP Google Group. I had been playing with the __d() convenience function, but didn't have a clear picture of how to tie it together to my .po files. The answer is easy once you know it:
The domain translation:
__d ( 'login', 'PLEASE_LOGIN' );
Will look for the "PLEASE_LOGIN" key in the file named login.po. I didn't know (and hadn't read anywhere) that domain == po file name (without extension). Learning that made all the difference.