Provide CPU/Memory and Elapsed time of CMSSW subprocess based on psutil module

Fixes #11660
Status
In development
Description
Provide CPU/Memory and Elapsed time of CMSSW subprocess based on psutil module.
Is it backward compatible (if not, which system it affects?)
YES
Related PRs
#11656 , #11657,  #11663
External dependencies / deployment changes
psutil module

@amaltaro I made necessary changes to provide CPU/Mem and time info for each cmsRun job and it would be useful if you'll provide initial review. I still need to adjust unit tests though.

Alan, I was able to successfully run unit tests with new PR implementation, but I step down from using stdoutHandle and stderrHandle (open file descriptors). Instead I used subprocess.PIPE and write its content into stdoutHandle and stderrHandle file descriptors. The reason for that is that subprocess.call relies on Popen.wait call internally, see
https://github.com/python/cpython/blob/3.11/Lib/subprocess.py#L389-L391
and, it blocks usage of resources. While using Popen with PIPE allows to redirect stdout/stderr to these PIPE objects and read it later, therefore it does not block subprocess execution and allows to use wait4 call (as I did) which provides resource object. Anyway, now unit tests are find (and it means running CMSSW job unit test subprocess is also fine) and you can review working version of new implementation.

hi @vkuznet
I am interested in this development here in the context of the following issue:  https://github.com/dmwm/WMCore/issues/11667
So  reading your comment above:

the code does not depend on third party library anymore (psutil) and therefore has advantage of being using pure python solution

May I ask, if you and @amaltaro have already converged on using psutils or resources libraries already.
I can see  they both are still used in your PR, while to me the portion of information related to resource consumption by a specific process, they are  supposed to be interchangeable. But in your PR, they are some kind of complementary - one used to fetch the subprocess information the other for fetching the resource utilization information.
I am asking because in the issue I am trying to resolve, we will have to support/test a large range of linux kernel versions: 3.* to 6.* And since there have been a change in the /proc/<pid>/smap* resource reports, somewhere at around kernel version 4.*, it means, whichever library we happen to chose here, it should be confirmed working in all of those kernels. One thing which is also important - IIUC, resources comes as a standard library package, while psutils happens to be an external library, hence it brings additional need for making sure we correctly fetch it at runtime  - either by a wrapper module inside the WMCore code  or through the equivalently provided psutils library with cmssw

Sorry, it seems that there is a detail, worth mentioning here.
About:

when it comes to the portion of information related to resource consumption by a specific process, they are supposed to be interchangeable

It seems in some cases psutils and resources  may give different  answers. Reading this post in stackoverflow: https://stackoverflow.com/questions/63983222/psutil-gives-other-result-than-resource

I just want to note that in https://github.com/dmwm/WMCore/issues/11604 I requested the elapsed wall clock time to be accompanied with a timestamp of the moment the cmsRun was started.

@makortel Matti, that was an overlook from my side. Valentin did start this implementation by providing start/end timestamps, while I thought we only wanted to know the wallclock time (elapsed time).
I guess the wallclocktime-only has been requested for the whole job wrapper, while for each cmsRun you want to have:

start timestamp (epoch? utc?)
end timestamp
wallclock time (end - start timestamp)

Could you please confirm this?

I guess the wallclocktime-only has been requested for the whole job wrapper,

Actually we'd like to have the start timestamp also for the job wrapper (e.g. to see the time difference from job wrapper startup to starting up cmsRun).

while for each cmsRun you want to have:

start timestamp (epoch? utc?)
end timestamp
wallclock time (end - start timestamp)

Either 1+2 or 1+3 would suffice. I don't think all three are needed as (2 or 3) can be calculated from 1 and (3 or 2).
As for the start timestamp format, I'd think the Unix time to be most convenient.

Alan, this PR is mostly complete and I need your initial review to understand if all necessary pieces are in place. Please have a look at your convenience.

Alan, regarding your questions:
a) it depends on use-case and in concurrent environment extra precision is valuable, therefore I do not mind to convert to ints, but keeping in floats seems reasonable too for me
b) I submitted new WM (from vocms0291), see wmagent_TaskChain_MC_Agent0291_forceComplete_230822_131344_5472
c) unless I'm mistaken there is no need for extra development to parse FJR to WMArchive doc since XMLParser.py will parse all available sections in FJR and create appropriate JSON document which will be send to WMArchvie. On WMArchive side we also do not need special handling since it reads JSON as is to send it over to MONIT. Said that, I only adjusted WMArchive schema, see PR$362 to include the metrics. But after the FJR report will be generated via step (b) I'll regenerate JSON file from FJR pkl one and post appropriate link over here.

@makortel Matti, for the timing measurements, do you have any preference of data type/precision? Right now it's float, but I think seconds in integer would be more than enough. Please let us know your opinion on this.
Valentin, for the point c) above, you need to check the createArchiverDoc method in this module:
https://github.com/dmwm/WMCore/blob/master/src/python/WMCore/Services/WMArchive/DataMap.py#L397
this is how the WMArchive documents gets constructed and it's not clear to me that a new section in the FJR will automatically make it to the final WMArchiver document.

@amaltaro , I added appropriate PR (https://github.com/dmwm/WMCore/pull/11692) which provides metrics to WMArchive service but I was under impression that we separate creation of metrics and their propagation to WMArchive anyway because it would be much easier to test rather then having so many PRs at the same time (I start preparing doc about CPU/Memory, Timing, CMSSW metrics and it has quite a lot of PRs).

Matti, for the timing measurements, do you have any preference of data type/precision? Right now it's float, but I think seconds in integer would be more than enough. Please let us know your opinion on this.

We would prefer float, so that if a less-than-second measurement occurs, a value different from zero would be visible (for exact 0 one could wonder if the value was actually measured or if the 0 is just a default value). But technically integer would work too (time durations of interest are longer than a second).

@amaltaro , I just checked the job from wmagent_TaskChain_MC_Agent0291_forceComplete_230822_131344_5472 (on cmsweb-testbed) and extracted one of the job pickle files, and decoded it back. Here is relevant subsection for metrics:
FrameworkJobReport.cmsRun1.WMCMSSWSubprocess.sysTime = 94.256681
FrameworkJobReport.cmsRun1.WMCMSSWSubprocess.endTime =<PHONE_NUMBER>.7409143
FrameworkJobReport.cmsRun1.WMCMSSWSubprocess.userTime = 6053.7735170000005
FrameworkJobReport.cmsRun1.WMCMSSWSubprocess.startTime =<PHONE_NUMBER>.8846245
FrameworkJobReport.cmsRun1.WMCMSSWSubprocess.wallClockTime = 6264.856289863586

and, it is transformed into JSON as following (only showing relevant section):
 'cmsRun1': {'WMCMSSWSubprocess': {'endTime':<PHONE_NUMBER>.7409143,
                                   'startTime':<PHONE_NUMBER>.8846245,
                                   'sysTime': 94.256681,
                                   'userTime': 6053.7735170000005,
                                   'wallClockTime': 6264.856289863586},
             'analysis': {'files': {'fileCount': 0}},
...

For completeness, here are the links to full report in different formats:

pkl format
JSON format

For completeness here is a simple script to transform pkl report to dot (txt) and JSON representations
#!/usr/bin/env python

import sys
import json
import pprint
import pickle

# WMCore modules
from WMCore.FwkJobReport.Report import Report

fname = sys.argv[1]
fout = fname + '.json'
print("Generating report for", fname)
report  = pickle.load(open(fname, 'rb'))
jsonData = report.dictionary_whole_tree_()
with open(fname + '.txt', 'w') as ostream:
    ostream.write(report.__str__())
with open(fname + '.json', 'w') as ostream:
    ostream.write(json.dumps(jsonData))
with open(fname + '_formated.json', 'w') as ostream:
    data = pprint.pformat(jsonData).replace("'", '"')
    ostream.write(data)

As we keep discussing this and try to have the whole chain functional, I have some updates that are worth sharing.

That the actual FJR used by the ArchiveDataReporter - to upload a document to WMArchive - does not have this new section added in this pull request, called WMCMSSWSubprocess.  This can be verified by pulling any job FJR from CouchDB (provided that the agent version is >=2.2.4rc3), e.g.:

curl ***:***@localhost:5984/wmagent_jobdump%2Ffwjrs/537-0 | jq

Each job step does have a start and stop metric though, but that already existed in the FJR previously to this development, e.g.:

        "start":<PHONE_NUMBER>,
        "stop":<PHONE_NUMBER>,

Job report pickle file does contain this section. Those report pickle files get transferred back to the agent once the job finishes and one example location to find it in a tarball is install/wmagentpy3/JobArchiver/logDir/a/amaltaro_TaskChain_ProdMinBias_Sept2023_Val_230907_205436_2542/JobCluster_0/Job_537.tar.bz2 (vocms0192). Upon decompressing it and loading the report pickle file

>>> with open("/data/srv/wmagent/current/Job_537/Report.0.pkl", "rb") as po:
...   data = pickle.load(po)
>>> pprint(data.dictionary_whole_tree_())
{'WMAgentJobID': 537,
 'WMAgentJobName': '893188c8-0783-4db2-8f55-ce060a3bdd4e-71',
 'ceName': 'b7s02p8471.cern.ch',
 'cmsRun1': {'WMCMSSWSubprocess': {'endTime':<PHONE_NUMBER>.631746,
                                   'startTime':<PHONE_NUMBER>.9059343,
                                   'sysTime': 17.675720000000002,
                                   'userTime': 320.763982,
                                   'wallClockTime':<PHONE_NUMBER>198944},

we can properly find it. Another alternative to see the whole structure of this object is with:
>>> pprint(data.pythonise_())
['FrameworkJobReport.WMAgentJobName = '
...
 "FrameworkJobReport.cmsRun1.section_('WMCMSSWSubprocess')",
 'FrameworkJobReport.cmsRun1.WMCMSSWSubprocess.startTime =<PHONE_NUMBER>.9059343',
 'FrameworkJobReport.cmsRun1.WMCMSSWSubprocess.userTime = 320.763982',

Having said that, the place to debug this further would be:
https://github.com/dmwm/WMCore/blob/4170e4a/src/python/WMCore/JobStateMachine/ChangeState.py#L346-L404
which generates the relevant information stored in the wmagent_jobdump/fwjrs CouchDB database. FYI @vkuznet
PS.: Note that the overall timing section defined at the wrapper and called WMTiming is nowhere to be found in these documents.

Changing the data source is definitely NOT the right way to proceed. If ArchiveDataReporter is fed with the FJRs stored in CouchDB, what we need to do is to ensure that the CouchDB documents have the proper content.
Please investigate the code I referenced above in ChangeState to ensure that the fwjrDocument object in that code ends with the new metrics.

@amaltaro , I do not understand what do you mean by saying "changing data source", which data source? In my view there two different FJR in a system. One is generated within job, this is the one where we put metrics. It is written to the pkl file when job is done. And, another which is create by some component in WMA which writes and update it in local CouchDB. If this is the case in order to get CMSSW, or any other job related metrics we need to read job FJR from pkl file because this is where metrics about job are stored. We can read it in ArchiveDataReporter or in ChangeState to complement the FJR which is circulating in WMA and not associated with a job. We verified already that WMCMSSWSubprocess are present in job FJR and are not present in local couchDB one. Therefore, it just confirms that those are two different FJR reports circulating in WMA, and in order to unify them we need to read pkl file elsewhere. In my view ArchiveDataPoller  is proper place as it runs after jobs are done, but the same logic can be put in ChangeState module but I doubt that pkl file will exist at every change of the workflow change, and therefore it reference in MariaDB will exist by the time we change  state from processing job to job archive for instance. So fart I see pointless to dig further since I have no clear idea how entire workflow and its transition in different system works. I rather prefer to have dedicated discussion/chat about the strategy. At the moment I see that we can simply dump fwjr object in ChangeState but as I pointed out already it does not create it in a first place, instead it is given jobs FJR objects which are created someplace else.


Support foe queues

Hi,
Our micrservices  communications are done via rabbit mq and not hhtp, is it supported?
Thank you

Hi @aviNrich yes it is!
Support maturity is dependent on the programming language that you are using. May I ask which languages are you using?
Thanks


SparseMarkovVariationalGP vs S2CVI

I've been using markovflow.SpatioTemporalSparseCVI, which implements S2CVI from this paper, for some modeling, and I'm now experimenting with BayesNewton. Is SparseMarkovVariationalGP with a SpatioTemporalKernel that has inducing points essentially equivalent to S2CVI?
Also, can the current implementations handle 2 spatial dimensions as well as a temporal dimension?

Hi. Sorry for the delay in replying. Yes these are two different implementations of the same approach. And yes, the implementation can handle multiple spatial dimensions.


Fix code snippet tuto_first_steps.md

Description
Remove a superfluous closing bracket in the first steps tutorial which breaks the code snippet for spawning vehicles. Fixes #5441

This change is

Apparently, dev already has this fixed, as no files changed are present after updating the PR, so I'm closing this


issue76 - Server improvement + problems solved

Requests without searchQuery returning an empty array of results.
MongoDB connection issues, now reconnects to mongo after connection loss.
Organizing databases files in to 'store' folder.
Moving tweets collection query methods into a separate file.

This pull request looks great !!! Thanks for making those changes

@anvk  changes done! check if it is ok now :)

Hey @carloscarcamo great job! sorry to bug but there is one more little change and I will merge it in.

@anvk  no problem! check now please!
Can you create a code conduct or code standard for this project? Would be good to have such thing for everyone who wants to contribute to this project.

Merged!
Well not sure if I need to add this code conduct page. There are so many available online already. For example https://github.com/airbnb/javascript This is a very popular source especially since it is used by many many projects while eslint-ing. Maybe in the future I just add eslint to the project which would lint the code for any "bad syntax" and errors.


Update natchez-core, natchez-honeycomb, ... to 0.2.2

Updates

org.tpolecat:natchez-core
org.tpolecat:natchez-honeycomb
org.tpolecat:natchez-noop

from 0.1.6 to 0.2.2.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.tpolecat" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.tpolecat" }
}]

labels: library-update, early-semver-major, semver-spec-minor, commit-count:1

PITA because this will change the slf4j version to 2.x.
See also https://github.com/valskalla/odin/pull/496


Support for Groovy

Description
The results of beautification are not what I expect.
Expected Results
The beautified code should have looked like:
<INSERT CODE HERE>

Steps to Reproduce

Add code to Atom editor
Run command Atom Beautify: Beautify Editor
This beautified code does not look right!

Debug
Here is a link to the debug.md Gist: https://gist.github.com/...
How to create debug.md Gist
Note that this will include a copy of your code.
If your code is private, please create a different sample of code that reproduces the problem.

In the Atom command-palette,
search for and run the command Atom Beautify: Help Debug Editor.
The debugging results will be copied to your clipboard.
Create a new Gist at https://gist.github.com/
Create a file in your new Gist called debug.md.
Paste your debugging results from Atom beautify into debug.md file in your Gist.
Add a link to your Gist in your new Issue.

Checklist

[ ] I have tried uninstalling and reinstalling Atom Beautify to ensure it installed properly
[ ] Searched for existing Atom Beautify Issues at https://github.com/Glavin001/atom-beautify/issues
so I know this is not a duplicate issue
[ ] Generated debugging information and added link for debug.md Gist to this issue

This issue appears to be a duplicate of https://github.com/Glavin001/atom-beautify/issues/371
Please feel free to reopen the issue if I am making an incorrect assumption.


User interface issue

On a run workout based on time or distance

Since the new cadence box has appeared, it gets in the way when you try to adjust the intensity/percentage.

Hello @trigg10 !
Thanks for reporting this. This has been fixed now!

Hello @trigg10 !
Thanks for reporting this. This has been fixed now!


Allow defining custom quote types

Describe the Feature
Allow defining a custom quote type for a dialect.
Why do you want this feature?
As I explained in #306, I would like to define a custom grammar of Trino SQL queries + {{Handlebars templates}} so that users can write (and format with sql-formatter) queries like this
select
  {{ country_code }}
from
  my_table

and we could render the query for other users with a dropdown in place of {{ country_code }}. The easiest way to do this is to make make sql-formatter treat {{}} like a type of string. In order to do this, we need to have a regex for this type of quote in quotePatterns. It makes no sense to add this to sql-formatter itself, so we have to fork it to add this custom quote type. It would be nice if I could pass the regex somehow through DialectOptions' tokenizerOptions.stringTypes or some other way.

This is now supported with the following API:
stringTypes: [
  { regex: "your regex here" }
]

Available in 12.0.0-beta.5 release.


fix(button): added variable for active state on slotted icon

Describe pull-request
Added a variable for the slotted icon on active state of button. This was previously getting overridden by the hover state of the slotted icon.
Solving issue
Fixes: CDEP-1982
How to test

Go to storybook link below.
Check in Components -> Button
Set it to use secondary variant.
Click the button and make sure the icon is the correct color when it is being clicked.

Tested and passed in browsers: Chrome, Safari, Firefox


Ts reorganise pretty

Reorganized Cardano.Ledger.Pretty
It is broken into two parts PrettyBase and Cardano.Ledger.Pretty

PrettyBase does not depend on any Era. it defines pretty printers for data structures widely used
such as Map Set StrictMaybe StrictSequence, etc.
Cardano.Ledger.Pretty  introduces the PrettyA class and provides scores of instances for many data types defined in Cardano.Core and Cardano.Ledger.Shelley

@TimSheard should we close this PR for now?

we still want to re-organize the pretty printing code, but this PR is so old there's not enough here to salvage.


[Bug?] Unnecessary black fill on right side of 'Large' player sized videos.

Image here: http://i.imgur.com/rieAihf.jpg
I'm using the Dev Build version #501 on Firefox 37.0.2. I didn't have this problem until FF crashed for some unknown reason.
I can't find any settings in YTCenter to fix this. No doubt that this would be in the 'Player' tab of the settings, but changing colours, changing aspect ratios, and manually setting numbers for sizes hasn't fixed this problem yet.
If I uncheck the 'Large' box in the player size settings (http://i.imgur.com/PP7bbB8.jpg which makes the player uncentred and puts the suggested videos on the right of the player) the black space is gone: http://i.imgur.com/VlGxhFZ.jpg
Is this a bug or just some weird settings conflict?

Jesus, how many duplicates of this will we get? People, please use the search feature. Heck, you don't even need to do that  much, you actually see all the duplicates before you can create a new issue report.

1, actually. I saw 1 other similar to this (#1695), I'm assuming it's related to the youtube update.

duplicate of
#1695
#1696
#1697
#1705


Update CONTRIBUTING with relevant info

Hi Cliven,
I am new to this project and I want to contribute to this issue.
Could you specify what type of info you want to update in CONTRIBUTING?
Thank you. @lare96


(lambda x: x+3) % Just(2)

(lambda x: x+3) % Just(2)
Traceback (most recent call last):
File "", line 1, in
TypeError: unsupported operand type(s) for %: 'function' and 'Just'

Thanks

from oslash import *
List([lambda x: x*2, lambda y: y+3]) * List([1, 2, 3])

Traceback (most recent call last):
File "", line 1, in
File "python3-3.8.3/lib/python3.8/typing.py", line 875, in new
obj = super().new(cls, *args, **kwds)
TypeError: object.new() takes exactly one argument (the type to instantiate)


style

Hello, @spacewander
This project is in included in our project. When I do my own lint check to my whole project, I found there are both tab and space indent.
Don't know if this need to change.
Thanks.

@RocFang
Merged. Thanks!


Add New Position Under Experience Section

I know this task is complete when:

I see a new position added to the Experience Section. See screenshot of current position:

This new section should be very similar to the one in the red box in the screenshot
New section will have the following details:

Company should stay the same: "Capital Group"
Position should be "Solutions Engineer II"
Dates should be "October 2022 – present"

Dates on the Old position (one red box in screenshot) should be updated to "December 2020 – October 2022"
Ensure present positions are at the top of the page, there should be two after completion of task: 1) New one for "Solutions Engineer II" and the "Oasis Planter Irrigation Solutions"

To get started on this, you'll want to do the following:

On the right side of this page, hit "Create a Branch". This will let you create a "Feature Branch". In the industry, a Feature Branch represents a copy of the master branch (main codebase) where you'll work on your changes related to a Task or new Feature. The naming convention of a Feature Branch differs from company to company... Looks like github just names the branch by default based on the issue # and task title. This is fine.
Once Feature Branch is created, you'll want to checkout the branch onto your local machine so you can start working on it.
Once you've completed the work in the description of the assignment, you'll want to commit and push your changes to your Feature Branch. After doing this successfully, you'll be able to see all your changes for your Feature Branch on github.
Finally, you can create a Pull Request from your feature branch (with your changes) to the master branch. Here, I'll be able to review your change, provide any feedback, and finally approve it so that we can merge your changes to the master branch.


Reduce usage of InstantiatorBackedObjectFactory

This removes some usages of InstantiatorBackedObjectFactory, there are 2 more left but they are more complicated.

@bot-gradle test this

I've triggered the following builds:

Pull Request Feedback (Trigger) (Check)

Build Scan

@bot-gradle test this

I've triggered the following builds:

Pull Request Feedback (Trigger) (Check)

Build Scan

@bot-gradle test APT

I've triggered the following builds:

All Performance Tests (Trigger)

Build Scan

@bot-gradle clean

@bot-gradle test this

I've triggered the following builds:

Pull Request Feedback (Trigger) (Check)

Build Scan

The following builds have passed:

Pull Request Feedback (Trigger) (Check)

Build Scan


improve documentation around worker_processes, multi_accept and rtmp_auto_push

It seems there are some rather sharp edges around this plugin and the stock Debian nginx configuration which I don't see documented anywhere.  Assuming my observations are correct here, it's probably worth making a note of some of this in README at the very least.  I'll also be filing a bug on the Debian side and linking to this issue to improve visibility, as I can't imagine I'm the first person to run into this.
Out of the box, Debian's nginx is configured with:
worker_processes auto;
There seems to be only two options at this point to get a consistently working configuration.  Either set this option to:
worker_processes 1;
which might massively limit performance on busy servers, or uncomment multi_accept in the events block and enable rtmp_auto_push:
events {
        worker_connections 768;
        multi_accept on;
}

rtmp_auto_push on;

If I do not enable multi_accept but keep worker_processes set to auto, I see this problem where I publish a stream but any subsequent calls to play that stream simply hang.  The publishing stream is ingesting into this module correctly as OBS (or ffmpeg directly) don't complain and if I also enable HLS or DASH, I can see the playlist and media chunks rotating through on the file system.  But any attempts to play the stream being published result in the clients hanging and never receiving any data.  Interestingly enough, they are connected as I can see the TCP connections from the clients on 1935 on the nginx host.
After banging away at this for quite some time, I ended up referring to the configuration out of the box of the folks over at Open Streaming Platform to see how they were shipping their software stack as I couldn't understand how this was a stable enough platform to do much of anything on given the problems I was seeing.  At first I thought it might have been their use epoll; that was fixing the behavior I was seeing.  But since I'm on Linux, that should have been getting selected by nginx automatically regardless of whether I was setting it.  After removing the few lines I added to mirror their configuration, I realized it is the multi_accept option that was allowing everything to work consistently when using auto for worker_processes.
Anyway, like I said earlier, assuming I'm correct in how all of this interacts under the covers, it would be great to at least mention something about this so that other people don't simply walk away from using this module due to inconsistent behavior out of the box on Debian (and I'd imagine others possibly).  Especially given that this seems to be one of the few mature, open source methods of doing RTMP at any sort of scale.
Thanks!

I don't use auto or 1,  and it works for very long time
#user  nobody;
worker_processes  8;

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;

events {
    use epoll;
    worker_connections  50000;
    multi_accept on;
}
    worker_rlimit_nofile 500000;

http {

Sorry.  I should have been clearer when I explained that.  If you use any value of worker_process other than 1, you also need to specify multi_accept on; or things are going to hang.  Since you're specifying that in your configuration, things are working.  I imagine if you removed multi_accept on; from your configuration, then you'd see the same hangs I'm describing.

Thank you @nipsy! This issue has been plaguing me lately as well. I came to the conclusion that as long as I pushed the stream to a different instance of nginx everything would work properly... but you got to the root of the problem. It made no sense to me that playing the RTMP stream would succeed only sometimes. But you cleared that up for me. Thanks for the detailed reporting of your findings and the solutions. I really appreciate it!

Sorry. I should have been clearer when I explained that. If you use any value of worker_processes other than 1, you also need to specify multi_accept on; or things are going to hang. Since you're specifying that in your configuration, things are working. I imagine if you removed multi_accept on; from your configuration, then you'd see the same hangs I'm describing.

Thank so much!


[embedded] Mark embedded Concurrency as INSTALL_WITH_SHARED so that it actually makes it into toolchains

The embedded concurrency .a libraries are produced and pass some basic tests, but they are missing from downloadable toolchains on swift.org. Let's fix that with INSTALL_WITH_SHARED.

@swift-ci please test

@swift-ci Please Build Toolchain macOS Platform

Hm, actually this doesn't seem to help.


Diozero

Convert the library to use diozero instead of a python process. This should make it signifigantly more stable.

Just a heads up, for the next version of the program I will be switching to using diozero as it is a much better solution than my current solution of running an interactive python process on the host computer. Currently its on the diozero branch but im finalizing some things in regards to that (aka testing and docs). Theoretically this also expands support to some non raspberry pi boards.

After a quick little test it seems to still work.


ShinyProxy WebURL QueryString to ShinyApp

Hi,
I have built an custom docker image using official ShinyProxy (2.6.0) image
FROM openanalytics/shinyproxy:2.6.0 COPY application.yml /opt/shinyproxy/application.yml EXPOSE 8088
I have accessed ShinyProxy URL with querystring like  "abc=xyz". And i could see all of my ShinyApps under http://localhost:8088/?abc=xyz. But whenever I tried to launch any ShinyApp i am loosing my query string and not able to access them inside my app.
Is there anyway to get that information ?
Also there is another issue which might cause problem is whenever i clicked on Navbar link (Title) from ShinyApp that time also it redirects to http://localhost:8088
My application.yml is standard one.
'proxy:
title: Hey Shiny Proxy !!
port: 8088
authentication: openid
docker:
url: http://host.docker.internal:2375
#net: "host"
cert-path: /home/none
port-range-start: 20000
#default-max-instances: 1
specs:

id: 01_hello
display-name: Hello Application
description: Application which demonstrates the basics of a Shiny app
container-cmd: ["R", "-e", "shinyproxy::run_01_hello()"]
container-image: openanalytics/shinyproxy-demo
#max-instances: 1

id: shinyapp
display-name: Demo application from container
description: Demo App
container-cmd: ["R", "-e", "shiny::runApp('/root/testApp')"]
container-image: shinyapp-abc
#max-instances: 1

server:
forward-headers-strategy: native
secureCookies: false
logging:
root: debug
file:
shinyproxy.log'

Hi
Currently ShinyProxy does not pass-though the query-strings to the app. Also, when you click on a link the querystring will not be preserved.
When we add  support for Shiny bookmarks (https://github.com/openanalytics/shinyproxy/issues/300), this should be supported.  We still want to support this, but we currently don't have a planned date for it.

Hi
Starting with ShinyProxy 3.0.0, any querystring, subpath or hash path added to the URL will be passed down to the app URL. Therefore, the above should work.
BTW, you can change the template of the navbar to change the behavior of the links and buttons, see https://github.com/openanalytics/shinyproxy-config-examples/tree/master/04-custom-html-template


Cant reset my game

I have this problem where I can´t reset my game and every time I uninstall and reinstall the game it just takes me back to where I was. Someone help

No matter what I do I cant pull up the menu and its annpying

Did you right-click on your game and click "delete save"?


Feat: BLOGS page in dark mode

Describe the feature

blog page in dark mode is not up to date
it has very low quality CSS also I want to add high quality stiling hover effect and zoom effect also
and images of that blog sections are also large small I will fix that also

Add ScreenShots
Uploading job do.mp4…
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Go ahead !


Atom freezes when opening

I managed to get Atom into a state where I cannot open it until I run in safe mode once.  I copied my .atom/storage directory.  I notice several files that begin with "editor-" and then have some sort of hash in the name; there's only one that appears to be particularly recent.  Are there any parts of it I could post that might help with diagnosis?

Do you mind zipping up your ~/.atom/storage directory and posting it here?
Also, some extra additional information would be fantastic. Can you tell us:

Which version of Atom are you using?
What OS and version are you running?

Thank you!

Same issue on Linux Mint 17. After update to 1.3.4 atom freezes. Also freezes in safe mode. When I removed content in ~/.atom/storage atom opening without any issues.

Do you need the content in the "buffers" property of the files inside?  It contains quite a bit of code.  I'd be happy to upload it if I strip out that code.

This seems to be happening if you try to open directories where you have split panes activated. Trying to split a pane freezes atom as well.

I'm also experiencing the problem, that very often after closing Atom with a few files opened it will not reopen properly. Even if executed with --safe.   --clear-window-state solves the problem but it feels like i have to execute it every time i want to launch atom. (Which is a very frustrating experience. )


Imu data problem

what if I have no good angular velocity?
I have raw gyro data from my IMU but it drift over time. This is my bag file.
https://drive.google.com/open?id=1ZfoIJP8t_8jl2-QrdE5rl-UfR8lS5YSL
When I enable IMU on cartographer I can see fast rotations that don't correspond with my movement.
A short video:
https://drive.google.com/open?id=11RhA5scSWGDt3ZGeVXt-jpElN3B6YyqT
is my gyro data a problem or is my accel data the problem?

never mind I was publishing in dps, but it need to be in rad/sec
http://docs.ros.org/melodic/api/sensor_msgs/html/msg/Imu.html


Combine firmware flashing steps

You can directly flash a.19 firmware. There is no need to flash A.24 and then the partitions separately.


HELLO WOLD

[Enter feedback here]

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

ID: 064087b4-3a9c-21a1-04e6-af522f587157
Version Independent ID: 1d2dd6fd-4dcd-5d6e-a148-4edadbff9bf4
Content: Serverless functions architecture design - Azure Architecture Center
Content Source: docs/serverless-quest/serverless-overview.md
Service: architecture-center
Sub-service: azure-guide
GitHub Login: @rogeriohc
Microsoft Alias: architectures

@MainaAwudu Thanks for reaching out. The feedback description is missing, and title doesn't provide any info on the issue. We are proceeding to close this thread but feel free to add a comment or reopen the issue with description .


-l flag for hub pull request isn't working

I'm on hub version 2.2.3 and when I try to add -l RELEASE to my hub pull-request command, I get an error
unknown shorthand flag: 'l' in -l
and the usage message doesn't contain -l
usage: git pull-request [-f] [-m <MESSAGE>|-F <FILE>|-i <ISSUE>|<ISSUE-URL>] [-o] [-b <BASE>] [-h <HEAD>]
Are labels supported in version 2.2.3?

No, sorry; labels are slated to come with 2.3.0 which is due soon!
In the meantime you can try to build hub from the master branch.


Add support for Python 3.11 on Github Actions

Closes #187
What I did?
Added Python 3.11 to the version matrix on Github Actions' config files.
How to test?
All Github Actions checks should succeed on this PR, including new checks for linting, testing / coverage and smoke tests on Python 3.11

@dougbrn  I do think this is as simple as adding 3.11 in github actions. Just checking that we are not missing something?


fix logo url

thx yall! just merged the pr over in registry, should be all fixed up once the next docs release goes out.


[ENGOPS-1918] Update Commons-DBCP in Core

COMP-431

Are we planning on upgrading all the rest of commons-dbcp across the suite?

Build Commands:
Build:

ant -Dtestreports.dir=bin/reports/unit-test -Djunit.jvmargs=-XX:PermSize=256m -f core/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -Djunit.jvmargs=-XX:PermSize=256m -f core/build.xml jacoco-integration checkstyle publish-local

Cleanup:
rm -r ~/.ivy2/local || echo no publish local to remove
Changed files:
core/ivy.xml

This is just for the use-case of embedding PDI into a Java project using Maven, which caused a conflict.  I'll take a look at the other projects as well, as it appears to be sprinkled across Mondrian and Reporting Engine, among a few others.

Important note - in the final BA/DI assemblies, DBCP-1.4 is already there in the WEB-INF/lib (even as far back as 4.8.3). This really just makes sure we're compiling against what we already run with. On that basis alone, this is a no-brainer.


What is the benefit of stripping viewBox?

Some libraries use SVGO for optimizing the SVG and I notice that stripping the viewBox is almost always used. However, I always disable stripping because it breaks proper scaling of the SVG. Unless I totally don't understand, what is the 'optimization' that stripping a viewBox provides?

Just as any stripping—minimize number of bytes, increase informational density.

According to your readme:

SVG files, especially those exported from various editors, usually contain a lot of redundant and useless information. This can include editor metadata, comments, hidden elements, default or non-optimal values and other stuff that can be safely removed or converted without affecting the SVG rendering result.

Removing viewBox definitely affects the rendering result, since scaling is then made almost impossible. The question is, why is it turned on by default? It isn't simple meta-data, it is critical viewport information.

Why? It's removed only when width and height attributes are present and equal to, so no information is lost. Finally, one can turn it off if needed.

Removing viewBox still affects the rendering output when width and height are present and viewBox is equal to 0 0 <width> <height>.
I encountered this issue when an upgrade to svgo broke rendering of some scaled inline SVGs on our website (https://github.com/hypothesis/h/issues/5656).
The SVGs in question had an outer <svg> element like this:
<svg xmlns="http://www.w3.org/2000/svg" width="120" height="120" viewBox="0 0 120 120">
…
</svg>

And were being rendered with a CSS class applied that scaled them down to a much smaller size (eg.  16px x 16px).

@robertknight that's incorrect usage, nothing to do with SVGO. Of course if you rewrite width and height, you'll get an error, no matter in which way.

 My understanding is that viewBox specifies the user-space coordinates which are then mapped to the viewport which has a default width and height controlled by the corresponding attributes on the <svg>, but can be overridden using CSS to rescale the image.
FWIW the original SVG file was produced some time ago by a designer using Sketch.

SVGO is an image which may have properties like width and height. Without viewBox attribute it has value equal to 0 0 width height. So if you change size in any way, you have corresponding result. SVG is highly depends on the usage way, so do optimizations. That's is why SVGO is highly configurable.

I have also encountered an issue with this in IE11 as described by someone else here: https://stackoverflow.com/questions/27970520/svg-with-width-height-doesnt-scale-on-ie9-10-11.
When I replace the width and height properties with a viewBox property with 0 0 width height value, it worked fine.
I know we can enable/disable the related plugins to not strip viewBox but it might be worth thinking about stripping width and height instead per default to avoid this?

Just ran into this with SVGO defaults. Seems crazy that by default you break SVG scaling using CSS.
// This won't scale using CSS. This is the default.
<svg xmlns="http://www.w3.org/2000/svg" width="21.001" height="13">

// This will scale using CSS, this is better and should be default.
<svg xmlns="http://www.w3.org/2000/svg" width="21.001" height="13" x="0px" y="0px" viewBox="0 0 21.001 13">

The viewBox needs to be preserved for inline <svg> elements in HTML to properly scale. Leaving out the viewBox breaks this behavior. I don't know enough about the SVG specification to say if it's supposed to default to viewBox="0 0 width height" or not, but the fact is that this issue is present in the latest versions of Chrome, Firefox and Safari. SVGs need to be inlined for a number of common use-cases, usually for changing colors on hover states or different themes like dark mode.
The fact that SVGO is so configurable is really awesome, but many apps like Image Shrinker use the default settings and don't offer options, ultimately breaking SVGs for anyone wanting to scale them inline.
Please see this CodePen: https://codepen.io/dahdah/pen/YzyjRaw
This is a very simple SVG run through Image Shrinker. I've restored the viewBox in one of the copies.
Screenshot:

Please reconsider changing the default value of removeViewBox to false. It's a few bytes more with a significant improvement for web developers on a wide range of tools. And finally, to reiterate on what @rj-coding said:

SVG files, especially those exported from various editors, usually contain a lot of redundant and useless information. This can include editor metadata, comments, hidden elements, default or non-optimal values and other stuff that can be safely removed or converted without affecting the SVG rendering result.

The above example shows pretty clearly that this setting does indeed affect the rendering result, and is not in line with what the SVGO readme promises.

@GreLI are you prepared to reconsider this?

Please change this. I spent a couple hours today digging around to figure out what's going on. The current default is super annoying...

Same for me, the most used case is scalable svgs that doesn't broke with css.
I'm here because I have to modify this weird default behavior and I needed to know how to do it, I see I'm not the only one in this case^^
@GreLI Please reconsider this <3

The same issue...

@GreLI Why this and https://github.com/svg/svgo/issues/505 issues are closed?

I used the -icon prop that set '1em' to height and width and keep the viewbox, if this can help someone...
It did the job for me but it's a weird workaround^^

I also agree with you, viewBox is very important for the scaling specially for web developper. In previous versions of svgo, removeViewBox was false by default. You should reconsider setting this option to false by default.

Given this discussion, I created a PR to remove this plugin from the list of default plugins. #1461
In the meantime, this is the svgo.config.js I am using on my website:
const { extendDefaultPlugins } = require('svgo');

module.exports = {
  multipass: true,
  plugins: extendDefaultPlugins([
    // viewBox is required to resize SVGs with CSS.
    // @see https://github.com/svg/svgo/issues/1128
    {
      name: 'removeViewBox',
      active: false,
    },
  ]),
};

@GreLI viewBox is such an important field needed for scaling SVG images. I'm surprised that we remove it by default just for the sake of "minimizing number of bytes". Let's get https://github.com/svg/svgo/pull/1461 in.

I've updated PR #1461 to fix a merge conflict.
Now that extendDefaultPlugins has been deprecated, this is the svgo.config.js I am using on my website:
module.exports = {
  multipass: true,
  plugins: [
    {
      name: 'preset-default',
      params: {
        overrides: {
          // viewBox is required to resize SVGs with CSS.
          // @see https://github.com/svg/svgo/issues/1128
          removeViewBox: false,
        },
      },
    },
  ],
};

I understand the issue, sometimes 'viewBox' is really valuable, but it's not a good idea to dictate disabling default optimization by minority of users. Most users are ok with it and they just don't write here, it's totally ok for them. Probably it's a good idea to disable the plugin in some super-safe preset.

Working daily with svgs intensively I agree very much with above comments: It's great that svgo is configurable and that we can decide ourselves to enable or disable the stripping of the viewBox attributes. But IMO the most logical setting for this is to NOT stip this setting by default. It just breaks the scaling for lots of svg's. I'm clearly not the only one who thinks like this.

sometimes 'viewBox' is really valuable, but it's not a good idea to dictate disabling default optimization by minority of users

I don't agree at all. The attribute is valuable most of the time, not 'sometimes'. Users who don't complain about this are probably users who either don't use svgo, don't take the time to post a message here, only work with simple svg stuff in an image tag or perhaps even don't know how svg works and that something like a viewBox exists.

The attribute is valuable most of the time…

While most users

…only work with simple svg stuff…

Don't you see a contradiction here?
It's impossible to conform everyone. Unless you're doing nothing. But that will raise a question too.

Perhaps readme should be updated. SVGO mostly optimize without a visible affect on rendering result. One of the most effective optimizations is reducing float numbers precision. Usually, one will not notice a change. However, it can be seen with extreme zoom. Again, it's not a problem in most cases.
But it's an offtopic. Removing viewBox doesn't affect rendering since an image has dimensions (otherwise it's kept as is). Intervening with this dimensions affects the rendering, not removing attribute itself. So, this is pro-usage like editing tool, which is minority of SVGO usage. I'm afraid people here don't get my point, because they don't like it.

Perhaps readme should be updated. SVGO mostly optimize without a visible affect on rendering result. One of the most effective optimizations is reducing float numbers precision. Usually, one will not notice a change. However, it can be seen with extreme zoom. Again, it's not a problem in most cases.
But it's an offtopic. Removing viewBox doesn't affect rendering since an image has dimensions (otherwise it's kept as is). Intervening with this dimensions affects the rendering, not removing attribute itself. So, this is pro-usage like editing tool, which is minority of SVGO usage. I'm afraid people here don't get my point, because they don't like it.

You are wrong, removing the viewBox affects rendering. Please read the viewBox documentation mozilla and check the examples, it's the same svg used three times with three different viewBox, I let you check the result.

Removing viewBox doesn't affect rendering since an image has dimensions

I think it affects a lot? If we inline an SVG file and scale it using CSS, the SVG has to have a viewBox property to get properly scaled?
Example: https://codepen.io/lzl124631x/pen/jOwbPXv

You are wrong, removing the viewBox affects rendering. Please read the viewBox documentation on mozilla and check the example, it's the same svg used three times with three different viewBox, I let you check the result.

Nope. It has nothing with the issue. Please read all I wrote carefully and thoughtfully.

You are wrong, removing the viewBox affects rendering. Please read the viewBox documentation on mozilla and check the example, it's the same svg used three times with three different viewBox, I let you check the result.

Nope. It has nothing with the issue. Please read all I wrote carefully and thoughtfully.

I'm giving up, no matter how we (not only me) show/explain/demonstrate you that viewBox affects the rendering, you still disagree...

@woodreamz I support you. You're correct. Anyone who's tried to actually build a website and scale an SVG knows what you're asking for is correct.

I agree as well, as I have posted about this 2 years ago because of rendering issues I experienced in browsers when using the default settings.
I believe the quality/usability improvement this change would provide to SVGO is much bigger than a couple extra bytes of file size in optimized SVGs.

I can't believe we are 2,5 years later after I filed this issue and after multiple people supporting my position nothing has changed including the arguments.
Rendering behavior > stripping bytes.
And if you think viewBox does not appear to affect rendering behavior then you clearly don't understand the varied use-cases of SVG's. Saying that 'an image has dimensions' clearly shows you have no clue what a viewBox does.

@GreLI please consider approving #1461. I'm sure it's clear that having a viewBox with matching width & height values meets the following criteria for changing the default:

it is allowed by the SVG spec linked from the code

browsers will apply different rendering rules based on the presence/absence of viewBox
CSS sizing is commonly applied, and frequently preferred over hard-coding pixel values in HTML
The default configuration should produce a result that is visually indistinguishable from copy-pasting the SVG element directly into the HTML

We know that some information is lost by removing the viewBox and we know that sizing images using CSS common (and recommended) practice. At the moment, it sounds like the claim is that the SVGO maintainers are okay with compromising that usage for the benefit of saving ~20 bytes from the processed output of each element, which doesn't seem right.

I've updated PR #1461 to fix a merge conflict.
Now that extendDefaultPlugins has been deprecated, this is the svgo.config.js I am using on my website:
module.exports = {
  multipass: true,
  plugins: [
    {
      name: 'preset-default',
      params: {
        overrides: {
          // viewBox is required to resize SVGs with CSS.
          // @see https://github.com/svg/svgo/issues/1128
          removeViewBox: false,
        },
      },
    },
  ],
};

i think the issue is solved if you just create your own config file. this is my svgo.config.js in Application Support / com.bohemiancoding.sketch3 / Plugins:
module.exports = {
  plugins: [
    {
      name: 'preset-default',
      params: {
        overrides: {
        	removeViewBox: false,
          	cleanupIDs: {
   				prefix: {
      				toString() {
        				return `${Math.random().toString(36).substr(2, 9)}`;
      				}
   				}
  		  	}
        },
      },
    },
  ],
};

it keeps viewbox and creates unique ids if you have many complex inline svgs on one page

@GreLI here's a real world example:
Before using SVGO:

After, with default settings:

In the past I've been really pleased with the smart decisions SVGO makes in that I almost never have to tweak the default settings and will always get a lot of value out of it. However, SVGs are notoriously hard to size, and viewBox definitely has an affect on how they render as shown here, so I'm agreeing with the crowd here that it should be retained by default. Users who are shooting for aggressive filesize reduction would still be able to change the setting, knowing that it might visually break some things, but even they won't see a very noticeable change from this short string, even across many SVGs.
Appreciate your work, SVGO is invaluable. Thanks for considering updating this default.

Just wanted to jump in and write on this issue, because I just learned the hard way we are using this library via another library with Webpack. It looks like an amazing library, and we would definitely use it in the future for projects with more complex SVG optimization needs.
But for now, we had some malformed SVGs and spent quite a bit of time trying to determine why they are broken only on production. I don't know much about the internals of SVGs. But after googling, I found this page, our problem, and our solution.
Not sure who's right on this issue. But if I didn't get lucky with my google search, I may have never found this library. It may be worth considering that an SVG novice (like me) may also not know they have an issue or where to comment when they do.

https://github.com/scriptex/svgo-add-viewbox

thats unnecessary
you can just disable removing viewbox
(vite config)
    svgLoader({
      svgoConfig: {
        plugins: [
          {
            name: 'removeViewBox',
            active: false,
          },
        ],
      },
    }),

But the issue is that not every consumer of SVGO allows modifying the SVGO config. And the default behavior of removing viewBox is wrong.

if you want to keep the presets ... try this:
svgoOptions: {
    plugins: [
         {
            name: "preset-default",
            // while https://github.com/svg/svgo/pull/1461
            // is not fixed.
            params: {
                overrides: {
                   removeViewBox: false,
                }
            }
         },
    ]
}

Stripping a viewBox is always incorrect and, in effect, corrupts the SVG data; the viewBox is what specifies the size of the internal coordinate system and is what is referred to by all of the elements inside the SVG tag.
If it's missing the browser/viewer will synthesize a viewBox based on the element size, but the element size does not necessarily match the width/height attributes on the element (e.g. overridden by CSS), and it will make the "scalable" vector graphics, well, not scale at all: it causes the content to be drawn anchored to the top left corner and will be cropped if it doesn't fit.
The only case where it appears correct is when the element is displayed at exactly its intrinsic size (the width/height attributes). Browsers will synthesize a missing width/height from the viewBox and use it as the intrinsic aspect ratio, but they will also expand the SVG to fit all available space, so removing (both) width and height is also not 100% safe.
The safest default would be to preserve both viewBox and (one of) width or height; possibly with an option to strip both width and height if they match the viewBox to make the SVG expand-to-fit. Stripping viewBox instead corrupts the SVG data.

it's not a good idea to dictate disabling default optimization by minority of users. Most users are ok with it and they just don't write here

Also, sorry for my tone, but this is just a headcanon. These "most users" who are "ok with it" are speculative and is impossible to prove correct or incorrect. The users who have been posting on this issue, however, are quantifiable.
And two can play the headcanon game. There's also the "most users" who stumble upon this problem and don't comment because someone else has already commented, or who are able to change their config to disable removeViewBox, or who manually edit their svg to dodge the rule.

@GreLI Please see this code snippet here on stack overflow, the SVG can't be scaled without the viewport, the solution to the problem, is to add the viewport back.
SVG stands for Scalable Vector Graphics. Without the viewport is is just VG.
Should be called VGO.

@mangelozzi you missed the point. If you change size of SVG, you are essentially editing it. Remove sizes then, in that case viewBox will be preserved. Or configure SVGO to do whatever you want, since you want something different that most people do.

I understand the point of SVGO is to optimize your SVGs, but it still seems odd to me that an approximate 23 byte savings is worth completely removing one of the core use cases of SVG as a file format.
I respect that the default viewBox behavior is ultimately your decision, even if I disagree with it.
Would you consider adding an easier command-line option for disabling viewBox stripping? Like svgo --preserve-viewbox or svgo -p or something? It's pretty difficult for a new user to figure out how to change this behavior.

@mangelozzi you missed the point. If you change size of SVG, you are essentially editing it. Remove sizes then, in that case viewBox will be preserved. Or configure SVGO to do whatever you want, since you want something different that most people do.

By applying CSS styles to scale a Scalable Vector Graphic with CSS rules, one is not editing the image. If you right click and click save image as, it is the same image. Removing the viewBox is actually editing the image, in the way that one is editing the way the scable vector graphic was intended to scale.
Maybe as an idealist and someone who is also a perfectionist (which I respect), you cannot let go of this belief. Maybe then see it as trading a few inperceptible bytes in terms of real world difference, for saving many developers hours of trouble shooting this problem (a real world difference), and for the very important feature of being able to scale the image at various places on a webpage to suit the screen size/page layout (a real world difference).

When we're dealing with an arrogant dev like @GreLI

I don't think that insulting a project maintainer is gonna get us what we want, @Lucienest...

When we're dealing with an arrogant dev like @GreLI

I don't think that insulting a project maintainer is gonna get us what we want, @Lucienest...

I'm not insulting honestly, but I'm just expressing my disappointment @wavebeem
have read the entire conversation and found that he'd ignore every valid comment
that doesn't satisfy his decision.
confirmation bias kills most healthy projects.
viewBox is a crucial part of the SVG,
but svgo won't respect this essential behavior.

@Lucienest I'm disappointed too, that my valid comments are ignored. And that the minority demand changes at the cost of (silent) majority. All that because they can't tune the tool in the way they want. width and height are crucial too, but why you abruptly change them and then cry, the image changed? Remove them and that is not a case anymore. Why are you so stubborn?

@GreLI
The problem is not that you are ignored. Your comments are completely invalid.
View box is CRUCIAL for rendering accurately.

@GreLI said:

If you change size of SVG, you are essentially editing it.

and:

width and height are crucial too, but why you abruptly change them and then cry, the image changed?

No one is changing the width and height attributes. You are misunderstanding what we are doing. We are leaving the SVG source exactly as-is after running it through SVGO. We are then taking that SVG source unmodified and adding to a HTML page. The CSS from that HTML page applies to the SVG markup (again, not modified) and the CSS changes the size of the svg DOM element via CSS properties. No source attributes of the svg element are changed at any time.
Please look at the HTML source in the codepen example I posted in March 2021. https://codepen.io/johnalbin/pen/yLggyXv It compares the rendering of one SVG with a viewbox to an identical SVG without a viewbox.
SVG with viewbox:
<div class="shrink">
  <svg width="50" height="50" viewBox="0 0 50 50" xmlns="http://www.w3.org/2000/svg">
    <path d="M25 10C30.263 0 40.789 0 46.053 5c5.263 5 5.263 15 0 25C42.368 37.5 32.895 45 25 50 17.105 45 7.632 37.5 3.947 30c-5.263-10-5.263-20 0-25C9.211 0 19.737 0 25 10z" fill="currentColor"/>
  </svg>
</div>

SVG without viewbox:
<div class="shrink">
  <svg width="50" height="50" xmlns="http://www.w3.org/2000/svg">
    <path d="M25 10C30.263 0 40.789 0 46.053 5c5.263 5 5.263 15 0 25C42.368 37.5 32.895 45 25 50 17.105 45 7.632 37.5 3.947 30c-5.263-10-5.263-20 0-25C9.211 0 19.737 0 25 10z" fill="currentColor"/>
  </svg>
</div>

As you can see, the SVG source is identical in the two examples and all the attributes (including width and height) are the same except for the missing viewBox attribute. But the two examples render differently. The one with a viewBox attribute scales correctly; the one without a viewBox does not scale at all and the image defined by the path is affixed to the top left corner of the svg containing element regardless the rendered size of the svg containing element. In the codepen, I applied a light grey background (with CSS) to the svg elements to make the rendered dimensions of the svg clear.
Specifically, this is the CSS properties that are being applied via rulesets defined in the HTML document:
  width: 25px;
  height: auto;

With a svg viewbox attribute, the browser knows how to scale the image from its attribute-defined 50px width down to the CSS-requested 25px width.
For argument completeness sake, I'll add that we cannot just edit the svg for different sizes because we need to be able to use SVG's ability to scale on the fly. You'll see that the codepen example shows an animation that absolutely requires the SVG viewbox attribute.

One last thing…
@GreLI said on Jul 18, 2019:

SVG is an image which may have properties like width and height. Without viewBox attribute it has value equal to 0 0 width height. So if you change size in any way, you have corresponding result.

That is incorrect according to the SVG spec.
The SVG 1.1 spec implies there is no default value for the viewBox attribute, but the SVG v2 spec is very clear. The initial value of the viewBox attribute is not 0 0 [width attribute] [height attribute]; it is “As if not specified”.

@JohnAlbin you missed the point. It doesn't matter whether you change width and height through SVG or CSS. You're essentially change the image.
CSS is a part of SVG, especially now. E.g. you can use rgba() colors and many other modern features, despite it's not described in SVG spec. Though it will probably work only in browsers and maybe partially in Inkscape. It was a deliberate choice by spec authors.
Funnily, your second comment proves my point.

@GreLI You essentially change the image.
No, we are not changing the SVG image. It is literally the SVG markup as it comes out of the svgo tool (depending on which plugins are enabled). You assertion that we are changing the image is false. Applying CSS affects the rendering, but doesn't "modify" the SVG source. You keep repeating yourself without explaining yourself any better. Please try using a different explanation of your argument. I can't follow your logic.

Funnily, your second comment proves my point.

How so? I was simply pointing out that you misunderstood the spec about what the initial value is for the viewBox attribute.
SVGs can only “stretch to fit a particular container element” when they include the viewBox. By removing that attribute, you are removing that feature from SVGs. And many, many web developers use that feature.

@GreLI Wait, are you arguing that displaying an SVG at different sizes is changing the image?
What we are asking for: preserve the viewBox by default so an SVG can fulfill its role of being a scalable vector image. This is a requirement for responsive websites, which is nowadays all websites (and not at all a minority).

SVG stands for Scalable Vector Graphics

@GreLI Are you really not aware that scaling the SVG outside of the SVG with CSS is not affecting the base source code of the SVG? How is that changing the image?

@jdahdah what do you mean? I don't get the question. Regarding the topic, as I said before, viewBox by default is removed when and only when it equals to "0 0 width height". So, just removing width/height, since size already get overwritten, will solve the issue. Of course, one can also set their config to configure SVGO plugins.

@mahnunchik Of course, that's why I disabled the plugin that did so several years ago (exact opposite to removeViewBox).
In fact it is equal, unless you change width or height some way or another. That thought is hard to get for the most who comments here.

But the plugin is enabled by default.

@jdahdah what do you mean? I don't get the question. Regarding the topic, as I said before, viewBox by default is removed when and only when it equals to "0 0 width height". So, just removing width/height, since the size already get overwritten, will solve the issue. Of course, one can also set their config to configure SVGO plugins.

But sometimes we don't have control over the SVG's in all cases. They are uploaded by clients for instance. I can't just remove width and height. Aside from that, it makes absolutely no sense at all.
Just disable the plugin by default. Is that so hard?

@avwie you do have control over SVGO. Just make a config. Is that so hard?
Why do you think you decide for all of users? Most of them want maximum optimisation SVGO can provide.

@mahnunchik I was talking about removeDimensions plugin. It's not in a default preset. Do you follow?

I would argue that optimizations must have a degree of safety. If SVGO "optimized" your SVG by removing half of it, that would not be OK. Users understand that optimizations generally do not perceptibly change the input, at least not with default settings.
I think most people in this thread realize that you can change the configuration. The discussion is around the default setting. Consider that for every 1 person who has shown up here to suggest that this default value is unsafe for the majority of web SVG use cases, probably 1000 other developers saw this thread and decided it was a waste of their time to argue in here.
I don't understand how you can insist that "most" users want to have critical information for web SVG usage removed from their SVGs. It's been demonstrated that this default setting is unsuitable for web development. I've also pointed out that "just" making a config isn't as easy as you make it sound.
That being said, I'm not sure what would change your mind at this point. I feel like we either have to accept as a community that the defaults you want to ship don't make sense for our use case, or start a fork of svgo (a huge undertaking).
I've held out hope for the last 3 years that perhaps you would eventually change your mind, but I think this is just turning into a big waste of everyone's time.

Yep, the idea about different presets with different levels of safety is floating here for years. E.g. “supersafe”, “average”, and “squeeze it as much as you can”

Yeah, C compilers ship with various optimization levels you can enable. It could totally work here too!

This is insane :) Few bytes vs critical attribute.
Is it possible at least put this "switch it off" in the readme in examples, so a lot of devs will save some working time when searching why the critical attribute has disappeared? Thanks

@julpat every byte matters. It's right in the readme under “Configuration” section.

@GreLI So if we were to have different presets… We need to agree how the removeViewBox affects the SVG so we can determine which preset that plugin can go into. “supersafe”, “average”, and “squeeze it as much as you can”, etc. Right?
Do you agree that the removing the viewBox attribute (even when the SVG has width/height that match the viewBox values) DOES change the rendering of the SVG file? See my comment above on October 24 for an example. If you have a counter example, please provide it.

@JohnAlbin to be more precise it does change rendering if and only if you are changing image size props (i.e. width or height). Some people make excuse that they doing it via CSS, but that doesn't matter. When you change the image no matter how, its rendering changes. It happens so even with raster image, so disputes here are unproductive. It's like to dispute law of physics. It just works that way.

@JohnAlbin to be more precise it does change rendering if and only if you are changing image size props (i.e. width or height). Some people make excuse that they doing it via CSS, but that doesn't matter. When you change the image no matter how, its rendering changes. It happens so even with raster image, so disputes here are unproductive. It's like to dispute law of physics. It just works that way.

What does the S stand for in SVG?

it does change rendering

So, your answer is yes. Removing the viewBox SVG property prevents CSS from being able to scale the rendering of the SVG so that it can be resized to fit the SVG's HTML container. As described by SVG 1.1 specification, section 7.7: The ‘viewBox’ attribute
Great. Glad we agree.
Now, can we agree that the removeViewBox plugin cannot be put into a "supersafe" preset?
I would also assert that cannot be put into any web-compatible preset, if one were to be created because the viewBox attribute is absolutely required by standard CSS practices in frontend development.
I don't see any problem with the removeViewBox plugin being put into a “squeeze it as much as you can” preset either. I won't use it, but "squeeze things until they break the web" isn't for me.
Now the question remains of what goes in a "default" preset. I would prefer one that is web-compatible, but that is up for discussion.

No, you get me incorrect, my answer is no. However, I understand specific cases in which the plugin could be undesirable, but they are not generic ones. Yes, “safe” IMO could have it off.

@GreLI it's just a simple change that we're asking u to make, this will make SVG's 100% compliant and have no more issues.
Happy ending :)

Any news about safe config? What should be the default config according to many people in this discussion.

@GreLI it's just a simple change that we're asking u to make, this will make SVG's 100% compliant and have no more issues. Happy ending :)

And the PR is ready since more than one year #1461
Several people have demonstrated the importance of the viewBox, but I think he went too far to admit he is wrong...

@GreLI it's just a simple change that we're asking u to make, this will make SVG's 100% compliant and have no more issues. Happy ending :)

And the PR is ready since more than one year #1461
Several people have demonstrated the importance of the viewBox, but I think he went too far to admit he is wrong...
8/

well, unfortunately, that's how open-source project works.
if the owner ignores all valid points and sticks with his bias,
it won't ever proceed.
we might consider a fork but that's not much preferred.
@woodreamz

@Lucienest Is it really easier to fork than just make a config that will fit you well? Also, the level of discussion here seem like people aren't really involved into open source.

@GreLI just accept the PR https://github.com/svg/svgo/pull/1461/ it makes working with SVG for many developers much easer 😉

@GreLI Did you have a chance to look at my question from a couple of weeks ago?
It feels a bit like you're purposefully ignoring it since you don't have an answer for it. In this case, maybe you could consider if everyone's arguments in here have some merit after all. This discussion seems to be pretty stuck because you don't listen to any arguments. But there's no shame in changing your position if the arguments are in favour of that. In fact, that's all that discussions are about – not winning or defeating everyone else, but finding the best solution. Nobody would think less of you if you decided to change your position and implement the requested change. In fact, everybody here would probably be very grateful since it will make a small aspect of our everyday work much easier. I know I would greatly appreciate it.

@GreLI If I understand you correctly, you're strongly opposed to using CSS to resize an SVG. So if an SVG has native dimensions of width="800" height="400", the SVG should be displayed at exactly those dimensions on the page. If I want to display this SVG at 600x300, instead of using the existing SVG and changing the size using CSS, I should export the SVG at this exact size. So in your view, putting the SVG with the native 800x400 resolution in my HTML and then using CSS to resize it to 600x300 is bad practice and not supported by SVGO because you consider it an antipattern. Is this correct so far?
In this case, I would ask you how you would handle responsiveness. Let's say the SVG is the site logo that's placed at the top of the page. On large enough viewports, the logo is displayed at the native resolution (800x400) and everything is fine, it works without the viewBox. But on smaller screens, I don't want overflow, so I'll limit the logo to the width of the container (e.g. max-width: 100%).
Without the viewBox, this will result in the logo being cropped instead of having it scale down. This is demonstrated nicely by the examples provided by @JohnAlbin.
Now, you have said multiple times that this is usage is unusual and/or somehow incorrect. But I would argue that this is pretty much the standard usage of an SVG. I can't think of a single example of having a large SVG that should not be responsive, but instead cause overflow or be cropped on smaller screens. And I can't imagine that there's a silent majority that prefers this behaviour over having the SVG scale to the size defined by CSS.
I don't think this is a fringe use-case, either. Almost all sites have some sort of logo. Most logos are simple enough that an SVG will be much smaller than a PNG file. They're small enough that they should be embedded in the HTML instead of loaded externally (by using an <img> tag) – and embedding the SVG is necessary if you want to do any sort of animation with the logo, like changing a fill colour on hover or animating a part of the logo. So almost all sites that have a logo they want to optimize with SVGO will run into this issue.
If I have understood your viewpoint correctly – and please correct me if I got it wrong – how would you solve this issue if not by including the viewBox in the SVG? And if including the viewBox is your preferred solution, wouldn't this make sense to have as a default?

I think there seems to be a misunderstanding here,
SVGO is a tool that is supposed to optimize the SVG by removing
the unnecessary metadata/comments that don't affect the SVG rendering.
So, the input and output rendering is expected to be 1:1
but removing the viewBox breaks this promise.
If an SVG already has viewBox it means the developer knows what he's doing
and well aware of the usage or nuances of the following attribute.
SVGO shouldn't be opinionated here.
@GreLI

@mahnunchik that's what I talked about. People here are not really involved.
@MoritzLost It was discussed several times. If you are breaking image by changing it sizes (by any means: attributes, css properties or whatever), it'd be broken. Just don't do it. Or make a special config for these cases. What makes you think that you can decide for everyone?

@GreLI isn't a primary feature of SVG files their ability to scale? I'm guessing that's where a lot of people's confusion comes from here, as the default viewBox optimizations break that core functionality. Fantastic tool, but I've always wondered why a separate config was necessary to support one of the main features of SVG files.

@GreLI You haven't answered my question though. I have a logo that I want to place on a page as an SVG. Here's a minimal example: https://codepen.io/MoritzLost/pen/wvxvbdV
I've optimized the SVG with SVGO. The first test case is the default SVGO output, for the second one I've added the viewBox attribute again. Observe what happens if you make the window smaller. Without the viewBox, the logo is cropped. With the viewBox, it scales nicely with the window size.
Have you ever put a logo in the form of an SVG on a web page? If so, was your client fine with the behaviour in the first example?
This is a super simple usage, not a special niche use-case or edge-case. Please example to me what I'm missing here.

Are you saying that putting a logo on a page is a special case for SVGO and should require a custom config to work properly?
If not, how would you solve the issue regarding the cropped logo with the default output generated by SVGO?
Or are you saying that the cropping is the correct behaviour?

Are you really sure that SVGs, Scalable Vector Graphics, shouldn't be allowed to scale?

@MoritzLost ignoring my answers and spamming “You haven't answered” wouldn't get you anywhere.  Please, follow GitHub Community Code of Conduct.

@MoritzLost ignoring my answers and spamming “You haven't answered” wouldn't get you anywhere.  Please, follow GitHub Community Code of Conduct.

You aren't answering our queries properly and saying others to follow the Code of Conduct?
I don't see their comments violating CoC either.

Whoops, I think this is an upstream issue with the SVG specification. What do you think @GreLI, should we fork https://github.com/w3c/svgwg/ and rename it to NSVG (Not Scalable Vector Graphics) so we finally have a format that matches the goal you apparently have with (n)svgo?
Here is a fork I made, I renamed everything to the newer, more fitting name:
https://github.com/nnmrts/nsvgwg
Also feel free to take a look at the latest commit I pushed, changing the behavior of the viewBox attribute so it is in line with (n)svgo's philosophy and your totally acceptable way of acting like this attribute doesn't affect rendering and if it affects rendering it's the user's fault because they are using it wrong or in your setup you just don't have access to neither the affected svg files, nor the svgo config used, so you would have to fork or monkeypatch parts of your dependencies to fix "broken" svg files you naively surrounded with CSS styles to make it responsive, thinking the maintainer of a repo with 18k+ stars probably made reasonable decisions to mitigate issues with optimizing and displaying a 20+ year old format in conjunction with even older markup and stylesheet formats - oh my sweet summer child:
https://github.com/nnmrts/nsvgwg/commit/f862750f42410fd3c96c8465e13b45d8ee0f8a72

this is a 3.5 year old thread, everyone. i think your effort would be better spent making a fork of svgo and trying to popularize it than posting in here.
posting snarky comments or trying to explain the situation 10 times isn't helping.

For the sane developer:

module.exports = {
  pretty: true,
  plugins: [
    {
      name: 'preset-default',
      params: {
        overrides: {
          removeViewBox: false,
        },
      },
    },
  ],
};

In the CLI run:
svgo config="config.js" *.svg

@julpat every byte matters. It's right in the readme under “Configuration” section.

I thought to point out in the readme exactly this option removeViewBox which is ruining SVG.

@julpat every byte matters. It's right in the readme under “Configuration” section.

Maybe you should read your own readme file then:

SVG files, especially those exported from various editors, usually contain a lot of redundant and useless information. This can include editor metadata, comments, hidden elements, default or non-optimal values and other stuff that can be safely removed or converted without affecting the SVG rendering result.

@julpat every byte matters. It's right in the readme under “Configuration” section.

Maybe you should read your own readme file then:

SVG files, especially those exported from various editors, usually contain a lot of redundant and useless information. This can include editor metadata, comments, hidden elements, default or non-optimal values and other stuff that can be safely removed or converted without affecting the SVG rendering result.

This has been my first issue filed ever on GitHub and boy.... does it keep giving.

The README is hypocritical, I've pointed this out before but the owner would simply ignore those.
I'm so fed up with these, it's not even a breaking change.

@MoritzLost ignoring my answers and spamming “You haven't answered” wouldn't get you anywhere.  Please, follow GitHub Community Code of Conduct.

@GreLI You haven't answered, though. I have asked some questions regarding your stance on this issue and some problems I'm seeing with it. You haven't answered a single one of those, but just repeated the same non sequitur about 'changing the rendering' you have used multiple times.  I have written multiple paragraphs to try to understand your reasoning, explain why I disagree and kindly where my reasoning is wrong. You're the one who is not willing to engage at all, instead resorting to short, intellectually dishonest replies. Pointing to the code of conduct because someone disagrees with you is laughable. Why is it so difficult for you to accept that you're wrong?

he's doubling down instead of acknowledging it.

I hove nothing more to add but this was a much needed break after fiddling the first time with SVGs in a web-context coming from Latex. I tried every setting of width and height in CSS in the <svg> tag, I read webpage after webpage of tutorials on how to get this thing, which has SCALABLE in its name to scale. Then I found this. Manually added a viewBox Attribute to all my SVG files with 0 0 [width] [height] and now everything is working fine. I used the last 2 hours to relax and to read this issue, because at this point this isn't an Issue this is comedy.

Wasted a couple of minutes on this problem today wondering why the SVGs were scaled incorrectly.
(on the other hand, it lead me into this Battle Thread filled with Don Quixotes🍿)

Ok. I commented in this thread back on Sep 10, 2021. And I have been 🍿 watching we "minority of users" complaining in this thread.  I was using SVGR to render SVG as React component and I found that the SVG file loses viewport attribute thus can't resize properly.
voice in my head -> SVGO: "SURPRISE M...F...r!"

Ok. I commented in this thread back on Sep 10, 2021. And I have been 🍿 watching we "minority of users" complaining in this thread.  I was using SVGR to render SVG as React component and I found that the SVG file loses viewport attribute thus can't resize properly.
voice in my head -> SVGO: "SURPRISE M...F...r!"

Thanks, for ignorance and arrogance

This looks like a community-maintained repository. Shouldn't this issue be put to vote?
On one hand, disabling removeViewBox seems to be a more sensible default. On the other, doing so would be a breaking change which affects all projects that didn't override it in config, if they would upgrade to a new release with the change.
We could require the plugin to be always specified in config with true or false, forcing all upgradees to decide which behavior they prefer instead of being surprised by a change in the default behavior. (I realize this isn't ideal for CLI usage.)

@ADTC It's not "community-maintained" in a sense that we could just "put" this issue to vote.
The most "active" maintainer nowadays is @TrySound, who seemingly abandoned this repo a couple of months ago. Seems like @GreLI also has rights to merge a PR, but we know their position...
We can't find out exactly who has admin access to this repo but there are two more @svg organization members (@rpominov and @deepsweet), both seem to not care about this repo anymore as well, otherwise a crazy person like @GreLI wouldn't have admin access to it anymore.
I'm just waiting for the moment @GreLI snaps and unpublishes the package or publishes it with some russian propaganda (something similar happened with another package in the past), so more people will notice and work on a fork.
So yeah, the only realistic option here is a fork, I'd love to work on one but don't even have time to set it up.

I'm the original author as it says in the package.json. I have all the possible access both here and on NPM, but not the time and necessary context to continue working on the project. For many years.
At the same time I can't just blindly merge PRs to the project with 15M NPM downloads per week, so I've tried to look for maintainers over the years. It's way more complicated than it seems to be, starting from the observation that there are no many candidates. In fact, there are none. One thing is to merge old and stalled for months PRs, and another is to develop it all further and push forward.
The only realistic way to dramatically change this situation is to contribute and be ready to become a new maintainer.
Talk to me.

@deepsweet thank you so much for coming back to chime in! I guess the position of active maintainer is still open and unlikely to be filled any time soon.
In the meanwhile though, do you mind helping us update the Readme? I'd like to start with my own PR #1731 which organizes the content to be more readable without adding anything new.
There's a discussion in the same PR about how to inform users of quirks like this, which I think would be best resolved by adding a FAQ or Troubleshooting section in the Readme. I can add it to the same PR or open a new one.
I think changes to the Readme are much safer to merge than changes to the code. The Readme will also reflect in the NPM repository site so it is worth updating with new and important information.

I'm the original author as it says in the package.json. I have all the possible access both here and on NPM, but not the time and necessary context to continue working on the project. For many years.
At the same time I can't just blindly merge PRs to the project with 15M NPM downloads per week, so I've tried to look for maintainers over the years. It's way more complicated than it seems to be, starting from the observation that there are no many candidates. In fact, there are none. One thing is to merge old and stalled for months PRs, and another is to develop it all further and push forward.
The only realistic way to dramatically change this situation is to contribute and be ready to become a new maintainer.
Talk to me.

all comments got single-handedly ignored by @GreLI
do we want a dictator-like maintainer like him?


Beta review of ASHG prototype

Month-end demo in advance of final iteration and test cycle.

Meeting scheduled for review 30Aug2018.
DECISION 20Aug2018: Focused review of Gecko plot as most complex and thus priority for testing with real data for all.
Notes from discussions here:
https://docs.google.com/document/d/1Y9K0ZTkMFHfA6Q-HSIFljJDimQ7aqHOwYIYi7dHUyZU/edit#heading=h.854al3qxj8nr

Next review scheduled for 07Sep2018 to review with real data where possible.

In the calendar now.


Is there a way for disabling underlines?

So many underlines (specifically in golang), makes reading the code way more challenging than it already is. Is there a way to disable those underlines? Perhaps a textmate trick or something?

Yes there are a setting actually.
Go to Settings/Extensions/Codemos Modern/Text Decorations/Underline and untick the checkbox.


fix sudoku example test errors

Minimal changes to make tests for sudoku work, as in issue #311

I wonder if instead of initialize... there should be
  @method update(sudokuInstance: Sudoku) {

to manually initialize the sudoku hash.

I actually want to make it work with init(), but I think it'll need a change to the CLI's deploy logic

but init() does not take arguments, how do you pass the hash() from sudokuInstance ?

thanks for making this PR and highlighting what needs to be fixed! I ended up inlcuding this as part a larger PR (https://github.com/o1-labs/zkapp-cli/pull/315), so closing this one


surgery.replace_module_classes should copy initialization weights where possible

🚀 Feature Request
Right now, surgery.replace_module_classes does not preserve any initialized model weights for modules that are replaced. However, in cases where there is a 1-1 mapping of weights in the replacement (ex. in StoachasticDepth), we should preserve initialized model weights.
Motivation
Surfaced by a user.

Closing. Tracking elsewhere as low pri


feat(line)!: impl From<Cow> for Line

BREAKING-CHANGES: Line now implements From<Cow<str>
As this adds an extra conversion, ambiguous infered values may no longer
compile.
// given:
struct Foo { ... }
impl From<Foo> for String { ... }
impl From<Foo> for Cow<str> { ... }

let foo = Foo { ... };
let line = Line::from(foo); // now fails due to ambiguous type inference
// replace with
let line = Line::from(String::from(foo));

Fixes: https://github.com/ratatui/ratatui/issues/1367

Does foo.into() work? e.g.:
let line = Line::from(foo.into());

Does foo.into() work? e.g.:
let line = Line::from(foo.into());

No, that would have the same problem. both String and Cow are acceptable inferences for Line::from.

This is likely safe to keep around until we drop 0.29.0.


Define affine space concepts

Do you think this PR should include concepts for cost?

Would that be something like EvaluableAtPoint, ConvexFunction, ScalarResult? (the second requires lots of work)

I have no idea why it says that this branch has conflicts that must be resolved. Isn't it already merged to origin/main?


IPv6 support

It seems IPv6 targets are not supported.
On my machine I get AAAA records which are preferred for time.google.com.
$ cargo test
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading chrono v0.4.6
 Downloading num-traits v0.2.6
 Downloading num-integer v0.1.39
   Compiling num-traits v0.2.6
   Compiling num-integer v0.1.39
   Compiling cfg-if v0.1.5
   Compiling custom_derive v0.1.7
   Compiling libc v0.2.43
   Compiling byteorder v1.2.6
   Compiling conv v0.3.3
   Compiling log v0.4.5
   Compiling log v0.3.9
   Compiling time v0.1.40
   Compiling ntp v0.5.0 (file:///home/mordner/projects/ntp)
   Compiling chrono v0.4.6
    Finished dev [unoptimized + debuginfo] target(s) in 8.01s
     Running target/debug/deps/ntp-f3e12cb312a2b718

running 2 tests
test test_request_ntp_org ... ok
test test_request_google ... FAILED

failures:

---- test_request_google stdout ----
thread 'test_request_google' panicked at 'Failed to get a ntp packet from time.google.com: Os { code: 97, kind: Other, message: "Address family not supported by protocol" }', libcore/result.rs:945:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:221
   4: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:475
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: rust_begin_unwind
             at libstd/panicking.rs:325
   7: core::panicking::panic_fmt
             at libcore/panicking.rs:77
   8: core::result::unwrap_failed
             at /checkout/src/libcore/macros.rs:26
   9: <core::result::Result<T, E>>::expect
             at /checkout/src/libcore/result.rs:809
  10: ntp::test_request_google
             at src/lib.rs:113
  11: ntp::__test::TESTS::{{closure}}
             at src/lib.rs:111
  12: core::ops::function::FnOnce::call_once
             at /checkout/src/libcore/ops/function.rs:223
  13: <F as alloc::boxed::FnBox<A>>::call_box
             at libtest/lib.rs:1451
             at /checkout/src/libcore/ops/function.rs:223
             at /checkout/src/liballoc/boxed.rs:642
  14: __rust_maybe_catch_panic
             at libpanic_unwind/lib.rs:105

failures:
    test_request_google

test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

error: test failed, to rerun pass '--lib'

$ host time.google.com
time.google.com has address <IP_ADDRESS>
time.google.com has IPv6 address 2001:4860:4806:8::

$ host 0.pool.ntp.org
0.pool.ntp.org has address <IP_ADDRESS>
0.pool.ntp.org has address <IP_ADDRESS>
0.pool.ntp.org has address <IP_ADDRESS>
0.pool.ntp.org has address <IP_ADDRESS>

I guess binding to an IPv4 socket has something to do with it:
https://github.com/JeffBelgum/ntp/blob/master/src/lib.rs#L85

Thanks for the issue @mordner!
That function is kind of just a "simple" helper API on top of the protocol implementation itself - we should probably break up the internals of it into some smaller reusable functions to make it easier to specify what socket you want to bind to, etc.


Set branch view data

This PR is meant to persist user defined data for reuse, ensure that subsequent attempts to set the data overwrites previous attempts, and paves the way for Branch Views
@rubinsingh @jeanmw, when you have a chance please

LGTM @jsaleigh , added one comment above more out of curiosity (I think the answer to my question is no), and tested it out, seems good, let's see what circleci says  :)

Rerunning the CircleCI tests...digging in to the SauceLabs URLs show passes, but CircleCI is reporting the same as fails.


All sonos amps respond except one

I 4 sonos amps.  3 of the 4 respond except the master bedroom.  I have checked the preset file and all looks to be OK.  Any ideas?
pi@raspberrypi ~ $ wget http://localhost:5005/master/play
--2015-08-11 03:08:41--  http://localhost:5005/master/play
Resolving localhost (localhost)... <IP_ADDRESS>, ::1
Connecting to localhost (localhost)|<IP_ADDRESS>|:5005... connected.
HTTP request sent, awaiting response... 200 OK
Length: 37 [application/json]
Saving to: `play.20'
100%[======================================>] 37          --.-K/s   in 0s
2015-08-11 03:08:41 (836 KB/s) - `play.20' saved [37/37]

This is more a question for [node-sonos-http-api] (https://github.com/jishi/node-sonos-http-api), because we delegate Sonos control to that library.  Check case sensitivity and make sure the string name for that speaker looks exactly right.


chore(image): update base image

Automated changes by create-pull-request GitHub action

Codecov Report
Patch and project coverage have no change.

Comparison is base (bb8ecfe) 72.94% compared to head (3affcb1) 72.94%.

Additional details and impacted files
@@           Coverage Diff           @@
##           master     #376   +/-   ##
=======================================
  Coverage   72.94%   72.94%
=======================================
  Files          25       25
  Lines         743      743
=======================================
  Hits          542      542
  Misses        201      201

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


infer question

Hello infer dev:
I want to obtain callees but not find console command,can you help me?
For example:
obtain proc_uid,proc_name can by infer-debug --procedures command.
how I want to get callees on the console by infer-debug command. Is there an interface for this?
Thanks!

Infer doesn't export this information at the moment.


Question: Update attribute based on other attribute

I am trying to encapsulate some logic related to updates. For example, if someone updates attribute X I would like to automatically update attribute Y. This is to handle some typical DynamoDB best practices like creating a composite key based on the values of multiple attributes.
What I would LIKE would be a way to hook in to the update mechanism and add my own update expressions based on the values of other update expressions. I could inspect the updates and see that attribute X is being set to a new value so then I could set attribute Y to another appropriate value.
A alternative to this is simply to handle this logic in a higher level of abstraction and I'm prepared to do that, however I have been impressed with the level of abstraction I'm getting with dynamo-easy and would love to handle this logic by extending my Model or DynamoStore classes.
Thank you in advance for your consideration and guidance.

Hi @chrisbrantley
When updating a property, we do not have the whole object and are therefore not able to access other property values to update a composite key than the key and the updated value.
personStore.update('my-id').updateAttribute('name').set('simon').exec()

(eg. a composite key with ${birthday}-${name} --> where to get birthday from?)
We handle composite keys by using an own type and a custom mapper. This way you're forced to always provide all necessary values. An example can be found in our running demo:

Model with Composite Key
Type/Class of Composite Key
Mapper for Composite Key


Add possibility to run keycloak testsuite against a cluster

It could be beneficial to have ability to run Keycloak testsuite (probably just a subgroup of tests) against a cluster to verify the deployment.
For example whether expiration (lifespan, max-idle) works in crossdc setup, or whether any change in deployment's configuration  didn't introduce a security issue, etc.

@martin-kanis I understand the value in running Keycloak testsuite against a crossdc setup, however that would be a case to be made in Keycloak and testsuite is probably the right place to host such mechanism. WDYT ? We did explore in the past to see if https://github.com/kami619/KeycloakWithTestKube something like this is possible, but it didn't get much of traction.


[folly related] update to 05.27

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[x] The "supports" clause reflects platforms that may be fixed by this new version.
[x] Any fixed CI baseline entries are removed from that file.
[x] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

Feature [bzip2,libsodium,lz4,lzma,snappy,zlib,zstd] tested successfully in the following triplet:

x86-windows
x64-windows
x64-windows-static