I am using Rhodes to develop android application.
I have installed HTTpary gem in Rhodes. Now when I am writing the statement "require 'httparty' " at top of the application it gives me error like "No such file to load".
What should I do to solve this problem?
From the documentation, scroll down to the section beginning "Adding Ruby Extension Libraries to Your Rhodes Application". It details 3 ways you can include external libraries into your application, summarized below.
Add ruby extension to an individual application
Add ruby library to an individual application
Add ruby library to the Rhodes framework to be built for all applications
The base Rhodes framework only contains things deemed generic enough to be included - so the built application package size can be kept low. Anything not in the base framework can be included in the application through the aforementioned methods.
This is just a guess since w/ Rhodes environment; but if this were a normal ruby script you would need to have require 'rubygems' first (assuming your used rubygems...).
The Motorola documentation is horrendous; allow me to help if I can. Firstly, examine the constant $LOAD_PATHS from your Ruby code to see the entire list of paths that Rhodes searches. Any .rb file in this path is automatically made available to require.
Then you have to decide whether to add this library to the entire Rhodes framework or just your app; personally I opt for one app at a time, because that way it reduces the chances of incompatibilities, and your apps are still provided all the libraries in rhodes-*version/lib/framework
If you want to add a library to your app, the docs suggest plopping it into the directory app/lib, but keep in mind that only this exact path is searched, so if you don't have a .rb file of the same name as your require statement directly under this path, it won't be detected automatically. I mention this because the common structure is a single file with the library name placed directly in lib, and the actual library contents inside a folder of the same name.
Example: the mime-types library is made up of: lib/mime-types.rb and lib/mime/, which are named differently and can lead to exactly this kind of confusion when including in Ruby.
Related
I got chance to migrate Flex application to Apache Royale, able to run helloworld applications. started migrating Application, getting couple of exceptions. bellow is the one.
we are using the
AdobeSpelling.swc
AlivePDF.swc
Cairngorm.swc
flexmdi.swc
FlexUnit.swc
spcairngorm.swc
these '.swc' libraries.
how can i import these or is any similar libraries in royale compatible files.
i found asconfig.json file - external-library-path - but i am compiling my application with maven pom.xml.
Please help me, basic migrations
Error Log:
Warning: Definition com.model.ModelLocator could not be found.
import com.model.ModelLocator;
Warning: Definition com.util.customComponents.CustomMenuBarEvent could
not be found.
import com.util.customComponents.CustomMenuBarEvent;
There is two path which you can go in case of migrating.
Emulation Components. However there is a chance that some of
the components wasn't added to emulation so you may get exceptions
and this would be the place where you can add them and make pull
requests to Royale. Those components allows you in best case
successfully build your application without changing drastically UI
part, but you may won't see anything on the screen or it may be
messed, cause there wasn't volunteer who could work on displaying
better them.
Another path is to distinguish your pure ActionScript code (no
dependency to Flash) from UI part - pure AS3 code should ported
without any problem - and rewrite UI from scratch using Basic module
or Jewel
All libraries which you have mention have strong dependencies to Flash, so my recommendation is to find JS replacement for them and use it in your porting. There is also PureMVC which is working pretty good with Royale - it's has been tested in several applications already.
I installed Perl6 with rakudobrew and wanded to browse the installed files to see a list of hex-filenames in ~/.rakudobrew/moar-2018.08/install/share/perl6/site/sources as well as ~/.rakudobrew/moar-2018.08/install/share/perl6/sources/.
E.g.
> ls ~/.rakudobrew/moar-2018.08/install/share/perl6/sources/
09A0291155A88760B69483D7F27D1FBD8A131A35 AAC61C0EC6F88780427830443A057030CAA33846
24DD121B5B4774C04A7084827BFAD92199756E03 C57EBB9F7A3922A4DA48EE8FCF34A4DC55942942
2ACCA56EF5582D3ED623105F00BD76D7449263F7 C712FE6969F786C9380D643DF17E85D06868219E
51E302443A2C8FF185ABC10CA1E5520EFEE885A1 FBA542C3C62C08EB82C1F4D25BE7B4696F41B923
522BE83A1D821D8844E8579B32BA04966BAB7B87 FE7156F9200E802D3DB8FA628CF91AD6B020539B
5DD1D8B49C838828E13504545C427D3D157E56EC
The files contain the source of packages but this does not feel very accessible. What is the rational for that?
In Perl 6, the mechanism for loading modules and caching their compilations is pluggable. Rakudo Perl 6 comes with two main mechanisms for this.
One is a file-system based repository, and it's used with things like -Ilib. This resolves modules simply using paths on disk. Whenever a module loaded, it first has to check that the modules sources have not changed in order to re-compile them if so. This is ideal for development, however such checks take time. Furthermore, this doesn't allow for having multiple versions of the same module available and picking the one matching the specification in the use statement. Again, ideal for development, when you just want it to use your latest changes, but less so for installation of modules from the ecosystem.
The other is an installation repository. Here, specific versions of modules are installed and precompiled. It is expected that all interactions with such a repository will be done through the API or tools using the API (for example, zef locate Some::Module). It's assumed that once a specific version of a module has been installed, then it is immutable. Thus, no checks need to be done against source, and it can go straight to loaded the compiled version of the module.
Thus, the installation repository is not intended for direct human consumption. The SHA-1s are primarily an implementation convenience; an alternative scheme could have been used in return for a bit more effort (and may well be used in the future). However, the SHA-1s do also create the appearance of something that wasn't intended for direct manipulation - which is indeed the case: editing a source file in there will have no effect in the immediate, and probably confusing effects next time the compiler is upgraded to a new version.
Update
I've since spent time learning how to use install_name_tool & otool to do this properly, and documented the process here: Using Frameworks Within NSBundles
I would like to use the Connection Kit framework within an NSBundle I am making.
To allow my bundle to load the framework successfully, I've changed the dynamic library install name to use #loader_path as opposed to #executable_path.
After building and including the framework in my NSBundle, then building that, running the program that loads my bundle, my bundle fails to load and produces the following output:
Error loading MyBundle.rwplugin/Contents/MacOS/MyBundle: dlopen(/Users/facelap/Library/Developer/Xcode/DerivedData/MyBundle-hiyhdkndcnuhspfqwcuyneqobeou/Build/Products/Debug/MyBundle.rwplugin/Contents/MacOS/MyBundle, 265): Library not loaded: #executable_path/../Frameworks/DAVKit.framework/Versions/A/DAVKit
Referenced from: /Users/facelap/Library/Developer/Xcode/DerivedData/MyBundle-hiyhdkndcnuhspfqwcuyneqobeou/Build/Products/Debug/MyBundle.rwplugin/Contents/MacOS/../Frameworks/Connection.framework/Versions/A/Connection
Reason: image not found
It seems that Connection Kit itself uses a framework.
I also have the source for this framework. I tried setting its dynamic library install name to #loader_path, but this resulted in similar output (and the bundle failed to loar).
What would a sane entry be for the dynamic library install name for a framework within a framework that is to be used within an NSBundle?
Look at the crash log. It says that you bundle can't load DAVKit.framework so the easiest way - its rebuild ConnectionKit framework but instead of embedding DAVKit.xcodeproj insert all sources of DAVKit. Its easiest way but more correctly - its setup install path of ConnectionKit and DAVKit frameworks.
Its link should help you:
embedding frameworks in loadable bundles
You should link your bundle with DAVKit and include it there In the same way as you're including ConnectionKit. This avoids having multiple depths of frameworks being shipped
I've never had any problem with the basic gem tree structure, namely
bin (executables)
lib (source code)
test
...because I've always developed gems as libraries. However, I recently started to develop an application that ships as a gem.
This application has a "runner.rb" file (lib/mygem/runner.rb), that provides a method to run the application. The application is run from the bin/mygem file.
Now this bothers me. "runner.rb" is a file that is specific to our application, it is not a service or an API or any kind of support class for other to reuse (which is what library should be for, right?), yet its directory is "lib/mygem/runner.rb).
I've been reading a lot of definitions, and libraries are supposed to be support an application, not to be the application itself. We don't say "this is the library of my application", but "this is the source code of my application".
So my question is, why do we put the libraries AND source code in the same folder?
I hope I made my point clear, I'm sure there's a good reason behind this, and I'd be interested to hear your thought and to clear this out.
Thank you for reading this :)
After even further investigations, it turns out 'lib/' is called 'lib/' because it only contains definitions.
'bin' is a script that gets executed, like a 'main' function. Since it gets executed, no application logic should be in it, otherwise it's not easily testable.
Thus, all the application logic belongs to your application's library folder. The bin (main) file's only task is to instantiate your application's runner class and run it.
i am currently trying to implement a "third party framework" (FeedbackReporter.Framework) into my preferencepane.
Unfortunately I am getting the following error all the time when trying to launch my preference pane:
16.05.10 23:13:30 System Preferences[32645] dlopen_preflight
failed with
dlopen_preflight(/Users/me/Library/PreferencePanes/myPane.prefPane/Contents/MacOS/myPane):
Library not loaded:
#executable_path/../Frameworks/FeedbackReporter.framework/Versions/A/FeedbackReporter
Referenced from:
/Users/me/Library/PreferencePanes/myPane.prefPane/Contents/MacOS/myPane
Reason: image not found for
/Users/me/Library/PreferencePanes/myPane.prefPane
As far as I read so far, this problem is probably caused because my prefPane is no actual app, but a "plugin" of "System Settings.app" and thus #executable_path resolves to a path within the bundle of this app, instead of the bundle of my prefpane.
But I don't really picked up howto fix this problem. I guess it must be fairly easy since it should be a usual case that people use non-apple-frameworks in PreferencePanes.
Thanks for your hints!
--
Short Update:
As far as I understood tons of docs I read so far, there might be a setting which has to be done in the third-party framework. Obviously the "install path" has to be set to "loader_path" instead to "executable_path" in order to work in a preferencepane.
But since I am using a precompiled framework (FeedbackReporter.framework) this is probably a setting which the author has to change?! and even if i could compile the framework myself, i had no idea where to change this install_path in Xcode.
If you cannot wait for the next release just download the source, change it in
FeedbackReporter.xcodeproj/project.pbxproj
and then open and compile the framework yourself.
Actually, you can change it yourself without recompiling the third party framework. You can use install_name_tool to change where a MachO binary will look for shared object libraries. First use otool -L <binary file for your plugin> to get the paths of where it expects its libraries to be, then use install_name_tool -change ... to change the paths in that file. Repeat for any bundled frameworks.