Implement Podman support for move2kube

Is your feature request related to a problem? Please describe.
Currently running container based transformers requires docker. Podman support would be good too.
Describe the solution you'd like
Implement support for podman. This would involve

Completing https://github.com/konveyor/move2kube/blob/main/environment/container/podmanengine.go, which should fully implement the containerengine interface (https://github.com/konveyor/move2kube/blob/a5bf3cd7a8f611792da01c580a171740acc404ce/environment/container/container.go#L36), [An example could be found in https://github.com/konveyor/move2kube/blob/main/environment/container/dockerengine.go for docker]
Adding a condition in https://github.com/konveyor/move2kube/blob/a5bf3cd7a8f611792da01c580a171740acc404ce/environment/container/container.go#L59 stating when to invoke it.

Describe alternatives you've considered
Using only docker for containers

@seshapad When we implement support for podman, consider using libpod (https://github.com/containers/podman/tree/main/libpod) instead of requiring external podman binary.

That's a good point @rmarting .
The scope of this issue is about what Container runtime needs to use to run its container based Transformers ( which are custom Transformers that can be built as containers). This can be automatically chosen, first it can try docker and if it does not work, then it can try podman. We havn't yet implemented the support for podman. It requires implementing an interface.
The point you have brought up is also valid. We should support creation of scripts with podman/docker. Can you possibly convert your comment into a new issue, so that we can track it to completion.

@ashokponkumar New Enhacement request created here

Hello! I'm trying to work on this one. If we want to do CopyDirsFromContainer, CopyDirsToContainer, Stat, StopContainer, CopyDirsToImage in podman(podmanengine.go) like we do in docker(dockerengine.go), we would need to have access to container IDs of the container we created.
Now, one way of doing that is to list the containers and filtering them out by image names i.e. podman ps -q --filter "ancestor=image_name". But the problem arises when there are multiple containers from the same image.
Am I missing something here? @kmehant @HarikrishnanBalagopal @ashokponkumar


proposal: language: allow getting capacity of map?

I posted a quiz on Twitter:
func main() {
	m := make(map[int]int, 500)
	fmt.Println(len(m))
	fmt.Println(cap(m))
}

Only 21% of people got it right, that it fails to compile with:
invalid argument: m (variable of type map[int]int) for cap

It's a little weird that you can kinda set the capacity of a map (a hint) but you can't get it back out. (Where "it" is really an  "optional capacity hint")
I imagine the reason is the same reason that the previous proposal to automatically round up slice capacities to the nearest slab class was declined: it binds us to an implementation, or at least leaks their details that we'd be locked into.
Filing a bug in any case, as I can't find any past discussions of it on the issue tracker, and don't remember hearing any discussions elsewhere.
My motivation, FWIW, was to periodically re-make a map representing a set of work to do when it dropped back down to len(m) == 0. But I only wanted to re-make it if the underlying hash map capacity had grown enough to be worthwhile. Of course that's all just a workaround for #20135 (maps not shrinking). And that means I wanted more than just the initial capacity hint; I wanted to see the underlying capacity change as a function of insertions into the map.

I think I'd rather just make maps shrinkable.

I think both cases would be useful. Allowing cap() on maps would make Go more consistent and easier to learn, even if it is only informative.
And making maps shrink automatically is also a useful feature but that is what issue #20135 is for.

It's hard to explain what cap means at all. It's a rough estimate of the size of the underlying storage and that's about it.
Unlike cap on slices and chans, it is not a guarantee about being able to store that much without resizing / blocking.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

I couldn't find the discussion that Russ mentioned (but I think I know the gist).  I still think this is a worthwhile idea.  An alternative would be to add a builtin function as part of the unsafe "package".

@AndrewWPhillips Sorry, this proposal is closed.  We aren't going to reopen it without new information that we didn't previously consider.

I don't know if this meets the threshold for "new information" sufficient to reopen the issue, but I've just run into this in the following scenario....
Developing a module which internally uses a map in a struct type that is initialised using a func where the caller indicates a desired capacity for the contained map.  Without the ability to determine the capacity of the newly initialised map, it is not possible to write a unit test to verify that the initialisation function returned a correctly initialised struct.
For all other types where make() supports establishing an initial capacity, cap() is available to determine the capacity.  A map being the only exception is perplexing and frustrating but, more seriously and significantly, is an impediment to testing.
I cannot conceive of any problem that addressing this omission/exception would create and would appreciate consideration being given to re-opening the proposal.

Я не знаю, соответствует ли это порогу «новой информации», достаточному для повторного открытия проблемы, но я только что столкнулся с этим в следующем сценарии....
Разработка модуля, который внутренне использует карту в типе структуры, инициализируемой с помощью функции, где вызывающая сторона указывает желаемую емкость содержащейся карты. Без возможности определить емкость вновь инициализированной карты невозможно написать модульный тест, чтобы убедиться, что функция инициализации вернула правильно инициализированную структуру.
Для ** всех ** остальных типов, где make()поддерживает создание первоначальной мощности, cap()доступен для определения емкости. А mapбудучи единственным исключением, это сбивает с толку и разочаровывает, но, что более серьезно и важно, это является препятствием для тестирования.
Я не могу себе представить какую-либо проблему, которую могло бы создать устранение этого упущения/исключения, и был бы признателен за рассмотрение возможности повторного рассмотрения предложения.

I uphold

A little story about why I'd have found it useful to have cap for maps. https://philpearl.github.io/post/map_clearing_and_size/

Maybe the new map implementation can avoid this problem?

Swiss tables will not make the clear-is-expensive-on-large-capacity-maps problem any better.
It could possibly help with very sparse maps (0.1% full or less), but not normally.
The new map implementation also makes the proposed cap less useful. The tie between what cap would report and when growth happens is much more tenuous.


Fixed a bunch of rename issues, including Charlie Zender's reported problem...

This PR is the result of additional testing for nc4var.c to increase code coverage in the tests.
It includes a fix for Charlie Zender's rename issue, as well as another important rename issue.
It also include some less-critical fixes which prevent segfaults for strings and fill values.
Also much more testing and internal documentation. @WardF I suspect you might want to include this in 4.6.0 due to the fix for the rename issues.
Fixes #758.
Fixes #757.
Fixes #750.
Fixes #749.
Fixes #746.
Fixes #743.
Fixes #741.
Fixes #738.
Fixes #736.
Fixes #732.
Fixes #727.
Part of #702.
Attempt to fix #554.

This pull request fixes 1 alert - view on lgtm.com
fixed alerts:

1 for Missing header guard

Comment posted by lgtm.com

This pull request fixes 3 alerts - view on lgtm.com
fixed alerts:

1 for Missing header guard
1 for Duplicate include guard
1 for Wrong number of arguments to formatting function

Comment posted by lgtm.com

This pull request fixes 3 alerts - view on lgtm.com
fixed alerts:

1 for Missing header guard
1 for Duplicate include guard
1 for Wrong number of arguments to formatting function

Comment posted by lgtm.com


OOM memory is not visible in vagrant, and error conditions in general.

When trying to launch a box that gets a power on failure... its not obvious what the power on failure is and there is no detail on how to resolve the issue. There should be some pertinent output.
For example display that there is not enough memory in this case...
2015-07-08T11:52:37.370-08:00| vmx| I125: [msg.memsched.preNotEnoughMem] Not enough physical memory is available to power on this virtual machine with its configured settings.
2015-07-08T11:52:37.370-08:00| vmx| I125: [msg.memsched.notEnoughMemGuestMemVal2.fusion] To fix this problem, power off other virtual machines or decrease the memory size of this virtual machine to 4556 MB.
2015-07-08T11:52:37.370-08:00| vmx| I125: [msg.memsched.hostUnderDuress] It is possible that native applications and/or services have locked down memory which could be preventing the virtual machine from launching. Shutting down unnecessary applications or services may free enough memory to launch this virtual machine.
2015-07-08T11:52:37.370-08:00| vmx| I125: [msg.memsched.postNotEnoughMem] If you were able to power on this virtual machine on this host computer in the past, try rebooting the host computer. Rebooting may allow you to use slightly more host memory to run virtual machines.

Yes, we're going to address this in future versions of AppCatalyst, it's not strictly related to the vagrant provider, it's a limitation in what the current API can report back.

Ok neat, so there will be some way to get console data? I am attempting to get a SmartOS image working, it works on Fusion, but the network never becomes available on catalyst. The log shows no obvious failures.

And nevermind. socat + serial.socket0 is your friend.

Is it possible to attempt booting the vm manually after it has a power-on failure when starting via vagrant?

yes you can use appcatalyst cli to do so.
You would need the vagrant-id for the vm in question, once you have 'id' you can run appcatalyst vmpower on .


Enable Multiple select with 'Shift' and 'Command' keys

It would be great if the multipleselect was working when holding 'Shift' and/or 'Cmd' keys. Exactly like on a computer OS.

Would love to see this feature implemented

@eightyfive closed this 6 days ago

Why? Is it resolved?

No, just cleaning my issues. Opened almost 3 years ago.


chore(main): release 4.1.0

:robot: I have created a release beep boop
4.1.0 (2024-09-18)
Features

added support for temporary_name_for_rotation (#268) (a3461cf)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v4.1.0
:sunflower:


pip installable

First, thanks for putting this library up. I find it very useful.
Could you do this library pip installable so I can add it as a requirement to one of my packages? (https://github.com/alvarouc/polyssifier)

Hi @alvarouc , yes.  I think that sounds like a good idea.  I think that @jcrist is working hard at changing some of the internals right now, so I suspect that he will want to wait a couple of days.  Are you ok with this delay?

No problem at all, thanks for the hard work.

@alvarouc in the meanwhile you could change the setup.py
    install_requires=[
        'mlp',
        'pandas',
        'sklearn',
        'numpy',
        'dask-learn'],
    dependency_links=[
        'git+https://github.com/dask/dask-learn.git@master#egg=dask-learn-0',
    ]

And perform the installation like this
pip install . --process-dependency-links

The library is now on pypi under dask-searchcv. Should be up on conda-forge early this week. Closing.


Show instances of workflows for more than last 30 days

It's very common for workflows to be a integral part of business operations but not run within 30 days. It would be more helpful if we could go back and see how many instances ran in a calendar year.

@hatfield41: thanks for using the assessment tool and providing the feedback. The assessment tool is using public APIs and currently those APIs are not returning data beyond the mentioned 30 days. We're investigating if workflow API changes can be made to support the actual "last used" date as that would capture workflows that run less frequent.

Closing as per design


bug fixed but haven't released yet

Hi, I noticed you fixed a bug of Resize, commit id: 2f6a07dabc017620f836226d41caac2251d18650. However, the latest version on pip doesn't include this change. Could you please release a new version? Thx.

sure. just did with 52fdfa0


not able to pass build

9644207b0380e7771d602c13895e64760479154b was the last version that can pass build.
clone then checkout

let me see, did you build using bun or nodejs?

works fine for me

oh, by the way, are there any error messages?

Maybe it's an issue related to bun?


Add information about how to escape command line arguments

In my case it was about passing a percent sign followed by a number without it getting interpreted/modified.
Others are struggling with passing '<' and '>' chars.
Like here:

https://stackoverflow.com/questions/7882295/how-to-include-the-percent-character-in-the-visual-studio-debugger-command-line
https://stackoverflow.com/questions/47991831/escaping-in-visual-studio-debugging-command-arguments/48006894

This information should be included here on this page rather than on just some SO responses.
Thanks,
sw

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

ID: 9bfbcccc-d2ac-0029-86cf-a67c2390272a
Version Independent ID: e1352298-0650-bba1-7c15-e90eb7209e40
Content: Project settings for a C++ debug config - Visual Studio (Windows)
Content Source: docs/debugger/project-settings-for-a-cpp-debug-configuration.md
Product: visual-studio-windows
Technology: vs-ide-debug
GitHub Login: @Mikejo5000
Microsoft Alias: mikejo

Updating this doc.

@Mikejo5000  - Thanks for addressing this. How can I view the change?
The history of this file: https://github.com/MicrosoftDocs/visualstudio-docs/blob/main/docs/debugger/project-settings-for-a-cpp-debug-configuration.md
..still shows Jan11 for the latest commit.

@softworkz It goes live by about 5:00 pm PST.

@softworkz -- yes, there is a private (staging) repo that gets published twice daily into this public-ready one.

Ah alright, understood. That's am interesting kind of setup.
Thanks for taking care of this!


[WIP] Generate web documentation with mkdocs (#1027)

The following PR introduces some changes in order to generate markdown files that is optimized for use with mkdocs.
Preview: https://andersevenrud.github.io/nvim-lspconfig-web/languages/pyls/
TODO:

[ ] Automated sorting of sidebar navigation by article title (H1). mkdocs uses the filename to sort so right now this is statically defined via configuration file.
[ ] Improve language names assigned in the metadata
[ ] ... see discussion topics below ...

Changes:

Changes language markdown templates
Adds language_name to the configuration files (ex.: Python)
Updates docgen to produce individual markdown files in addition to CONFIG.md
Added MkDocs configuration

If you wanna test this yourself:
pip install mkdocs-material # this also installs peer dependencies
./scripts/docgen.sh
mkdocs serve

Some things to discuss:

The template changes makes CONFIG.md a bit more verbose. Should there be two types of documentation here, i.e. web and repo ? Or:
Phase out CONFIG.md and direct users to the individual files?
The <details> elements did not support markdown, so they were removed. But because of the template changes this is maybe not much of an issue?
The contents of ex. README.md has now been duplicated, which is probably not ideal.

Relevant issues:

https://github.com/neovim/nvim-lspconfig/issues/1027

bad bot

bad bot

It's my fault. I did some rebasing and it turns out I was not using upstream, so something went a bit wrong here :joy: I'll ping to re-open when I have it sorted out.

@mjlbach Should be in order now... but I don't see any changes in this UI when I force pushed. But maybe it's just because the PR was closed ? :)

I decided to scratch this PR because things got a bit messed up, and I changed things quite a bit. Sorry about the inconvenience.
#1036


improve ntrip client startup process

Improved NTRIP client startup process.
NTRIP client is used to receive RTK correction from a remote server (NTRIP server) and the received RTK correction is sent to a GNSS board.
Because NTRIP client binary (str2str) has been run completely independent of ROS 2 system, I think it is better to improve integration between NTRIP client and ROS 2 for future development.
Changes

Run str2str command in a ROS 2 node to log console output to the cabot log directory
Add ntrip_client package as an alternative to str2str.
Add environment variables to set NTRIP client parameters
Add an environment variable option to select whether or not start NTRIP client node at cabot launch.sh
Add an environment variable option to select whether or not start ublox node at cabot launch.sh

Note

This change has no effect when GNSS is not used.

Pull request https://github.com/CMU-cabot/cabot-common/pull/11 needs to be merged to fix run unittest errors.


Unable To Load Trace In Perfetto UI

In the Arc browser we use Chromium's tracing support to produce diagnostics that our members can send us if they have an issue with the browser. In addition to some Chromium specific categories, we add a custom category that let's us bridge tracing information from our Swift application into the tracing report.
Internally, we use Chromium's TRACE_EVENT_NESTABLE_ASYNC_BEGIN1 and TRACE_EVENT_NESTABLE_ASYNC_END1 respectively to begin and end span information from the Swift application.
When loading the trace into https://ui.perfetto.dev we are typically greeted with an error that says the following:
To assist with debugging please attach or link to the trace you were viewing.

Viewed on: https://ui.perfetto.dev

Error: Error @ row: 39 col: 'name': SQL value is NULL but that was not expected (expected type: STR). Did you intend to use NUM_NULL or STR_NULL?
Error: Error @ row: 39 col: 'name': SQL value is NULL but that was not expected (expected type: STR). Did you intend to use NUM_NULL or STR_NULL?
    at RowIteratorImpl.tryMoveToNextBatch (https://ui.perfetto.dev/v31.0-0392f51dc/frontend_bundle.js:325412:23)
    at RowIteratorImpl.next (https://ui.perfetto.dev/v31.0-0392f51dc/frontend_bundle.js:325309:23)
    at new RowIteratorImpl (https://ui.perfetto.dev/v31.0-0392f51dc/frontend_bundle.js:325279:14)
    at new RowIteratorImplWithRowData (https://ui.perfetto.dev/v31.0-0392f51dc/frontend_bundle.js:325428:22)
    at QueryResultImpl.iter (https://ui.perfetto.dev/v31.0-0392f51dc/frontend_bundle.js:325015:22)
    at TrackDecider.<anonymous> (https://ui.perfetto.dev/v31.0-0392f51dc/frontend_bundle.js:345878:41)
    at Generator.next (<anonymous>)
    at fulfilled (https://ui.perfetto.dev/v31.0-0392f51dc/frontend_bundle.js:4524:62)

v31.0-0392f51dc 0392f51dc49c47aa5754d6e987b1b4bf4fab32d1
UA: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36

However loading the trace into the legacy UI (or converting it and loading it) shows all of the tracing tracks without issue (albeit in the old UI).
I've attached a trace that triggers the error and I'm very much looking forward to debugging further but am just unsure how to proceed and would love some advice, however since the tracks load in the legacy UI and not the modern tool I wanted to file this issue as a jumping off point.
trace_log_2022-12-20_09-50-02.json.gz

Took a look into this. A few things which stand out:

Your file name is not accurate: inside the gzip container is not a JSON trace but actually a proto trace. I tried to open this with a text editor and was surprised to see binary nonsense come up.
The root cause of this issue is null track names for global scoped and process scoped tracks. We always expect those to have a name inside the Perfetto UI so when they are null, the UI just fails. It's questionable whether the UI should treat this as an error but given we always expect well-formed traces to have a non-null track name, it's not super unreasonable.
The null track names are coming from the the fact that we don't seem to be associating names correctly when legacy_event is specified in track_event. As the name implies, this stuff is legacy for a reason and was always intended as a short-term solution which would go away at this point.

I don't have cycles to look  more into this but I'll cc @betasheet @skyostil and ping some people internally about whether they can dig more into this.

Note also that many people are off for the holidays so it may not be anyone can look into this until after. I'd consider following up on this after the holidays if you don't hear anything here over the next few days.

Thanks so much for the info @LalitMaganti and to @primiano who I see pushed a commit trying to fix some portion of this. I assume the correct thing for us to do is to migrate off of whatever these legacy APIs are internally to something a bit more modern? @vivekg-ai any thoughts here for us?


Enabling source clear

Coverage remained the same at 100.0% when pulling f452ad6e2cb634b3bbfeb6a049553fd9ad9492f1 on ali/add_src_clr into c1ca00d7a73581fd5fbafff692e343490d8448b3 on master.


Retry on conflict setting

I am trying to include a retry_on_conflict parameter to my configuration, but I'm not sure where that should go. I am mostly using ensure in the following way:
const db = admin.database();

const indexRef = db.ref(Constants.FIREBASE.LOCATIONS.INDEX);

const indexSearch = new FirebaseSearch(indexRef, {
   elasticsearch: elasticSearchConfig,
}, Constants.FIREBASE.LOCATIONS.INDEX);

indexSearch.elasticsearch.indices.ensure().then(() => {
   indexSearch.elasticsearch.firebase.start();
});

Is it something that could be added to the elasticsearch config, passed into FirebaseSearch, or passed into the ensure() function?

@Bonitis
I haven't used Elasticsearch in a while, but it appears that retryOnConflict is a parameter for elasticsearch.update: ElasticSearch 5.0 API Update
It looks like I need to add more options to firebase-search so you can pass additional create/update/delete parameters. firebase-search.js:267 is where those extra params would need to be attached to the main update params.
You're welcome to make a pull request :)
It's probably just a few lines of code plus an explanation in the README.
I'll try to take a pass at it later today, but I've been crazy busy.

Awesome! I will try to take a crack at a PR tomorrow morning. I agree that it shouldn't take a ton of code.

Turns out @mbifulco went and did it for me!

Big thanks to @Bonitis for the excellent suggestion and to @mbifulco for getting it done!


Passing HTML / CSS Attributes  not load for ionic 4 beta7.0.0-beta.2

i  have problem
i'm use in html
<img-loader src="{{seller.sellerimageURL  }}" useImg [imgAttributes]="imageAttributes">
and .ts
this.imageAttributes.push({
element: 'class',
value: 'circle-photo'
})
but it not load class
https://sv1.picz.in.th/images/2019/07/26/KAJwUQ.png

Where did you write css for the class? Can you please mention its code?

write css in page // bootdetails.page.css

I change to write in  global.scss it work but only width not' work
https://sv1.picz.in.th/images/2019/08/09/ZWx5FQ.png

I've found a simple way for me to attach for example a border-radius styling to the <img> element, which is dynamically created by the Ionic Image Loader.
Put the following styles in a globally available style sheet:
img-loader {

	// Default border radius
	--border-radius: 0;

	// Custom border radius, if set
	$border-radius: var(--border-radius);

	& img {

		// Apply default or custom border radius
		border-radius: #{$border-radius};
	}
}

So we store a custom css variable, here called --border-radius, into a scss variable, then we access the child (<img>) and append the styling to it.
Now you can style any image, using the Ionic Image Loader (with <img> tags), like following:
[some code here]

& img-loader {
	--border-radius: 4px 4px 0 0;
}

[some code there]

So we pass the styling from the <img-loader> element to the <img>.
If no styling is passed, it will use the default border radius. The default value will be overwritten, if you append the css variable to a <img-loader>. No scss checks or something like that required here.
This can be adapted to any other styling like width, height or something else. Also you can rename the variables as you wish.
Hope it helps someone.


Glossary Management Screen UI behaviour.

Affected module
Glossary Management UI
Describe the bug
When the number of Terms increases the tree overflows at  the bottom.
To Reproduce

Expected behavior
A vertical scroll bar should appear to avoid overflow. I suggest also adding a lateral slider, so tree width can be resized. Dealing with special characters in terms name or descriptions when creating terms should be desirable too.
Version:

OS: RHEL 7.9
Python version: 3.8.13
OpenMetadata version: 0.11.2
Browser: Google Chrome 102.0.5005.63
OpenMetadata Ingestion package version: [e.g. openmetadata-ingestion[docker]==XYZ]

Additional context
Add any other context about the problem here.

It’s fixed in 0.12.0 release


tailscale: 1.6.0 -> 1.8.0

Motivation for this change
This PR updates tailscale to the latest stable version.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

You're fast! We pushed the release button minutes ago :)

This was by accident. :) I'm running 1.8 now. I see no issues so far.


Outgoing mail broken for local dev, blocks testing of user registration

Developers should configure their own environment using the information outlined here: https://github.com/hydroshare/hydroshare/wiki/hydroshare_email_using_gmail
The *.hydroshare.org VMs have their own email server that is specified via the local_settings.py file located on each VM separately. These configuration files are not made publicly available as part of the code on github for security reasons.

I think there is a larger issue involved of developer setups and VM deployments still requiring far too many manual steps. Any deployment that requires manual steps is prone to errors.

Why is the local_settings.py checked into the repo if you have to use a local version? Usually these would not exist, so they initial setup requires they be put in place before anything will run. This helps catch mistakes early.
If there has to be settings that should exist only on a particular machine or machines, they can be kept on that machine by default.

If I didn't have to make a completely new clone and setup on riverdev, this would not have been a problem. With this setup, there aren't even really "deployments" in any traditional sense. We just have developers checking out developer setups on some VMs.

There are scripts for all of this: https://github.com/hydroshare/hydroshare/tree/develop/scripts
Other developers using the public VMs are deploying via Jenkins and using the aforementioned scripts to keep the data backup and deployments relative to the machine being deployed to.
Happy to walk you through this if you are still confused or having issues on the deploy.

@mjstealey is the process to deploy via Jenkins documented? I was never given access to Jenkins, only SSH access to the machine and told to check out the repo and deploy manually. If I had been given the proper information and setup that others are enjoying, it would have saved considerable time and frustration.

Presently myself, @pkdash, @selimnairb, and @hyi are admins on the Jenkins box, any one of us could set you up with a user level account.
The process is not documented formally, however there are plenty of example jobs running that can be used as a template or starting point for a new job, and then tweaked to suit your needs.
Depending on what needs to be done, the slave VM may need to be configured independently of Jenkins to place it in a known state before you run the job for the first time. There are still some brittle portions of the workflow that can break the slave VM and put it in a non-recoverable state from the Jenkins point of view, and maintenance would need to be done directly on the VM at that point.

I'd like to add to this issue that not all GMail accounts have app-specific passwords enabled, so this doens't work for all of us. There are fallback behaviors we could put in place by default, like the console backend https://docs.djangoproject.com/en/1.8/topics/email/#console-backend

There are fallback behaviors we could put in place by default, like the console backend https://docs.djangoproject.com/en/1.8/topics/email/#console-backend

I'm happy to put anything other than the production smtp credentials there.
If you have something that will work for all, then by all means please modify / PR it and we'll bring it in.

Update to local_settings.py to default to console as email backend.
Since Django is running in a daemonized docker container the user will need to attach back to the container to see the output.
Example:
$ docker attach hydroshare_hydroshare_1
...

Fill out new user info in your local development browser and click join
...
Content-Type: multipart/alternative;
 boundary="===============1573799015647134470=="
MIME-Version: 1.0
Subject: Activate your account in HydroShare
From: webmaster@localhost
To<EMAIL_ADDRESS>Date: Mon, 04 Jan 2016 19:58:40 -0000
Message-ID: <20160104195840.40.17919@26223243c15c>

--===============1573799015647134470==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Welcome to HydroShare. This email address was used to request an account on www.hydroshare.org.
If you originated the request, please use the link below to verify your email address and activate your account.
http://<IP_ADDRESS>:8000/accounts/verify/2/489-94521b86ec6110b4fb48/?next=/
If you did not originate this request you may ignore this email.
The HydroShare Team

--===============1573799015647134470==
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

Welcome to HydroShare. This email address was used to request an account on www.hydroshare.org.

If you originated the request, please use the link below to verify your email address and activate your account.

<a href="http://<IP_ADDRESS>:8000/accounts/verify/2/489-94521b86ec6110b4fb48/?next=/">http://<IP_ADDRESS>:8000/accounts/verify/2/489-94521b86ec6110b4fb48/?next=/

If you did not originate this request you may ignore this email.

The HydroShare Team

--===============1573799015647134470==--

-------------------------------------------------------------------------------

Email defaults to console output which can be viewed by attaching to the running hydroshare container.
$ docker attach --sig-proxy=false hydroshare_hydroshare_1
Developer deployment to VM has been implemented as a Developer Build option found here: http://ci.hydroshare.org:8080/view/4. Developer Builds/

presently in testing phase with @mauriel133
plan to distribute to all during next team call


⚠ Mitsubishi has degraded performance

In 9c2d327, Mitsubishi (https://mitsubishimotorsid-mobileapp.com/app/login) experienced degraded performance:

HTTP code: 200
Response time: 20473 ms

Resolved: Mitsubishi performance has improved in 0e18fc8 after .


and intrinsic does not support vector arguments

Currently, Slang does not support vector types for the and intrinsic:
shader.hlsl(14): error 30019: expected an expression of type 'bool', got 'vector<bool,2>'
    n = and(m, l);
            ^
shader.hlsl(14): error 30019: expected an expression of type 'bool', got 'vector<bool,2>'
    n = and(m, l);
               ^
shader.hlsl(15): error 30019: expected an expression of type 'bool', got 'vector<bool,3>'
    q = and(o, p);
            ^
shader.hlsl(15): error 30019: expected an expression of type 'bool', got 'vector<bool,3>'
    q = and(o, p);
               ^
shader.hlsl(16): error 30019: expected an expression of type 'bool', got 'vector<bool,4>'
    t = and(r, s);
            ^
shader.hlsl(16): error 30019: expected an expression of type 'bool', got 'vector<bool,4>'
    t = and(r, s);
               ^
shader.hlsl(19): error 30019: expected an expression of type 'bool', got 'vector<bool,2>'
    n = and(n, true);
            ^
shader.hlsl20): error 30019: expected an expression of type 'bool', got 'vector<bool,3>'
    q = and(q, true);
            ^
shader.hlsl(21): error 30019: expected an expression of type 'bool', got 'vector<bool,4>'

To ease porting, it would be nice to have support for a vectorized and. It's reasonable to assume that the and intrinsic gets a decent amount of usage in cases where clarity is desired. Note that there is a special case for when the arguments are a vector and a scalar bool. The scalar bool is implicitly expanded to a vector. However, there is not any special cases for arguments of vectors of two different dimensions, so no truncation.
Shader*
float4 main() : SV_Target
{
    bool a, b, c;
    c = and(a, b);

    bool1 i, j, k;
    bool2 l, m, n;
    bool3 o, p, q;
    bool4 r, s, t;
    k = and(i, j);
    n = and(m, l);
    q = and(o, p);
    t = and(r, s);

    k = and(k, true);
    n = and(n, true);
    q = and(q, true);
    t = and(t, true);

    bool2 tv = bool2(and(a, b), and(k.x, and(n.x, and(q.x, t.x))));
    return tv.x ? float4(0, 0, 0, 0) : float4(1, 1, 1, 1);
}

https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/and--sm4---asm-
(reference for whomever picks up the task)

Looks like the vector variant is from HLSL 2021 as part of the and(), 'or()', and 'select() intrinsics:
https://devblogs.microsoft.com/directx/announcing-hlsl-2021/

https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/and--sm4---asm- (reference for task)

I don't think this is a good reference link.
The document shows the assemble code of how the operation should work not HLSL.

The document shows the assemble code of how the operation should work not HLSL.

There is no actual doc page for and/or. I agree the provided link is not very good.
HLSL2021 touch upon the topic, I suppose the description is fine for implementation purposes(?): https://github.com/microsoft/DirectXShaderCompiler/wiki/HLSL-2021

Closed by https://github.com/shader-slang/slang/pull/4529


Update sbt to 1.3.7

Updates org.scala-sbt:sbt from 1.3.2 to 1.3.7.
Release Notes/Changelog
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.
Have a fantastic day writing Scala!

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

labels: library-update, semver-patch

Superseded by #1354


sw: Restructuring of BLAS and DNN kernels

This PR will introduce substantial changes to the SW library in the BLAS and DNN kernels.
GEMM
This PR comprises the following changes in the BLAS library:

We moved to a generic impl function that will fetch the correct kernel from the config.json file. All of this is wrapped inside a gemm_args_t struct that holds all kernel-related data. The arguments in the struct are loaded into the cluster's TCDM to avoid costly DRAM accesses when calling the function. The roadmap is to adapt all kernels in the sw library to this format to improve performance.
We added the option to run multiple tests in parallel.
We aligned the tests to work with the new GEMM layout and added a naive FP16 kernel for verification.
We moved the BETA multiplicative factor from an integer to float to make sure we can use FP registers and do not run into synchronization issues when using SSRs.
We added more assertions to the datagen script of unsupported or invalid configurations with the relevant error messages.
We adjusted other kernels, such as fused_concat_linear to the new layout.

FlashAttention-2

We added the transposition layer that is used inside the kernel.
We added the FP16 and FP8 MiniFloat implementations.
We added multiple configurations for testing.
We aligned the kernel to work with the new GEMM layout.
Several fixes to the kernel were integrated and casts from lower to higher precision and vice versa.

@colluca The dnn-additions branch is now synched with my fork here. I will remove the tcasai related files, respectively.


Replace all OL extractors to use DefaultExtractor

Describe the bug
Use DefaultExtractor for all astro provider extractors as done for astro-sdk

Can you update this ticket with the current status?

Currently have changed redshift and snowflake.
Need to change for bigquery and add tests for the extractors.

As we are deprecating providers, this might not be needed now. closing this


Up Symfony and phpstan components versions in composer.json

@wowo @mariusz-jeruzal Hello! Would be amazing if you could take a look.


Detecting when the cache is dirty

#273
I took the liberty to modify the fork of @apGribble to submit a pull request
this branch adds a check for uncommitted changes in the cache if the folder is a git repo, printing a warning.
in case the folder is not a git repo, a status message is printed and no real check is performed.

I saw under test/unit that there is a cache.cmake test. should I add there a unit test for this feature?
I think a cmake script that creates a folder, inits a repo, then modifies a file.

added a new unit test dirty-cache-check.cmake

I've been using this fork for my project and so far so good. My daily setup is a Linux machine with git configured, a mix of .zip libs, third-party git libs, and in-house git libs.
in-house git libs are the main reason for this fork, and in this regard, I was able to catch a couple of instances of uncommitted changes in the cache that I overlooked.
open questions:

since I have to if(DEFINED CPM_ARGS_GIT_TAG) is it ok to assume that if CPM_ARGS_GIT_TAG is defined then I am for sure in a git repo library?
1.1 in this case there is no need for a check for the edge use case - a .zip lib inside an unrelated git repo. should I keep the check nonetheless, to be defensive?
1.2 should i rename back cpm_check_working_dir_is_clean to cpm_check_git_working_dir_is_clean to reflect the fact that it's in fact meat only for git?

@TheLartians  ok, I went ahead removed the check and renamed the function.
I think work for now is done, I'll keep using my branch to test it. Let me know if I have to do anything.


Why @setFloatMode(.Optimized) is allowed for Zig?

Could you please explain why @setFloatMode(.Optimized) is allowed for zig in spectralnorm code?
As far as I know this is “equivalent” to -ffast-math in GCC yet quite rightfully -ffast-math is not allowed for gcc.

You are right. https://ziglang.org/documentation/master/#setFloatMode
It is should be:

removed from Zig implementations
or
allowed to add fast-math to others.

Similar problem with Zig's Vector. It uses SIMD inside..https://github.com/hanabi1224/Programming-Language-Benchmarks/issues/316
At least those implementations should be marked with "-I" flag.


Dashboard pin: change label 'raw customer' to 'new customer'

Dashboard pin: change label 'raw customer' to 'new customer'

done, updated name as "New (raw) customer"


increase awesome_bot timeout

We are getting a lot of failed builds and, as such, we should increase the timeout to 10s to reduce their number. Take into account that the default for awesome_bot is 30s.

Well, seems that it doesn't change much... Maybe we should implement a way of counting the number of times a certain website fails per month and remove it in case it goes over a certain threshold, but maybe this is unnecessary over engineering.


Restrict signature debug logging to vivisect backend

I noticed that signatures will only load when the backend is vivisect:
https://github.com/mandiant/capa/blob/7debc54dbd90372af8f4e3b1819fe632afdaa3fa/capa/main.py#L695-L698
I moved the debug logging from handle_common_args to get_signatures_from_cli, so it's only printed when the signatures are actually used. This means that other backends don't need the default signatures directory to exist.
Closes #1875
Checklist

[x] No CHANGELOG update needed

[x] No new tests needed

[x] No documentation update needed

see inline comment, then good to go

is this good? thanks!


Bug report: Installation behavior for existing manually installed apps

Description of issue
When an application previously installed manually exists at /Applications, brew install ... should not delete the app unless --force is specified. This was reported by @gabriel as part of testing the keybase cask at https://github.com/caskroom/homebrew-cask/pull/29956#discussion_r101410551
It seems that the logic wants to both remove the existing app and fail to do so...
Repro steps. install keybase manually from https://keybase.io/docs/the_app/install_macos and then from cask using brew cask install keybase
Output of `brew cask install keybase`
$ brew cask install keybase
==> Downloading https://prerelease.keybase.io/darwin/Keybase-1.0.18-20170209165653%2B17b641d.dmg
Already downloaded: /Users/joshka/Library/Caches/Homebrew/Cask/keybase--1.0.18-20170209165653,17b641d.dmg
==> Verifying checksum for Cask keybase
==> Removing App: '/Applications/Keybase.app'
Error: It seems there is already an App at '/Applications/Keybase.app'.
Error: nothing to install

When an application previously installed manually exists at /Applications, brew install ... should not delete the app unless --force is specified.

And it doesn’t. I can’t reproduce this with other casks and won’t try with this one because I don’t have an available VM. Please try with other casks first.

I thought at first it was due to the commands in the cask's preflight / postflight stanza, but commenting those stanzas out completely gives the same error.
Full output of `brew cask install --debug keybase`
$ brew cask install --debug keybase
==> Loading Cask definitions
==> Translating 'keybase' into a valid Cask source
==> Testing source class Hbc::Source::URI
==> Testing source class Hbc::Source::PathSlashRequired
==> Testing source class Hbc::Source::TappedQualified
==> Testing source class Hbc::Source::UntappedQualified
==> Testing source class Hbc::Source::Tapped
==> Success! Using source class Hbc::Source::Tapped
==> Resolved Cask URI or file source to '/usr/local/Homebrew/Library/Taps/caskroom/homebrew-cask/Casks/keybase.rb'
==> Cask instance dumps in YAML:
Warning: Unexpected method 'encode_with' called on Cask keybase.
Follow the instructions here:
  https://github.com/caskroom/homebrew-cask/blob/master/doc/reporting_bugs/pre_bug_report.md

If this doesn’t fix the problem, please report this bug:
  https://github.com/caskroom/homebrew-cask#reporting-bugs

==> Cask instance toplevel:
--- !ruby/object:Hbc::Cask
token: keybase
sourcefile_path: !ruby/object:Pathname
  path: /usr/local/Homebrew/Library/Taps/caskroom/homebrew-cask/Casks/keybase.rb
dsl: !ruby/object:Hbc::DSL {}
==> Cask instance method 'name':
---
- Keybase
==> Cask instance method 'homepage':
--- https://keybase.io/
...
==> Cask instance method 'url':
--- !ruby/object:Hbc::URL
uri: !ruby/object:URI::HTTPS
  scheme: https
  user:
  password:
  host: prerelease.keybase.io
  port: 443
  path: /darwin/Keybase-1.0.18-20170209165653%2B17b641d.dmg
  query:
  opaque:
  registry:
  fragment:
  parser:
user_agent:
cookies:
referer:
using:
revision:
trust_cert:
data:
==> Cask instance method 'appcast':
---
- !ruby/object:URI::HTTPS
  scheme: https
  user:
  password:
  host: prerelease.keybase.io
  port: 443
  path: /update-darwin-prod-v2.json
  query:
  opaque:
  registry:
  fragment:
  parser:
- :checkpoint: 37f720c5a5c9be9cbf429c0b755a4b024ab900f5758f64b195bdf00c672634b4
==> Cask instance method 'version':
--- !ruby/string:Hbc::DSL::Version
str: !binary |-
  MS4wLjE4LTIwMTcwMjA5MTY1NjUzLDE3YjY0MWQ=
raw_version: 1.0.18-20170209165653,17b641d
==> Cask instance method 'sha256':
--- a5a974089e94e68ac3a5113570e903d0b88fe243d04474107645a5c792d13693
...
==> Cask instance method 'artifacts':
---
:app: !ruby/object:Set
  hash:
    ? - Keybase.app
    : true
:postflight: !ruby/object:Set
  hash:
    !ruby/object:Proc {}: true
:uninstall_preflight: !ruby/object:Set
  hash:
    !ruby/object:Proc {}: true
==> Cask instance method 'caveats':
--- []
==> Cask instance method 'depends_on':
---
...
==> Cask instance method 'conflicts_with':
---
...
==> Cask instance method 'container':
---
...
==> Cask instance method 'gpg':
---
...
==> Cask instance method 'accessibility_access':
---
...
==> Cask instance method 'auto_updates':
--- true
...
==> Hbc::Installer#install
==> Printing caveats
==> Hbc::Installer#fetch
==> Downloading
==> Downloading https://prerelease.keybase.io/darwin/Keybase-1.0.18-20170209165653%2B17b641d.dmg
Already downloaded: /Users/joshka/Library/Caches/Homebrew/Cask/keybase--1.0.18-20170209165653,17b641d.dmg
==> Downloaded to -> /Users/joshka/Library/Caches/Homebrew/Cask/keybase--1.0.18-20170209165653,17b641d.dmg
==> Verifying download
==> Determining which verifications to run for Cask keybase
==> Checking for verification class Hbc::Verify::Checksum
==> 1 verifications defined
Hbc::Verify::Checksum
==> Running verification of class Hbc::Verify::Checksum
==> Verifying checksum for Cask keybase
==> SHA256 checksums match
==> Hbc::Installer#stage
==> Extracting primary container
==> Determining which containers to use based on filetype
==> Checking container class Hbc::Container::Pkg
==> Checking container class Hbc::Container::Ttf
==> Checking container class Hbc::Container::Otf
==> Checking container class Hbc::Container::Air
==> Checking container class Hbc::Container::Cab
==> Checking container class Hbc::Container::Dmg
==> Executing: ["/usr/bin/hdiutil", "imageinfo", "/Users/joshka/Library/Caches/Homebrew/Cask/keybase--1.0.18-20170209165653,17b641d.dmg"]
==> Using container class Hbc::Container::Dmg for /Users/joshka/Library/Caches/Homebrew/Cask/keybase--1.0.18-20170209165653,17b641d.dmg
==> Executing: ["/usr/bin/hdiutil", "mount", "-plist", "-nobrowse", "-readonly", "-noidme", "-mountrandom", "/tmp", "/Users/joshka/Library/Caches/Homebrew/Cask/keybase--1.0.18-20170209165653,17b641d.dmg"]
==> Executing: ["/usr/bin/mkbom", "-s", "-i", "/var/folders/qy/vftdx05n0rl4mxvp33zrt3l00000gn/T/20170216-29786-oxhelx.list", "--", "/var/folders/qy/vftdx05n0rl4mxvp33zrt3l00000gn/T/20170216-29786-x1vw5o.bom"]
==> Executing: ["/usr/bin/ditto", "--bom", "/var/folders/qy/vftdx05n0rl4mxvp33zrt3l00000gn/T/20170216-29786-x1vw5o.bom", "--", "/private/tmp/dmg.huaKMn", "/usr/local/Caskroom/keybase/1.0.18-20170209165653,17b641d"]
==> Executing: ["/usr/sbin/diskutil", "eject", "/private/tmp/dmg.huaKMn"]
==> Creating metadata directory /usr/local/Caskroom/keybase/.metadata/1.0.18-20170209165653,17b641d/20170216083206.906
==> Creating metadata subdirectory /usr/local/Caskroom/keybase/.metadata/1.0.18-20170209165653,17b641d/20170216083206.906/Casks
==> Installing artifacts
==> Determining which artifacts are present in Cask keybase
==> Checking for artifact class Hbc::Artifact::PreflightBlock
==> Checking for artifact class Hbc::Artifact::NestedContainer
==> Checking for artifact class Hbc::Artifact::Installer
==> Checking for artifact class Hbc::Artifact::App
==> Checking for artifact class Hbc::Artifact::Suite
==> Checking for artifact class Hbc::Artifact::Artifact
==> Checking for artifact class Hbc::Artifact::Colorpicker
==> Checking for artifact class Hbc::Artifact::Pkg
==> Checking for artifact class Hbc::Artifact::Prefpane
==> Checking for artifact class Hbc::Artifact::Qlplugin
==> Checking for artifact class Hbc::Artifact::Dictionary
==> Checking for artifact class Hbc::Artifact::Font
==> Checking for artifact class Hbc::Artifact::Service
==> Checking for artifact class Hbc::Artifact::StageOnly
==> Checking for artifact class Hbc::Artifact::Binary
==> Checking for artifact class Hbc::Artifact::InputMethod
==> Checking for artifact class Hbc::Artifact::InternetPlugin
==> Checking for artifact class Hbc::Artifact::AudioUnitPlugin
==> Checking for artifact class Hbc::Artifact::VstPlugin
==> Checking for artifact class Hbc::Artifact::Vst3Plugin
==> Checking for artifact class Hbc::Artifact::ScreenSaver
==> Checking for artifact class Hbc::Artifact::Uninstall
==> Checking for artifact class Hbc::Artifact::PostflightBlock
==> Checking for artifact class Hbc::Artifact::Zap
==> 3 artifact/s defined
Hbc::Artifact::PreflightBlock
Hbc::Artifact::App
Hbc::Artifact::PostflightBlock
==> Installing artifact of class Hbc::Artifact::PreflightBlock
==> Installing artifact of class Hbc::Artifact::App
==> Reverting installation of artifact of class Hbc::Artifact::App
==> Removing App: '/Applications/Keybase.app'
==> Reverting installation of artifact of class Hbc::Artifact::PreflightBlock
==> Executing: ["launchctl", "list"]
==> Purging files for version 1.0.18-20170209165653,17b641d of Cask keybase
Error: It seems there is already an App at '/Applications/Keybase.app'.
Error: nothing to install/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/install.rb:13:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:110:in `run_command'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:149:in `process'
/usr/local/Homebrew/Library/Homebrew/cask/cmd/brew-cask.rb:8:in `<top (required)>'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Homebrew/brew.rb:24:in `require?'
/usr/local/Homebrew/Library/Homebrew/brew.rb:100:in `<main>'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:154:in `exit'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:154:in `rescue in process'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:144:in `process'
/usr/local/Homebrew/Library/Homebrew/cask/cmd/brew-cask.rb:8:in `<top (required)>'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Homebrew/brew.rb:24:in `require?'
/usr/local/Homebrew/Library/Homebrew/brew.rb:100:in `<main>'

Note in particular the following lines:
==> 3 artifact/s defined
Hbc::Artifact::PreflightBlock
Hbc::Artifact::App
Hbc::Artifact::PostflightBlock
==> Installing artifact of class Hbc::Artifact::PreflightBlock
==> Installing artifact of class Hbc::Artifact::App
==> Reverting installation of artifact of class Hbc::Artifact::App
==> Removing App: '/Applications/Keybase.app'
==> Reverting installation of artifact of class Hbc::Artifact::PreflightBlock
==> Executing: ["launchctl", "list"]
==> Purging files for version 1.0.18-20170209165653,17b641d of Cask keybase
Error: It seems there is already an App at '/Applications/Keybase.app'.
Error: nothing to install/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/install.rb:13:in `run'
...

This is where I start to lose understanding of what should be happening, but the app definitely gets deleted after this. I'm definitely not passing --force. Reading the code, it suggests that the moved.uninstall_phase is being called which does not check for --force.
I wonder if this is due to the keybase formula previously being a  formula and now only available as a cask? (See https://github.com/Homebrew/homebrew-core/pull/9852)

Like I said, please try with other casks, to narrow down the problem first.

What brew --version are you running?

Homebrew 1.1.10-10-g5a2a06380
Homebrew/homebrew-core (git revision 6407; last commit 2017-02-10)

I tried this with the zulip cask and the issue didn't trigger, but it also no longer removes the app when I try this with keybase. That said there's another problem happening now.
What I think I was seeing is:

install starts, gets to the point where the app artifact would install, hits an app already there error
starts uninstall process to revert installation, which removes the .app file installed manually

What I'm currently seeing.

as above
as above, but runs the uninstall preflight which breaks an installation that brew doesn't own when considering the command uninstalls the extra stuff that keybase installs (keybase-cli, kbfs, privileged helpers etc.)

brew cask install keybase --debug
$ brew cask install keybase --debug
==> Loading Cask definitions
==> Translating 'keybase' into a valid Cask source
==> Testing source class Hbc::Source::URI
==> Testing source class Hbc::Source::PathSlashRequired
==> Testing source class Hbc::Source::TappedQualified
==> Testing source class Hbc::Source::UntappedQualified
==> Testing source class Hbc::Source::Tapped
==> Success! Using source class Hbc::Source::Tapped
==> Resolved Cask URI or file source to '/usr/local/Homebrew/Library/Taps/caskroom/homebrew-cask/Casks/keybase.rb'
==> Cask instance dumps in YAML:
Warning: Unexpected method 'encode_with' called on Cask keybase.
Follow the instructions here:
  https://github.com/caskroom/homebrew-cask/blob/master/doc/reporting_bugs/pre_bug_report.md

If this doesn’t fix the problem, please report this bug:
  https://github.com/caskroom/homebrew-cask#reporting-bugs

==> Cask instance toplevel:
--- !ruby/object:Hbc::Cask
token: keybase
sourcefile_path: !ruby/object:Pathname
  path: /usr/local/Homebrew/Library/Taps/caskroom/homebrew-cask/Casks/keybase.rb
dsl: !ruby/object:Hbc::DSL {}
==> Cask instance method 'name':
---
- Keybase
==> Cask instance method 'homepage':
--- https://keybase.io/
...
==> Cask instance method 'url':
--- !ruby/object:Hbc::URL
uri: !ruby/object:URI::HTTPS
  scheme: https
  user:
  password:
  host: prerelease.keybase.io
  port: 443
  path: /darwin/Keybase-1.0.18-20170209165653%2B17b641d.dmg
  query:
  opaque:
  registry:
  fragment:
  parser:
user_agent:
cookies:
referer:
using:
revision:
trust_cert:
data:
==> Cask instance method 'appcast':
---
- !ruby/object:URI::HTTPS
  scheme: https
  user:
  password:
  host: prerelease.keybase.io
  port: 443
  path: /update-darwin-prod-v2.json
  query:
  opaque:
  registry:
  fragment:
  parser:
- :checkpoint: 37f720c5a5c9be9cbf429c0b755a4b024ab900f5758f64b195bdf00c672634b4
==> Cask instance method 'version':
--- !ruby/string:Hbc::DSL::Version
str: !binary |-
  MS4wLjE4LTIwMTcwMjA5MTY1NjUzLDE3YjY0MWQ=
raw_version: 1.0.18-20170209165653,17b641d
==> Cask instance method 'sha256':
--- a5a974089e94e68ac3a5113570e903d0b88fe243d04474107645a5c792d13693
...
==> Cask instance method 'artifacts':
---
:app: !ruby/object:Set
  hash:
    ? - Keybase.app
    : true
:postflight: !ruby/object:Set
  hash:
    !ruby/object:Proc {}: true
:uninstall_preflight: !ruby/object:Set
  hash:
    !ruby/object:Proc {}: true
==> Cask instance method 'caveats':
--- []
==> Cask instance method 'depends_on':
---
...
==> Cask instance method 'conflicts_with':
---
...
==> Cask instance method 'container':
---
...
==> Cask instance method 'gpg':
---
...
==> Cask instance method 'accessibility_access':
---
...
==> Cask instance method 'auto_updates':
--- true
...
==> Hbc::Installer#install
==> Printing caveats
==> Hbc::Installer#fetch
==> Downloading
==> Downloading https://prerelease.keybase.io/darwin/Keybase-1.0.18-20170209165653%2B17b641d.dmg
Already downloaded: /Users/joshka/Library/Caches/Homebrew/Cask/keybase--1.0.18-20170209165653,17b641d.dmg
==> Downloaded to -> /Users/joshka/Library/Caches/Homebrew/Cask/keybase--1.0.18-20170209165653,17b641d.dmg
==> Verifying download
==> Determining which verifications to run for Cask keybase
==> Checking for verification class Hbc::Verify::Checksum
==> 1 verifications defined
Hbc::Verify::Checksum
==> Running verification of class Hbc::Verify::Checksum
==> Verifying checksum for Cask keybase
==> SHA256 checksums match
==> Hbc::Installer#stage
==> Extracting primary container
==> Determining which containers to use based on filetype
==> Checking container class Hbc::Container::Pkg
==> Checking container class Hbc::Container::Ttf
==> Checking container class Hbc::Container::Otf
==> Checking container class Hbc::Container::Air
==> Checking container class Hbc::Container::Cab
==> Checking container class Hbc::Container::Dmg
==> Executing: ["/usr/bin/hdiutil", "imageinfo", "/Users/joshka/Library/Caches/Homebrew/Cask/keybase--1.0.18-20170209165653,17b641d.dmg"]
==> Using container class Hbc::Container::Dmg for /Users/joshka/Library/Caches/Homebrew/Cask/keybase--1.0.18-20170209165653,17b641d.dmg
==> Executing: ["/usr/bin/hdiutil", "mount", "-plist", "-nobrowse", "-readonly", "-noidme", "-mountrandom", "/tmp", "/Users/joshka/Library/Caches/Homebrew/Cask/keybase--1.0.18-20170209165653,17b641d.dmg"]
==> Executing: ["/usr/bin/mkbom", "-s", "-i", "/var/folders/qy/vftdx05n0rl4mxvp33zrt3l00000gn/T/20170216-55997-151dycv.list", "--", "/var/folders/qy/vftdx05n0rl4mxvp33zrt3l00000gn/T/20170216-55997-nz30ce.bom"]
==> Executing: ["/usr/bin/ditto", "--bom", "/var/folders/qy/vftdx05n0rl4mxvp33zrt3l00000gn/T/20170216-55997-nz30ce.bom", "--", "/private/tmp/dmg.GDkBji", "/usr/local/Caskroom/keybase/1.0.18-20170209165653,17b641d"]
==> Executing: ["/usr/sbin/diskutil", "eject", "/private/tmp/dmg.GDkBji"]
==> Creating metadata directory /usr/local/Caskroom/keybase/.metadata/1.0.18-20170209165653,17b641d/20170216234052.243
==> Creating metadata subdirectory /usr/local/Caskroom/keybase/.metadata/1.0.18-20170209165653,17b641d/20170216234052.243/Casks
==> Installing artifacts
==> Determining which artifacts are present in Cask keybase
==> 3 artifact/s defined
#<Hbc::Artifact::PreflightBlock:0x007fb552a902e0>
#<Hbc::Artifact::App:0x007fb552a90268>
#<Hbc::Artifact::PostflightBlock:0x007fb552a901f0>
==> Installing artifact of class Hbc::Artifact::PreflightBlock
==> Installing artifact of class Hbc::Artifact::App
==> Reverting installation of artifact of class Hbc::Artifact::PreflightBlock
==> Executing: ["launchctl", "list"]
==> Executing: ["/Applications/Keybase.app/Contents/SharedSupport/bin/keybase", "uninstall"]
==> 2017-02-16T17:40:52.274194 ▶ [INFO keybase launchd.go:291] 001 Removing /Users/joshka/Library/LaunchAgents/keybase.kbfs.plist
==> 2017-02-16T17:40:52.277914 ▶ [INFO keybase launchd.go:217] 002 Waiting for keybase.kbfs to exit...
==> 2017-02-16T17:40:52.486961 ▶ [INFO keybase launchd.go:160] 003 Stopped keybase.kbfs
==> 2017-02-16T17:40:52.491151 ▶ [INFO keybase mounter_nix.go:29] 004 Trying to unmount: /keybase
==> 2017-02-16T17:40:52.499879 ▶ [INFO keybase launchd.go:291] 005 Removing /Users/joshka/Library/LaunchAgents/keybase.service.plist
==> 2017-02-16T17:40:52.504451 ▶ [INFO keybase launchd.go:217] 006 Waiting for keybase.service to exit...
==> 2017-02-16T17:40:52.718048 ▶ [INFO keybase launchd.go:160] 007 Stopped keybase.service
==> 2017-02-16T17:40:52.722273 ▶ [INFO keybase launchd.go:291] 008 Removing /Users/joshka/Library/LaunchAgents/keybase.updater.plist
==> 2017-02-16T17:40:52.726265 ▶ [INFO keybase launchd.go:217] 009 Waiting for keybase.updater to exit...
==> 2017-02-16T17:40:52.939543 ▶ [INFO keybase launchd.go:160] 00a Stopped keybase.updater
==> 2017-02-16T17:40:53.024266 ▶ [INFO keybase install_osx.go:694] 00b Removing KBFuse
==> 2017-02-16T17:40:53.127623 ▶ [INFO keybase install_osx.go:699] 00c Removing privileged helper tool
==> 2017-02-16T17:40:53.230287 ▶ [INFO keybase install.go:222] 00d Removing /usr/local/bin/keybase
==> Purging files for version 1.0.18-20170209165653,17b641d of Cask keybase
Error: It seems there is already an App at '/Applications/Keybase.app'.
Error: nothing to install/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli/install.rb:13:in `run'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:111:in `run_command'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:154:in `process'
/usr/local/Homebrew/Library/Homebrew/cask/cmd/brew-cask.rb:8:in `<top (required)>'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Homebrew/brew.rb:24:in `require?'
/usr/local/Homebrew/Library/Homebrew/brew.rb:100:in `<main>'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:159:in `exit'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:159:in `rescue in process'
/usr/local/Homebrew/Library/Homebrew/cask/lib/hbc/cli.rb:145:in `process'
/usr/local/Homebrew/Library/Homebrew/cask/cmd/brew-cask.rb:8:in `<top (required)>'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
/usr/local/Homebrew/Library/Homebrew/brew.rb:24:in `require?'
/usr/local/Homebrew/Library/Homebrew/brew.rb:100:in `<main>'

I came back from vacation and did a "brew update", and surprisingly, it basically installed keybase (said it was moved from the old location to Casks/keybase.rb), which ended up replacing a CLI program with something that want's root to install a system fuse filesystem.
I always thought that "brew update" was largely safe, and "brew upgrade" was where the bad things would end up happening, if anything...

@weingart That has noting to do with this issue.
There’s already an issue open for that problem (in https://github.com/Homebrew/brew/, I think).

We have already fixed this and narrowed the issue at the time to keybase, right?


rkt run --set-env-file errors if file contains comments

Support for rkt run --set-env-file some-file ... was added in 1.9 with https://github.com/coreos/rkt/pull/2816. According to docs "Lines starting with # or ; and empty ones will be ignored." This was true until 1.10.1 when a regression was introduced by https://github.com/coreos/rkt/pull/2901.
What did you do?
Running a container with an env-file which contains an error complains about malformed key=value.
## OK
$ sudo rkt run coreos.com/etcd:v3.0.6

## Not OK
$ cat > temp << EOF
# Some comment
FOO=bar
EOF
$ sudo rkt run --set-env-file=temp coreos.com/etcd:v3.0.6
Error: invalid argument "temp" for --set-env-file=temp: environment variable must be specified as name=value (file &{%!q(*os.file=&{3 temp <nil>})})

Removing the comment line from the file temp allows it to be used as an env-file again.
Why
The comment line token check was moved below the = token pair splitter, likely by mistake.
Work-around
For now, I've removed comments from my development env files.
Possible fix
Here is a possible fix https://github.com/coreos/rkt/pull/3115
cc @alepuccetti

Closed via #3115


Fix for extended types can missing annotations

Extended types were not getting the correct annotations.  They were getting the annotations from the inherited type alone, not any additional annotaions on the extend block.

I deviated from what we talked about before.  The main reason was that by the time we are in insert_extend_annotations the TypeDecl for the extended type still didnt have any annotations associated with it.  This is because it was grabbing the annotations from its parent, not the extend block.  I am not 100% happy with this, it feels a bit cludgy but it does work.

I deviated from what we talked about before. The main reason was that by the time we are in insert_extend_annotations the TypeDecl for the extended type still didnt have any annotations associated with it. This is because it was grabbing the annotations from its parent, not the extend block. I am not 100% happy with this, it feels a bit cludgy but it does work.

I'm not really following this.  I'm inclined to agree that the approach here feels kind of cludgy.  And I don't think it works with something like:
domain dom {
    resource res {}
}

extend dom.res {
    // ...
}

Which, I think is something that should be considered valid.
I don't really understand the issue you're describing above.  Isn't the whole point of insert_extend_annotations() that the TypeDecl doesn't have any annotations?  That's why we saved them to insert later.
Maybe it just needs more cleanup in extend_type_map().  Right now we only handle @associate annotations, which get inserted on the parent.  But we should be able to grab the annotations on the nested type and directly insert them into the Map extend_type_map() returns for the type itself.

I made the changes to insert_extend_annotations to have it run twice.  And I added it around here to match where it was previously called.  The expressions passed into the new PolicyFile, which is then passed into extend_type_map is the first time in compile_machine_policies_internal where bar.tmp is present.  But when I looked into all of the information that is passed into extend_type_map I saw no reference to a noderive association.  So I am not exactly sure where to pull it from to save it off.
So, I dug deeper into where the expressions for bar.tmp where created came up with this solution.
I tried to compile
domain dom {
    resource res {}
}

extend dom.res {
    // ...
}

And got
error: Unexpected character "."
   ┌─ data/policies/extend.cas:36:11
   │
36 │ extend dom.res {
   │           ^ Expected "inherits" or "{"

error: Unexpected character "{"
   ┌─ data/policies/extend.cas:36:16
   │
36 │ extend dom.res {
   │                ^ Expected "(" or "." or "<"

Abandoning


Add unit tests to the new PreemptStrategyNormal and SmoothWidgetsFlutterBinding

[ ] including logic of shouldShiftOneFrameForInterestVsyncTarget

Problem: in tests, seems that onbeginframe gets the current timestamp? but in real world, it gets vsynctargettime (i.e. future time)? so cannot test

[TODO]

But, since it is relative time, maybe just abuse it?

It is indeed simple. just use SimpleDateTime everywhere, and use "diff-datetime-to-timestamp" when needing a timestamp. that'sall

wrong. what about currentVsyncTargetTime

review the problem

Method B: strategy is completely isolated from bindings etc

[TODO] ... and add VsyncSource class

seems no problem?

Question: can we use real preemptstrategy for tests?
Q: then, how to simulate time elapse?

Question: do we really need "add one frame" in _currentFrameVsyncTargetDateTime?

this is wrong?
consider: we are just at 18ms, then need to use prev vsync?

will be continued: #41


TO: upgrade todb test to go 1.11

What does this PR (Pull Request) do?

[x] This PR fixes #3644

Which Traffic Control components are affected by this PR?
No components affected: only fixes building of docker image for traffic ops database testing.  No additional tests or documentation required.
What is the best way to verify this PR?
Run the traffic ops db tests in docker:
cd traffic_ops_db/test/docker
docker-compose up --build --exit-code-from trafficops-db-admin

without this change, the trafficops-db-admin image would fail to build.
The following criteria are ALL met by this PR

[x] This PR includes tests OR I have explained why tests are unnecessary
[x] This PR includes documentation OR I have explained why documentation is unnecessary
[x] This PR includes an update to CHANGELOG.md OR such an update is not necessary
[x] This PR includes any and all required license headers
[x] This PR ensures that database migration sequence is correct OR this PR does not include a database migration
[x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/trafficcontrol-PR/3759/
Test PASSed.


Upgrade to Terraform 0.12. Add health_check parameter.

Fixes #10, #3, #9

Note, that the example requires the latest terraform-google-vm module that hasn’t been released yet. In particular, it relies on the project_id parameter added in this commit https://github.com/terraform-google-modules/terraform-google-vm/commit/d246bd3b3ba9ba7c8923980d2585b2f17ea1d3d6

Noticed that the zone input was dropped from the mig module, couldn't find the input in the instance_template module as well, so couldn't pass it the way it was passed before https://github.com/terraform-google-modules/terraform-google-lb-internal/blob/master/examples/simple/mig.tf#L45,


New RHEL 9.4 ISO is to big to fit, had to make the partitions larger

New RHEL 9.4 ISO is to big to fit, had to make the partitions larger

/lgtm


Artifact upload destination env

@mcgain was trying to setup a custom s3 bucket for artifact uploads and noticed that $BUILDKITE_ARTIFACT_UPLOAD_DESTINATION is only respected in the bootstrap's default artifact uploader, and not when using buildkite-agent artifact upload ... manually. It seems the destination arg is not a normal flag and doesn't ingest environment variable values by default, so if the argument is not supplied positionally then it always uses the default buildkite artifact bucket. I've added support to our arg parser so that positional args can also fall through to environment variables, which doesn't seem to be available in the codegangsta cli package.
@mcgain, care to give it a go and confirm it's working now?

I tried this out locally and it works fine now. Thanks!


#700 & #701: HTTPClient.shared a globally shared singleton & .browserLike configuration

Offer HTTPClient.shared, a global singleton HTTPClient that doesn't need shutdown (because it lives as long as your application). This globally shared HTTPClient does not accept any special configuration and uses HTTPClient.Configuration.browserLike (also introduced in this PR).

fixes #700
fixes #701

I'm somewhat worried about this tbh and am wordering if rephrasing these APIs a bit could help?
What if we documented "do a let http = HTTPClient.makeShared() when you need one" and at least then if necessary moving to a configured one is less painful than the pain from moving of a HTTPClient.shared sprinkled allover the codebase...?
The docs could literarily say that the simplest way is:
let http = HTTPClient.makeShared()

and you can just exit the process if you want to -- you may lose in flight requests or whatever. And then we explain, well, if you do care -- please hook into service lifecycle, (and here's how ...). If folks don't care they can literarily plop a global let http into their codebase and call it a day.
The "make" could function the same as this ".shared" but I wonder how we should be recommending this to be used, such that moving to "oh no, actually I do need to configure it" isn't a world of pain... Otherwise we'll end up allowing "configure the global shared one" which is not something we'd want I feel...
Note also that a global will become main actor isolated in Swift 6 most likely, so there will be a hop like that. The SDK will have the same issue, so yeah we'd be on equal footing, but I am wondering if we can't do better and recommend things like:
actor INeedHTTP {
  let http: HTTPClient = .shared // .makeShared() ?

}

to avoid un-necessary hops to the global actor...?

Either way, at least tracing in applications "will work" but Fabian's concern that parallel testing with asserting on traces will be impacted and not usable if shared instances are used.
So... I guess this is fine, but I'm not very happy about it -- I'd like to consider if we can at least recommend "to the global variable yourself" and change how we phrase it in order to make "move away from static global func everywhere" less painful when people will need to do so.

Hi, Has there been any progress on this PR?

I'm eager for this change. It resolves the main issues I see people (including myself at times) run into with libraries that depend on AHC, and I feel that 99% of people will want the default configuration for AHC anyways. This change makes it much easier to set up libraries based on AHC for end-users, in addition to making it more accessible to send HTTP requests.
One issue I tend to run into during (Lambda) application setup is that I need to fetch secrets before booting the remainder of services. If anything errors during this phase, and AHC is not correctly shut down under failing circumstances, the deinit will trigger a crash before the error is caught and displayed to the user. This leads to very confusing scenarios to debug, and is very hard to understand for the less-than-expert Swift developer.

I'm also looking forward to be able to use this, but I do still want the configurability.
Perhaps we can use some mechanism like swift-log's LoggingSystem bootstrap to let the shared HTTPClient be configurable?
Some stuff libraries like the "aws-lambda" can provide APIs to users to be able to do a "pre-setup" so users can setup stuff like the LoggingSystem and HTTPClient as soon as they should.
Otherwise if the user is in charge of the main function of the entrypoint they should be able to setup the HTTPClient soon enough.

After reading a recommendation to switch over from URLSession to this package, I too would love to see this land!

Just today was working with AHC and wondering—what is the best way to work with the client? It's not very clear from description.
My initial assumption was shutdown is when an application stops working. But apparently from description one should use shutdown to prevent memory leaks? It's also somewhat not very clear what Shuts down the client and event loop gracefully. does really mean...
The thing is, it became very manual to check all creations/shutdowns of clients, even for our small service, wondering how it's for bigger apps... So this PR is very welcoming.
Though I have some questions:

How does this solves memory leak issue then? 🤔 I see it just uses different config, but not sure how it helps. Maybe missing something, not very familiar with the code tbh.
What is advantage of using let httpClient = HTTPClient.shared rather than defining let httpClient = HTTPClient(eventLoopGroupProvider: .singleton) in your app?
Reading through comments, think maybe having a function makeShared() as @ktoso mentioned is actually a better approach. Otherwise it's a global instance and can be misused or lead to unexpected errors (e.g. when you want shared per some system but end with shared between them).

Anyway, looking forward for PR to be merged! 🙂

If you are writing an app, then using a singleton like this is almost certainly the best approach. The main reason to use non-singleton clients is to isolate state. This is useful if you have separate privacy domains (e.g. different credentials, TLS identities, cookies, etc.) or if you want to be sure you're starting from a clean slate when you're writing tests.
Otherwise, you should have long-lived clients and except in rare cases you should never shut them down.

build timeout:
[519/522] Testing AsyncHTTPClientTests.StressGetHttpsTests/testStressGetHttps
[520/522] Testing AsyncHTTPClientTests.TestIdleTimeoutNoReuse/testIdleTimeoutNoReuse
[521/522] Testing AsyncHTTPClientTests.NoBytesSentOverBodyLimitTests/testNoBytesSentOverBodyLimit
Build timed out (after 10 minutes). Marking the build as failed.
$ ssh-agent -k

Would love to see a release with this in. I'm just about to release the beta for Soto and this allows me to get rid of the requirement to shutdown the Soto client, as I don't have to manage an HTTPClient

I'm just about to release the beta for Soto and this allows me to get rid of the requirement to shutdown the Soto client, as I don't have to manage an HTTPClient

I would caution against Soto relying solely on HTTPClient.shared. It's almost inevitable that you'll need to set up your own HTTP client with special configuration (maybe number of connections to host, connection pool size, ...).
If you design Soto to not have a shutdown, then Soto essentially becomes a singleton-only library which I don't think is a good and scalable design.
What I would recommend is to design Soto to have a correct lifecycle and make shutdown calls always required. But additionally you may offer your own SotoS3Client.shared or similar for the users that are happy with losing control over resources and losing configurability.
Personally I think it's really important that on the server side all important libraries have correct lifecycles and here are some of the reasons why:

Resource limit control (maybe you want to allow 100k connections at the same time, maybe only 1)
Resource control (by running shutdown you can be sure that all resources have been terminated, with singletons that's impossible)
Resource isolation (Often servers have more than one component in one address space. But frequently these components have a differing level of importance. For example you may have your service & and admin HTTP endpoint. There may come a time when you discover that your admin endpoint is eating up resources that your service needs. With correctly managed lifecycles and no singletons you can now configure your admin endpoint to get its own EventLoopGroup (just 1 thread), its own instances of HTTPClient (configured with smaller limits), ...)
other configuration like Network.framework vs. BSD sockets that may differ in different parts of a program

I would caution against Soto relying solely on HTTPClient.shared. It's almost inevitable that you'll need to set up your own HTTP client with special configuration (maybe number of connections to host, connection pool size, ...).

Soto would not rely on the shared instance. You will still be able to provide your own HTTPClient instance. But I was mistaken I thought the only resources Soto relied on that needed a shutdown were controlled by HTTPClient that is not the case.
But I would like to be in the position where Soto is not controlling the lifecycle of of a HTTPClient. Currently the options for Soto are provide your own HTTPClient or Soto will create one for you. I would prefer it to be provide your own HTTPClient or Soto will use the shared instance.

I would caution against Soto relying solely on HTTPClient.shared. It's almost inevitable that you'll need to set up your own HTTP client with special configuration (maybe number of connections to host, connection pool size, ...).

Soto would not rely on the shared instance. You will still be able to provide your own HTTPClient instance. But I was mistaken I thought the only resources Soto relied on that needed a shutdown were controlled by HTTPClient that is not the case.
But I would like to be in the position where Soto is not controlling the lifecycle of of a HTTPClient. Currently the options for Soto are provide your own HTTPClient or Soto will create one for you. I would prefer it to be provide your own HTTPClient or Soto will use the shared instance.

Yes, all are options. I'd just make sure that the API contracts are spelled with an always/never. Like in HTTPClient (I hope we removed exceptions):

If you call HTTPClient.init() you always have to call client.shutdown()
If you use HTTPClient.shared you never have/should to call shutdown()

In the past we tried this misguided EventLoopGroupProvider thing which was just not a good idea. The problem is that you end up with objects that you sometimes need to shut down, depending on what value you passed into the init, that just doesn't seem right.
I'd suggest a similar design in Soto: Either lifecycle or singleton, but not a combination thereof.

Aside: I would imagine that over time Soto will have to manage other resources that aren't just a HTTPClient too. If you already have a shutdown mechanism: easy: add it there. If not: screwed :|. And libraries of the size/shape of Soto will always need other resources in my experience. The only way out is to lean into singletons all the way but then we lose resource control which is fine for certain smaller applications but certainly not always true (+ it's a pain to test).


docs: update some doctest examples

Motivation
Cleaned up doctests with tokio::main and no_run, and etherscan tests which all had redundant client initializations which are not the focus of the example
I don't believe running async tests in doctests is a great practice
Breaking change in etherscan::Client::get_ether_balance_multi because slice of references is not good

Solution

PR Checklist

[ ] Added Tests
[ ] Added Documentation
[ ] Breaking changes

We have another small breaking change in ethers-etherscan already from #2327


labeling_function as a method on class

Hi i want to know the method labeling function decorator with class
tutorial and guide have only function based example
i want to use like following example.
class LabelingFunctions:
@labeling_function()
def something(self, x):
return 1
but in this case, it occur a error like 'TypeError: LabelingFunctions.something() missing 1 required positional argument: 'x'
because it has 'self' as a parameter on method. how can i use class based labeling
thank you

@SomewhereInTheVastUniverse
Can you modify your example like the following:
@labeling_function()
def something(x):
    return 1

If you look at the documentation in https://github.com/snorkel-team/snorkel/blob/61c60e8496a057057c663912bafb0614ed2fc98a/snorkel/labeling/lf/core.py#L84, you can see that when defining the function, you only pass in 'x' as the argument and not self.

@SomewhereInTheVastUniverse
Can you modify your example like the following:
@labeling_function()
def something(x):
    return 1

If you look at the documentation in
https://github.com/snorkel-team/snorkel/blob/61c60e8496a057057c663912bafb0614ed2fc98a/snorkel/labeling/lf/core.py#L84
, you can see that when defining the function, you only pass in 'x' as the argument and not self.

okay then, i can use only function case. thank you.


Redo the interface for SBOM generation

Describe the Enhancement
I would like to see the SBOM generation reworked behind a new interface or abstraction. We had some limits imposed when this functionality was added because we didn't want to break compatibility in v1. That is not a concern with v2, so we should rethink the SBOM interface and abstractions in the library.
In particular, I would like to be able to easily swap in/out different SBOM generators w/out causing changes to core code.
Motivation
SBOM is an area where things are still changing rapidly. We need to be flexible. We also need to support multiple tools, because Syft is not the only tool folks want to use.

Could we actually deprecate the old SBOM logic and compatibly introduce an alternative? That would decouple this from bumping the major version of libpak - at least until we want to eventually remove the deprecated API.

Possibly, but the thought with this issue is that we won't be able to introduce a new API that is acceptable without breaking the API in some way. The previous attempt had limits to which we could go without breaking things, so I'm hoping that we can break things so that we can arrive at an API that is better suited for the task.


Update CBMC starter kit

Issue #, if available:
Description of changes:

changes the SPDX identifier in CBMC proof Makefile from MIT to MIT-0
introduces updates to the files related to the CBMC starter kit (this was accomplished by running cbmc-starter-kit-update).
removes 2 .git submodules (this was accomplished by running cbmc-starter-kit-update --remove-starter-kit-submodule --remove-litani-submodule). symlinks to files present in the CBMC starter-kit submodule are no longer present Additionally, a user will have to install litani (instructions here) in order to run CBMC proofs locally. litani is present in the CI system that executes the CBMC proofs.
updates the README to include a section on CBMC.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

The latest commit concerned solely the SPDX identifier change.

/bot run checks


Fix all reportPrivateImportUsage in pyright

Type of changes

[x] Bug fix
[ ] New feature
[ ] Documentation / docstrings
[ ] Tests
[ ] Other

Checklist

[x] I've run the latest black with default args on new code.
[x] I've updated CHANGELOG.md and CONTRIBUTORS.md where appropriate.
[ ] I've added tests for new code.
[x] I accept that @willmcgugan may be pedantic in the code review.

Description
This commit adds TYPE_CHECKING guards to the __main__ sections of all
files that imported/redefined part of their own API in this section.
This hides the redefinition from type checkers as needed to avoid
accidentally signalling the API as private.
This PR resolves https://github.com/willmcgugan/rich/issues/1523
I didn't update CONTRIBUTORS since the change is minor, but if you have a policy of always updating it let me know and I'll add my name.

I brought up the possibility of excluding __main__ sections with upstream, but the feeling was that it's really a library issue. The proper TYPE_CHECKING guard is simple enough anyway.

Thanks. I think I'll go with 2.

Isn't really an option. The main blocks are fairly integral and popular feature.


Deploy test server

Deployed to https://test.skohub.io/
$ node src/subscriber.js https://test.skohub.io/hub http://test.lobid.org/gnd/118696432

$ curl -i -H "Content-Type: application/ld+json" "https://test.skohub.io/inbox?target=http://test.lobid.org/gnd/118696432" -d '{"foo": "bar"}'
HTTP/1.1 202 Accepted

When I try this, I get the 202 Accepted but do not see the notification being logged by the subscriber.  Shouldn't it be that way?

The commands from https://github.com/hbz/skohub-pubsub/pull/12#issue-274406968 work fine (but like for Adrian, nothing is logged by the subscriber).
However I have problems with the README steps:

Basic setup, curl -i "localhost:3000/inbox?target=https://test.lobid.org/gnd/118696432" (I added the test subdomain, this should work, right?) -> 400 Bad Request, Invalid link headers for target URL (same in master)
Further down, node src/subscriber.js http://localhost:3000/hub http://$address:$port/some/random/path (I set address and port to my publisher) -> Could not connect to hub http://localhost:3000/hub (works in master)

Basic setup, curl -i "localhost:3000/inbox?target=https://test.lobid.org/gnd/118696432" (I added the test subdomain, this should work, right?) -> 400 Bad Request, Invalid link headers for target URL (same in master)

This is expected behavior. The Link headers returned by http://test.lobid.org/gnd/118696432 do no point to localhost:3000 but to https://test.skohub.io:
$ curl -i http://test.lobid.org/gnd/118696432
HTTP/1.1 200 OK
Date: Tue, 30 Apr 2019 08:53:11 GMT
Server: Apache/2.4.10 (Linux/SUSE)
Link: <https://test.skohub.io/inbox?target=http://test.lobid.org/gnd/118696432>; rel=http://www.w3.org/ns/ldp#inbox, <https://test.skohub.io/hub>; rel=hub, <http://test.lobid.org/gnd/118696432>; rel=self
Access-Control-Allow-Origin: *

Thus the inbox at localhost:3000 rejects the request as of https://github.com/hbz/skohub-pubsub/issues/7. I need to update the README accordingly. Please also note that we agreed to use the http URIs for lobid targets in https://github.com/hbz/lobid-gnd/issues/184#issuecomment-479890419.

I see. Also, since it's the same in master it's not actually relevant for this PR. The second point however seems to be related to the changes here, since it works for me in master:

Further down, node src/subscriber.js http://localhost:3000/hub http://$address:$port/some/random/path (I set address and port to my publisher) -> Could not connect to hub http://localhost:3000/hub (works in master)

Further down, node src/subscriber.js http://localhost:3000/hub http://$address:$port/some/random/path (I set address and port to my publisher) -> Could not connect to hub http://localhost:3000/hub (works in master)

This was also due to the Link headers, see https://github.com/hbz/skohub-pubsub/pull/12/commits/9f62edab335cf32bda7ab20aaa1db7cb47e5a915 for an updated README. To test the PR though, it is not necessary to run the hub locally. The hub is running at https://test.skohub.io/hub, looking into https://github.com/hbz/skohub-pubsub/pull/12#issuecomment-487856537 now (was working when I opened the PR).

When I try this, I get the 202 Accepted but do not see the notification being logged by the subscriber. Shouldn't it be that way?

Doh, I tested this by running the subscriber on https://test.skohub.io - it obviously cannot work when you run the subscriber locally, because the hub cannot POST to your local machine. We will have to think about a proper test setup, or even better yet implement a subscriber for lobid-gnd.
In the meantime, you can use https://test.skohub.io/deck/ to test subscriptions in the browser using WebSocket. Use wss://test.skohub.io as the hub URL and subscribe e.g. to http://test.lobid.org/gnd/118696432:

Then send a notification to the inbox of http://test.lobid.org/gnd/118696432:
$ curl -i -H "Content-Type: application/ld+json" "https://test.skohub.io/inbox?target=http://test.lobid.org/gnd/118696432" -d '{"foo": "bar"}'

And see it logged in the browser:


Receive email from domain like gmail, yahoo etc

Hello I tried to set up a mail server with this module.
The server is able to receive email from a python script from remote, but it doesn't receive email when the sender is an email from gmail or similar.
I have set the noip domain and the mx recorde itself.

By default, gmail or yahoo will use your MX record, and port 25. I know for a fact this works, because I get emails all the time myself.
My guess is that your ISP (especially if it's Cox) is blocking port 25. Or it could be your firewall. There are a number of reasons that other providers could not get email to you, but it's definitely not aiosmtpd that's the problem.

Thank you for your response. The port 25 is opened, the mail server is an amazon aws machine with ubuntu linux, it was running postfix.

When I send an email what is the user I should use, for example my domain is mydomain.biz and the mx record is mail.mydomain.biz, can I send an email to<EMAIL_ADDRESS>

OK it works, it was a problem with the hostname.


ver 7.9.1 use api /forms/chromium/convert/html error :

i deploy gotenberg  7.9.1 on openshift and i use convert html to pdf with htmfile and got error
convert HTML to PDF: convert to PDF: chromium PDF: wait for events: wait for event LoadEventFired: context deadline exceeded
convert HTML to PDF: convert to PDF: chromium PDF: wait for events: wait for event networkIdle: context deadline exceeded

thank you.

Hello @sgamro,
Looks like the HTML document you're giving to Gotenberg cannot be converted before the timeout duration.
Could you try on the demo instance (https://demo.gotenberg.dev) or increase the API timeout with --api-timeout?

Hello @sgamro,
Looks like the HTML document you're giving to Gotenberg cannot be converted before the timeout duration.
Could you try on the demo instance (https://demo.gotenberg.dev) or increase the API timeout with --api-timeout?

how to set  args --api-timeout on openshift.

I have solved this problem caused by html including the font from url to connect another server
I deleted these lines and converted the new pdf. It works fine.
Thank you very much for your help.


pull-request-hotkeys works intermittently

Description
I would like to press a keyboard shortcut to quickly go to the conversation tab from e.g. the /files tab. Sumtim + Sumtim + C (for Conversation) would make the most sense to me.
Example URLs

https://github.com/refined-github/refined-github/issues/1

I'm noticing intermittent behavior on some PRs vs other PRs. Something is off, as I just tested this on https://github.com/refined-github/refined-github/pull/3500/files and I'm seeing it work now.
From Conversation tab (1):

g + 2 takes me to "commits"
g + 3 takes me to "checks"
*** g + 4 does not take me to "files**

From Commits tab (2):

g + 1 takes me to "conversation"
g + 3 takes me to "checks"
g + 4 takes me to "files

From Checks tab (3):

g + 1 does not take me to "conversation"
*** g + 2 does not take me to "commits"**
*** g + 4 does not take me to "files**

From Files tab (4):

g + 1 takes me to "conversation"
g + 2 takes me to "commits"
g + 3 takes me to "checks"

I'm already seeing a bunch of errors:

I'm already seeing a bunch of errors:

The errors are all about your missing token.

I'm noticing intermittent behavior on some PRs vs other PRs

Same here, even on the same PR across reloads. I turned this into a bug report. This is most likely a race condition (or GitHub A/B testing some classes)

Is it possible to also add the g 1, g 2 etc. shortcuts in the help (shift ?) so that folks knows about it? 🙏
I spent 30 mins trying to find that shortcut 😅

Same here, even on the same PR across reloads. I turned this into a bug report. This is most likely a race condition (or GitHub A/B testing some classes)

Thank you for the sanity check!!!

The errors are all about your missing token.

Thanks, didn't even realize I needed one, I just added a token.


hybrid-analysis?

I don't see hybrid-analysis on the list?
https://www.hybrid-analysis.com

Hybrid Analysis is a great tool for malware analysis, but it's not a good fit for this repository. I don't think there are other sandboxes on the list, so adding this one, would open the floodgates.
I don't know if you're aware of https://github.com/rshipp/awesome-malware-analysis. If not, you should definitely take a look. There are lots of tools for malware analysis in there, including Hybrid Analysis.

I think I'm going to include some references to other lists that are related to this one. Thanks for the nudge! 😄


Add implementation for to_netcdf()

Please confirm that this PR has done the following:

[x] Tests Added
[x] Documentation Added
~Name of contributors Added to AUTHORS.rst~
[x] Description in RELEASE_NOTES.md Added

Description of PR
This PR refactors #898 to use the internal pd.Series object for efficiency.

Merging to make a new release before the end of the year and send announcements before the break


Adds a verifyCompatibility method to the Win32FileSystem to report case-sensitivity issues

-triggered during debug only
-still need to expand that to handle bad directories.

doesn't catch em all, but does catch more than a few. example output:
https://gist.github.com/Azaezel/84b902169a9a66a6735a#file-gistfile1-txt-L630-L810

I like this idea; thanks for this! Is OSX not also case-insensitive and would benefit from having this check? That can happen in the future though.

OSX needs more work to be verified functional Possibly up to and including yet another pass at the opengl layer. (and for myself, still need to save up to get one to compile on instead of having to throw builds to my artists).
Do wish https://msdn.microsoft.com/en-us/library/windows/desktop/aa364419(v=vs.85).aspx didn't explicitly require the operating system itsself to be set up for case sensitivity in order to properly trigger based on FIND_FIRST_EX_CASE_SENSITIVE to catch the directories, but perhaps we'll have better luck once we do get to the apple end there.