text:
GH-70 Allow the client to discover new brokers

Refactor the message listener container to finish tasks on broker connection failure
and spawn new ones whenever a new broker is discovered;
Add an explicit disconnect operation on the ConnectionFactory to release the connection
on failure;
Other improvements and test refactorings;

This is a pretty big change to have no tests :smile:
Given the commit comment mentions tests, I guess this was due to the commit hour.

Yeah, actually I've tested this manually, since tests that involve starting and stopping brokers are faring pretty badly with the PR.
Let me add one though.

The test battery should catch any regressions though.

The 'test refactoring' was an artifact of an earlier change that I ditched on rebase, since it didn't really improve much over the existing test set.

That's all for me here.
Will take a look one more time when will be at home this afternoon.
But everything looks good anyway. I don't see now critical concerns, unless it is still enough difficult to determine the whole logic when it is distributed between thread...
From other side I still don't feel good with those GC Collections :cry:

@mbogoevici , does it say anything to you?
15:31:03.233 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@0
15:31:03.237 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@2
15:31:03.239 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@4
15:31:03.241 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@6
15:31:03.242 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@8
15:31:03.243 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@10
15:31:03.244 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@12
15:31:03.245 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@14
15:31:03.246 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@16
15:31:03.248 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@18
15:31:03.249 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@20
15:31:03.251 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@22
15:31:03.252 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@24
15:31:03.253 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@26
15:31:03.254 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@28
15:31:03.257 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@30
15:31:03.258 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@32
15:31:03.260 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@34
15:31:03.261 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@36
15:31:03.262 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@38
15:31:03.263 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@40
15:31:03.265 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@42
15:31:03.267 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@44
15:31:03.268 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@46
15:31:03.270 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@48
15:31:03.374 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@50
15:31:03.476 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@50
15:31:03.579 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@50
15:31:03.683 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@50
15:31:03.785 DEBUG [kafka-fetch-1][org.springframework.integration.kafka.core.DefaultConnection] Reading from Partition[topic='test-topic', id=0]@50

and so on for the 50

Well, that's what you get when debug is enabled for `[org.springframework.integration.kafka.core.DefaultConnection. It's disabled by default in the tests.

I guess we could consider dropping it to trace level. @mbogoevici are we expecting a final commit to address the loose ends?

I guess https://github.com/spring-projects/spring-integration-kafka/pull/89#issuecomment-157423426, I guess we just have a couple of minor things left: https://github.com/spring-projects/spring-integration-kafka/pull/89#discussion_r45081740 and https://github.com/spring-projects/spring-integration-kafka/pull/89#discussion_r45081556. The main question there was running the tests in Windows.

Oh, sorry; I see you reverted that AtomicInteger stuff - @artembilan are you going to merge after testing on Windoze?

Merged as https://github.com/spring-projects/spring-integration-kafka/commit/cabc9d14a717222fd6ffb3969288f44eba9b1d29

authors: artembilan garyrussell mbogoevici


text:
transactional.id per topic/partition

https://www.confluent.io/blog/transactions-apache-kafka/

The key to fencing out zombies properly is to ensure that the input topics and partitions in the read-process-write cycle is always the same for a given transactional.id. If this isn’t true, then it is possible for some messages to leak through the fencing provided by transactions.

For instance, in a distributed stream processing application, suppose topic-partition tp0 was originally processed by transactional.id T0. If, at some point later, it could be mapped to another producer with transactional.id T1, there would be no fencing between T0 and T1. So it is possible for messages from tp0 to be reprocessed, violating the exactly once processing guarantee.

Practically, one would either have to store the mapping between input partitions and transactional.ids in an external store, or have some static encoding of it. Kafka Streams opts for the latter approach to solve this problem.

Hi,
I was just going to write an issue about that here :)
I'm using kafka 1.3.6.RELEASE and I'm having a headache trying to understand and implement transaction in a read-process-write cycle.
Having several instance of my application running, when a consumer partition rebalance occur, the transaction are not preventing me from getting duplicates.
The transaction id should be computed with topic-name.group-id.partition-id when using it in a listener container or something.
With the actuel implementation, the id being generated on producer creation, I can't achieve this.
Thanks for opening this.

@Rajh 2.1.10 and 1.3.7 containing this fix is now in maven central.

source: gharchive/issue

authors: Rajh garyrussell

repo: spring-projects/spring-kafka

license_type: permissive

license_source: github-api


text:
Ability to use non-shaded Pulsar Client with the Spring Boot starter

Feature request:
The current Pulsar client used by the spring-pulsar-spring-boot-starter is a "shaded" jar file, which means all the dependencies are in the same jar and with a modified package name. While shading can be useful to avoid dependency conflicts, it also means users of the jar cannot exclude or override these dependencies through Maven/Gradle. Being able to override dependencies is sometimes desirable/necessary, for example if these dependencies have a known vulnerability. A concrete example: the 2.12.1 version of the client (used by the 0.2 version of the starter contains a vulnerable version of Google Guava.
A non-shaded version of the Pulsar client is available (pulsar-client-original), but I cannot use that to override the client used by the starter, as it throws a ClassNotFoundException due to the fact the shaded package and the non-shaded packages are different.
Possible solutions would include:

have the starter use the non-shaded Pulsar Cliente
give the option of using the non-shaded Pulsar Client (either built-in or with a dependency override)

(PS I could solve the concrete example above, as Pulsar has a 2.12.2 version of the client that does not use the vulnerable Guava version, so I am not looking to solve this particular instance, but more in general.)

Hi @jheijmans
I am glad 2.11.2 solves this particular issue.  I do understand your use case. We will likely always use the shaded version as the default as the client has many dependencies that will clash with user application dependencies. The shading allows the client to use whatever it wants as an internal concern, at the expense of not letting the user manage the dependencies (in your case, exclude a vulnerable lib).
I believe you could exclude pulsar-client-all from the starter and just use the pulsar-client-orignal and pulsar-client-admin-original.

Hi @jheijmans
Were you able to verify if you could do the suggested workaround from above?

I believe you could exclude pulsar-client-all from the starter and just use the pulsar-client-orignal and pulsar-client-admin-original.

Closing this out as "wont fix".

authors: jheijmans onobc

repo: spring-projects/spring-pulsar


text:
Set path prefix to Authentication redirect with WebFlux and Spring Boot

Summary
Add prefix in WebFlux + Spring Boot that would be honored by DefaultServerRedirectStrategy
Actual Behavior
I cannot see an option to set a prefix for Authentication redirect.
I've tried to set server.servlet.context-path but it's not honored

Ok, if someone would have similar issue in the future - instead of trying to set context path, use ForwardedHeaderTransformer that will retrieve path prefix if your app is behind a proxy or load balancer

repo: spring-projects/spring-security-oauth

license_source: bigquery


text:
Enum array is parsed as a string array in a request param.

Hi,
I have a following RequestParam filterBy which is a Enum array.
public enum ContactField {
    COMPANY,
    TITLE;
}

@RequestParam(value = "filterBy", required = false) ContactField[] filterBys,

The ContactField[] is mapped to a string array.

             {
                "name": "filterBy",
                "in": "query",
                "description": "filterBys",
                "required": false,
                "type": "array",
                "items": {
                    "type": "string"
                },
                "collectionFormat": "csv"
            },

Closing this as its a duplicate of #664
It should've rendered the alowable values in the items object, which its not doing. More detailed explanation of why this is happening over in the other issue.

authors: RobWin dilipkrish

repo: springfox/springfox


text:
Add maven dependency example

Add maven dependency example

Thanks for the PR!

source: gharchive/pull-request

authors: qmunke stavshamir


text:
EIP-1271 Support

Add support for EIP-1271 to support smart contract wallets. The web3 provider used should be configurable by the end user to allow for vendor agnosticism. This should not be a required flow to use the library, as some implementers may want to support EOA accounts only in their deployments.

@CPerezz - from the SIWE community call if you're interested!

repo: spruceid/siwe-rs


text:
Comment typo

I think there's a copypaste error in the comment at https://github.com/spruceid/ssi/blob/c800b20463024ea0d9e144635de9a6c6d9fcde03/crates/jwk/src/lib.rs#L1082 A P-384 public key serialized with point compression is a 49 byte string.

Good catch, I'll fix it.

authors: mspiegel timothee-haudebourg

repo: spruceid/ssi


text:
Nonetype object is not subscriptable

Description
What steps will reproduce the problem?

I open the project and it comes up with the box that says Spyder has encountered an internal project.
File "C:\Users\rayde\iCloudDrive\GitHub\Anaconda3\lib\site-packages\spyder\plugins\completion\kite\client.py", line 135, in perform_request
Traceback
  File "C:\Users\rayde\iCloudDrive\GitHub\Anaconda3\lib\site-packages\spyder\plugins\completion\kite\client.py", line 135, in perform_request
TypeError: 'NoneType' object is not subscriptable

Versions

Spyder version: 4.0.0b4
Python version: 3.7.1
Qt version: 5.9.6
PyQt5 version: 5.9.2
Operating System: Windows 10

Dependencies
pygments >=2.0    :  2.3.1 (OK)
qdarkstyle >=2.6.4:  2.7 (OK)
sphinx >=0.6.6    :  1.8.2 (OK)
pyls >=0.27.0     :  0.28.0 (OK)
nbconvert >=4.0   :  5.4.0 (OK)
pandas >=0.13.1   :  0.23.4 (OK)
numpy >=1.7       :  1.17.1 (OK)
sympy >=0.7.3     :  1.3 (OK)
cython >=0.21     :  0.29.2 (OK)
qtconsole >=4.5.2 :  4.5.2 (OK)
IPython >=4.0     :  7.2.0 (OK)
matplotlib >=2.0.0:  3.0.2 (OK)
pylint >=0.25     :  2.2.2 (OK)

Spyder version: 4.0.0b4

Please update to beta7. This error should be fixed in that version.

repo: spyder-ide/spyder

license: MIT


text:
Add Sparkle Framework for macOS Application Update

See:

https://sparkle-project.org/
https://fman.io/blog/codesigning-and-automatic-updates-for-pyqt-apps/

Closing in favor of our own update mechanisms for conda-based installers.


text:
Spyder calls discrete graphics on Windows

Issue Report Checklist

[x] Searched the issues page for similar reports
[x] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
[x] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
[ ] Could not reproduce inside jupyter qtconsole (if console-related)
[x] Tried basic troubleshooting (if a bug/error)

[x] Restarted Spyder
[x] Reset preferences with spyder --reset
[x] Reinstalled the latest version of Anaconda
[x] Tried the other applicable steps from the Troubleshooting Guide

[x] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description
Spyder IDE randomly call DGPU. I cant open it without it calling the dedicated nividia card.
What steps reproduce the problem?

simply open spyder

What is the expected output? What do you see instead?
I would the spyder to not unnecessarily call the DGPU a
Paste Traceback/Error Below (if applicable)

PASTE TRACEBACK HERE

Versions

Spyder version: 5.4.3  (conda)
Python version: 3.11.7 64-bit
Qt version: 5.15.2
PyQt5 version: 5.15.10
Operating System: Windows 11

Dependencies

PASTE DEPENDENCIES HERE

Mandatory:
atomicwrites >=1.2.0                             :  1.4.0 (OK)
chardet >=2.0.0                                  :  4.0.0 (OK)
cloudpickle >=0.5.0                              :  2.2.1 (OK)
cookiecutter >=1.6.0                             :  2.5.0 (OK)
diff_match_patch >=20181111                      :  20200713 (OK)
intervaltree >=3.0.2                             :  3.1.0 (OK)
IPython >=7.31.1,<9.0.0,!=8.8.0,!=8.9.0,!=8.10.0 :  8.20.0 (OK)
jedi >=0.17.2,<0.19.0                            :  0.18.1 (OK)
jellyfish >=0.7                                  :  1.0.1 (OK)
jsonschema >=3.2.0                               :  4.19.2 (OK)
keyring >=17.0.0                                 :  23.13.1 (OK)
nbconvert >=4.0                                  :  7.10.0 (OK)
numpydoc >=0.6.0                                 :  1.5.0 (OK)
paramiko >=2.4.0                                 :  2.8.1 (OK)
parso >=0.7.0,<0.9.0                             :  0.8.3 (OK)
pexpect >=4.4.0                                  :  4.8.0 (OK)
pickleshare >=0.4                                :  0.7.5 (OK)
psutil >=5.3                                     :  5.9.0 (OK)
pygments >=2.0                                   :  2.15.1 (OK)
pylint >=2.5.0,<3.0                              :  2.16.2 (OK)
pylint_venv >=2.1.1                              :  2.3.0 (OK)
pyls_spyder >=0.4.0                              :  0.4.0 (OK)
pylsp >=1.7.2,<1.8.0                             :  1.7.2 (OK)
pylsp_black >=1.2.0                              :  1.2.1 (OK)
qdarkstyle >=3.0.2,<3.2.0                        :  3.0.2 (OK)
qstylizer >=0.2.2                                :  0.2.2 (OK)
qtawesome >=1.2.1                                :  1.2.2 (OK)
qtconsole >=5.4.2,<5.5.0                         :  5.4.2 (OK)
qtpy >=2.1.0                                     :  2.4.1 (OK)
rtree >=0.9.7                                    :  1.0.1 (OK)
setuptools >=49.6.0                              :  68.2.2 (OK)
sphinx >=0.6.6                                   :  5.0.2 (OK)
spyder_kernels >=2.4.3,<2.5.0                    :  2.4.4 (OK)
textdistance >=4.2.0                             :  4.2.1 (OK)
three_merge >=0.1.1                              :  0.1.1 (OK)
watchdog >=0.10.3                                :  2.1.6 (OK)
zmq >=22.1.0                                     :  25.1.2 (OK)
Optional:
cython >=0.21                                    :  None (NOK)
matplotlib >=3.0.0                               :  3.8.0 (OK)
numpy >=1.7                                      :  1.26.4 (OK)
pandas >=1.1.1                                   :  2.1.4 (OK)
scipy >=0.17.0                                   :  1.11.4 (OK)
sympy >=0.7.3                                    :  1.12 (OK)

Hey @nitro122, thanks for reporting. Please close Spyder, open the Anaconda Prompt and run there
spyder --reset
and try again.
Let us know if that helps.

hey @ccordoba12 , thankyou for your reply. I ran spyder --reset but unfortunately the issue still remains.

Then I don't know what happens because our default option is to not use the GPU in our interface but software acceleration instead.
You can check that by going to the menu Tools > Preferences and then
Application > Advanced settings > Rendering engine

i checked it out. it says 'Desktop'. It call it at very random intervals. For instance when opening spyder the nvidia gpu indicator would light up and then switch off. This will playout until i close both spyder and anaconda. Hence believe it might be a bug

hey @ccordoba12 , I changed it to 'software'. But the indicator still turns on and off at random intervals when Spyder is open . Could it be a bug? Or are there any other settings I should change.

You need to restart Spyder doing it. Did you do that?

Yes, it did prompt me to restart Spyder.

Sorry, then I'd say this is not a Spyder problem. Sure, when you open Spyder the GPU is enabled, but Spyder depends on about 100 libraries (between direct and indirect dependencies), so any of them could be enabling it.
Sorry but for now I'm going to close this issue because I don't have additional feedback to give you. But if you gather more info about this, please post it here and I'll reopen it to continue the discussion.

What does "Desktop" mean in this context? It is not self-explanatory to the average user.

Sorry, then I'd say this is not a Spyder problem. Sure, when you open Spyder the GPU is enabled, but Spyder depends on about 100 libraries (between direct and indirect dependencies), so any of them could be enabling it.
Sorry but for now I'm going to close this issue because I don't have additional feedback to give you. But if you gather more info about this, please post it here and I'll reopen it to continue the discussion.

Hi @ccordoba12 ,
Thank you very much. I got it working

@hippie68, that's the terminology used by Qt. You can read more about it here.
@nitro122, that's great! How did you manage to fix it?

@hippie68, that's the terminology used by Qt. You can read more about it here.
@nitro122, that's great! How did you manage to fix it?

I installed the Standalone Spyder.


text:
Variable explorer does not show variables and crashes when buttons on side pressed

Description
What steps will reproduce the problem?

Changing the variable explorer preferences in the spyder preferences

What is the expected output? What do you see instead?
Please provide any additional information below
When I change any settings in the variable explorer Spyder crashes. When I run any script I cannot see any of the variables in the environment. It is empty. I have tried re-installing anaconda and spyder and neither works.
Version and main components

Spyder Version: 2.3.6
Python Version: 2.7.10
Qt Versions:  4.8.6, PyQt4 (API v2) 4.11.3 on Darwin

Optional dependencies
pyflakes >=0.5.0:  0.9.2 (OK)
pep8 >=0.6      :  1.6.2 (OK)
pygments >=1.6  :  2.0.2 (OK)
IPython >=1.0   :  4.0.0 (OK)
zmq >=2.1.11    :  14.7.0 (OK)
qtconsole >=4.0 :  4.0.1 (OK)
pandas >=0.13.1 :  0.16.2 (OK)
sphinx >=0.6.6  :  1.3.1 (OK)
psutil >=0.3    :  2.2.1 (OK)
rope >=0.9.2    :  0.9.4 (OK)
jedi >=0.8.1    :  0.9.0 (OK)
matplotlib >=1.0:  1.4.3 (OK)
sympy >=0.7.3   :  0.7.6 (OK)
pylint >=0.25   :  None (NOK)

Are you using 10.10 or 10.11 by any chance?

Closing because of lack of response.
If you're using 10.10 or 10.11, this problem could be fixed by an Anaconda update in a couple of weeks.

Are you using 10.10 or 10.11 by any chance?
I see that this question comes back often. Is it possible to include this information in the bug template ?

Yes, I think it's possible :-) Could you open an issue about it so I don't forget to do it?

Well I could, but I don't even know what 10.10 and 10.11 refer to exactly... Is it the Darwin version ?

authors: Nodd ccordoba12 cvanheer


text:
Scroll down/up scrolls down twice

Description of your problem
Scroll down/up performs two consecutive calls to scroll instead of a single one
What steps will reproduce the problem?

Place the cursor on the first line of a file in the editor pane
Press scroll down (PageDown key)

What is the expected output? What do you see instead?
The cursor should be at line 26 (assuming the scroll is 25 lines), but instead it is at line 52
Please provide any additional information below
Versions and main components

Spyder Version:3.2.0dev (3.x branch) and 4.0.0dev (master)
Python Version:3.5.2
Qt Version:5.6.2
PyQt Version:5.6
Operating system:Linux

Dependencies
Please go to the menu entry Help > Optional Dependencies (or
Help > Dependencies), press the button Copy to clipboard
and paste the contents below:

This is caused by this change https://github.com/spyder-ide/spyder/commit/738f8e190f4256ff26f741af4c8e7bed20ace460#diff-b19a1c3b49c9057f7bf2edae2a53747dR2710 keyPressEvent is called twice (at keyPress and also at keyRelease)
Should it be super(CodeEditor, self).KeyReleaseEvent(event)?
@goanpeca

@rlaverde, please work on this one.

authors: ccordoba12 liavassif rlaverde


text:
Spyder fails with: "ValueError: numpy.ufunc has the wrong size, try recompiling"

From martinzi...@gmail.com on 2011-11-07T09:17:46Z
I am unable to install and run spyder 2.0.12 or 2.1.1 on my Mac OS X 10.7 (Lion) due to the error above, from both MacPorts and a download form this site.
I would be very grateful if someone could help out - I am missing spyder!
Thanks,
Martin.
More details:
I have installed all the dependencies of py27-spyder (and py27-spyder-beta) using MacPorts. I've used spotlight search to try to indentify any alternative builds of numpy, but only see the py27-numpy 1.6.1 installed from macports. (I've also verified that I am able to use numpy and matplotlib functions from the install).
If I then try to install py27-spyder or py27-spyder-beta from MacPorts (using 'sudo port install py27-spyder-beta') it fails like this (full log file attached).
:info:destroot   File "/Library/Python/2.7/site-packages/scipy-0.10.0.dev_20110723-py2.7-macosx-10.7-x86_64.egg/scipy/io/matlab/mio4.py", line 15, in <module>
:info:destroot     from mio_utils import squeeze_element, chars_to_strings
:info:destroot   File "numpy.pxd", line 849, in init scipy.io.matlab.mio_utils (scipy/io/matlab/mio_utils.c:3468)
:info:destroot ValueError: numpy.ufunc has the wrong size, try recompiling
If I download spyder-2.1.1.zip from this site, and install using 'sudo python setup.py install', the install completes, but then it fails to start with the same error:
MZOffice:spyder-2.1.1 martin$ spyder
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/2.7/bin/spyder", line 2, in <module>
from spyderlib import spyder
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/spyderlib/spyder.py", line 60, in <module>
from spyderlib.plugins.inspector import ObjectInspector
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/spyderlib/plugins/inspector.py", line 30, in <module>
from spyderlib.widgets.externalshell.pythonshell import ExtPythonShellWidget
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/spyderlib/widgets/externalshell/pythonshell.py", line 27, in <module>
from spyderlib.widgets.externalshell.namespacebrowser import NamespaceBrowser
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/spyderlib/widgets/externalshell/namespacebrowser.py", line 31, in <module>
from spyderlib.utils.iofuncs import iofunctions
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/spyderlib/utils/iofuncs.py", line 26, in <module>
import scipy.io as spio
File "/Library/Python/2.7/site-packages/scipy-0.10.0.dev_20110723-py2.7-macosx-10.7-x86_64.egg/scipy/io/init.py", line 11, in <module>
from matlab import loadmat, savemat, byteordercodes
File "/Library/Python/2.7/site-packages/scipy-0.10.0.dev_20110723-py2.7-macosx-10.7-x86_64.egg/scipy/io/matlab/init.py", line 11, in <module>
from mio import loadmat, savemat
File "/Library/Python/2.7/site-packages/scipy-0.10.0.dev_20110723-py2.7-macosx-10.7-x86_64.egg/scipy/io/matlab/mio.py", line 15, in <module>
from mio4 import MatFile4Reader, MatFile4Writer
File "/Library/Python/2.7/site-packages/scipy-0.10.0.dev_20110723-py2.7-macosx-10.7-x86_64.egg/scipy/io/matlab/mio4.py", line 15, in <module>
from mio_utils import squeeze_element, chars_to_strings
File "numpy.pxd", line 849, in init scipy.io.matlab.mio_utils (scipy/io/matlab/mio_utils.c:3468)
ValueError: numpy.ufunc has the wrong size, try recompiling
Attachment: log.txt
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=827

From ccordoba12 on 2011-11-08T09:46:33Z
Hi Martin,
I thought you had a problem like that. I'm glad you fixed it quickly. If you need any other help, don't hesitate to open an issue or leave a message in our mailing list.
Cheers,
Carlos
Status: WontFix

From martinzi...@gmail.com on 2011-11-07T10:36:09Z
Sorry -I  found the issue. Somehow there was an old scipy dev build on my system that was interfering (see where the message is actually coming from):
File "/Library/Python/2.7/site-packages/scipy-0.10.0.dev_20110723-py2.7-macosx-10.7-x86_64.egg/scipy/io/matlab/mio4.py", line 15, in <module>
I deleted the egg, uninstalled and reinstalled scipy before rebuilding spyder, and all is now well. This can be closed.

From fhe...@gmail.com on 2011-11-10T05:05:43Z
I think we may add this information somewhere more appropriate and visible? maybe an 'Install issues' section or something?

From pierre.raybaut on 2011-11-10T05:12:37Z
This should be mentioned in SciPy installation notes, not in Spyder's. Not that I don't think it's important to install SciPy in conjunction with Spyder but we can't handle this kind of troubleshooting: we simply don't have the manpower.
Anyway thanks for keeping us informed of this.


text:
CK's changes

Thanks @ConstantineK !

Lies that the test failed!

repo: sqlcollaborative/dbatools


text:
Fixed spelling errors and license terms

Type of Change

[ ] Bug fix (non-breaking change, fixes #)
[ ] New feature (non-breaking change, adds functionality)
[ ] Breaking change (effects multiple commands or functionality)
[ ] Ran manual Pester test and has passed (`.\tests\manual.pester.ps1)
[ ] Pester test is included

Purpose

Approach

Commands to test

Screenshots

Learning

🥚 cellent! Thank you!

authors: gbargsley potatoqualitee


text:
Support for CHARACTER LARGE OBJECT[(p)] and CHAR LARGE OBJECT[(p)]

Adding support for CHARACTER LARGE OBJET[(p)] and CHAR LARGE OBJECT[(p)], both defined on ANSI (1).
Add tests for both and CLOB[(p)].

(1) : https://jakewheat.github.io/sql-overview/sql-2016-foundation-grammar.html#character-large-object-type

Pull Request Test Coverage Report for Build 3246980821

17 of 17 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 85.841%

Totals

Change from base Build 3227007003:
0.02%

Covered Lines:
10537

Relevant Lines:
12275

💛  - Coveralls

authors: AugustoFKL coveralls

repo: sqlparser-rs/sqlparser-rs


text:
Add the Duktape stack trace to the thrown DuktapeException as StackTr…

…aceElements rather than including it in the message string.

This is going to be great. Lots of feedback & I'd like another round once you've addressed this feedback.

authors: swankjesse szurbrigg

repo: square/duktape-android


text:
Add logs

It would be nice if the lib could report the progress in the logs.
Maybe it could be an optional go-log logger provided by the app using the lib.

It's not really clear what we want to log and where. My proposal:

CLI

Log repos start/finished. As we know how many repos are there we can logstarted downloading src-d/sourced-ce
finished downloading src-d/sourced-ce (10/210)

Same for orgs as soon as we add multi org support

Lib

Log when downloader goes to sleep (when we have this feature implemented)
Log token change (when we have multi-token support implemented)
Log start/finish per type for each repository (prs, issues, comments, ...)

We can add more logs but, imo, it will be too verbose. The list above gives enough info to track the progress without spamming too much. And we can extend it later if we see the need for it.

After discussion with @se7entyse7en the scope for this issue:

Log repos start/finished as proposed above
Log start/finish per type for each repository (prs, issues, comments, ...)

Also, investigate how to track progress for big repositories. We already have --log-http flag which kind of solve this problem but most probably we can make it more user-friendly.

authors: carlosms smacker

repo: src-d/metadata-retrieval


text:
Update Block Hasher

Update the hashing functions in crypto.py to reflect on the new fields we added

[ ] Timestamp


text:
Module's data type support

The changes are done in parser.py, where we parse the subtypes until we get a EOF.
Each subtype is passed to the callback for handling, currently only the MemoryCallback support s modules.
There is a possibility to extend the basic ModuleMemoryCallback for different types of modules.

thanks. merging.

authors: danni-m oranagra

repo: sripathikrishnan/redis-rdb-tools

license: mit


text:
Move Base URL in Client to Env

Expected Behavior
Base URL i.e kzilla.xyz to be moved to env instead of being hardcoded.
Current Behavior
Base URL is hardcoded in client under constants.
Steps to Reproduce

Shrink a URL
kzilla.xyz is hardcoded for the short code & analytics domain

#204 fixes this issue in v2

authors: mdfarhaan sm-sami


text:
tests/data/exec_code: Store test data outside of zip

We currently store test zip files, whilst this is useful to have, it is also incredibly difficult to look at exactly what code the unit tests are running.
We should zip these before running the unit tests in a temp directory. Binary files in git isn't fun.

This is moot now following #157

repo: srobo/astoria


text:
Adds support on initial load and manual trigger to load until the pag…

Adds support on initial load and manual trigger to load until the page is full - fixes #125

Can you let me know how you would "manually trigger" the load with this PR?

Hey, this uses the existing 'infinite-scroll-listen-for-event' mechanism. It simply calls my new load() function instead of handler() directly. Basically I'm wrapping handler() in a $interval for the initial load and when the event is triggered. The $interval runs until handler() returns false indicating that that page is full.

Looks like the build failed due to a timeout issue with saucelabs selenium server. Is this something you are interested in merging into your branch? I'm also about to check-in a bug fix against this. $interval only runs once in firefox when the delay argument is not provided.

I'm going to close this pull request for now. I need to make sure it will meet all the test requirements.

repo: sroze/ngInfiniteScroll


text:
SetupTask's "ext" property causes naming conflicts

The SetupTask currently has a property named ext of type NodeExtension.  The name ext is probably a bad idea since Gradle developers will expect ext to be an ExtraPropertiesExtension based on http://www.gradle.org/docs/current/dsl/org.gradle.api.plugins.ExtraPropertiesExtension.html.
Even worse, the standard way of adding a property (or method) to a task is with a statement like task.ext.myProperty = 'myValue', but if a developer of plugin tries to do this, they will get a NullPointerException because ext starts out null.

Thanks for noticing this. Will fix this by using another variable name.

Issue fixed.

authors: srs stevesaliman

repo: srs/gradle-node-plugin


text:
🛑 Keycloak is down

In 5be75f2, Keycloak (https://sso.srueg.ch/health) was down:

HTTP code: 530
Response time: 257 ms

Resolved: Keycloak is back up in 76b5c99 after 1 hour, 6 minutes.

repo: srueg/upptime


text:
Clean the VM

Big spring fall clean !
What needs to be done :

[x]  Merge scripts tools,  varia folders and any other ancillary wrappers that are used in multiple tools into utils
[x] Create launcher folder to store all of the high-level scripts that launch some tool
[ ] Standardize launching scripts so that their name is always the tool name, and they always take in a folder, as well as the minimum absolutely necessary parameters (for SAD, nothing; for diarization, a SAD may be provided); and that they also accept a parameter (--keep-temp)
[x] Create data/temporary folder where all the temporary data will be stored (if --keep-temp asked by the user; otherwise, this folder's contents get emptied after running)
[x] Create repos folder, inside which there will be one folder per repo cloned into the VM (one per each sad, diarizer, etc)
[ ] Inside each tool subfolder (e.g., tools/OpenSAT), there will be a wrapper that specifies the behavior to adopt regarding the files that need to be processed*
[x] Get rid of all names that are confusing
[ ] Separate the docs into what minimally has to be there (how to install, build, uninstall; how to run the test.sh [and test-daylong.sh --- when this one is implemented]) and what will depend on what tools get installed correctly - only the former gets built WITH the VM
[ ] In the test files, incorporate a routine that harvests doc files from within each tool folder (eg. tools/OpenSAT should contain an .rst file) ONLY when the tool passed the test. (note: docs get rebuilt every time the user manually launches a test and only then.)

*notes regarding this intermediate wrapper (from a conversation between Eric and Alex):

The job of this tool-specific wrapper is to conform to "the main API", translating into and out of the tool's specific needs. So if we find WhizzySADTool takes an mp3 file and puts output in /tmp/whizzyTool.xml ... we reformulate our wrapper to accept WAV files (by calling on a general conversion file that lives inside toolbox/, since it may and will be used by other tools) and rewrite output in /vagrant/data/whizzy_tool...RTTM (idem for the xml to rttm conversion). This tool-specific wrapper lives in the folder with the tool, not in toolbox/ because those needs are specific to that tool.
Each tool-specific wrapper will define how to deal with long files and with many files; by and large, we can imagine two possible issues:

tool cannot deal with long files, so they need to be cut up into smaller clips, then each clip gets processed, then the individual rttm's get reconcatenated. Note that Eric already wrote something for this. Note also that this is excellent for models that take local decisions -- i.e. all except diarization like diartk, which should try to label each individual speaker over the whole file. Let us make this the default for now.
tool has massive model, so it would be better to load this only once and then process all the files. It is difficult to imagine a tool that would benefit from being called for each file separately, so let us make this the default for now.

Don't hesitate if you have ideas to improve the way we're dealing with the files hierarchy.
It's now or never !

lots of tools break when they can't find things where they expect. I'm not sure it's fair to require tool creators (some no longer available, or some tools we may not have source code for) to make changes to their code to accomodate new folder names.

Config files normally found in /vagrant have gone missing in the reorganization. More than one tool uses the HTK feature config file (ERROR) [1] in configManager : cFileConfigReader::openInput : cannot open input file '/vagrant/MED_2s_100ms_htk.conf'!
Also .theanorc (which is in the reorganized repository) and also a whole folder of configuration files named https://github.com/srvk/DiViMe/tree/master/conf which exists "outside the VM" for a reason: it makes it easier for nonexperts to change a configuration local to their machine, but then tools in the VM reads the new configuration to work in a different way.
conf is currently mostly for enhancements to the VM (the slurm batch queuing system for example) but I see @MarvinLavechin is using a new subfolder conf/vad. I propose that we preserve conf in the reorganization, and if we want to move forward with changing tool source code to work in new folder layours, we move the 2 or more tools that depend on MED_2s_100ms_htk.conf to get their configs from /vagrant/conf/ instead of just /vagrant, so that at least that ugly filename won't be there making the list of files look ugly :)

lots of tools break when they can't find things where they expect. I'm not sure it's fair to require tool creators (some no longer available, or some tools we may not have source code for) to make changes to their code to accomodate new folder names.

For the past tools, I propose we either fix it ourselves or remove the tools. We are not committed to preserving all tools that are there. The goal is not to preserve the VM as it is now, but rather to build a sensible, well-organized platform that others can build on and use easily. Perhaps the changes we suggested with Marvin were not ideal for this, so we are very open to discussion of how best to do this.

Config files normally found in /vagrant have gone missing in the reorganization. More than one tool uses the HTK feature config file (ERROR) [1] in configManager : cFileConfigReader::openInput : cannot open input file '/vagrant/MED_2s_100ms_htk.conf'!
Also .theanorc (which is in the reorganized repository) and also a whole folder of configuration files named https://github.com/srvk/DiViMe/tree/master/conf which exists "outside the VM" for a reason: it makes it easier for nonexperts to change a configuration local to their machine, but then tools in the VM read the new configurations to work in a different way.
conf is currently mostly for enhancements to the VM (the slurm batch queuing system for example) but I see @MarvinLavechin is using a new subfolder conf/vad. I propose that we preserve conf in the reorganization, and if we want to move forward with changing tool source code to work in new folder layouts, we alter the source of the 2 or more tools (much as this terrifies me) that depend on MED_2s_100ms_htk.conf to get their configs from /vagrant/conf/ instead of just /vagrant, so that at least that ugly MED_2s_100ms_htk.conf filename won't be there making the list of files look ugly :)

I think part of this comments point out a bug I introduced -- sorry about that.
And part is about adding back a folder I did not know about. Of course, we can use it, in which case it would be ideal if there was some documentation explaining what is in there and why, so that in the future people can re-use it.

Super! Moving on... (I've been working from home this morning since waking up a couple hours ago)
I've now made enough changes to the new scripts in launcher/ (and possibly utils/) to get the tests to pass.
This does not mean that they all work in the desired way yet, simply that they WORK. If it's OK to commit all my changes, you could use this as a starting point for "something that works" then make incremental changes to finish making them work with the new reorganized folder paths.
In particular, things that I changed in order to make the tests all pass, that may need more changes to work to fully work in the reorganized way:

Put a copy of Opensmile back in vagrant's home folder (tools that are hard coded to find it there) by hand
Put OpenSAT back in the home folder (it has numerous hard coded dependencies that require it to be there) by hand
put G/ back in the home folder (tools hard code that location) by hand
Refactored and fixed bugs in numerous launcher/ and utils/ scripts relating to pathname confusions we've encountered: /vagrant vs. /home/vagrant and DATADIR being absolute path vs. relative (data vs /vagrant/data)
This includes some cases of scripts that take as an argument a folder name (eg "data") intended to be in /vagrant (/vagrant/data) being actually passed full paths ("/vagrant/data") [ in the eval.sh stack of scripts' use of audio_dir]
LOTS of fixes where more tool names needed to be changed from e.g: tool_sad or tool_diar to toolSad and toolDiar

Things that still need work:

eval.sh sub-scripts still use temp_ref and temp_sys rather than temp/temp_ref and temp/temp_sys (there were too many changes for me to make to get it to work the temp/temp_ref way)
many places in scripts define paths with trailing slashes,  that then get concatenated into bigger pathnames that work fine, but if you print them out the paths look like e.g: /vagrant//data/VanDam-Public/BN32//folder-name - not a real bug :)
G/ folder is back in /home/vagrant, again because tools have hard coded dependencies on it being there
Changes to Vagrantfile to ensure these tools are back where they were -or- a larger effort of changing the tool sources (something I was hoping we could leave fixed) to work with new locations which involves:

putting modified tools in a new branch or release tag or repository
maintaining multiple versions of tool source code, if we wish to support people currently using them in current DiViMe deployments
possibly updating tools' internal documentation
possibly updating system-level documentation

So I'm mostly writing to ask if it's OK to commit my changes to test.sh that "work", and the launcher/ scripts I've modified to work with it, in hopes that development of the reorganized branch can continue with now a way to test tools again, and starting from these "working" ones, then make further refinements to them use new temp folder layout.

Eric and myself discussed having a launcher and utils folders as separate repos versus within the divime folder. We decided for the latter because:

for someone who wants to install a new tool inside VM, this means forking ONE thing and not 2 or 3,
for someone reviewing a pull request, this means reviewing changes in one repo, not 2-3
it'll be easier for tool makers to edit launcher etc. from the host machine rather than only through the VM
all the launch/util scripts are hidden neatly inside folders so the GitHub page for DiViMe home folder still looks clean enough

The only disadvantage is that this makes the divime repo heavier in size, but this does not seem to be an issue given that launchers and utils are all light files.
We also decide to add repos to PATH, which will allow very clean and easy to read code for calling tools: vagrant ssh -c launchMe.sh data
We also decide that launchers will be by default read-only, to avoid accidental editing

[ ] straightening out chaos
That's one box you should check!

one of the far above checkboxes goes away (compile selectively the docs based on tool failures)

good point, that actually takes care of 2 problems - because now the online and local docs are the same. I'm adding a line to bootstraph.sh to build the local docs.
Also, I think the last unchecked box, "Inside each tool subfolder (e.g., tools/OpenSAT), there will be a wrapper that specifies the behavior to adopt regarding the files that need to be processed*" is no longer relevant, right? Since you're systematically having all the tools analyze file by file, so by the same token, this routine should break up long files into subfiles?

authors: MarvinLavechin alecristia riebling

repo: srvk/DiViMe


text:
feat(카테고리별 심부름 페이지 및 카테고리 내비게이션 기능 추가와 개선): #189

요약
카테고리별 심부름 페이지 및 카테고리 내비게이션 기능 추가와 개선하였습니다.
변경 내용

카테고리와 심부름 내역 데이터 타입 파일 분리 및 재사용 구현
심부름 내역 페이지 라우터 경로 "/errand/category/:categoryId"로 변경 및 관련 import 수정
카테고리별 심부름 내역 API 호출을 axios 인스턴스로 변경
카테고리 API 호출 및 아이콘 이미지 매칭, NavItem 컴포넌트로 데이터 전달
useParams 훅 사용하여 선택된 카테고리 UI에 하이라이트 표시
페이지 이동 시 메뉴 자동 닫힘 처리 구현
ErrandItem 컴포넌트에 카테고리별 내역 데이터 props 전달

이슈 번호 또는 링크
#189

고생하셨슴다 오늘 새벽에 굉장히 많은 작업을 하셨네요

authors: ExceptAnyone SSUK-H

repo: ssap-rainbow/SSAP


text:
Why project still 0.XX? Multiplayer and Deterministic Replay?

Hello @sschmid and others,
Why the version is still 0.XX? is there a full roadmap?
And now, i want to developing multiplayer game which implementing Deterministic Replay concept. Is Entitas good enough for it? and why?
Thanks

Hi,
I recently posted sth about the roadmap in the chat:
https://gitter.im/sschmid/Entitas-CSharp?at=58cdae0efe6a638b1add8d63
I'm currently working on a roslyn code generator and @mzaks is about to release Entitas-Lang which both attempt to solve the issues you might have with code generation. I also just updated the build pipeline and the Entitas code base to be deployed as dlls.
I want to have those things in before I consider going 1.0.0 since those changes might have an effect on the public api.
Having said that:

Entitas is ready for production

We used it for multiple different games in different genres over the last 3 years and there are a few games already out in the AppStore made with Entitas. Take a look at the Wiki - #madeWithEntitas
I used Entitas in a synchronous multiplayer game and in a deterministic game where I could replay the game just by providing inputs. It's really easy to achieve this with Entitas.

Is Entitas good enough for it?

In my opinion Entitas it currently one of the best options to build a game with a solid architecture. I'm currently working on a game with hundreds of systems and growing complexity, but it's still a pleasure to work with, and the complexity is manageable very well. We have thousands of unit tests and the game runs very smooth.

and why?

It's fast and optimized
I uses way less memory than Unity
It uses object pools and caching by default to ensure to have almost no allocations
Data Oriented approach, composition over inheritance
Systems that follow the Single Responsibility Principle
It's really easy to write Unity Tests with Entitas, which can be veeery beneficial if you want to create a deterministic game
It has proven to scale well
Me and the great community are happy to help if you have any questions
It's plain fun to work with :D

Hi @sschmid ,
Thanks very much for your explanation.
I will start to explore more.
(y)

authors: leopripos sschmid

repo: sschmid/Entitas-CSharp


text:
fix: extend validation schemas to allow dates across all timezones and all possible tag values

The current schemas for trust data validation neither allow timezones with negative offsets nor tags containing dashes. This fixes both and adds additional tests.
Fix #10

Codecov Report

Merging #15 into master will not change coverage.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##           master      #15   +/-   ##
=======================================
  Coverage   90.06%   90.06%
=======================================
  Files          14       14
  Lines         594      594
=======================================
  Hits          535      535
  Misses         59       59

Impacted Files
Coverage Δ

connaisseur/__main__.py
0.00% <0.00%> (ø)

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 dc9bd8d...4be9713. Read the comment docs.

authors: annekebr codecov-io

repo: sse-secure-systems/connaisseur


text:
Call to undefined function Anik\ElasticApm\Middleware\now()

Uncaught exception 'Error' with message 'Call to undefined function Anik\ElasticApm\Middleware\now()' in /var/www/vendor/anik/elastic-apm-php/src/Middleware/RecordForegroundTransaction.php:87
Raised a PR for this.
Also the error transactions not showing in the Elastic APM.
FYI, Elastic APM is stable now for php

Due to some personal urgencies, I can't actually work on this project and no time soon. If you want to help everyone will appreciate it.

I have modified the changes in the PR. Could you please verify and merge the same. Thanks in advance.

tagged v2.1

authors: biswajit-landmarkgroup ssi-anik

repo: ssi-anik/elastic-apm-php


text:
[GSSoC'23] - [NEW GAME]: SMASHER

A simple yet interesting game where the player has to drag their mouse (which acts like a blade) and slice/smash through the cubes flying around.
@Dharmesh177 Please assign me this issue.

@Dharmesh177 I have the game ready. It's built with HTML, CSS and JS. Could you please assign it to me so that I can make a PR for GSSoC'23?

@Dharmesh177 Could you please assign it to me? I have the game ready and working.

@Dharmesh177 Are you there?

repo: ssitvit/Code-Canvas


text:
[ New Game ] : Added CarGame { GSSOC'23 }

A Fun Car Game.

@panwar8279 Could You Look Into This And Merge The Pr😊 >>And Point Out Issues If Any!

@panwar8279 when will you see this project .

@panwar8279  could you plz checkout this project ???

@panwar8279 Plz merge my PR

@panwar8279 Could you plz merge my PR ??

@panwar8279 Could you plz merge my PR ??

@panwar8279 Could you plz merge my PR ??

repo: ssitvit/Games-and-Go


text:
多图滑动问题

我这是一个商品列表，每一个商品有多个图片，可以预览，代码如下，id是商品的id按理来说是可以分不同的gallery的，现在预览的时候，可以预览到别的商品的图片，0.15.0之前是好使的，看了gallery.js做了一些String()的修改，不知道是不是有影响，麻烦看一下
<div                  v-for="(img,index) in data.goods.imgs"                 :key="'img'+data.goods.id+index"                  class="img-wrapper"              >                 <img                      v-gallery:data.goods.id                     :src="common.handleImgUrl(img)"                      alt="商品图片">             </div>

是这里的问题。gallery.js里面以前没有String()，现在是let group = String(binding.arg) || binding.value，想问为什么要这么改呀？

低级错误，抱歉

v0.15.3 已修复

authors: leeww ssshooter

repo: ssshooter/img-vuer


text:
Use div instead p for the default unstyled element

The default unstyled element in draft is div instead of p. This is a quick-fix that fixes this. It should use the DefaultDraftBlockRenderMap instead (possibly with an option to specify the rendering of block types). Once #15 is done, I'd be willing to add support for it.
https://github.com/facebook/draft-js/blob/master/src/model/immutable/DefaultDraftBlockRenderMap.js#L62
Note: this was tested with Draft.js v0.7.0

Hi @xarg. Thanks for your contribution. The reason we are using
 instead of
 is because "paragraph" is the semantic representation of a normal, un-styled block of text.
Even though the draft editor internally renders un-styled blocks as
...
 at edit time, that does not mean it's the right markup for exporting semantic HTML. Similarly, draft uses foo for italic text whereas we will export foo.
draft-js-export-html is not meant to be a raw dump of draft's rendered html, but rather a tool for exporting editor contents in a way that would fit nicely with web content (such that you might insert into your blog or cms for instance).
I do not believe semantic HTML content should have any
s.

Alternatively, I'm happy to allow you to specify custom tags for each block. In fact, I think that's the right thing to do here, similar to #15. I will create an issue to that effect..

authors: sstur xarg

repo: sstur/draft-js-export-html

license: isc


text:
Add Getting Started section to README

README Update
Please add a Getting Started section to the README file so that folks know how to start with this project.

Adding Getting Started section in README file.

repo: ssummers/website


text:
Support social-auth-app-django >= 3.1.0,<4.0?

social-auth-app-django recently released version 3.1 which contains important improvements, which are:

Updated JSONField.from_db_value signature to support multiple Django versions by accepting just the needed parameters.
Cleanup username when using email as username

(maybe other enhancements are important for other developers...)
it's a good time to bump version

Good spot, thank you.
Will check it soon

Now on pypi: v1.5.0


text:
Fix item collection asset hrefs

Related issues and pull requests

Closes #52

Description
We were being too liberal setting an item's self href, which was leading to invalid item collection asset hrefs.
Checklist

[x] Add tests
[ ] Add docs
[ ] Update CHANGELOG

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.49% :tada:

Comparison is base (5b79fd5) 75.19% compared to head (66fc86d) 75.69%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #53      +/-   ##
==========================================
+ Coverage   75.19%   75.69%   +0.49%
==========================================
  Files          13       13
  Lines         504      506       +2
==========================================
+ Hits          379      383       +4
+ Misses        125      123       -2

Files Changed
Coverage Δ

src/stac_asset/_cli.py
92.00% <ø> (ø)

src/stac_asset/functions.py
83.57% <100.00%> (+1.68%)
:arrow_up:

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

authors: codecov-commenter gadomski

repo: stac-utils/stac-asset


text:
Distance between located person and robot

Hi Team,
do you have a python script enabling the distance calculation (for collision avoidance) between a person (his coordiantes xyz are available) and a robot. What i did is following:

using an example (overview-urdf.py) from your repositoty i m able to calculate the xyz of all the axes

In order to avoid:

interpolation approach for defining new points between all the axes
generating theirs xyz values
identifying the nearest point from the robot points to the person

the goal is to stop the robot when a predefined safety distance is reached between human (at the moment only the position of his hand) and the nearst robot point
regards,

@dadouz Is this issue still up to date?

authors: dadouz jcarpent

repo: stack-of-tasks/pinocchio


text:
Fix buildReducedModel

The parent frame of the geometry objects was copied from the input model. As the frame order is not kept, they were erroneous.
As a side note, I think the frame order could be kept. I won't have time to dig into this.

As a side note, I think the frame order could be kept. I won't have time to dig into this.

Could you add a TODO?

authors: jcarpent jmirabel


text:
Fixes

several tests / improvements

LGTM :)

authors: Maleware maltesander

repo: stackabletech/datenplatform


text:
the preview appears white

Describe the bug

Link to the Bolt URL that caused the error
https://bolt.new/~/sb1-ouapsq
Steps to reproduce
when I ask for any application
Expected behavior
do what I ask
Screen Recording / Screenshot
No response
Platform

OS: [e.g. macOS, Windows, Linux]
Browser: [e.g. Chrome, Safari, Firefox]
Version: [e.g. 91.1]

Additional context
No response

Appreciate the feedback! We are aware of this issue and are tracking it here: #1791. You can also try typing “npm run dev” in the Bolt console to see if that resolves the issue. Also, selectively disable browser extensions, especially ad blockers, to see if that resolves the issue. We appreciate your patience as improvements continue to be made!

authors: Chochipols endocytosis


text:
Configuration not allowing DB connections to work

Describe the bug
Configured the browser with exceptions as requested. POSTman cannot access the API endpoints. Works locally, but not via StackBlitz.
Link to the Bolt URL that caused the error
Look it up
Steps to reproduce
View all of my other tickets LMAO
Expected behavior
The DB to connect via a connection string that works locally and via MongoDB Compass
Screen Recording / Screenshot
No response
Platform
Browser name = Chrome

Additional context
No response

@benspak direct DB connections to traditional SQL DBs and such are not currently supported due to limitations of running entirely in the browser.
Most users are finding success with Firebase for DB, so we made this tutorial: https://x.com/sulco/status/1850937685512478850
I recommend that approach for now!


text:
Loose aeson contraint to <0.10 and -j2 for travis

@jpvillaisaza @jsl could you check it please? this resolves #18 and since new documentation for travis tells us that we have 2 dedicated cores for the container, i added -j2

LGTM
On Friday, July 24, 2015, Juan Paucar notifications@github.com wrote:

@jpvillaisaza https://github.com/jpvillaisaza @jsl
https://github.com/jsl could you check it please? this resolves #18
https://github.com/stackbuilders/twitter-feed/issues/18 and since new
documentation for travis tells us that we have 2 dedicated cores for the
container, i added -j2
You can view, comment on, or merge this pull request online at:
https://github.com/stackbuilders/twitter-feed/pull/19
Commit Summary

Loose aeson contraint to <0.10 resolves #18 & add -j2 for travis

File Changes

M .travis.yml
https://github.com/stackbuilders/twitter-feed/pull/19/files#diff-0
(5)
M twitter-feed.cabal
https://github.com/stackbuilders/twitter-feed/pull/19/files#diff-1
(2)

Patch Links:

https://github.com/stackbuilders/twitter-feed/pull/19.patch
https://github.com/stackbuilders/twitter-feed/pull/19.diff

—
Reply to this email directly or view it on GitHub
https://github.com/stackbuilders/twitter-feed/pull/19.

--
Justin Leitgeb http://justinleitgeb.com
Twitter: @justinleitgeb http://twitter.com/justinleitgeb
Github: @jsl https://github.com/jsl
Co-Founder and CTO, Stack Builders Inc. http://www.stackbuilders.com

@juanpaucar Thanks!

authors: jpvillaisaza jsl juanpaucar

repo: stackbuilders/twitter-feed


text:
Add os_projects role

Add os_projects role
lint: Fix os_projects issues
os_projects: Update for identity_user_info module
os_projects: Remove legacy support for Ansible 2.8.3 without quotas
os_projects: Drop Python 3 support
os_projects: Update README
os_projects: Remove Ansible 2.3 user password workaround

tested and working in a devstack environment

Thanks for testing!

repo: stackhpc/ansible-collection-openstack


text:
Unit tests and debug tools

When these charts work, they are fine. When they don't work, the user is left in a world of hurt, rummaging round in a complex system trying to find clues as to what has gone wrong.
For a production system intended for others to use, these charts should come with a set of unit tests and debug tools that can be run on a cluster to check all the components are present and correct.
A simple library of kubectl commands to look for obvious things would be a useful start. So rather than posting suggestions in a Slack channel, StackHPC can point people at a page of common debug queries they can copy and paste.
These scripts should include kubectl queries to resolve the random Pod names so that they will 'just work' without requiring the user to resolve the names manually.
These will be useful for people trying to port the Helm charts to new platforms, and for system admins trying to verify if their Openstack platform is working correctly.

@DavidFair @meoflynn
Do you have any docs for your deployments on STFC Cloud that you could contribute to the project? Would be much appreciated.

We are trying to make a code base that is portable across all the available clouds.
Our deployment works on the Arcus Openstack system at Cambridge. It sometimes works on the Somerville Openstack system at Edinburgh, but no one knows why.
https://github.com/lsst-uk/somerville-operations/issues/144
Several people have contributed suggestions, including a couple of people from StackHPC, but we haven't managed to identify the cause yet.
We are not experts on Openstack or ClusterAPI. We are developers trying to build our services on top of Kubernetes, so we don't have a lot of time to dedicate to debugging this. It would be really useful to have some unit tests and health diagnostics written Openstack and ClusterAPI experts that we could run on a platform to help diagnose what is going wrong.
Note - the problem is not a fault with the the capi-helm-charts themselves. The assumption is that the underlying cause lies with the configuration of the Openstack platform. The problem is that the capi-helm-charts Helm charts don't provide any feedback about what is wrong.

authors: Zarquan mkjpryor

repo: stackhpc/capi-helm-charts


text:
Building second set of overcloud container images fails

If we build a second set of images using a new tag we come up against a docker overlay storage driver limitation:
ERROR:kolla.image.build.nova-libvirt:Error'd with the following message
ERROR:kolla.image.build.nova-libvirt:link /var/lib/docker/overlay/e1251f91bd1949691006a20cf47c8ae73dbe02d230f1fd4864b37c664907f880/root/var/lib/yum/yumdb/h/6e65f96e8fd137ed
72729a1e39f219905779eb91-hardlink-1.0-19.el7-x86_64/checksum_type /var/lib/docker/overlay/0d9d6d7a3d39471dff211b82d24ffce4f3e756fe9e9464d60cee8a1bb3f243fa/tmproot290834309/
var/lib/yum/yumdb/h/6e65f96e8fd137ed72729a1e39f219905779eb91-hardlink-1.0-19.el7-x86_64/checksum_type: too many links

The current workaround is delete the old set of images. A better solution would be to use another storage driver. I briefly tested overlay2:
(kayobe) [root@seed kayobe]# cat /etc/docker/daemon.json
{
  "storage-driver": "overlay2",
   "storage-opts": [
    "overlay2.override_kernel_check=true"
  ]
}

but there is an issue with the version of docker kolla-ansible installs:
Docker version 1.12.0
When the container images are built with this storage engine, you get spurious file permission errors when attempting to run the containers:
RUNNING HANDLER [common : Initializing toolbox container using normal user] ************************************************************************************************
fatal: [control-0]: FAILED! => {"changed": false, "cmd": ["docker", "exec", "-t", "kolla_toolbox", "ansible", "--version"], "delta": "0:00:00.150262", "end": "2018-09-14 18:21:35.929873", "failed": true, "rc": 1, "start": "2018-09-14 18:21:35.779611", "stderr": "", "stderr_lines": [], "stdout": "Traceback (most recent call last):\r\n File \"/opt/ansible/bin/ansible\", line 43, in <module>\r\n    import ansible.constants as C\r\nImportError: No module named ansible.constants", "stdout_lines": ["Traceback (most recent call last):", "  File \"/opt/ansible/bin/ansible\", line 43, in <module>", " import ansible.constants as C", "ImportError: No module named ansible.constants"]

The solution may be to upgrade docker (which kolla-ansible doesn't actually pin).

I have an upstream kolla ansible patch in progress for installing a more recent Docker: https://review.openstack.org/582612.

authors: jovial markgoddard

repo: stackhpc/sib-kayobe-config


text:
Implement sorting/filtering for new evaluation history endpoints

Please describe the enhancement
TBD
Solution Proposal
TBD
Describe alternatives you've considered
No response
Additional context
No response
Acceptance Criteria
No response

Combined with #3559

repo: stacklok/minder


text:
Add more logging to user/project deletion

Summary
In order to better debug the recent race conditions we've seen in user/project deletion
this ads more logs.
Change Type
Mark the type of change your PR introduces:

[x] Bug fix (resolves an issue without affecting existing features)
[x] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[ ] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Review Checklist:

[x] Reviewed my own code for quality and clarity.
[ ] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[ ] Included tests that validate the fix or feature.
[ ] Checked that related changes are merged.

coverage: 47.088% (+0.02%) from 47.07%
when pulling 43d6b83591db88163da5387a7034430c45cb939e on auth-delete-logging
into 5f6bcbdb2464cac6594bf63741c1b45cf18cd0a8 on main.

authors: JAORMX coveralls


text:
Update aws-sdk-go

The version which we currently have is vulnerable, according to Minder.
Summary
Provide a brief overview of the changes and the issue being addressed.
Explain the rationale and any background necessary for understanding the changes.
List dependencies required by this change, if any.
Fixes #(related issue)
Change Type
Mark the type of change your PR introduces:

[ ] Bug fix (resolves an issue without affecting existing features)
[ ] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[ ] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist:

[ ] Reviewed my own code for quality and clarity.
[ ] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[ ] Included tests that validate the fix or feature.
[ ] Checked that related changes are merged.

coverage: 54.299%. remained the same
when pulling 5fe1bc19ccfb8a5abd35c23f9b42ca50db352edb on update-aws-sdk
into 0c7a14862f5b99dc3771a4d8c64b9a3e526dde49 on main.

authors: coveralls dmjb


text:
Jv mock grpc server should report multiple connections

Description
Currently the mock grpc server only reports the latest connection that it sees for each container. We should have tests were multiple connections are seen per container. We should also make sure that when we expect to see one connection reported for a container, that there is only one connection for that container and not multiple connections. This PR updates the mock grpc server image to one that reports multiple connections per container and makes changes to the integration tests so that they get an array of connections rather than just a string representing one connection. See the corresponding PR in stackrox/stackrox https://github.com/stackrox/stackrox/pull/6308
Checklist

[ ] Investigated and inspected CI test results

Testing Performed
Ran integration tests locally.

Having more than one connection reported for a test-case is absolutely something we want. However, with PR's approach, I am not sure that the validation of the result is going to be reliable. Also, it does not solve our flackyness issues with variable execution times, AFAIUI.
How about importing the grpc mock "inside" the test environment instead and dropping the database ?
With this approach:

we would not rely on an external mock grpc server image
we could implement scenarios based on expected events instead of relying on hypothetically timed steps
since we would have scenarios, one test could cover much more functionality
the individual tests could execute much faster
the GRPC mock is written in Golang, so integrating it with the existing testing logic is hopefully "reinventing the wheel".

What do you think @JoukoVirtanen ?

Having more than one connection reported for a test-case is absolutely something we want. However, with PR's approach, I am not sure that the validation of the result is going to be reliable. Also, it does not solve our flackyness issues with variable execution times, AFAIUI.
How about importing the grpc mock "inside" the test environment instead and dropping the database ?
With this approach:

we would not rely on an external mock grpc server image
we could implement scenarios based on expected events instead of relying on hypothetically timed steps
since we would have scenarios, one test could cover much more functionality
the individual tests could execute much faster
the GRPC mock is written in Golang, so integrating it with the existing testing logic is hopefully "reinventing the wheel".

What do you think @JoukoVirtanen ?

I agree with incorporating the mock grpc server directly into the integration tests, but I think that could be done in another PR.

authors: JoukoVirtanen ovalenti

repo: stackrox/collector


text:
Sannmælast um að nota eingögnu redirect fyrir authentication

https://github.com/stadlar/IST-FUT-FMTH/wiki/Payment-Initiation-Flows

Samþykkt

repo: stadlar/IST-FUT-FMTH


text:
Clickhouse keeper is broken in bitnami chart

see:
https://github.com/bitnami/charts/issues/15935
Current fix is to switch to zookeper.  The issue has been languishing for quite a while, but just noted that they are increasing the priority.  To use zookeeper set your values to clickhouse.keeper.enable = false and clickhouse.zookeeper.enabled = true.
alternatively in values.yaml:
clickhouse:
  keeper:
    enabled: false
  zookeeper:
    enabled: true

Do you know if this made ClickHouse entirely unusable with CH Keeper? I'll have to treat the switch of the default values with a little more caution if it's possible the existing CH Keeper holds any data. As far as I'm aware there's no migration path from CH Keeper to Zookeeper.

With the default config of shards=2, and replicas=3 I saw that databases never were created, so I went to create them manually since they were listed as not created by prisma here, when attempting to create the tables manually I saw that the DDL operations would hang at 49%.  I spent way too much time digging through clickhouse logs and the error messages eventually led me back to the mentioned bug report.   All that is to say, that I went about eliminating errors until I was able to have a working instance.

I have been messing with the bitnami clickhouse chart, and it looks like the issue is that it create a set of keeper replicas for every shard.

Good job finding out all of this. I merged #20 to at least provide a working clickhouse deployment by default. At least there's a documented migration path from zookeeper to keeper for when keeper is fixed in Bitnami's chart. Thanks a lot for the contributions!

authors: echozio mleklund

repo: stafftastic/jitsu-chart


text:
XS✔ ◾ remove params from task

❌ Add a description.

@AsfaMumtaz Image is available for testing. docker pull stakater/workshop-exercise:SNAPSHOT-PR-93-77613811

authors: AsfaMumtaz stakater-user

repo: stakater/workshop-exercise


text:
🛑 STAKR.space site is down

In 03bb775, STAKR.space site (https://stakr.space) was down:

HTTP code: 0
Response time: 0 ms

Resolved: STAKR.space site is back up in 5b46bed after 28 minutes.

repo: stakrspace/upptime


text:
🛑 Proxima/DNS Server is down

In 108ac60, Proxima/DNS Server (http://proxima01.its-telekom.eu/livewatch.php) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Proxima/DNS Server is back up in 33bc193.

repo: stamateas/upptime


text:
2.22.0 release notes

Summary:
pulling discussion of 2.22 release notes into its own issue  from here: https://github.com/stan-dev/cmdstan/issues/797#issuecomment-576204588
Description:
Proposed release notes summarizing Stan changes don't mention stanc3 compiler -
need to put this at the top
Current proposal:
Features:

validate_dims in stan::io::var_context vas made a virtual function which allows its implementation for JSON data which is needed to accepts arrays where any dimension is size 0
replaced Eigen vectors of strings with std::vectorstd::string
replaced stan::math::domain_error with throw_domain_error
added const noexcept accessors to the stepsize adaptation class which allows developers to query the adaptation parameters in contexts where it's natural to have a const sampler (logging, serialization, ...)

Current Version:
v2.21.0

accepts arrays where any dimension is size 0

Wait, does this mean I can do
parameters {
  vector[0] notUsedInThisModel;
}

??

See https://github.com/stan-dev/cmdstan/issues/775 for details on that.

authors: jpritikin mitzimorris rok-cesnovar

repo: stan-dev/cmdstan


text:
Jenkins Job for Testing Against Newest Downstream Libraries

Description
From some comments @bgoodri made on Discourse, it could be nice for us and downstream maintainers if we ran a jenkins job on dev->master that used the newest versions of Eigen, Boost, etc. These would be set to warnings and not actual errors. Once we figure out if it's us or them that's goofing up we can report to maintainers as appropriate.
This could pull either their dev or most recent release.
I'm pretty sure we also lag behind the latest version for most things, so we can set these tests to run when the current release version is greater than the one we use. Then we can use these tests to also know if it's fine to update the dependencies.
Layout
For the Jenkins job

Download newest versions of Eigen, boost etc. to libraries folder
Connect those properly to libraries file
Run tests (all or some or ???)
Have a report (or something legible) generated in the output

Dunno if we should test each individually or all at once or whatever.
Expected Output
We could be very fancy and have Jenkins post an issue or something, but a simple alt is just to have the test failures available via the Jenkins console.
If people think this is useful and good I can probably spend a bit of time working on it.

Thanks---that sounds like a good idea.  We'll likely run into parse errors.  Testing individually will be most informative, but it may be too high a burden.

Is this issue still relevant with the build with parameters thing we have now?

Which thing is that?

Ah I misunderstood this issue. I thought this was an issue on how to test cmdstan with specific branches on Math with newer libraries, nevermind. This one is trying to actually automatically use the newest library. sorry.

authors: SteveBronder bob-carpenter rok-cesnovar

repo: stan-dev/math


text:
Issue 1010 - Replace hand-coded math with standard library c++11 functions

Summary
This pull closes out issue #1010 by replacing the math functions with their std:: equivalents.
All functions, except for ldexp had existing implementations for fwd and rev, so I added those (as well as their respective tests).
Once Bob's ad test framework (#1262) is merged, I'll update those tests.
Tests
Autodiff tests for ldexp, all others unchanged as existing behaviour should not change
Side Effects
N/A
Checklist

[x] Math issue #1010

[x] Copyright holder: Andrew Johnson
The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
- Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
- Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

[x] the basic tests are passing

unit tests pass (to run, use: ./runTests.py test/unit)
header checks pass, (make test-headers)
docs build, (make doxygen)
code passes the built in C++ standards checks (make cpplint)

[x] the code is written in idiomatic C++ and changes are documented in the doxygen

[x] the new changes are tested

I don't think it's a big deal either way as I don't think most users even know hypot() is there. I can't see it ever being a big chunk of computation (unlike, say lgamma, which dominates a lot of density calculations like the Dirichlet and gamma).  I can't imagine it's part of our performance regression tests anywhere.
I also wouldn't worry too much about reversion down the line.  We may come up with some principled decision on precision vs. speed, at which point the implementation of hypot() could go either way.

On Aug 27, 2019, at 7:57 PM, Andrew Johnson notifications@github.com wrote:
@andrjohns commented on this pull request.
In stan/math/prim/scal/fun/hypot.hpp:

@@ -23,8 +21,8 @@ namespace math {
*/
template <typename T1, typename T2>
inline return_type_t<T1, T2> hypot(const T1& x, const T2& y) {

using std::sqrt;
return sqrt(square(x) + square(y));

using std::hypot;
return hypot(x, y);

Is there a situation where you see enough usage of hypot to be worth an optimization effort?
Mainly because it would be introducing a performance regression (in terms of speed, not precision) if we replaced sqrt(square(a) + square(b)) with hypot(a, b). I'm not sure whether the speed cost would outweigh the precision benefits or whether we'd just end up having to revert it down the line
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Word! I'll mark my comment as resolved

Works for me!

#1262 was merged! Is this waiting for anymore review?

The question is probably only if @andrjohns is going to redo the tests with the new AD testing framework from Bob. I think it would be less work to do it here than creating a new separate PR just for that. We should use that everywhere we can anyways.

I agree about the testing framework, I'll re-work those over the weekend

Any idea where the test is hanging?  If not, could you show a version that worked and what changed in the one that doesn't?

Looks like it had something to do with template ambiguity, since adding enable_if_all_arithmetic to the prim definition got rid of the problem

@SteveBronder this is ready for another look. I updated the prim functions with forwarding, but from the discussion in #1344 it looks like forwarding might not always be needed. Let me know if I should change that back

Also, I needed to add std::decay to enable_if_arithmetic otherwise the templates weren't picking it up

@SteveBronder this is ready for another look. I updated the prim functions with forwarding, but from the discussion in #1344 it looks like forwarding might not always be needed. Let me know if I should change that back

Apologies for the delay here, yes after doing stuff on godbolt plain old data inputs do not have a benefit from forwarding etc. Dan Lemire just had a good blog post that showed using plain old copies is better for integer types. Feels like his results would carry over to other primitive types. These functions will always use primitive types right? Would you mind changing them back? If you are busy this week I can do that since it's my goof that led to you making the change.

Yes, we've had the policy in place that primitives should be passed by value wherever possible.
On a related note, const isn't useful for primitive arguments, as they are passed by value, so the API behavior doesn't change with "const int" vs. "int".

On Sep 24, 2019, at 12:05 PM, Steve Bronder notifications@github.com wrote:
@SteveBronder this is ready for another look. I updated the prim functions with forwarding, but from the discussion in #1344 it looks like forwarding might not always be needed. Let me know if I should change that back
Apologies for the delay here, yes after doing stuff on godbolt plain old data inputs do not have a benefit from forwarding etc. Dan Lemire just had a good blog post that showed using plain old copies is better for integer types. Feels like his results would carry over to other primitive types. These functions will always use primitive types right? Would you mind changing them back? If you are busy this week I can do that since it's my goof that led to you making the change.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

On Sep 24, 2019, at 2:23 PM, Rok Češnovar notifications@github.com wrote:
Doesn't const on a pass by value prevent that you modify the arguments value inside the function?

Sort of.  But you can always cast away const inside the body.
The bigger argument to not require references is that you can pass rvalues.  If you have foo(double& x), you can't call foo(2 + 3).

It has no effect in terms of modification in the caller function, but it does inside the function.

Right.
Lots of discussion of this on stackoverflow.  I like the first answer to the big one:

https://stackoverflow.com/questions/46292490/is-it-better-to-remove-const-in-front-of-primitive-types-used-as-function-pa/46292715

which is sort of what this one says

https://stackoverflow.com/questions/16033751/c-const-modifier-with-primitive-types

And also some discussion on isocpp (no idea what status that has):
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-in
Overall, it's a minor point.

Its bad practice if you do it. But people do.

Why is it bad practice to modify an argument variable if it's a primitive?  That seems overly prescriptive to me, like requiring every function to have a single return statement.
The alternative would be to copy it.  I don't know the cost there---it might get compiled away since modifying the argument variable doesn't do anything to the caller.
What the stackoverflow comments recommend is having the API not be const but the definition be const.  I don't even know if that's legal in C++.

authors: SteveBronder andrjohns bob-carpenter rok-cesnovar


text:
Spreadshirt links on Shop page are dead

Both mc-stan.spreadshirt.com and mc-stan.spreadshirt.co.uk are dead links on https://mc-stan.org/shop/.
I also could not find Stan at all on the Spreadshirt website to let me update the links on that page via a pull request, so perhaps we can no longer infer in style?

They seem to be working once again

authors: BrandonEdwards WardBrian


text:
Bug: real fees arent relevant to config setup

fc.conf
    hcParams = {
      feeBaseMsat = 0

      feeProportionalMillionths = 15000 // fee charged per transferred satoshi in millionths of a satoshi (100 = 0.01%)

      cltvDeltaBlocks = 144 // will be set in ChannelUpdate message, SHOULD have the same cltvDeltaBlocks as `expiry-delta-blocks` in Eclair config

      channelCapacityMsat = 5500000000 // offered capacity for hosted channels // 0.1 btc

      htlcMinimumMsat = 50000

      maxAcceptedHtlcs = 10

      isResizable = true // Can client initiate channel resizing on the fly, sticky feature (can not be changed for HC once it is established)
    }

does not work as intended and leads to sub 0.5% fees instead of 1.5% fee.

True story @NCrashed:

We could change fees for the channel only after overriding its state.
What didn't help:
Using eclair's updaterelayfee
Manually suspending and removing channel from host DB. It appeared as suspended again with the same high fee as at the beginning.

repo: standardsats/plugin-fiat-channels


text:
Filter parsing - can't have multiple != conditions on same field in filter

Retina's filter validation marks multiple conditions on the same protocol.field as "duplicate pattern". This mistakenly marks patterns like "tcp.port != 80 and tcp.port != 100" as invalid filters.
Checking for duplicate or incompatible patterns may still be valuable, so this would ideally change/correct how fq_pattern.has_duplicate_fields() is calculated.

Fixed by multi-subscription

repo: stanford-esrg/retina


text:
Fix tests referring to an obsolete API

Which is gone now

Pull Request Test Coverage Report for Build 3291

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 66.257%

Totals

Change from base Build 3287:
0%

Covered Lines:
6497

Relevant Lines:
9227

💛  - Coveralls

authors: coveralls gcampax

repo: stanford-oval/almond-cloud


text:
IP added to the set call

IP was added to the set call in order to pass users' localization data correctly.

Thanks @mbrucki

repo: stape-io/mixpanel-tag


text:
[FIXED JENKINS-27256] Dispatcher for getX(long) model object methods

See JENKINS-27256.
Added dispatcher for getX(long) style model methods. Already tested manually but will add a functional test in Jenkins core test harness (yeah, should have done that first etc etc).
@reviewbybees

:+1:

:-1:
"l" (ell) as a variable name shouldn't be used.
return l can be read as return ell or return one and its not obvious which it is and is hard to spot accidental typos.

Are we happy now James? ffs

:+1: happy chappy

https://github.com/stapler/stapler/blob/master/src/site/resources/reference.html#L160 needs to be updated.

authors: daniel-beck jglick jtnord tfennelly

repo: stapler/stapler


text:
Do not check git tags in prepush

Bug Report
Steps
$ gp
husky > npm run -s prepush (node v8.11.3)

[11:22:15] Requiring external module ts-node/register
[11:22:24] Using gulpfile ~/devel/stardust-ui-react/gulpfile.ts
[11:22:24] Starting 'git:prepush'...
[11:22:24] Finished 'git:prepush' after 19 ms

prepush checks tags. The check was necessary to keep integrity of tags after moving from semantic-ui/react. It is hopefully no longer necessary, remove the step to save up to 10s with every push

We do not have an agreement that we can remove this, see #1103 for details.

repo: stardust-ui/react


text:
fix(content): fixing the type of the content prop in all components

This PR introduces the correct typings in the props' interface as well as in the propTypes in all components regarding the content property. For this purpose two different interfaces and commonPropTypes definition are introduced:
1. The content is used as a shorthand
export interface ContentShorthandComponentProps {
  /** Shorthand for primary content. */
  content?: ShorthandValue
}

export const contentShorthandComponentPropsTypes = {
  content: customPropTypes.itemShorthand,
}

2. The content is used as a ReactNode
export interface ContentNodeComponentProps {
  /** Shorthand for primary content. */
  content?: React.ReactNode
}

export const contentNodeComponentPropsTypes = {
  content: customPropTypes.contentShorthand,
}

In addition, the customPropTypes.itemShorthand was changed in the following manner:
Before
export const itemShorthand = every([
  disallow(['children']),
  PropTypes.oneOfType([
    PropTypes.node,
    PropTypes.object,
    PropTypes.arrayOf(PropTypes.oneOfType([PropTypes.node, PropTypes.object])),
  ]),
])

After
export const itemShorthand = every([
  disallow(['children']),
  PropTypes.oneOfType([
    PropTypes.node,
    PropTypes.object,
  ]),
])

With this change, it corresponds to the TS definition ShorthandValue:
export type ShorthandValue = React.ReactNode | Props

It will be awesome to have a similar generic for UIComponentProps, but I don't have a good idea there.

Thanks @layershifter this is actually a great idea about the propTypes. Will add this functionality and will try to think about something similar for the props' interfaces.

authors: layershifter mnajdova


text:
Fixes and tests clean up

What this PR does:
Which issue(s) this PR fixes:
Fixes to accept username and password instead of token, so the driver ll automatically generate/refresh token.
Fixes and test cases clean up based on integration testing JSON API server on local.
Checklist

[X] Changes manually tested
[ ] Automated Tests added/updated
[ ] Documentation added/updated
[ ] CLA Signed: DataStax CLA

Thanks @vkarpov15!

repo: stargate/stargate-mongoose


text:
dse version upgraded to 6.8.29

What this PR does:

Upgrades DSE version to 6.8.29

Checklist

[ ] Changes manually tested
[x] Automated Tests added/updated
[ ] Documentation added/updated
[x] CLA Signed: DataStax CLA

Due to #2204 (upgrade to 6.8.28( merging there are some conflicts here.
But one other thing is that when merging to main (Stargate v2) there is at least one additional references to C*/DSE version(s):

apis/pom.xml has "default" settings for profiles
gv2-quarkus-common/src/test/java/io/stargate/sgv2/common/testresource/StargateTestResource.java has reference to C*4 version (4.0.4 for now)

and although these are probably not critical (only used by ITs) we do want to keep them mostly in-sync too.

4 version (4.0.4 for now)

Done @tatu-at-datastax please review

authors: tatu-at-datastax versaurabh

repo: stargate/stargate


text:
无法正常启动程序

设备: MacBook Pro 2021, M1 Max
操作系统: macOS Sonoma 14.0 Beta 7
相似情况: #1
复现步骤：

从 Releases 下载 arm64 / universal 版本安装包
拖拽进 Applications
使用 xattr -r -d com.apple.quarantine /Applications/YesPlayMusic.app 移除隔离属性
从启动台或访达启动程序
程序报错，弹窗

点击确定后，程序未退出，但没有窗口显示，macOS 顶部状态栏的控件可以正常点击，点击 Toggle Developer Tools 无响应

我这边没有M芯片的电脑咧。你先试试官方的0.4.7版本是否正常？第3步是M芯片安装软件后的必要步骤吗？

第三步是的，官方版本可以正常运行

第三步是的，官方版本可以正常运行

可能是因为我电脑不是M芯片的，所以打包时不会下载arm相关的依赖？建议你自己打包一下吧。。

同样的报错，M2，macOS14.1

我也碰到这个报错了

同样的报错，M2，macOS14.1 亲测用Node16自己打包就可以正常使用了

打包的安装包可以分享下吗？谢谢！

我也碰到这个报错了

因为我自己电脑是intel芯片的，打包出来的程序M芯片用不了。。可以尝试自己打包，或者发邮件给MamboJiang，让他发一下他打包好的程序哦


text:
bucc fly fails when using a custom ATC certificate

I spent some time trying to add a custom certificate to the concourse web app. My CPI is vSphere and I'm using a certificate from Let's Encrypt. I got close, but ended up with one issue.
I added the certificate to my vars.yml file with
 atc_ssl:
   ca: ...
   certificate: ...
   private_key: ...

I also added the intermediate certificate with concourse_ca_certs. Its pretty cool that bucc sees the atc_ssl cert in vars.yml and doesn't calculate a new one for state/creds.yml. Once everything was up, the certificate was successfully applied to the web worker and I could login. However, there was a problem.
Everything in bucc test worked except for bucc fly. bucc fly fails because the certificate is not trusted and the CA is not calculated with my changes. I dug into the code a bit and see that the ca_cert() function ignores all the configuration in the vars.yml file. It only calculates CA certs from state\creds.yml - and none of my configuration changes are in that file.
So, finally, my question - is this a problem in bucc that should be fixed somehow, or am I doing something wrong? One idea I had was to change the implementation of bucc fly so that it will look for the atc_ssl:ca cert in either state/creds.yml or vars.yml - but I'm not sure if that's the correct approach or not.

i have a workaround for now
add the following line bosh int ${vars_file} --path /concourse_ca_certs >> $ca_cert_file &> /dev/null
on https://github.com/starkandwayne/bucc/blob/master/bin/bucc#L158
please let me know if this worked for you

I like the idea of this patch, but it didn't work - the pipe to /dev/null means that the certificate is not added to the temp file. I changed the patch to the following and it worked:
if bosh int ${vars_file} --path /concourse_ca_certs &> /dev/null; then
  bosh int ${vars_file} --path /concourse_ca_certs >> $ca_cert_file
fi

This does run the bosh interpolate twice, but apparently there is no option for providing a default value in the event that a path doesn't exist or an "ignore missing path" option. So I don't see another way around it.

i have figured out a better and way cleaner way.
try to replace it with get_var concourse_ca_certs >> ca_cert_file

This works!

thanks for your help the fix is already in the development branch.
and will make a release next week

authors: jeffgbutler ramonskie

repo: starkandwayne/bucc


text:
Larger vnum slots needed

Diego is at 0.14xx.0 or something crazy high.  We need to bump the size of each vnum slot to 10,000 (at least) to accommodate.  Make sure three of these fit in a BIGINT and write a migration (v2 schema!)

BIGINT is 9.223372036854775808 × 10^18, which is enough for 3x 10^6 (100,000) vnum components.  BONUS

repo: starkandwayne/genesis-index


text:
type inferrence regression between 1.0.0 and 1.1.0-alpha0

Bug Report
Cairo version: 1.1.0-alpha0

Current behavior:
I was running the quaireaux test suite (make test). When using Cairo version 1.0.0, it passed successfully. After switching to 1.1.0-alpha0, I encountered the following error:
~/projects/cairo/target/release/cairo-test .
error: Type annotations needed. Failed to infer ?5
 --> merkle_tree.cairo:59:46
                    if current_node.into() < (*proof_element).into() {
                                             ^*********************^

Error: failed to compile: .

It's stemming from here. Seems the compiler can no longer infer it should compare u256 that were into()-ed from felt252?
Expected behavior:
I was expecting this test suite to run successfully using v1.1.0-alpha0 as it did before with v1.0.0.
Steps to reproduce:

make sure you're running cairo 1.0.0
clone the quaireaux repo
run make test in the project
switch to cairo 1.1.0-alpha0
run make test again, observe failure

this is caused by expansion of the corelib - this shouldn't work.
if current_node.into() < (*proof_element).into()
previously ("by chance") there was only a single relevant into function mapping to the same type - now there are more - so you need to help the compiler to know what is the actual type.

Got it, thanks.

authors: milancermak orizi

repo: starkware-libs/cairo


text:
Update account contract signature.

This change is

crates/cairo-lang-starknet/test_data/account.cairo line 68 at r2 (raw file):
Previously, liorgold2 wrote…
Shouldn't it be span?

It's a result of deserialization, I'm not sure if there is an advantage in limiting what the user can do with it.


text:
fix(storage): remove option from event_commitment and transaction_commitment

fix(storage): make n_transactions and n_events non optional
fix(storage): remove option from event_commitment and transaction_commitment

This change is

crates/starknet_client/src/reader/objects/block.rs line 278 at r1 (raw file):

                // In some older starknet versions, the transaction and event commitments are not
                // available from the feeder gateway. In such cases, we return None for these
                // fields.

This means we must leave the Option, no?
Code quote:
                // In some older starknet versions, the transaction and event commitments are not
                // available from the feeder gateway. In such cases, we return None for these
                // fields.

authors: ShahakShama dan-starkware

repo: starkware-libs/papyrus


text:
test(starknet_client): add tests for a 0.13.2 block

test(starknet_client): add tests for a 0.13.2 block
fix(mempool): fix add-tx method by updating the queue according to input state (#58)
feat(mempool): impl mempool state (#59)
test(mempool): add tests for commit block method (#61)
test(mempool): add commit block test different leader scenario (#62)
feat(mempool): remove addresses of reverted transactions from queue in commit block method (#60)
test(mempool): open commit block tests (#74)
fix: add missing features to dependencies serde and hyper
refactor(mempool_infra): expose public structs and functions to shorten use paths
test(mempool): rename get_txs test to be more specific (#72)
test(mempool): refactor MempoolState to have Partial and Full states (#80)
test(mempool): refactor test_add_tx_with_duplicate_tx to use mempool state (#82)
feat(mempool): replenishing queue in get_txs (#88)
test(mempool): refactor test_tip_priority_over_tx_hash to use mempool state (#81)
test(mempool): refactor test_add_tx_with_duplicate_tx to check only pool state (#104)
chore(consensus): reuse db and prevent InsufficientPeers error (#64)

chore(consensus): reuse DB

chore(config): add short consensus delay to give time for network peering

chore(mempool_infra): deps hyper and serde to use workspace versions and remove http1 feature
fix: conflict resolution
Signed-off-by: Dori Medini dori@starkware.co
test(mempool): implement default for MempoolState FullState (#102)
feat(mempool): get txs return requested txs after replenishing queue (#91)
test(mempool): get txs replenishes queue only between chunks (#95)
feat: add functionality to use remote mempool client/server
refactor: committer create tree test

This change is

#133  👈
main-v0.13.2

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @AvivYossef-starkware and the rest of your teammates on  Graphite

repo: starkware-libs/sequencer


text:
fix(useTransferToL1/2): use promise instead of contract event

Description of the Changes
Contract events are sometimes not dispatched - until this will be investigated and resolved, use promise as the indication for tx completed.
Checklist

[ ] Changes have been done against master branch, and PR does not conflict
[ ] New unit / functional tests have been added (whenever applicable)
[ ] Test are passing in local environment
[ ] Docs have been updated
[ ] PR title is follow the Conventional Commits convention: <type>[optional scope]: <description>, e.g: fix: prevent racing of requests

This change is

:tada: This PR is included in version 1.5.1-dev.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.6.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

repo: starkware-libs/starkgate-frontend