temperature sensor demo question

I think it may be better to use ESP-OPEN-RTOS. for base
it has more sensor support
but what type of temp sensor this demo is supported?

Currently the demo just sends a random number between 0 and 100 I believe. It doesnt actually use a sensor.
The LED demo uses the built in LED of most ESPs

Exactly. I did not want to mess with any external libraries or in any other way complicate examples. Temperature sensor example was supposed to show how to handle values that are updated on their own, how to declare and use characteristics.
Although I might add real DHT11 implementation sometime later.

Here you go guys! I've updated temperature_sensor example with real DHT11 integration code plus it now also exposes humidity information (because why not). Enjoy!

I have error “can not read data from sensor” error in bloc “B” (DHT11). On ESP8266_RTOS_SDK sensor work good. Am I need to use resistor?

That is probably because you've specified incorrect GPIO pin number. Pin numberss might be different from Espressif SDK (myself had to do a couple of trial and error attempts before settling down correct one).

I test nodemcu v3. Pin №4 (D2). Led example work on this pin.

Here is how I tested: I opened NodeMCU pinout
, set SENSOR_PIN=4 in Makefile and connect DHT11 data output to NodeMCU's D2 (GPIO4). Although this method did not work for me for combination GPIO16 and D0.

That is strange because this is exactly the set up that worked for me. Could you provide your wiring schematics.

Not sure what kind of break out you've got, but on mine (which looks exactly like this) data pin is in center while on your layout it's on the left. Are you sure you've connected everything properly?

Ok, the image of DHT is very blury, but it looks like your pin layout is correct. What I've noticed is: my breakout has embedded pull-up resistor (along with capacitor), so maybe you need to change line 60 to enable pull-up on ESP8266 side:
gpio_set_pullup(SENSOR_PIN, true, false);

I use this module. This work with ESP8266_RTOS_SDK...

Well, I'm out of ideas. I suggest you ask help in esp-open-rtos project. Try starting with their simple dht_sensor example and make it work.

I noticed that there is a 10kom resistor on my module. Could this be the reason? Do you use a resistor?

I found mistake!
In dht.c first argument "dht_sensor_type_t":
bool dht_read_float_data(dht_sensor_type_t sensor_type, uint8_t pin, float *humidity, float *temperature)
{
int16_t i_humidity, i_temp;
if (dht_read_data(sensor_type, pin, &i_humidity, &i_temp)) {
    *humidity = (float)i_humidity / 10;
    *temperature = (float)i_temp / 10;
    return true;
}
return false;

}
but you use first argument "SENSOR_PIN":
bool success = dht_read_float_data(
SENSOR_PIN, DHT_TYPE_DHT11,
&humidity_value, &temperature_value
);

Oh! Thank you for reporting that. Fixed.

I see another strange behavior
It shows temperature and humidity, but continuously I get error
HomeKit: [Client 5] Error reading data (code 128)
It looks like it ask too many times for getting data
after some time it crashed

faronov, your not alone, I'm getting that error as well

Pushed change to force disconnect client in case reading from socket results in an error.

As I see it fail after it shows IP
I increase vtask time , but it didn't help
>>> mdns_recv: pbuf too big
>>> HomeKit: Got new client connection: 4
>>> HomeKit: [Client 4] Pair Setup Step 1/3
>>> HomeKit: [Client 4] Pair Setup Step 2/3
>>> HomeKit: [Client 4] Pair Setup Step 3/3
>>> HomeKit: Added pairing with 1F4D9525-9246-430F-B309-538363BA9646
>>> HomeKit: Configuring mDNS
>>> HomeKit: [Client 4] Successfully paired
>>> HomeKit: [Client 4] Closing client connection
>>> HomeKit: Got new client connection: 4
>>> HomeKit: [Client 4] Pair Verify Step 1/2
>>> HomeKit: [Client 4] Pair Verify Step 2/2
>>> HomeKit: [Client 4] Found pairing with 1F4D9525-9246-430F-B309-538363BA9646
>>> HomeKit: [Client 4] Verification successful, secure session established
>>> HomeKit: [Client 4] Get Accessories
>>> HomeKit: [Client 4] Update Characteristics
>>> HomeKit: [Client 4] Update Characteristics
>>> HomeKit: Got new client connection: 5
>>> HomeKit: [Client 5] Pair Verify Step 1/2
>>> HomeKit: [Client 5] Pair Verify Step 2/2
>>> HomeKit: [Client 5] Found pairing with 1F4D9525-9246-430F-B309-538363BA9646
>>> HomeKit: [Client 5] Verification successful, secure session established
>>> HomeKit: [Client 5] Get Accessories
>>> HomeKit: [Client 4] Get Characteristics
>>> HomeKit: [Client 4] Update Characteristics
Temperature sensor identify
>>> HomeKit: [Client 4] Get Characteristics
>>> HomeKit: [Client 4] Update Characteristics
Temperature sensor identify
>>> HomeKit: [Client 4] Get Characteristics
>>> HomeKit: [Client 5] Update Characteristics
>>> HomeKit: Got new client connection: 6
>>> HomeKit: [Client 6] Pair Verify Step 1/2
>>> HomeKit: [Client 6] Pair Verify Step 2/2
>>> HomeKit: [Client 6] Found pairing with 1F4D9525-9246-430F-B309-538363BA9646
>>> HomeKit: [Client 6] Verification successful, secure session established
>>> HomeKit: [Client 6] Get Accessories
ip:<IP_ADDRESS>,mask:<IP_ADDRESS>,gw:<IP_ADDRESS>
!!! HomeKit: [Client 5] Error reading data (code 104)
!!! HomeKit: [Client 5] Error reading data (code 104)

Next run
same result
dhcp client start...
ip:<IP_ADDRESS>,mask:<IP_ADDRESS>,gw:<IP_ADDRESS>
>>> HomeKit: Got IP, starting
>>> HomeKit: Configuring mDNS
>>> HomeKit: Got new client connection: 4
>>> HomeKit: [Client 4] Pair Setup Step 1/3
>>> HomeKit: [Client 4] Pair Setup Step 2/3
>>> HomeKit: [Client 4] Pair Setup Step 3/3
>>> HomeKit: Added pairing with 1F4D9525-9246-430F-B309-538363BA9646
>>> HomeKit: Configuring mDNS
>>> HomeKit: [Client 4] Successfully paired
>>> HomeKit: [Client 4] Closing client connection
>>> HomeKit: Got new client connection: 4
>>> HomeKit: [Client 4] Pair Verify Step 1/2
>>> HomeKit: [Client 4] Pair Verify Step 2/2
>>> HomeKit: [Client 4] Found pairing with 1F4D9525-9246-430F-B309-538363BA9646
>>> HomeKit: [Client 4] Verification successful, secure session established
>>> HomeKit: [Client 4] Get Accessories
>>> HomeKit: [Client 4] Update Characteristics
>>> HomeKit: [Client 4] Update Characteristics
>>> HomeKit: Got new client connection: 5
>>> HomeKit: [Client 5] Pair Verify Step 1/2
>>> HomeKit: [Client 5] Pair Verify Step 2/2
>>> HomeKit: [Client 5] Found pairing with 1F4D9525-9246-430F-B309-538363BA9646
>>> HomeKit: [Client 5] Verification successful, secure session established
>>> HomeKit: [Client 5] Get Accessories
>>> HomeKit: [Client 4] Get Characteristics
>>> HomeKit: [Client 4] Update Characteristics
Temperature sensor identify
>>> HomeKit: [Client 4] Get Characteristics
>>> HomeKit: [Client 4] Update Characteristics
Temperature sensor identify
>>> HomeKit: [Client 4] Get Characteristics
>>> HomeKit: [Client 5] Update Characteristics
>>> HomeKit: Got new client connection: 6
>>> HomeKit: [Client 6] Pair Verify Step 1/2
>>> HomeKit: [Client 6] Pair Verify Step 2/2
>>> HomeKit: [Client 6] Found pairing with 1F4D9525-9246-430F-B309-538363BA9646
>>> HomeKit: [Client 6] Verification successful, secure session established
>>> HomeKit: [Client 6] Get Accessories
>>> HomeKit: [Client 5] Get Characteristics
>>> HomeKit: [Client 5] Update Characteristics
>>> HomeKit: [Client 5] Update Characteristics
ip:<IP_ADDRESS>,mask:<IP_ADDRESS>,gw:<IP_ADDRESS>
Couldnt read data from sensor

could this work with DHT22 sensor?

Yes, the library that is used there supports both DHT11 and DHT22, you just need to pass it which version of sensor you have.

@faronov Have you solved your problem? I have the same problem, except the separate pairing switch, other devices cannot be paired。


{,} gives too much spacing

(Not sure whether it is related to https://github.com/cdelker/ziamath/issues/30)
After the latest commits $x=1{,}5$ gives too much space around a comma (comma is meant as a decimal separator and it used to give less spacing).

278c67f


"contributing guidelines coding standards" url broken

[ ] Have you checked the guidelines in our Contributing document?

Description
when checking the contributing guidelines at https://github.com/locutusjs/locutus/blob/master/CONTRIBUTING.md , if you click on the "updated coding standards." link, you're greeted with this 404 error:

Thanks for reporting, this was fixed in the meantime https://github.com/locutusjs/locutus/blob/main/CONTRIBUTING.md


The image need to rebulid

In GitLab by @wknet123 on Sep 5, 2017, 17:00

In GitLab by @luotian-github on Nov 8, 2019, 07:35
Confirm repair

In GitLab by @sokril on Nov 8, 2019, 08:08
closed

In GitLab by @sokril on Nov 8, 2019, 08:09
assigned to @wknet123


Update installer to install latest version of .NET Core 3.1

Title says it all.

We need to update to 3.1.13 https://dotnet.microsoft.com/download/dotnet/3.1


Auro radio Installation docs are incorrect

Describe the bug
The installation instructions here are incorrect. The instructions reference auro-checkbox under the sections for "Define dependency in project component", "Install bundled assets from CDN", and "Testing".
To Reproduce
Steps to reproduce the behavior:

Go to auro radio docs
Scroll to sections referenced above in the description
Note that the instructions reference  and  instead of  and

Expected behavior
I expected the correct cdn assets to be listed for auro-radio.
Screenshots

I filed this under the wrong repo, so I moved it to the auro-radio repo: https://github.com/AlaskaAirlines/auro-radio/issues/2


Feature/color route segments

Added a overlay which reflects the quality of the route based on either:

cost
altitude
incline
Partially adresses https://github.com/nrenner/brouter-web/issues/19 and could be extended by using https://github.com/hgoebl/Leaflet.MultiOptionsPolyline to overlay the road types.

I didn't looked at the code yet and wanted to give it a try, looks also good! I'm not sure if cost should be the default one (over incline), but 3 visualizations are complementary.
The coloration doesn't go away when you refresh route (eg. if you switch between profile, you end up with the old colored profile and the new pink profile, until the route is fully calculated). Is that a bug or a feature?

@bagage this is just the way components get notified when a total reloading of the track is done. Like the elevation chart.
But you're right the cost function currently might be most useful for me because I want to see where the algorithm shows the most costly paths. I changed it to be incline first.
Next thing would be to maybe switch to https://github.com/hgoebl/Leaflet.MultiOptionsPolyline and get this to a separate tab to the right similar to:

Next thing would be to maybe switch to https://github.com/hgoebl/Leaflet.MultiOptionsPolyline and get this to a separate tab to the right similar to

There was the idea to have a separate tab for BRouter-web configuration (for instance for #229). Maybe this would be a good place to put the options for the path overlay color as well?

@bagage can we switch to gulp-uglify-es to support ecmascript 6?

Totally that would be cool! Is there any reason not to @nrenner?

I opened a new issue for the ES 6 question: #249.
Great to see many pull requests! Will try to look through them in the next days.

Nice! I do have some comments, but will open a follow-up issue after merging.
Just a minor wish right now: can we move the button just above the route opacity slider (by moving the .addTo(map))? It's less important than the drawToolbar and fits thematically, as both change the route appearance.

Thanks!

A follow-up issue: #262


only single line, how to make it support mult line

you can try delete the setInputType(InputType.TYPE_TEXT_FLAG_NO_SUGGESTIONS) in MentionEditText init()


Issue #160

when a user scans the same barcode more than once, combine the line items in the page (increment the qty)
when a user scans the same barcode one more time, prompt them to enter a quantity (in a dialog box)
There is some problem with js and Capybara. I see that all test with js have pending The JS doesn't appear to be executing in this correctly

i see rspec error Expected pending 'TODO - This spec fails in January because Year-to-date... need to use TimeCop or something' to fail. No error was raised.   ./spec/features/dashboard_spec.rb:32
, but it's not related with this pull request.

Awesome! Thank you so much for this!

Nice work!


rye fails to find existing version of package

Steps to Reproduce
# create temp folder
mkdir temp
cd temp

# new project
rye init --py 3.12.3
rye sync

# add requests 2.32.3
rye add requests==2.32.3
# error: Failed to run uv compile   × No solution found when resolving dependencies:
#   ╰─▶ Because there is no version of requests==2.32.3 and you require
#       requests==2.32.3, we can conclude that the requirements are
#       unsatisfiable.
# . uv exited with status: exit code: 1

Expected Result
It adds requests version 2.32.3. The version is available here: https://pypi.org/project/requests/2.32.3/
Actual Result
error: Failed to run uv compile   × No solution found when resolving dependencies:
  ╰─▶ Because there is no version of requests==2.32.3 and you require
      requests==2.32.3, we can conclude that the requirements are
      unsatisfiable.
. uv exited with status: exit code: 1

Version Info
rye 0.37.0
commit: 0.37.0 (09b67c469 2024-07-20)
platform: windows (x86_64)
self-python<EMAIL_ADDRESS>symlink support: true
uv enabled: true
Stacktrace
No response

Is the issue still there on your machine?
Was trying to reproduce and was not successful with that. Tried both Powershell and Cmd...

Yes, I've reproduced it just now:

Trying to think of how this could be possible -- works as expected for me:
~/workspace on  main [!+?] via 🐍 v3.10.14
❯ cd temp
~/workspace/temp on  main [!+?]
❯ rye init
success: Initialized project in /Users/crmarsh/workspace/temp/.
  Run `rye sync` to get started
~/workspace/temp on  main [!+?] is 📦 v0.1.0 via 🐍 v3.12.3
❯ rye sync
Initializing new virtualenv in /Users/crmarsh/workspace/temp/.venv
Python version<EMAIL_ADDRESS>Generating production lockfile: /Users/crmarsh/workspace/temp/requirements.lock
Generating dev lockfile: /Users/crmarsh/workspace/temp/requirements-dev.lock
Installing dependencies
Resolved 1 package in 1ms
Building temp @ file:///Users/crmarsh/workspace/temp
   Built temp @ file:///Users/crmarsh/workspace/temp
Prepared 1 package in 416ms
Installed 1 package in 0.90ms
 + temp==0.1.0 (from file:///Users/crmarsh/workspace/temp)
Done!
~/workspace/temp on  main [!+?] is 📦 v0.1.0 via 🐍 v3.12.3
❯ rye add requests==2.32.3
Added requests==2.32.3 as regular dependency
Reusing already existing virtualenv
Generating production lockfile: /Users/crmarsh/workspace/temp/requirements.lock
Generating dev lockfile: /Users/crmarsh/workspace/temp/requirements-dev.lock
Installing dependencies
Resolved 6 packages in 2ms
   Built temp @ file:///Users/crmarsh/workspace/temp
Prepared 6 packages in 153ms
Uninstalled 1 package in 0.47ms
Installed 6 packages in 2ms
 + certifi==2024.7.4
 + charset-normalizer==3.3.2
 + idna==3.7
 + requests==2.32.3
 - temp==0.1.0 (from file:///Users/crmarsh/workspace/temp)
 + temp==0.1.0 (from file:///Users/crmarsh/workspace/temp)
 + urllib3==2.2.2
Done!

Can you include the output of running with --verbose? You must not be able to access the index for some reason (or you have an alternate index configured and don't realize it).

Here's the output when I add --verbose to each command:
PS D:\Programming\krita-scripting> # create temp folder
>> mkdir temp
>> cd temp
>>

    Directory: D:\Programming\krita-scripting

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2024-07-28     01:27                temp

PS D:\Programming\krita-scripting\temp> rye init --py 3.12.3 --verbose
success: Initialized project in D:\Programming\krita-scripting\temp\.
  Run `rye sync` to get started
PS D:\Programming\krita-scripting\temp> rye sync --verbose
Python version already downloaded. Skipping.
Initializing new virtualenv in D:\Programming\krita-scripting\temp\.venv
Python version<EMAIL_ADDRESS>Using Python 3.12.3 interpreter at<EMAIL_ADDRESS>Creating virtualenv at: .venv
Activate with: .venv\Scripts\activate
Generating production lockfile: D:\Programming\krita-scripting\temp\requirements.lock
Resolved 1 package in 25ms
-e file:.
    # via -r C:/Users/James/AppData/Local/Temp/.tmpaFZoz7
Generating dev lockfile: D:\Programming\krita-scripting\temp\requirements-dev.lock
Resolved 1 package in 3ms
-e file:.
    # via -r C:/Users/James/AppData/Local/Temp/.tmp29ZvsK
Installing dependencies
DEBUG uv 0.2.27
DEBUG Searching for Python interpreter in system path or `py` launcher
DEBUG Found cpython 3.12.3 at `D:\Programming\krita-scripting\temp\.venv\Scripts\python.exe` (active virtual environment)
DEBUG Using Python 3.12.3 environment at .venv\Scripts\python.exe
DEBUG Acquired lock for `.venv`
DEBUG Using request timeout of 30s
DEBUG Found PEP 621 metadata for D:\Programming\krita-scripting\temp in `pyproject.toml` (temp)
DEBUG Solving with installed Python version: 3.12.3
DEBUG Adding direct dependency: temp*
DEBUG Searching for a compatible version of temp @ file:///D:/Programming/krita-scripting/temp (*)
DEBUG Acquired lock for `\\?\C:\Users\James\AppData\Local\uv\cache\built-wheels-v3\editable\b0baee121f5fccb0`
DEBUG Preparing metadata for: temp @ file:///D:/Programming/krita-scripting/temp
DEBUG No static `PKG-INFO` available for: temp @ file:///D:/Programming/krita-scripting/temp (MissingPkgInfo)
DEBUG Found static `pyproject.toml` for: temp @ file:///D:/Programming/krita-scripting/temp
DEBUG No workspace root found, using project root
DEBUG Tried 1 versions: temp 1
DEBUG Split specific environment resolution took 0.009s
Resolved 1 package in 12ms
DEBUG Identified uncached requirement: temp @ file:///D:/Programming/krita-scripting/temp
DEBUG Acquired lock for `\\?\C:\Users\James\AppData\Local\uv\cache\built-wheels-v3\editable\b0baee121f5fccb0`
DEBUG Building: temp @ file:///D:/Programming/krita-scripting/temp
INFO Ignoring empty directory
DEBUG Solving with installed Python version: 3.12.3
DEBUG Adding direct dependency: hatchling*
DEBUG No cache entry for: https://download.pytorch.org/whl/cu121/hatchling/
DEBUG Found fresh response for: https://pypi.org/simple/hatchling/
DEBUG Searching for a compatible version of hatchling (*)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/0c/8b/90e80904fdc24ce33f6fc6f35ebd2232fe731a8528a22008458cf197bc4d/hatchling-1.25.0-py3-none-any.whl.metadata
DEBUG Selecting: hatchling==1.25.0 [compatible] (hatchling-1.25.0-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.25.0: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.25.0: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.25.0: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.25.0: trove-classifiers*
DEBUG No cache entry for: https://download.pytorch.org/whl/cu121/packaging/
DEBUG No cache entry for: https://download.pytorch.org/whl/cu121/pathspec/
DEBUG No cache entry for: https://download.pytorch.org/whl/cu121/pluggy/
DEBUG No cache entry for: https://download.pytorch.org/whl/cu121/trove-classifiers/
DEBUG Searching for a compatible version of packaging (>=23.2)
DEBUG No compatible version found for: packaging
DEBUG Searching for a compatible version of hatchling (<1.25.0 | >1.25.0)
DEBUG Selecting: hatchling==1.24.2 [compatible] (hatchling-1.24.2-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/5f/20/b890241570ac3ba6508febab3104eeb1acd7ffba1bd3447190f56151f1bc/hatchling-1.24.2-py3-none-any.whl.metadata
DEBUG Adding transitive dependency for hatchling==1.24.2: packaging>=23.2
DEBUG Found fresh response for: https://pypi.org/simple/pathspec/
DEBUG Adding transitive dependency for hatchling==1.24.2: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.2: pluggy>=1.0.0
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/cc/20/ff623b09d963f88bfde16306a54e12ee5ea43e9b597108672ff3a408aad6/pathspec-0.12.1-py3-none-any.whl.metadata
DEBUG Adding transitive dependency for hatchling==1.24.2: trove-classifiers*
DEBUG Searching for a compatible version of hatchling (<1.24.2 | >1.24.2, <1.25.0 | >1.25.0)
DEBUG Selecting: hatchling==1.24.1 [compatible] (hatchling-1.24.1-py3-none-any.whl)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/e5/d1/9e933f6ed4276c448806968a97d42ad4ed3e8d8722541fba5f75571d9add/hatchling-1.24.1-py3-none-any.whl.metadata
DEBUG Adding transitive dependency for hatchling==1.24.1: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.24.1: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.1: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.24.1: trove-classifiers*
DEBUG Searching for a compatible version of hatchling (<1.24.1 | >1.24.1, <1.24.2 | >1.24.2, <1.25.0 | >1.25.0)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/36/47/8266533720febfb0640ba1c93ab2edb83be4091dcfb107595cc8bbbb99ef/hatchling-1.24.0-py3-none-any.whl.metadata
DEBUG Selecting: hatchling==1.24.0 [compatible] (hatchling-1.24.0-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.24.0: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.24.0: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.0: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.24.0: trove-classifiers*
DEBUG Searching for a compatible version of hatchling (<1.24.0 | >1.24.0, <1.24.1 | >1.24.1, <1.24.2 | >1.24.2, <1.25.0 | >1.25.0)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/b8/f3/565163cc52fe6c330ad59b17204701a85e0440af6b5463dc0613a93c4212/hatchling-1.23.0-py3-none-any.whl.metadata
DEBUG Selecting: hatchling==1.23.0 [compatible] (hatchling-1.23.0-py3-none-any.whl)
DEBUG Prefetching 5 hatchling versions
DEBUG Adding transitive dependency for hatchling==1.23.0: packaging>=23.2
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/52/6a/5e6a176ac6be3d3c36dded0b0d346f7059f83268716cc88f707b16f711f5/hatchling-1.22.5-py3-none-any.whl.metadata
DEBUG Adding transitive dependency for hatchling==1.23.0: pathspec>=0.10.1
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/49/63/2d56d6356f9f8b906aa68335cbf5b1b54c69873a2e271eda2ddba319c1ae/hatchling-1.22.4-py3-none-any.whl.metadata
DEBUG Adding transitive dependency for hatchling==1.23.0: pluggy>=1.0.0
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/2d/31/b4ffda996d1e21bb7096fd377b0437f4925351c2f60dbe9563e83705744c/hatchling-1.22.3-py3-none-any.whl.metadata
DEBUG Adding transitive dependency for hatchling==1.23.0: trove-classifiers*
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/7d/a4/c69d252d72d61591c2f9354f30fe39927256ec0615f77d16d419a7b98d28/hatchling-1.22.2-py3-none-any.whl.metadata
DEBUG Searching for a compatible version of hatchling (<1.23.0 | >1.23.0, <1.24.0 | >1.24.0, <1.24.1 | >1.24.1, <1.24.2 | >1.24.2, <1.25.0 | >1.25.0)
DEBUG Selecting: hatchling==1.22.5 [compatible] (hatchling-1.22.5-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.22.5: packaging>=21.3
DEBUG Adding transitive dependency for hatchling==1.22.5: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.22.5: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.22.5: trove-classifiers*
DEBUG Searching for a compatible version of packaging (>=21.3, <23.2)
DEBUG Found fresh response for: https://download.pytorch.org/whl/packaging-22.0-py3-none-any.whl#sha256=957e2148ba0e1a3b282772e791ef1d8083648bc131c8ab0c1feba110ce1146c3
DEBUG Selecting: packaging==22.0 [compatible] (packaging-22.0-py3-none-any.whl)
DEBUG Searching for a compatible version of pathspec (>=0.10.1)
DEBUG Selecting: pathspec==0.12.1 [compatible] (pathspec-0.12.1-py3-none-any.whl)
DEBUG Found fresh response for: https://pypi.org/simple/pluggy/
DEBUG Searching for a compatible version of pluggy (>=1.0.0)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/88/5f/e351af9a41f866ac3f1fac4ca0613908d9a41741cfcf2228f4ad853b697d/pluggy-1.5.0-py3-none-any.whl.metadata
DEBUG Selecting: pluggy==1.5.0 [compatible] (pluggy-1.5.0-py3-none-any.whl)
DEBUG Found fresh response for: https://pypi.org/simple/trove-classifiers/
DEBUG Searching for a compatible version of trove-classifiers (*)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/0f/b0/09794439a62a7dc18bffdbf145aaf50297fd994890b11da27a13e376b947/trove_classifiers-2024.7.2-py3-none-any.whl.metadata
DEBUG Selecting: trove-classifiers==2024.7.2 [compatible] (trove_classifiers-2024.7.2-py3-none-any.whl)
DEBUG Tried 11 versions: hatchling 6, packaging 2, pathspec 1, pluggy 1, trove-classifiers 1
DEBUG Split specific environment resolution took 1.934s
DEBUG Installing in hatchling==1.22.5, packaging==22.0, pathspec==0.12.1, pluggy==1.5.0, trove-classifiers==2024.7.2 in \\?\C:\Users\James\AppData\Local\uv\cache\builds-v0\.tmp7e39IF
DEBUG Requirement already cached: hatchling==1.22.5
DEBUG Requirement already cached: packaging==22.0
DEBUG Requirement already cached: pathspec==0.12.1
DEBUG Requirement already cached: pluggy==1.5.0
DEBUG Requirement already cached: trove-classifiers==2024.7.2
DEBUG Installing build requirements: hatchling==1.22.5, packaging==22.0, pathspec==0.12.1, pluggy==1.5.0, trove-classifiers==2024.7.2
DEBUG Calling `hatchling.build.get_requires_for_build_editable()`
DEBUG Installing extra requirements for build backend
DEBUG Solving with installed Python version: 3.12.3
DEBUG Adding direct dependency: hatchling*
DEBUG Adding direct dependency: editables>=0.3, <1.dev0
DEBUG Searching for a compatible version of hatchling (*)
DEBUG No cache entry for: https://download.pytorch.org/whl/cu121/editables/
DEBUG Selecting: hatchling==1.25.0 [compatible] (hatchling-1.25.0-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.25.0: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.25.0: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.25.0: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.25.0: trove-classifiers*
DEBUG Found fresh response for: https://pypi.org/simple/editables/
DEBUG Searching for a compatible version of editables (>=0.3, <1.dev0)
DEBUG Found fresh response for: https://files.pythonhosted.org/packages/6b/be/0f2f4a5e8adc114a02b63d92bf8edbfa24db6fc602fca83c885af2479e0e/editables-0.5-py3-none-any.whl.metadata
DEBUG Selecting: editables==0.5 [compatible] (editables-0.5-py3-none-any.whl)
DEBUG Searching for a compatible version of packaging (>=23.2)
DEBUG No compatible version found for: packaging
DEBUG Searching for a compatible version of hatchling (<1.25.0 | >1.25.0)
DEBUG Selecting: hatchling==1.24.2 [compatible] (hatchling-1.24.2-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.24.2: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.24.2: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.2: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.24.2: trove-classifiers*
DEBUG Searching for a compatible version of hatchling (<1.24.2 | >1.24.2, <1.25.0 | >1.25.0)
DEBUG Selecting: hatchling==1.24.1 [compatible] (hatchling-1.24.1-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.24.1: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.24.1: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.1: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.24.1: trove-classifiers*
DEBUG Searching for a compatible version of hatchling (<1.24.1 | >1.24.1, <1.24.2 | >1.24.2, <1.25.0 | >1.25.0)
DEBUG Selecting: hatchling==1.24.0 [compatible] (hatchling-1.24.0-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.24.0: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.24.0: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.24.0: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.24.0: trove-classifiers*
DEBUG Searching for a compatible version of hatchling (<1.24.0 | >1.24.0, <1.24.1 | >1.24.1, <1.24.2 | >1.24.2, <1.25.0 | >1.25.0)
DEBUG Selecting: hatchling==1.23.0 [compatible] (hatchling-1.23.0-py3-none-any.whl)
DEBUG Prefetching 5 hatchling versions
DEBUG Adding transitive dependency for hatchling==1.23.0: packaging>=23.2
DEBUG Adding transitive dependency for hatchling==1.23.0: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.23.0: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.23.0: trove-classifiers*
DEBUG Searching for a compatible version of hatchling (<1.23.0 | >1.23.0, <1.24.0 | >1.24.0, <1.24.1 | >1.24.1, <1.24.2 | >1.24.2, <1.25.0 | >1.25.0)
DEBUG Selecting: hatchling==1.22.5 [compatible] (hatchling-1.22.5-py3-none-any.whl)
DEBUG Adding transitive dependency for hatchling==1.22.5: packaging>=21.3
DEBUG Adding transitive dependency for hatchling==1.22.5: pathspec>=0.10.1
DEBUG Adding transitive dependency for hatchling==1.22.5: pluggy>=1.0.0
DEBUG Adding transitive dependency for hatchling==1.22.5: trove-classifiers*
DEBUG Searching for a compatible version of editables (>=0.3, <1.dev0)
DEBUG Selecting: editables==0.5 [compatible] (editables-0.5-py3-none-any.whl)
DEBUG Searching for a compatible version of packaging (>=21.3, <23.2)
DEBUG Selecting: packaging==22.0 [compatible] (packaging-22.0-py3-none-any.whl)
DEBUG Searching for a compatible version of pathspec (>=0.10.1)
DEBUG Selecting: pathspec==0.12.1 [compatible] (pathspec-0.12.1-py3-none-any.whl)
DEBUG Searching for a compatible version of pluggy (>=1.0.0)
DEBUG Selecting: pluggy==1.5.0 [compatible] (pluggy-1.5.0-py3-none-any.whl)
DEBUG Searching for a compatible version of trove-classifiers (*)
DEBUG Selecting: trove-classifiers==2024.7.2 [compatible] (trove_classifiers-2024.7.2-py3-none-any.whl)
DEBUG Tried 13 versions: hatchling 6, editables 2, packaging 2, pathspec 1, pluggy 1, trove-classifiers 1
DEBUG Split specific environment resolution took 0.844s
DEBUG Installing in editables==0.5, hatchling==1.22.5, packaging==22.0, pathspec==0.12.1, pluggy==1.5.0, trove-classifiers==2024.7.2 in \\?\C:\Users\James\AppData\Local\uv\cache\builds-v0\.tmp7e39IF
DEBUG Requirement already cached: editables==0.5
DEBUG Requirement already installed: hatchling==1.22.5
DEBUG Requirement already installed: packaging==22.0
DEBUG Requirement already installed: pathspec==0.12.1
DEBUG Requirement already installed: pluggy==1.5.0
DEBUG Requirement already installed: trove-classifiers==2024.7.2
DEBUG Installing build requirement: editables==0.5
DEBUG Calling `hatchling.build.build_editable("\\\\?\\C:\\Users\\James\\AppData\\Local\\uv\\cache\\built-wheels-v3\\editable\\b0baee121f5fccb0\\EZqDRRA9zgActQoyEo6vt\\.tmpwg1oGA", {}, None)`
DEBUG Finished building: temp @ file:///D:/Programming/krita-scripting/temp
Prepared 1 package in 3.08s
warning: Failed to hardlink files; falling back to full copy. This may lead to degraded performance. If this is intentional, use `--link-mode=copy` to suppress this warning.

hint: If the cache and target directories are on different filesystems, hardlinking may not be supported.
Installed 1 package in 3ms
 + temp==0.1.0 (from file:///D:/Programming/krita-scripting/temp)
Done!
PS D:\Programming\krita-scripting\temp> rye add requests==2.32.3 --verbose
error: Failed to run uv compile   × No solution found when resolving dependencies:
  ╰─▶ Because there is no version of requests==2.32.3 and you require
      requests==2.32.3, we can conclude that the requirements are
      unsatisfiable.
. uv exited with status: exit code: 1
PS D:\Programming\krita-scripting\temp>

Not sure what an alternate index is. Here's my rye config in case it has anything weird:
[behavior]
use-uv = true
global-python = true

[default]
toolchain =<EMAIL_ADDRESS>
[[sources]]
name = "pytorch"
url = "https://download.pytorch.org/whl/cu121"

It looks like you're using the PyTorch index, but that version of request doesn't exist on that index: https://download.pytorch.org/whl/requests/. You can use 2.28.1 instead, or try to add an additional index.

Is it possible to keep the pytorch index, but have rye prefer the requests package on pypi instead?

You can set the UV_INDEX_STRATEGY=unsafe-best-match environment variable, e.g.:
UV_INDEX_STRATEGY=unsafe-best-match rye add requests==2.32.

Docs here: https://github.com/astral-sh/uv/blob/main/PIP_COMPATIBILITY.md#packages-that-exist-on-multiple-indexes


Is it possible to rebind the text selection key?

Steps to reproduce the problem:

Try to select parts of the text in mitmproxy on a mac with a windows keyboard
Find out the selection override key is Fn
Key does not exist on keyboard but is on laptop keyboard

Any other comments? What have you tried so far?
At the time I am kind of just reaching over to the mac itself to hit the fn key, with 10.12 I can't even use karabiner to do some rebind action as it is broken with the new version of osx. So it would be great if I can use a cmd option / config file to make mitmproxy to react to a different key for text selection
System information
mackbook pro mid 2014, osx 10.12.4
windows keyboard, with control and command swapped in OS if that changes anything.

You can disable mouse support, which should at least give you back normal text selection.
But the Fn key is not used by mitmproxy, but comes directly from your Terminal.app (or are you using iTerm2?).
I'm using iTerm2 and can select text by holding down the Alt key. Unfortunately I can't remember where or what I configured in iTerm2.

cool thanks, iterm2 did it thanks!


When using docker images, ggcaller does not work well

We heard that there were problems with installation via conda, so we used docker as recommended. However, downloading the test dataset and using the commands listed in the documents did not work. Also, no error information is output, so I have no idea what is causing the problem. Please advise.
It appears that docker images is installed correctly as --help works.
Commands used.
cd test && docker run --rm -it -v $(pwd):/workdir samhorsfield96/ggcaller:latest ggcaller --refs pneumo_CL_group2.txt

Thanks for the reply.
I have tried two operating systems, ubuntu 20.04 and ubuntu 22.04 on wsl2.
There was no output at all.
The pneumo_CL_group2.txt is the same as the one in the test folder on github. So it only contained the file name.
I personally presume that it is a permissions issue, but changing the workdir permissions by chmod 777 had no effect. Also, building the docker image on my PC did not work.

Hi, I would suggest trying two things:

Try regenerating the input.txt file for the test sequence using the command documented here, this will use absolute file paths which may be causing the issue.
If that does not work, install ggCaller from source, documented here

Please let me know whether you still run into trouble.

Building coloured compacted DBG...
Generating graph stop codon index...
Mapping contigs to graph...
Downloading databases...
Traceback (most recent call last):

There could be a number of reasons for this, and unfortunately I have not been able to replicate this issue. To circumvent the download, you can navigate to the models directory where you installed ggCaller from source, and run wget https://ftp.ebi.ac.uk/pub/databases/pp_dbs/ggCallerdb.tar.bz2 to download the model database. You should then be able to run ggCaller as before.

Test data worked fine! Thank you very much for your very courteous response!


[BugFix] fix incorrect memory metrics of jemalloc

What type of PR is this：

[x] BugFix
[ ] Feature
[ ] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Which issues of this PR fixes ：

Fixes #12349
Problem Summary(Required) ：

fix a stupid bug that would cause the value of jemalloc_retained_bytes incorrect.
update the statistics cached by mallctl before get them, otherwise we won't get the latest results

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

starrocks_be_unittest succeeded.

run starrocks_admit_test

run starrocks_admit_test

@mergify backport branch-2.4

run starrocks_admit_test

starrocks_be_unittest succeeded.

run starrocks_admit_test


Fixed #29403 -- Fixed storing too large values in PyLibMCCache.

This issue was previosly reported as a test failure five years ago, in issue #19914. Sadly the approach taken to fix it then was simply to paper over the exception in the test case, instead of handling it in the cache backend. This meant that for actual users of the code the issue remained even though the test no longer failed. This PR removes the papering-over and fixes the bug.
https://code.djangoproject.com/ticket/29403

I have pushed an updated version hopefully addressing the review comments (thanks @charettes and @pope1ni).

@edmorley, as the author of 674e3fe13e5156344bfafbea59018b8837eb3044, do you have any comments on this?
I noticed there are no test faiures if the new self._cache.delete(key) is removed. Probably a test for that should be added.

Sorry for the delayed reply.

Sadly the approach taken to fix it then was simply to paper over the exception in the test case, instead of handling it in the cache backend.

The tooBig exception is only supported as of pylibmc 1.5.2, which wasn't released until March 2017 - 4 months after 674e3fe landed.
I'm not sure this fix is the right approach on it's own. The pylibmc backend already has different behaviour from the memcached backend, in that it raises exceptions rather than failing silently.
This should probably be merged into #8681.

Though note I no longer use the pylibmc backend at all, since I've given up with memcached entirely and now use Redis via django-redis. I would strongly recommend people at least try it out compared to any memcached solution. (Which reminds me, it would be great to highlight Redis options in the Django docs... I'll file a ticket/open a PR when I get a chance.)

Closing due to inactivity.


Omni for Windows Terminal!

Omni for Windows Terminal
Hello my name is Davi, and I came to present my proposal for an Omni theme.

I converted the entire color palette from Omni to Windows Terminal, and as seen from the images, they were perfectly good!

I wait for your answer and thanks for the chance to contribute! Any suggestions, teaching or improvement just let me know!

Hey Davi, thanks for your PR!
This repository is a template that we created for new applications.
It contains all the files that the repositories on the Omni organization must-have, like License, Issue templates, and others.
Soon, we will be adding more theme applications, and I recommend you create your own repository using this template, so we can make the process as smooth as possible 💜

Hey Davi, thanks for your PR!
This repository is a template that we created for new applications.
It contains all the files that the repositories on the Omni organization must-have, like License, Issue templates, and others.
Soon, we will be adding more theme applications, and I recommend you create your own repository using this template, so we can make the process as smooth as possible 💜


[bug] How to define Scroll Options

Describe the bug
I am running into difficulty when trying to define the autoscroll options. I've tried to provide scroll options as documented here https://github.com/SortableJS/Sortable/blob/master/plugins/AutoScroll/README.md,  but they do not seem to work. I am attaching the scroll options as props directly to the ReactSortable component. I've even tried scroll: false and autoscroll is still active. On the flipside, onSpill works with no issues.
How do I properly specify the scroll options? Am I missing something?
To Reproduce
Steps to reproduce the behavior:

Run any of the examples or use this sandbox: https://codesandbox.io/s/floral-snowflake-zubw8
Set scroll: false
Try to drag an item to the bottom of the screen, it will still scroll

Expected behavior
The page window should not scrollable
Information
Versions:
react-sortable = ^2.0.11
react = ^16.8.6
Additional context
https://codesandbox.io/s/floral-snowflake-zubw8
You can toggle the scroll prop from true or false and when you drag any item to the bottom of the screen, it will still scroll:

Whatever you're missing, I'm missing too.
You should post this on the sortablejs repo. scroll=false I believe should work.

@waynevanson Thanks for the reply! I have created the issue on the sortablejs repo: https://github.com/SortableJS/Sortable/issues/1814

After doing some investigating, setting scroll: false, does in fact disable the AutoScroll plugin. However, it'll instead default to the browser's built in autoscroll with HTML draggable attributes.
Fair enough. However, if I decide to set scroll: true (or omit it), I see that the AutoScroll plugin is properly initialized and goes through the setup process. However, it still does not seem to be firing the internal autoscroll handler. After some investigation, it seems to be due to line 141 (https://github.com/SortableJS/Sortable/blob/master/plugins/AutoScroll/AutoScroll.js#L141).
In this line, when I change the call from getParentAutoScrollElement(elem, false) to getParentAutoScrollElement(elem, true),  the autoscroll config options work as expected, otherwise, it'll default to the default native autoscroll. Setting it to false will return the window scrolling element, rather than the current container in which to apply the scroll.
Not sure why it's set to false and even when changing it to true, setting a scrollFn still doesn't execute.

Closing because the issue is related to the original sortabje repo


triggerFlow to Azure function

Is there any possibility to trigger an Azure function with http request trigger? I know that Logic App is an alternative to MS Flow, but as a developer I prefer to skip no-code intermediaries. Thanks.

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

ID: 68267476-ee8d-7b95-446b-711ddb683da2
Version Independent ID: aa099b9d-48db-5513-11c7-32c49a27e5be
Content: Site design JSON schema
Content Source: docs/declarative-customization/site-design-json-schema.md
Product: sharepoint
GitHub Login: @spdevdocs
Microsoft Alias: spdevdocs

Unfortunately no, this is not possible. You'll need to call Flow or Logic Apps.


Is there a way to register a fieldname aside from a @JSONField annotation?

Hello there!
We've been working with fastjson to try and do something a bit "abstract" with a project. In our JSON we have:
vulnerabilities field, that we want to serialize into a Extension.class.
What we are trying to avoid is on our POJO putting a @JSONField annotation that ties it directly to vulnerability, as we know that more keys will be added (we are attempting to deserialize specific keys into a Map<String, Extension>.
I have yet to find a way with ParserConfig to map a field name to a specific Deserializer. Is this possible? Is there some way to do this? Scratching my head a bit, to be honest. If my description isn't clear let me know!

I found a slightly interesting workaround, but have not been able to FULLY get it to work.
I discovered alternateNames which works, but doesn't fully fix our problem because we want to know the actual fieldName it encounters, and a deserializer doesn't seem to be told that, just the "name" of the field so:
    @JSONField(deserializeUsing = ExtensionDeserializer.class, alternateNames = {"vulnerabilities"})
    private Map<String, Extension> extensions;

And in the ExtensionDeserializer, we get fieldName as extensions. We want it as vulnerabilities so that we can place the deserialized contents in a Map<String, Extension>.

Something that would be nice is if with ParserConfig we could put a deserializer for a fieldname, because then we could initialize the deserializer with enough context to know the original fieldname.


Always use ctx.Locale.Tr inside templates

Refactoring performed using
cd templates/
ag --only-matching --nofilename '[^{()\s]+\.Tr\b' | sed 's/ //g' | uniq --unique | sort -h | uniq --unique

 # Then pipe into vim, execute ':sort u', throw out `ctx.Locale.Tr`, and save as '../bad-instances'

for bad_instance in $(cat ../bad-instances); do
  echo $bad_instance;
  for file in $(ag --literal --files-with-matches "$bad_instance") ; do
    vim "$file" -c ":%s/$bad_instance/ctx.Locale.Tr" -c ':wq' ;
  done;
done

for file in $(ag --files-with-matches -Q '$ctx.Locale.Tr') ; do vim $file -c ':%s/\$ctx\.Locale\.Tr/ctx\.Locale\.Tr/g'; done
git checkout da0467e3b -- ./status/500.tmpl

This PR is a corollary to #27227 as that PR removes the unneeded locale parameters from subtemplates.

500.tmpl is special, it can't use ctx at the moment.

Done

Hmm… Is the current CI failure related to my changes or not?
I'm rather leaning towards unrelated.

Looks related to me.... the few tests I looked at refer to some text inside pages, or http errors... looks like broken templates

Found the culprit.
Am currently fixing it.

Okay, now I am confused:
According to the CI, my changes appear to be responsible for the failure.
However, I cannot reproduce the 500 locally.
I cannot even find a template that is called by the respective method.
So, I have no idea what is going wrong here.
Does anyone else have an idea?

@delvh It's the mail template under templates/mail/team_invite.tmpl.
It doesn't seem to work with ctx.Locale.Tr. When changing back to .locale.Tr, the tests pass

CI finally passes.

So effectively, I should revert the changes in the mail directory?

@delvh please fix the merge conflicts. :tea:

I was unable to create a backport for 1.21. @delvh, please send one manually. :tea:
go run ./contrib/backport 27231
...  // fix git conflicts if any
go run ./contrib/backport --continue


Add Devbox

Description
This PR adds a Devbox configuration to make working with the Python SDK easier.
Documentation
Does this require changes to the WorkOS Docs? E.g. the API Reference or code snippets need updates.
[ ] Yes

If yes, link a related docs PR and add a docs maintainer as a reviewer. Their approval is required.

Oops, sorry I missed this Monday!

All good! I wasn't expecting any reviews on PRs this week, but I appreciate it all the same 😄


DEV-14988: Add extra height constraints to prevent image-sequences from rendering outside of catalog lightbox boundaries

See these companion PRs with lightbox style updates (all three are identical, we should really move these styles into quire core soon):

https://github.com/thegetty/quire-starter-default/pull/30
https://github.com/thegetty/quire-starter-iiif/pull/3
https://github.com/thegetty/quire-starter-demo/pull/1

As a side note on those three content repos, as far as I know both @hbalenda and I have failed to update the iiif and demo ones as we've made changes to quire-starter-default for accordions and PDF output. Another thing to consider as we're also talking about versioning and where the content stuff lives, etc.


All of the tests.

Let's get some test coverage going!

 Automated testing

Reopening this as we've begun work on testing: #864, #865, #867, #868, #869

@aaronschachter should this issue stay open now that we have over 17% test coverage in Gambit? If its going to remain open, I guess we should add some goals to this ticket.


Add memo to transactions sent through Voyager

Description:

Add memo to track all txs Sent via Cosmos Voyager

can we include this emoji? 🚀


Added number field - issue#304

This is a working Number field where it also gets written to the markdown as a number type. It may be a little rough now as I haven't gone through and cleaned up the code. Focused on get it to work first.

Great work guys! Sorry for not being that active in the conversation ... Have had a lot on my table last couple of days. I should have clean up the code myself. Pushed my code that I created a long time ago just to give you something. =)

Everything looks good to me. Waiting on approval for the documentation.
https://github.com/tinacms/tinacms.org/pull/60

Thanks @weibenfalk this pr helped me get my head around these form components a little better  🍹 I also did a test and looks good to me :)

Great to hear! Thanks =)

11 feb. 2020 kl. 22:21 skrev PaulBunker<EMAIL_ADDRESS>Thanks @weibenfalk https://github.com/weibenfalk this pr helped me get my head around these form components a little better 🍹 I also did a test and looks good to me :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/tinacms/tinacms/pull/726?email_source=notifications&email_token=ACVRL3UH3LNHOTEF66L6NCDRCMJGPA5CNFSM4KRRVPYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELODZQA#issuecomment-584858816, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACVRL3QCSS4NNCLY2NCQ54LRCMJGPANCNFSM4KRRVPYA.


Glm broadcasting

Summary
This pr implements broadcasting of x and y for the GLMs that do not support it yet. More details in the issue.
To avoid compile errors with code that is optimized away the meta function as_scalar() was replaced with more general assume_type().
Tests
Each GLM has two new tests - one for broadcasting of x and one for y.
Side Effects
None.
Checklist

[x] Math issue #1378

[x] Copyright holder: Tadej Ciglarič
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

Could you please list the signatures this will add to the GLMs. In case this gets merged in time for 2.21 would want to make a stanc3 PR at the same time.
Is this otherwise ready for review?

Yes, this is ready for review.
This will add the following signatures:
real normal_id_glm_lpdf(double/var, matrix, real, vector, vector)
real normal_id_glm_lpdf(vector, row_vector, vector, vector, vector)
real bernoulli_logit_glm_lpmf(int, matrix, real, vector)
real bernoulli_logit_glm_lpmf(int[], row_vector, vector, vector)
real poisson_log_glm_lpmf(int, matrix, real, vector)
real poisson_log_glm_lpmf(int[], row_vector, vector, vector)
real neg_binomial_2_log_glm_lpmf(int, matrix, real, vector, real)
real neg_binomial_2_log_glm_lpmf(int[], row_vector, vector, vector, real)

@t4c1, this PR got out of synch with develop. Can you merge the latest develop in?

@bob-carpenter Just a reminder - this is still waiting for your review.

I just looked at this and realize a lot of it is GPU code.  Could you find someone else to review it as I don't know how any of that code works.

I will take a look then, if there are no other volunteers.

@bob-carpenter Since the idea for broadcasting in GLMs came from you I think you can review at least CPU part - which is half of the changes in this PR.

I'd like to review but I have a bit too much on my plate atm. @rok-cesnovar I can take a first look with some comments if your juggling too much atm

@t4c1 would it be possible to split the CPU stuff up into one PR and the GPU stuff into another. I think it would make the review easier. Then while Bob is looking over the CPU part Rok and I can start reviewing the GPU part

I can take a first look with some comments if your juggling too much atm

Sure, go ahead :)
I do agree with splitting this up tho.

I reverted all GPU stuff from this PR. So only CPU changes remain here. Once this is merged I will open another PR with GPU broadcasting.

Thanks.  I'll take a look when it's passing tests.  I'm traveling today, but have plenty of time starting tomorrow.

@t4c1 answered all the questions I had about this.  Before merging, I would very much like to see the name of assume_type changed and some doc on what it's for.  Thanks.

Please do not missunderstand - I agree with the comments I did not respond to. If you think some part of doc is unclear I will try to improve it.
I general I don't mind reviewers being strict - that is how we keep some level of code qualty.

Doesn't it have to work for rvalues like numeric literals?

On Dec 11, 2019, at 4:16 PM, Tadej Ciglarič<EMAIL_ADDRESS>wrote:
@t4c1 commented on this pull request.
In stan/math/prim/mat/meta/assume_type.hpp:

trigger compile error even though they are optimized away.

@tparam T_desired type of output we need to avoid compile time errors

@tparam T_actual actual type of the argument

@param a input value

@return the input value a

*/
+template <typename T_desired, typename T_actual,

     typename = std::enable_if_t<

         std::is_convertible<T_actual,

                             T_desired>::value&& static_cast<  // NOLINT

             int>(T_desired::RowsAtCompileTime)

             == static_cast<int>(T_actual::RowsAtCompileTime)

         && static_cast<int>(T_desired::ColsAtCompileTime)

                == static_cast<int>(T_actual::ColsAtCompileTime)>,

     typename = void>

+inline T_actual&& assume_type(T_actual&& a) {  // NOLINT
Actually I don't know why I used rvalue references here. Lvalue ref should be fine.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or unsubscribe.

On Dec 11, 2019, at 5:34 PM, Steve Bronder<EMAIL_ADDRESS>wrote:
@SteveBronder commented on this pull request.
In stan/math/opencl/prim/normal_id_glm_lpdf.hpp:

@@ -159,7 +159,7 @@ return_type_t<T_alpha, T_beta, T_scale> normal_id_glm_lpdf(
= from_matrix_cl<Dynamic, 1>(sigma_derivative_cl);
} else {
ops_partials.edge3_.partials_[0]

     = (y_scaled_sq_sum - N) * as_scalar(inv_sigma);

     = (y_scaled_sq_sum - N) * assume_type<double>(inv_sigma);

^I would look at forward_as and think it has something to do with std::forward

The implementation is literally std::forward with a check for assignability to the specified type.
I'm not that bothered if the name isn't forward_as---did you have another alternative or did you like assume_type?

The implementation is literally std::forward with a check for assignability to the specified type.

I'm not that bothered if the name isn't forward_as---did you have another alternative or did you like assume_type?

Lol oh whups sorry I was skimming this at work. Then yeah forward_as makes sense

@t4c1---please ping me when this is ready to review again---I don't want to miss it in the chatter.

@bob-carpenter Now that tests passed this can be reviewed again.


Migration from Azure functions 3.x to 4.x required after deployment; update to device bridge example required

It would be useful if this example could be updated to use version 4.x of Azure Functions to align with support for 3.x ending in December 2023. Running the pre-upgrade validator shows a range of issues that need to be resolved.
I'm unsure how best to update the example deployment json to use v 4.0 to deploy. I assume it is the API versions used and will look at this for a resolution in the meantime.
Thanks!

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

ID: 67845cea-8e3c-6b49-486e-42c88a579555
Version Independent ID: cb490be1-cba3-0f25-1f63-1a618374e4b7
Content: Deploy the Azure IoT Central device bridge
Content Source: articles/iot-central/core/howto-build-iotc-device-bridge.md
Service: iot-central
GitHub Login: @dominicbetts
Microsoft Alias: dobett

@nicolemeaker
Thanks for your feedback! We will investigate and update as appropriate.

Hi @nicolemeaker - the sample has now been updated for Azure Functions 4.x. See: https://github.com/Azure/iotc-device-bridge. Thanks for reporting this to us.
#please-close


Compatibility with Raspberry Pi 5?

Sorry to contact you via GitHub Issues, but I wasn't able to join the DeepRacer Community Discord (phone verification issue).
Just curious if this code works with the Raspberry Pi 5. I notice the README refers to "Raspberry Pi 4 compatible" boards. Would that include the 5?

I have not tried. Apparently GPIO works differently on the 5, so I suspect some changes would be needed.

Sorry, another quick question. I had a look at the .stl files for the mounting plate and front and back pieces, and it isn't clear which version of the files I should print out for use with the DeepRacer car. After opening them and examining them carefully, I assume I need to print:
PiMount v1.2-Back.stl
PiMount v1.2-Front.stl
PiMount v1.2-Plate.stl
So....all "v1.2". Is that correct?
Also, what mounting hardware did you use to mount the Pi to the plate and to mount the Pi camera? I bought a set of M3/M2.5 bolts, screws, and spacers, not knowing what else to buy.

You can do either v1.2 or v1.3 plate - the v1.3 plate has the Pi in the front, rotated - v1.2 has it on the right side. Legs if you want to mount on a DeepRacer, no-Legs if you want to mount on stock A947, A959, A979.
Check also - https://github.com/larsll/deepracer-pi/pull/10/files

Ok I'll try with the 4 first then (apparently Pi 4 and Pi5 share the same GPIO pinout but use different GPIO hardware supported by different libraries). 👍

The code primarily uses sysfs, so if that works then only the pin numbers need adjusting.

Awesome, missed that one.

Just a followup: I did test with a Pi 4B and a Waveshare servo driver hat. Worked like a charm.

Did some testing on the Raspberry Pi 5 this morning. Turns out Ubuntu Server 22.04 is not supported on the Pi 5 and there are no plans to back-port it.
This means either:

Updating the whole ROS 2 stack to work with ROS 2 Jazzy on Ubuntu 24.04
Attempting to run ROS 2 Humble on Ubuntu 23, as documented in this blog post
Attempt to run ROS 2 inside Docker containers running Ubuntu 22

I'll try Option 2 later this week and update here on whether or not it can be made to work. Options 1 and 3 are too much work for me to attempt right now.
As for GPIO incompatibilities, I'm not able to test that yet, but it does look like sysfs is forwards compatible with the Pi 5, assuming a newer kernel is used.

After some additional research it looks like there are enough problems to make Options 2 and 3 unlikely to work.

Running ROS 2 Humble in Docker on 24.04 can work, but as Docker containers aren't VMs and don't have a normal "boot" process, systemd isn't going to work and NetworkManager probably won't work either.
Running ROS 2 Humble on Ubuntu 23 might work, but Ubuntu 23 uses Python 3.11 not 3.10 and no deadsnakes Python 3.10 is available for Ubuntu 23, meaning it 3.10 would have to be built from source.

So the correct thing to do for the Pi 5 would be to port everything forward to ROS 2 Jazzy on Ubuntu 24.04. Don't have time for that right now but if I find the time I'll definitely give it a try + share my code.

@jeremypedersen - I think moving to Jazzy is the easiest thing. Foxy to Humble was quite simple; code changes were very limited. The bigger topic was to adapt the DR code to work with the OS (differences between 20.04 and 22.04). For now, as the RPi4 is working this is not really a priority, but still a valid request, so I will keep it open.

Note; this effort has moved to https://github.com/aws-deepracer-community/deepracer-custom


problems installing torch-geometric

pip-sync  requirements_lock.txt reports missing torch for any of these packages:
torch-cluster==1.6.0 \
    --hash=sha256:362076bd713268ba52ed31ac9517686e206084a50bc4ea50543bdeb992d25bfe
    # via -r requirements.in
torch-geometric==2.0.4 \
    --hash=sha256:d64e4c7486fcf0c7fa82f0acbf5dd52035855469708bf89f8bc7fc607671c8b7
    # via -r requirements.in
torch-scatter==2.0.9 \
    --hash=sha256:a3e90ca7d97b0269ba5c86995f93dedd9dba80c42a65aab51d0250581ef024b4
    # via -r requirements.in
torch-sparse==0.6.14 \
    --hash=sha256:1d19c337e4842f633aedc4e23ad27c15a7ac85ce1bee0b9b016e26a821ab5f85
    # via -r requirements.in
torch-spline-conv==1.2.1 \
    --hash=sha256:959287ca87f33b8c5d901d5dccf24b1744e9c10b60fee54958fc452302059426
    # via -r requirements.in

Environment Versions

OS Type: Ubuntu 20.04
Python version: $ python -V = Python 3.9.5
pip version: $ pip --version = pip 22.2.1
pip-tools version: $ pip-compile --version = version 6.8.0

Steps to replicate

create requirements_lock.txt with:

--find-links https://download.pytorch.org/whl/torch_stable.html
--find-links https://data.pyg.org/whl/torch-1.12.0+cpu.html
torch==1.12.0+cpu \
    --hash=sha256:133023854509dd84d7ccefd99d1e9c07c392efef48c574ef6f798933c284dd6a \
    --hash=sha256:2f15f6bfcc3bca61e9b7acead9b47e6ee848c3523dedfcff3efbdd07ae6777ed \
    --hash=sha256:37f14f640b91effe41db244b932c2dd697ca2b51ae241a534259b9d9f7f51f6f \
    --hash=sha256:69afe17ea3f1bd3dd5c88ede3e275c7395463293739965e9b206f94c575d8c99 \
    --hash=sha256:6fa9e60fed5c7d7738e49e343aa1c3849ba4f3bd4da661a146d86f253e5e43cb \
    --hash=sha256:733ebe15f94edda67286b0284921b513940024d9c1943ba4122cdae4959de6e6 \
    --hash=sha256:98993de211242593626a236ee31686b2dc31b6fe564ce10a4047167b9c3eb2f5 \
    --hash=sha256:ed618d8aec7c4d46edd05fb064b2712f039b418e414a83acb959596cdf80423c
    # via
    #   -r requirements.in
    #   torchaudio
    #   torchvision
torch-cluster==1.6.0 \
    --hash=sha256:362076bd713268ba52ed31ac9517686e206084a50bc4ea50543bdeb992d25bfe
    # via -r requirements.in
torch-geometric==2.0.4 \
    --hash=sha256:d64e4c7486fcf0c7fa82f0acbf5dd52035855469708bf89f8bc7fc607671c8b7
    # via -r requirements.in
torch-scatter==2.0.9 \
    --hash=sha256:a3e90ca7d97b0269ba5c86995f93dedd9dba80c42a65aab51d0250581ef024b4
    # via -r requirements.in
torch-sparse==0.6.14 \
    --hash=sha256:1d19c337e4842f633aedc4e23ad27c15a7ac85ce1bee0b9b016e26a821ab5f85
    # via -r requirements.in
torch-spline-conv==1.2.1 \
    --hash=sha256:959287ca87f33b8c5d901d5dccf24b1744e9c10b60fee54958fc452302059426
    # via -r requirements.in

pip-sync requirements_lock.txt

Expected result
pip-sync installed the packages
Actual result
Collecting torch-cluster==1.6.0
  Using cached torch_cluster-1.6.0.tar.gz (43 kB)
  Preparing metadata (setup.py) ... error
  error: subprocess-exited-with-error

  × python setup.py egg_info did not run successfully.
  │ exit code: 1
  ╰─> [6 lines of output]
      Traceback (most recent call last):
        File "<string>", line 2, in <module>
        File "<pip-setuptools-caller>", line 34, in <module>
        File "/tmp/pip-install-jpw__qkf/torch-cluster_04c100c202574c86820a68b9c8a6ad3f/setup.py", line 8, in <module>
          import torch
      ModuleNotFoundError: No module named 'torch'
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.

Workaround:
 pip-sync --pip-args "--only-binary torch-cluster,torch-scatter,torch-sparse,torch-spline-conv" requirements_lock.txt

but then the hashes are different than those created by pip-compile and need to be adjusted manually... Maybe there is a way to avoid this?

I think an issue here is that torch-cluster doesn't use a pyproject.toml (or deprecated setup file stuff) to specify that torch is a build dependency, yet does in fact require torch to be pre-installed in order to build; see https://setuptools.pypa.io/en/latest/build_meta.html#dynamic-build-dependencies-and-other-build-meta-tweaks

I think you'll see the same problem installing with pip install -r requirements_lock.txt, as long as torch isn't preinstalled.

Another workaround I found is to install the torch deps like this:

@AndydeCleyre do you have an idea why the hashes might be different when using:
pip-sync --pip-args "--only-binary torch-cluster,torch-scatter,torch-sparse,torch-spline-conv" requirements_lock.txt
as compared to the hashes generated by pip-parse?
I double checked for example the hash for torch-scatter returned by pip-compile is correct as can be seen here:
(https://pypi.org/project/torch-scatter/#copy-hash-modal-d4d4dc20-c5c5-4f31-9fab-4994e36cc657):
but when running:
pip-sync --pip-args "--only-binary torch-cluster,torch-scatter,torch-sparse,torch-spline-conv" requirements_lock.txt
I get:
 (ERROR: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.
    torch-scatter==2.0.9 from https://data.pyg.org/whl/torch-1.12.0%2Bcpu/torch_scatter-2.0.9-cp39-cp39-linux_x86_64.whl (from -r /tmp/tmpyj7b66_c (line 1)):
        Expected sha256 08f5511d64473badf0a71d156b36dc2b09b9c2f00a7cd373b935b490c477a7f1
             Got        a3e90ca7d97b0269ba5c86995f93dedd9dba80c42a65aab51d0250581ef024b4

Yeah, I'm not too familiar with the hash logic, but I think when fetching remote hashes we currently rely on the --index-url, maybe not accounting for --find-links.
Pinging @atugushev for some wisdom here
Related: #1109

Oh, this might be an unknown bug where pip-compile wouldn't fetch hashes from packages listed in --find-links. See details below.


Error messages

Add messages to error responses returned by Hummingbird
Return messages as json

Also considering #432, we should consider making empty error messages (possibly optionally) non-json. I don't think it makes sense to serialize {} into an application/json

Errors with no body no longer report as having a JSON content type


Issue 45

Fixes Issue #45

Fixes issue #45

FWIW * seems a bit optimistic to me (unless you run tests on a lot of different node/npm combinations which I think SRE currently does not)

(To clarify: I meant versions of the dependencies in the package.json)


Not working on any versions of Windows 7 while installing SP1

I have official installations of Windows 7 Pro, Home, and more (x86 and x64), yet legacy update will not work on any of them.
It runs the updater and is installing SP1 but while the computer is doing that I get an error saying "Legacy Update has stopped working" after that the OS is unusable as legacy update makes registry changes during the upgrade of the service packs.
Not sure what to do here felt you all should know this is an issue.

This will be the same issue as #186, sorry for the problem. As a workaround you can log out of the LegacyUpdateTemp user it creates, log into your own user, and run Legacy Update setup again, unticking Enable Microsoft Update. It'll clean up the temp user when it finishes (or if you just click Cancel).
Will close this as a duplicate, but thanks for posting regardless.


Fix issues

Codecov Report

Merging #12 (8c1b09c) into master (b68124a) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff             @@
##            master       #12    +/-   ##
==========================================
  Coverage   100.00%   100.00%
==========================================
  Files           16         1    -15
  Lines          426         6   -420
==========================================
- Hits           426         6   -420

Impacted Files
Coverage Δ

lib/app/app.dart

lib/common/widgets/custom_elevated_button.dart

lib/manage_note/cubit/manage_note_cubit.dart

lib/manage_note/view/manage_note_page.dart

lib/note/cubit/note_cubit.dart

lib/note/view/note_page.dart

lib/notes_overview/cubit/notes_overview_cubit.dart

lib/notes_overview/view/notes_overview_page.dart

packages/notes_api/lib/src/models/note.dart

lib/note/cubit/note_state.dart

... and 5 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Code navigation stuck on "$"

Type: Bug
I have language settings configured to NOT treat $ as word separator (in PHP, it's a part of every variable name, not a separate operator), nonetheless, 1.90 started to stumble upon it like on a sore thumb when you move around with Ctrl+Arrow keys.
Reproducible with extensions disabled.
VS Code version: Code 1.90.0 (89de5a8d4d6205e5b11647eb6a74844ca23d2573, 2024-06-04T19:33:54.889Z)
OS version: Windows_NT x64 10.0.19045
Modes:

System Info

Item
Value

CPUs
Intel(R) Core(TM) i3-8145U CPU @ 2.10GHz (4 x 2304)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: enabled_ondirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_graphite: disabled_offvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
undefined

Memory (System)
7.86GB (0.16GB free)

Process Argv
--folder-uri file:///d%3A/Profiles/anrdaemon/Documents/hk/invapi-php

Screen Reader
no

VM
0%

@hediet could you please help reroute this issue if you're not the intended audience?

Turned out, I've enabled screen reader compatibility mode somehow.
After locating and clicking an inconspicuous "Screen Reader" button somewhere in the footer, everything returned back to normal. Although I still don't understand, why it did so like the way it did.

Seems to be fixed now.

Doesn't look like it is fixed.
Why would enabling screen reader discard an explicitly configured option?


[LAB] Week 3_Problem 1_박하원

Problem
Week 3_Problem 1
Source Code
import torch
import torch.nn.functional as F
from random import random
from typing import Callable

##                         Problem 1                          ##
##                                                            ##
##            Arbitary x_train, y_train are given.            ##
##          In function predict(), you should return          ##
##            list y_test corresponding to x_test.            ##
##               y_train only contains 0 and 1.               ##
##             Therefore, use logstic regression.             ##
##                  Made by @jangyoujin0917                   ##
##                                                            ##

# NOTE : 1. Feel free to use torch.optim and tensor.
#        2. In this problem, we will only grade "predict" function.
#           Function "training" is only for modularization.

def training(x_train : list, y_train : list) -> tuple: # DO NOT MODIFY FUNCTION NAME
    y_min = min(y_train)
    y_max = max(y_train)
    normalize = lambda y : (y - y_min)/(y_max - y_min)

    normalized_y_train = [[normalize(y)] for y in y_train]

    w = torch.tensor(1., requires_grad=True)
    b = torch.tensor(0., requires_grad=True)

    alpha = 0.0001
    epoch = 1000

    x_train_tensor = torch.tensor(x_train, requires_grad=True)
    y_train_tensor = torch.tensor(normalized_y_train, requires_grad=True)
    optimizer = torch.optim.SGD([w, b], lr=alpha)

    for _ in range(epoch):
        optimizer.zero_grad()
        hypothesis = torch.sigmoid(x_train_tensor * w + b)

        error = -(y_train_tensor * torch.log(hypothesis) + (1 - y_train_tensor) * torch.log(1 - hypothesis)).mean()
        error.backward()
        optimizer.step()

    return w.data.item() * (y_max - y_min), b.data.item() * (y_max - y_min) + y_min

def predict(x_train : list, y_train : list, x_test : list) -> list: # DO NOT MODIFY FUNCTION NAME
    w, b = training(x_train, y_train)

    temp = torch.sigmoid(torch.tensor(x_test) * (torch.tensor(w)) + torch.tensor(b))

    return [0 if i[0] < 0.5 else 1 for i in temp.tolist()]
    ### IMPLEMENT FROM HERE

if __name__ == "__main__":
    # This is very simple case. Passing this testcase do not mean that the code is perfect.
    # Please consider for the practial problems when score is not high.
    x_train = [[0., 1.], [1., 0.], [2., 5.], [3., 1.], [4., 2.]]
    y_train = [0., 0., 1., 0., 1.]
    x_test = [[7., 2.], [1.5, 1.], [2.5, 0.5]]

    y_test = predict(x_train, y_train, x_test)

    print(y_test)

Description
.
Output (Optional)
No response

This issue is closed now because of the lack of progress.


stream issue ?

Adding a text version of the screenshot above for people to find this issue:
On Next.js 14.1 when running next build, this error comes:
./node_modules/replicate/lib/stream.js
Module not found: Can't resolve 'stream' in '/Users/param/Code/poc/node_modules/replicate/lib'
Did you mean './stream'?
Requests that should resolve in the current directory need to start with './'.
Requests that start with a name are treated as module requests and resolve within module directories (node_modules).
If changing the source code is not an option there is also a resolve options called 'preferRelative' which tries to resolve these kind of requests in the current directory too.

Current workaround: install readable-stream npm package.
Being fixed in: #181


Fix issue where propel reverse breaks with system-versioned tables

MariaDB 10.3.4 introduced system-versioned tables (https://mariadb.com/kb/en/temporal-data-tables/).
There is a known issue (possibly a bug) that can cause issues for ORM tools like Propel, described here: https://jira.mariadb.org/browse/MDEV-16857?focusedCommentId=117570&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-117570
"ORM tool will be confused as the primary key definition in the database doesn't match the one defined in application code after system versioning is enabled."
Basically, system versioning creates an invisible primary key that shows up with "SHOW KEYS FROM table" but not with "SHOW COLUMNS FROM table". This PR fixes that by skipping these invisible primary key columns when generating the schema.

ping @zwhedbee
Are you able to fix up the CS issue? Otherwise, we can also do that post-merge.

Sorry for the issues with the original PR and that I haven’t been able to resolve those. Post-merge would be fine.


Fix navigation issue of supported distributions

Description:
in README, there is a navigation issue of supported distribution feature which has been introduced in v2. I fixed this in this PR.
Check list:

[ ] Mark if documentation changes are required.
[ ] Mark if tests were added or updated to cover the changes.

Thank you for contribution!


Confirm before the state is changed.

In my use case, enabling or disabling the button makes a call to server, so I want to add a confirm window before the state is changed asking the user if he/she really wants to change the state.
So I added a directive:
.directive('ngConfirmClick', [
function(){
return {
priority: 10,
restrict: 'A',
link: function(scope, element, attrs){
element.bind('click', function(e){
var message = attrs.ngConfirmClick;
if(message && !confirm(message)){
e.stopImmediatePropagation();
e.preventDefault();
}
});
}
}
}
])

But this directive doesnt work. It doesnt gets called at all. Can you help me if this can be achieved.

binding to the change event might work better. however, there's no guarantee of if the event listener will be bound before or after the Switchery event listeners.
Unfortunately I have been pretty busy lately & have not been able to add time to this project. You may want to check out the CSS solution described in the README & create your own directive using that.


Bumpline plot using binaries - the challenge

Dear Asjad,
I have worked your examples and beside my minor comments all is well.
Then, to proceed to create a bumpline plot like:

some serious work will be required.
The current functionality is based on using ' a numeric y variable and a numeric x variable. The x variable is usually a time variable'.
For my type of bump the  'x variable' is categorical variable (age groups), so that is in agreement with your syntax.
The 'problem' is with the 'y variable' for which your code uses the by(varname) to calculate the bumps of the plot, which is the same  categorical by(varname) but now ranked relatively at each ordered position of the x variable.
It is here where my 'problem' originates as you calculate the relative rank order of the y variable (summed) by the by(varname). That will work just fine but only when the y variable is a single measurement as such.
But that is not how the above plot was created. What we see on the y-axis is the relative rank of thirteen binary variables. To be able to create this graph I first have to go through matrix calculations to collect the relative rank of the binary variables and hustle back and forth to collect labels at the correct position in the matrix, save all that into a result data set to finally settle on a twoway command like:

local color "blue "0 162 232" "0 162 232" "0 162 232" teal blue orange orange teal purple orange gs7 gs8"
local mc "`color'"
local fc "blue "0 162 232" "0 162 232" "0 162 232" "255 255 0" "255 255 0" orange orange "255 255 0" "255 255 0" orange white gs8"
local lc "`color'"
local pms "o o o o o o o o o o o s s"
local msi "*2 *2 *2 *2 *2 *2 *2 *2 *2 *2 *2 *1.8 *1.8"
tw line sal uitd ontw arbv kreis bwsf mzing mflex intb mvert maut geen andr xage , lc(`lc') ///
	|| scatter sal uitd ontw arbv kreis bwsf mzing mflex intb mvert maut geen andr xage , ms(`pms') msiz(`msi') mc(`mc') mfc(`fc')  ///
	, legend(off) text(14 -1.5 "NSO21 `binary'", size(*.8)) ///
	plotreg(m(b+1 l+1 r+1)) xtit("") ytit("") xsize(12) ysize(8) ///
	graphreg(fc(white) lc(white) ilc(white) m(l-0 r-1 b-2 t-1))	///
	ysca(range(1(1)13) rev) xsca(range(2(1)9)) ///
	xlab(1 "20t25" 2 "25t30" 3 "30t35" 4 "35t40" 5 "40t45" 6 "45t50" 7 "50t55" 8 "55t60" 9 "60t65", labs(*.9) ) /// 11 "60t70"
	ylab(1 "Hoger salaris of loon " 6 "Betere arbeidsvoorwaarden " 11 "Meer autonomie " 2 "Meer uitdaging " 8 "Meer flexibiliteit " 7 "Meer vertrouwen " 5 "Betere werksfeer " 9 "Kortere reistijden " 3 "Meer ontwikkeling " 10 "Internationale loopbaan " 4 "Meer zingeving " 12 "Andere reden " 13 "Geen enkele reden ", labs(*.9) angle(none))

This is something of a 'coding cauchemar' because I am drawing a bundle of line graphs for which properties are set manually (through locals) and, even worse, the same has to be done to label each one of them. Moreover, to be able to continue with another bump plot but now for a subset of the data (like males or females) I have to tinker with all these options and labels all over again.
So, you can imagine that this could be improved seriously.
But how?
My more naive solution would be to be able to specify multiple binary variables in your command, something like:
bumpline y1 y2 y3 y4 y5 y6 y7 y8 y9 y10 y11 y12 y13 x
which must prohibit the use of by(varname), or, should this totally mess up your code, create a special version, like:
bibumpline y1 y2 y3 y4 y5 y6 y7 y8 y9 y10 y11 y12 y13 , over(x)
or
bibumparea y1 y2 y3 y4 y5 y6 y7 y8 y9 y10 y11 y12 y13 , over(x)
where the x variable is set through the over(varname) (although I expect Nick Cox will complain about the use of 'over' for this purpose.
Anyway, I assume that you probably will have very different ideas on how to accomplisch such 'binary based' bump plots.
And if possible, how to carry over options once set for a (first) plot to the next (subset) plot, is a problem of its own.
Ofcourse, I am more than willing to support you with data to test and testing itself.
On a side note, I assume that you are aware of the 'origin' of the 'bump chart' itself: Oxford University Boat Races!
which date back to 1815 and with the first chart from 1824!
There is actually a lot on this subject to be found (I have collected a good deal of it, should you be interested).
But, I did not try to create a true Oxford bump chart, the data is rather terse, but I suspect something like a binary approach will be required for that as well.

Allowing bumplines over categorical variables is doable! I got a similar request from another user so will prioritize this.

Good to read that this is possible. But note that the above case is a little more 'complicated because a 'collection' of binary variables are 'bumped' (so, here not the individual categories of a single categorical variable-which would be just as useful).


Incorrect Statement

There's a statement toward the top of the page that reads:
"Retention settings from both retention policies and retention labels do not apply to organizing structures that include libraries, lists, and folders."
You later go on to discuss the Preservation Hold Library, which is specifically there to hold the items per the retention policy. So the first statement should be amended to exempt the Preservation Hold Library.
Additionally, throughout the documentation pages on SharePoint, OneDrive and other pages about data retention (including this article), you reference 30 days or 93 days. However, all of those are customizable time frames. So, you should really be specific that it is the time frame set in our tenants, and ideally include the link path to get to that setting.

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

ID: 36b54827-f642-4c77-7cfe-64e8c2a1d1d9
Version Independent ID: 67dffecf-4da7-864d-5c10-9b55740f32cd
Content: Learn about retention for SharePoint and OneDrive - Microsoft Purview (compliance)
Content Source: microsoft-365/compliance/retention-policies-sharepoint.md
Service: o365-seccomp
GitHub Login: @cabailey
Microsoft Alias: cabailey

@cabailey Please help us in resolving this issue. Thanks

@DontNeedNoGit Yes, the statement also applies to the Preservation Hold Library - Microsoft 365 retention settings don't retain or delete the Preservation Hold Library itself but apply to items in it.
I'm told it's not supported to change the 30/93 days for SharePoint/OneDrive, so they are not default values that can be customized per tenant. If you have a link that suggests otherwise, please share that.

Here in OneDrive:
https://TENANTNAME-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/settings/OrphanedPersonalSitesRetentionPeriod
I quickly found that one. I don't see SharePoint in there. So, maybe that can't be changed. I'd have to dig more, but ^ example shows that at a minimum, OneDrive is customizable. So, the source of your data that it cannot be changed "for SharePoint/OneDrive" is at least partially incorrect, and I would say invalidates that data point. I've got a super busy week, but I'll try to find a similar option for SharePoint if I find time.

I think I see the confusion - you're referring to this scenario that supports the retention and deletion of OneDrive sites for deleted users? https://learn.microsoft.com/en-us/onedrive/retention-and-deletion
That's a different scenario to the Microsoft 365 retention and deletion of individual items in SharePoint and OneDrive.  If you change those settings, they don't impact the 30/93 days mentioned here for individual items.  The long but helpful PowerShell parameter helps to clarify scope: "OrphanedPersonalSitesRetentionPeriod"

I think we can close this now?  The numbers quoted on this page are accurate and can't be changed by configuring OneDrive settings for orphaned sites.


Make parsing 17% faster.

I've spent a couple of hours optimizing some low-hanging fruits in the parsing (while for RF this may not be a huge gain, the language servers which use the parsers can gain quite a bit since parsing is a bottleneck on big documents).

Very interesting! I haven't yet tested changes locally, but I believe your measurements. Tests have also succeeded on CI so changes shouldn't have broken anything either.
Some general comments about the changes:

Since there are two separate enhancements, two separate PRs would've been a bit easier to review. Changes are relatively simple, considering that this is optimization, so we ought to manage this way as well.

Resolving lexer classes just once is a clever idea. It would be great if there was a cleaner way to accomplish that than a module level function call, though. Especially the fact that the function in blocklexers apparently modifies also classes in statementlexers is kind of ugly. I was thinking we could possibly use a metaclass instead, but that probably won't work because all lexer classes may not be available yet at the class creation time. Another alternative would be resolving classes when lexer_classes is called the first time:
def lexer_classes(self):
    if self._resolved_lexer_classes is None:
        self._resolved_lexer_classes = self._lexer_classes()
    return self._resolved_lexer_classes

If the check for self._resolved_lexer_classes is considered expensive, perhaps we could even rewrite the whole method:
def lexer_classes(self):
    classes = self._lexer_classes()
    self.lexer_classes = lambda: classes
    return classes

I think the above solutions would have same performance as the current proposal but that would need to be tested. I agree performance is important here so even somewhat ugly but fast solution is fine. If we'd stick with the current proposal, the RESOLVED_LEXER_CLASSES should be defined already in the base Lexer class with a comment explaining where it is populated.

Avoiding unnecessary iteration of tokens in _cleaup_tokens looks good too. I especially like how you handle comments. That said, the resulting method is now pretty long and there seems to be parts that aren't related to each others. Would splitting it to helper methods slow down parsing speed too much? I'd prefer that over comments explaining that the code is doing in general because it eases maintenance.

Let me know what you think about my proposals related to points 2. and 3. above. We could also do it so that I merge this PR and then do those changes myself.

Since there are two separate enhancements, two separate PRs would've been a bit easier to review. Changes are relatively simple, considering that this is optimization, so we ought to manage this way as well.

I'll keep that in mind for future PRs.

Especially the fact that the function in blocklexers apparently modifies also classes in statementlexers is kind of ugly.

I can't really see that happening (i.e.: def lexer_classes is only found in blocklexers.py -- statementlexers.py was changed only to convert the handles to a classmethod).
Another thing that happened is that the method lookup became an attribute access which is faster (so, if the approach is changed to still have a method it'll probably regress a bit from the performance in the patch)...

Would splitting it to helper methods slow down parsing speed too much? I'd prefer that over comments explaining that the code is doing in general because it eases maintenance.

Regarding _cleanup_tokens, I usually tend to inline methods if the performance is really critical in some session (and I think it is in this case), but if you'd rather regress a bit in the performance to keep the code a bit cleaner in this case, that's ok for me (also, splitting usually prevents some optimizations as it makes it harder to see the full code, so, in this case I started expanding all the code to then started looking for things which could be enhanced -- I think there are additional opportunities there, but I didn't have more time to dig further).
The current profile I have is below (so, _cleanup_tokens is the 3rd there) -- keep in mind that the profile itself adds some overhead, which makes function calls even slower, so, to make final measurements the timing should be gotten without the profile overhead...

As a note, the code I used to measure the performance is below (if you want to get a profile picture you can get https://www.pyvmmonitor.com/download.html, start it and uncomment the code related to it -- you may have to update the sys.path.append if you don't install it in the default location):
from robot.api import get_model
import time

header = """
*** test case ***
"""

body = """
some keyword
    no operation    ${some var}
    no operation

""" * 10000

full = header + body
print(len(body.splitlines()))
count = 10

_count = 3
_full = '''
*** test case ***
*** keywords ***
some keyword   #comment
    no operation    #  comment

'''

def main():
    check()

# import sys
# sys.path.append('C:\\Program Files\\Brainwy\\PyVmMonitor 2.0.2\\public_api')
# import pyvmmonitor
# @pyvmmonitor.profile_method
def check():
    values = []
    for i in range(count):
        t = time.time()
        get_model(full)
        values.append(time.time() - t)
        print('%s of %s' % (i, count))

    m = min(values)
    values.remove(m)

    m = max(values)
    values.remove(m)

    avg = sum(values) / len(values)
    print('%.2fs' % avg)

if __name__ == '__main__':
    main()

p.s.: Feel free to change the PR in any way you'd like to get it integrated (I'm saying this because it's usually faster for a maintainer just change and merge than going back and forth, but if you'd like me to do the changes, that's ok too).
p.s.2: Another thing that crossed my mind was using some optional accelerator modules using cython (but this can add some burden in maintaining build scripts, so, I wasn't sure it was worth investigating).
p.s.3: There are definitely other low-hanging fruits there... Image showing profile by cumulative time:

I tested this locally and was able to reproduce ~10% performance enhancement with the data set I used. That's very nice!
I tested changing the code so that lexer_classes itself resolves classes only once like this:
-    @classmethod
-    def lexer_classes(cls):
+    def lexer_classes(self):
+        classes = self._lexer_classes()
+        self.lexer_classes = lambda: classes
+        return classes
+
+    def _lexer_classes(self):
         return ()

That change didn't affect the performance but avoided the somewhat ugly global modifications of the classes. To my surprise the performance didn't change when I commented out the self.lexer_classes = lambda: classes line which basically reverts the logic to what it was initially. Could it be that resolving classes multiple times doesn't actually have meaningful performance penalty? The change to make Lexer.handles a classmethod could be responsible for most of the benefits. Could you @fabioz test this with your data?

From my tests here it's just a bit slower. The test timing with my data/machine goes from around 1.58s -> 1.61s, so, it accounts for a bit less than 2% of the savings to me -- most gains there really seem to be from not creating the class instances and not from the function call/tuple creation.
I agree that this is probably what makes the code uglier. I'll leave it up to you to decide whether you think it's worth it or not.

-    @classmethod
-    def lexer_classes(cls):
+    def lexer_classes(self):
+        classes = self._lexer_classes()
+        self.lexer_classes = lambda: classes
+        return classes
+
+    def _lexer_classes(self):
         return ()

p.s.: have you changed all the classes so that _lexer_classes is overridden instead of lexer_classes? Because otherwise, the lexer_classes is the method still overridden and this did nothing.

Good point that trying to be too clever with overriding the called function can cause problems with Python's own optimization especially when there are so many enhancements planned for that in Python 3.11+. I think it's best to just leave lexer_classes as it was because performance benefits are so small. Converting handles to a class method avoids creating instances unnecessarily and seems to have much bigger impact.

I played with the tokenizer changes locally. Changes in this PR had smallish but measurable performance benefits that seemed to surprisingly be mostly due to method inlining. As I commented earlier, this change made the method somewhat long and complex, and I tried to find alternatives for similar performance benefits. Most of the changes caused barely measurable enhancements, but the following change had pretty much exactly the same effect as the change in this PR:
diff --git a/src/robot/parsing/lexer/tokenizer.py b/src/robot/parsing/lexer/tokenizer.py
index 1784cbec0..39311bd59 100644
--- a/src/robot/parsing/lexer/tokenizer.py
+++ b/src/robot/parsing/lexer/tokenizer.py
@@ -72,8 +72,7 @@ class Tokenizer:
         yield rest, True

     def _cleanup_tokens(self, tokens, data_only):
-        has_data = self._handle_comments(tokens)
-        continues = self._handle_continuation(tokens)
+        has_data, continues = self._handle_comments_and_continuation(tokens)
         self._remove_trailing_empty(tokens)
         if continues:
             self._remove_leading_empty(tokens)
@@ -82,31 +81,27 @@ class Tokenizer:
             tokens = self._remove_non_data(tokens)
         return tokens, has_data and not continues

-    def _handle_comments(self, tokens):
+    def _handle_comments_and_continuation(self, tokens):
         has_data = False
+        continues = False
         commented = False
         for token in tokens:
             if token.type is None:
                 # lstrip needed to strip possible leading space from first token.
                 # Other leading/trailing spaces have been consumed as separators.
                 value = token.value.lstrip()
-                if value and not commented:
+                if commented:
+                    token.type = Token.COMMENT
+                elif value:
                     if value[0] == '#':
+                        token.type = Token.COMMENT
                         commented = True
-                    else:
+                    elif not has_data:
+                        if value == '...':
+                            token.type = Token.CONTINUATION
+                            continues = True
                         has_data = True
-                if commented:
-                    token.type = Token.COMMENT
-        return has_data
-
-    def _handle_continuation(self, tokens):
-        for token in tokens:
-            if token.value == '...' and token.type is None:
-                token.type = Token.CONTINUATION
-                return True
-            elif token.value and token.type != Token.SEPARATOR:
-                return False
-        return False
+        return has_data, continues

     def _remove_trailing_empty(self, tokens):
         for token in reversed(tokens):

The above change basically combines functions for handling comments and continuations together which avoids one pass through the tokens. Also this is a bit more complicated than earlier, but looks pretty ok to me anyway. Could you @fabioz test how these changes affect performance with your tests?

2% is quite little especially when shown only by a single benchmark. Could also be that Python 3.11 with various enhancements to performance changes these measurements. Anyway, I'll merge this PR as-is and then look at the code again. I'll certainly remove resolving classes and even more certainly preserve handles as a classmethod. I'll take another look at tokenizing and decide what to do with it. When I'm done, I hope you can try out the code and experiment with possible new changes.
One thing to test would be adding __slots__ to lexer classes. It mainly affects memory usage and it can be that when parsing individual files that doesn't give any benefits. Could also try adding __slots__ to the parsing model objects, but they are based on ast.AST that at least in Python 3.10 doesn't itself have __slots__. I think that was about to change but haven't tested with Python 3.11.

I merged the PR and then did some of the changes discussed above. In my tests there was no measurable performance difference before and after my changes and the code is, arguably, a bit cleaner. Anyway, hopefully you @fabioz can test the latest changes and report if there are big differences or that if you find out other possible enhancements. Thanks also for the contribution!


[openmama] Modify the output path of the common header file

Describe the pull request
In CI Test, workflow installation failed with following errors:
error C2079: 'list' uses undefined struct 'list_head'
error C2198: 'list_for_each': too few arguments for call
error C2143: syntax error: missing ';' before '{'

This issue occurs because there is a list.h file generated by openmama and saved in the vcpkg\installed{triplets}\include folder, it conflict with the list.h file of workflow. As a result, the structure and macro defined in the header file list.h(workflow) become undefined during compilation.
After communicatied with upstream, I moved these common header files into the wombat folder and modified header files those include the common header files.
BTW, update the REPO and homapage from OpenMAMA/OpenMAMA to finos/OpenMAMA, because OpenMAMA/OpenMAMA is no longer found.

@ras0219-msft
There are more than 300 header files generated by openmama, most of which have nothing to do with this modification. I have verified the header file that was modified and other header files affected by this modification, and they can be compiled normally. So I want to confirm with you that other header files still need to be verified?

Please create one .cpp file that includes every header and try to compile that file.
ls -recurse .\packages\openmama_x64-windows\include\* | % { "#include <$_>" -replace "\\","/" } | out-file -enc ascii test.cpp

I have tested all of the generated header files of openmama, and them built failed with following errors:

I also tested the files of previous versions of openmama and the files manually downloaded from https://github.com/finos/OpenMAMA, and above errors still exist.
So these errors have nothing to do with this PR.

Hi it's the OpenMAMA maintainer here and yes this looks good to me. The fact is most users won't actually be using those headers anyway and in future I'll try and get these moved into a subdirectory by default. When that time comes I'll update this workaround in VCPKG but for now yes this looks perfectly fine to me.


Create example for disabled prop issue.

Example for Issue #153 .

This is more of a bug, so it should be fixed instead of advocating a workaround.


Fetching kernel GPG key ... Failed

I'm trying to use this installer on a brand new install of Debian Jessie 8.1.0 but it just fails as follows:
==> Checking current versions of grsecurity ...
######################################################################## 100.0%
######################################################################## 100.0%
######################################################################## 100.0%
==> 1. grsecurity version 3.1 for kernel 3.2.69, revision<PHONE_NUMBER>15 (stable version)
==> 2. grsecurity version 3.1 for kernel 3.14.48, revision<PHONE_NUMBER>03 (stable version)
==> 3. grsecurity version 3.1 for kernel 4.1.3, revision<PHONE_NUMBER>02 (testing version)
==> Please make your selection: [1-3]: 2
==> Remove build tools after install? (build-essential bin86 kernel-package libncurses5-dev zlib1g-dev gcc-4.9-plugin-dev bc): [y/N]
==> Installing grsecurity stable version 3.1 using kernel version 3.14.48 ...
==> Fetching kernel GPG key ... Failed

I should add that I am little more than a script kiddie when it comes to these types of things.

You might be missing the gnupg tools, try installing them with sudo apt-get install gnupg and try again.
I will try update the install script to also install this tool

No, that's definitely not it. I had just finished generating my own GnuPG key minutes before.

gpg should do gpg --recv-keys from the keyserver first before verifying signatures