Extending Chef IIS Pool LWRP - iis

I would like to extend the Chef IIS Pool LWRP (https://github.com/chef-cookbooks/iis/blob/master/resources/pool.rb) and I was hoping someone could help me figure out the syntax.
This is where I'm at:
I created a new cookbook and then I referenced the IIS cookbook,
afterwards I created this file in the libraries folder of me:
# Located At: myCookbook/libraries/my_iis_pool.rb:
::Chef::Recipe.send(:include, Opscode::IIS)
class Chef
class Resource::MyPool < Chef::Resource::IIS::Pool
# Some Magic Happens
end
end
and then the recipe looks like this:
# Located At: myCookbook/recipes/default.rb
mypool 'new-pool' do
end
I can't seem to get the < Chef::Resource::IIS::Pool inherit statement correct.
It produces this error:
NameError: uninitialized constant Chef::Resource::IIS
I've also tried
class Resource::MyPool < Chef::ResourceResolver.resolve(:iis_pool)
which produces this error:
TypeError: superclass must be a Class (NilClass given)
Any help would be appreciated.
Thanks,
Abrehm

Unfortunately there isn't a good way to directly extend a DSL-based custom resource like that. The best approach is to just make a new custom resource that uses iis_pool internally, so kind of like a wrapper pattern. This only lets you do stuff before or after the existing resource code though, if that isn't enough you may have to dig in to some more exciting metaprogramming like the edit_resource APIs or declaring the classes in recipe files.

Related

Where can I find the lua script of a Co-Simulation model in OMSimulator (OpenModelica)?

I am trying to run a co-simulation model using OMSimulator. I managed to create a FMU from a TRNSYS model thanks to this tool: https://sourceforge.net/projects/trnsys-fmu/
When I import it, I get the following error:
[2] 12:23:32 Scripting Error
[fmiLogger] module FMI2XML: Start attribute is required for this causality, variability and initial combination
It seems that I need to initialize some variables (not sure about what) in the OMSimulator command line. I think that it is the Lua script I heard about, but I cannot really find it.
I would really appreciate it someone could help me on this, since the documentation (https://openmodelica.org/doc/OMSimulator/v2.0.1/html/OMSimulator.html) it is not enough for my level.
Thanks!!!
It seems to be a problem with the FMU and not OMSimulator. The start value is required in the modelDescription.xml file of the FMU according to the FMI specification.

cannot find the declaration of element 'resources'

Cannot find the declaration of element
This is in values.xml (a system therefore uneditable file) and is giving me
Cannot find the declaration of element 'resources'
This is an error that is preventing my project from building
It would really help if you could post a log of the actual error, it should tell you which file and line is causing the issue, and why.
Resources need to be pointed to in order for your project to compile properly and with the correct resources. For example, when coding with java (referring to building for Android) you might see an import of a resource directory.
This could look like:
import com.android.systemui.R;
or
import com.android.settings.R;
The R you see there represents a resource directory.
Posting your build error along with the file(s) you modified would be very helpful.

Missing props on RowRendererParams

We're currently working on a table powered by React Virtualized and using TypeScript.
At the moment we're looking at making a custom row render.
We started off by looking at the implementation of the defaultRowRenderer.
We took that code and started modifying it to our needs, and we noticed that there are two props it expects that aren't defined in the #types/react-virtualised type definitions.
key, and onRowRightClick.
So we dug a bit deeper and had a look at the types.js which is in the same directory as defaultRowRenderer.js and found that babelPluginFlowReactPropTypes_proptype_RowRendererParams also doesn't define those props.
We then had a look at the Grid and List folders, and their types.js files do contain the key prop in babelPluginFlowReactPropTypes_proptype_RowRendererParams (List) and babelPluginFlowReactPropTypes_proptype_CellRendererParams (Grid).
Should key, and onRowRightClick be defined in Table/types.js.
And if so is the fact they are missing the reason that they're also missing in the TypeScript definitions?
Or am I miss-reading the entire lot? ;)
And if so is the fact they are missing the reason that they're also missing in the TypeScript definitions?
The TypeScript definitions aren't maintained by me so they may lag behind the actual project for no good reason.
As for why those props are missing from the Flow type in the git repo- probably just an oversight. The type isn't a strict object type so additional properties aren't treated as an error. We should add them into the type and fix it though.

Puppet 4: how to add calling class variables to scope of a defined type

In Puppet 3 and prior, templates in defines inherited scope from their calling class the same way native defined types do, so if I had a file resource with a template source created by a define, that template could make use of variables set in the calling class no matter which class called the define.
In Puppet 4 (also tested with Puppet 3.8 future parser), that appears to no longer be the case, and it is causing breakage that is hard to even measure in my environment, which has relied on this behavior for tens of thousands of lines of code. Is there any way at all to get this back? After looking into it, even converting the defines into native types doesn't solve the problem, as they rely on the ability to gather server-side information about what templates are available in different modules via custom functions, and everything in a native resource type appears to happen on the client.
Is this fixable, or do I attempt to wait for Puppet 5?
Edit: Don't get too caught up in the word 'scope' here -- I need any way to pass all class variables to a define and unpack them there so that they are available to templates, or a way to have a native type see what files are inside specified modules on the puppetmaster. I will accept any bizarre, obscure message passing option as long as it has this result, because the classes do not know where the templates are -- only the define does, because it's making use of the helper functions that scan the filesystem on the server.
Edit 2: To prove this works as expected in Puppet 3.8.5, use the following:
modules/so1/manifests/autotemplate.pp:
# Minimal define example for debugging
define so1::autotemplate (
$ensure = 'present',
$module = $caller_module_name,
) {
$realtemplate = "${module}${title}"
file { $title :
ensure => $ensure,
owner => 'root', group => 'root', mode => '0600',
content => template($realtemplate),
}
}
in modules/so2/manifests/example.pp:
# Example class calling so1::autotemplate
class so2::example (
$value = 'is the expected value'
) {
so1::autotemplate { '/tmp/qwerasdf': }
}
in modules/so2/templates/tmp/qwerasdf:
Expected value: <%= #value %>
In Puppet 3.8.5 with future parser off, this results in /tmp/qwerasdf being generated on the system with the contents:
Expected value: is the expected value
In Puppet 3.8.5. with parser = future in environment.conf (and also Puppet 4.x, though I tested for this example specifically on a 3.8.5 future parser environment), this results in the file being create with the contents:
Expected value:
Edit 3: two-word touch-up for precision
In Puppet 3 and prior, defines inherited scope from their calling class the same way native defined types do, so if I had a file resource with a template source created by a define, that template could make use of variables set in the calling class no matter which class called the define.
What you're describing is Puppet's old dynamic scoping. The change in scoping rules was one of the major changes in Puppet 3.0; it is not new in Puppet 4. There was, however, a bug in Puppet 3 that templates still used dynamic scope. That was fixed in Puppet 3.5, but only prospectively -- that is, when the future parser is enabled. Defined types themselves went through the scoping change in Puppet 3.0.0, along with everything else. The scope changes were a big deal (and Puppet devoted considerable effort to alerting users to them) when they first went into place, but nowadays there's no big deal here.
it is causing breakage that is hard to even measure in my environment, which has relied on this behavior for tens of thousands of lines of code.
I'm sorry you're having that experience.
Is there any way at all to get this back?
No. Puppet scoping rules do not work the way you want them to do. That they did work that way in templates (but not most other places) in Puppet 3 was and still is contrary to Puppet's documentation, and never intentional.
Is this fixable, or do I attempt to wait for Puppet 5?
There is no way to get dynamic variable scoping in templates or elsewhere in Puppet 4, and I have no reason to think that there will be one in Puppet 5.
If you need a template to expand host variables from the scope of a particular class, then you can get that by evaluating the template in the scope of that class. Alternatively, an ERB template can obtain variables from (specific) other scopes by means of the scope object. On the other hand, if you want to expand the template in the scope of a defined type, then you could consider passing the needed variables as parameters of that type.
There may be other ways to address your problem, but I'd need more details to make any other suggestions. (And that would constitute a separate question if you choose to ask it here on SO.)

How to get XHP working in hack/hhvm on Ubuntu

I've installed hack-nightly and set up fastcgi using nginx by following the instructions on the website, however I'm getting an error when trying to create a simple file that uses xhp:
<?hh
$x = <html><body>hello</body></html>;
echo $x->toString();
Error:
Fatal error: Class undefined: xhp_html in /
Is there a step I need to take to enable this, or an additional import or package to install?
You need to include the XHP library, which you can find here. This defines the :xhp base class as well as all the HTML classes. Put all three files somewhere in your source tree then include init.php before doing anything with XHP.
There's currently a discussion going on in the HHVM.dev group on Facebook about if the library should be included by default or not, which you can view at https://www.facebook.com/groups/hhvm.dev/229787297210377/.

Resources