Improve error message if table is missing thead

If DataTables 1.9 is bound to a  missing a  the browser throws:
"oColumn is undefined"
at line 6461 at jquery.dataTables.js.
The error message should clarify that  must be added, or the plugin should function properly even if  is missing.

As you can see in this example ( http://datatables.net/release-datatables/examples/data_sources/js_array.html ) DataTables will add a THEAD element if it doesn't find one, so there is something else going on here. Can you link me to a test case please?

Hi,
Here is the offending table:

				Month
				Expenses

					1

					$1000

Oh I see! Thanks for the code. It doesn't mean the DataTables prerequisites though: http://datatables.net/usage/#prerequisites .
While I appreciate that an error message specifically for this would be helpful, it is rare that I see this issue flagged up, so I don't particularly want to add more bytes to the file for the error detection and the message. I'll keep an eye open, and if this does become more frequent I'll add in a specific error for this situation, but not make any changes at this time.
Thanks for flagging this up!

Is there a way for you to add error checking to the debug version (non-minimized) and strip it out in the min version?

I've long wanted to have a third version of DataTables what is exactly that - a debug version that provides a large amount of trace and log information to catch errors exactly like this. However, I've not had the time to implement that thus far, finding that other aspects of the project have taken priority, but it is something that I'm very much keeping in mind for future development.


WebView on Android 5.0

Why did the rigid body created by matter.js flicker inside the WebView on Android 5.0?

It's just rendering to a canvas, so I'm not sure what might make it flicker.
What hardware are you seeing this on?


New fixes

Co-authored-by: flame4ost<EMAIL_ADDRESS>Co-authored-by: best-lucky1030<EMAIL_ADDRESS>Co-authored-by: sleepmalc<EMAIL_ADDRESS>Minor bugs fixes

I am get pair achievements. Thank you

Create new pull request. Work

Write comment

Thank you)

lmfao. dafuq is happening here 🤣

B A D G E

Locking the conversation! Feel free to contribute via PRs and issues!


Adding Azure Demo and related Azure modules

This change contains Azure Compute related demo files as well associated AzureRM modules. I've run the demo script using alpha.9 release of PowerShell on Ubuntun 14.04 and Windows 10. Thank You!

Hi @KrishnaV-MSFT, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Krishna Vutukuri). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

Do we need to include the Azure-PowerShell License with the binaries?

Why binaries?  Can't we pull them in from somewhere?

@TravisEz13  @lzybkr you've raised a valid point and I agree with it. Let me explore alternatives. I could publish to PowerShellGallery but Install-Module is broken currently with -alpha.9 release. I will figure out a workaround.

Based on comments waiting on author

@KrishnaV-MSFT - instead of a new commit, can you rewrite history so that the binary files were never introduced.  Squashing the commits should do it.


Empty/Blank passwords don't seem to work.

Please include the following information in your ticket.

ibmmq-jms-spring version(s) that are affected by this issue.

com.ibm.mq
mq-jms-spring-boot-starter
2.0.9

Java version (including vendor and platform).
Launching defaultServer (Open Liberty <IP_ADDRESS>/wlp-1.0.22.cl180320180905-2337) on IBM J9 VM, version <IP_ADDRESS> - pxa6480sr5fp25-20181030_01(SR5 FP25) (en_US)
A small code sample that demonstrates the issue.

Using ibm-mqadvanced-server-dev helm chart, I left the app password blank, and I tried setting the password in mq-jms-spring to empty string, but I'm unable to successfully send a message,
2018-12-05T15:33:58.797Z AMQ5534E: User ID 'app' authentication failed
2018-12-05T15:33:58.797Z AMQ5542I: The failed authentication check was caused by the queue manager CONNAUTH CHCKCLNT(REQDADM) configuration.

com.ibm.msg.client.jms.DetailedJMSSecurityException: JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'stocktrader' with connection mode 'Client' and host name 'mqtrader1-ibm-mq.stocktrader(1414)'.
...
[err] Caused by:
[err] com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED').

exec'ing into the mq pod, and setting a password for the app user (and then configuring that password) allows the application to function as expected.
confirmed before changing app's password that /etc/shadow had no password configured for app.
confirmed that using passwd -d app to clear apps password reverts the app to being unable to work.

It looks like the queue manager really does not like trying to authenticate a user with no password.
I worked through the stack and was able to check the actual authentication steps made to verify a password which is empty. And it fails with both of the possible authentication strategies that MQ can use with the OS.
So you need to try to avoid doing any authentication at all. The default developer qmgr config which creates that "app" user with an empty password can be used by connecting to the correct channel and passing no credentials at all. No userid or password. The "app" user is then assigned to the connection based on CHLAUTH rules.
In the Spring Boot configuration, that can be done by setting the userid property to be blank.
ibm.mq.user=

If there is no property at all, then "admin" is the default ID asserted, but if the property exists and is empty, then the client doesn't try to send any credentials so you end up with the CHLAUTH map.

I know this issue is old an closed nut maybe @ibmmqmet you have an idea on how to achieve this:
I need to connect a Queue using only the userId and now password. Sadly if i leave ibm.mq.password blank, Spring / YAML will convert this to an empty string (https://github.com/spring-projects/spring-framework/issues/19986#issuecomment-453453915) which leads to the authentication not working.
Are there any workarounds for this?


IHostingStartup support for multiple key vaults

The IHostingStartup implementation for key vault in ASP.NET Core appears to support a single key vault configuration. I would like to retrieve secrets from an application specific key vault, as well as a more general shared key vault. An example of a shared secret might be a SendGrid API key. Is IHostingStartup support for multiple key vaults on the roadmap, or is the use of multiple key vaults in this way discouraged?
Thanks!

You can use AddAzureKeyVault (https://github.com/aspnet/Configuration/blob/d469707ab18eef7ed0002f00175a9ad5b0f36250/src/Config.AzureKeyVault/AzureKeyVaultConfigurationExtensions.cs#L134 ) extension method multiple times but I don't think support for multiple keyvaults via hosting startup is planned.


Foundry V10

Hi there.
I just updated my system to Foundry V10 b284.
I updated the Dee Sanction and now cannot access anything in my game world.  (!)
I just get a blank "black" screen with the foundry logo top left - not even the icons on the right hand side for chat etc.
I have another rig with foundry on and have updated it to V10.  Other games have ported over ok.
I set up a new install of Dee, and it loaded, but when it asked to import the compendia, it said it had items to import to armor, consequences and items, and had now hung (dead).
I have a backup of my old Dee world.
DO I try to revert to V9 or can we get Dee running on V10 ?
THanks
Richard

Update.
I uninstalled V10 and reinstalled a fresh V9 B280.  Managed to copy into the rebooted Dee folders the backup.  GOt everything back up and running.

Hi, sorry, only just saw this today. Yes, V10 is a trainwreck of an update...they've broken so much :-( It will take me a bit of time to update, but I'll let you know here when I have.

Thanks Chris.
I have a week off from running Dee ,so I'll give it a blast next week.
Richard
On Thu, 15 Sep 2022, 22:19 Chris Sharp, @.***> wrote:

@newbyr https://github.com/newbyr I have uploaded a new version 2.0.1
for FoundryVTT V10.
I think I've caught everything, but please give it a good test and see if
you can spot anything I might have missed.
Backup first, of course!
—
Reply to this email directly, view it on GitHub
https://github.com/chrisesharp/foundryvtt-dee-sanction/issues/22#issuecomment-1248571709,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZJ3MWTJIMMPQMPFJM3F3MTV6OAFJANCNFSM6AAAAAAQJAMQBY
.
You are receiving this because you were mentioned.Message ID:
@.***>


Core: Upgrade react-native-svg

This is the latest recommended version

+1, I would like those changes.
Necessary on Expo SDK 47 to avoid dependency conflicts.


Proposal: Configurable gRPC Middleware Pipelines

/area runtime

/area operator
/area placement
/area docs
/area test-and-release

NOTE: This proposal is to add a transport specific middleware implementation to compliment the existing HTTP middleware but doesn't exclude a transport agnostic middleware solution being added later.

What?
Allow Dapr to support user configurable gRPC middleware (interceptor) pipelines. I propose that we use a similar structure to how we currently support HTTP pipelines to make it consistent. This includes the definition of the middleware as components and the configuration of the middleware pipeline itself using the configuration file.
Why?
Once available, we can plugin to existing go grpc middleware such as https://github.com/grpc-ecosystem/go-grpc-middleware
(eventually WASM for custom middleware) and let users opt-in to having it on their Dapr  gRPC APIs.
AFAIK most of the SDKs use the gRPC API for actors and thus this change will also have benefits there.
How?
GRPC Middleware Components
Unlike HTTP middleware which is defined by a single function signature, GRPC middleware (a.k.a. interceptors) comes in 4 types:

UnaryClient
StreamClient
UnaryServer
StreamServer

In order to support a future proof approach to gRPC middleware pipelines we should allow (not block) the eventual definition of all of these types as Dapr components types.
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: grpcmiddleware
spec:
  version: v1
  type: middleware.grpc.[server|client].[unary|stream]
  ...

I've inverted the order of words from the gRPC type naming ([unary|stream].[server|client]) as I think [server|client].[unary|stream] is more intuitive when used in the pipelines (see below).
In terms of runtime implementation, we can share a single GRPCMiddlewareRegistry that supports registering and creating different grpc middleware types and has multiple internal maps to avoid too much code pollution.
GRPC Middleware Pipelines
As mentioned above, for consistencies sake I think we should follow the same pattern as the HTTP middleware pipeline and use a configuration spec to define gRPC middleware pipelines too.
There are many locations within daprd where we either host a gRPC server or use a gRPC client (see: diagram)
I propose that we only allow users to configure the gRPC pipelines in the following places:

Dapr's external gRPC API
Dapr's gRPC app channel

And for now, not in the following places:

Dapr's internal gRPC API
Dapr's internal gRPC client (for service invocation)
Dapr's control plane clients

If we can think of a good use case to support user configurable gRPC interceptors on the daprd internal clients and servers then we can expand to support this later but I currently think this would cause more problems that it solves.
Dapr's External gRPC API
Dapr's gRPC API can be configured using a GRPCPipelineSpec in the configuration file. Where grpcPipeline is the reserved name of the pipeline.
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: grpcpipeline
  namespace: default
spec:
  grpcPipeline:
    unary:
      - name: first
        type: middleware.grpc.server.unary.first
      - name: second
        type: middleware.grpc.server.unary.second
   stream:
      - name: first
         type: middleware.grpc.server.stream.first
      - name: second
         type: middleware.grpc.server.stream.second

We separate out the type of middleware into individual pipelines (unary pipeline and stream pipeline) as they will be added to different interceptor chains on the gRPC server itself and cannot be mixed.
Dapr's gRPC App Channel
Dapr's gRPC App Channel is the channel over which daprd communicates with the user's app when configured to use the gRPC protocol. This means that we can construct a client middleware pipeline for requests sent to the user's app. This will allow the users to avoid having to host additional middleware on their app's APIs when using gRPC with daprd. This is a lower priority feature than adding middleware to the Dapr gRPC API but I think it still offers some value to the user such as adding contextual tags to the request context.
The app channel pipeline can be configured using a GRPCAppPipelineSpec in the configuration file. Where grpcAppPipeline is the reserved name of the pipeline.
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: grpcapppipeline
  namespace: default
spec:
  grpcAppPipeline:
    unary:
      - name: first
        type: middleware.grpc.client.unary.first
      - name: second
        type: middleware.grpc.client.unary.second
   stream:
      - name: first
         type: middleware.grpc.client.stream.first
      - name: second
         type: middleware.grpc.client.stream.second

Diagram

Tasks
This proposal can be broken down into the following implementation tasks:

Add support for gRPC unary server middleware to Dapr's external gRPC API
Add support for gRPC stream server middleware to Dapr's external gRPC API
Add support for gRPC unary client middleware to Dapr's gRPC app channel
Add support for gRPC stream client middleware to Dapr's gRPC app channel

Issues

https://github.com/dapr/dapr/issues/4022
https://github.com/dapr/dapr/issues/2386
https://github.com/dapr/dapr/issues/1857

@jjcollinge great proposal! I believe this is a vital aspect of Dapr extensibility. One thing that caught my eye in your proposal was the mention that middleware for the gRPC app channel has lower priority than gRPC API.
I think the two go hand in hand, similar to the HTTP middleware pipeline. Any request manipulation on the sender app side must have a counterpart on the receiving end unless I am missing something from your proposal.

/no-stale

/assign

Please, create a proposal in proposals repo.

This didn't make it in for 1.14. Targeting 1.15


general query about "factor " terms

I notice that
GO:0003716 obsolete RNA polymerase I transcription termination factor activity
is obsoleted with the comment
This term is obsolete.
This term was obsoleted because it is essentially identical to a Process term (specifically the Biological Process term which has been selected as a term to consider for reannotation), i.e. it is defined only in terms of the process it acts in and it does NOT convey any information about the molecular nature of the function or whether the function is based on binding DNA, on interacting with other proteins, or some other mechanism. To transfer all annotations without review, the BP term indicated is considered to be equivalent and thus the only appropriate destination for all annotations. To reannotate to a MF term, you will probably need to revisit the original literature or other primary data because this "MF" term was not defined in terms of mechanism of action and there are multiple possibilities in the revised MF structure. In reannotation, please also consider descendent terms of the suggested MF terms as a more specific term may be more appropriate than the MF terms indicated. Please be aware that you may wish to request a new term if the mechanism of action of this gene product is not yet represented or if you are annotating for an RNAP different than one for which there is a specific suggested term. Also note that if there is no information about how the gene product acts, it may be appropriate to annotate to the root term for molecular_function.
but we do not apply this rule consistently because we still have terms
GO:0003746
Name	translation elongation factor activity
Definition	Functions in chain elongation during polypeptide synthesis at the ribosome.
GO:0003743 translation initiation factor activity
Functions in the initiation of ribosome-mediated translation of mRNA into a polypeptide
transcription factor activity, protein binding
nteracting selectively and non-covalently with any protein or protein complex (a complex of two or more proteins that may include other nonprotein molecules), in order to modulate transcription. A protein binding transcription factor may or may not also interact with the template nucleic acid (either DNA or RNA) as well.
transcription factor activity , RNA polymerase II core promoter sequence-specific binding involved in preinitiation complex assembly
GO:0045183 translation factor activity, non-nucleic acid binding
etc, etc
which are exactly the same, a "factor" involved in a process

Hi Val,
I agree that the 'factor' argument is not completely convincing.
Do you suggest we merge those MF into their respective BP ? for example 'translation initiator factor activity -> translation initiation', etc (although I am not sure we can do a Function/process merge).
Thanks, Pascale

Actually a "factor" term which is precisely positioned as an "RNA binding" term for example, might be OK. In this case it might be representing more accurately how the community refer to these functions.   Maybe it is better to leave it be for the time being and just deal with the ones which do not say anything about the molecular function at all?

The lack of a specific, well-defined GO molecular function, i.e. the inability to define the MF term for "transcription factor activity" more specifically than somehow involved in the BP of "transcription" was exactly why some of the transcription factor terms were obsoleted. The idea at the time was that the MF term should include some description of HOW the BP is accomplished. It was also hoped that this would satisfy a complaint I received from a researcher at a transcription meeting that she could never remember whether she should use the MF term or the BP term for enrichment analyses since they seemed indistinguishable.
However, there was never any follow through to treat other preexisting "factor" terms similarly and there has been discussion about bringing "transcription factor activity" back...

Hi @krchristie
I think the main issue with transcription is that the process is way overused, in such a way that it's not possible to get all transcription factors by using the BP terms. (That being said, I think the ontology is designed to allow this - just the annotations are not strict enough for this).
What do you think ?
Pascale


Missing transformer in data-plane-selector-control-api

Bug Report
Describe the Bug
The getAllDataPlaneInstances endpoint throws a 500 because the DataPlaneInstance --> JsonObject transformer is not registered.
https://github.com/eclipse-edc/Connector/blob/6e7bb67dfbd08d5a41300af15db2688691a3017a/extensions/data-plane-selector/data-plane-selector-control-api/src/main/java/org/eclipse/edc/connector/dataplane/selector/control/api/DataplaneSelectorControlApiController.java#L103-L113
https://github.com/eclipse-edc/Connector/blob/6e7bb67dfbd08d5a41300af15db2688691a3017a/extensions/data-plane-selector/data-plane-selector-control-api/src/main/java/org/eclipse/edc/connector/dataplane/selector/control/api/DataplaneSelectorControlApiExtension.java#L58-L66
Context Information

EDC 0.7.0

Possible Implementation
I see two possible solutions:

Register the transformer
Delete the endpoint, as this is a duplicate of the only endpoint (at least in V3) in the data-plane-selector-api extension.
https://github.com/eclipse-edc/Connector/blob/6e7bb67dfbd08d5a41300af15db2688691a3017a/extensions/data-plane-selector/data-plane-selector-api/src/main/java/org/eclipse/edc/connector/dataplane/selector/api/v3/DataplaneSelectorApiV3Controller.java#L32-L56

I vote solution 1, deletion is not correct, because control and management context should be kept separated as they serve separate needs, so this duplication is accepted (and I'll say needed) tho.

also, generally we shouldn't just remove endpoints without deprecating them first.


Tag change not working in project page

Describe the bug
When try to change tag of multiple company the checking the checkbox (Add to existing tags) is not working
Expected behavior
It should add to existing tags when we checked the checkbox
Screenshots

https://www.berrycast.com/conversations/bba2b403-55d4-5413-ba2c-33c4b096d75e


Provide a way to enhance generated documentation

First of all: Thank you for jaxrs-analyzer!
It would be great if it would provide a way to enhance the generated documentation by descriptions to resources and methods either via

recognizing Swagger annotations
providing your own annotations
special Javadoc annotations (to avoid further link dependencies?)
accepting a yaml/xml/properties file

If such a facility should already exist please add instructions to the plugin documentation.

Hi, thanks for using my tool!
Funnily just in these days I've finished the first version of JavaDoc support. You can now describe JAX-RS methods and parameters directly in the JavaDoc which will be incorporated into the Swagger output. The feature will be included in version 0.12 (which is just about to be released).

Wow, great! I'll gladly use the new feature once it's out :-)

Update: 0.12 is published. Also see https://blog.sebastian-daschner.com/entries/javadoc_jaxrs_analysis

Is this working in the current version?

Yes it is

Can you show me an example? I'm not being able to use it. The produced swagger.json ignores all java docs and swagger annotations..

Swagger annotations are not supported. You can have a look at the JavaDoc support here: https://blog.sebastian-daschner.com/entries/javadoc_jaxrs_analysis


Default notebook.fold/unfold keybindings are invalid

Open default keybindings json and you'll see problems. The schema requires args, we should follow our own rules:

They should be optional, good catch ;)

I don't how to express this with the keybinding args: what I did
args: [
	{
		name: 'index',
		description: 'The cell index',
		schema: {
			'type': 'object',
			'required': ['index', 'direction'],
			'properties': {
				'index': {
					'type': 'number'
				},
				'direction': {
					'type': 'string',
					'enum': ['up', 'down'],
					'default': 'down'
				},
				'levels': {
					'type': 'number',
					'default': 1
				},
			}
		}
	}
]

I want to make the args optional, but when a arg is provided, it must at least has index and direction properties. However, it seems that if the arg has required property, the arg is then required for the command, which IMHO is not correct.
@aeschli may I ask what's the right thing to do here?

@jrieken Looks like what we talked about lately. Did you find a solution?


binance-btc.zip

unfortunately the binance-btc.zip is missing
at the fullhistory dataset

Still doing it from gekko interface. Have 1 year for almost all coins. Gonna post it on another google drive.

what's the word on this?


Redesign selinux::module parameters

Current situation

it only allows to build modules with only *.te files. no *.if and .fc extensions are possible
it does not allow to install an already compiled module
with some policies it's not needed to install make and co. it may install too much software not required and not wishfull on some systems.

Proposed interface
# only minimal module building (checkmodule, semodule_package)
selinux::module { 'mymodule':
  builder => 'minimal',
  source_te => 'puppet:///modules/profile/mymodule.te',
}

# this will install additional required packages
# and build with make -f /usr/share/selinux/devel/Makefile
selinux::module { 'mymodule':
  ensure => 'present',
  builder => 'makefile', # DEFAULT
  source_te => 'puppet:///modules/profile/mymodule.te',
  source_if => 'puppet:///modules/profile/mymodule.if',
  source_fc => 'puppet:///modules/profile/mymodule.fc',
}

# no compiling at all, only loading an already compiled binary
selinux::module { 'mymodule':
  source_pp => 'puppet:///modules/profile/mymodule.pp',
}

# remove a module
selinux::module { 'mymodule':
  ensure => 'absent',
}

selinux::module { 'mymodule':
  ensure => 'disabled',
}

Things to consider

newer semodule utilities have the ability to specify a module priority (-X,--priority=PRIORITY) which isn't supported by the selmodule type. semodule defaults to priority 400 if nothing is defined (seen on EL7, Fedora 25)
semodule provides the ability to disable and enable modules which the selmodule type does not support, valid usecase was given in #60

@rnelson0 and @oranenj  - your opinions?

Why not just a source_dir parameter? I think for the simple cases we should allow source_te perhaps as well, but having to specify everything separately is not good either, I think.

Why not just a source_dir parameter? I think for the simple cases we
should allow source_te perhaps as well, but having to specify
everything separately is not good either, I think.

I personally have all my custom modules in 1 folder. this would sync all
my modules at once.

@oranenj - tried to write your proposal down as code.
selinux::module { 'mymodule':
  ensure => 'present',
  builder => 'makefile', # DEFAULT
  source_dir => 'puppet:///modules/profile/mymodule',
}

how would I distinct if a user wants to load a pre-compiled module?
will it load and build one module or all modules in dir?
howto ensure the content of the directory is named as expected?
if we stop managing the directory, do we remove it on the system?

what about dedicated defined types?
selinux::module_build::dir { 'mymodule':
  ensure => 'present',
  builder => 'makefile', # DEFAULT
  source => 'puppet:///modules/profile/mymoduledir',
}

selinux::module_build { 'mymodule':
  ensure => 'present',
  builder => 'makefile', # DEFAULT
  source  => 'puppet:///modules/profile/mymodule.te',
  source_fc => 'puppet:///modules/profile/mymodule.fc',
  source_if => 'puppet:///modules/profile/mymodule.if',
}

selinux::module { 'mymodule':
  ensure => 'present',
  # if we wanted a default for source, we needed to ensure that all module_build
  # builded modules reside at an expected place.
  source => ' puppet:///modules/profile/mymodule.pp',
}

seems bloated to me and the.
Still find the dedicated param per file the better option. I can easily validate the parameter, save the files with expected names, decide what the user wants (compile+load or just load). And the parameter names are descriptive/indicative what the content should be (at least IMHO).

I agree, and like how this looks. We have had the need to setup custom policies as RPMs due to the need to keep "make" and company off our production servers. This would be nice. It does occur to me, that in addition, there should be a way to ensure the version, somehow, but maybe that would be implemented by the type/provider?
I can see the case where the policy is updated on the puppet server and the update needs to be propagated to the servers that it is installed on. Maybe RPM's are not such a bad idea, after all? hopefully I didn't complicate this :)
~tommy

Hmm, yeah. I can see how separate parameters would make the implementation much easier.
We need to be really careful with implementing this, since there are many corner cases where a compilation/installation/upgrade of the SELinux module might fail, and we don't want to end up in a situation where the next puppet runs won't even notice that something is wrong as seems to be the case with the current version sometimes.
I think the module definitely should manage the source dir and the source files completely (eg. something like $vardir/puppet-selinux/$modulename), and purge them when it stops managing the module (it does not need to remove the module). Perhaps output the resulting .pp file into another path that does not get purged?
Also, how does selmodule behave when the policy source is updated without corresponding a version bump in the source? IIRC the current version has problems with that case. Can we detect such a case and issue a warning? The File resource has validate_cmd nowadays, those might be useful.
It might be possible to write our own provider for selmodule that extends the built-in provider with any functionality we might need.

We need to be really careful with implementing this, since there are many corner cases where a
compilation/installation/upgrade of the SELinux module might fail, and we don't want to end up in a
situation where the next puppet runs won't even notice that something is wrong as seems to be the case
with the current version sometimes.

regarding the build/load indempotentcy or constant error-ing when things fail. i thought about something like:
class selkinux::config::module {
  # manage dir to store sources/binaries of selinux modules
  # purge not puppet managed files
  file { '/var/lib/puppet/puppet-selinux/modules':
    ensure => 'directory',
    recurse => true,
    purge => true,
    force => true,
  }
}

define selinux::module {
  require selinux::config::module

  #file resources for
  #   /var/lib/puppet/puppet-selinux/modules/$title.te,
  #  /var/lib/puppet/puppet-selinux/modules/$title.if,
  #  /var/lib/puppet/puppet-selinux/modules/$title.fc,   ->

  exec { "build-module-$title":
    command => "build-command || (rm -f /var/lib/puppet/puppet-selinux/modules/$title.pp && exit 1)",
    unless => 'test -f /var/lib/puppet/puppet-selinux/modules/$title.pp.needsload && test -f /var/lib/puppet/puppet-selinux/modules/$title.pp',
  } ->
  exec { 'build-module-$title-needs-load':
    # will only be run if previous exec did succeed and the needsload stanza does not exist
    command => 'touch /var/lib/puppet/puppet-selinux/modules/$title.pp.needsload',
    unless => 'test -f /var/lib/puppet/puppet-selinux/modules/$title.pp.needsload',
  } ->
  selmodule {  $title:
    ensure => present'
  } ~>
  exec { 'build-module-$title-load-succeeded':
    # will only be run if selmodule did succeed and .loaded stanza does not exist.
    command => 'rm /var/lib/puppet/puppet-selinux/modules/$title.pp.needsload && touch /var/lib/puppet/puppet-selinux/modules/$title.pp.loaded',
    unless => 'test -f /var/lib/puppet/puppet-selinux/modules/$title.pp.loaded',
  }

  # ensure files do not get purged (if they exist)
  file { [
    /var/lib/puppet/puppet-selinux/modules/$title.pp,
   /var/lib/puppet/puppet-selinux/modules/$title.pp.needsload,
   /var/lib/puppet/puppet-selinux/modules/$title.pp.loaded
  ]:
  owner => 'root',
  group => 'root',
  mode => '0640',
}

Also, how does selmodule behave when the policy source is updated without corresponding a version
bump in the source? IIRC the current version has problems with that case. Can we detect such a case and
issue a warning? The File resource has validate_cmd nowadays, those might be useful.

the the selmodule utility happily installs/overrides an already existing module with -i. it doesnt require a force or somewhat. this is what the selmodule type uses.
unfortunatly selinux utility upstream thought that version numbers in modules are useless and removed the ability to display module versions with the semodule utlity. Fedora 25 example:
$ sudo semodule -l | head -5
abrt
accountsd
acct
afs
aiccu
$ sudo semodule -lfull | head -5
400 sandbox           pp disabled
400 tmpreaper         pp
200 container         pp
100 abrt              pp

no versions anymore.
They even introduced this new userspace utlities with EL 7.3 and broke the selmodule types syncversion parameter (https://docs.puppet.com/puppet/latest/type.html#selmodule-attribute-syncversion). Customers complained about this change within a major version and they will re-introduce it for 7.3 as bugfix.
anyway you cannot get the version number anymore. so you really don't know which version of your module is loaded.  the only way is to track exit codes of commands and ensure they get retried every puppet run.

@oranenj but maybe this could also be implemented as type/provider - but on the type/provider side i'm very newbie. I think it would then need a dedicated type/provider for building modules as it is a complet other business than loading/removing a module.

ways to compile a module:
the refpolicy style way:

having a directory with mymodule.te, mymodule.if and mymodule.te files (only .te is mandatory)
to compile run make -f /usr/share/selinux/devel/Makefile mymodule.pp
creates a tmp/ file with temp files an the mymodule.pp, only recompiles the module if it thinks the source has changed since
requires the selinux-policy-devel  package (and tools like make which it depends on)

the minimal way:

have a *.te and a *.fc file (only .te is mandatory)
create *.mod file: /usr/bin/checkmodule -M -m -o ${name}.mod {name}.te
create *.pp file: /usr/bin/semodule_package -o ${name}.pp --fc ${name}.fc -m ${name}.mod
doesn't require selinux-policy-devel - but you can't use the interfaces and patterns

I implemented the suggested changes in the linked PR and I'm pretty happy with how it looks. If no-one has any ideas for an even better interface, feel free to merge that in.


⚠ Bofrost.be has degraded performance

In 61df301, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 886 ms

Resolved: Bofrost.be performance has improved in 9624674 after 6 minutes.


Normal maps

@brechtvl wrote:
It's not clear to me if these parameters expect tangent space or world/rendering space normals. I would guess it's world/rendering space if bump maps are to be supported as well, and because also for normal maps there might be various additional controls that feel out of scope for OpenPBR.

Just to note, I think that unambiguous specification of the normal map conventions is something that would be very valuable to have in the model, eventually, to eliminate the pain associated with the convention being ill-defined, mentioned by @anderslanglands and @meshula.
But i'd defer this for a later point in time once (perhaps) the model is more established, as to do it now would add quite a bit of complexity and it's not necessarily clear what parametrization to choose (or how the lack of it impacts the integration of the model into pipelines and workflows).


[Bug]: Appium is giving ERROR "Remote server was still not ready after 10 minutes."

Describe the bug
Appium is giving ERROR "Remote server was still not ready after 10 minutes."
when run Appium2 on real device
Link to SHAFT_Engine Console logs
SHAFT_Log1.txt
SHAFT :v7.1.20230220
Appium2
Mobile Device OS: Android
Desktop OS: win10
///////////////////////////////
Screenshot

Hello @Salma2018170,
This is a known issue and was fixed in the latest release as per the release notes
https://github.com/ShaftHQ/SHAFT_ENGINE/releases/tag/7.1.20230222
Kindly upgrade and try again. Feel free to reopen this issue if needed.


New architecture for template generator

Why?
It is now much easier to automatically compute constants required for code generation from within gurvy instead of manually copy-pasting from sage.  (Also, I did some house cleaning.  There's still lots more cleaning needed though.)
The flagship example is the methods MulByNonResiduexPowery found in frobenius.go for each curve.  Another example is the inverse of 2 modulo p used in curves with a field tower of the form used by BLS12-381, BW6-761.  There are several other constants whose computation could also be automated in this way.
In the future, it will be easier to add new constants or new curves to gurvy.  Perhaps one could even use this new architecture to reduce reliance on sage to make tests, though I suspect the complete elimination of sage from the process is not yet worth the effort.
Overview
Prior to this PR, all code (goff, tower, curve groups, pairing) for each curve was generated from a single executable invoked from the root directory via go generate ./internal/....  This single executable prevented the use of code generated earlier in the process to generate subsequent code.  For example, it was not possible to use code from goff or the field tower to generate code for the pairing.  Thus, it was impossible, for example, to automate the computation of constants used in Frobenius computations.  Instead, these constants must be computed manually in sage and copy-pasted into gurvy's Go codebase.
By contrast, the new architecture splits code generation into four worker executables: one for each of goff, tower, curve groups, pairing.

Each worker is invoked under-the-hood via go run, which automatically compiles the executable from source before executing.  Some of that source is generated by previous workers, so newly generated code is instantly compiled into the next worker's executable.
The new architecture

The master executable is located at /internal/generators/main.go.  It contains all the info required to generate all the curves.
Instead of passing all this info to the four worker executables via terminal arguments, the master executable generates code in the curve package.
The four worker packages are primefields, tower, gpoint, and pairing.  Each imports from curve---that's how they get their arguments.
A minimalist package has at least two files:├── generator.go
└── main
    └── main.go

Template execution occurs in generator.go.  The master executable invokes main/main.go via go run.  main.go is typically just a wrapper that imports curve (as a way to get curve info) and invokes generator.go.

The primefields worker has this simple structure.  All the work is done by goff, so no more code is needed here.

All workers other than primefields provide their own templates instead of invoking goff.  For these workers, template code appears in a templates/ directory.
Some workers have code generated for them by other workers.  Such code, if present, appears at the worker's root directory in generated-code.go.

These workers provide a template for themselves.  This template is usually nothing more than an import statement, so it is included in generator.go.  See for example: https://github.com/ConsenSys/gurvy/blob/17fb8608bf278e67ad264849ef11ed3a3d260f0b/internal/generators/tower/generator.go#L103
Worker code generation is invoked from the master executable in main.go.  Example: https://github.com/ConsenSys/gurvy/blob/17fb8608bf278e67ad264849ef11ed3a3d260f0b/internal/generators/main.go#L130

Some workers might have complicated generation code.  In order to keep generate.go simple, this extra generation code is typically split into other source files at the worker's root.  (Example: computation of Frobenius constants in pairing/constants.go.)

By the way, this PR also contains some new code for BW6-761 pairing: Frobenius and final exponentiation.
TODO for BW6-761

mulAssign for lineEval to finish off the pairing
tests

We now have a working pairing for BW6-761.  Ready to merge.
Several optimizations remain TODO.  For example:

Miller loop is currently the "naive" method with 190-bit loop length instead of 127.  Reference sage code for the "naive" Miller loop.  Need to get fully optimized Miller loop with 127-bit loop length.  Reference sage code for optimized Miller loop.
Need to hard-code the non-residue constants like we do for other curves.  Currently we do an expensive conversion from string inside the Miller loop.  See for example: https://github.com/ConsenSys/gurvy/blob/c023044951d4589aef9a877b9d60af447314b090/bw6_761/pairing.go#L414

Clean-up TODO:

Work for #7 has begun with BW6-761.  The methods MulByVMinusThree, MulByVminusTwo, MulByVminusFive introduced for BW6-761 appear in pairing.go.  Need to do the same for other curves and modify the template generator accordingly.
The template for pairing.go is a mess.  Most of the code here is curve-specific.  Most or all of this code should be removed from the template generator.


Rename managing-disruptive-comments.md to managing-disruptive-comment…

…s.md.

Why:
Closes [issue link]

What's being changed:

Check off the following:

[x] I have reviewed my changes in staging (look for the latest deployment event in your pull request's timeline, then click View deployment).
[x] For content changes, I have completed the self-review checklist.

Writer impact (This section is for GitHub staff members only):

[x] This pull request impacts the contribution experience

[x] I have added the 'writer impact' label
[x] I have added a description and/or a video demo of the changes below (e.g. a "before and after video")

tabaco.tv