text:
Confirmation::wait() blocks forever on failure when running on Windows

Executing the following code on Windows and Linux (actually WSL running on the same machine to demonstrate that network/firewall are not at fault) and with rabbitmq halted, the Windows executable blocks forever or at least until interrupted with control-c.
Under Linux it will, as expected, return immediately and produce output: "Connection failed: ConnectionRefused"
This was tested with lapin 0.28.1.
use lapin::{Connection, ConnectionProperties};

fn main() {
   match Connection::connect("amqp://127.0.0.1:5672/%2f", ConnectionProperties::default()).wait() {
       Ok(_conn) => println!("Connected"),
       Err(e) => println!("Connection failed: {:?}", e) ,
   };
}

As an addendum, with logging set to trace, it prints the following (and then hangs)
[2019-11-09T00:46:17Z ERROR lapin::io_loop] error reading: IOError(Os { code: 10057, kind: NotConnected, message: "A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied." })        [2019-11-09T00:46:17Z ERROR lapin::connection] Connection error

Interesting, I'm getting strange behavior as well, no errors, and I'm running on Windows. However, my issue is it connects to the queue successfully every time, but it stops processing messages part way through. If I restart it may process everything, then if I restart again it might just process 3 things, etc.

Hi,
Fwiw, I'm working on better error reportig, once I'm done with this, we might get better insight of what's going on, but looks like mio is working differently on windows.
I do not have a windows system to test this though

Any chance you could retry this with lapin 0.30?
Error reporting will hopefully be better

redoing the test with lapin 0.30.1 looks similar:
 Running `target\debug\lapin_test.exe`

[2020-02-26T22:50:58Z TRACE mio::poll] registering with poller
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] register Token(1) Readable | Writable
[2020-02-26T22:50:58Z TRACE mio::sys::windows::tcp] scheduling a connect
[2020-02-26T22:50:58Z DEBUG lapin::channels] create channel with id 0
[2020-02-26T22:50:58Z TRACE lapin::connection] connection send_frame; channel_id=0
[2020-02-26T22:50:58Z TRACE lapin::connection] connection set readable
[2020-02-26T22:50:58Z TRACE mio::poll] registering with poller
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] reregister Token(1) Readable | Writable
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to (empty)
[2020-02-26T22:50:58Z TRACE mio::sys::windows::tcp] scheduling a read
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to Readable
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to Readable | Writable
[2020-02-26T22:50:58Z TRACE mio::poll] registering with poller
[2020-02-26T22:50:58Z TRACE mio::poll] registering with poller
[2020-02-26T22:50:58Z TRACE lapin::io_loop] io_loop run
[2020-02-26T22:50:58Z TRACE lapin::io_loop] io_loop poll
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] select; timeout=Some(0ns)
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] polling IOCP
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] returning
[2020-02-26T22:50:58Z TRACE lapin::io_loop] io_loop poll done
[2020-02-26T22:50:58Z TRACE lapin::io_loop] io_loop do_run; can_read=true, can_write=true, has_data=true
[2020-02-26T22:50:58Z TRACE lapin::io_loop] will write to buffer: ProtocolHeader
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to Readable
[2020-02-26T22:50:58Z TRACE mio::sys::windows::tcp] scheduling a write of 8 bytes
[2020-02-26T22:50:58Z TRACE mio::sys::windows::tcp] write error: A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied. (os error 10057)
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to Readable | Writable
[2020-02-26T22:50:58Z TRACE lapin::io_loop] wrote 8 bytes
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to Writable
[2020-02-26T22:50:58Z TRACE mio::sys::windows::tcp] scheduling a read
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to Readable | Writable
[2020-02-26T22:50:58Z ERROR lapin::io_loop] error reading: IOError(Os { code: 10057, kind: NotConnected, message: "A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied." })
[2020-02-26T22:50:58Z ERROR lapin::connection] Connection error

Ok, I think I know how to « fix » this. It will remove the hang but your
program still won’t work though.
It seems that mio tells us that the tcp connection is connected, writable
and readable, we then « successfully » write 11 bytes (or so mio tells us)
and then hit this error when reading: not connected, which means we were
never connected in the first place and the write failed, I guess
On Wed 26 Feb 2020 at 23:56, ajnewlands notifications@github.com wrote:

redoing the test with lapin 0.30.1 looks similar:
Running target\debug\lapin_test.exe
[2020-02-26T22:50:58Z TRACE mio::poll] registering with poller
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] register Token(1)
Readable | Writable
[2020-02-26T22:50:58Z TRACE mio::sys::windows::tcp] scheduling a connect
[2020-02-26T22:50:58Z DEBUG lapin::channels] create channel with id 0
[2020-02-26T22:50:58Z TRACE lapin::connection] connection send_frame;
channel_id=0
[2020-02-26T22:50:58Z TRACE lapin::connection] connection set readable
[2020-02-26T22:50:58Z TRACE mio::poll] registering with poller
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] reregister
Token(1) Readable | Writable
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to
(empty)
[2020-02-26T22:50:58Z TRACE mio::sys::windows::tcp] scheduling a read
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to
Readable
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to
Readable | Writable
[2020-02-26T22:50:58Z TRACE mio::poll] registering with poller
[2020-02-26T22:50:58Z TRACE mio::poll] registering with poller
[2020-02-26T22:50:58Z TRACE lapin::io_loop] io_loop run
[2020-02-26T22:50:58Z TRACE lapin::io_loop] io_loop poll
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] select;
timeout=Some(0ns)
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] polling IOCP
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] returning
[2020-02-26T22:50:58Z TRACE lapin::io_loop] io_loop poll done
[2020-02-26T22:50:58Z TRACE lapin::io_loop] io_loop do_run; can_read=true,
can_write=true, has_data=true
[2020-02-26T22:50:58Z TRACE lapin::io_loop] will write to buffer:
ProtocolHeader
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to
Readable
[2020-02-26T22:50:58Z TRACE mio::sys::windows::tcp] scheduling a write of
8 bytes
[2020-02-26T22:50:58Z TRACE mio::sys::windows::tcp] write error: A request
to send or receive data was disallowed because the socket is not connected
and (when sending on a datagram socket using a sendto call) no address was
supplied. (os error 10057)
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to
Readable | Writable
[2020-02-26T22:50:58Z TRACE lapin::io_loop] wrote 8 bytes
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to
Writable
[2020-02-26T22:50:58Z TRACE mio::sys::windows::tcp] scheduling a read
[2020-02-26T22:50:58Z TRACE mio::sys::windows::selector] set readiness to
Readable | Writable
[2020-02-26T22:50:58Z ERROR lapin::io_loop] error reading: IOError(Os {
code: 10057, kind: NotConnected, message: "A request to send or receive
data was disallowed because the socket is not connected and (when sending
on a datagram socket using a sendto call) no address was supplied." })
[2020-02-26T22:50:58Z ERROR lapin::connection] Connection error
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/sozu-proxy/lapin/issues/216?email_source=notifications&email_token=AABWNXVJKBZQO6DY7C6WIXLRE3XQZA5CNFSM4JLAN3P2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCG2WQ#issuecomment-591687002,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABWNXUDWB3BWAZ3OGRURNDRE3XQZANCNFSM4JLAN3PQ
.

Can you retry with 0.32?

v0.32 is much better; the call returns and hits the outer match statement as intended, rather than hanging. Thank you for taking the time to fix this.
[2020-02-27T10:39:44Z ERROR lapin::io_loop] error reading: IOError(Os { code: 10057, kind: NotConnected, message: "A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied." })
Connection failed: IOError(Os { code: 10057, kind: NotConnected, message: "A request to send or receive data was disallowed because the socket is not connected and (when sending on a datagram socket using a sendto call) no address was supplied." })
[2020-02-27T10:39:44Z ERROR lapin::connection] Connection error

authors: Keruspe ajnewlands andrewbanchich

repo: sozu-proxy/lapin


text:
Новый инструмент. Yes, плазменный резак

Добавляет новый инструмент - плазменный резак, используемый для уничтожения конструкций, самозащиты, и взлома шкафчиков(для синдиката) в будущем я сделаю версию синдиката, которая покупается в аплинке.

Для разбора вещей есть RCD. А для взлома шкафчиков лучше было бы написать код отдельный.

Для разбора вещей есть RCD. А для взлома шкафчиков лучше было бы написать код отдельный.

Делался плазменный резак как раз таки как обрезанная версия RCD, потому что РСУ далеко не всем доступна, да и количество зарядов маленькое.
А писать отдельный скрипт для взлома я не видел смысла, да, можно сделать через ивенты, но функционал будет один, и проще будет при нажатии на объект просто проверять на наличие замка, и удалять его.

Отправь это в офф, там лучше отсмотрят код, но сейчас оно даже не билдится.

Угу, со всем разберусь, доделаю, и отправлю.

source: gharchive/pull-request

authors: Abobadadada LarryRussian Morb0

license: MIT

license_type: permissive

license_source: github-api


text:
Toggle lights command keeps resetting itself

Description
It's quite annoying when you gotta see some administrative shit but gotta turn it back on every 1 or 2 minues
Reproduction

be admin
turn on toggle lights command
wait 1 to 3 minutes
???
profit

I think it's something to do with player-specific state handling or the likes as it doesn't seem to happen locally but happens frequently on live.

Ive never experienced this.

https://github.com/space-wizards/space-station-14/pull/15053

source: gharchive/issue

authors: DrSmugleaf IProduceWidgets Mirino97 metalgearsloth


text:
Device linking needs prediction

Title, flipping levers / opening linked doors feels bad.

a lot/all packet handling is serverside so this would be big

New to networking in SS, so I'll give this a go to figure it out.
What I've gathered so far:

Server/Client/Shared folders determine what code runs in which compilations
Components/fields are replicated either manually (gotta figure out how), or with [AutoGenerateComponentState]/ComponentHandleState Event per Tick() (oh no!?).

So imma try move InvokePort() and whatever it calls into Shared and auto replicate DeviceLinkSinkComponent
as a starting point, then manually replicate the fields OnActivate() once that works (if I got this right...).

Read like all existing net replication code, made hundreds of lines of changes before noticing I forgor to build
the new branch to begin with so LSP was broken and I rage quit.
If another newer person wants to take a shot at this, feel free but not obligated to hmu for a team up.

authors: Bixkitts deltanedas metalgearsloth


text:
Melee refactor

Goals:

prediction
fix the attack effects jank (e.g. xenos) and kill effectsystem
toggle precision as an action
Fadeout for the red hit marker rather than on / off
thrust / swing per weapon (which I think we have anyway)
Fix the code being jank so it's easier to make changes
windup?

Requires https://github.com/space-wizards/space-station-14/pull/8475 because I want predicted component changes.

Requires https://github.com/space-wizards/space-station-14/pull/8475 because I want predicted component changes.

if the requirement is the reason the PR was closed, that should hopefully be fixed soon, unless there's some issues with the PR,

Requires #8475 because I want predicted component changes.

if the requirement is the reason the PR was closed, that should hopefully be fixed soon, unless there's some issues with the PR,

I mainly need predicted component changes on client for active melee weapon accumulators; if the PR doesn't fix my issue I can just find a workaround.

authors: ElectroJr metalgearsloth


text:
add oily oaf drink

About the PR
mix 2u manly dorf and 1u soda water to get 3u of oily oaf
ROCK AND STONE FOREVER!
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog
:cl:

add: Added the Oily Oaf drink, mix manly dorf and soda water to get it.

I think changing the full sprite of the manly dorf and its taste description would be better

authors: AJCM-git deltanedas


text:
Swap the advanced tool borg modules omnitool for jaws and a power drill

About the PR
The Engineering Cyborg Advanced Tool Module no longer has an omnitool, but instead jaws of life and a power drill, with the network configurator being swapped for a multitool.
Why / Balance
The omnitool is a pain to use since you have to spam Z to cycle to the correct tool, with this being much easier to use. Also, this way the borg keeps a blunt weapon for simplemobs, etc. with the jaws. Which it loses since the module loses its toolbar, and the welder is a much worse blunt weapon.
Media
Not Neccesary.
Requirements

[X] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.

Changelog

:cl: BramvanZijp

tweak: The Engineering Cyborg's Advanced Tool Module now has jaws of life and a power drill instead of an omnitool, with a multitool replacing the network configurator.

Jaws let it open bolted doors. Probably don't want that.

i hate omnitool good pr

The omnitool is a pain to use since you have to spam Z to cycle to the correct tool, with this being much easier to use.

I still think this is the wrong approach to the problem. If the problem is with the omnitool, fix the omnitool instead of removing it from the borg module.

Also, this way the borg keeps a blunt weapon for simplemobs, etc. with the jaws. Which it loses since the module loses its toolbar, and the welder is a much worse blunt weapon.

The module is not meant for combat so this is irrelevant.

Omnitool is a pain to use, this will be a really nice change until the omni gets reworked or modified to be less annoying to use,

Should be fine 👍
Thank you for your contribution.

authors: 0x6273 BramvanZijp IProduceWidgets Radezolid deltanedas slarticodefast


text:
Allow gas to escape from burning things and add gas emitting candles.

About the PR

Now flammable things can emit gases while they burn.
also adds gas emitting candles.

Why / Balance

Slow push toward miner removal?
A crate of air gas candles can be ordered from cargo for 2500 spesos and provides 32000 moles of 3-nitrogen/1-oxygen. The catch, is you have to burn the candles, collect the gas, and handle the hot temperatures they produce. These are the only available candles to players.
The candles added emit roughly 1500 mol per candle if all the gas is successfully retained. The exact amount produced depends on temperature/pressure regulation.
The flammable changes probably wont even be noticed by players. You still die, and the damage from actually burning has not changed. The only difference is you will no longer become the surface of the sun hot from being briefly on fire. This might lead to less ashings as high temperature (which are very hard to alleviate in game) also cause heat damage.
Technical details

I changed the logic of how the flammable component handled increasing heat. Previously it was just additive and lead to absurd temperatures approaching - or surpassing - the surface of the sun in a matter of minutes. Now that doesn't happen.
I added a limit to the temperature that a burning entity will increase to. This limit can be changed, and might be a good idea to do so depending on accelerants splashed or other factors, but I leave that as an exercise for the reader.
Media

Requirements

[x] I have read and am following the Pull Request and Changelog Guidelines.
[x] I have added media to this PR or it does not require an ingame showcase.

Breaking changes

Changelog

:cl:

add: Cargo can now order bargain priced gas candles for the Engineering Department!

Please be aware that our pull request guidelines ask that you split up unrelated refactoring changes (e.g. removing [ViewVariables] for unrelated fields) in a separate PR. This makes reviewing your actual PR easier, reduces merge conflicts, and makes it easier to revert if things go wrong.

In place of RequiresOxygen, perhaps it would generalize better to have an GasMixture? InputGasMix similar to how you define a new GasMixture? EmissiveGasMix. This could help this generalize better to different types of burning things.

Stepping back a bit and considering gameplay design issues: What problem does this solve? If it's about finding a way to supply the station with gas that isn't a miner, isn't this like a super beefed gas canister? Now I can see why you want to make burning the candles require a bit more work. But I see two issues here:

Functionally, candles are still pretty much still just less useful canisters (even canisters have pressure limits)
The source of gas (via these candles) is still cargo, which several folks have objected to in the past

Would it be possible to name the candles something realistic? Like real Oxygen candles used in submarines are sodium chlorate that on burning produce oxygen and salt. For nitrogen it could be ammonium nitrate since it thermally decomposes into nitrogen and water.
A different PR could make it be possible for chemistry to produce them in a way similar to plastic (upon mixing proper reagents it pops out of the beaker). I envision medical trying to keep people alive in a situation where station atmos is fucked and chemists can make these oxygen candles to pressurize the medical area and save the day.
The canisters have the unfortunate tendency to be accidentally emptied when people refill their tanks so a constant supply of oxygen filling a room would be a nice alternative to deal with station wide atmos issues.

Okay, so I got clued into more of this bug with the run away temps when I noticed that the temperatures between the flammable entities and the local atmos weren't equalizing at all. I addressed that, so although this isn't "superconduction" its... conduction lmao.

This is pretty closely related to #319 because it implements temperature as a more interactive atmos mechanic.

Everything said, I think the presently-PR'd heat-addition approach (_temperatureSystem.ChangeHeat(uid, flammable.JoulesPerFirestack * flammable.FireStacks, false, temp);) is the right way to go. Thanks for working on this and your patience while we clean up the last bits.

authors: IProduceWidgets Partmedia daevidos


text:
Adds Plastitanium, Plastitanium glass, Titanium, Titanium Glass, as well as Titanium and Plastitanium Glass shards

About the PR
I was looking around and stumbled upon sprites for Plastitanium, and Titanium stuff. Decided there would be no harm to add em. Right now they're sheets used for nothing, but I do intend to add stuff for them to be used on in the future

:cl:

add: Adds Plastitanium Sheets, Plastitanium Glass Sheets, Titanium Sheets, Titanium Glass Sheets, as well as Titanium and Plastitanium Glass shards.

We don't currently accept prototypes that are not actually used for anything, sorry.

If you added the walls themselves so mappers can make the syndie stuff it'd probably get merged.

Im not sure of the current maintainer stance on new resources, so I cant comment too much on adding more. What i will say is that adding new prototypes with no use and no in-game way of acquiring them almost certainly qualifies bloat content. If anything, the sprites should be removed until decided on whether or not they will be used. The vague promise of "I'll use them soon" doesnt seem to justify their inclusion.

I’m general are they used for anything unique? Or is it just shuttle walls and floors etc?
To add to others, a use for shards is construction of spears, otherwise construction graphs for making shuttle walls or plast whatever walls will do it.

Tests are also failing because you need to create a stack prototype for each new material here:
/Prototypes/Stacks/Materials/


text:
recover from a checkpoint file

Motivation
part of #4090
Changes

add a command line arg --checkpoint-file to specify URI for checkpoint file. the file can be from

an URL (https://)
local file (file://)
the node will download/copy the file to local disk and execute the recovery logic

add a command line arg --restore-layer to specify which layer to restart the mesh

recovery logic include the following steps:

read recovery file
check if the node's most recent ATX is in the checkpoint file. if not, copy its latest ATX and dependencies (prev/positioning ATX,  and the poet proof) from the old db
backup the old database files
create a new database file, save the checkpoint ATXs, accounts and the data for the node's most recent ATX if any
set the effective genesis layer to (restore layer - 1)
resume the app init logic

sqlite recovery table
only allow 1 entry, and records the the restore layer.

ATXs re-gossip
when ATXs are not included in the checkpoint file, the network will re-gossip these ATXs by syncing them from peers as soon as a node recovers the checkpoint data. this is achieved by syncer requesting current epoch ATXs immediately after recovery

gossip handlers
reject data (proposal/ballot/blocks) that are before the restore layer

debug API service
add querying account states at specific layer

admin recover RPC
the only way (i can figure out) to preserve PoST data is to make the node commit suicide (log fatal) after receiving the recover RPC.

checkpoint systest does the following:

submit transactions to spawn account and transfer coins
get accounts nonce/balance
issue checkpoint RPC to every node
check all the returned checkpoint data are the same
issue recovery RPC to every node (node will copy the local checkpoint file to $dataDir/recovery/) and restart
check that all accounts have the same nonce/balance as before the checkpoint
run testSmeshing() the nodes that tests miners are generating proposals
make boostrapper serve the checkpoint data
add two new nodes with --checkpoint=http://bootstrapper-0:80/checkpoint
run testSmeshing on these two nodes

bors try

bors try

bors try

bors try

bors try

bors try

closed for the changes were merged in 3 separate PRs

repo: spacemeshos/go-spacemesh


text:
Update CI to use merge queues instead of bors

Motivation
Bors it seems has finally been discontinued. This updates our CI to work with Github Merge Queues in a similar fashion as it did before when we were using bors:

PRs immediately trigger the jobs in ci.yml and only allow adding to a merge queue if all jobs in this file pass
While in the merge queue jobs in both ci.yml and systest.yml are executed and only of all of them pass the code is merged to the target branch.
Manual execution of system tests now needs to be done via Actions -> System tests -> Run Workflow on the GH homepage

NOTE: merging this requires updating the branch protection rules for develop - see test-merge-queue branch protection rules as a reference.
Changes

a dummy systest workflow is added that is only executed on the PR trigger and always passes

this is needed because systest-status needs to be a requirement for both triggering the merge and successfully completing it

removed bors configuration from ci and systest jobs.

Test Plan
n/a
TODO

[x] Explain motivation or link existing issue(s)
[x] Test changes and document test plan
[x] Update documentation as needed
[x] Update changelog as needed

is it possible to run manual workflow from a fork?
when you add several changes to a queue, do we run systests once or once per item in the queue?

With GH merge groups the system tests would be executed once per group, so if multiple PRs are pending for a merge they would trigger one system test run (assuming there aren't any conflicts for merging all of them at once).

Closed for now in favour of self-hosted bors-ng instance

authors: dshulyak fasmat


text:
BUG: fix graph file name generation for default requirement version

The meaning of requirement equal to "" and null was changed in
b9bdf379e5, but the Javascript code was not updated so graphs won't
load.
Sync the javascript side with Python.
Extend the web tests to run with null and "" requirements, to cover this.

Going to merge soon, as master is broken without this...

repo: spacetelescope/asv

license_source: bigquery


text:
v0.3.1

Fixes PYPI upload.

Coverage remained the same at 70.48% when pulling 23d6a870926ed9ba003c35406f8592989db8d364 on hover2pi:master into 080c248d417f73e5a529554918b7ece0b014151d on spacetelescope:master.

repo: spacetelescope/awesimsoss


text:
NER differences

Could someone explain me the difference between doc.ent_type_ and doc.ents[0].label_ ? Is it the same thing but a different way to get it ? Thanks!

The .label attribute is available on Span objects. ent_type is available on Token objects. So yes, the values should match in an entity.

repo: spacy-io/spaCy

license: mit


text:
[Bug] 방 이름이 너무 길면 방 이름이 X 버튼에 겹침

Summary
It closes #801
사진과 같이 방 이름에 해당하는 부분의 오른쪽 패딩을 X 버튼 크기만큼 더했습니다.
Images or Screenshots

Further Work

Do something...

LGTM

authors: imYourChoi jinhyeonkwon

repo: sparcs-kaist/taxi-front


text:
"I forgot my password" from app not working

I've verified that it works on an iPhone but on Android (Samsung Galaxy S6 Android version 6.0.1) on the Particle app if you click the link "I forgot my password" it seems to open a mobile web page with the message "Looks like you got lost". The menu item from this page doesn't offer a link to retrieve a password and requires a user to know and go to the website to reset a password.
I suspect it is an outdated URL/resource that is not auto directing/updated.

Seconded @idokleinman and thirded by Chris.

authors: bloukingfisher jenesaisdiq

repo: spark/photon-tinker-android


text:
Incompatible native module: serialport

Loaded spark-dev module, got the following in the Incompatible Package window:
Error message: Cannot find module '/Users/leo3/.atom/packages/spark-dev/node_modules/serialport/build/serialport/v1.6.3/Release/atom-shell-v0.22.3-darwin-x64/serialport.node'
Particle menu is blank (I'm guess because Spark Dev 0.0.25 stops loading upon error).
OS: Mac OSX 10.10.5
Hardware: Mac Pro (Mid 2012)
Atom: 1.0.7

Yeah, this is caused by bug in apm. You can solve it by following steps 4 and 5 from Linux instructions

repo: spark/spark-dev


text:
XSL message in a XSLT transform throws a RuntimeError

source = Nokogiri::XML(File.read monograph_filename)
xsl = Nokogiri::XSLT(File.read 'ipm.xsl' )
transformed = xsl.transform(source)

The last line throws a runtime error because the xls file contains a message
<xsl:otherwise>
  <xsl:message>Warning:  Class not handled:  <xsl:value-of select="$vDiv"/></xsl:message>
</xsl:otherwise>

So we get the error
RuntimeError: Warning:  Class not handled:  date lrvdt

Is there a way for me to suppress the warning so I don't get a runtime error?

@higherpixels - Can you provide a working example of this issue? This would save time in trying to reproduce, as well as saving me the embarassment of admitting I have no idea how XSLT works!
Background for this bug-report policy is here:

http://www.nokogiri.org/tutorials/getting_help.html

Thanks!

This should recreate the error
source = Nokogiri::XML(File.read "ipm5547_eng.xml")
xsl = Nokogiri::XSLT(File.read 'ipm.xsl' )
transformed = xsl.transform(source)
http://temp-host.com/download.php?file=nx92xy
http://temp-host.com/download.php?file=cc54gq

Excellent, thanks so much! I've reproduced it and am looking into it.
On Thu, Jan 22, 2015 at 9:57 AM, higherpixels notifications@github.com
wrote:

This should recreate the error
source = Nokogiri::XML(File.read "ipm5547_eng.xml")
xsl = Nokogiri::XSLT(File.read 'ipm.xsl' )
transformed = xsl.transform(source)
http://temp-host.com/download.php?file=nx92xy
http://temp-host.com/download.php?file=cc54gq
—
Reply to this email directly or view it on GitHub
https://github.com/sparklemotion/nokogiri/issues/1217#issuecomment-71032120
.

OK, so I've done a bit of research, and it appears as though using xsl:message is expected to raise an error of some sort. My sources:

https://msdn.microsoft.com/en-us/library/ms256441(v=vs.110).aspx
http://www.devguru.com/technologies/xslt/8437

The second reference notably mentions "The xsl:message element is primarily used to report errors by displaying a text message".
What is the behavior that you expect in this case?

I'm seeing the same issue.

I came across this issue because I was debugging an xsl template and had read a couple of articles that recommended the use of xsl:message to provide helpful feedback in figuring out the order and selection of templates.
To address @flavorjones question in the comment above, based on what I read I would expect the behavior to be displaying the message content on the console or returned by the XSLT.transform method somehow.
Reference: "The xsl:message element is optional. Processors are not required to support it. However most do, and usually they do so by printing messages on the console."
http://www.ibm.com/developerworks/library/x-tipxslmsg/

I'm affected by this as well, and it would be very useful to have the choice of what to do, and here are two possible ways the API could be changed to support it:
xslt = Nokogiri::XSLT::Stylesheet.parse_stylesheet_doc xslt_file
output = xslt.transform(input) do |message|
  puts message
  #raise an exception if you want, but if you don't we just keep processing
end

or
xslt = Nokogiri::XSLT::Stylesheet.parse_stylesheet_doc xslt_file
xslt.handle_messages  do |message|
  puts message
  #raise an exception if you want, but if you don't we just keep processing
end
output = xslt.transform(input)

Alternatively, instead of raising exceptions directly, the block could take an second parameter
xslt = Nokogiri::XSLT::Stylesheet.parse_stylesheet_doc xslt_file
xslt.handle_messages  do |message, transform|
  puts message
  transform.continue
end
output = xslt.transform(input)

@frivoal What would you think about adding the error to the Document#errors array, if the xsl:message does not declare terminate="yes"?

@flavorjones Just to be clear on what you're proposing:

it does not declare terminate="yes" you would just continue processing and store the error in Document#errors
it does declare terminate="yes", abort imediately (and store the message in Document#errors ? and print the message on stderr?)

Yes, this would work. Transformations that are supposed to continue would continue, and those that are supposed to stop would stop.
I think it would probably be better to put the messages in something like document#messages (at least when terminate="yes" is not declared) since these are not actually errors, and may not even be warnings at all, but that's less important. This would be a question of API intuitiveness, not of capabilities or correctness.
Another small limitation of that design would be when the non-terminating messages are meant to give progress reports in a long running task, just storing them in Document#errors and letting the caller read them at the end defeats the purpose. This is secondary, since the processing would still occur normally, but the messages would be less useful than could be.
That said, your proposal is actually compatible with mine: the default message handler would do what you said, and you could let users supply their won, using something like a handle_message method on XSLT::Stylesheet, which would take a block, and pass it the message and terminate as a boolean, and allowing it to signal somehow if it wants processing to continue or stop. I guess that would be ideal, getting the best of both worlds.

A brief investigation of libxlst and its xsltMessage function leads me to believe that it's not currently possible to filter xsl:message messages differently from other parse errors and warnings.
@nwellnhof if you have a moment, please let me know if I'm missing something.

And if that's the case, then I can update Nokogiri's code to only raise an exception if the parsing failed (i.e., xsltApplyStylesheet returning NULL), and otherwise we can stash all of the warnings and messages in an accessor.

A brief investigation of libxlst and its xsltMessage function leads me to believe that it's not currently possible to filter xsl:message messages differently from other parse errors and warnings.

That's correct. libxslt's error handling is extremely limited. It never implemented what libxml2 calls "structured" error handling.

Thank you! I'll schedule some time to make Nokogiri's behavior a bit more robust, then.

authors: flavorjones frivoal higherpixels kmeister2000 mejackreed nwellnhof

repo: sparklemotion/nokogiri


text:
Update to latest htmlunit neko

What problem is this PR intended to solve?
This is a WIP for #2565. Feedback and help welcome.

I had a look at this but it's probably a bit too involved for my xerces and nokogiri/htmlunit knowledge.
Was your thinking to essentially have two xerces versions eventually packaged? (Retain the mainline org.apache one as well as the shaded, refactored/simplified one inside htmlunit)?
It looks like nokogiri seems to try and reuse the same xerces xonfiguration for its own direct stuff as well as for use by htmlunit so seemed to require a change to the configuration approach.

authors: chadlwilson flavorjones


text:
Is there any current issues to be worked on the sparsehash / densehash structures?

Hi there,
I checked this code description and in 2005 it informed "It would be nice to rework this C class to follow the C++ API as closely as possible (eg have a set_deleted_key() instead of using a #define like this code does now).  I believe the code compiles and runs, if anybody is interested in using it now, but it's subject to major change in the future, as people work on it. Craig Silverstein"
I would like to check if this set_deleted_key() issue was resolved, else what are the current issues.
(I am looking for a theme to work in software engineering monography.)
thanks!

Hi,
most of the current issues are present here on Github in the issue-tracker :-) Some of them have been addressed in this branch which needs to be merged:
https://github.com/sparsehash/sparsehash/tree/issue-fixes
There's also a fork here:
https://github.com/sparsehash/sparsehash-c11
which aims to remove all the type traits and conditional build logic that isn't required now that C++11 is widely available. Ideally, it needs a better build process (CMake or plain old Makefile).
Patches and contributions are more than welcome. This project has been static for some time :-)
Cheers,
Donovan.

authors: donovanhide pyrobit

repo: sparsehash/sparsehash


text:
No module named 'scheduled_tasks'

Something is still a miss. Where does 'scheduled_tasks' come from? I see you import it everywere but ...
Traceback (most recent call last):
File "D:\02_Stock_Analysis\Stocksera-spartan737\Stocksera\scheduled_tasks\main.py", line 2, in
import scheduled_tasks.get_reddit_trending_stocks.scrape_reddit as scrape_reddit
ModuleNotFoundError: No module named 'scheduled_tasks'

Scheduled_tasks is a folder name found in the main directory

Hi. I have rewrote the pipeline of the entire scheduled_tasks section. You only need to edit tasks_to_run.py in the main parent directory directly. I have also removed the section for due diligence, as I have decided to focus on other sections of the application first. Please clone the latest version of the repo


text:
Tactical graphics

milsymbol dosen't draw tactical graphics and except a few point symbols that are referenced in other appendixes. If I would implement tactical graphics it would probably be done in another library, so that it will be easy to choose if you want to import it or not.
I have for quite some time been collecting ideas for how I would be able to create tactical graphics, and unfortunately my time might be too limited to implement the whole tactical graphics appendix, but I have some ideas that I might try out.
My idea is to start out with some, maybe five or ten, different graphics and see how it works out. If anyone has any input, wishes, questions, please post them here and I'll try to answer. (And if you need this done faster, you can always take me in as a consultant.)

If you want inspiration, I know of two open source libraries that can draw control measures:

milsymb-js / milsymb-java
MilSymb

I have experimented with milsymb-java/js. The interface is relatively straight forward and it can generate KML and GeoJSON. I have not looked at the implementation, but I know that the point symbology is  font based.
Usually it only makes sense to draw control measures on a map, so the library should generate output that can be used with  OpenLayers and Leaflet. GeoJson is one option, but it does not support curved lines. milsymb-js/java solves this by converting curves to polylines. This works, but it requires many line segments to look good.
SVG will look better, but you'll probably need to adjust the SVG output every time the map is zoomed in or out. Canvas is also an option.

Thank you for your input. My idea at the moment is SVG, I have looked at the d3 layers examples that exists for both openlayers and Leaflet, so it's something like that I have in mind, but I keep thinking about it and see if I find some time to make some initial tests.

:+1:

The initial plan is to support point symbols for tactical graphics. I'm adding functionality to inject new SIDC (so that you only will have tactical symbols if you want them and not otherwise) at the moment, and it will also require a rewrite of how the text labels are placed, but I got an idea for how to solv that.

I have now added support injecting support for new SIDC and for non standard bounding boxes, this is the first step to supporting point graphics from tactical symbols. Next step is to be able to add new icon building blocks, and to be able to override text placements.

All except two tactical points are now implemented, please have a look and give feedback. Since the size of the symbols isn't specified in the standard I had to improvise some.
http://www.spatialillusions.com/milsymbol-dev/docs/milsymbol-2525c-tactical-points-svg.html
Does this work for you @szechyjs ?

Impressive work @spatialillusions! I'll have a look at them.

Implementing something for graphics other than points will be done here:
https://github.com/spatialillusions/milgraphics

authors: kjellmf spatialillusions szechyjs

repo: spatialillusions/milsymbol


text:
WIP: UNR-1545: Add documentation for offloading and actor groups

Contributions: We are not currently taking public contributions - see our contributions policy. However, we are accepting issues and we do want your feedback.

Description
Documentation of offloading includes additions to the GDK concepts doc, a new reference page which covers the newly added SpatialStatics, best practices, and a description of the usage of offloading in the example project.
Primary reviewers
@ElleEss @mattyoung-improbable

Closing this because there's another PR with the most up to date draft.

repo: spatialos/UnrealGDK


text:
Accessor attribute doesn't log if it not in $appends array.

Is it intended behavior? If so, I think, it's good to point out this moment in documentation.
Update:
I foregt to say, that I use 1.16.0 version on laravel 5.4
Update 2:
Accessor attribute get equal value in "attributes" and "old" arrays. So, as I can see, I can't use dynamic attributes to log changes. Where I can find contribution process, maybe I can implement this feature.

An accessor attribute isn't an attribute like all the others. And primary an accessor attribute doesn't have an old and dirty state.

Thanks for clarifying. Maybe I can be wrong, but in $changes property of Activity class contains a serialized model (If I use LogsActivity trait). So, if I append to a serialized model dynamic attribute and in next update it changes log will contain changes. I think this is crucial feature and worth noting in documentation.

Sorry for link to your concurrent, but it will be cool if this package has something like this.

That's out of scope for this package, implement that in your own app.

authors: Gummibeer fotonmoton freekmurze

repo: spatie/laravel-activitylog


text:
add php 8.1 support to composer.json

fixes #195

Please pull this PR in

Why is this taking so long?

I believe this is unnecessary as the ^8.0 constraint means that 8.1 is also included (as is 8.2, and so on).
@freekmurze Please correct me if I'm wrong, but I believe this PR can be closed without merging as the referenced issue (#195) is not related to this directly.

I believe this is unnecessary as the ^8.0 constraint means that 8.1 is also included (as is 8.2, and so on).
@freekmurze Please correct me if I'm wrong, but I believe this PR can be closed without merging as the referenced issue (#195) is not related to this directly.

My comment is after testing en composer does not accept 8.1 with this setting.

authors: darviscommerce devinfd lintaba patinthehat

repo: spatie/pdf-to-image


text:
Ray not sending integers

Describe the bug:
I'm using Ray in WordPress and framework-agnostic PHP projects and for some reason integers don't show up in Ray app.
Versions:
Ray version:  1.14.5
PHP version: 7.4.13
Ray WP plugin: 1.2.4
To Reproduce:
Try sending an integer value, i.e.:
ray(25);

Desktop:

OS: macOS
Version 10.13.6

I'm also noticing this in Laravel

Posting this as a potential workaround for people before this gets fixed. It's simple but took a little too long to occur to me to do this. Just typecast any integers to a string when outputting in the debugger.
ray((string) 25);

Can confirm I'm also seeing this on Drupal.
PHP Library version: 1.21.2
Ray client: 1.14.5
PHP: 8.0.3
MacOS

Also having this issue, even when multiple arguments are fed to the ray() function, as soon as an integer is include all these are not showing up.

Hapenned to me as well

+1. Using Laravel + Linux (ubuntu)
Terminal Log:
TypeError: e.includes is not a function
    at D (/tmp/.mount_Ray-1.UH5UqJ/resources/app.asar/dist/main.js:367:19406)
    at /tmp/.mount_Ray-1.UH5UqJ/resources/app.asar/dist/main.js:367:18468
    at Array.map (<anonymous>)
    at /tmp/.mount_Ray-1.UH5UqJ/resources/app.asar/dist/main.js:367:18444
    at Array.map (<anonymous>)
    at /tmp/.mount_Ray-1.UH5UqJ/resources/app.asar/dist/main.js:367:18198
    at s.handle_request (/tmp/.mount_Ray-1.UH5UqJ/resources/app.asar/dist/main.js:156:784)
    at s (/tmp/.mount_Ray-1.UH5UqJ/resources/app.asar/dist/main.js:149:883)
    at u.dispatch (/tmp/.mount_Ray-1.UH5UqJ/resources/app.asar/dist/main.js:149:905)
    at s.handle_request (/tmp/.mount_Ray-1.UH5UqJ/resources/app.asar/dist/main.js:156:784)

Have same issue with M1 mac. Until lates update everything works just fine.

Thanks for the reports and especially thanks too @vicenterusso for the logs which gave me an idea about what could be causing the bug :)
This has been fixed and will be included in the 1.14.6 patch version (releasing now).

authors: AdrianMrn Muffinman SpencerCloud ajimatahari lorlab nlemsieh nnerijuss tomcoonen vicenterusso

repo: spatie/ray


text:
СУЩЕСТВУЕТ ИНТЕРЕСНЕНЬКИЙ БАГ)

https://github.com/spbu-math-cs/GiveGift-frontend/assets/57632427/54db6c39-79fa-44c3-bfb5-bf4e9f8d05b3
ДУМАЮ ЧТО НАДО ПОФИКСИТЬ)

https://github.com/spbu-math-cs/GiveGift-frontend/assets/57632427/b9fe8f3b-a47f-4aec-b09a-8961e9f0ef21

repo: spbu-math-cs/GiveGift-frontend


text:
DNS: CNAME, NS or Load Balancer

We have a few options when it comes to achieving a human-readable domain name for our API endpoint. Here are the first 3 that come to mind:

CNAME - Points from UoB subdomain to our own domain
NS - We host our own nameservers and have UoB delegate that subdomain
Load Balancer - We have a static IP address pointing to an Elastic IP (reserved for us by AWS) that assigns to a NAT Gateway that links to a subnet where the lambda is hosted inside the VPC.

We are not deploying to production so can close this

repo: spe-uob/HealthcareLake


text:
Take into account (x-)nullable when validating defaults

Fixes # 1462.
CC: @nielsbox

Pull Request Test Coverage Report for Build 1853825683

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

Totals

Change from base Build 1819970533:
0.002%

Covered Lines:
2842

Relevant Lines:
2928

💛  - Coveralls

authors: RobbeSneyders coveralls

repo: spec-first/connexion


text:
Identify TR specs that are too far behind their Editor's Drafts

Given https://github.com/w3c/browser-specs/blob/main/index.json, for specs with organization == W3C, the tool can fetch the two URLs available at either {series.releaseUrl, series.nightlyUrl} or {release.url, nightly.url}, and compare their publication dates (<time class="dt-updated">). If they're different, the SLI is the age of the release, and the SLO could be 4 weeks.
IETF specs have a similar feature using <time class="published">.

Sounds good in general although I would be wary of a metric that encourages republishing unchanged drafts with a new date just to keep the metric happy.
Also depending on the document status:

updating a CR Snapshot with another CR Snapshot requires a new round of horizontal review, a transition request, a mandatory one-week period for related groups to object, a once-weekly meeting to review the transition request and then scheduling publication. That will never happen in 4 weeks and 3 months is a more realistic minimum, assuming horizontal re-review starts on the day the previous CRS was published.
updating a Rec with an edited Rec with proposed corrections or amendments requires a 4-week AC review plus a couple of weeks to review the responses, giving an absolute minimum of 6 weeks even if the process is started the same day the previous Recommendation is published, with no time for public review.

authors: jyasskin svgeesus

repo: speced/spec-maintenance


text:
feat(revit/objects): new rebar class and sending rebar from revit

see details in https://www.notion.so/speckle/Rebar-Support-in-Revit-Revit-workflow-c1922ee7c1d0450184b16221c6b939b6?pvs=4

Sending rebar from Revit is implemented. A separate ticket is created for receiving as it is more complicated.

authors: bimgeek paloknapo

repo: specklesystems/speckle-sharp


text:
Add export without displayValue.

Currently Speckle uses host applications to calculate meshes.
First, there can be scenarios when people want to extract only alpha-numerical data.
Second, it is very inconvenient to write a code specifically for each software and keep it updated.
Third, it is a huge time waist and depends on application quality. E.g. Revit sucks.
What we are currently after (and hope it will be implemented in the future in Speckle):

we extend geometry kit to cover main surface types from OpenCascade
save data as collections of faces (surfaces with edge curves; curves are fully covered already)
write a single post-process to calculate Breps and mesh them (if necessary) based on Speckle geometry kit using whole power of OpenCascade.

Currently in Revit Convertor the method GetElementDisplayValue() is implemented in about 30(!) places. I haven't check other connectors. I presume it could be optimized to quickly turn it off.

Hi @nickger, we can look at implementing this as a send setting in Revit (and maybe other host apps where this would make sense), though it can be a rather counterintuitive for the majority of specklers.
Regarding meshing breps with opencascade: this is something we've never tried before, but it opens a slippery slope. We currently benefit from not having to mesh things client side/server side and being able to instantly display them!
I'm going to close this issue, but the first idea - send without display values - is captured in our backlog!

Well, currently you mesh things on client's side, moreover, in the host application during sending. This is unnecessary load at least, and for me as developer - huge head ache: if I want to do further geometry processing, I must implement it on client's side as well. Think of exporting BReps as a third export option.

perhaps we need to understand what you're after better: for us meshing things client side saves a lot of headaches. happy to hear what you're building!

authors: didimitrie nickger


text:
fix(objects): Added fix for sketchup blocks using dynamic blockDefinition prop

SketchUp sends every detached property with the prefixed @.
This causes issues with the transformedGeometry computed property of blocks, which uses BlockInstance.blockDefinition and BlockDefinition.geometry properties.
Both of these properties, on sketchup objects, would end up being deserialised as dynamic props, which would throw null reference errors.
This PR addresses this issue, while also adding warnings on the code to inform us in the future about this.

@JR-Morgan I'm re-requesting your review, but mostly to open the conversation of how cringy this is codewise... and that maybe we should not ever merge this 😅

Closing as we decided to fix this on the SketchUp side.

authors: AlanRynne teocomi


text:
Direct contributors to the current CONTRIBUTING.md

fixes # no issue logged, this is a simple spot suggestion

[X] I have read the Contribution Guidelines
[ ] I have commented on the issue above and discussed the intended changes
[ ] A maintainer has signed off on the changes and the issue was assigned to me
[ ] All newly added code is adequately covered by tests
[ ] All existing tests are still running without errors
[X] The documentation was modified to reflect the changes OR no documentation changes are required.

Changes
The current PR template contains a link to CONTRIBUTING.md. However, when clicking on it, Github redirects to a 404:

In short, the URL is missing /blob/main. This PR fixes the issue, and so contributors don't have to look too deeply.

Merged! Thank you for your contribution. Much appreciated! 👍

authors: patriksvensson tonycknight


text:
chore(main): release 0.0.1

:robot: I have created a release beep boop
0.0.1 (2024-05-01)
Bug Fixes

add production stage to Dockerfile (427a05c)
add ReconcileFlaggedCVERule and update global manifest (c2b954c)
group version, namespace, vuln counter (62fbc75)
helm chart nil pointer dereference for SA (42f47f3)
include all src code in Dockerfile build context (525b3e7)
rename charts to chart (96a1825)
typo (eae9f24)
update v1 to v1alpha1 and CRD (9a50145)
v1 to v1alpha1 (7cf2316)

Other

add extra files (d4bfa93)
add github workflows (be53017)
deps: update actions/checkout digest to 0ad4b8f (#19) (9f389b8)
deps: update azure/setup-helm digest to fe7b79c (#20) (deee20d)
deps: update codecov/codecov-action digest to 5ecb98a (#21) (53760d4)
release 0.0.1 (27d0852)
release 0.0.1 (5fa1a9b)
upgrade controller-gen (eb6ab5a)
upgrade github.com/docker/docker (7d6417c)
upgrade github.com/kubescape/storage (358cb4f)
upgrade golang.org/x/net (4488f72)
upgrade to go1.22 (c2c1bf8)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/spectrocloud-labs/validator-plugin-kubescape/releases/tag/v0.0.1 :sunflower:


text:
How to use dynamic mixing with multi-gpu training in LibriMix recipe?

Hi everyone,
I am trying to run sepformer with dynamic mixing on my own dataset. I created a dummy .csv file with 20000 rows, and set batch_size=2 in hparam. But when I trained on 8 gpus using the following command, the iteration of each epoch was still 10000.
srun -p gpu --gres=gpu:8 --cpus-per-task=40  python -m torch.distributed.launch --nproc_per_node=8 train.py hparams/sepformer-lrs2mix.yaml --distributed_launch --distributed_backend='nccl'

I noticed that the dynamic_mix_data_prep_librimix function in recipes/LibriMix/separation/dynamic_mixing.py returns a Dataloader, thus I specified sampler=DistributedSampler(dataset), then I got 1250 iterations per epoch. All GPUs were running, but the convergence was really slow like only one GPU was working. I added logger.info(f"rank{self.rank}, ids:{batch.id}") in fit_batch function, but only rank0 outputs.
Then I tried to set lr=0.0012, 8 times larger than the default, but the model failed to converge this time.
I am new to the torch DDP, and the official google colab multi-gpu tutorial is a bit brief, so I'd like to ask how to use dynamic mixing with multi-gpu, should I modify the optimizer or other components? Thanks a lot!

Can you set batchsize=1 per gpu as well?

Hi @ycemsubakan , I try batchsize=1 and gpu=8, which leads to 2500 iterations per epoch. After 80 epochs si-snr is stable at 12.3, while single gpu gets 16.8.
DDP seems to be working fine, except for abnormal memory usage, it should be less than 10G each GPU.

I am not sure why you are getting much lower performance. I only tried with 2 gpus however. Did you try that?
How much memory is used with single gpu? Can you try to see that?
The explanation for this could be bursts due to longer sequences. Can you try limiting the sequence length to see if you get this behavior even when you limit the length of training sequences?

For all the experiments, I limited the length of training sequences to less than 3s (16k x 3  = 48000).
Single gpu and batchsize=1 will use 10519MB memory.
I will try with 2 gpus and report the result soon. Thank you very much!

Hi @ycemsubakan .
Yesterday I decided to train sepformer on WSJ0-2mix dataset using default hyerparameters. Here are the current si-snr on eval set , after 20 hours training:

No Augment
Dynamic Mixing

1 GPU
16.7
17.1

8 GPUs
17.1
16.9

SB baseline
20.4
22.4

It is worth pointing out that overfitting has already occurred in multi-gpu training, so there should be no better results. The results may indicate that 8 GPU training will hurt the performance badly.

Hi @caixy97,
Here's a training curve on WSJ0-2Mix with DM, with 1 gpu:
epoch: 1, lr: 1.50e-04 - train si-snr: -5.43e+00 - valid si-snr: -7.11e+00
epoch: 2, lr: 1.50e-04 - train si-snr: -8.40e+00 - valid si-snr: -9.21e+00
epoch: 3, lr: 1.50e-04 - train si-snr: -1.02e+01 - valid si-snr: -1.10e+01
epoch: 4, lr: 1.50e-04 - train si-snr: -1.21e+01 - valid si-snr: -1.26e+01
epoch: 5, lr: 1.50e-04 - train si-snr: -1.35e+01 - valid si-snr: -1.36e+01
epoch: 6, lr: 1.50e-04 - train si-snr: -1.45e+01 - valid si-snr: -1.38e+01
epoch: 7, lr: 1.50e-04 - train si-snr: -1.52e+01 - valid si-snr: -1.50e+01
epoch: 8, lr: 1.50e-04 - train si-snr: -1.55e+01 - valid si-snr: -1.53e+01
epoch: 9, lr: 1.50e-04 - train si-snr: -1.57e+01 - valid si-snr: -1.54e+01
epoch: 10, lr: 1.50e-04 - train si-snr: -1.62e+01 - valid si-snr: -1.59e+01
epoch: 11, lr: 1.50e-04 - train si-snr: -1.66e+01 - valid si-snr: -1.63e+01
epoch: 12, lr: 1.50e-04 - train si-snr: -1.69e+01 - valid si-snr: -1.65e+01
epoch: 13, lr: 1.50e-04 - train si-snr: -1.72e+01 - valid si-snr: -1.66e+01
epoch: 14, lr: 1.50e-04 - train si-snr: -1.74e+01 - valid si-snr: -1.69e+01
epoch: 15, lr: 1.50e-04 - train si-snr: -1.77e+01 - valid si-snr: -1.71e+01
epoch: 16, lr: 1.50e-04 - train si-snr: -1.77e+01 - valid si-snr: -1.72e+01
epoch: 17, lr: 1.50e-04 - train si-snr: -1.78e+01 - valid si-snr: -1.75e+01
epoch: 18, lr: 1.50e-04 - train si-snr: -1.79e+01 - valid si-snr: -1.76e+01
epoch: 19, lr: 1.50e-04 - train si-snr: -1.82e+01 - valid si-snr: -1.79e+01
epoch: 20, lr: 1.50e-04 - train si-snr: -1.84e+01 - valid si-snr: -1.77e+01
epoch: 21, lr: 1.50e-04 - train si-snr: -1.85e+01 - valid si-snr: -1.79e+01
epoch: 22, lr: 1.50e-04 - train si-snr: -1.87e+01 - valid si-snr: -1.81e+01
epoch: 23, lr: 1.50e-04 - train si-snr: -1.88e+01 - valid si-snr: -1.82e+01
epoch: 24, lr: 1.50e-04 - train si-snr: -1.89e+01 - valid si-snr: -1.85e+01
epoch: 25, lr: 1.50e-04 - train si-snr: -1.91e+01 - valid si-snr: -1.85e+01
epoch: 26, lr: 1.50e-04 - train si-snr: -1.89e+01 - valid si-snr: -1.84e+01
epoch: 27, lr: 1.50e-04 - train si-snr: -1.87e+01 - valid si-snr: -1.84e+01
epoch: 28, lr: 1.50e-04 - train si-snr: -1.89e+01 - valid si-snr: -1.87e+01
epoch: 29, lr: 1.50e-04 - train si-snr: -1.92e+01 - valid si-snr: -1.89e+01
epoch: 30, lr: 1.50e-04 - train si-snr: -1.93e+01 - valid si-snr: -1.89e+01
epoch: 31, lr: 1.50e-04 - train si-snr: -1.95e+01 - valid si-snr: -1.88e+01
epoch: 32, lr: 1.50e-04 - train si-snr: -1.95e+01 - valid si-snr: -1.91e+01
epoch: 33, lr: 1.50e-04 - train si-snr: -1.96e+01 - valid si-snr: -1.90e+01
epoch: 34, lr: 1.50e-04 - train si-snr: -1.95e+01 - valid si-snr: -1.91e+01
epoch: 35, lr: 1.50e-04 - train si-snr: -1.93e+01 - valid si-snr: -1.92e+01
epoch: 36, lr: 1.50e-04 - train si-snr: -1.96e+01 - valid si-snr: -1.93e+01
epoch: 37, lr: 1.50e-04 - train si-snr: -1.97e+01 - valid si-snr: -1.94e+01
epoch: 38, lr: 1.50e-04 - train si-snr: -1.99e+01 - valid si-snr: -1.95e+01
epoch: 39, lr: 1.50e-04 - train si-snr: -1.98e+01 - valid si-snr: -1.95e+01
epoch: 40, lr: 1.50e-04 - train si-snr: -1.99e+01 - valid si-snr: -1.95e+01
epoch: 41, lr: 1.50e-04 - train si-snr: -2.00e+01 - valid si-snr: -1.95e+01
epoch: 42, lr: 1.50e-04 - train si-snr: -2.01e+01 - valid si-snr: -1.96e+01
epoch: 43, lr: 1.50e-04 - train si-snr: -2.02e+01 - valid si-snr: -1.97e+01
epoch: 44, lr: 1.50e-04 - train si-snr: -2.03e+01 - valid si-snr: -1.97e+01
epoch: 45, lr: 1.50e-04 - train si-snr: -2.04e+01 - valid si-snr: -1.98e+01
epoch: 46, lr: 1.50e-04 - train si-snr: -2.04e+01 - valid si-snr: -1.97e+01
epoch: 47, lr: 1.50e-04 - train si-snr: -2.05e+01 - valid si-snr: -1.99e+01
epoch: 48, lr: 1.50e-04 - train si-snr: -2.05e+01 - valid si-snr: -2.00e+01
epoch: 49, lr: 1.50e-04 - train si-snr: -2.00e+01 - valid si-snr: -1.99e+01
epoch: 50, lr: 1.50e-04 - train si-snr: -2.02e+01 - valid si-snr: -2.00e+01
epoch: 51, lr: 1.50e-04 - train si-snr: -2.03e+01 - valid si-snr: -1.99e+01
epoch: 52, lr: 1.50e-04 - train si-snr: -2.04e+01 - valid si-snr: -2.00e+01
epoch: 53, lr: 1.50e-04 - train si-snr: -2.05e+01 - valid si-snr: -2.00e+01
epoch: 54, lr: 1.50e-04 - train si-snr: -2.05e+01 - valid si-snr: -1.98e+01
epoch: 55, lr: 1.50e-04 - train si-snr: -2.02e+01 - valid si-snr: -1.99e+01
epoch: 56, lr: 1.50e-04 - train si-snr: -2.03e+01 - valid si-snr: -2.00e+01
epoch: 57, lr: 1.50e-04 - train si-snr: -2.04e+01 - valid si-snr: -2.01e+01
epoch: 58, lr: 1.50e-04 - train si-snr: -2.05e+01 - valid si-snr: -2.02e+01
epoch: 59, lr: 1.50e-04 - train si-snr: -2.03e+01 - valid si-snr: -2.01e+01
epoch: 60, lr: 1.50e-04 - train si-snr: -2.04e+01 - valid si-snr: -2.01e+01
epoch: 61, lr: 1.50e-04 - train si-snr: -2.05e+01 - valid si-snr: -2.03e+01
epoch: 62, lr: 1.50e-04 - train si-snr: -2.07e+01 - valid si-snr: -2.03e+01
epoch: 63, lr: 1.50e-04 - train si-snr: -2.07e+01 - valid si-snr: -1.99e+01
epoch: 64, lr: 1.50e-04 - train si-snr: -2.08e+01 - valid si-snr: -2.03e+01
epoch: 65, lr: 1.50e-04 - train si-snr: -2.09e+01 - valid si-snr: -2.04e+01
epoch: 66, lr: 1.50e-04 - train si-snr: -2.10e+01 - valid si-snr: -2.04e+01
epoch: 67, lr: 1.50e-04 - train si-snr: -2.05e+01 - valid si-snr: -2.04e+01
epoch: 68, lr: 1.50e-04 - train si-snr: -2.06e+01 - valid si-snr: -2.02e+01
epoch: 69, lr: 1.50e-04 - train si-snr: -2.06e+01 - valid si-snr: -2.04e+01
epoch: 70, lr: 1.50e-04 - train si-snr: -2.07e+01 - valid si-snr: -2.04e+01
epoch: 71, lr: 1.50e-04 - train si-snr: -2.08e+01 - valid si-snr: -2.04e+01
epoch: 72, lr: 1.50e-04 - train si-snr: -2.09e+01 - valid si-snr: -2.05e+01
epoch: 73, lr: 1.50e-04 - train si-snr: -2.10e+01 - valid si-snr: -2.06e+01
epoch: 74, lr: 1.50e-04 - train si-snr: -2.11e+01 - valid si-snr: -2.05e+01
epoch: 75, lr: 1.50e-04 - train si-snr: -2.11e+01 - valid si-snr: -2.04e+01
epoch: 76, lr: 1.50e-04 - train si-snr: -2.11e+01 - valid si-snr: -2.06e+01
epoch: 77, lr: 1.50e-04 - train si-snr: -2.12e+01 - valid si-snr: -2.06e+01
epoch: 78, lr: 1.50e-04 - train si-snr: -2.12e+01 - valid si-snr: -2.05e+01
epoch: 79, lr: 1.50e-04 - train si-snr: -2.13e+01 - valid si-snr: -2.07e+01
epoch: 80, lr: 1.50e-04 - train si-snr: -2.13e+01 - valid si-snr: -2.07e+01
epoch: 81, lr: 1.50e-04 - train si-snr: -2.14e+01 - valid si-snr: -2.08e+01
Epoch loaded: 81 - test si-snr: -2.06e+01
epoch: 82, lr: 1.50e-04 - train si-snr: -2.11e+01 - valid si-snr: -2.07e+01
epoch: 83, lr: 1.50e-04 - train si-snr: -2.09e+01 - valid si-snr: -2.06e+01
epoch: 84, lr: 1.50e-04 - train si-snr: -2.10e+01 - valid si-snr: -2.07e+01
epoch: 85, lr: 1.50e-04 - train si-snr: -2.11e+01 - valid si-snr: -2.08e+01
epoch: 86, lr: 1.50e-04 - train si-snr: -2.09e+01 - valid si-snr: -2.07e+01
epoch: 87, lr: 1.50e-04 - train si-snr: -2.10e+01 - valid si-snr: -2.09e+01
epoch: 88, lr: 1.50e-04 - train si-snr: -2.12e+01 - valid si-snr: -2.09e+01
epoch: 89, lr: 1.50e-04 - train si-snr: -2.12e+01 - valid si-snr: -2.09e+01
epoch: 90, lr: 1.50e-04 - train si-snr: -2.13e+01 - valid si-snr: -2.09e+01
epoch: 91, lr: 1.50e-04 - train si-snr: -2.13e+01 - valid si-snr: -2.09e+01
epoch: 92, lr: 1.50e-04 - train si-snr: -2.14e+01 - valid si-snr: -2.08e+01
epoch: 93, lr: 1.50e-04 - train si-snr: -2.11e+01 - valid si-snr: -2.10e+01
epoch: 94, lr: 1.50e-04 - train si-snr: -2.12e+01 - valid si-snr: -2.09e+01
epoch: 95, lr: 1.50e-04 - train si-snr: -2.13e+01 - valid si-snr: -2.10e+01
epoch: 96, lr: 1.50e-04 - train si-snr: -2.13e+01 - valid si-snr: -2.09e+01
epoch: 97, lr: 1.50e-04 - train si-snr: -2.14e+01 - valid si-snr: -2.10e+01
epoch: 98, lr: 1.50e-04 - train si-snr: -2.14e+01 - valid si-snr: -2.08e+01
epoch: 99, lr: 1.50e-04 - train si-snr: -2.15e+01 - valid si-snr: -2.10e+01
epoch: 100, lr: 1.50e-04 - train si-snr: -2.16e+01 - valid si-snr: -2.10e+01
epoch: 101, lr: 1.50e-04 - train si-snr: -2.16e+01 - valid si-snr: -2.10e+01
epoch: 102, lr: 1.50e-04 - train si-snr: -2.17e+01 - valid si-snr: -2.11e+01
epoch: 103, lr: 1.50e-04 - train si-snr: -2.17e+01 - valid si-snr: -2.11e+01
epoch: 104, lr: 1.50e-04 - train si-snr: -2.17e+01 - valid si-snr: -2.11e+01
epoch: 105, lr: 1.50e-04 - train si-snr: -2.18e+01 - valid si-snr: -2.11e+01
epoch: 106, lr: 1.50e-04 - train si-snr: -2.18e+01 - valid si-snr: -2.11e+01
epoch: 107, lr: 1.50e-04 - train si-snr: -2.18e+01 - valid si-snr: -2.11e+01
epoch: 108, lr: 1.50e-04 - train si-snr: -2.19e+01 - valid si-snr: -2.11e+01
epoch: 109, lr: 7.50e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.14e+01
epoch: 110, lr: 7.50e-05 - train si-snr: -2.22e+01 - valid si-snr: -2.15e+01
epoch: 111, lr: 7.50e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.15e+01
epoch: 112, lr: 7.50e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.15e+01
epoch: 113, lr: 7.50e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.15e+01
epoch: 114, lr: 7.50e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.15e+01
epoch: 115, lr: 7.50e-05 - train si-snr: -2.19e+01 - valid si-snr: -2.15e+01
epoch: 116, lr: 7.50e-05 - train si-snr: -2.17e+01 - valid si-snr: -2.15e+01
epoch: 117, lr: 7.50e-05 - train si-snr: -2.18e+01 - valid si-snr: -2.15e+01
epoch: 118, lr: 7.50e-05 - train si-snr: -2.19e+01 - valid si-snr: -2.15e+01
epoch: 119, lr: 7.50e-05 - train si-snr: -2.19e+01 - valid si-snr: -2.16e+01
epoch: 120, lr: 7.50e-05 - train si-snr: -2.20e+01 - valid si-snr: -2.16e+01
epoch: 121, lr: 7.50e-05 - train si-snr: -2.20e+01 - valid si-snr: -2.16e+01
epoch: 122, lr: 7.50e-05 - train si-snr: -2.20e+01 - valid si-snr: -2.16e+01
epoch: 123, lr: 7.50e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.16e+01
epoch: 124, lr: 7.50e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.16e+01
epoch: 125, lr: 7.50e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.16e+01
epoch: 126, lr: 7.50e-05 - train si-snr: -2.22e+01 - valid si-snr: -2.16e+01
epoch: 127, lr: 7.50e-05 - train si-snr: -2.22e+01 - valid si-snr: -2.16e+01
epoch: 128, lr: 7.50e-05 - train si-snr: -2.22e+01 - valid si-snr: -2.16e+01
epoch: 129, lr: 7.50e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.16e+01
epoch: 130, lr: 7.50e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.16e+01
epoch: 131, lr: 7.50e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.16e+01
epoch: 132, lr: 7.50e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.16e+01
epoch: 133, lr: 7.50e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.17e+01
epoch: 134, lr: 7.50e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.16e+01
epoch: 135, lr: 7.50e-05 - train si-snr: -2.24e+01 - valid si-snr: -2.16e+01
epoch: 136, lr: 7.50e-05 - train si-snr: -2.24e+01 - valid si-snr: -2.16e+01
epoch: 137, lr: 7.50e-05 - train si-snr: -2.24e+01 - valid si-snr: -2.16e+01
epoch: 138, lr: 7.50e-05 - train si-snr: -2.24e+01 - valid si-snr: -2.16e+01
epoch: 139, lr: 3.75e-05 - train si-snr: -2.26e+01 - valid si-snr: -2.18e+01
epoch: 140, lr: 3.75e-05 - train si-snr: -2.26e+01 - valid si-snr: -2.18e+01
epoch: 141, lr: 3.75e-05 - train si-snr: -2.26e+01 - valid si-snr: -2.18e+01
epoch: 142, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.18e+01
epoch: 143, lr: 3.75e-05 - train si-snr: -2.19e+01 - valid si-snr: -2.19e+01
epoch: 144, lr: 3.75e-05 - train si-snr: -2.20e+01 - valid si-snr: -2.19e+01
epoch: 145, lr: 3.75e-05 - train si-snr: -2.20e+01 - valid si-snr: -2.19e+01
epoch: 146, lr: 3.75e-05 - train si-snr: -2.20e+01 - valid si-snr: -2.20e+01
epoch: 147, lr: 3.75e-05 - train si-snr: -2.20e+01 - valid si-snr: -2.19e+01
epoch: 148, lr: 3.75e-05 - train si-snr: -2.20e+01 - valid si-snr: -2.19e+01
epoch: 149, lr: 3.75e-05 - train si-snr: -2.20e+01 - valid si-snr: -2.19e+01
epoch: 150, lr: 3.75e-05 - train si-snr: -2.20e+01 - valid si-snr: -2.20e+01
epoch: 151, lr: 3.75e-05 - train si-snr: -2.20e+01 - valid si-snr: -2.20e+01
epoch: 152, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.20e+01
epoch: 153, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.20e+01
epoch: 154, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.20e+01
epoch: 155, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.20e+01
epoch: 156, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.20e+01
epoch: 157, lr: 7.50e-05 - train si-snr: -2.20e+01 - valid si-snr: -2.19e+01
epoch: 158, lr: 7.50e-05 - train si-snr: -2.19e+01 - valid si-snr: -2.19e+01
epoch: 159, lr: 7.50e-05 - train si-snr: -2.20e+01 - valid si-snr: -2.19e+01
epoch: 160, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.21e+01
epoch: 161, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.21e+01
epoch: 162, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.21e+01
epoch: 163, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.21e+01
epoch: 164, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.21e+01
epoch: 165, lr: 3.75e-05 - train si-snr: -2.22e+01 - valid si-snr: -2.21e+01
epoch: 166, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.21e+01
epoch: 167, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.21e+01
epoch: 168, lr: 3.75e-05 - train si-snr: -2.21e+01 - valid si-snr: -2.21e+01
Epoch loaded: 167 - test si-snr: -2.21e+01
epoch: 169, lr: 3.75e-05 - train si-snr: -2.22e+01 - valid si-snr: -2.21e+01
epoch: 170, lr: 3.75e-05 - train si-snr: -2.22e+01 - valid si-snr: -2.21e+01
epoch: 171, lr: 3.75e-05 - train si-snr: -2.22e+01 - valid si-snr: -2.21e+01
epoch: 172, lr: 1.87e-05 - train si-snr: -2.22e+01 - valid si-snr: -2.22e+01
epoch: 173, lr: 1.87e-05 - train si-snr: -2.22e+01 - valid si-snr: -2.22e+01
epoch: 174, lr: 1.87e-05 - train si-snr: -2.22e+01 - valid si-snr: -2.22e+01
epoch: 175, lr: 1.87e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.22e+01
epoch: 176, lr: 1.87e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.22e+01
epoch: 177, lr: 1.87e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.22e+01
epoch: 178, lr: 1.87e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.22e+01
epoch: 179, lr: 1.87e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.22e+01
Epoch loaded: 178 - test si-snr: -2.22e+01
epoch: 180, lr: 1.87e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.22e+01
epoch: 181, lr: 1.87e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.22e+01
epoch: 182, lr: 1.87e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.22e+01
epoch: 183, lr: 1.87e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.22e+01
epoch: 184, lr: 1.87e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.22e+01
epoch: 185, lr: 1.87e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.22e+01
epoch: 186, lr: 1.87e-05 - train si-snr: -2.23e+01 - valid si-snr: -2.22e+01
epoch: 187, lr: 9.37e-06 - train si-snr: -2.23e+01 - valid si-snr: -2.23e+01
epoch: 188, lr: 9.37e-06 - train si-snr: -2.23e+01 - valid si-snr: -2.23e+01
Epoch loaded: 188 - test si-snr: -2.23e+01

So, your current run seems to be ahead of this one with 1 gpu.
Regarding multi-gpu: I haven't tested the code in depth for this. But from memory, the experiments I did with DDP, 2 gpu seemed like the performance drop was not significant. I would need to study what's happening to be able to tell you what's going on. Do you have results with 2 gpus?

Hi, I am sorry for late reply. I don't have 2 gpus result yet. I will run several experiments. After getting the results we can discuss further.
Besides, 8 gpus training is over, I updated the results in the table above.

I see.. it seems for some reason multigpu updates is effecting the gradient. And yes, looking forward for the 2 gpu results.

I found a rather shocking problem, when sepformer with batch_size=1 can converge well, but when batch_size=2 it does not converge.

@JusperLee , thanks for pointing this out. I will try to see what's going on. The proposed results are obtained with batch_size=1.

Yes, this is clear to me. I have tried several of these operations so far without converging.

I doubled the learning rate because the batch_size increased: lr=0.00015 -> 0.0003.
Another reason is that the learning rate is too big, so I use warmup to change the learning rate dynamically.
To avoid the problems caused by mixing precision, all the above experiments were performed with and without mixing precision.

Still, all the solutions could not solve the problem of non-convergence.
My initial suspicion is that the network structure itself may be unstable.

@JusperLee , is your network not converging with default parameters? For all networks large learning rate can cause issues..

But regarding batchsize, I will check if something fishy is happening inside the network.

Hi, I did the following experiment.
On a single gpu, with all the variables being the same, I tried batchsize 1 and 2. Here's what I get with batchsize 1:
epoch: 1, lr: 1.50e-04 - train si-snr: -5.78e+00 - valid si-snr: -7.92e+00
epoch: 2, lr: 1.50e-04 - train si-snr: -9.04e+00 - valid si-snr: -9.79e+00
epoch: 3, lr: 1.50e-04 - train si-snr: -1.07e+01 - valid si-snr: -1.14e+01
epoch: 4, lr: 1.50e-04 - train si-snr: -1.20e+01 - valid si-snr: -1.27e+01
epoch: 5, lr: 1.50e-04 - train si-snr: -1.32e+01 - valid si-snr: -1.34e+01
epoch: 6, lr: 1.50e-04 - train si-snr: -1.38e+01 - valid si-snr: -1.41e+01
epoch: 7, lr: 1.50e-04 - train si-snr: -1.44e+01 - valid si-snr: -1.46e+01
epoch: 8, lr: 1.50e-04 - train si-snr: -1.48e+01 - valid si-snr: -1.49e+01
epoch: 9, lr: 1.50e-04 - train si-snr: -1.51e+01 - valid si-snr: -1.53e+01
epoch: 10, lr: 1.50e-04 - train si-snr: -1.54e+01 - valid si-snr: -1.57e+01
epoch: 11, lr: 1.50e-04 - train si-snr: -1.57e+01 - valid si-snr: -1.58e+01
epoch: 12, lr: 1.50e-04 - train si-snr: -1.60e+01 - valid si-snr: -1.59e+01
epoch: 13, lr: 1.50e-04 - train si-snr: -1.62e+01 - valid si-snr: -1.62e+01
epoch: 14, lr: 1.50e-04 - train si-snr: -1.63e+01 - valid si-snr: -1.64e+01
epoch: 15, lr: 1.50e-04 - train si-snr: -1.65e+01 - valid si-snr: -1.66e+01
epoch: 16, lr: 1.50e-04 - train si-snr: -1.67e+01 - valid si-snr: -1.66e+01
epoch: 17, lr: 1.50e-04 - train si-snr: -1.69e+01 - valid si-snr: -1.69e+01
epoch: 18, lr: 1.50e-04 - train si-snr: -1.70e+01 - valid si-snr: -1.69e+01
epoch: 19, lr: 1.50e-04 - train si-snr: -1.71e+01 - valid si-snr: -1.70e+01
epoch: 20, lr: 1.50e-04 - train si-snr: -1.72e+01 - valid si-snr: -1.71e+01
epoch: 21, lr: 1.50e-04 - train si-snr: -1.73e+01 - valid si-snr: -1.73e+01
epoch: 22, lr: 1.50e-04 - train si-snr: -1.71e+01 - valid si-snr: -1.68e+01
epoch: 23, lr: 1.50e-04 - train si-snr: -1.71e+01 - valid si-snr: -1.72e+01
epoch: 24, lr: 1.50e-04 - train si-snr: -1.72e+01 - valid si-snr: -1.70e+01
epoch: 25, lr: 1.50e-04 - train si-snr: -1.73e+01 - valid si-snr: -1.73e+01
epoch: 26, lr: 1.50e-04 - train si-snr: -1.74e+01 - valid si-snr: -1.72e+01
epoch: 27, lr: 1.50e-04 - train si-snr: -1.76e+01 - valid si-snr: -1.75e+01
epoch: 28, lr: 1.50e-04 - train si-snr: -1.77e+01 - valid si-snr: -1.76e+01
epoch: 29, lr: 1.50e-04 - train si-snr: -1.78e+01 - valid si-snr: -1.77e+01
epoch: 30, lr: 1.50e-04 - train si-snr: -1.79e+01 - valid si-snr: -1.78e+01
epoch: 31, lr: 1.50e-04 - train si-snr: -1.80e+01 - valid si-snr: -1.79e+01
epoch: 32, lr: 1.50e-04 - train si-snr: -1.81e+01 - valid si-snr: -1.79e+01
epoch: 33, lr: 1.50e-04 - train si-snr: -1.82e+01 - valid si-snr: -1.80e+01
epoch: 34, lr: 1.50e-04 - train si-snr: -1.82e+01 - valid si-snr: -1.80e+01
epoch: 35, lr: 1.50e-04 - train si-snr: -1.83e+01 - valid si-snr: -1.79e+01
epoch: 36, lr: 1.50e-04 - train si-snr: -1.83e+01 - valid si-snr: -1.82e+01
epoch: 37, lr: 1.50e-04 - train si-snr: -1.84e+01 - valid si-snr: -1.82e+01
epoch: 38, lr: 1.50e-04 - train si-snr: -1.85e+01 - valid si-snr: -1.83e+01
epoch: 39, lr: 1.50e-04 - train si-snr: -1.85e+01 - valid si-snr: -1.82e+01
epoch: 40, lr: 1.50e-04 - train si-snr: -1.85e+01 - valid si-snr: -1.83e+01
epoch: 41, lr: 1.50e-04 - train si-snr: -1.86e+01 - valid si-snr: -1.84e+01
epoch: 42, lr: 1.50e-04 - train si-snr: -1.87e+01 - valid si-snr: -1.85e+01
epoch: 43, lr: 1.50e-04 - train si-snr: -1.86e+01 - valid si-snr: -1.84e+01
epoch: 44, lr: 1.50e-04 - train si-snr: -1.87e+01 - valid si-snr: -1.84e+01
epoch: 45, lr: 1.50e-04 - train si-snr: -1.87e+01 - valid si-snr: -1.85e+01
epoch: 46, lr: 1.50e-04 - train si-snr: -1.88e+01 - valid si-snr: -1.86e+01
epoch: 47, lr: 1.50e-04 - train si-snr: -1.88e+01 - valid si-snr: -1.86e+01
epoch: 48, lr: 1.50e-04 - train si-snr: -1.88e+01 - valid si-snr: -1.86e+01
epoch: 49, lr: 1.50e-04 - train si-snr: -1.89e+01 - valid si-snr: -1.87e+01
epoch: 50, lr: 1.50e-04 - train si-snr: -1.90e+01 - valid si-snr: -1.87e+01

And here's what I get with batchsize 2:
epoch: 1, lr: 1.50e-04 - train si-snr: -3.79e+00 - valid si-snr: -6.96e+00
epoch: 2, lr: 1.50e-04 - train si-snr: -6.60e+00 - valid si-snr: -8.55e+00
epoch: 3, lr: 1.50e-04 - train si-snr: -7.97e+00 - valid si-snr: -9.54e+00
epoch: 4, lr: 1.50e-04 - train si-snr: -8.78e+00 - valid si-snr: -9.93e+00
epoch: 5, lr: 1.50e-04 - train si-snr: -9.56e+00 - valid si-snr: -1.11e+01
epoch: 6, lr: 1.50e-04 - train si-snr: -1.03e+01 - valid si-snr: -1.16e+01
epoch: 7, lr: 1.50e-04 - train si-snr: -1.09e+01 - valid si-snr: -1.24e+01
epoch: 8, lr: 1.50e-04 - train si-snr: -1.16e+01 - valid si-snr: -1.28e+01
epoch: 9, lr: 1.50e-04 - train si-snr: -1.21e+01 - valid si-snr: -1.35e+01
epoch: 10, lr: 1.50e-04 - train si-snr: -1.25e+01 - valid si-snr: -1.40e+01
epoch: 11, lr: 1.50e-04 - train si-snr: -1.29e+01 - valid si-snr: -1.43e+01
epoch: 12, lr: 1.50e-04 - train si-snr: -1.33e+01 - valid si-snr: -1.45e+01
epoch: 13, lr: 1.50e-04 - train si-snr: -1.34e+01 - valid si-snr: -1.47e+01
epoch: 14, lr: 1.50e-04 - train si-snr: -1.39e+01 - valid si-snr: -1.50e+01
epoch: 15, lr: 1.50e-04 - train si-snr: -1.40e+01 - valid si-snr: -1.51e+01
epoch: 16, lr: 1.50e-04 - train si-snr: -1.42e+01 - valid si-snr: -1.54e+01
epoch: 17, lr: 1.50e-04 - train si-snr: -1.44e+01 - valid si-snr: -1.56e+01
epoch: 18, lr: 1.50e-04 - train si-snr: -1.46e+01 - valid si-snr: -1.58e+01
epoch: 19, lr: 1.50e-04 - train si-snr: -1.48e+01 - valid si-snr: -1.58e+01
epoch: 20, lr: 1.50e-04 - train si-snr: -1.48e+01 - valid si-snr: -1.60e+01
epoch: 21, lr: 1.50e-04 - train si-snr: -1.51e+01 - valid si-snr: -1.62e+01
epoch: 22, lr: 1.50e-04 - train si-snr: -1.50e+01 - valid si-snr: -1.60e+01
epoch: 23, lr: 1.50e-04 - train si-snr: -1.51e+01 - valid si-snr: -1.61e+01
epoch: 24, lr: 1.50e-04 - train si-snr: -1.53e+01 - valid si-snr: -1.62e+01
epoch: 25, lr: 1.50e-04 - train si-snr: -1.54e+01 - valid si-snr: -1.65e+01
epoch: 26, lr: 1.50e-04 - train si-snr: -1.53e+01 - valid si-snr: -1.66e+01
epoch: 27, lr: 1.50e-04 - train si-snr: -1.56e+01 - valid si-snr: -1.67e+01
epoch: 28, lr: 1.50e-04 - train si-snr: -1.57e+01 - valid si-snr: -1.67e+01
epoch: 29, lr: 1.50e-04 - train si-snr: -1.54e+01 - valid si-snr: -1.64e+01
epoch: 30, lr: 1.50e-04 - train si-snr: -1.54e+01 - valid si-snr: -1.66e+01
epoch: 31, lr: 1.50e-04 - train si-snr: -1.57e+01 - valid si-snr: -1.65e+01
epoch: 32, lr: 1.50e-04 - train si-snr: -1.58e+01 - valid si-snr: -1.70e+01
epoch: 33, lr: 1.50e-04 - train si-snr: -1.59e+01 - valid si-snr: -1.70e+01
epoch: 34, lr: 1.50e-04 - train si-snr: -1.61e+01 - valid si-snr: -1.71e+01
epoch: 35, lr: 1.50e-04 - train si-snr: -1.60e+01 - valid si-snr: -1.72e+01
epoch: 36, lr: 1.50e-04 - train si-snr: -1.62e+01 - valid si-snr: -1.72e+01
epoch: 37, lr: 1.50e-04 - train si-snr: -1.62e+01 - valid si-snr: -1.71e+01
epoch: 38, lr: 1.50e-04 - train si-snr: -1.62e+01 - valid si-snr: -1.71e+01
epoch: 39, lr: 1.50e-04 - train si-snr: -1.62e+01 - valid si-snr: -1.73e+01
epoch: 40, lr: 1.50e-04 - train si-snr: -1.63e+01 - valid si-snr: -1.74e+01
epoch: 41, lr: 1.50e-04 - train si-snr: -1.65e+01 - valid si-snr: -1.74e+01
epoch: 42, lr: 1.50e-04 - train si-snr: -1.64e+01 - valid si-snr: -1.73e+01
epoch: 43, lr: 1.50e-04 - train si-snr: -1.66e+01 - valid si-snr: -1.76e+01
epoch: 44, lr: 1.50e-04 - train si-snr: -1.65e+01 - valid si-snr: -1.76e+01
epoch: 45, lr: 1.50e-04 - train si-snr: -1.64e+01 - valid si-snr: -1.76e+01
epoch: 46, lr: 1.50e-04 - train si-snr: -1.66e+01 - valid si-snr: -1.77e+01
epoch: 47, lr: 1.50e-04 - train si-snr: -1.67e+01 - valid si-snr: -1.77e+01
epoch: 48, lr: 1.50e-04 - train si-snr: -1.68e+01 - valid si-snr: -1.76e+01
epoch: 49, lr: 1.50e-04 - train si-snr: -1.67e+01 - valid si-snr: -1.78e+01
epoch: 50, lr: 1.50e-04 - train si-snr: -1.69e+01 - valid si-snr: -1.79e+01

While it is true that the performance is a bit lower with batchsize=2, I am not really observing a major instability.

I am closing the issue for now as from what I observe the default code seems to stable with batchsize=2. Feel free to open it again.

By comparing my code and speechbrain, I found that it might be a problem with the middle copy part of the speechbrain, but I didn't look into why it caused this problem.
https://github.com/speechbrain/speechbrain/blob/b5d2836e3d0eabb541c5bdbca16fb00c49cb62a3/speechbrain/lobes/models/dual_path.py#L960

Hm.. I am not sure why this would cause a problem.. that copy basically
just replicates the dual computation module..
Le mar. 3 mai 2022, à 01 h 25, Kai Li (李凯) @.***> a
écrit :

By comparing my code and speechbrain, I found that it might be a problem
with the middle copy part of the speechbrain, but I didn't look into why it
caused this problem.
https://github.com/speechbrain/speechbrain/blob/b5d2836e3d0eabb541c5bdbca16fb00c49cb62a3/speechbrain/lobes/models/dual_path.py#L960
—
Reply to this email directly, view it on GitHub
https://github.com/speechbrain/speechbrain/issues/1314#issuecomment-1115750402,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEGOFX7SRGSXKSPJPBTDCZTVIC2C5ANCNFSM5PQKTBRA
.
You are receiving this because you modified the open/close state.Message
ID: @.***>

authors: JusperLee caixy97 ycemsubakan

repo: speechbrain/speechbrain


text:
Basic SECURITY.md

It is good to have at least some rudimentary security policy set up for SpeechBrain. The GitHub template suggests two sections: Supported versions and Reporting a vulnerability.

I have made the security updates paragraph a bit clearer.


text:
Log Improvement: Options for only the first 10 column families are reported to the log

The options of column families are reported to the log at the top of every log file. However, if there are more than 10 column families (not very common but definitely allowed and occurs in practice), only the options of the first 10 are reported to the log.
Throughout the log file, any other log line that is associated with any column family will be reported. So, you find in the log information about column families whose options you don't know.

@udi-speedb, do you know if these options are printed to the OPTIONS file?

also, i dont know if this is a bug since its definitely intentional

@Yuval-Ariel:

I do not know if its in the options. I assume it is.
I agree that it's intentional , but I still think it should be considered a bug.
I believe that a log file should allow a person to see all the information that a log file provides. In addition, I might have access only to to a log file (e.g., log parsing tool) and should be able to use it only to parse and process.

@Yuval-Ariel:

I do not know if its in the options. I assume it is.
I agree that it's intentional , but I still think it should be considered a bug.
I believe that a log file should allow a person to see all the information that a log file provides. In addition, I might have access only to to a log file (e.g., log parsing tool) and should be able to use it only to parse and process. You will see in the log events, stats, etc. related to the "missing" column families, but no options for them

I was working on something earlier that would only print/return options that were different than the default.  This could be useful if we wanted to keep the logs (or options files) shorter and pruned.  I can try to resurrect that code...

@Yuval-Ariel:

I do not know if its in the options. I assume it is.
I agree that it's intentional , but I still think it should be considered a bug.
I believe that a log file should allow a person to see all the information that a log file provides. In addition, I might have access only to to a log file (e.g., log parsing tool) and should be able to use it only to parse and process. You will see in the log events, stats, etc. related to the "missing" column families, but no options for them

I was working on something earlier that would only print/return options that were different than the default. This could be useful if we wanted to keep the logs (or options files) shorter and pruned. I can try to resurrect that code...

@mrambacher As part of the log parser tool, I am displaying a diff between baseline options files (options files that are generated from official RocksDB / Speedb releases whose values are the defaults for that release) and options as displayed in the log file.

I am opening a new issue that will keep the limit of 10 cf-s but, unlike now, will print their names to the log. This is a simpler change and also a more useful one as most users do not have more than 10 cf-s anyway. In addition, this will apply to any number of cf-s in the log so it's useful either way.

Until this issue is resolved (I am not sure if reporting the options for all of the cf-s is a valid solution when there are many cf-s) I have added https://github.com/speedb-io/speedb/issues/520
My concerns with reporting all of the options is that, when there are many cf-s (their number is not limited), we may bloat the log file with the text reporting the options of all of the cf-s. This may be a bigger issue when log files are rotated frequently, as the options are reported at the top of every rolled log.

thats why @mrambacher  suggestion of reporting only the options that are different than the first cf is a great one. i believe doing this is irrelevant of the log-parser and it would have several beneficial effects:

reduce confusion since it would immediately popup an option thats different
reduce writing to the log
allow for all the cfs options to be printed to the log - what this issue is all about

@mrambacher - Please attach a sample log output when you have one ready, so we would be able to better understand how that would look (and also estimate the effort of the log parser's adaptation).

@mrambacher - Could you please add a reference for the pr-s on which you rely as infrastructure for this one?

This is being resolved in stages that will require several PRs:

#619 changes the serialize methods to use Properties/Maps instead of strings.  This allows later formatting to be implemeneted
#648 allows only options that were changed to be part of the serialization.  This allows the output written to the Dump to be shorter and only contain the pertinent information, thereby shrinking the size of the LOG.
#651 adds a pluggable formatter that allows options to be serialized in different formats (such as that written to the LOG)
#719 changes the Options::Dump to use the Options internal code and not hard-coded values.  This insures that all options are logged appropriately (as new ones are added)

There will also be a subsequent PR that brings this altogether and removes the cap of the number of CFs that are written.

authors: Yuval-Ariel mrambacher udi-speedb

repo: speedb-io/speedb


text:
Jinja support in Hugo

Hi,
We are really liking Hugo. Thanks for the great software. We would like to see Jinja template support in Hugo. My questions are:

Is there any plan to add support for Jinja(via flosch/pongo2 maybe) templates?
If there is no plan to add Jinja support by the core team, are you folks interested in accepting code contribution to this regard? Is there any guide on how to add new template support?

Thanks.

Hello @codefx9,
there is already an issue (#1359) with the request of adding support for pongo2. Your effort could maybe give this enhancement a push.

@digitalcraftsman, thanks for pointing this out. Closing this one.


text:
Unusual camelCase repository name breaks vgo

The x/vgo prototype enforces strict casing on imports. spf13/viper imports spf13/jwalterweatherman, which is not the same casing as the github repo. This breaks importing the library.
Arguably vgo should not be enforcing case. However, even you, the author, don't use the correct case, which suggests to me maybe in this case the github repo should just be renamed to what people actually import it as. WDYT?

I'm not the author, but I have an opinion: The camel-case makes a good test case for the x/vgo and simliar. So I vote to keep as is.

My question would be: what do we gain from this test case? AFAICT, this repository is the only popular repository out there that violates the casing convention. Allowing mismatched case packages is problematic, because it will only work with vgo in specific situations ("is the repo on github", basically).
The generic module hosting mecanisms described for vgo have as a requirement "must be able to use a dumb static content server," which means there must be no arbitrary transformations between the imported name and the name of the thing hosting the modules.
In theory, vgo could add a bunch of special-casing for just Github... But otoh, this really is only a problem during the onboarding phase of vgo. Post vgo adoption, any such mismatching would be found instantly, and corrected before the module is even published. So, my question is: is it worth the pain to support this special case, if it results in a less consistent vgo UX, when github trivially allows renaming of repositories?

AFAICT, this repository is the only popular repository out there that violates the casing convention.

That I doubt. But as I said, I'm not the owner of this repo. If it somehow stops me from using vgo when that time comes, then I will maybe revisit this problem. But vgo is an early prototype, there are lots of "case issues" and other stuff to be ironed out.

@bep seems to be fixed in a recent version of vgo. @danderson would you consider trying go get -u golang.org/x/vgo and if it works consider closing this issue?

The "canonical Go import" part of this module has already been github.com/spf13/jwalterweatherman -- I say this because that is how it always has been in Hugo, the origin of this module. This is also the module name used in go.mod, which works fine for most.
So, the only correct thing to do is to rename this repository to all lowercase. I will get @spf13 's attention about this and get it done.

authors: bep danderson losinggeneration


text:
OSError: [Errno 22] Invalid argument when trying to run cpuset-modify on user.slice

Today I noticed that after a system upgrade if I attempt to run vfio-isolate cpuset-modify --cpus C0-15 user.slice, it no longer works:
17:02:29 ~ #> vfio-isolate cpuset-modify --cpus C0-15 user.slice
OSError: [Errno 22] Invalid argument

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/bin/vfio-isolate", line 33, in <module>
    sys.exit(load_entry_point('vfio-isolate==0.5.2', 'console_scripts', 'vfio-isolate')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cli.py", line 200, in run_cli
    executor.run()
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cli.py", line 191, in run
    for undo in e.action.record_undo(e.params):
  File "/usr/lib/python3.11/site-packages/vfio_isolate/action/cpuset_modify.py", line 39, in record_undo
    cpus=cpu_set.get_cpus(),
         ^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cpuset.py", line 69, in get_cpus
    return self.impl.get_cpus(self)
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cpuset.py", line 232, in get_cpus
    CGroupV2.ensure_cpuset_controller_enabled(cpuset)
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cpuset.py", line 228, in ensure_cpuset_controller_enabled
    CGroupV2.enable_controller(cpuset, "cpuset")
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cpuset.py", line 222, in enable_controller
    with cpuset.open("cgroup.subtree_control", "w") as f:
OSError: [Errno 22] Invalid argument

Changing the cpuset from --cpus C0-15 to something else does not seem to make any difference. The command does work for system.slice, strangely enough.
I'm running
#> uname -a
Linux Archiroo 6.1.53-1-lts #1 SMP PREEMPT_DYNAMIC Wed, 13 Sep 2023 09:32:00 +0000 x86_64 GNU/Linux

with systemd 254.3-1, in case it is relevant.

I saw the same behavior -- failed cpuset.open("cgroup.subtree_control"...
system.slice worked for me also.
I even checked /sys/fs/cgroup/user.slice/cgroup.subtree_control. It exists and appears normal.
I am using kernel 6.5.5-arch1-1 with systemd 254.5-1. Not sure which update caused this or how recently.
vfio-isolate seemed to become intermittent some weeks or even longer ago.
I was seeing silent failures to restore the undo file and restore cores to the host.
I  had no time to look at it or even use it much, but I did just now find the same error message as roobre.
Previously, I was experiencing silent failures to restore the undo file and free cores up to the host again.
The error disappeared suddenly while I  was adding print statements for logging and testing repeatedly.
I have a feeling it may return on next boot - if it does, I'll try to document what exactly gets around it.
Happy to run any other debugging needed.

This is what I'm getting on a fresh boot of 6.5.6-arch2-1
I have a the vfio_isolate command-line used below along with a crude debug from this non-Python guy
/usr/lib/python3.11/site-packages/vfio_isolate/cpuset.py has a modified open() that does print (self.__path(file))
Those are the paths you see printed on their own lines
vfio-isolate -v -u /var/run/libvirt/qemu/vfio-isolate-undo.bin 		drop-caches 		cpuset-modify --cpus C8-14,24-30 /system.slice 		cpuset-modify --cpus C8-14,24-30 /user.slice 		compact-memory 		cpu-governor performance C0-7,15-23,31 		irq-affinity mask C0-7,15-23,31
/sys/fs/cgroup/system.slice/cgroup.controllers
/sys/fs/cgroup/system.slice/cgroup.subtree_control
FileNotFoundError: [Errno 2] No such file or directory

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/vfio-isolate", line 33, in <module>
    sys.exit(load_entry_point('vfio-isolate==0.5.2', 'console_scripts', 'vfio-isolate')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cli.py", line 200, in run_cli
    executor.run()
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cli.py", line 191, in run
    for undo in e.action.record_undo(e.params):
  File "/usr/lib/python3.11/site-packages/vfio_isolate/action/cpuset_modify.py", line 39, in record_undo
    cpus=cpu_set.get_cpus(),
         ^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cpuset.py", line 70, in get_cpus
    return self.impl.get_cpus(self)
           ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cpuset.py", line 233, in get_cpus
    CGroupV2.ensure_cpuset_controller_enabled(cpuset)
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cpuset.py", line 229, in ensure_cpuset_controller_enabled
    CGroupV2.enable_controller(cpuset, "cpuset")
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cpuset.py", line 223, in enable_controller
    with cpuset.open("cgroup.subtree_control", "w") as f:
FileNotFoundError: [Errno 2] No such file or directory
taskset -pc 8-14,24-30 2
pid 2's current affinity list: 0-31

vfio-isolate -v restore /var/run/libvirt/qemu/vfio-isolate-undo.bin
Traceback (most recent call last):
  File "/usr/bin/vfio-isolate", line 33, in <module>
    sys.exit(load_entry_point('vfio-isolate==0.5.2', 'console_scripts', 'vfio-isolate')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cli.py", line 199, in run_cli
    cli(standalone_mode=False, obj=executor)
  File "/usr/lib/python3.11/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
         ^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 1719, in invoke
    rv.append(sub_ctx.command.invoke(sub_ctx))
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/click/decorators.py", line 45, in new_func
    return f(get_current_context().obj, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/vfio_isolate/cli.py", line 171, in restore
    with open(undo_file, "rb") as f:
         ^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/var/run/libvirt/qemu/vfio-isolate-undo.bin'
taskset -pc 0-31 2
pid 2's current affinity list: 8-14,24-30
pid 2's new affinity list: 0-31

[ranguvar@khufu ~]$ ls -l /sys/fs/cgroup/system.slice/cgroup.subtree_control
-rw-r--r-- 1 root root 0 Oct  7 21:31 /sys/fs/cgroup/system.slice/cgroup.subtree_control
[ranguvar@khufu ~]$ cat /sys/fs/cgroup/system.slice/cgroup.subtree_control
memory pids

I don't believe the failure to find the restore file is an issue, I believe it complains the same yet creates it happily in the past. Obviously it then isn't ready for the restore either.

authors: Ranguvar roobre

repo: spheenik/vfio-isolate


text:
Add option to fill all rows with general order information

In the order export, we should offer an option to fill all rows of an order with the general order information, instead of just the first row of an order.
Background: Currently, the 1st row in the order export contains general information such as address; in the 2nd row per order are all the line items of the order. The general rows are not filled because they are redundant, but some of our customers would like them to always be filled.

The first row of the order with lineItems contains basic (order level) info like addresses, prices, etc.
If we put this info also to other rows, should we remove the first row because of a redundancy?
What do you think @Siilwyn @hisabimbola?

I think we shouldn't add more options and instead fill them all as a default behaviour unless there is a huge benefit that I'm missing. The redundancy is not that big of a problem imho.

We should not remove the first row, but I am not sure whether we should do this without a flag, what if some users do not want the redundant rows 🙄

I added here https://github.com/sphereio/sphere-order-export/issues/48 a --fillAllRows parameter which will add this behavior.

I'll just leave this here: https://www.youtube.com/watch?v=glZ1C-Yu5tw
^^
:wave:

authors: Oehmi Siilwyn hisabimbola junajan

repo: sphereio/sphere-order-export


text:
Fix PHP 7.4 deprecation

There's a deprecation at https://github.com/spicywebau/craft-embedded-assets/blob/master/src/Service.php#L196 with PHP 7.4.

Should be changed to:
$code = ($value instanceof Twig_Markup ? (string)$value : is_string($value)) ? $value : '';

fix has been released in v2.2.1.1

authors: engram-design pvldigital

repo: spicywebau/craft-embedded-assets


text:
Name Spider-Gazelle

There is already a project with the same name but for ruby. would not something better be more creative?
https://github.com/cotag/spider-gazelle

I saw that you are comiiter, but both projects can be confused with the same purpose but with equal names. What sets it apart is the language. IMHO =/

repo: spider-gazelle/spider-gazelle

license: WTFPL