I am trying the bifacial radiance tool which is python wrapper to radiance developed by NREL that provides a set of functions and classes for simulating the performance of bifacial PV systems. I have gone through the examples provided in bifacial radiance library package and those are working as shown in the jupyter notebook files.
I am trying to include a Module Mounting structure (MMS) as per civil structure drawings in the bifacial radiance tool. Creating objects in radiance is cumbersome hence I am trying external tool (e.g Sketch up) to create structure and read it using bifacial radiance.
For that, I have created an MMS drawing in SketchUp, and using Su2rad plugins I got the object rad file. However, I am facing some errors while adding exported Object rad file using makeCustomObject and appendtoScene.
how to read object created in other tool to radiance environment with Su2rad or by any other means?
Exported files from Sketchup using Su2rad are:
https://groups.google.com/u/1/group/pvlib-python/attach/d70740ae6c48/FT%20ONLY.rar?part=0.1&authuser=1
Related
I'm trying to load a png image in OCaml and make it into a matrix of color pixels. I'm using the OCaml Graphics module. I think I need to use the CamlImages module as well but I'm not quite sure how to.
First of all, let's make it clear. The OCaml graphics library doesn't provide any image decoders, so you have to use some other library to decode a file into the representation that the Graphics library understands, which is a matrix of colors.
I failed to find an online documentation for CamlImages, so I will teach you how to generate one using odig - the tool for querying and exporing OCaml universe. First of all you need to install it and odoc - a documentation generator, e.g., if you're using opam then do
opam install odig odoc
Now you can do
odig doc camlimages
and it will generate documentation and open it in your browser.
There you will find the Png.load function that will load a file encoded in the PNG format. It will return the image in the one of the CamlImages formats and you have to write a translation function from that format to the matrix of colors format.
Note, if in your course setup you doesn't have opam or odig or odoc, then ask your teachers for documentation. If they are nonresponsive, then you can read the mli files directly, the following command will show you all the interfaces available in the CamlImages library:
ls $(ocamlfind -query camlimages)/*/*.mli
I've setup Ogre and dependencies on my PC, and downloaded some Ogre applications. When I launch my new exe file of the project I just downloaded it generates the following error:
05:37:59: Loading library C:/OgreSDK_vc9_v1-7-1/bin/debug\RenderSystem_Direct3D9_d
05:37:59: OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library C :/OgreSDK_vc9_v1-7-1/bin/debug\RenderSystem_Direct3D9_d. System Error: The specified module could not be found.
in DynLib::load at ..\..\..\..\OgreMain\src\OgreDynLib.cpp (line 91)
Any help would be appreciated.
Thanks in advance.
Upon creation of the central Ogre3D class Ogre::Root, you need to pass the name of a *.CFG file that contains all to be loaded Ogre plugins, such as the above mentioned D3D9 Render System.
That file needs to be next to your *.EXE by default and should look like this (in a minimal form where only the D3D9 Render System is loaded and the matching DLL file resides next to this CFG file):
# Defines plugins to load
# Define plugin folder
PluginFolder=.
# Define plugins
Plugin=RenderSystem_Direct3D9
For more information, have a look at this section in the Ogre3D tutorial 1
This took me a while until I figured it out. The dll (RenderSystem_Direct3D9_d) is missed because you didn't build it - it's the project with the same name (RenderSystem_Direct3D9) in the OGRE.sln
I'm using OGRE 2.1, so the dll I missing is RenderSystem_Direct3D11_d.dll instead of RenderSystem_Direct3D9_d.dll like yours, but the fix is similar, just build that dll's project, like the image below.
Anyway, as a beginner, to avoid any trouble, just hit F6 to build whole solution.
I'm beginning development on an acoustic spectrum analysis tool (inspired by spek) written in C++ with gtkmm (C++ bindings for the GTK+ GUI toolkit). I would imagine that I should know how to do this by now, however...
My directory structure is a-la-GNOME, e.g src/, data/, po/, man/. The specific situation that presented the need for my inquiry is the use of a GTK UI Manager that will be located in data/ui. For this specific situation, I want to be able to load the user-interface from this file in an install-independent manner (e.g. loading of the file does not depend on a make install; the executable may be run [and load the UI file] either from src/ after running make [thus compiling the sources into the selfsame exectuable] or from its install prefix). How would I refer to the UI file in my source code (keeping in mind that the loading of the file is not performed by creating a file object (fopen(...)) but rather by passing a file location as a string argument to (UIManager).add_ui_from_file(...))?
In addition to this particular situation of a UI file, how would I do similar references to files (i.e. databases, INI files, XML schemas) by using the autotools build process? Is there a piece of relevant Automake code to quickly set up a project to use this type of directory structure?
simply try to use both files (with the un-installed taking precedence):
if(!(UIManager).add_ui_from_file(../data/ui/mygui))
(UIManager).add_ui_from_file(/incalled/location/mygui)
In Glom, I created a helper function that tries both locations, with both locations being defined in the Makefile.am (this is simpler if you have only one Makefile.am, by using non-recursive automake, which is simpler anyway):
http://git.gnome.org/browse/glom/tree/glom/glade_utils.h#n38
I am currently learning how to create Firefox addons using XPCOM and I want to know how to include thirdparty libraries to develop them. I followed a few tutorials to compile .xpt and .dll from c++ files (noted in: https://developer.mozilla.org/en/How_to_build_a_binary_XPCOM_component_using_Visual_Studio and http://nerdlife.net/building-a-c-xpcom-component-in-windows/) and I am not sure how we are suppose to include the files into an addon project (which gets packaged into .xpi file).
I am using Opencv (c++) to do image conversions via the addon such as resizing a very large image (3mb high res png) down to something small and simple (such as 600X800 200kb jpg) that will be done by my addon. I know that Opencv is written in c++ and xpcom can compile c++ code into a dll and xpt. I read a couple of tutorials but most of them points to adding these files (xpt and dll) in "C:/Program Files(x86)/Mozilla Firefox/components" instead of the addons "components/" folder (which is not how addons work, I believe). Though the Mozilla page (listed above) does include something about "{app}/components" and "{app}/application.ini" folders but I have never read anything like this, so therefore I am confused how this is done.
My other option is making the Opencv methods into an executable and then running it separately (similar to how MemoryFox addon runs an executable to clear Firefox's memory) and use that to conduct image resizing.
I am really not sure how to do this (I am new the addon development) and I would like to know how to accomplish this (using 3rd party C++ libs into the addons). An example, tutorial or explanation is fine to get me started.
Thanks in advance.
Edit: I would also like to inform that I have read threw most of https://developer.mozilla.org/en/Creating_XPCOM_Components (picked and choose topics) and it does not tell me how to achieve the above.
There are several places you can store an addon and inform FireFox of it's existence.
Mostly it comes down to how you want to distribute it.
With MS Windows the loadLibrary process will search the current directory then the path.
Simply locating your xpcom.dll alongside 3rdparty.dll in the components folder of your pluggin should work ok.
XPCOM is like windows COM but for across platforms.
Your designing to meet the requirements of interfaces.
Your addon may not need to define it's own interface (.idl -compiles-> .xpt, .h) but if it does from firefox 4 you will need to list this in the chrome.manifest.
Once compiled you will need to list your dll in the chrome.manifest also.
taking your example prototype function
long Add(in long a, in long b);
baz_1.idl might look like
#include "nsISupports.idl"
[scriptable, uuid(F0F0F0F0-AAAA-BBBB-CCCC-111111111111)]
interface iBaz : nsISupports
{
long Add(in long a, in long b);
};
generate your header and xpi distrib
$(GECKOBIN_PATH)/xpidl -m header -I $(GECKOSDK_PATH)/idl -e baz_1.idl
$(GECKOBIN_PATH)/xpidl -m typelib -I $(GECKOSDK_PATH)/idl -e baz_1.idl
Link the contract guid to the contract name in C++ for FF4
NS_DEFINE_NAMED_CID(BAZ_CID); // defined in baz.h generated from baz_1.idl
static const mozilla::Module::ContractIDEntry kSLMozContracts[] = {
{ "#foo.bar.com/baz;1", &kBAZ_CID },
{ NULL }
};
usage in C++
nsCOMPtr<iBaz> baz = do_CreateInstance("#foo.bar.com/baz;1",&rv);
usage in JavaScript
var baz = components.classes["#foo.bar.com/baz"] .createInstance(Components.interfaces.iBaz);
Example.
We have a product that also provides a firefox addon, so we don't ship an xpi, but the addon sits in a subfolder of the product.
Product in
c:\program files\foo\
addon in - lets call this foobar
c:\program files\foo\bar
register the addon
HKLM\SOFTWARE\Mozilla\Firefox\Extensions\
"{GUID}"="c:\program files\foo\bar"
so then the layout of the addon is
foobar\chrome.manifest
foobar\install.rdf
foobar\components\baz_1.xpt
foobar\components\baz_1_32.dll
foobar\components\baz_1_64.dll
foobar\components\someOtherWorker.dll
foobar\chrome\ui.jar
In FF < 4 you didn't need to list binaries in the manifest, things in components folder are loaded and checked for functions to see if they are xpcom, so a chrome manifest might have looked like
content baz jar:chrome/ui.jar!/content/baz/
skin baz classic/1.0 jar:chrome/ui.jar!/skin/classic/baz/
From FF 4 the chrome manifest needs to list your binary files, so it then looks like
(we only support 64 bit after FF 3.5)
content baz jar:chrome/ui.jar!/content/baz/
skin baz classic/1.0 jar:chrome/ui.jar!/skin/classic/baz/
interfaces components/baz_1.xpt
binary-component components/baz_1_32.dll ABI=WINNT_x86-msvc
binary-component components/baz_1_64.dll ABI=WINNT_x86_64-msvc appversion>=3.5
FireFox 5 (Out now) has changed
the formats of xpt files - so your interfaces won't be found by FF5 unless you build with that SDK.
the version of the xpcom registration - so FF5 won't use a dll built for FF4 as the xpcom version isn't high enough.
The tutorial you refer to is about developing applications, not extensions. So application.ini doesn't apply in your case. Extensions have a manifest file called chrome.manifest, starting with Firefox 4 all XPCOM components and XPT files need to be registered there - or they will be ignored. It no longer matters where the component is located though components/ would still be the common place for them. https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0#Component_registration should be a good starting point - that should explain what you need to write there.
Note that the source code in the tutorials you were reading is outdated as well. Current code examples are linked to from https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0#Binary_components. And you should use XULRunner SDK 2.0 (corresponds to Firefox 4) or higher. Sorry, you arrived at a bad time - that's the biggest change to XPCOM in the past 10 years.
I have created a gstreamer plugin with an element inside that would generate some data when put in a pipeline (by following the GStreamer Plugin Writer's Guide).
My problem is that I cannot load my plugin in a test application. When I call gst_element_factory_make("myextractor", NULL) the result is always NULL.
More data (I'm not sure this is related):
When I run gst-inspect on my dll I get incomplete output (output generated using cygwin):
beq11049#beqleuleu1nb028 /cygdrive/c/work
$ /cygdrive/c/OSSBuild/GStreamer/v0.10.6/bin/gst-inspect.exe MyProject/Release/gstxyzlibrary.dll
Plugin Details:
Name: myextractor
Description: XYZ Library
Filename: MyProject/Release/gstxyzlibrary.dll
Version: 1.0
License: LGPL
Source module: myextractor
Binary package: MyProject
Origin URL: http://www.example.com/
myextractor: XYZExtractor
1 features:
+-- 1 elements
If I compare this with the avisubtitle addon (from the GStreamer Good Plug-ins package) I get a lot less information for mine.
For example, my plugin says:
1 features:
+-- 1 elements
The avisubtitle plugin says (generated using $ /cygdrive/c/OSSBuild/GStreamer/v0.10.6/bin/gst-inspect.exe avisubtitle):
GObject
+----GstObject
+----GstElement
+----GstAviSubtitle
My question: I need advice on how to debug this / determine what I am missing (enabling debugging output, settings and paths to check and so on). My test code (the call to gst_element_factory_make) is written in a Songbird adon, but I get the same results if I put my code in a separate executable.
It might be because the loader can't find your plugin, you should check that your plugin is in the shared library path:
Make sure you've set the LD_LIBRARY_PATH environment variable to the directory containing your compiled plugin.
In cygwin, add this to your .profile, or run it before you run your program:
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/cygdrive/c/path/to/your/plugin/"
You could also use the -L linker option to specify a search path at compile time.
I am not sure how to answer your question, because there might be several things missing. I think about unresolved symbol depedencies (although unlikely, since you can actually inspect your plugin) or wrong registration, somehow (it's also difficult to get it wrong), perhaps issue with songbird or windows that I ignore.
However, I just want to clear out one thing: GStreamer has "plug-ins" (aka dynamically loadable library) that can contain one or more elements. When you gst-introspect the plug-in or the element, you get different outputs! In the case of "avisubtitle", it's an element, and you can read the class hierarchy. If you introspect the plugin (or the library) "avi" or "/usr/lib/gstreamer-0.10/libgstavi.so" (on Unixes), you get the list of elements it contains and some common properties (version, project etc..).
For example, gst-introspect XYZ (XYZ a library or a path to a library) is different than gst-introspect XYZ (XYZ the name of the element in the XYZ library)
Perhaps that will helps you. good luck! Oh, and errors/warning can be displayed with the environment variable GST_DEBUG=*:2