Access POD from another Perl 6 file - raku

The Perl 6 POD documentation has a section on accessing the current file's POD document by using $=pod. There is no information on accessing another file's POD document.
How can I access another file's POD structure, without altering the current file's $=pod?

You can now do that with Pod::Load. From the README in the examples directory
perl6 -e 'use Pod::Load; .perl.say for load("pod-load-clean.pod6")'
Please note that the Pod6 file has to be "clean", that is, not use any external module that is not generally available or it might fail.

I have created a filesystem-agnostic solution in Module::Pod (soon to be published) at git#github.com:dmaestro/Module-Pod.git
use Module::Pod;
# Get all Pod::Block::* objects in the module, from its own $=pod
my #pod = pod-from-module(<My::Module>);
Pros:
No direct EVALS of file code (even within Module::Pod)
Uses CompUnit::Repository and kin to locate the module
May be used with or without use-ing the module for other purposes in your code
If module is already loaded, you may call with its Type Object
Cons:
Module uses nqp: methods directly, as in Pod::Convenience (maybe not really a con?)
Not able to retrieve pod from *.pod files
Intended for use in Pod6-checking tests, etc.

Related

No detect the external library (Phpoffice) in yii2

Two computers are working on the SAME repository but first computer detect the library and work well but second computer not detect it and show "Error 'PhpOffice\Phpspreadsheet\Reader\Xlsx' not found".
In vendor, the library also exist.
composer.json and composer.lock also the same on both computer.
One thing is that by git ignore, I use yii's composer mechanism at 1st computer but at sec computer(err computer), I add library manually.
If you want to use a composer package, you absolutely need to install it using composer. This ensures that the autoloader is generated properly and your class can be found through PHP.
Copying library files into vendor directory is not enough to install it. During installation Composer creates autoload script with information how to find all classes installed by Composer. If you just copy library files, Composer will not even know that it exist and will not able load any class from it.
If you cannot use Composer on server/computer A, you should install all dependencies on different computer (B) and copy the entire vendor directory into server/computer A. Autoload definitions are in vendor so it should work if you copy the whole dorectory.

Dropwizard serve external images directory

I have a dropwizard API app and I want one endpoint where I can run the call and also upload and image, these images have to be saved in a directory and then served through the same application context.
Is it possible with dropwizard? I can only find static assets bundles.
There is similar question already: Can DropWizard serve assets from outside the jar file?
The above module is mentioned in the third party modules list of dropwizard. There is also official modules list. These two lists are hard to find maybe because the main documentation doesn't reference them.
There is also dropwizard-file-assets which seems new. I don't know which module will work best for your case. Both are based on dropwizard's AssetServlet
If you don't like them you could use it as example how to implement your own. I suspect that the resource caching part may not be appropriate for your use case if someone replace the same resource name with new content: https://github.com/dirkraft/dropwizard-file-assets/blob/master/src/main/java/com/github/dirkraft/dropwizard/fileassets/FileAssetServlet.java#L129-L141
Edit: This is simple project that I've made using dropwizard-configurable-assets-bundle. Follow the instructions in the README.md. I think it is doing exactly what you want: put some files in a directory somewhere on the file system (outside the project source code) and serve them if they exist.

Why won't OSA_LIBRARY_PATH not work as documented for JXA?

According to Apple's Developer Docs the Library global allows one to import compiled scripts so they can be used as a library in one's current script. This works just fine if you were to do something like the below code with myLibName.scpt located at ~/Library/Script Libraries:
myLib = Library('myLibName');
myLib.myLibMethod() // Works just fine
But, the docs also claim that one can export an environment variable — OSA_LIBRARY_PATH containing a string of : delimited paths — and Library() would then defer to that list of paths before proceeding to it's default path: ~/Library/Script Libraries. Ya know, like the bash environment variable Path. Here's the relevant piece of documentation below; it describes the path hierarchy:
The basic requirement for a script to be a script
library is its location: it must be a script document in a “Script
Libraries” folder in one of the following folders. When searching for
a library, the locations are searched in the order listed, and the
first matching script is used:
If the script that references the library is a bundle, the script’s
bundle Resources directory. This means that scripts may be packaged
and distributed with the libraries they use.
If the application running the script is a bundle, the application’s bundle Resources
directory. This means that script applications (“applets” and
“droplets”) may be packaged and distributed with the libraries they
use. It also enables applications that run scripts to provide
libraries for use by those scripts.
Any folders specified in the environment variable OSA_LIBRARY_PATH. This allows using a library
without installing it in one of the usual locations. The value of this
variable is a colon-separated list of paths, such as /opt/local/Script
Libraries:/usr/local/Script Libraries. Unlike the other library
locations, paths specified in OSA_LIBRARY_PATH are used exactly as-is,
without appending “Script Libraries”. Supported in OS X v10.11 and
later.
The Library folder in the user’s home directory, ~/Library.
This is the location to install libraries for use by a single user,
and is the recommended location during library development.
The
computer Library folder, /Library. Libraries located here are
available to all users of the computer.
The network Library folder,
/Network/Library. Libraries located here are available to multiple
computers on a network.
The system Library folder, /System/Library.
These are libraries provided by OS X.
Any installed application
bundle, in the application’s bundle Library directory. This allows
distributing libraries that are associated with an application, or
creating applications that exist solely to distribute libraries.
Supported in OS X v10.11 and later.
The problem is that it doesn't work. I've tried exporting the OSA_LIBRARY_PATH variable — globally via my .zshrc file — and then running a sample script just like the one above via both the Script Editor and the osascript executable. Nothing works; I get a "file not found" error. I found this thread-where-the-participants-give-up-hope online; it doesn't explain much. Any thoughts?
On a somewhat related note, the Scripting Additions suite provides two other methods — loadScript and storeScript — that seem like they might be useful here. Unfortunately, when you try to use them, osascript gives you the finger. Though, I did manage to return what looked like a hexadecimal buffer from a compiled script using loadScript. Anyway, any insight you guys can shed on this would be much appreciated. Thanks.
The OSA_LIBRARY_PATH environment variable is ignored by restricted executables when running with System Integrity Protection enabled.
To workaround this limitation you can either turn off SIP, or you can use an unrestricted executable.
For instance, to make osascript unrestricted, you should first make a copy, and then re-sign it with an ad-hoc signature:
cp /usr/bin/osascript ./osascript
codesign -f -s - ./osascript
Once you have the unrestricted osascript, you can run it with the OSA_LIBRARY_PATH environment variable set like this:
OSA_LIBRARY_PATH="/path/to/libs" ./osascript path/to/script.scpt
As a lousy alternative, you can put a symlink at one of the "Script Libraries" folders that osascript would look at and point it to the folder you want. Note that the symlink must be a replacement for the entire folder, it can't just exist inside of it.
rm -rf ~/Library/Script\ Libraries
ln -s "/Your/Custom/Path/Goes/Here/" ~/Library/Script\ Libraries
Tested on 10.13.2

Can I save into a specific folder?

While learning how to create Lua file output code with the support of LÖVE, I've always hated that LÖVE filesystem handler always saved the specific file somewhere in C:/Documents and Settings/...
How can I create a code that saves a file into a specific folder that I'd like to define (and maybe to change while running the application)?
The love.filesystem library doesn't let you do anything outside the sandbox. However, LÖVE doesn't disable Lua's built in io library, so you can use io.open to open files outside the sandbox and read/write them as normal, as well as other Lua functions like require and loadfile.
It also doesn't restrict loading of external modules, so you can (for example) require "lfs" to load LuaFileSystem and use that, if it is installed.

Proper approach to sharing CMake module across projects?

I have written a CMake module that contains a couple of useful macros that I would like to use across a number of other CMake projects. However, I'm not sure where to put the module.
I would like to be able to do this inside each project that uses the macro:
include(MyModule)
However, I'm not sure if there is an easy and cross-platform way of achieving this. In fact, I can't even get it to work on Unix. I put the module (MyModule.cmake) in the following locations:
/usr/lib/cmake/
/usr/lib/cmake/Modules
/usr/local/lib/cmake
/usr/local/lib/cmake/Modules
...and the project with the include() was unable to load the module.
What is the correct location for this module? Is there a better approach?
I should also point out that the macros are not related to "finding" a third-party library and therefore have nothing to do with find_package().
Put the module in a directory of your choice, and then add that directory to CMAKE_MODULE_PATH using list(APPEND).
You can even host that module somewhere and then download it via file(DOWNLOAD). If you download it to the same directory as the current CMake script being processed, you just include(MyModule.cmake) and don't need to modify CMAKE_MODULE_PATH.
You could download the file to a common location on disk and then add a check using if(EXISTS "${module_location_on_disk}") to skip the download if it's already downloaded. Of course, more logic will be required if your module changes, or you want to have a common location and multiple versions of the module, but that's out of those scope of your question.