A lot of global lock test errors

--- FAIL: TestLockAndDo (15.23s)
    --- FAIL: TestLockAndDo/redis (15.00s)
        globallock_test.go:89:
            	Error Trace:	/home/runner/work/gitea/gitea/modules/globallock/globallock_test.go:89
            	            				/opt/hostedtoolcache/go/1.23.2/x64/src/runtime/asm_amd64.s:1700
            	Error:      	Received unexpected error:
            	            	lock already taken, locked nodes: [0]
            	Test:       	TestLockAndDo/redis
        globallock_test.go:89:
            	Error Trace:	/home/runner/work/gitea/gitea/modules/globallock/globallock_test.go:89
            	            				/opt/hostedtoolcache/go/1.23.2/x64/src/runtime/asm_amd64.s:1700
            	Error:      	Received unexpected error:
            	            	lock already taken, locked nodes: [0]
            	Test:       	TestLockAndDo/redis

...
...
...
         globallock_test.go:89:
            	Error Trace:	/home/runner/work/gitea/gitea/modules/globallock/globallock_test.go:89
            	            				/opt/hostedtoolcache/go/1.23.2/x64/src/runtime/asm_amd64.s:1700
            	Error:      	Received unexpected error:
            	            	lock already taken, locked nodes: [0]
            	Test:       	TestLockAndDo/redis
        globallock_test.go:89:
            	Error Trace:	/home/runner/work/gitea/gitea/modules/globallock/globallock_test.go:89
            	            				/opt/hostedtoolcache/go/1.23.2/x64/src/runtime/asm_amd64.s:1700
            	Error:      	Received unexpected error:
            	            	lock already taken, locked nodes: [0]
            	Test:       	TestLockAndDo/redis
        globallock_test.go:95:
            	Error Trace:	/home/runner/work/gitea/gitea/modules/globallock/globallock_test.go:95
            	            				/home/runner/work/gitea/gitea/modules/globallock/globallock_test.go:43
            	Error:      	Not equal:
            	            	expected: 1000
            	            	actual  : 776
            	Test:       	TestLockAndDo/redis
FAIL
coverage: 91.8% of statements
FAIL	code.gitea.io/gitea/modules/globallock	23.286s

How were these errors reproduced? Is it possible that the previous test was aborted and the lock was not released, and the test was restarted before the lock expired?

I cannot reproduce it on my local machine. macOS go1.23.2 run with TEST_REDIS_URL=redis://<IP_ADDRESS>:6379/15 go test -tags=sqlite -run=TestLockAndDo.

How were these errors reproduced? Is it possible that the previous test was aborted and the lock was not released, and the test was restarted before the lock expired?

No idea, I just caught it from github actions. https://github.com/go-gitea/gitea/actions/runs/11459790779/job/31885087438

It fails a lot, probability > 5% or 10%


Add commands to tor.main for key generation

Modify tor to add a new CLI command --gen-keypair (or something to that effect). It will take in a type parameter of x25519 or ed25519 to either generate v3 hidden service auth keys (x25519), or a new onion address (ed25519).
This will allow for key generation w/o the need to be running tor.

This work will commence after a 2.0.0-alpha release of kmp-tor. Want to get that out so it can mature as much as possible before implementing new features. This will happen in maybe a 2.1.0 release or something.

Moved to https://github.com/05nelsonm/kmp-tor-resource


sfpowerscripts:orchestrator:validate fails in authenticating to created scratch org

Validate utilizes sfdx force:auth:jwt:grant to authenticate to devhub and fetch the scratch org from the pool.  Recent update of the cli has deprecated the flag (though its not supposed to be immediate)  has made validate unable to login to the fetched scratch org
Linked Issue https://github.com/forcedotcom/cli/issues/801

This is an issue with the recent version of the CLI, sfpowerscripts has now been updated to use sfdx auth  instead.
Fixed in 1.6.11

This is an issue with the recent version of the CLI, sfpowerscripts has now been updated to use sfdx auth  instead.
Fixed in 1.6.11


I need help , some form of wrap text in excel

I need to be so

it looks like this , when you export

is posible?

Hello,
Please use the provided github issue template (https://github.com/Maatwebsite/Laravel-Excel/blob/2.1/.github/ISSUE_TEMPLATE.md) which was automatically inserted on issue create. Without the template, we are not able to efficiently look at your issue/question/proposal.


TAN on Linux?

It's possible to build TAN on linux. Will the provided linux binaries work with TAN binaries with the same public header files as the windows version? Thanks.

@duplexsystem While it might be possible to build Steam Audio with TAN support on Linux, now that the entire SDK is open source, we have not built or tested this combination, and do not have any plans to support it. That said, if you are able to get this to work, feel free to open a pull request.


[DOC] SETUP without the database

If the user does not have an active database like we do, he cannot use any of these services since he does not the database or his database is not in the right structure.
Should we add database description or database structure to the instructions or do we not care?

Yes, I think this is necessary. At least in the document similarity microservice the methods rely on the fact that the database has a structure like ours, with the same names of tables and columns.


Missing "Engine Type" when installed

After building the jar and adding to Fortify SSC, the parser does not show any value for "Engine Type" and cannot be enabled.

This value is available after enabling plugin. It is Fortify SSC limitation.

How do I enable the plugin then? After attempting to enable the plugin I get a "Failed to Enable" error

Is it possible to get error details from ssc.log file?
Also, what version of SSC is used?

We're using version 17.20
I'm working on getting the logs

OK, 2.0.1 plugin should be compatible with 17.20. Is it first time when plugin is installed? Or you used older version of plugin before?

This is the first time installing any parser plugin

I'm not seeing much in these logs, no errors at least. What should a successful install and enabling look like?
2018-04-26 17:55:28,550   [INFO] com.fortify.plugin.connector.manager.PluginManagerServiceImpl - Sending INSTALL request
2018-04-26 17:55:28,550   [INFO] com.fortify.plugin.connector.PluginFrameworkBrokerUriResolver - Using plugin framework broker URI tcp:
2018-04-26 17:55:28,708   [INFO] com.fortify.plugin.connector.manager.PluginManagerServiceImpl - Returned from INSTALL request
2018-04-26 17:55:28,708   [INFO] com.fortify.manager.plugin.connector.PluginPersistenceServiceImpl - Installing plugin com.blackducksoftware.fortifyparserplugin, version 2.0.1, UUID:
2018-04-26 18:03:32,760   [WARN] com.fortify.manager.service.PluginManagementHelperServiceImpl - Helper: Requesting START for : com.blackducksoftware.fortifyparserplugin
2018-04-26 18:03:32,760   [INFO] com.fortify.plugin.connector.manager.PluginManagerServiceImpl - Sending START request
2018-04-26 18:03:32,760   [INFO] com.fortify.plugin.connector.PluginFrameworkBrokerUriResolver - Using plugin framework broker URI tcp:
2018-04-26 18:03:32,773   [INFO] com.fortify.plugin.connector.manager.PluginManagerServiceImpl - Returned from START request

Ok, thanks.
Could you please get content of this log file:
{ssc.user.home.folder}.fortify\ssc\plugin-framework\logs\plugin-framework.log
It should have more details about this failure.

The member of my team who can ssh into the server just left. Lemme try get the logs from him tomorrow. What would I be looking for in plugin-framework.log?

For any error messages.

right, but what entries are normally written to plugin-framework.log? does it only log errors?

Oh, I see. It has both types of messages - important diagnostic entities (info / debug level) and errors (exceptions with stack traces).
Framework is actually the module that serves plugins. SSC is a client of this module. Looks like that some problem happens on the framework side and it was not able to install the plugin correctly. So, I hope that this log contains exact reason.
Meanwhile I verified compatibility one more time and install 2.0.1 plugin in 17.20, everything worked fine. So, it might be some kind of environment specific problem.

Oh, that clears up a lot. Thanks Evgeny! I'll take a look tomorrow and see if I can find an error entry in the log

Hey, so I grabbed the logs and found these entries:
2018-04-26 17:42:55,841 | ERROR | pool-29-thread-1 | ProxyWeavingHook                 | 32 - org.apache.aries.proxy.impl - 1.0.6 |  There was a serious error trying to weave the class com.blackducksoftware.integration.fortify.parser.BlackDuckIssueParser. See the associated exception for more information.
java.lang.IllegalArgumentException
at org.objectweb.asm.ClassReader.(Unknown Source)[39:org.objectweb.asm.all:5.2.0]
at org.objectweb.asm.ClassReader.(Unknown Source)[39:org.objectweb.asm.all:5.2.0]
at org.apache.aries.proxy.impl.weaving.WovenProxyGenerator.getWovenProxy(WovenProxyGenerator.java:38)[32:org.apache.aries.proxy.impl:1.0.6]
at org.apache.aries.proxy.impl.weaving.ProxyWeavingHook.weave(ProxyWeavingHook.java:104)[32:org.apache.aries.proxy.impl:1.0.6]
at org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2425)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2112)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)[org.apache.felix.framework-5.4.0.jar:]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_161]
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)[org.apache.felix.framework-5.4.0.jar:]
at com.fortify.plugin.runtime.helpers.BundleUtils.loadPluginProvider(BundleUtils.java:106)[13:com.fortify.plugin.runtime:1.1.183]
at com.fortify.plugin.runtime.helpers.StandardPluginBundleExtender.loadPluginProvider(StandardPluginBundleExtender.java:118)[13:com.fortify.plugin.runtime:1.1.183]
at com.fortify.plugin.runtime.helpers.StandardPluginBundleExtender.newPluginServiceInstance(StandardPluginBundleExtender.java:98)[13:com.fortify.plugin.runtime:1.1.183]
at com.fortify.plugin.runtime.internal.PluginBundleTracker.addingBundle(PluginBundleTracker.java:59)[13:com.fortify.plugin.runtime:1.1.183]
at com.fortify.plugin.runtime.internal.PluginBundleTracker.addingBundle(PluginBundleTracker.java:32)[13:com.fortify.plugin.runtime:1.1.183]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469)[org.apache.felix.framework-5.4.0.jar:]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:415)[org.apache.felix.framework-5.4.0.jar:]
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)[org.apache.felix.framework-5.4.0.jar:]
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)[org.apache.felix.framework-5.4.0.jar:]
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.Felix.startBundle(Felix.java:2172)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)[org.apache.felix.framework-5.4.0.jar:]
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)[org.apache.felix.framework-5.4.0.jar:]
at com.fortify.plugin.runtime.manager.internal.PluginManagerImpl.startPlugin(PluginManagerImpl.java:150)[13:com.fortify.plugin.runtime:1.1.183]
at com.fortify.plugin.camel.manager.PluginManagerMessageHandler.handleInOutRequest(PluginManagerMessageHandler.java:66)[12:com.fortify.plugin.camel:1.1.183]
at com.fortify.plugin.camel.manager.PluginManagerMessageHandler.handleInOutRequest(PluginManagerMessageHandler.java:39)[12:com.fortify.plugin.camel:1.1.183]
at com.fortify.plugin.camel.helpers.ExchangeProcessorRequest.handle(ExchangeProcessorRequest.java:37)[12:com.fortify.plugin.camel:1.1.183]
at com.fortify.plugin.camel.helpers.ExchangeProcessor$AsyncTask.run(ExchangeProcessor.java:121)[12:com.fortify.plugin.camel:1.1.183]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_161]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_161]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_161]
2018-04-26 17:42:55,842 | ERROR | lixDispatchQueue | impl                             | 32 - org.apache.aries.proxy.impl - 1.0.6 |  FrameworkEvent ERROR - org.apache.aries.proxy.impl
org.osgi.framework.hooks.weaving.WeavingException: There was a serious error trying to weave the class com.blackducksoftware.integration.fortify.parser.BlackDuckIssueParser. See the associated exception for more information.
at org.apache.aries.proxy.impl.weaving.ProxyWeavingHook.weave(ProxyWeavingHook.java:117)
at org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2425)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2112)
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_161]
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at com.fortify.plugin.runtime.helpers.BundleUtils.loadPluginProvider(BundleUtils.java:106)
at com.fortify.plugin.runtime.helpers.StandardPluginBundleExtender.loadPluginProvider(StandardPluginBundleExtender.java:118)
at com.fortify.plugin.runtime.helpers.StandardPluginBundleExtender.newPluginServiceInstance(StandardPluginBundleExtender.java:98)
at com.fortify.plugin.runtime.internal.PluginBundleTracker.addingBundle(PluginBundleTracker.java:59)
at com.fortify.plugin.runtime.internal.PluginBundleTracker.addingBundle(PluginBundleTracker.java:32)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469)[org.eclipse.osgi-3.7.1.jar:]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:415)[org.eclipse.osgi-3.7.1.jar:]
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)[org.eclipse.osgi-3.7.1.jar:]
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)[org.eclipse.osgi-3.7.1.jar:]
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)[org.eclipse.osgi-3.7.1.jar:]
at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2172)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
at com.fortify.plugin.runtime.manager.internal.PluginManagerImpl.startPlugin(PluginManagerImpl.java:150)
at com.fortify.plugin.camel.manager.PluginManagerMessageHandler.handleInOutRequest(PluginManagerMessageHandler.java:66)
at com.fortify.plugin.camel.manager.PluginManagerMessageHandler.handleInOutRequest(PluginManagerMessageHandler.java:39)
at com.fortify.plugin.camel.helpers.ExchangeProcessorRequest.handle(ExchangeProcessorRequest.java:37)
at com.fortify.plugin.camel.helpers.ExchangeProcessor$AsyncTask.run(ExchangeProcessor.java:121)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_161]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_161]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_161]
Caused by: java.lang.IllegalArgumentException
at org.objectweb.asm.ClassReader.(Unknown Source)[asm-3.1.jar:3.1]
at org.objectweb.asm.ClassReader.(Unknown Source)[asm-3.1.jar:3.1]
at org.apache.aries.proxy.impl.weaving.WovenProxyGenerator.getWovenProxy(WovenProxyGenerator.java:38)
at org.apache.aries.proxy.impl.weaving.ProxyWeavingHook.weave(ProxyWeavingHook.java:104)
... 34 more
2018-04-26 17:42:55,847 | WARN  | pool-29-thread-1 | ExchangeProcessor$AsyncTask      | 12 - com.fortify.plugin.camel - 1.1.183 |  Finishing exchange processing with asyncCallback.done() did not succeed [1] - trying again after 500 ms
2018-04-26 17:42:55,872 | ERROR | lixDispatchQueue | scanparser                       | 9 - com.fortify.plugin.runtime.scanparser - 1.1.183 |  FrameworkEvent ERROR - com.fortify.plugin.runtime.scanparser
java.lang.ClassFormatError: Weaving hook failed.
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2439)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2112)
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1542)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:79)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:2018)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)[:1.8.0_161]
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1925)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:978)
at com.fortify.plugin.runtime.helpers.BundleUtils.loadPluginProvider(BundleUtils.java:106)
at com.fortify.plugin.runtime.helpers.StandardPluginBundleExtender.loadPluginProvider(StandardPluginBundleExtender.java:118)
at com.fortify.plugin.runtime.helpers.StandardPluginBundleExtender.newPluginServiceInstance(StandardPluginBundleExtender.java:98)
at com.fortify.plugin.runtime.internal.PluginBundleTracker.addingBundle(PluginBundleTracker.java:59)
at com.fortify.plugin.runtime.internal.PluginBundleTracker.addingBundle(PluginBundleTracker.java:32)
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:469)[org.eclipse.osgi-3.7.1.jar:]
at org.osgi.util.tracker.BundleTracker$Tracked.customizerAdding(BundleTracker.java:415)[org.eclipse.osgi-3.7.1.jar:]
at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:256)[org.eclipse.osgi-3.7.1.jar:]
at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:229)[org.eclipse.osgi-3.7.1.jar:]
at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444)[org.eclipse.osgi-3.7.1.jar:]
at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)
at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2172)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
at com.fortify.plugin.runtime.manager.internal.PluginManagerImpl.startPlugin(PluginManagerImpl.java:150)
at com.fortify.plugin.camel.manager.PluginManagerMessageHandler.handleInOutRequest(PluginManagerMessageHandler.java:66)
at com.fortify.plugin.camel.manager.PluginManagerMessageHandler.handleInOutRequest(PluginManagerMessageHandler.java:39)
at com.fortify.plugin.camel.helpers.ExchangeProcessorRequest.handle(ExchangeProcessorRequest.java:37)
at com.fortify.plugin.camel.helpers.ExchangeProcessor$AsyncTask.run(ExchangeProcessor.java:121)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_161]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_161]
at java.lang.Thread.run(Thread.java:748)[:1.8.0_161]
Caused by: org.osgi.framework.hooks.weaving.WeavingException: There was a serious error trying to weave the class com.blackducksoftware.integration.fortify.parser.BlackDuckIssueParser. See the associated exception for more information.
at org.apache.aries.proxy.impl.weaving.ProxyWeavingHook.weave(ProxyWeavingHook.java:117)
at org.apache.felix.framework.util.SecureAction.invokeWeavingHook(SecureAction.java:1203)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2425)
... 32 more
Caused by: java.lang.IllegalArgumentException
at org.objectweb.asm.ClassReader.(Unknown Source)[asm-3.1.jar:3.1]
at org.objectweb.asm.ClassReader.(Unknown Source)[asm-3.1.jar:3.1]
at org.apache.aries.proxy.impl.weaving.WovenProxyGenerator.getWovenProxy(WovenProxyGenerator.java:38)
at org.apache.aries.proxy.impl.weaving.ProxyWeavingHook.weave(ProxyWeavingHook.java:104)
... 34 more
2018-04-26 17:48:27,582 | INFO  | ] | ExchangeProcessorRequest         | 12 - com.fortify.plugin.camel - 1.1.183 |  Plugin com.fortify.plugin.runtime.manager received message com.fortify.plugin.messaging.manager.PluginUninstallRequest@46b2ef3f; session null
I'm not really sure what to think of this past the failure being rooted in the proxy weaving hook, but I don't have any experience with that and am not really sure how to proceed in troubleshooting this. Any advice/suggestions?

Hey,
It definitely does not look right. Let me ask you few clarification questions.

The plugin was downloaded from releases section of the hub-fortify-parser git repository? Just want to make sure that that I verified that same version of the plugin that you are trying to use.
What exact version of JRE is used for SSC?
Could you do me favor and try to remove plugin from SSC and install it again?

Hey,
1- yup, I downloaded the latest version from master
2- This is the output of java -version on the server:
openjdk version “1.8.0_161”
OpenJDK Runtime Environment (build 1.8.0_161-b14)
OpenJDK 64-Bit Server VM (build 25.161-b14, mixed mode)
But my development machine that I used to build the JAR from source is running:
      java version "9.0.1"
      Java(TM) SE Runtime Environment (build 9.0.1+11)
      Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)

Could that be causing the issue? With the error output I can't really see that being it, but could it be causing the issue with the ProxyWeavingHook?

3- we tried that a couple of times yesterday as a sanity check, even grabbing a new zip of the source and building a new JAR when that didn't work.
Thanks!

Oh, you built plugin jar from plugin sources manually? Did you try to grab blackduck-plugin-2.0.1.jar from releases page https://github.com/blackducksoftware/hub-fortify-parser/releases and install it in SSC? I'm not sure that jar built using java 9 will work correctly in java 8 environment? As far as I can see the plugin gradle script does not define  source / target compatibility version of java compiler.

Welp, I think that was the issue, haha. I'll try rebuild with java 8 instead of 9 for a sanity check, as I was able to enable the JAR you linked without a hitch.
Thanks for being so helpful, and I'm really sorry this turned into so much trouble shooting.

No problems at all. Do not hesitate to ask any extra questions related to the plugin stuff :).

Ugh, sorry, but while I'm able to install the prebuilt jar, I tried building another jar from source using jdk 1.8 in eclipse and it failed to enable again, how did you guys build the jar that you linked to earlier? My team needs to be able to extend the plugin, and so I need to be able to build a jar from source. Can you help me confirm that a new jar built from the current master branch source installs and can be enabled in SSC 17.20?

@evgeny-sem when I trying to add few columns and build the parser plugin, the engine type is not populating. As you mentioned, when I try to enable the updated plugin, getting the below error
Caused by: java.lang.IllegalArgumentException: engineType must not be null or empty
		at org.springframework.util.Assert.isTrue(Assert.java:118) ~[spring-core-5.1.1.RELEASE.jar:5.1.1.RELEASE]
		at com.fortify.manager.plugin.connector.PluginHandleImpl.<init>(PluginHandleImpl.java:17) ~[ssc-core-<IP_ADDRESS>09.jar:?]
		at com.fortify.manager.plugin.connector.ScanParserPluginPersister.handleSideEffects(ScanParserPluginPersister.java:157) ~[ssc-core-<IP_ADDRESS>09.jar:?]
		at com.fortify.manager.service.PluginManagementHelperServiceImpl.lambda$handleStop$16(PluginManagementHelperServiceImpl.java:501) ~[ssc-core-<IP_ADDRESS>09.jar:?]
		at com.fortify.manager.service.transaction.TransactionCallbackNoResult.execute(TransactionCallbackNoResult.java:11) ~[ssc-core-<IP_ADDRESS>09.jar:?]
		at com.fortify.manager.service.transaction.TransactionCallbackNoResult.execute(TransactionCallbackNoResult.java:7) ~[ssc-core-<IP_ADDRESS>09.jar:?]
		at com.fortify.manager.service.transaction.TransactionServiceImpl.doRunInTransaction(TransactionServiceImpl.java:76) ~[ssc-core-<IP_ADDRESS>09.jar:?]
		... 34 more

@msenmurugan When this error happens? When you try to install new plugin? Or stop the existed one?

@evgeny-sem stopped and removed the existing plugin and uploading the new plugin

@evgeny-sem plugin framework.log
2019-11-12 21:04:30,603 | INFO  | pool-5-thread-1  | PluginManagerImpl                | 16 - com.fortify.plugin.runtime - <IP_ADDRESS>7 |  STARTING plugin bundle with uuid=7a957af0-59e0-3f4f-ad54-5e6c6657b478 [com.blackducksoftware.fortifyparserplugin [65] 2.0.1]
2019-11-12 21:04:30,607 | INFO  | pool-5-thread-1  | PluginMetadataLoaderImpl         | 16 - com.fortify.plugin.runtime - <IP_ADDRESS>7 |  Plugin metadata loaded from bundle com.blackducksoftware.fortifyparserplugin [65] with com.fortify.plugin.runtime.metadata.internal.StandardMetadataLoader@4a2b3514
2019-11-12 21:04:30,618 | INFO  | pool-5-thread-1  | BundleUtils                      | 16 - com.fortify.plugin.runtime - <IP_ADDRESS>7 |  Loaded plugin provider com.blackducksoftware.integration.fortify.parser.BlackDuckIssueParser@681a48bb [com.fortify.plugin.spi.ParserPlugin] from com.blackducksoftware.fortifyparserplugin [65]
2019-11-12 21:04:30,626 | INFO  | pool-5-thread-1  | BlackDuckIssueParser             | 65 - com.blackducksoftware.fortifyparserplugin - 2.0.1 |  BlackDuckIssueParser is starting...
2019-11-12 21:04:30,638 | INFO  | pool-5-thread-1  | OsgiDefaultCamelContext          | 10 - org.apache.camel.camel-core - 2.18.4 |  Apache Camel 2.18.4 (CamelContext: plugin-adapter-7a957af0-59e0-3f4f-ad54-5e6c6657b478) is starting
2019-11-12 21:04:30,638 | INFO  | pool-5-thread-1  | ManagedManagementStrategy        | 10 - org.apache.camel.camel-core - 2.18.4 |  JMX is enabled
2019-11-12 21:04:30,678 | INFO  | pool-5-thread-1  | DefaultRuntimeEndpointRegistry   | 10 - org.apache.camel.camel-core - 2.18.4 |  Runtime endpoint registry is in extended mode gathering usage statistics of all incoming and outgoing endpoints (cache limit: 1000)
2019-11-12 21:04:30,686 | INFO  | pool-5-thread-1  | OsgiDefaultCamelContext          | 10 - org.apache.camel.camel-core - 2.18.4 |  StreamCaching is not in use. If using streams then its recommended to enable stream caching. See more details at http://camel.apache.org/stream-caching.html
2019-11-12 21:04:30,711 | INFO  | pool-5-thread-1  | OsgiDefaultCamelContext          | 10 - org.apache.camel.camel-core - 2.18.4 |  Route: in-7a957af0-59e0-3f4f-ad54-5e6c6657b478 started and consuming from: pluginmq://queue:plugin_in_7a957af0-59e0-3f4f-ad54-5e6c6657b478?asyncConsumer=true&concurrentConsumers=2&destination.consumer.prefetchSize=1&maxConcurrentConsumers=8
2019-11-12 21:04:30,711 | INFO  | pool-5-thread-1  | OsgiDefaultCamelContext          | 10 - org.apache.camel.camel-core - 2.18.4 |  Total 1 routes, of which 1 are started.
2019-11-12 21:04:30,711 | INFO  | pool-5-thread-1  | OsgiDefaultCamelContext          | 10 - org.apache.camel.camel-core - 2.18.4 |  Apache Camel 2.18.4 (CamelContext: plugin-adapter-7a957af0-59e0-3f4f-ad54-5e6c6657b478) started in 0.073 seconds
2019-11-12 21:04:30,742 | INFO  | pool-5-thread-1  | PluginServiceCamelAdapterImpl    | 18 - com.fortify.plugin.camel - <IP_ADDRESS>7 |  Plugin com.blackducksoftware.fortifyparserplugin, UUID: 7a957af0-59e0-3f4f-ad54-5e6c6657b478 has successfully subscribed
2019-11-12 21:04:30,742 | INFO  | pool-5-thread-1  | PluginServiceCamelAdapterImpl    | 18 - com.fortify.plugin.camel - <IP_ADDRESS>7 |  Started camel adapter com.fortify.plugin.camel.helpers.PluginServiceCamelAdapterImpl@69776981 for com.fortify.plugin.runtime.scanparser.internal.ScanParserServiceImpl@5fdade46
2019-11-12 21:04:30,900 | INFO  | 7c-254f768c9fa9] | ExchangeProcessorRequest         | 18 - com.fortify.plugin.camel - <IP_ADDRESS>7 |  Plugin com.fortify.plugin.runtime.manager received message com.fortify.plugin.messaging.manager.PluginStopRequest@6033c3e8; session null
2019-11-12 21:04:30,913 | INFO  | pool-5-thread-1  | PluginManagerImpl                | 16 - com.fortify.plugin.runtime - <IP_ADDRESS>7 |  STOPPING plugin bundle with uuid=7a957af0-59e0-3f4f-ad54-5e6c6657b478 [com.blackducksoftware.fortifyparserplugin [65] 2.0.1]
2019-11-12 21:04:30,932 | INFO  | pool-5-thread-1  | PluginServiceCamelAdapterImpl    | 18 - com.fortify.plugin.camel - <IP_ADDRESS>7 |  Plugin com.blackducksoftware.fortifyparserplugin, UUID: 7a957af0-59e0-3f4f-ad54-5e6c6657b478 has successfully unsubscribed
2019-11-12 21:04:30,932 | INFO  | pool-5-thread-1  | PluginServiceCamelAdapterImpl    | 18 - com.fortify.plugin.camel - <IP_ADDRESS>7 |  Stopping executor java.util.concurrent.ThreadPoolExecutor@126c868e[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] for camel adapter com.fortify.plugin.camel.helpers.PluginServiceCamelAdapterImpl@69776981 and plugin com.fortify.plugin.runtime.scanparser.internal.ScanParserServiceImpl@5fdade46
2019-11-12 21:04:30,933 | INFO  | pool-5-thread-1  | PluginServiceCamelAdapterImpl    | 18 - com.fortify.plugin.camel - <IP_ADDRESS>7 |  Stopping plugin session registry com.fortify.plugin.camel.helpers.PluginSessionRegistry@616510fb for camel adapter com.fortify.plugin.camel.helpers.PluginServiceCamelAdapterImpl@69776981 and plugin com.fortify.plugin.runtime.scanparser.internal.ScanParserServiceImpl@5fdade46
2019-11-12 21:04:30,934 | INFO  | pool-5-thread-1  | DefaultShutdownStrategy          | 10 - org.apache.camel.camel-core - 2.18.4 |  Starting to graceful shutdown 1 routes (timeout 10 seconds)
2019-11-12 21:04:31,735 | INFO  | 5 - ShutdownTask | DefaultShutdownStrategy          | 10 - org.apache.camel.camel-core - 2.18.4 |  Route: in-7a957af0-59e0-3f4f-ad54-5e6c6657b478 shutdown complete, was consuming from: pluginmq://queue:plugin_in_7a957af0-59e0-3f4f-ad54-5e6c6657b478?asyncConsumer=true&concurrentConsumers=2&destination.consumer.prefetchSize=1&maxConcurrentConsumers=8
2019-11-12 21:04:31,736 | INFO  | pool-5-thread-1  | DefaultShutdownStrategy          | 10 - org.apache.camel.camel-core - 2.18.4 |  Graceful shutdown of 1 routes completed in 0 seconds
2019-11-12 21:04:31,736 | INFO  | pool-5-thread-1  | OsgiDefaultCamelContext          | 10 - org.apache.camel.camel-core - 2.18.4 |  Route: in-7a957af0-59e0-3f4f-ad54-5e6c6657b478 is stopped, was consuming from: pluginmq://queue:plugin_in_7a957af0-59e0-3f4f-ad54-5e6c6657b478?asyncConsumer=true&concurrentConsumers=2&destination.consumer.prefetchSize=1&maxConcurrentConsumers=8
2019-11-12 21:04:31,737 | INFO  | pool-5-thread-1  | OsgiDefaultCamelContext          | 10 - org.apache.camel.camel-core - 2.18.4 |  Apache Camel 2.18.4 (CamelContext: plugin-adapter-7a957af0-59e0-3f4f-ad54-5e6c6657b478) is shutting down
2019-11-12 21:04:31,737 | INFO  | pool-5-thread-1  | DefaultShutdownStrategy          | 10 - org.apache.camel.camel-core - 2.18.4 |  Starting to graceful shutdown 1 routes (timeout 10 seconds)
2019-11-12 21:04:31,742 | INFO  | 5 - ShutdownTask | DefaultShutdownStrategy          | 10 - org.apache.camel.camel-core - 2.18.4 |  Route: in-7a957af0-59e0-3f4f-ad54-5e6c6657b478 shutdown complete, was consuming from: pluginmq://queue:plugin_in_7a957af0-59e0-3f4f-ad54-5e6c6657b478?asyncConsumer=true&concurrentConsumers=2&destination.consumer.prefetchSize=1&maxConcurrentConsumers=8
2019-11-12 21:04:31,742 | INFO  | pool-5-thread-1  | DefaultShutdownStrategy          | 10 - org.apache.camel.camel-core - 2.18.4 |  Graceful shutdown of 1 routes completed in 0 seconds
2019-11-12 21:04:31,753 | INFO  | pool-5-thread-1  | OsgiDefaultCamelContext          | 10 - org.apache.camel.camel-core - 2.18.4 |  Apache Camel 2.18.4 (CamelContext: plugin-adapter-7a957af0-59e0-3f4f-ad54-5e6c6657b478) uptime 1.115 seconds
2019-11-12 21:04:31,753 | INFO  | pool-5-thread-1  | OsgiDefaultCamelContext          | 10 - org.apache.camel.camel-core - 2.18.4 |  Apache Camel 2.18.4 (CamelContext: plugin-adapter-7a957af0-59e0-3f4f-ad54-5e6c6657b478) is shutdown in 0.016 seconds
2019-11-12 21:04:31,753 | INFO  | pool-5-thread-1  | PluginServiceCamelAdapterImpl    | 18 - com.fortify.plugin.camel - <IP_ADDRESS>7 |  Stopped camel adapter com.fortify.plugin.camel.helpers.PluginServiceCamelAdapterImpl@69776981 for com.fortify.plugin.runtime.scanparser.internal.ScanParserServiceImpl@5fdade46
2019-11-12 21:04:31,754 | INFO  | pool-5-thread-1  | BlackDuckIssueParser             | 65 - com.blackducksoftware.fortifyparserplugin - 2.0.1 |  BlackDuckIssueParser is stopping working...

@evgeny-sem oh found out the reason
Caused by: com.fortify.manager.exception.FMPluginHandlerException: The plugin was not enabled because the extended fields of the plugin could not be stored.
Reason: Maximum number of custom attributes 5 is exceeded for attribute type DATE.

@msenmurugan Could you try to bump plugin version as well?
It can be done in build.gradle
// plugin version, note the version must match versionRegex.
version = '2.0.1'

As I can see in adding-recommendations branch, it is still the same as in master.

@msenmurugan Sorry, have not noticed your second comment
Reason: Maximum number of custom attributes 5 is exceeded for attribute type DATE.

It might be the reason.

@evgeny-sem oh found out the reason
Caused by: com.fortify.manager.exception.FMPluginHandlerException: The plugin was not enabled because the extended fields of the plugin could not be stored.
Reason: Maximum number of custom attributes 5 is exceeded for attribute type DATE.

Unfortunately, this limitation currently caused by the way how plugin meta data is stored in our data storage. The workaround is to use string attribute. It is not perfect, though.

Thanks @evgeny-sem.. Always a helping guy!!! :-)


Fix new_mycobot_320_pi compile error

Fix the compile error
-- +++ processing catkin package: 'aikit_320_pi'
-- ==> add_subdirectory(mycobot_ros/mycobot_ai/aikit_320_pi)
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- Could NOT find new_mycobot_320_pi (missing: new_mycobot_320_pi_DIR)
-- Could not find the required component 'new_mycobot_320_pi'. The following CMake error indicates that you either need to install the package with the same name or change your environment so that it can be found.
CMake Error at /opt/ros/noetic/share/catkin/cmake/catkinConfig.cmake:83 (find_package):
  Could not find a package configuration file provided by
  "new_mycobot_320_pi" with any of the following names:

    new_mycobot_320_piConfig.cmake
    new_mycobot_320_pi-config.cmake

  Add the installation prefix of "new_mycobot_320_pi" to CMAKE_PREFIX_PATH or
  set "new_mycobot_320_pi_DIR" to a directory containing one of the above
  files.  If "new_mycobot_320_pi" provides a separate development package or
  SDK, be sure it has been installed.
Call Stack (most recent call first):
  mycobot_ros/mycobot_ai/aikit_320_pi/CMakeLists.txt:10 (find_package)

@wangWking Could you help take a look the PR? I fixed the compile error and verified on my local


Add a xrootd demo/link to a demo for very large files

We recently made it possible to talk to xrootd directly on mybinder.org. We should add/link to a repository that makes use of this (and preferably just this) to access very large files without having to download them first.
CERN has a lot of open-data that we could build on.
A starting point could be https://github.com/lukasheinrich/atlasbinder

cc @matthewfeickert, apparently I can't assign you

I was originally going to suggest just fixing up https://github.com/cernphsft/rootbinder so that the Dockerfile built again and worked with Binder, but I then remembered that XRootD is only supported on SLC, Solaris, and MacOS so I should probably just start with getting an SLC6 image that has ROOT installed on it and then installing xRootD in the ROOT build process (assuming that this image would build ROOT from source).

Still need to make a repo that actually demos xRootD and CERN Open Data, but this PR at least offers a Binder compatible image with ROOT.

Some potential datasets: https://root-forum.cern.ch/t/public-dataset-available-via-xrootd/31535

@betatim Are there restrictions on how services inside of a Binder image can access the outside world?
I have two Dockerfiles for Binders with ROOT + XRootD on Ubuntu () and CentOS 7 (). If I build those images with docker build locally I am able to run
xrdcp root://eospublic.cern.ch//eos/root-eos/cms_opendata_2012_nanoaod/Run2012B_DoubleMuParked.root .

in them (albeit the transfer is a bit slow). However, if I launch one of those images and run the above they just hang and never start the transfer. Do I need to tell Binder some additional information?

Are there restrictions on how services inside of a Binder image can access the outside world?
Oh yes, if I had read.

There are a few restrictions on outgoing traffic from your Binder that are imposed by the team operating https://mybinder.org. Currently only connections to HTTP and Git are allowed.

So I guess I need to figure out how to properly configure XRootD with HTTPS

https://github.com/jupyterhub/mybinder.org-deploy/blob/72ed9d319b394981630ed1df392f499f3dc7cf8b/mybinder/values.yaml#L38 so xrootd should be possible.

Hm, very strange. I'll have to poke at this more then.

This is weird. It seems like it has already transferred a whole bunch of data and then fails because of a certificate validation error?

It seems like it has already transferred a whole bunch of data and then fails because of a certificate validation error?

Oh no, sorry, it doesn't fail. I just copied and pasted that as it was running (I haven't let it download the full dataset because I didn't want to wait, but it happily downloaded over 1.5 GB). The  secgsi: unknown CA: cannot verify server certificate is just a warning, it doesn't stop the transfer in anyway that I can tell.
The strange thing to me is that this repo2docker image seems happy to work, but when I try to run the same thing in a terminal when it has been deployed on BinderHub the transfer never starts. It just hangs.

Hi @matthewfeickert @betatim , I would like to warm up this discussion since this is the key point to make the open data analysis at CERN available through binder.
I've set up a minimal example using the conda build of ROOT which is coming with XRootD and a minimal analysis example: https://github.com/stwunsch/test-root-binder
There's anything that could be done to make this happen? I see that you've already opened the port but I see as well the hanging xrdcp in the terminal. The minimal reproducer is as follows:
xrdcp root://eospublic.cern.ch//eos/root-eos/cms_opendata_2012_nanoaod/Run2012B_DoubleMuParked.root .

To make the topic probably even more attractive: I plan to push the "technical" tutorials from ROOT like this one or this one to the CERN Open Data portal, which could be powered by CERN's jupyter service SWAN. However, this is restricted to CERN users only. Using binder, these analyses could be run by everyone just out-of-the-box, which is obviously the way to go for open data and open analyses!

From running with -d3 (for all the debug output) I see the following in the logs:
[2019-05-21 10:35:39.623404 +0000][Debug  ][PostMaster        ] Creating new channel to: p06636710s16574.cern.ch:1095 1 stream(s)

This makes me think there are more ports that need opening.
You could make a PR that adds 1095 as port here. Maybe you can find someone at CERN/one of the experiments who can tell us if these are all the ports or if there are more.

Thanks for the information! I'm going to look for someone ;)

Two things:

XRootD is now available from conda-forge
The minimal firewall configuration required to get it to work is (tested in a docker container):

iptables --flush
# Lock everything down
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
# Open DNS + XRootD
iptables -A INPUT --proto udp --sport 53 -j ACCEPT
iptables -A INPUT --proto tcp --sport 1094 -j ACCEPT
iptables -A INPUT --proto tcp --sport 1095 -j ACCEPT
# Open DNS + XRootD
iptables -A OUTPUT --proto udp --dport 53 -j ACCEPT
iptables -A OUTPUT --proto tcp --dport 1094 -j ACCEPT
iptables -A OUTPUT --proto tcp --dport 1095 -j ACCEPT
# View the rules
iptables -L -v -n

https://github.com/jupyterhub/mybinder.org-deploy/pull/973 opened the port. Should be live in ~10minutes. Thanks for finding out Chris!

Many thanks @chrisburr !

It's amazing!

With this my Binder built FROM rootproject/root-ubuntu16:6.12 works now too (c.f. Notebooks/XRootD_Example.ipynb):  :+1:
The goal here was to create add a demo of XRootD, so as conda-forge has ROOT binaries that seem to be the latest release then @betatim does it make more sense in your mind to adapt and expand the notebook that I have and make a binder-examples controlled repo, or to just link to the tutorials that @stwunsch will make?
The Binder I currently have is to get the (seemingly abandoned) JupyROOT examples to work again if people wanted to have a C++ kernel rather than a Python3 kernel with PyROOT, but the notebooks can get adapted.

Given that this repo won't be able to demo all the possible "access really large data" options I'd make a new repo and link to it from here.
re: C++ kernels, I think https://github.com/QuantStack/xeus-cling is the future there so I would make a pure Python example, instead of using JupyROOT which does weird stuff.

Given that this repo won't be able to demo all the possible "access really large data" options I'd make a new repo and link to it from here.

@betatim Sounds good! Since I don't have the ability to make repos under binder-examples could you make an empty one that I can fork and then make a PR against with content?

re: C++ kernels, I think https://github.com/QuantStack/xeus-cling is the future there so I would make a pure Python example, instead of using JupyROOT which does weird stuff.

:rocket: We're in agreement. I wasn't proposing using JupyROOt (just explaining why it was the way I had it so far).

The example can even use uproot to read the file. It is, after all, about demo'ing how to access large datasets, where the whole ROOT thing (and its weird ways of doing notebooks) is more of a distraction IMHO.

I'm an uproot fanboy, so that's an excellent suggestion. :)

created https://github.com/binder-examples/getting-data-xroot. In your first PR can you also add a LICENSE like https://github.com/binder-examples/minimal-dockerfile/blob/master/LICENSE

Regrading the C++ kernel: I don't know whether I got you wrong but adding ROOT from conda-forge in the environment.yaml seems sufficient so that the C++ jupyter kernel is picked up. You can try https://github.com/stwunsch/test-root-binder and simply select the C++ kernel from there.

Done with binder using the environment from here:

Here are some demo notebooks we use for teaching ROOT with C++ and Python, which are using XRootD and run now nicely with binder: https://github.com/stwunsch/root_dataframe_tutorial
These notebooks show-case as well what you can do with the data mentioned above:


Is white-space char as groupSeparator possible?

Hello,
is it possible to have white-space character as groupSeparator? When I use something like this:
data-inputmask="'alias': 'decimal', 'groupSeparator': ' ', 'autoGroup': true"

I get weird behavior: I can type up to 3 digits, any digit more resets the whole input and I start up with only the last typed digit. Any other string character works well.
I have 3.0.4 version but I tested it with current as well.

What about  this : ", " (comma with white-space)  why so poorly?

@twg-group ,
Hmm that never came to mind to allow a groupseparator of more then one char.  Let's make a nex issue for this.


Contributing guide with build instructions.

Thanks for having gitpod support.
I tried to experiment and got errors. I guess there is more to be done before start executing the commands I tried. Also noticed contributing.md is not there yet as mentioned ind readme.md.
Here is the gitpod console...
itpod /workspace/bob $  HISTFILE=/workspace/.gitpod/cmd-0 history -r; {
> set +x; clear
> } && {
> set +x;clear
>
> # Added to bashrc so each shell gets the settings
> cat <<EOD >> ~/.bashrc
> function gt() {
>   TAG=\${1}; git tag --delete \${TAG} 2>/dev/null; git push  --delete origin \${TAG} 2>/dev/null; git tag  \${TAG}; git push --tags
> }
>
> function deploy() {
>   gq https://cloud.okteto.com/graphql -H "Authorization: Bearer \$OKTETO_TOKEN" -q 'mutation deployGitRepository(\$name: String!, \$space: String!, \$repository: String!, \$branch: String!) {deployGitRepository( name: \$name, space: \$space, repository: \$repository, branch: \$branch ) {id, status}}' -v 'name=bob' -v 'space=' -v 'repository=https://github.com/BobDotMe/bob' -v 'branch=master'
Usage:
  okteto login [url] [flags]

Flags:
  -h, --help           help for login
  -t, --token string   API token for authentication.  (optional)

Global Flags:
  -l, --loglevel string   amount of information outputted (debug, info, warn, error) (default "warn")

 x  flag needs an argument: --token
cp: cannot stat '/home/gitpod/.kube/config': No such file or directory
flag needs an argument: 'p' in -p
See 'docker login --help'.
gitpod /workspace/bob $ ls
CODENAME  distro  dockerfiles  docs  examples  files  helm  LICENSE  okteto-pipeline.yml  okteto.yaml  plugins  README.md  VERSION  work
gitpod /workspace/bob $ kubec
kubeconfig  kubectl
gitpod /workspace/bob $ kubectl get pod
ls: cannot access '/home/gitpod/.kube/*.cfg': No such file or directory
ls: cannot access '/home/gitpod/.kube/config': No such file or directory
The connection to the server localhost:8080 was refused - did you specify the right host or port?
gitpod /workspace/bob $ docker ps
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
gitpod /workspace/bob $ cd helm/
gitpod /workspace/bob/helm $ helm package
ls: cannot access '/home/gitpod/.kube/*.cfg': No such file or directory
ls: cannot access '/home/gitpod/.kube/config': No such file or directory
bash: /usr/local/bin/helm: No such file or directory
gitpod /workspace/bob/helm $ ls
chart
gitpod /workspace/bob/helm $ cd chart
gitpod /workspace/bob/helm/chart $ ls
Chart.yaml  okteto-values.yaml  templates  values.yaml
gitpod /workspace/bob/helm/chart $ helm package
ls: cannot access '/home/gitpod/.kube/*.cfg': No such file or directory
ls: cannot access '/home/gitpod/.kube/config': No such file or directory
bash: /usr/local/bin/helm: No such file or directory
gitpod /workspace/bob/helm/chart $

I'll take a look.
Doing the development is a bit different on the cloud.  You cannot yet do everything in gitpod.  Also I think a bit of work would need to be done for the okteto.  Probably hard coded at the moment.

Noted.  I will try clone locally and see how to make a small change and test it out...
If I am able to figure that out, I may contribute by writing contributing.md file.

@mookkiah  Please try our new getting started guide available now...


WIP: switch to blake3

We seem to be pretty universally on board with this: #100

Leave kiss checksums unchanged, otherwise update won't be possible without manual intervention.


Fixed the time indexing bug with to_data_frame

I think that the bug reported on the listserv is fixed. In classy fashion, by implementing the "ToDataFrameMixin" base class, I also managed to undo the fix that led me to create the Mixin in the first place. I think that I've fixed it now, take a look and let me know if all looks well.

@choldgraf does this solve our problem?

I recreated the bug that the person was speaking of, and then these changes
fixed it. Also wrote in a test to make sure it was working for raw arrays.
On Fri, Apr 10, 2015 at 11:02 AM, Denis A. Engemann <
<EMAIL_ADDRESS>wrote:

@choldgraf https://github.com/choldgraf does this solve our problem?
—
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/pull/1942#issuecomment-91637629.

I think what you meant to say was "I created a test that failed and then fixed it with my changes", so we can claim a test-driven-development victory here :)

Do you think we should also check other objects? I can't remember how the branching works, but e.g. SourceEstimate might have a different flow...?

So basically the error was that we had this big object-dependent split at
the beginning, and in that split I was adding ('time', times) to the
multiindex. Then, later on, I was doing the times scaling and then
rounding, but only to the "times" object. So it didn't actually affect what
was already in the multiindex tuple. As a result, the index wasn't scaled,
so when it got rounded everything went to 0.
I removed all of the multi-index stuff until after the big split, and then
included the scaling / rounding correction as well as appending to
multiindex afterward. I can't remember if SourceEstimate would have a
problem with this - doesn't it use time as well, just has a different
configuration of columns?
On Fri, Apr 10, 2015 at 12:21 PM, Eric Larson<EMAIL_ADDRESS>wrote:

Do you think we should also check other objects? I can't remember how the
branching works, but e.g. SourceEstimate might have a different flow...?
—
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/pull/1942#issuecomment-91657071.

Yeah it does, it's just that how you get the time information would be different (tmin / tstep as opposed to sfreq). But it from your response it's clear that this actually gets rid of some branching, which is great, and answers my question.
Thanks for the quick fix!

thx

dang @agramfort beat me to it :)

Oops - it looks like I missed something. One line is duplicated (177 and
188)
On Fri, Apr 10, 2015 at 12:47 PM, Eric Larson<EMAIL_ADDRESS>wrote:

dang @agramfort https://github.com/agramfort beat me to it :)
—
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/pull/1942#issuecomment-91663203.

Ahh, couldn't see that in the GitHub diff. I'll fix it in master. I should just be able to delete the second one, right?

Yeah, the one that's not paired with the "add to multiindex" line
On Fri, Apr 10, 2015 at 12:55 PM, Eric Larson<EMAIL_ADDRESS>wrote:

Ahh, couldn't see that in the GitHub diff. I'll fix it in master. I
should just be able to delete the second one, right?
—
Reply to this email directly or view it on GitHub
https://github.com/mne-tools/mne-python/pull/1942#issuecomment-91664743.


Add AboutUs section to the webpage

If AboutUs is added then the visitors of the website will have a clear idea on what the webpage is about.
@BamaCharanChhandogi Please assign me this issue under gssoc-ext with a level tag and hacktoberfest-accecpted tag
Thank You

Do not need.


Projection aliases support for SELECT queries

Now the result of SELECT query returns both aliases and rows.
Implement support for fetching aliases.
e.g.
SELECT id, name as foo FROM TableA;

The query above provides not only fetched rows, but also it serve aliases like ["id", "foo"].
Change Payload::SELECT from
Payload::SELECT(Vec<Row>)

to
Payload::SELECT {
  aliases: Vec<String>,
  rows: Vec<Row>,
}

resolve #83

@willy610 Thanks for reporting this issue, now it works!

Nice implementation.
I think the public sql programmer in interfacing with the select thinks in terms of columns or labels or similar more than alias.
I think alias is more AST
Could be confusing also because all in the projection does not for sure have any AS NAME but sticks to the column name from a table.
Perhaps labels is preferred??

@willy610 That sounds... great.
I agree of the point you mentiond, alias sounds more.. related to AST, it may not fit to user-side names.
labels sounds good and I'll do work on this soon. thanks!


[Question]: What does printing.smooth(true) do?

Hey @tr3v3r , I was just wondering what printing.smooth(true) does. Couldn't find any documentation on EPSON or here either. Thanks in advance :)

Ok I looked at the picture in docs of the test print very closely - it just makes the text smoother :)
Closing!


protocol: extract JSON-LD context creation

Feature Request
Currently, many of the dsp classes that perform JSON-LD compaction(e.g. delegates, controllers) contain their own method for creating the JSON-LD context. This should be extracted to be shared by all these classes.
Which Areas Would Be Affected?
dsp
Why Is the Feature Desired?
To not have duplicated code

this is already resolved, now the context is created by the JsonLd service


The increment in ArrayStore

Laravel Version: lastest
PHP Version:7.0
Database Driver & Version:

Description:
The method increment in cache\ArrayStore has a bug that array index out of range
 public function increment($key, $value = 1)
    {
        // $key not exist
        // if (!isset($this->storage[$key])) $this->storage[$key] = 0;
        $this->storage[$key] = ((int) $this->storage[$key]) + $value;

        return $this->storage[$key];
    }

https://github.com/laravel/framework/blob/5.4/src/Illuminate/Cache/ArrayStore.php#L53

handled in https://github.com/laravel/framework/pull/20156
Thanks :)


[BUG] withRestoreOnRetry should look at Throwable causes in addition to retry OOMs

Re: https://github.com/NVIDIA/spark-rapids/pull/7958
While debugging an issue with https://github.com/NVIDIA/spark-rapids/pull/7925 I ran into an issue where an UDF was failing to allocate a GPU buffer due to an injected OOM, but then it turns around and wraps it into its own exception:
Caused by: org.apache.spark.SparkException: Failed to execute user defined function: (emptygeneric: (string) => string)

This means the retry is hidden in the cause by, so I had to change the logic in the retry iterator to account for it. @jbrennan333, we'll need to adapt the new withRestoreOnRetry as well to account for this.

This is what I ended up doing: https://github.com/NVIDIA/spark-rapids/pull/7925/commits/63e83d092732d9d3b4365276b1089cbd32f3e30a


Add option for auto-selecting next window on overview toggle

You implemented the traditional alt tab functionality, and I thank you for that. Now, I would love if we had the option to auto-select the next window when the alt release mechanism is enabled.

I don't think this is a good idea, because the plugin is also compatible with users who use directional switching, and for users who use directional switching, they can't determine what the next window is after triggering overview

Well, that's why it can be an option which you'll be able to set to 0 or 1.

done


Integration is using deprecated DEVICE_CLASS_* constants

Version of the custom_component

All
Configuration

n/a

Describe the bug
This custom integration uses deprecated DEVICE_CLASS_* constants in its codebase.
The DEVICE_CLASS_* constants have been deprecated and replaced in Home Assistant Core 2021.12 (over a year ago). I would highly suggest updating/migrating this integration to the new enums.
For example, for the device classes supported by the sensor platform, there is now a SensorDeviceClass enum. So if a sensor previously used the DEVICE_CLASS_ENERGY constant, it should now use SensorDeviceClass.ENERGY. Other platforms (like binary_sensor, and number) provide similar enumerations for their supported device classes.
The migration thus only consists of replacing constants with an enumeration member and is, therefore, very low impact and should be fairly straightforward.
If I can help resolve any questions regarding this change or migration, feel free to ask or respond to this issue. I'm happy to help!
Kindest regards,
../Frenck
Debug log

n/a

Thanks @frenck
This custom component is deprecated. It has been merged into core in 2021.8 and finalised in 2021.10.
I guess it's about time to remove it from HACS.

I guess it's about time to remove it from HACS.

Hehe that is why it showed up on my list in the first place :)
I agree, for confusion it might be best to remove it from the HACS listing in that case.
../Frenck

Done: https://github.com/hacs/default/pull/1657


[Bug]: Model Launch Hangs with 16+ Ranks in vLLM

Your current environment
Collecting environment information...
PyTorch version: 2.3.0+cu121
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A
OS: Ubuntu 22.04.4 LTS (x86_64)
GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Clang version: Could not collect
CMake version: version 3.29.3
Libc version: glibc-2.35
Python version: 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] (64-bit runtime)
Python platform: Linux-6.2.0-1018-aws-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: 12.1.105
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration:
GPU 0: NVIDIA A10G
GPU 1: NVIDIA A10G
GPU 2: NVIDIA A10G
GPU 3: NVIDIA A10G
GPU 4: NVIDIA A10G
GPU 5: NVIDIA A10G
GPU 6: NVIDIA A10G
GPU 7: NVIDIA A10G
Nvidia driver version: 535.161.08
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True
CPU:
Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Address sizes:                      48 bits physical, 48 bits virtual
Byte Order:                         Little Endian
CPU(s):                             192
On-line CPU(s) list:                0-191
Vendor ID:                          AuthenticAMD
Model name:                         AMD EPYC 7R32
CPU family:                         23
Model:                              49
Thread(s) per core:                 2
Core(s) per socket:                 48
Socket(s):                          2
Stepping:                           0
BogoMIPS:                           5599.00
Flags:                              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf tsc_known_freq pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch topoext perfctr_core ssbd ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr rdpru wbnoinvd arat npt nrip_save rdpid
Hypervisor vendor:                  KVM
Virtualization type:                full
L1d cache:                          3 MiB (96 instances)
L1i cache:                          3 MiB (96 instances)
L2 cache:                           48 MiB (96 instances)
L3 cache:                           384 MiB (24 instances)
NUMA node(s):                       2
NUMA node0 CPU(s):                  0-47,96-143
NUMA node1 CPU(s):                  48-95,144-191
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Not affected
Vulnerability Retbleed:             Mitigation; untrained return thunk; SMT enabled with STIBP protection
Vulnerability Spec rstack overflow: Mitigation; safe RET
Vulnerability Spec store bypass:    Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:           Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:           Mitigation; Retpolines, IBPB conditional, STIBP always-on, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected
Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] nvidia-nccl-cu12==2.20.5
[pip3] torch==2.3.0
[pip3] triton==2.3.0
[pip3] vllm-nccl-cu12==<IP_ADDRESS>.4.0
[conda] Could not collectROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: 0.4.2
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
GPU0	GPU1	GPU2	GPU3	GPU4	GPU5	GPU6	GPU7	CPU Affinity	NUMA Affinity	GPU NUMA ID
GPU0	 X 	PHB	PHB	PHB	PHB	PHB	PHB	PHB	0-191	0-1		N/A
GPU1	PHB	 X 	PHB	PHB	PHB	PHB	PHB	PHB	0-191	0-1		N/A
GPU2	PHB	PHB	 X 	PHB	PHB	PHB	PHB	PHB	0-191	0-1		N/A
GPU3	PHB	PHB	PHB	 X 	PHB	PHB	PHB	PHB	0-191	0-1		N/A
GPU4	PHB	PHB	PHB	PHB	 X 	PHB	PHB	PHB	0-191	0-1		N/A
GPU5	PHB	PHB	PHB	PHB	PHB	 X 	PHB	PHB	0-191	0-1		N/A
GPU6	PHB	PHB	PHB	PHB	PHB	PHB	 X 	PHB	0-191	0-1		N/A
GPU7	PHB	PHB	PHB	PHB	PHB	PHB	PHB	 X 	0-191	0-1		N/A
Legend:
X    = Self
SYS  = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node
PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
PXB  = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge)
PIX  = Connection traversing at most a single PCIe bridge
NV#  = Connection traversing a bonded set of # NVLinks
🐛 Describe the bug
When launching a model using the vLLM library with 16 ranks (processes) on 2 nodes, the launch hangs indefinitely and fails to complete. However, launching with 8 ranks on 2 nodes works as expected. This issue impacts the ability to run large models that require 16 or more ranks to operate efficiently on multi-node clusters.
Steps to Reproduce:

8 Ranks (Successful):
On a Ray cluster with 8 GPUs across two AWS g5.12xlarge machines, confirm the cluster status:

ubuntu@ubuntu:~ $ ray status
======== Autoscaler status: 2024-05-31 21:18:32.605238 ========
Node status
---------------------------------------------------------------
Active:
 1 node_1a93b656e273149f144a0ef03fad7c56dfdb0eb2005b289eee44914e
 1 node_bdda5bb6d33b5b29813769d6c4238d0e764aa1851f620abb31d4d3e0
Pending:
 (no pending nodes)
Recent failures:
 (no failures)

Resources
---------------------------------------------------------------
Usage:
 0.0/96.0 CPU
 0.0/8.0 GPU
 0B/235.77GiB memory
 0B/105.04GiB object_store_memory

Demands:
 (no resource demands)

Launch model run with 8 ranks:
python -m vllm.entrypoints.openai.api_server \
    --enforce-eager \
    --tensor-parallel-size 8 \
    --swap-space 16 \
    --gpu-memory-utilization=0.9 \
    --model meta-llama/Meta-Llama-3-70B \
    --disable-custom-all-reduce \
    --disable-log-requests

16 Ranks (Hangs):
On a Ray cluster with 16 GPUs across two AWS g5.48xlarge machines, confirm the cluster status:

ubuntu@ubuntu:~ $ ray status
======== Autoscaler status: 2024-05-31 20:52:39.099177 ========
Node status
---------------------------------------------------------------
Active:
 1 node_5bd8b16e07dc169bc0f7dcc901f47246c4f78a58775ff48675f298db
 1 node_023579a04c1324bb4e2cdb146f8be2a530b9e7b0d449f57d3e2e63bd
Pending:
 (no pending nodes)
Recent failures:
 (no failures)

Resources
---------------------------------------------------------------
Usage:
 0.0/384.0 CPU
 0.0/16.0 GPU
 0B/1.00TiB memory
 0B/372.53GiB object_store_memory

Demands:
 (no resource demands)

Launch model run with 16 ranks:
python -m vllm.entrypoints.openai.api_server \
    --enforce-eager \
    --tensor-parallel-size 16 \
    --swap-space 16 \
    --gpu-memory-utilization=0.9 \
    --model meta-llama/Meta-Llama-3-70B \
    --disable-custom-all-reduce \
    --disable-log-requests

Expected Behavior: The model should successfully launch and load across the specified 16 ranks.
Impact: This bug prevents launching and running large models that require a high number of ranks on multi-node clusters.

Please set the environment variable export VLLM_LOGGING_LEVEL=DEBUG to turn on more logging to help debugging potential issues.
If you experienced crashes or hangs, it would be helpful to run vllm with export VLLM_TRACE_FUNCTION=1 . All the function calls in vllm will be recorded. Inspect these log files, and tell which function crashes or hangs.

From issue templates.

I tried the above suggestions, and it seems this call causes the hang:
2024-06-03 16:53:30.748291 Call to synchronize in /home/ubuntu/shared/vllm-main/main/lib/python3.10/site-packages/torch/cuda/streams.py:93 from __init__ in /home/ubuntu/shared/vllm-main/vllm/distributed/device_communicators/pynccl.py:101

After commenting out this line, there are more hangs:
2024-06-03 17:03:26.030671 Call to _compute_cos_sin_cache in /home/ubuntu/shared/vllm-main/vllm/model_executor/layers/rotary_embedding.py:85 from __init__ in /home/ubuntu/shared/vllm-main/vllm/model_executor/layers/rotary_embedding.py:66
2024-06-03 17:03:26.030696 Call to _compute_inv_freq in /home/ubuntu/shared/vllm-main/vllm/model_executor/layers/rotary_embedding.py:70 from _compute_cos_sin_cache in /home/ubuntu/shared/vllm-main/vllm/model_executor/layers/rotary_embedding.py:87
2024-06-03 17:03:26.030797 Call to __torch_function__ in /home/ubuntu/shared/vllm-main/main/lib/python3.10/site-packages/torch/utils/_device.py:74 from _compute_inv_freq in /home/ubuntu/shared/vllm-main/vllm/model_executor/layers/rotary_embedding.py:81


Replaced concatenated strings with template literals in plugins.js

Fixes #
Changes proposed in this pull request:

Checklist:

[ ] docs updated
[ ] tests updated
[ ] Changes updated

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@d0e5426). Click here to learn what that means.
The diff coverage is 42.85%.

@@            Coverage Diff            @@
##             master       #1   +/-   ##
=========================================
  Coverage          ?   59.55%
=========================================
  Files             ?       28
  Lines             ?     6055
  Branches          ?     1500
=========================================
  Hits              ?     3606
  Misses            ?     2449
  Partials          ?        0

Impacted Files
Coverage Δ

plugins.js
77.02% <42.85%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d0e5426...5677bdb. Read the comment docs.


Implement RccPeriph and BaudPeriph for UART4, 5 traits

Hi, I'm using the stm32l476re and it seems that these two traits are semi implemented for UART 4 and 5 in util.rs, but are commented out or incomplete. Can we open these up to the L4 family (minus l4x3, l4x2, l4x1) as well? Checking against the SVD, the entire family has UART 4 and 5. I'd be glad to submit a pull request if you are looking for contributors.

Done


Read post processing treats 300 codes as failures

Treat redirect response codes as successful in default http read response processing

Coverage remained the same at 82.951% when pulling 184a63bda4cf82fb27ebd540f3eb03d649aa4d8a on redirect_response_as_success into 70037a5294f132427f422b561f21d84a5d42a9d2 on master.


header/store: unboding period handling to mitigate long-range attack

context: https://github.com/celestiaorg/celestia-node/pull/195#discussion_r749177764

Ref to #244

Fixed by syncer implementation #334


Question: does custom serializable work with structs?

The examples for custom serializable types are all classes so I wonder if structs are possible?

I just made a quick fix for supporting serializable struct type.
But it still needs more tests before release.
Personally I don't think use a serializable struct is a good idea since it requires box/unbox during deserializing, and the performance might be slower than class one.
But who knows, it might be useful in some cases.
Feel free to reopen this issue if it is not what you're asking for.

Thanks for the quick fix. Could you please elaborate about the boxing? Because I've seen some tests done by my colleagues to prove that structs are better than classes on a ScriptableObject. The results are all in favor of structs (Unity 2021).

That really depends on which platform and environment your tests are running on.
General speaking, struct with SetValueDirectly is the fastest way to deserialize data since there's no boxing involved, but unfortunately, unity's IL2CPP does not support this operator yet, so it fallback to SetValue for IL2CPP, and nowadays, almost all platform requires IL2CPP for some reason.
Anyway, always run benchmarks on your target platform and see if it is worth optimizing.
And here's my benchmark result of different ways to "deserialize" data.
BenchmarkDotNet=v0.13.2, OS=macOS Monterey 12.4 (21F79) [Darwin 21.5.0]
Apple M1 2.40GHz, 1 CPU, 8 logical and 8 physical cores
  [Host]     : Mono <IP_ADDRESS> (2020-02/6051b710727 Tue), X64 VectorSize=128
  DefaultJob : Mono <IP_ADDRESS> (2020-02/6051b710727 Tue), X64 VectorSize=128

|                                 Method |       Mean |   Error |  StdDev |   Gen0 | Allocated |
|--------------------------------------- |-----------:|--------:|--------:|-------:|----------:|
|                   Class_CreateInstance |   902.8 ns | 2.17 ns | 2.03 ns | 0.0381 |         - |
|           Class_GetUninitializedObject |   541.0 ns | 3.65 ns | 3.41 ns | 0.0381 |         - |
|         Struct_CreateInstance_SetValue | 1,070.9 ns | 2.65 ns | 2.21 ns | 0.0458 |         - |
| Struct_CreateInstance_SetValueDirectly |   846.7 ns | 1.11 ns | 0.99 ns | 0.0458 |         - |
|       Struct_GetUninitialized_SetValue |   633.7 ns | 0.80 ns | 0.67 ns | 0.0381 |         - |
| Struct_GetUninitialized_SetValueDirect |   360.8 ns | 0.18 ns | 0.15 ns | 0.0381 |         - |

Code
public class MyClass
{
    public Matrix4x4 Value;
}

public struct MyStruct
{
    public Matrix4x4 Value;
}

public class S
{
    public MyClass Class;
    public MyStruct Struct;
}

[MemoryDiagnoser]
public class Deserializing
{
    private S instance = new();
    private FieldInfo classField = typeof(S).GetField(nameof(S.Class), BindingFlags.Instance | BindingFlags.Public);
    private FieldInfo structField = typeof(S).GetField(nameof(S.Struct), BindingFlags.Instance | BindingFlags.Public);
    private Matrix4x4 value;

    private FieldInfo classValueField = typeof(MyClass).GetField(nameof(MyClass.Value), BindingFlags.Instance | BindingFlags.Public);
    private FieldInfo structValueField = typeof(MyStruct).GetField(nameof(MyStruct.Value), BindingFlags.Instance | BindingFlags.Public);

    [Benchmark]
    public S Class_CreateInstance()
    {
        var c = Activator.CreateInstance(typeof(MyClass));
        classValueField.SetValue(c, value);
        classField.SetValue(instance, c);
        return instance;
    }

    [Benchmark]
    public S Class_GetUninitializedObject()
    {
        var c = FormatterServices.GetUninitializedObject(typeof(MyClass));
        classValueField.SetValue(c, value);
        classField.SetValue(instance, c);
        return instance;
    }

    [Benchmark]
    public S Struct_CreateInstance_SetValue()
    {
        var s = Activator.CreateInstance(typeof(MyStruct));
        structValueField.SetValue(s, value);
        structField.SetValue(instance, s);
        return instance;
    }

    [Benchmark]
    public S Struct_CreateInstance_SetValueDirectly()
    {
        var s = Activator.CreateInstance(typeof(MyStruct));
        structValueField.SetValueDirect(__makeref(s), value);
        structField.SetValue(instance, s);
        return instance;
    }

    [Benchmark]
    public S Struct_GetUninitialized_SetValue()
    {
        var s = FormatterServices.GetUninitializedObject(typeof(MyStruct));
        structValueField.SetValue(s, value);
        structField.SetValue(instance, s);
        return instance;
    }

    [Benchmark]
    public S Struct_GetUninitialized_SetValueDirect()
    {
        var s = FormatterServices.GetUninitializedObject(typeof(MyStruct));
        structValueField.SetValueDirect(__makeref(s), value);
        structField.SetValue(instance, s);
        return instance;
    }
}


Building verto communicator with bower install fails

Bower install fails because the repository for Material design for bootstrap moved.
hence I had to update that package to make it work.
Error:
bower bootstrap-material-design#~0.3.0         ENORESTARGET No tag found that was able to satisfy ~0.3.0
issue:
https://github.com/FezVrasta/bootstrap-material-design  changed to https://github.com/mdbootstrap/bootstrap-material-design
Solution:
I used https://libraries.io/bower/MDBootstrap which installed the design packages for me.
bower install MDBootstrap or edit bower.json and replace bootstrap-material-design#~0.3.0 with  "MDBootstrap":"~4.1.3",
regards,
Fred

I finded that we should edit something about bower.json
change the repo from bower to github's archive
"bootstrap-material-design": "git://github.com/mdbootstrap/bootstrap-material-design#~0.3.0"


NIFI-11773 - Upgrade groovy to 3.0.18

Summary
NIFI-11773 - Upgrade groovy to 3.0.18
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[ ] Apache NiFi Jira issue created

Pull Request Tracking

[ ] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[ ] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[ ] Pull Request based on current revision of the main branch
[ ] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[ ] Build completed using mvn clean install -P contrib-check

[ ] JDK 17

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

+1 LGTM, checked the release notes and noticed a potential breaking change GROOVY-8164, but it appears to be an improvement versus a backwards-incompatible change (adding support for Java static interface methods). Thanks for the upgrade! Merging to support/nifi-1.x and main


[MINOR] Add description of POST /batches

What changes were proposed in this pull request?
Just added a description of POST /batches in the api-doc.
How was this patch tested?
Since the change is quite small, I didn't test the patch. If I have an instruction, I will follow it.

Codecov Report

Merging #283 into master will increase coverage by 0.05%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #283      +/-   ##
============================================
+ Coverage      68.2%   68.26%   +0.05%
  Complexity      965      965
============================================
  Files           104      104
  Lines          5951     5952       +1
  Branches        900      900
============================================
+ Hits           4059     4063       +4
+ Misses         1314     1309       -5
- Partials        578      580       +2

Impacted Files
Coverage Δ
Complexity Δ

...cala/org/apache/livy/scalaapi/ScalaJobHandle.scala
52.94% <0%> (-2.95%)
7% <0%> (ø)

...ain/java/org/apache/livy/rsc/driver/RSCDriver.java
80.83% <0%> (ø)
45% <0%> (-1%)
:arrow_down:

...va/org/apache/livy/client/http/LivyConnection.java
82.27% <0%> (+0.22%)
15% <0%> (ø)
:arrow_down:

...main/scala/org/apache/livy/server/LivyServer.scala
33.48% <0%> (+0.44%)
11% <0%> (ø)
:arrow_down:

...ain/scala/org/apache/livy/utils/SparkYarnApp.scala
73.75% <0%> (+1.87%)
40% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3a26856...a6d8aab. Read the comment docs.

Thanks for the fix, merging to master branch.


Stitching is sub-optimal in Daphne

Although Daphne's results look impressive, a single tile looks like it displays a large z-shift accumulated in the stitch stage.
Long term, we need to look into how to resolve this and possibly transition to zetastitcher.

closing as stitching works very well with new algorithm


SSL Certificate

Loggly has fixed the issue with the SSL certificate.  Maybe you want to remove the note around SSL issues in the docs?

Thanks for notifying me! The warning is removed now.


Mail server cannot access database

Mail server and Flask web server are currently running at two different process. Mail server therefore cannot access the the database via SQLAlchemy.

The mail server is supposed to be in a separate project on a separate host and only send POST request to this API to save email to the database.


scroll issue for 4"(se1,5s...)

cant see payment button

Hi @NSMohammad thanks for reporting this issue, we work on it.


DDoS protection plan for Azure AD?

How do I make sure AAD is not flooded from DDoS attack? Will DDoS protection plan cover it?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6f38b1bd-2ab0-71f1-a6e9-925b7af3389d
Version Independent ID: 9528f5cf-16e1-0550-dc3e-edc135c82167
Content: Azure DDoS Protection Standard Overview
Content Source: articles/virtual-network/ddos-protection-overview.md
Service: virtual-network
GitHub Login: @KumudD
Microsoft Alias: kumud

@codemaker , DDOS Standard only protects the Public IP of the resources which are part of the VNET in which Standard plan is enabled.
Azure AD is not covered in DDOS but DDOS basic is enabled for all Azure resources in Azure which is part of the platform itself to protect against DDOS attack.

@codemaker , Do you have any update for me on this issue?

@codemaker , Tag me if you have any further questions.


[Improvement]  UI: Make catalogs information more clear

What would you like to be improved?

How should we improve?
We

Resolved by #1579.


Parse the tasks as text and return object

Should respect the Todo.txt format

@bmedy if you can take a look at my first javascript code, it would be nice.

Tips :
you can add #!/usr/bin/env node at start of file.
and allow execution mode on file
$ chmod +x parseTask.js
and then you can run your code with ./src/tasks/parseTask.js
Have good ;)

Thanks great tip, I will use is for quick scripting
I created an issue for the bug you found #7 ;)


Add new errors to ddsrecorder

New errors reported:
1. Failure to create mcap file: [DDSRECORDER_MCAP_HANDLER Warning] Failed to open MCAP file
2. Disk full / failure to write to disk: [DDSRECORDER_MCAP_HANDLER Error] Not enough space available on disk. Space available: 0

Codecov Report
Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (ea973cb) 19.24% compared to head (a99bb98) 19.23%.
Report is 1 commits behind head on main.

Files
Patch %
Lines

...participants/src/cpp/recorder/mcap/McapHandler.cpp
0.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #127      +/-   ##
==========================================
- Coverage   19.24%   19.23%   -0.01%
==========================================
  Files          32       32
  Lines        2832     2833       +1
  Branches     1501     1502       +1
==========================================
  Hits          545      545
- Misses       1802     1803       +1
  Partials      485      485

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Refactor List table to use react-table

The big table on the list page now uses react-table.
This library is amazing as it takes care of so many things one would need to implement manually, like sorting, filtering, column visibility, formatting, and more.
Additionally, a search input has been added. It searches for SLO names and also works to search for label name and values. 🎉

Lol that was completely unintentional, please ignore ahahahaha

No worries, this is project is open to reviews from anyone! ☺
Let me know what you think. 😉

Looks Great!!


Looping Commit > Export > Commit workflow

Currently testing the publishing of http://bicycle-demo-msm.review.dgadteamdev.com/mentions-légales, created in the "default" node of our testing environment, that I would like to roll out to other sub-locales.
I encountered the following issue (Chrome 58 on Windows 7):

open http://bicycle-demo-msm.review.dgadteamdev.com/mentions-légales in admin mode (admin/admin)
edit it in draft mode
commit it; you will land on a screen that says "it is already committed on default, with an Export button"
clicking on Export will show the locale tree
re-committing, it is going back to the previous screen, and so on

Console input:

Stack trace:
/app/node_modules/apostrophe-workflow/lib/removeDotPathViaSplice.js:12
    o = o[elements[i]];
         ^

TypeError: Cannot read property ‘headline’ of undefined
    at module.exports (/app/node_modules/apostrophe-workflow/lib/removeDotPathViaSplice.js:12:10)
    at deleteObject (/app/node_modules/apostrophe-workflow/index.js:956:19)
    at /app/node_modules/apostrophe-workflow/index.js:995:17
    at arrayEach (/app/node_modules/apostrophe-workflow/node_modules/lodash/index.js:1289:13)
    at Function.<anonymous> (/app/node_modules/apostrophe-workflow/node_modules/lodash/index.js:3345:13)
    at purgeObjects (/app/node_modules/apostrophe-workflow/index.js:994:17)
    at applyPatch (/app/node_modules/apostrophe-workflow/index.js:891:13)
    at /app/node_modules/async/lib/async.js:718:13
    at Immediate.iterate (/app/node_modules/async/lib/async.js:262:13)
    at runCallback (timers.js:651:20)
    at tryOnImmediate (timers.js:624:5)
    at processImmediate [as _immediateCallback] (timers.js:596:5)

npm info lifecycle<EMAIL_ADDRESS>Failed to exec start script
npm ERR! Linux 4.4.0-28-generic
npm ERR! argv “/usr/local/bin/node” “/usr/local/bin/npm” “start”
npm ERR! node v6.10.0
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>start: `babel-node app.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script ‘babel-node app.js’.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the bicycle package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     babel-node app.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs bicycle
npm ERR! Or if that isn’t available, you can get their info via:
npm ERR!     npm owner ls bicycle
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /app/npm-debug.log

I've committed a change to apostrophe-workflow that should get you past
this, let me know.
On Fri, Jun 9, 2017 at 8:02 AM, ECoursimaultM<EMAIL_ADDRESS>wrote:

Currently testing the publishing of http://bicycle-demo-msm.
review.dgadteamdev.com/mentions-légales, created in the "default"
node of our testing environment, that I would like to roll out to other
sub-locales.
I encountered the following issue (Chrome 58 on Windows 7):

open http://bicycle-demo-msm.review.dgadteamdev.com/
mentions-l%C3%A9gales in admin mode (admin/admin)
edit it in draft mode
commit it; you will land on a screen that says "it is already
committed on default, with an Export button"
clicking on Export will show the locale tree
re-committing, it is going back to the previous screen, and so on

Console input:
[image: image]
https://user-images.githubusercontent.com/29304766/26974597-52002090-4d1c-11e7-87f4-8e780b713ab1.png
Stack trace:
/app/node_modules/apostrophe-workflow/lib/removeDotPathViaSplice.js:12
o = o[elements[i]];
^
TypeError: Cannot read property ‘headline’ of undefined
at module.exports (/app/node_modules/apostrophe-workflow/lib/removeDotPathViaSplice.js:12:10)
at deleteObject (/app/node_modules/apostrophe-workflow/index.js:956:19)
at /app/node_modules/apostrophe-workflow/index.js:995:17
at arrayEach (/app/node_modules/apostrophe-workflow/node_modules/lodash/index.js:1289:13)
at Function. (/app/node_modules/apostrophe-workflow/node_modules/lodash/index.js:3345:13)
at purgeObjects (/app/node_modules/apostrophe-workflow/index.js:994:17)
at applyPatch (/app/node_modules/apostrophe-workflow/index.js:891:13)
at /app/node_modules/async/lib/async.js:718:13
at Immediate.iterate (/app/node_modules/async/lib/async.js:262:13)
at runCallback (timers.js:651:20)
at tryOnImmediate (timers.js:624:5)
at processImmediate [as _immediateCallback] (timers.js:596:5)
npm info lifecycle<EMAIL_ADDRESS>Failed to exec start script
npm ERR! Linux 4.4.0-28-generic
npm ERR! argv “/usr/local/bin/node” “/usr/local/bin/npm” “start”
npm ERR! node v6.10.0
npm ERR! npm  v3.10.10
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>start: babel-node app.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script ‘babel-node app.js’.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the bicycle package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     babel-node app.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs bicycle
npm ERR! Or if that isn’t available, you can get their info via:
npm ERR!     npm owner ls bicycle
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     /app/npm-debug.log
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/punkave/apostrophe-workflow/issues/56, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AAB9fQh1pog5XmRs673HxJXNOT4pVkXQks5sCTRzgaJpZM4N1Q8e
.

--
*THOMAS BOUTELL, *SUPPORT LEAD
P'UNK AVENUE |<PHONE_NUMBER>  |  punkave.com


Make SRem sign aware like all the other arithmetic ops.

Fix #2396.

Ok, that fixes my problem, thanks!


[1403] add override for search bar [master]

Gets rid of the unwanted height depicted in #1403

Great catch, thanks for the fix. Can you update the commit message to match the specs in the CHANGELOG and cherry-pick the resulting commit onto release-v5.5 in a new branch and open a PR for it so we can merge this fix into v5.5.1 as well? Thanks!

I updated the commit message, merging!


Update prime api demo script

Description
To better support the new flow this PR updates the prime-api-demo script. It adds support to set the destination address, it supports mtoID or moveOrderID as the latter is easier to retrieve during the TOO stage, and finally it also triggers the Payment Request's status to go from Reviewed to Sent_to_Gex after the edi is generated
Reviewer Notes
I also added to https://github.com/transcom/mymove/wiki/Manually-run-Prime-API-for-Slice-demo
Setup
Add any steps or code to run in this section to help others prepare to run your code:
make db_dev_e2e_populate
make server_run
prime-api-demo 9c7b255c-2981-4bf8-839f-61c7458e2b4d

Feel free to start the client and go through creating a new move and using that move with the demo script.
Code Review Verification Steps

[X] Request review from a member of a different team.

Warnings

:warning:
Please add the JIRA issue key to the PR title (e.g. MB-123)

  Generated by :no_entry_sign: dangerJS against a0773c294b257340f8ad807f4f38e514ad1d616e

This might not be particular to this particular PR but I ran the script and noticed it says it created a payment request for 4 service items but the displayed payload only has 3. Seems to be missing FSC
Sending the following create payment request payload for DLH, FSC, MS, and CS:

{
  "body": {
    "isFinal": false,
    "moveTaskOrderID": "9c7b255c-2981-4bf8-839f-61c7458e2b4d",
    "serviceItems": [
      {
        "id": "6431e3e2-4ee4-41b5-b226-393f9133eb6c"
      },
      {
        "id": "ca9aeb58-e5a9-44b0-abe8-81d233dbdebf"
      },
      {
        "id": "722a6f4e-b438-4655-88c7-51609056550d"
      }
    ]
  }
}

Yeah I've seen that, I believe it's due to the seed data missing one of the service items. I'll update the seed data to have all four, which will be true when going through the ui flow to create the move.


syscall: panic in syscall.ParseNetlinkMessage when attempting to copy past slice end

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.7.4 linux/amd64
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/elevran/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build112723414=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
What did you do?
Use netfilter subsystem to deliver traffic to user space using https://github.com/elevran/nfq.
Running instructions to reproduce are in README. The failure is not deterministic, and depends on actual messages sent by kernel. An example failure is documented in https://github.com/subgraph/go-nfnetlink/pull/3, which fixes an issue with the go-nfnetlink library.
What did you expect to see?
All valid packets of the connection are processed by the usersapce program
What did you see instead?
Panic in syscall.ParseNetlinkMessage
Note
This is a duplicate of https://github.com/golang/go/issues/16681, which was closed and planned for 1.8.
I believe the fix in https://github.com/golang/go/commit/6fd8c006adf792e523232a026823a5444893f28f can be improved. The current suggestion logs an error and drops packets, which I think is too strict.
To the best of my understanding there is no hard and clear requirement that netlink messages are always aligned in size, only that they should start at an aligned address. This leaves room for a case where the last message has a size which is not a multiple of the required alignment, causing the parsing call to attempt accessing past the slice end.

So did you try Go 1.8?

@bradfitz
I have.
An EINVAL is returned from the parsing which skips packet processing. Only two packets are processed before the userspace program receives (indirectly) an invalid argument error from ParseNetlinkMessage using the go 1.8rc2 code base.
The code is in the subgraph branch, since master has a fix that bypasses the issue in the go-nfnetlink package itself.
build and run test program
$ go version
go version go1.8rc2 linux/amd64
$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/elevran/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build882606754=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
$ git checkout subgraph
$ go build .
$ sudo ./nfq
Packet: PACKET: 60 bytes
- Layer 1 (20 bytes) = IPv4	{Contents=[..20..] Payload=[..40..] Version=4 IHL=5 TOS=0 Length=60 Id=11896 Flags=DF FragOffset=0 TTL=64 Protocol=TCP Checksum=16952 SrcIP=<IP_ADDRESS> DstIP=<IP_ADDRESS> Options=[] Padding=[]}
- Layer 2 (40 bytes) = TCP	{Contents=[..40..] Payload=[] SrcPort=36738 DstPort=80(http) Seq=2493731064 Ack=0 DataOffset=10 FIN=false SYN=true RST=false PSH=false ACK=false URG=false ECE=false CWR=false NS=false Window=29200 Checksum=6124 Urgent=0 Options=[..5..] Padding=[]}

Packet: PACKET: 40 bytes
- Layer 1 (20 bytes) = IPv4	{Contents=[..20..] Payload=[..20..] Version=4 IHL=5 TOS=0 Length=40 Id=11897 Flags=DF FragOffset=0 TTL=64 Protocol=TCP Checksum=16971 SrcIP=<IP_ADDRESS> DstIP=<IP_ADDRESS> Options=[] Padding=[]}
- Layer 2 (20 bytes) = TCP	{Contents=[..20..] Payload=[] SrcPort=36738 DstPort=80(http) Seq=2493731065 Ack=354624002 DataOffset=5 FIN=false SYN=false RST=false PSH=false ACK=true URG=false ECE=false CWR=false NS=false Window=29200 Checksum=50979 Urgent=0 Options=[] Padding=[]}

Error from socket receive: invalid argument - closed channel
Exiting after 2 packets

$ wget www.google.com
--2017-01-20 10:47:41--  http://www.google.com/
Resolving www.google.com (www.google.com)... <IP_ADDRESS>, 2a00:1450:400e:805::2004
Connecting to www.google.com (www.google.com)|<IP_ADDRESS>|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.google.co.il/?gfe_rd=cr&ei=rc6BWM3jDKGk8wf927KADA [following]
--2017-01-20 10:47:42--  http://www.google.co.il/?gfe_rd=cr&ei=rc6BWM3jDKGk8wf927KADA
Resolving www.google.co.il (www.google.co.il)... <IP_ADDRESS>, 2a00:1450:400e:804::2003
Connecting to www.google.co.il (www.google.co.il)|<IP_ADDRESS>|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.1’

index.html.1            [ <=>                ]  10.94K  --.-KB/s    in 0.001s

2017-01-20 10:47:42 (8.61 MB/s) - ‘index.html.1’ saved [11199]

Sure, send a change via Gerrit? See https://golang.org/doc/contribute.html

https://go-review.googlesource.com/35531

I'm closing this as WontFix. My comment on the CL:

It sounds like there isn't consensus on what to do here, so the default is to not accept this, especially since it's in the syscall package which is frozen. Development should happen in x/sys/unix or x/net.


Add PromQL syntax text with tabs, spaces, trailing commas, singlequotes

Signed-off-by: Julien Pivotto<EMAIL_ADDRESS>

I'd suggest a comment that some of these are tabs/spaces. Otherwise it might get auto-formatted away at some point - might even be worth testing these ones in Go rather than here.

You might want to include some test with backquotes, too.

I guess some weird unicode quotes while we're at it too.

OK I will work on that in the coming days


sanitycheck: support symbolic links in ZEPHYR_BASE

Fix issue where sanitycheck wrongly assumes all tests to be external
when ZEPHYR_BASE contains symbolic link(s) because it compares
"testcase_root" oranges with ZEPHYR_BASE apples.
The consequence was sanitycheck dropping the --testcase-root prefix
argument from the unique name for Zephyr tests which means some test
names could be not unique anymore and silently overwrite each other's
results. Example:
bash# cd zephyr_dir_with_symlink; export ZEPHYR_BASE=$(pwd)
./scripts/sanitycheck -T samples/portability/cmsis_rtos_v1
-T samples/portability/cmsis_rtos_v2
The more systematic and practical consequence (and how I actually found
this) was test outputs landing in unexpected locations.
To define a unique name, TestCase.get_unique(testcase_root) first checks
whether testcase_root contains ZEPHYR_BASE. ZEPHYR_BASE is defined by
the user's environment and can contain symbolic link(s). On the other
hand, testcase_root is (to keep things short) typically defined by
sanitycheck as "os.getcwd()/testcase_root_arg". As specific by POSIX
getcwd() never contains any symbolic link.
The fix is just re-using:
real_zephyr_base = os.path.realpath(ZEPHYR_BASE)
... which was already defined later and resolves symbolic links.
Signed-off-by: Marc Herbert<EMAIL_ADDRESS>

testcase_root can have have symlinks too when it's the default (thx @mbolivar), pushed new version that canonicalizes both testcase_root and ZEPHYR_BASE

testcase_root can have have symlinks too when it's the default (thx @mbolivar), pushed new version that canonicalizes both testcase_root and ZEPHYR_BASE

Is --testcase-root the only one? What about --board-root? Are there any others?

I reviewed all direct and indirect uses of ZEPHYR_BASE and I haven't found any that involves a path comparison or requires canonicalization for any other reason. I've tested sanitycheck (compiling hundreds of tests) with symbolic links using a fair number of its features and I didn't find any other similar issue. In case I missed one similar issue in some other feature I didn't use, the new canonical_zephyr_base constant will make it easier to fix.
Keep in mind the only thing this PR fixes is test outputs landing in the wrong place (and in case of extremely bad luck overwriting each other). So it's possible that people have already been using sanitycheck with symbolic links for a long time without noticing any problem.