ci-automation: Add foundational testing primitives

This PR adds testing primitives and tapfile handling to the "containerised builds" ci-automation.
Design:

A generic "test.sh" stub takes care of starting test wrappers within the SDK container. The script will also re-run failed tests to ensure failures are consistent, avoiding breakage from transient failures. The retry count is very high by default (999).
Image / vendor specific scripts in ci-automation/vendor-testing/ take care of running the actual tests. These scripts are being run in the SDK container.
A helper library for querying and for merging tap files is also supplied. It's currently used to figure out if tests failed and should be re-run. It is envisioned this script will later be used by another job to merge all tap files of a release.

Would it help to do some of the restart logic directly in kola? We have reprovisioning retries there already and could also do this for the tests itself (with one TAP report entry per test execution).

Thank you very much for the review! I'll implement the feedback today and update the PR.

In general I would have liked to start from the current working setup instead and adapting it to use the SDK container where needed instead of rearchitecting it which means that we have to rewrite most test platform integrations and get them right which is very time consuming.

I would like to try and prevent this. The current test implementation is tightly coupled to our internal Jenkins logic and will be very hard to generalise. We risk ending up polluting the clean interfaces the containerised CI automation currently employs - just consider the dozens of env vars woven into the current set-up, and our failure to adapt these when we were struggling with the Google bucket issue. I think there is a lot of value in re-thinking our approach to CI and testing.
The main criteria I'm pursuing is: What if you would need to set up the whole infra from scratch - how much effort would that take you? What components / services are you required to use because of assumptions baked into the automation? To give you an example: Can you set up the current infrastructure - or the re-designed containerised infra retrofitted to run the "old" test automation - so it builds for and tests a single platform we don't support (say, openstack)? Do you need AWS and GCP accounts (my assumption would be "yes")? Do you need to use Jenkins? I'd like to keep the effort at a minimum, and make as few assumptions as possible. Doing a re-design seems the faster / easier way to get there.

Would it help to do some of the restart logic directly in kola? We have reprovisioning retries there already and could also do this for the tests itself (with one TAP report entry per test execution).

I don't think that's the right place; it would make it harder to adapt to custom environments (changing go code and automation instead of just adapting automation glue).

fixed some issues in test.sh which effectively broke re-runs
reduced retries to 20 (which feels sufficient for transient issues) in an attempt to address @jepio 's concern.

Updated packages.sh and the test script in accordance with this proposal: https://github.com/flatcar-linux/scripts/pull/228#issuecomment-1044571244

I would be happy to have this merged and integrated into CI, but with standalone builds of kola outside of the SDK container.

I would be happy to have this merged and integrated into CI, but with standalone builds of kola outside of the SDK container.

I agree this is a different topic to tackle. With standalone builds I would like to see a proposal on how I can reproduce the tests locally (or on another server) without having access to the parameters of the respective Jenkins build.

PR cherry-picked to flatcar-3033, flatcar-3066, and flatcar-3139.


HeplerFuntions in each class synced with main.cpp of main branch

Here each class
(1) Move Stack   (2) Queue  (3) ResultStack   (4)  LLNode  (5) LL  (6) LL2DNode  (7) LL2D  (8) TicTacToeGame  (9) TicTacToePro
Now each of these classes have different functions

MoveStack:
Description: This class represents a stack data structure to store the moves made in the Tic-Tac-Toe game.
Main Function: It provides methods to push a move onto the stack, pop a move from the stack, check if the stack is empty, and clear the stack.

2)Queue:
Description: This class represents a queue data structure to store the values/moves of each computer that will play in the game.
Main Function: It includes methods for enqueueing items, dequeuing items, checking if the queue is empty, and clearing the queue. It also has a function to fill the queue with random values (1-9) without duplicates.
3)ResultStack:
Description: This class represents a stack data structure to store and display the total instances of wins, losses, or ties across all game modes (except CvC).
Main Function: It provides methods for pushing results onto the stack, checking if the stack is empty, and popping results from the stack.
4)LLNode:
Description: This class represents a node for a linked list that stores the state of the game board for each move in the game.
Main Function: It initializes the node with default values and has members to store the board state, player's move, and other relevant information.
5)LL:
Description: This class represents a linked list that stores the state of the game board for each move in the game. It is used for a single session of the game.
Main Function: It provides a method to add a move to the linked list and a method to display all moves played in a session.
6)LL2DNode:
Description: This class represents a node for a 2D linked list that stores multiple sessions of the game.
Main Function: It initializes the node with default values and contains a pointer to an LL object.
7)LL2D:
Description: This class represents a 2D linked list that stores multiple sessions of the game.
Main Function: It provides a method to add a new LL (linked list) to the 2D linked list.

TicTacToeGame:
Description: This class is the main class that handles the Tic-Tac-Toe game. It includes functions for initializing winning conditions, resetting the game board, checking if the game is over, evaluating the game board, finding the best move for the computer player, and more.
Main Function: It orchestrates the entire Tic-Tac-Toe game, including player vs. player (PvP) and player vs. computer (PvC) modes. It also keeps track of game results and utilizes other classes for managing moves and results.

MoveStack:
Description: This class represents a stack data structure to store the moves made in the Tic-Tac-Toe game.
Main Function: It provides methods to push a move onto the stack, pop a move from the stack, check if the stack is empty, and clear the stack.
Queue:
Description: This class represents a queue data structure to store the values/moves of each computer that will play in the game.
Main Function: It includes methods for enqueueing items, dequeuing items, checking if the queue is empty, and clearing the queue. It also has a function to fill the queue with random values (1-9) without duplicates.
ResultStack:
Description: This class represents a stack data structure to store and display the total instances of wins, losses, or ties across all game modes (except CvC).
Main Function: It provides methods for pushing results onto the stack, checking if the stack is empty, and popping results from the stack.
LLNode:
Description: This class represents a node for a linked list that stores the state of the game board for each move in the game.
Main Function: It initializes the node with default values and has members to store the board state, player's move, and other relevant information.
LL:
Description: This class represents a linked list that stores the state of the game board for each move in the game. It is used for a single session of the game.
Main Function: It provides a method to add a move to the linked list and a method to display all moves played in a session.
LL2DNode:
Description: This class represents a node for a 2D linked list that stores multiple sessions of the game.
Main Function: It initializes the node with default values and contains a pointer to an LL object.
LL2D:
Description: This class represents a 2D linked list that stores multiple sessions of the game.
Main Function: It provides a method to add a new LL (linked list) to the 2D linked list.
TicTacToeGame:
Description: This class is the main class that handles the Tic-Tac-Toe game. It includes functions for initializing winning conditions, resetting the game board, checking if the game is over, evaluating the game board, finding the best move for the computer player, and more.
Main Function: It orchestrates the entire Tic-Tac-Toe game, including player vs. player (PvP) and player vs. computer (PvC) modes. It also keeps track of game results and utilizes other classes for managing moves and results.

Note: Each class detail is separately committed


Add format for complex matrix

This change add CFormatted function for mat package. It is like Formatted function but for complex matrix.
Note: Haven't support for python format and matlab format

It seems to me that the best way to do this, given that we can't shoe horn complex matrices into the same infrastructure that we have for reals, would be to just copy the whole file and adjust it for complex values. This would leave only minor edits for the documentation and would ensure that the behaviour is consistent. It's not entirely clear to me why you stripped the documentation and other comments.

It seems to me that the best way to do this, given that we can't shoe horn complex matrices into the same infrastructure that we have for reals, would be to just copy the whole file and adjust it for complex values. This would leave only minor edits for the documentation and would ensure that the behaviour is consistent. It's not entirely clear to me why you stripped the documentation and other comments.

wait i didn't modify anything excpet adding cformat.go and cformat_test.go

Please just start from the complete copy and delete/modify as needed.

Although it is worth spending some time to see if we can get away with less code duplication. That will not be trivial.

I'm closing this PR because it has gone stale. We're still interested in contributions, so please create a new PR if you still intend to submit this change.


Node not reconnecting after internet outage

To recreate:
-after node has connected
-disable internet
-wait for 'error' status to show
-re-enable internet
-node will display 'error' status indefinitely and not attempt to reconnect

We are also facing this issue when using this node in combination with IOT Central.
It also looks like it is triggered by the selected enrollmet type.
For IOT central we have always used the saskey, but in this library if you select enrollmenttype = group then something is done with they key and DPS doesn't work.
If we select enrollmenttype = individual then works, but for some reason the node does not saves this configuration.
var saskey = (node.enrollmenttype === "group") ? computeDerivedSymmetricKey(node.saskey, node.deviceid) : node.saskey;

Should have been solved in #16
I think the problem is that the configuration window does not correctly saves the selected value in enrollment type


Fix Warning uninitialized memory '*aJoinerId' in otJoinerGetId()

In function otJoinerGetId() of otapi.cpp
otExtAddress structure pointed to by aJoinerId potentially is uninitialized
and produces a C6001 compiler warning.
adding
ZeroMemory(aJoinerId, sizeof(otExtAddress));
before calling
return DwordToThreadError(SetIOCTL(aInstance, IOCTL_OTLWF_OT_JOINER_ID, aJoinerId));
suppresses the warning and initializes the calling routines structure before attempting to use
the IOCTL_OTWLF_OT_JOINER_ID call to get the Joiner Id
In addition it may be good to check for (aJoinerId == nullptr) as well as the (aInstance == nullptr) check

Thanks for raising this issue.  Would you like to submit a PR to address this?


Skipped tests includes links

following up of #37429 this PR is fixing the issues that appeared in it. Particularly, the list should not show duplicated tests. The reason was that it regex'ed for skipped tests in the whole page without taking care of the arch. report will display skipped test per arch now, fetching the links to those tests as well.

Unfortunately the tox is still failing. However it is not relative to the changes.


Price not syncing?

I have setup my own heroku website & repo.
It seems that the price & calendar are not syncing and that I have to do that manually each time, is it expected?

Are you pinging the following links every 15 min or so?
http://yourHerokuDomain.com/checkRules
http://yourHerokuDomain.com/updatePricing

I'm going to close this due to no response.


Error relocating mini_racer_extension.so: backtrace_symbols: symbol not found on 2.5-alpine and 2.6-alpine

see e.g here
/home/runner/work/ruby-libv8-node/ruby-libv8-node/test/mini_racer/lib/mini_racer.rb:11:in `load': Error relocating /home/runner/work/ruby-libv8-node/ruby-libv8-node/test/mini_racer/lib/mini_racer_extension.so: backtrace_symbols: symbol not found (LoadError)
152
	from /home/runner/work/ruby-libv8-node/ruby-libv8-node/test/mini_racer/lib/mini_racer.rb:11:in `<top (required)>'

Turns out the musl build is OK, it's just old Rubygems having nil as a version instead of musl, therefore it fetches the incorrect one.

we aren't supporting 2.5 and 2.6 anymore. Is this issue still valid?


Minor HTML parsing update

BASE_URL/v2/login/registration returns null values for each of the
requested PAC digits.  This is due to a minor change to the page HTML.
This minor fix updates the scraper to account for this change.

This is a fix for #3

Thanks Joel! Appreciated!

No problem. Thanks for open sourcing your code!
Joel
On 18 May 2016 23:23, "Owen O Byrne"<EMAIL_ADDRESS>wrote:

Thanks Joel! Appreciated!
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/owenobyrne/aib-internet-banking-api/pull/2#issuecomment-220176145


Switch to codecov

Current coverage is 60.90%

Branch #82 has no coverage reports uploaded yet.

No diff could be generated. No reports for portable-3.0 found.

Powered by Codecov. Updated on successful CI builds.


How to convert Unicode characters

Hello Peter, I found you font-2-py tool. I use it with sh1106 driver.
Thank you very much for the great work. Unfortunately I’m not so familiar with TTF font format.
Under Windows a character map (in the font folder) is findable, that shows a lot of Unicode characters.
I.e. In Segoe UI Symbol font (seguisym.ttf) the U-26E3 ( ☾ half-moon) character.
Is it possible to convert the Unicode characters with your tool to a py-font ?
Can you help, and show how ?
Thank you very much
BR Kai

Perhaps I need to expand the docs as you're not the first to be puzzled by this.
See optional arguments. The one you want is -k. Create a file containing the entire character set you want to include. There are some examples in the charsets directory. Then you can use that charset file to create one or more fonts containing that character set. The doc has some usage examples for -k.

I recognized the -k  parameter. Thank you for the advise.
Unfortunately  I don't know the charsets  in the Segoe UI Symbol font (seguisym.ttf)
Do you know, where I will find the information ?
If the charsets  are known, how to catch the characters like U-26E3 ?
I work with Windows10 in the cmd window it is impossible to insert the unicode characters.
Is there a tip ?

I abandoned Windows 15 years ago so I'm afraid you'll need to seek help elsewhere. A quick websearch yielded this doc.
Nor do I know how to determine which glyphs a TTF font contains, other than trial and error.
The way to generate a charsets file is in a text editor. It's easiest to start with an existing file such as charsets/extended and simply add the glyphs you require (optionally removing any that are of no interest). Glyphs can be cut and pasted from another source, or there may be a set of keystrokes that produces the glyph.
This can be done using any font, but if you can set the editor to use the font you're targeting it will be apparent if a glyph you wish to create is not present in the font.

Thanks for the hint. I found an online font editor and could copy the needed glyphs to a new ttf fontfile. That file was convered perfect by your font-to-py tool.


math: use types defined in image repository

A set of reasonably-common types for image work have ended up in:
https://godoc.org/golang.org/x/image/math/f32
They seem to line up with the types in gxui/math. The only downside is you cannot put methods on types from an external package.
If this seems reasonable, I'll give it a go.

:+1: to the idea.
If possible, I'd like to see https://godoc.org/github.com/go-gl/mathgl/mgl32 used too. Are there valid reasons why it isn't?

@crawshaw is there any reason why the methods couldn't be absorbed into https://godoc.org/golang.org/x/image/math/f32? It's not going to break compatibility.

But then again, it's a bit weird to have that sort

argh, wrong button

But then again, it's a bit weird to have that sort of math in an image library.

Methods can be added to image/math if we can reach consensus on what they should be. We had a lot of trouble with it in early discussions. We could find common ground on types, so we started there.

If the methods cannot be brought across, I don't really see the gain in switching to the f32 package - does it not contain just 7 typedefs? Do you see common functionality between GXUI and f32?

Let's punt on this issue for a bit, I believe it will be useful but would like to demonstrate it with code.
It is also worth looking at https://godoc.org/github.com/go-gl/mathgl/mgl32 as@shurcooL mentioned, it has a lot of relevant machinery in it.

Yup mgl32 looks like a pretty good replacement. It doesn't have my fantastic unicode art though. :)

Yup mgl32 looks like a pretty good replacement. It doesn't have my fantastic unicode art though. :)

Please feel free to make a PR, improvements to it are always welcome.


new tests for surface module; bug fix for PointSet title arg

Codecov Report

Merging #157 (054f314) into master (53df6ff) will increase coverage by 1.48%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #157      +/-   ##
==========================================
+ Coverage   41.01%   42.49%   +1.48%
==========================================
  Files          50       50
  Lines       23429    23429
==========================================
+ Hits         9610     9957     +347
+ Misses      13819    13472     -347

Impacted Files
Coverage Δ

resqpy/surface.py
55.06% <ø> (+10.51%)
:arrow_up:

resqpy/olio/vector_utilities.py
41.35% <0.00%> (+4.21%)
:arrow_up:

resqpy/lines.py
28.38% <0.00%> (+10.70%)
:arrow_up:

resqpy/olio/triangulation.py
89.13% <0.00%> (+85.50%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 53df6ff...054f314. Read the comment docs.


Possibility of caching as dictionary or list

Summary of the issue
Hi, I've started using this library and I like it.
I have a question though.
If I'm not mistaken, it seems that only the result of the query is put in cache, which means that the real result of the linq query chain, often ending with ToDictionary(), ToList() is not put in cache.
And the creation of this structure can be expensive.
Would it be possible to include in the library something like AsCacheableDictionary(Async), AsCacheableList(Async), maybe also by prefixing the cachekey with the resulting type ?
Or do you think it's completely irrelevant and in that case, do you have an idea on how to achieve this ?
Thanks in advance,
Kindanam
Environment
.NET Core SDK version: 3.1
Microsoft.EntityFrameworkCore version: 3.1
EFCoreSecondLevelCacheInterceptor version: 1.7.1

Example code/Steps to reproduce:
var myDictionary = await myQuery.Cacheable(CacheExpirationMode.Absolute, TimeSpan.FromHours(1)).ToDictionaryAsync(myEntity => myEntity.Key);

// The hash code is different each time. it seems that the dictionary is always recreated and not itself put in cache
var hash = myDictionary.GetHashCode();

Output:
Exception message:
Full Stack trace:

This library works on the DataReader level of EF. It has not access to anything else.
Also it's performance is good:

This actually seems like a really interesting idea and could potentially provide even better performance improvements.   I think @kindamam was trying to discuss how we store the final result set in the cache, not the key.    If we know that a certain result will always be used as a List or Dictionary, etc.   Storing the result in that set would save a ton of time by preventing us from re-composing the native result set into the data-structure.
Maybe something like .AsCachableList() would be a great first start?  Not sure of the complexity for doing this, but it is a great idea.

This actually seems like a really interesting idea and could potentially provide even better performance improvements. I think @kindamam was trying to discuss how we store the final result set in the cache, not the key. If we know that a certain result will always be used as a List or Dictionary, etc. Storing the result in that set would save a ton of time by preventing us from re-composing the native result set into the data-structure.
Maybe something like .AsCachableList() would be a great first start? Not sure of the complexity for doing this, but it is a great idea.

Thanks @jasenf . It's exactly what I was thinking about.
I know from experience that the recreation of dictionaries in some contexts, can easily have a significant cost.
In the context I was talking about, we had 100 req per sec, and we were creating dictionaries with 3500 keys.
Does not seem very big, but we saw those dictionaries clearly in our memory dumps in Production (because obviously these dictionaries were only a small part of each request, and should have been taken from cache as a reference to the same dictionary instance, and not cloning it for no reason at every request)
I'm really interested in this feature, so I hope you'll be interested too, and will find a way to implement it.
Thanks, Kindanam


fix: no existing tags creates a 0.0.0 format tag

I've created a test which showcases the issue. This is the results from the test:
 1) plugin
       should increment version without existing tags:

      AssertionError: expected '<IP_ADDRESS>' to equal '24.2.1'
      + expected - actual

      -<IP_ADDRESS>
      +24.2.1

I'll make an attempt at fixing it.

After having a look at node-calver, it seems this issue can be bypassed by simply specifying calendar as increment.
Closing this PR for now.


📚 - Documentation redesign

What is the affected URL?
https://taiga-ui.dev
Description
https://www.figma.com/file/e7haZlhOm9DjupCkq5UIMe/Taiga-3.0?node-id=31602%3A136510&t=6zYP6BtXIzsghQbH-11
Which browsers have you used?

[X] Chrome
[ ] Firefox
[ ] Safari
[ ] Edge

Which operating systems have you used?

[X] macOS
[ ] Windows
[ ] Linux
[ ] iOS
[ ] Android

Add page with all components

Add left menu similar to notion


added the usage of std::find

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

@scissorsneedfoodtoo This PR has gone stale.

@RandellDawson, I agree. Best to close this.


Consider deriving Debug only in test config

Since the DPE implementation doesn't really have anything useful to do with a Debug string, we could probably bulk-update the derive attributes and move Debug into #[cfg_attr(test

Do you have proof that these unused strings are being included in the binary? From my experience the compiler won't include them if they aren't used. And we should be adding tests for size/bloat regressions regardless of what we do here....

I don't have proof. I created this bug to lift out this comment from a recent PR: https://github.com/chipsalliance/caliptra-dpe/pull/58#discussion_r1157835823

Agreed if you don't use them then they don't be included in the binary. Just don't want to make the traits available and encourage people to write firmware that uses them.
Agreed tests for fw bloat are necessary either way. This has more to do with setting expectations on what is supported to contributors.

Going to close this. I don't think this is a problem, compiler is smart enough to not include these strings.


Redis LOADING error should cause different node to be queried during pipeline reads in redis-cluster

When processing pipeline read commands in redis-cluster if LOADING error is encountered we retry to the same node because failedCmds is not updated in pipelineReadCmds() (see https://github.com/go-redis/redis/blob/master/cluster.go#L1332). This means that if there's an extended period of time in which a node responds with LOADING error, which can happen eg after a failover recovery event in which an entire read replica needs to be replicated from the master, no pipeline reads can succeed. We unfortunately experienced this very scenario in production recently.
Is it by design that upon LOADING error is encountered during pipeline reads go-redis doesn't attempt to look for a different node to query, and if so what is/are the rationale? One factor we considered was consistency, but in redis cluster there's already no data consistency guarantee across shards anyways. Or is this an oversight that should be fixed?
As a reference for non-pipeline reads defaultProcess() already handles LOADING error properly (see https://github.com/go-redis/redis/blob/master/cluster.go#L946).

@koenoki PTAL https://github.com/go-redis/redis/pull/1034


pip error on Macbook pro (m1 pro)

Hi! I am working on Macbook pro with basemap, but I met some issues. When I try to pip install basemap, there is something wrong with this. But I have already brew install geos, what's wrong? Thanks!

Hi @CaffreyR! Did you set the GEOS_DIR environment variable? Since your traceback says that the file "geos_c.h" is not found, I would assume that the _geoslib module cannot be compiled because of not finding the GEOS headers in your system.

I'm getting the same problem, and I'm setting GEOS_DIR.
Brew installs geos=3.10.2, this comment in basemap suggests installing an older version https://github.com/matplotlib/basemap/issues/533

Hi @ronaldbradford, thanks for the feedback. Could you confirm me if you can find a "geos_c.h" file in your system and the value that you are assigning to GEOS_DIR?

I was using GEOS_DIR=/usr/local/Cellar/geos/3.10.2
I've uninstalled and building form source right now to see if I can confirm it fixes my issuel

I have installed geos 3.8.2 from source https://libgeos.org/usage/download/
$ ls -l $GEOS_DIR/include/geos_c.h
-rw-r--r--  1 rbradfor  staff  97001 Apr  7 17:26 /usr/local/include/geos_c.h
$ echo $GEOS_DIR
/usr/local

$ pip3 install basemap
DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
Collecting basemap
  Using cached basemap-1.3.2.zip (155 kB)
  ...
  Building wheels for collected packages: basemap
  Building wheel for basemap (pyproject.toml) ... error
  ERROR: Command errored out with exit status 1:
   command<EMAIL_ADDRESS>/usr/local/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py build_wheel /var/folders/hp/l11pqpjn721d4cjpw1qjzl_c0000gn/T/tmpjrhbdnvf
       cwd: /private/var/folders/hp/l11pqpjn721d4cjpw1qjzl_c0000gn/T/pip-install-0vpt9rzd/basemap_ce944475e96546c5846addd29810dfff
  Complete output (32 lines):
  setup.py:52: RuntimeWarning: Cannot find GEOS library and/or headers in standard locations ('/usr/local'). Please install the corresponding packages using your software management system or set the environment variable GEOS_DIR to point to the location where GEOS is installed (for example, if 'geos_c.h' is in '/usr/local/include' and 'libgeos_c' is in '/usr/local/lib', then you need to set GEOS_DIR to '/usr/local'
    warnings.warn(" ".join([
  running bdist_wheel
  running build
  running build_py
  ...

FWIW 'm also getting the same error with
$ pip3 install basemap==1.3.1
$ pip3 install basemap==1.3.0

From your traceback I would infer that there is no problem with finding the header file but with finding the library itself.
The problematic line could be this one in the setup file: https://github.com/matplotlib/basemap/blob/f9c9dabd2e8e41b7573c5a8b1beaf7182ea87173/packages/basemap/setup.py#L45
The setup file tries to find the library assuming that the library filename follows the pattern "libgeos_c*.so*" and is placed inside $GEOS_DIR/lib, $GEOS_DIR/lib/x86_64-linux-gnu or $GEOS_DIR/lib64. Is this correct for MacOS? If not, then the setup file would need an update.

I have installed geos 3.9.2 now from source https://libgeos.org/usage/download/
I Installed basemap from source via https://github.com/matplotlib/basemap instructions
Debugging setup.py is beyond my knowledge level. I know it's late there, please let me know what I can try.
$  ls -l $GEOS_DIR/include/geos_c.h
-rw-r--r--  1 rbradfor  staff  79397 Apr  7 17:53 /usr/local/include/geos_c.h
$ python -m pip install .
DEPRECATION: Configuring installation scheme with distutils config files is deprecated and will no longer work in the near future. If you are using a Homebrew or Linuxbrew Python, please see discussion at https://github.com/Homebrew/homebrew-core/issues/76621
Processing /Users/rbradfor/tmp/basemap/packages/basemap
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Requirement already satisfied: numpy<1.23,>=1.21 in /usr/local/lib/python3.9/site-packages (from basemap==1.3.2+dev) (1.22.2)
Requirement already satisfied: basemap-data<1.4,>=1.3.2 in /usr/local/lib/python3.9/site-packages (from basemap==1.3.2+dev) (1.3.2)
Requirement already satisfied: matplotlib<3.6,>=1.5 in /usr/local/lib/python3.9/site-packages (from basemap==1.3.2+dev) (3.5.1)
Collecting pyshp<2.2,>=1.2
  Using cached pyshp-2.1.3-py3-none-any.whl
Requirement already satisfied: pyproj<3.4.0,>=1.9.3 in /usr/local/lib/python3.9/site-packages (from basemap==1.3.2+dev) (3.3.0)
Requirement already satisfied: pillow>=6.2.0 in /usr/local/lib/python3.9/site-packages (from matplotlib<3.6,>=1.5->basemap==1.3.2+dev) (9.0.1)
Requirement already satisfied: kiwisolver>=1.0.1 in /usr/local/lib/python3.9/site-packages (from matplotlib<3.6,>=1.5->basemap==1.3.2+dev) (1.3.2)
Requirement already satisfied: pyparsing>=2.2.1 in /usr/local/lib/python3.9/site-packages (from matplotlib<3.6,>=1.5->basemap==1.3.2+dev) (3.0.7)
Requirement already satisfied: packaging>=20.0 in /usr/local/lib/python3.9/site-packages (from matplotlib<3.6,>=1.5->basemap==1.3.2+dev) (21.3)
Requirement already satisfied: fonttools>=4.22.0 in /usr/local/lib/python3.9/site-packages (from matplotlib<3.6,>=1.5->basemap==1.3.2+dev) (4.29.1)
Requirement already satisfied: cycler>=0.10 in /usr/local/lib/python3.9/site-packages (from matplotlib<3.6,>=1.5->basemap==1.3.2+dev) (0.11.0)
Requirement already satisfied: python-dateutil>=2.7 in /usr/local/lib/python3.9/site-packages (from matplotlib<3.6,>=1.5->basemap==1.3.2+dev) (2.8.2)
Requirement already satisfied: certifi in /usr/local/lib/python3.9/site-packages (from pyproj<3.4.0,>=1.9.3->basemap==1.3.2+dev) (2021.10.8)
Requirement already satisfied: six>=1.5 in /usr/local/lib/python3.9/site-packages (from python-dateutil>=2.7->matplotlib<3.6,>=1.5->basemap==1.3.2+dev) (1.16.0)
Building wheels for collected packages: basemap
  Building wheel for basemap (pyproject.toml) ... error
  ERROR: Command errored out with exit status 1:
   command<EMAIL_ADDRESS>/usr/local/lib/python3.9/site-packages/pip/_vendor/pep517/in_process/_in_process.py build_wheel /var/folders/hp/l11pqpjn721d4cjpw1qjzl_c0000gn/T/tmp8iq42jtw
       cwd: /Users/rbradfor/tmp/basemap/packages/basemap
  Complete output (19 lines):
  setup.py:52: RuntimeWarning: Cannot find GEOS library and/or headers in standard locations ('/usr/local'). Please install the corresponding packages using your software management system or set the environment variable GEOS_DIR to point to the location where GEOS is installed (for example, if 'geos_c.h' is in '/usr/local/include' and 'libgeos_c' is in '/usr/local/lib', then you need to set GEOS_DIR to '/usr/local'
    warnings.warn(" ".join([
  running bdist_wheel
  running build
  running build_py
  running build_ext
  clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk<EMAIL_ADDRESS><EMAIL_ADDRESS>-c src/_geoslib.c -o build/temp.macosx-10.15-x86_64-3.9/src/_geoslib.o
  In file included from src/_geoslib.c:685:
  In file included from /usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/numpy/core/include/numpy/arrayobject.h:5:
  In file included from /usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/numpy/core/include/numpy/ndarrayobject.h:12:
  In file included from /usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/numpy/core/include/numpy/ndarraytypes.h:1960:
  /usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:17:2: warning: "Using deprecated NumPy API, disable it with "          "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-W#warnings]
  #warning "Using deprecated NumPy API, disable it with " \
   ^
  src/_geoslib.c:686:10: fatal error: 'geos_c.h' file not found
  #include "geos_c.h"
           ^~~~~~~~~~
  1 warning and 1 error generated.
  error: command '/usr/bin/clang' failed with exit code 1
  ----------------------------------------
  ERROR: Failed building wheel for basemap
Failed to build basemap
ERROR: Could not build wheels for basemap, which is required to install pyproject.toml-based projects
WARNING: You are using pip version 21.3.1; however, version 22.0.4 is available.
You should consider upgrading via the<EMAIL_ADDRESS>-m pip install --upgrade pip' command.

$ ls -l $GEOS_DIR/lib/libgeos_c*
-rwxr-xr-x  1 rbradfor  staff   226536 Apr  7 17:35 /usr/local/lib/libgeos_c.1.13.4.dylib
-rwxr-xr-x  1 rbradfor  staff   233112 Apr  7 17:49 /usr/local/lib/libgeos_c.1.14.3.dylib
-rwxr-xr-x  1 rbradfor  staff  1407648 Apr  7 17:58 /usr/local/lib/libgeos_c.1.9.1.dylib
lrwxr-xr-x  1 rbradfor  staff       21 Apr  7 17:58 /usr/local/lib/libgeos_c.1.dylib -> libgeos_c.1.9.1.dylib
lrwxr-xr-x  1 rbradfor  staff       17 Apr  7 17:35 /usr/local/lib/libgeos_c.dylib -> libgeos_c.1.dylib
$ uname -a
Darwin atlantis.lan 19.6.0 Darwin Kernel Version 19.6.0: Sun Nov 14 19:58:51 PST 2021; root:xnu-6153.141.50~1/RELEASE_X86_64 x86_64

Let me interactively look at ~L45 and see.

>>> import os
>>> os.name
'posix'
>>> libfiles = []
>>> libdirs = ["bin", "lib", "lib/x86_64-linux-gnu", "lib64"]
>>> libext = "dll" if os.name == "nt" else "so"
>>> libcode = "{0}geos_c".format("" if os.name == "nt" else "lib")
>>> libname = "{0}*.{1}*".format(libcode, libext)
>>> for libdir in libdirs:
...   libfiles.extend(glob.glob(os.path.join(prefix, libdir, libname)))
>>> print(libfiles)
[]
>>> print("{},{},{}".format(libext,libcode,libname))
so,libgeos_c,libgeos_c*.so*

So yes, there is no *.so file on MacOS

https://github.com/matplotlib/basemap/commit/41214409b49461cee8b65dd25fb33ed8ebd9963b

This traceback shows much more information. Something is going wrong when setting the compilation flags internally, because the clang call is missing a -I$GEOS_DIR/include (with $GEOS_DIR expanded to your value). This is supposed to be done by the setup.py but it is clear that it is not doing its job in MacOS.
Can you check if setting the environment variable CFLAGS=-I$GEOS_DIR/include before lets you go further with the installation?

https://github.com/matplotlib/basemap/commit/41214409b49461cee8b65dd25fb33ed8ebd9963b

You got it. This commit done by me is causing at least one of the problems. Before, only the presence of the header file was checked. I wanted to ensure that the library was actually there too, but only considered the extensions for Windows (.dll) and for manylinux (.so).
I will need to update this. But still I am confused, because in your other traceback the first check seems to pass but later the compilation of _geoslib fails due to the missing clang header argument.
What is clear is that I should create a GitHub Action to build MacOS wheels, because with them this error would have appeared fast.
It is a bit late for me now but I will try to take a look to this either tomorrow afternoon or this weekend.

Hi @CaffreyR! Did you set the GEOS_DIR environment variable? Since your traceback says that the file "geos_c.h" is not found, I would assume that the _geoslib module cannot be compiled because of not finding the GEOS headers in your system.

I'm getting the same problem, and I'm setting GEOS_DIR. Brew installs geos=3.10.2, this comment in basemap suggests installing an older version #533
Yep, I have set the dir in .bash_profile too. As you can see above. @molinav

And does an older version work? @ronaldbradford

@CaffreyR You need to define GEOS_DIR as an independent environment variable instead of adding the GEOS directory to PATH, like so:
export GEOS_DIR="/opt/homebrew/Cellar/geos/3.10.2"

Still, this won't be enough because the setup file needs a correction as shown by @ronaldbradford above. Here the GEOS version does not play a role: the recommendation about the version limit for GEOS is due to a problem only when drawing the Antarctic coast.

@ronaldbradford I have just pushed some commits to the bugfix-539 branch. There, I reimplement how the GEOS library is searched so that it also considers .dylib extensions on MacOS. Could you give a try and install from this branch to see if your problem is solved on your system?

@CaffreyR May I ask you to try my attempt of fixing your problem? You need to do:
export GEOS_DIR="/opt/homebrew/Cellar/geos/3.10.2"
git clone --depth 1 https://github.com/matplotlib/basemap.git
cd basemap/packages/basemap
git checkout bugfix-539
python -m pip install .

@CaffreyR May I ask you to try my attempt of fixing your problem? You need to do:
export GEOS_DIR="/opt/homebrew/Cellar/geos/3.10.2"
git clone https://github.com/matplotlib/basemap.git
cd basemap/packages/basemap
git checkout bugfix-539
python -m pip install .

OK！But there's something wrong with the git , maybe for network in my region, let me try it again later. @molinav

@CaffreyR Be sure not to use --depth 1 when cloning, because then the history is not downloaded and you cannot change to the bugfix branch. I wrote it wrong and edited my message, but if you copied the snippet from an email notification it will be still there.

@CaffreyR Be sure not to use --depth 1 when cloning, because then the history is not downloaded and you cannot change to the bugfix branch. I wrote it wrong and edited my message, but if you copied the snippet from an email notification it will still be there.

see there is continuously disconnection, whether I use my VPN. Is there any chance that git broken? @molinav

@CaffreyR It looks more like a network issue then. Maybe you can try a bit later in case the connection gets better.

@molinav  +1
...
Installing collected packages: pyshp, basemap

$ pip list | grep basemap
basemap                                  1.3.2+dev
basemap-data                             1.3.2
basemap-data-hires                       1.3.2

@ronaldbradford Thanks! Great to see that it works. I will prepare a patch release 1.3.3 soon so that the source distributions from PyPI also work for MacOS.

@molinav Finnally!!!! I downloaded the git! It really worked! Thanks so much!

@CaffreyR Nice to hear! Thanks!

I'll leave an update on how to solve this since even bug #539 of basemap has been fixed but I still had this issue even after.
You want to make sure you first run
brew install geos
Then, @molinav 's lines might need some modifications. Check where geos is being stored, it might not be "/opt/homebrew/Cellar/geos/3.10.2". This will be printed when you install geos using brew. For me, it was rather
export GEOS_DIR = "/usr/local"
Then,
cd basemap/packages/basemap
And again, this will be different since the bugfix-539 branch has already been merged and deleted;
git checkout develop
And finally
python -m pip install .
Summary:
brew install geos
export GEOS_DIR = "/usr/local"
cd basemap/packages/basemap
git checkout develop
python -m pip install .

@isimo00 Thanks for the feedback. I recently created a hotfix version 1.3.3 with the corrections for Mac and pushed it to PyPI:
https://pypi.org/project/basemap/1.3.3/
Although there are no precompiled wheels for Mac, now you can install basemap from the PyPI source distribution, so in principle it would be enough with doing the following (assuming that you have a C compiler):
brew install geos
export GEOS_DIR="/usr/local"
python -m pip install basemap

The good thing of this approach is that you do not need to deal with the specific commands related to using a repository clone.

@molinav Oh great! Thanks for the answer and work, hopefully this will make it easier for future users.

Thanks a lot! Came here precisely to find this <3
Any chance to get a wheel at some point to conda-forge, please?

@jucor Actually there was some work recently in the corresponding feedstock, and we managed to make the pipelines pass again with the new basemap 1.3.x series. I am waiting for some feedback from the other people involved in the PR just to be sure that everything also looks ok for them... And then we will have basemap back in conda-forge. ;-)

Hi @ihaseeburrehman. I am not an expert on macOS and I have no macOS machine to test, but this seems to be some issue related to the build toolchain rather than basemap itself, see for example this issue:
https://github.com/llvm/llvm-project/issues/55836
Since you were able to install basemap successfully in your homebrewed Python based on  https://github.com/matplotlib/basemap/issues/547#issuecomment-1352890489, looking at your environment variables could help you find a solution (to ensure that Anaconda and your SDK do not conflict).

Having the import error "symbol not found in flat namespace '_GEOSArea'" when trying to run from mpl_toolkits.basemap import basemap.

@CaffreyR May I ask you to try my attempt of fixing your problem? You need to do:
export GEOS_DIR="/opt/homebrew/Cellar/geos/3.10.2"
git clone https://github.com/matplotlib/basemap.git
cd basemap/packages/basemap
git checkout bugfix-539
python -m pip install .

Hello here :)
While running git checkout bugfix-539 I have the following error:
error: pathspec 'bugfix-539' did not match any file(s) known to git

Hi @xpivan! The bugfix-539 branch was a temporary branch to solve this issue, but it was removed as soon as it was merged back to the main branches. You can try to install from any stable tag, e.g. for version 1.3.8 it would be as below:
python -m pip install https://github.com/matplotlib/basemap/archive/v1.3.8.tar.gz#subdirectory=packages/basemap

Please note that until I release basemap version 1.3.9, you should ensure that you have numpy < 1.24, otherwise you might be hit by the bug reported recently in #589.

Hi @molinav
Thanks for your answer
Using the command below returns the same problem:

@xpivan Do you have GEOS on your system? When building basemap from source, you need GEOS available on your system (e.g. installed with homebrew). Once GEOS is installed, you need to define the environment variable GEOS_DIR with the location where GEOS was installed.
From the traceback, "/opt/homebrew/Cellar/geos/3.10.2" does not look like a valid GEOS installation root, so my first guess would be that you do not have the GEOS library in this location.

@molinav GEOS was properly installed but I realized reading your message that my export was pointing to the wrong version. I changed the export from
export GEOS_DIR="/opt/homebrew/Cellar/geos/3.10.2"
to
export GEOS_DIR="/opt/homebrew/Cellar/geos/3.12.0"
I works like a charm.
Thank you for taking time and helping solving for my issue. I really appreciated it.
Cheers

Hello, I have been trying to run code originally written for Python 2, but I have encountered some issues when attempting to run it
Traceback (most recent call last):
File "PyVelest.py", line 27, in
from mpl_toolkits.basemap import Basemap
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mpl_toolkits/basemap/init.py", line 53, in
import _geoslib
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_geoslib.so, 0x0002): symbol not found in flat namespace '_GEOSArea'
I have done everything that others have suggested in this issue, but I don't have any idea what's going on. I use a Mac M2, and I don't know if there is any problem with Macs.

When I try to install basemap via pip3 on my Mac, I wish that instead of, or in addition to, failing to find the header file when I don't have geos installed, it would tell me to install geos.

Hi @ofloveandhate! The issue here is that with a pip installation you cannot recommend installing GEOS with pip, the GEOS installation is somehow a "manual" step to do before the pip install basemap call. We can still, of course, reformulate the error message to make it a bit more descriptive (e.g. common ways to install GEOS, either from homebrew, from conda, from GNU/Linux package manager, etc.).
Which is your current environment on MacOS (system version, Python version)? I am currently experimenting to create MacOS wheels with a local Mac mini (making GEOS be already bundled in the wheel), so it would be great if somebody can try them succesfully too before they become public. They seem to work in my computer, but I am not so experienced with Mac devices.

@molinav I'm on Python 3.11 provided by homebrew, on a 2020 Mac Mini with an M1 chip running MacOS 13.6 (I cannot change the MacOS version, it's managed by my university).
I guess I was mostly asking not for pip to provide geos, but to tell me that there's an expectation that I would have geos installed separately as a pre-requisite step.  (Especially since I teach, and I was helping a student install things for a project, having never installed basemap before I didn't understand that they/I needed to install geos separately).
Additional context for why I think an improved warning / message would help: I had been previously conditioned to suspect a missing header problem as a package bug, due to a few similar bugs I encountered in other Python packages.

@ofloveandhate May I ask if you found some time to try the wheel?

@molinav It was successful out of the box!

These are the homebrew packages I had installed:  (I removed geos before testing your wheel)
brew list
==> Formulae
aom			freetype		ipython			libtiff			node			python-setuptools
autoconf		fribidi			isl			libtool			numpy<EMAIL_ADDRESS><EMAIL_ADDRESS>gcc			jasper			libuv			openblas<EMAIL_ADDRESS>automake		gd			jbig2dec		libvmaf			openexr<EMAIL_ADDRESS>bison			gdbm			jpeg-turbo		libx11			openjdk			pyyaml
black			gdk-pixbuf		jpeg-xl			libxau			openjpeg		readline
boost			gettext			jupyterlab		libxcb<EMAIL_ADDRESS>ruff
boost-python3		ghostscript		libavif			libxdmcp		openssl@3		shared-mime-info
brotli			giflib			libde265		libxext			pandoc			six
c-ares			glib			libevent		libxrender		pango			sqlite
ca-certificates		gmp			libheif			libyaml			pcre2			webp
cairo			graphite2		libidn			little-cms2		pixman			x265
cffi			graphviz		liblqr			lz4			plantuml		xorgproto
cmake			gts			libmpc			lzo			pycparser		xz
coreutils		harfbuzz		libnghttp2		m4			pydocstyle		zeromq
cython			highway			libomp			mpdecimal		pygments		zstd
eigen			hwloc			libpng			mpfr			python-certifi
eigenpy			icu4c			libraw			mpich			python-lsp-server
flex			imagemagick		librsvg			mypy			python-packaging
fontconfig		imath			libsodium		netpbm			python-psutil

and here's the output from pip as I installed:
python3 -m pip install basemap-1.4.0.dev0-cp311-cp311-macosx_11_0_arm64.whl
Processing ./basemap-1.4.0.dev0-cp311-cp311-macosx_11_0_arm64.whl
Requirement already satisfied: basemap-data<1.4,>=1.3.2 in /opt/homebrew/lib/python3.11/site-packages (from basemap==1.4.0.dev0) (1.3.2)
Requirement already satisfied: pyshp<2.4,>=1.2 in /opt/homebrew/lib/python3.11/site-packages (from basemap==1.4.0.dev0) (2.3.1)
Requirement already satisfied: matplotlib<3.8,>=1.5 in /opt/homebrew/lib/python3.11/site-packages (from basemap==1.4.0.dev0) (3.7.3)
Requirement already satisfied: pyproj<3.7.0,>=1.9.3 in /opt/homebrew/lib/python3.11/site-packages (from basemap==1.4.0.dev0) (3.5.0)
Requirement already satisfied: packaging<24.0,>=16.0 in /opt/homebrew/lib/python3.11/site-packages (from basemap==1.4.0.dev0) (23.0)
Requirement already satisfied: numpy<1.26,>=1.21 in /opt/homebrew/lib/python3.11/site-packages (from basemap==1.4.0.dev0) (1.24.2)
Requirement already satisfied: contourpy>=1.0.1 in /opt/homebrew/lib/python3.11/site-packages (from matplotlib<3.8,>=1.5->basemap==1.4.0.dev0) (1.0.7)
Requirement already satisfied: cycler>=0.10 in /opt/homebrew/lib/python3.11/site-packages (from matplotlib<3.8,>=1.5->basemap==1.4.0.dev0) (0.11.0)
Requirement already satisfied: fonttools>=4.22.0 in /opt/homebrew/lib/python3.11/site-packages (from matplotlib<3.8,>=1.5->basemap==1.4.0.dev0) (4.38.0)
Requirement already satisfied: kiwisolver>=1.0.1 in /opt/homebrew/lib/python3.11/site-packages (from matplotlib<3.8,>=1.5->basemap==1.4.0.dev0) (1.4.4)
Requirement already satisfied: pillow>=6.2.0 in /opt/homebrew/lib/python3.11/site-packages (from matplotlib<3.8,>=1.5->basemap==1.4.0.dev0) (9.4.0)
Requirement already satisfied: pyparsing>=2.3.1 in /opt/homebrew/lib/python3.11/site-packages (from matplotlib<3.8,>=1.5->basemap==1.4.0.dev0) (3.0.9)
Requirement already satisfied: python-dateutil>=2.7 in /opt/homebrew/lib/python3.11/site-packages (from matplotlib<3.8,>=1.5->basemap==1.4.0.dev0) (2.8.2)
Requirement already satisfied: certifi in /opt/homebrew/lib/python3.11/site-packages (from pyproj<3.7.0,>=1.9.3->basemap==1.4.0.dev0) (2022.12.7)
Requirement already satisfied: six>=1.5 in /opt/homebrew/lib/python3.11/site-packages (from python-dateutil>=2.7->matplotlib<3.8,>=1.5->basemap==1.4.0.dev0) (1.16.0)
Installing collected packages: basemap
Successfully installed basemap-1.4.0.dev0

(thanks for both your patience, and your follow-through!)

So finally we have the first basemap packages in conda-forge for MacOS ARM64 (since version 1.3.9). I was planning to postpone this to basemap 1.4.0, but this way I can use basemap 1.3.9 as test release to ensure that the conda-forge recipe is working as expected for the next minor release.
A simple example would be as follows:
(base) vic@alpha:~$ conda create -y -c conda-forge -n test39 python=3.9 basemap
Collecting package metadata (current_repodata.json): done
Solving environment: done

==> WARNING: A newer version of conda exists. <==
  current version: 23.3.1
  latest version: 23.11.0

Please update conda by running

    $ conda update -n base -c conda-forge conda

Or to minimize the number of packages updated during conda update use

     conda install conda=23.11.0

## Package Plan ##

  environment location: /opt/homebrew/Caskroom/miniforge/base/envs/test39

  added / updated specs:
    - basemap
    - python=3.9

The following NEW packages will be INSTALLED:

  basemap            conda-forge/osx-arm64::basemap-1.3.9-py39hb118012_0
  basemap-data       conda-forge/noarch::basemap-data-1.3.2-pyhd8ed1ab_3
  brotli             conda-forge/osx-arm64::brotli-1.1.0-hb547adb_1
  brotli-bin         conda-forge/osx-arm64::brotli-bin-1.1.0-hb547adb_1
  bzip2              conda-forge/osx-arm64::bzip2-1.0.8-h93a5062_5
  c-ares             conda-forge/osx-arm64::c-ares-1.24.0-h93a5062_0
  ca-certificates    conda-forge/osx-arm64::ca-certificates-2023.11.17-hf0a4a13_0
  certifi            conda-forge/noarch::certifi-2023.11.17-pyhd8ed1ab_0
  contourpy          conda-forge/osx-arm64::contourpy-1.2.0-py39he9de807_0
  cycler             conda-forge/noarch::cycler-0.12.1-pyhd8ed1ab_0
  fonttools          conda-forge/osx-arm64::fonttools-4.47.0-py39h17cfd9d_0
  freetype           conda-forge/osx-arm64::freetype-2.12.1-hadb7bae_2
  geos               conda-forge/osx-arm64::geos-3.12.1-h965bd2d_0
  importlib-resourc~ conda-forge/noarch::importlib-resources-6.1.1-pyhd8ed1ab_0
  importlib_resourc~ conda-forge/noarch::importlib_resources-6.1.1-pyhd8ed1ab_0
  kiwisolver         conda-forge/osx-arm64::kiwisolver-1.4.5-py39hbd775c9_1
  krb5               conda-forge/osx-arm64::krb5-1.21.2-h92f50d5_0
  lcms2              conda-forge/osx-arm64::lcms2-2.16-ha0e7c42_0
  lerc               conda-forge/osx-arm64::lerc-4.0.0-h9a09cb3_0
  libblas            conda-forge/osx-arm64::libblas-3.9.0-20_osxarm64_openblas
  libbrotlicommon    conda-forge/osx-arm64::libbrotlicommon-1.1.0-hb547adb_1
  libbrotlidec       conda-forge/osx-arm64::libbrotlidec-1.1.0-hb547adb_1
  libbrotlienc       conda-forge/osx-arm64::libbrotlienc-1.1.0-hb547adb_1
  libcblas           conda-forge/osx-arm64::libcblas-3.9.0-20_osxarm64_openblas
  libcurl            conda-forge/osx-arm64::libcurl-8.5.0-h2d989ff_0
  libcxx             conda-forge/osx-arm64::libcxx-16.0.6-h4653b0c_0
  libdeflate         conda-forge/osx-arm64::libdeflate-1.19-hb547adb_0
  libedit            conda-forge/osx-arm64::libedit-3.1.20191231-hc8eb9b7_2
  libev              conda-forge/osx-arm64::libev-4.33-h93a5062_2
  libffi             conda-forge/osx-arm64::libffi-3.4.2-h3422bc3_5
  libgfortran        conda-forge/osx-arm64::libgfortran-5.0.0-13_2_0_hd922786_1
  libgfortran5       conda-forge/osx-arm64::libgfortran5-13.2.0-hf226fd6_1
  libjpeg-turbo      conda-forge/osx-arm64::libjpeg-turbo-3.0.0-hb547adb_1
  liblapack          conda-forge/osx-arm64::liblapack-3.9.0-20_osxarm64_openblas
  libnghttp2         conda-forge/osx-arm64::libnghttp2-1.58.0-ha4dd798_1
  libopenblas        conda-forge/osx-arm64::libopenblas-0.3.25-openmp_h6c19121_0
  libpng             conda-forge/osx-arm64::libpng-1.6.39-h76d750c_0
  libsqlite          conda-forge/osx-arm64::libsqlite-3.44.2-h091b4b1_0
  libssh2            conda-forge/osx-arm64::libssh2-1.11.0-h7a5bd25_0
  libtiff            conda-forge/osx-arm64::libtiff-4.6.0-ha8a6c65_2
  libwebp-base       conda-forge/osx-arm64::libwebp-base-1.3.2-hb547adb_0
  libxcb             conda-forge/osx-arm64::libxcb-1.15-hf346824_0
  libzlib            conda-forge/osx-arm64::libzlib-1.2.13-h53f4e23_5
  llvm-openmp        conda-forge/osx-arm64::llvm-openmp-17.0.6-hcd81f8e_0
  matplotlib-base    conda-forge/osx-arm64::matplotlib-base-3.7.3-py39h6685e7c_0
  munkres            conda-forge/noarch::munkres-1.1.4-pyh9f0ad1d_0
  ncurses            conda-forge/osx-arm64::ncurses-6.4-h463b476_2
  numpy              conda-forge/osx-arm64::numpy-1.26.2-py39heee92a0_0
  openjpeg           conda-forge/osx-arm64::openjpeg-2.5.0-h4c1507b_3
  openssl            conda-forge/osx-arm64::openssl-3.2.0-h0d3ecfb_1
  packaging          conda-forge/noarch::packaging-23.2-pyhd8ed1ab_0
  pillow             conda-forge/osx-arm64::pillow-10.1.0-py39h755f0b7_0
  pip                conda-forge/noarch::pip-23.3.2-pyhd8ed1ab_0
  proj               conda-forge/osx-arm64::proj-9.3.1-h93d94ba_0
  pthread-stubs      conda-forge/osx-arm64::pthread-stubs-0.4-h27ca646_1001
  pyparsing          conda-forge/noarch::pyparsing-3.1.1-pyhd8ed1ab_0
  pyproj             conda-forge/osx-arm64::pyproj-3.6.1-py39hd1c2dfb_5
  pyshp              conda-forge/noarch::pyshp-2.3.1-pyhd8ed1ab_0
  python             conda-forge/osx-arm64::python-3.9.18-hd7ebdb9_1_cpython
  python-dateutil    conda-forge/noarch::python-dateutil-2.8.2-pyhd8ed1ab_0
  python_abi         conda-forge/osx-arm64::python_abi-3.9-4_cp39
  readline           conda-forge/osx-arm64::readline-8.2-h92ec313_1
  setuptools         conda-forge/noarch::setuptools-68.2.2-pyhd8ed1ab_0
  six                conda-forge/noarch::six-1.16.0-pyh6c4a22f_0
  sqlite             conda-forge/osx-arm64::sqlite-3.44.2-hf2abe2d_0
  tk                 conda-forge/osx-arm64::tk-8.6.13-h5083fa2_1
  tzdata             conda-forge/noarch::tzdata-2023d-h0c530f3_0
  unicodedata2       conda-forge/osx-arm64::unicodedata2-15.1.0-py39h0f82c59_0
  wheel              conda-forge/noarch::wheel-0.42.0-pyhd8ed1ab_0
  xorg-libxau        conda-forge/osx-arm64::xorg-libxau-1.0.11-hb547adb_0
  xorg-libxdmcp      conda-forge/osx-arm64::xorg-libxdmcp-1.1.3-h27ca646_0
  xz                 conda-forge/osx-arm64::xz-5.2.6-h57fd34a_0
  zipp               conda-forge/noarch::zipp-3.17.0-pyhd8ed1ab_0
  zstd               conda-forge/osx-arm64::zstd-1.5.5-h4f39d0f_0

Downloading and Extracting Packages

Preparing transaction: done
Verifying transaction: done
Executing transaction: done
#
# To activate this environment, use
#
#     $ conda activate test39
#
# To deactivate an active environment, use
#
#     $ conda deactivate

And a simple test for this new environment:
(base) vic@alpha:~$ conda activate test39
(test39) vic@alpha:~$ python -c "from mpl_toolkits import basemap; print(basemap.__version__)"
1.3.9

I found out that it is very important for basemap to stay within the conda-forge channel for the dependencies, otherwise there is unexpected behaviour (some numpy dylibs missing).
cc @jucor since you were asking about this very long ago.

Brilliant! Thanks a lot for the update @molinav :)

Hello, I have been trying to run code originally written for Python 2, but I have encountered some issues when attempting to run it
Traceback (most recent call last): File "PyVelest.py", line 27, in from mpl_toolkits.basemap import Basemap File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mpl_toolkits/basemap/init.py", line 53, in import _geoslib ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_geoslib.so, 0x0002): symbol not found in flat namespace '_GEOSArea'
I have done everything that others have suggested in this issue, but I don't have any idea what's going on. I use a Mac M2, and I don't know if there is any problem with Macs.

@Isaac0880 May I ask you to open a separate issue for the specific problem that you are describing? If you provide a complete traceback and a description of the environment, I can try to see what can be done.


⚠ API - Lens has degraded performance

In e1d703d, API - Lens ($LENS_API_URL) experienced degraded performance:

HTTP code: 502
Response time: 345 ms

Resolved: API - Lens performance has improved in aa285db after 24 minutes.


Crash outside of "public" branch, when viewing manifests.

Example:

Select Black Mesa.
Change branch to public-beta.
Try to view manifest of change on depot and branches.

There's no "crash". SteamDB only tracks manifest/depots in the public branch.


Install coq-community boilerplate

@palmskog as mentioned in Zulip, I have split your commit into two (see #7 for the second half). If that’s fine by you, I would like to merge this PR as-is.


ENH: Conform to GitHub PR and issue template guidelines.

Conform to GitHub PR and issue template guidelines:

Add the YAML front matter markup.
Split the former ISSUE_TEMPLATE.md into a BUG_REPORT.md and a
FEATURE_REQUEST.md template so that they better serve their purpose.
Store the templates into their own, separate folders.

These changes should enable the templates be included in the community
profile checklist:
https://github.com/InsightSoftwareConsortium/ITK/community
References:
https://help.github.com/articles/about-issue-and-pull-request-templates/
https://help.github.com/articles/manually-creating-a-single-issue-template-for-your-repository/
https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/

Not sure how we will be able to test these before merging.
This comes after some discussions with the GitHub support team dating back to October 2018, and after they have updated the referred documentation.
The issue stemmed from the fact that I realized that our CoC and Issue Template were not being taken into account in the Insights/Community profile.
Let's see if this makes the trick. Cross-checking the documentation would be appreciated (e.g. looks weird that the YAML :about: is the only field requiring a colon before the word).
Thanks for your patience.

The errors reported by ITK.Linux Azure are unrelated:
The following tests FAILED:
	2058 - itkSPSAOptimizerTest (Failed)

with the following error:
etValue( 1.97733 -1.98178) = -9.99906
Solution        = (1.97726,-1.98181)
StateOfConvergence in last iteration: 5.65225e-06
NumberOfIterations: 58
Stop condition: SPSAOptimizer: Below tolerance. Tolerance is 1e-05
Test failed.

May be due to some numerical instabilities? Not sure when this started failing. Would need some time to investigate.

The errors reported by ITK.Linux Azure are unrelated: itkSPSAOptimizerTest fails

Yes, this is new to me -- let's keep an eye on it :eyeglasses: .

Thanks Matt.
Unfortunately, it looks like the PR did not solve the issue, even the contrary :worried: :
https://github.com/InsightSoftwareConsortium/ITK/community
No issue template is displayed now when trying to open one, while I'd have expected two templates to be available now:
https://github.com/InsightSoftwareConsortium/ITK/issues/new
I'll contact the GitHub support team.


[10.x] Report exception after job timeout occurred

As i explained in #47068, TimeoutExceededException only occurs in the JobFailed event when the job fails.
Consider that I set 5 attempts to the job and timeout occurred on the first and second attempt. After that the worker is killed and there is no way to know the timeout exception occured.
I think it is necessary to report this exception or send a special event

I can revisit the event PR - what are you actually trying to accomplish?


fix: add railtie to clear caches when code reloads

fixes #1439
This adds a railtie hook to clean up the JSONAPI::Resource caches when code reloads so that we don't have stale references to classes lying around.
I'm not sure how to test this one in a test suite, but there's a reproduction script in #1439 that passes with this.
All Submissions:

[x] I've checked to ensure there aren't other open Pull Requests for the same update/change.
[x] I've submitted a ticket for my issue if one did not already exist. https://github.com/cerebris/jsonapi-resources/issues/1439
[x] My submission passes all tests. (Please run the full test suite locally to cut down on noise from travis failures.)
[x] I've used Github auto-closing keywords in the commit message or the description.
[ ] I've added/updated tests for this change.

Bug fixes and Changes to Core Features:

[x] I've included an explanation of what the changes do and why I'd like you to include them.
[x] I've provided test(s) that fails without the change. (see script in #1439, happy to incorporate into CI if you have ideas on how to do that)

Test Plan:
Reviewer Checklist:

[ ] Maintains compliance with JSON:API
[ ] Adequate test coverage exists to prevent regressions

Thanks @adamkiczula!


[WIP] Examples for demonstrating the usage and incremental value of TorchData Nodes

🚀 The feature
Starting this issue to track minimal examples we can create to demonstrate effective usage and value of TorchData nodes. I can create separate issues for each of these as required.
Motivation, pitch

Vanilla torch.utils dataloader usage ported over to torchdata nodes
GPU accelerated transforms
Flexible parallelism (mixing multiprocessing with multithreading)
Examples porting over popular OSS datasets

connecting to popular cloud storage

Example creating new nodes (might get covered through examples above)
Basic multimodal model trained E2E using torchdata nodes
Chaining multiple transforms (might get covered through examples above)
Dataset mixing (with different sampling strategies)

Alternatives
No response
Additional context
No response

Discussions:
let's do 1, 2, 4 but with HF, 6 through torchtune, and 8

Also add tasks for Documentation, READMEs, docstrings, param lists, design doc

Contribution guide (lower priority)


add design note for pouchdb plugin

I have created a design note for PouchDB Context Store Pulugin.
PouchDB is an abstraction layer and the database to be used is selected by the adapter.
PouchDB Context Store Pulugin applies a Node SQLite adapter and saves the data in SQLite.

This design note considers using the SQLite plugin to save to a file with a specified path.
This is similar to a file plugin.
PouchDB can also use other DB plugins and replicate.
However, let them be considered in the future.

Yes having that as a configurable option is good. SQLite is a good first choice for edge devices.
Ideally we should document/include an example configuration of how to set up the replication/backup to another server.

Updated the design notes for the PouchDB plugin.
Added information about replication to other databases.
I have also made it available for LevelDB and CouchDB, which PouchDB supports as standard.
I would appreciate it if you could also consider the repository to which the plugin will be merged.
I assume that "node-red-context-pouchdb" is used for now.

Looks good - I'll create the repo as you suggest.

https://github.com/node-red/node-red-context-couchdb

urgh - got the name wrong. Let's try that agin.

https://github.com/node-red/node-red-context-pouchdb


Update locale: Lenovo.UpdateRetriever version <IP_ADDRESS>

Checklist for Pull Requests

[ ] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.9 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

URL: https://download.lenovo.com/pccbbs/thinkvantage_en/updateretriever_<IP_ADDRESS>.exe
Status Code: 200
(Automated message - build 903)


stable/airflow Add support for prometheus rules to the airflow helm chart

What this PR does / why we need it:
This PR adds support for adding prometheus rules specified by the prometheus operator project.
Which issue this PR fixes

none

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] title of the PR contains starts with chart name e.g. [stable/chart]

@gsemet If you could review this when you have the time

/lgtm


Dusk testing updates

Duskt testing updates for acceptance tests.
Pre-Merge checklist
Complete these items before requesting reviews

[x] Static Analysis Rules Validated
[x] All commits follow naming conventions

I'll approve once i get an answer, but what is the difference between the dusk tag and using the id tag for identifying elements? I notice you use both. I have a PR that also adds more dusk but i'll update/fix things if i did something wrong.

I'll approve once i get an answer, but what is the difference between the dusk tag and using the id tag for identifying elements? I notice you use both. I have a PR that also adds more dusk but i'll update/fix things if i did something wrong.

Both work, but the main reason I use a dusk tag is that the id must always be unique to the page, so I prefer to use dusk tags in some cases where I don't want to make sure the ID I choose isn't already in use on the page


Add video player support for viewing response of video mimetype

Use case
User should be able to directly play video in the response pane when the response is of content type video/H264, video/H265, video/mp4 etc. Full list of mimetypes available here. Currently, the app allows users to download the video response.

I want to work on this can you please assign this to me @ashitaprasad

I want to work for this issue Please assign this to me @ashitaprasad

Hi @Utkarsh4517 @Harsh1350,
Firstly, Join our discord server so that you can message on the #foss channel whenever you encounter any issue. That is also our official channel where we have all discussions related to API Dash.
You must also follow the Contribution Guidelines.
We currently do not assign an issue to a single person, as it might not be the best approach.
Also, before sending a PR, just let me know when your code is ready for review.

Hi !
I would like to work on this issue, I posted a message on discord :)

Sure @Nirsu
Please feel free to work on the issue and send across a PR.
If you have any query, kindly drop a message on the discord channel.

I saw that there's a closed PR for this issue. Can I still work on it?

@monstajoe2002 yes you can.

I created a PR here: https://github.com/foss42/apidash/pull/298


Calling 'default' trait checks env first, falling back to .aws config file.

First attempt, let me know what you think.
The behaviour of this is really well documented https://rusoto.github.io/rusoto/rusoto_core/region/enum.Region.html#default

Thanks! I was wondering whether we should do the same thing on line 49:
https://github.com/jamesmcm/s3rename/blob/2d6364901ba79ac2b41b9bae48be89aa34ed0abd/src/main.rs#L49
But I think it's best to return an error like that if we can't get the bucket region, and then the user can always override that.

I agree, as it will have checked first if the user has set it as an option flag as well on line 30: https://github.com/jamesmcm/s3rename/blob/master/src/main.rs#L30.
At this point it's good to let the user know what the error was.


RFC: monthly micro surveys

I would like to run monthly micro surveys, starting once we've had a chance to process the annual survey data. This PR is an unofficial RFC to determine if its a good idea. The PR adds a README describing monthly micro surveys, I expect we will iterate on that and can discuss in this PR.
cc @rust-lang/core since I believe new surveys are core team's remit, and for this to work we would need to use project resource (blog, Twitter account, etc) to promote the surveys.

I like this proposal a lot. As we are designing the 2023 survey I see now how it is difficult to compress data (questions + options for answers) in it and make it an all-encompassing tool to learn about everything (which is unrealistic).
Minus the "monthly format", I think everything in this proposal is within our reach. I see these mini surveys more at an irregular cadence, happening when we have really something to ask, otherwise we might end up looking for a topic to respect a self-imposed monthly cadence. We could poll the community about the topics to be surveyed upon :sweat_smile:
Also, this Zulip discussion for more thoughts about how a more focused survey coold look like.
I'd like to circle back on this after the annnual survey bandwagon is gone.

Another interesting question I noticed on Zulip: "Do people want an official CI Rust Github Action?"

Closing in favour of https://github.com/rust-lang/surveys/pull/257.


adds Yii2 Container

also includes updates to current container versions

Thank you! I'll share the results very soon :)


Allow more SBATCH keywords

Allow in the input for the Slurm distribute_jobs a section to specify in a free format some other keywords required by SBATCH

solved via #241


JAVA-1286: Support setting and retrieving udt fields in QueryBuilder

For JAVA-1286.

To be honest I would be in favor of a different approach: allow QueryBuilder.raw() (or maybe QueryBuilder.column()) to be used as a column name in a set assignment.
This would lead to a change (hopefully backwards-compatible) in the signature of set(): public static Assignment set(Object name, Object value), and would require some changes in the Assignment class to detect when a variable name should or should not be enclosed in single quotes.
But I think this would be ultimately more in line with the way we currently protect strings from being mistankenly quoted by the query builder.

To be honest I would be in favor of a different approach: allow QueryBuilder.raw() (or maybe QueryBuilder.column()) to be used as a column name in a set assignment.

I am on the fence with that, but I think I've come around on your suggestion.  On the one hand, the current proposed code can break some users if they for whatever reason had periods in their column names and weren't quoting column names theirselves.   On the other hand, users should be in the right to expect the driver to not mistakenly quote the name in this particular case.
I think quoting the name for the user as it currently exists is inconsistent with other parts of our API and we should consider changing this in the future.  For example, we won't quote the keyspace when passed into Cluster.connect(keyspace).  However, we can't simply change that here.  And even changing that in a future major release could be a problem too for users (even if we are really careful about communicating it).
In that case I agree that the right approach then is to come up with an alternative way to say "Here is my name, don't touch it" (as you've proposed) by allowing use of column or raw with set.   There will still be users who encounter their name being escaped when they wouldn't expect, but at least now they'll have a workaround.

+1 for the QueryBuilder.raw() approach + we should study where else we could allow it to give people escape plans when the driver doesn't behave as expected.

Changed base to 3.x, make sure you use that branch for future rebases.

Rebased on 3.x.
On a side note, do we have an agreement on modifying cnamePattern vs modifying set signature?

Turns out changing the parameter of a public method is a breaking change :-/ it's a pity because this pattern could be applied in lots of places. But anyway, semver says no :)

We could get around the breaking change by leaving set(String, Object) and adding an overload set(Object, Object).
For selection, there is already a workaround with select().raw("a.b").
Maybe we should also have a programmatic way to express it (field("a", "b")?), for cases when you generate a query from a UDT definition.

We could get around the breaking change by leaving set(String, Object) and adding an overload set(Object, Object).

Indeed, done.

Maybe we should also have a programmatic way to express it (field("a", "b")?), for cases when you generate a query from a UDT definition.

Agreed and done. Although I named the method path instead of field, as I sense that in the future that dotted notation could be useful in more places than are currently supported.

The changes look good to me, can't approve since I created the PR, but this has my thumbs up.


chore: update types to match bn version (5.1.1)

This is resolved with the latest dependency updates. Thanks!


Dialogue oops error

Describe the bug
I've completed the setup and landed into this error
Version: 0.27.1
Path: /project/bf/dialogue
Info:
TypeError: Failed to fetch
    in TypeError: Failed to fetch
    in Unknown
    in Suspense
    in d
    in div
    in Unknown
    in div
    in t
    in div
    in t
    in div
    in div
    in $
    in ForwardRef
    in ForwardRef
    in Connect(Component)
    in c
    in Unknown
    in RouterContext
    in Router
    in o
    in c
    in t
    in DocumentTitle
    in SideEffect(DocumentTitle)
    in $

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser: Brave
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

https://github.com/botfront/botfront/issues/790
https://github.com/botfront/botfront/issues/789


refactor Dockerfile in order to use python:3.8-slim-buster as base

Overview
This PR modifies pycsw's Dockerfile in order to use an official python-debian image as the base for building.
Related Issue / Discussion
#614
Additional Information
My percieved advantages of this approach vs the current implementation (base image based on alpine linux):

Faster cold build time, since we can use python wheels - no need to compile anything
Similar environment to CI and non-docker environments (seems to me that alpine is not common outside of embedded and containers)
Being based on the official Python repos, it is easier to build and test pycsw with other python versions, it is just a matter of changing the dockerfile base image

In addition to replacing alpine with an offcial python image based on current debian, I've made some other notorious modifications to the Dockerfile:

Rearrange dockerfile commands in order to make use of the docker caching mechanism. This makes rebuilding the image much faster whenever a change is made in the pycsw codebase - This change is orthogonal to the image being used as a base so we should add it regardless of what final decision is made on the alpine vs. debian front

Install pycsw in editable mode, which allows easier dev workflow - we can run a container and mount the code dir
Additionally, leave all files in place instead of moving pycsw config to /etc/pycsw and moving entrypoint.py to /usr/local/bin - this is also in order to allow a friendlier dev environment

Install the psycopg2-binary dependency instead of psycopg2. This change has been made in the Dockerfile and not on the requirements-pg.txt file in order to be less intrusive

Comparison between the proposed implementation and current master:

Current master (based on alpine)

Builds are slow
image is small
Rebuilds are slow

time docker build -t geopython/pycsw:master -f Dockerfile .
# build time: 2m50s
# image size: 172MB
# rebuild time after a change in pycsw's codebase: 2m58s

This implementation (based on debian)

Builds are fast
image is bigger
Rebuilds are fast

docker rmi geopython/pycsw:with-dev python:3.8-slim-buster
time docker build -t geopython/pycsw:without-dev -f Dockerfile.test2 .
# build time: 30s
# image size: 311MB
# rebuild time after a change in pycsw's codebase: 5s

IMO an image size of 311MB is still pretty modest and, all things considered, absolute image size is probably not so relevant anyway.
This implementation builds significantly faster and uses a more flexible and familiar base image. It also opens up the door to other niceties:

It is now easier to dev inside a docker container, for example with:
# using the container for dev work by bind mounting the code dir inside the container
# changes to pycsw are automatically available inside the container
docker run \
    --name pycsw-dev \
    --rm \
    -ti \
    -v $(pwd)/pycsw:/home/pycsw/pycsw/pycsw \
    {image}

# reload the gunicorn server by sending the HUP signal (it is pid 1 inside the container)
docker exec -ti pycsw-dev /bin/bash -c 'kill -HUP 1'

It is now easier to run tests inside a docker container:
# running tests inside container (requires installation of the dev requirements)
docker run \
    --rm \
    -ti \
    --user root \
    --entrypoint /bin/bash \
    {image} \
    -c 'cd pycsw && pip install requirements-dev.txt && su pycsw -c "pytest -x -v -k \"not harvesting and not distributed\""'

Contributions and Licensing
(as per https://github.com/geopython/pycsw/blob/master/CONTRIBUTING.rst#contributions-and-licensing)

[x] I'd like to contribute [feature X|bugfix Y|docs|something else] to pycsw. I confirm that my contributions to pycsw will be compatible with the pycsw license guidelines at the time of contribution.
[x] I have already previously agreed to the pycsw Contributions and Licensing Guidelines

There seems to be a failing CI test for something unrelated to this. Something to do with demo.pycsw.org
@tomkralidis any thoughts on this?

@ricardogsilva I revamped the demo and forgot that the gisdata service was being used by the tests.  This is back online now, and I've closed/reopened this PR as a result to see how the tests run.

@tomkralidis any update on this?

@ricardogsilva in discussion : https://gitter.im/geopython/pycsw?at=5ebb568840e3122a8814ef35
I like the fact that the PR aligns the dev and test workflow.  cc'ing @kalxas and @epifanio for any comments on this PR.

Thanks for the updates.
+1 to merge

@ricardogsilva @epifanio @tomkralidis how about having 2 separate docker images (one based on alpine and one based on debian)?

+1

-1
I'm obviously biased, since I am the one proposing this change :smile:
However, it seems to me that the only benefit of keeping an alpine-based image at this point is just to try and get the smallest image size possible. In my opinion this is not a worthy effort because:

the current proposal generates images that are still somewhat small (for Python), as it is below 350 MB
due to how docker caching works, the actual size taken on disk is likely much smaller, since deployments are likely to also use other images based on debian
being based on glibc, we can use python wheels (which are not available for alpine) and thus we don't need to install dev dependencies no compile anything, which results in a simpler Dockerfile
build times are a lot faster and rebuilds are also faster
there is now a much more pleasant developer experience
opens up interesting possibilities also from a CI perspective, where we could now have a pipeline that builds the docker image, runs tests inside it, pushes it to docker registry, etc

Also, keeping two images means more maintenance work, which is also a stress factor given the small size of the team.

I am also biased because I do much packaging for rpm and deb so I obviously prefer a mature distribution over alpine :)

I am also biased, but I will try to give my 2 cents.
At work I was required to use the smallest image possible ... hence the needs of using alpine. In reality, as a developer, the benefits of using an image with a small footprint like alpine are too little compared to the flexibility offered by Debian based machine.
Maybe in a production environment alpine is to prefer and will be worth to maintain a pycsw dockerfile dedicated to that purpose ... but in development, I found very time-consuming rebuilding each time the alpine machine because I needed to add extra libraries for data-science which are not available for alpine (also debugging is hard, no vim no nano no bash .. in default alpine)

Thank you all for the feedback, I think there is consensus to merge this PR and move to debian based images as default.


[Dubbo-7514]Ignore "dubbo" namespace when using nacos registry and metadata center

What is the purpose of the change
fix #7514

Codecov Report

Merging #7738 (87ec268) into master (e845e16) will decrease coverage by 0.16%.
The diff coverage is 0.00%.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e845e16...87ec268. Read the comment docs.


Upload: Project's readme

DO NOT MERGE BEFORE I GET THIS INFO:
I also need info from @devimalka @leixdd for this section of README:

Update: Devim's info was added, now we only need Lei's and probably @yutounun since he has joined us today.

Ready to be merged!

Ready to be approved!


fix(samples/resource): fix samples intent creation

Fixes #11

[x] Tests and linter pass

Codecov Report

Merging #104 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #104   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           1      1
  Lines           5      5
=====================================
  Hits            5      5

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 693bd53...0140f48. Read the comment docs.


#66 Update pool stake page UI

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

52 of 54 (96.3%)  changed or added relevant lines in 21 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.1%) to 73.332%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

packages/ui/src/components/Icons.tsx
1
3
33.33%

Files with Coverage Reduction
New Missed Lines
%

apps/staking/src/components/stake/components/StakingInstructions.tsx
1
73.33%

Totals

Change from base Build<PHONE_NUMBER>:
0.1%

Covered Lines:
2707

Relevant Lines:
3507

💛  - Coveralls

@nevendyulgerov, The deposit button, once enabled, becomes the old blue. Also, there is a conflict to be solved.
Screenshot


The problem that the app runs internally when a push message is received even when it is terminated

Steps to Reproduce

This is a test in ios.

Swipe to completely terminated the app.
Even if the app is completely closed, the app runs internally when it receives a push.
initstate, build functions are called even though the app is shut down.  is it normal?

If this is normal, how can i distinguish it from what a user executes?
Expected results:
Actual results:

Logs
I could not leave the log because I did not own the mac to connect the device.

[√] Flutter (Channel stable, 2.2.1, on Microsoft Windows [Version 10.0.19042.1052], locale ko-KR)
• Flutter version 2.2.1 at C:\flutter
• Framework revision 02c026b03c (5 weeks ago), 2021-05-27 12:24:44 -0700
• Engine revision 0fdb562ac8
• Dart version 2.13.1
[√] Android toolchain - develop for Android devices (Android SDK version 30.0.3)
• Android SDK at C:\Users\Seong\AppData\Local\Android\Sdk
• Platform android-30, build-tools 30.0.3
• ANDROID_SDK_ROOT = C:\Users\Seong\AppData\Local\Android\Sdk
• Java binary at: C:\Program Files\Android\Android Studio\jre\bin\java
• Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6842174)
• All Android licenses accepted.
[√] Chrome - develop for the web
• Chrome at C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
[√] Android Studio (version 4.1.0)
• Android Studio at C:\Program Files\Android\Android Studio
• Flutter plugin can be installed from:
https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
https://plugins.jetbrains.com/plugin/6351-dart
• Java version OpenJDK Runtime Environment (build 11.0.8+10-b944.6842174)
[√] VS Code (version 1.57.1)
• VS Code at C:\Users\Seong\AppData\Local\Programs\Microsoft VS Code
• Flutter extension can be installed from:
https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter
[√] Connected device (3 available)
• SM G887N (mobile) • 39934ad8f80c7ece • android-arm64  • Android 10 (API 29)
• Chrome (web)      • chrome           • web-javascript • Google Chrome 91.0.4472.124
• Edge (web)        • edge             • web-javascript • Microsoft Edge 91.0.864.59

@jinnyum
I believe you've already asked / opened this issue in flutterfire repo: https://github.com/FirebaseExtended/flutterfire/issues/6517
Please follow-up in it instead of opening multiple issues in different repos. Your question is related to firebase.
Closing from here.


Update to Xcode 9

Codecov Report

Merging #5 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master       #5   +/-   ##
=======================================
  Coverage   85.42%   85.42%
=======================================
  Files          41       41
  Lines        2703     2703
=======================================
  Hits         2309     2309
  Misses        394      394

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e5fcf7a...dd92b04. Read the comment docs.


Changing to Celcius

Hi,
I can't find the way to change the recipe editor to use degrees celsius, it's even possible?

This is not possible at this time. Please convert from Celsius to Fahrenheit manually (say using google or some other tool /calculator).
I'll leave this ticket open as a user improvement, though isn't going to be prioritized right now due to prioritizing the server setup and device coverage. For this ask there is a known workaround of converting temperatures yourself.

Hi @tmack8001 , I modified the server to allow F o C, the setting is done in the config file, the conversion to C is in the display functions only, the data sended to the Pico and saved on files is still in F. (I just did it for the Pico recipes). Some times there are one degree difference due to the decimals in the conversion.  I don't know how to use git to send the changes for your review.

I made a pull request #105 with the enhancement


basic system tests

Add some basic tests to do the following for all nodes or by groups of nodes

ssh test
check nvidia drivers via nvidia-smi
check mount tables
check kernel version
check all yum repos in /etc/yum.repos.d/

buildtest can use clush https://clustershell.readthedocs.io/en/latest/tools/clush.html to run commands against groups. buildtest can manage the groups file to execute commands against nodes, groups.

adding comment to avoid stale bot to close ticket.
@vsoch this issue was inspired by the SC19 BoF see https://sc19.supercomputing.org/proceedings/bof/bof_pages/bof195.html
There is a Github project https://github.com/olcf/hpc-system-test-wg related to this work. I have worked with clush its great tool but was not sure how to approach this problem.

Let's keep this open stalebot, thanks!

I think we should work on basic testing for the library before going into advanced tests, but it's +1 from me!

@shahzebsiddiqui I think this fits nicely with tutorials, so I'm going to transfer there.


fix: unsupported platforms

:tada: This PR is included in version 8.7.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Always use https://

This CL simply makes sure we don't use // and also adds playsinline which is almost always mandatory in iOS world
This CL simply makes sure we don't use protocol relative URLs.

Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the asset you need is available on SSL, then always use the https:// asset.
Allowing the snippet to request over HTTP opens the door for attacks like the recent Github Man-on-the-side attack. It’s always safe to request HTTPS assets even if your site is on HTTP, however the reverse is not true.

Source: See https://www.paulirish.com/2010/the-protocol-relative-url/ and https://google.github.io/styleguide/htmlcssguide.html#Protocol.

@joeyparrish Here it is: git grep -l "'//" | xargs sed -i "s/'\/\//'https:\/\//g"

Thank you, but I meant in the entire project, not just the docs.  Don't worry, though, I'll take care of it.  git grep -l was a very helpful hint.  Thanks!


Use rfdc module as bedrock.util.clone implementation

Replace lodash.clone with https://www.npmjs.com/package/rfdc
https://www.npmjs.com/package/rfdc#benchmarks
We will get a free performance bump wherever bedrock.util.clone is used.

This might be better: https://github.com/lukeed/klona

Instead, we should remove bedrock.util.clone and any other utility function as well, so that changes / fixes / removals in the core bedrock package do not disrupt all other dependencies.

bedrock.util.clone is being removed in v6, closing.


Claims list for access tokens

Can there be a table for the claims of access tokens, similar to the table for ID tokens?

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

ID: c18ae119-a9b9-44eb-ead0-f8dee59718b2
Version Independent ID: 92634a9a-ac00-6aa4-1c3b-67f8940a9ad5
Content: Azure Active Directory v2.0 tokens reference
Content Source: articles/active-directory/develop/v2-id-and-access-tokens.md
Service: active-directory
GitHub Login: @CelesteDG
Microsoft Alias: celested

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

@jchenbb Please refer to document JSON Web Token claim set to get the list of claims.

Thanks for the pointer.  Specifically I'm looking for clarification on the values of the aud and appid claims. We observed from the graph api access token the aud claim is "https://graph.microsoft.com" and the appid claim carries the client app id. From an access token for a registered third party resource though, the aud claim has the app id and there is no app id claim.
Would like to see elaboration on the usage of these two claims. Thanks!

@jchenbb Please refer to SAML2 vs JWT: Understanding JSON Web Token (JWT)

@jchenbb we'll look at getting this doc update.  In general, the client shouldn't be looking inside the access token claims; rather, they're intended for the service they're being sent to.
For your specific question:

Audience: specifies who the token is intended for. In this case, the token is meant for the Microsoft Graph API. If the token was for your service, this field would reflect your App ID URI or Application ID.

AppID: reflects the app registration (denoted by the GUID named App or Client ID) of the client app that obtained the token. Note, this is not who the access token is necessarily intended for, but who obtained the token on the users behalf.

Thanks. This is indeed for deciding how the service validates the access token.
The definitions make sense. Is appid a mandatory claim on all access tokens? We see it missing from the access token for our service. We happen to have a single application registration for both the web api (service) and the client application. They have the same application id.

Hi @jchenbb - Please see this topic, https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens, which provides lists of the claims in access tokens. This was content we released/updated for the Ignite 2018 timeframe.

@SaurabhSharma-MSFT @MarileeTurscak-MSFT @MohitGargMSFT @MicahMcKittrick-MSFT Provided answer to customer. #please-close Thank you.


gffstring mishandles transpliced genes

'locus(gene).strand' in gffstring assumes all positions in the locus are on the same strand, which is not true for trans-spliced genes, e.g. join(11056..11919,complement(94283..95886)) is a valid GenBank locus that can now be faithfully represented using your much-appreciated rewrite of GenomicAnnotations.Locus, but which is rendered as
gene	11056	11919	.	+
gene	94283	95886	.	+
by GFF.gffstring()

Thanks for bringing up these issues; I only work with prokaryotic data so I rarely encounter more complex locus descriptors myself.


Teleporting Enemies Block Tiles

Currently, enemies that teleport are moved using the spatial system (until the next turn, at least, when their position is removed and the map indexing system no longer includes them). They should probably be removed from the spatial map instead, since they're no longer present on the map.
Additionally, in 5.25 multi-tiled enemies aren't handled by the move system or death system. Since those interact with the Spatial Map, they should probably also be updated.

Additionally: blocking multiple tiles stops pathfinding from working if you head down+right of the enemy. A simple fix is to remove the entity from the spatial map before doing any pathing :)


Android: 'The item you requested is not available for purchase' error.

Version of react-native-iap
2.3.23
Version of react-native
0.57.8
Platforms you faced the error (IOS or Android or both?)
Android
Expected behavior
With the help of RNIap.buySubscription('subscription.id') method I will subscribe to any application subscription.
Actual behavior
Frankly speaking, that is caused by android project configuration, I think. After moving from one project id (com.project.id) to another one (new.project.id) this method is always returning error "The item you requested is not available for purchase." After some hours of googling I've found out that this is the common issue with lots of info about it. But after 3 days!!! of debugging I'm still getting this error. The funniest part is that RNIap.getSubscriptions(SUBSCRIPTIONS) is always returning the full list of project subscriptions. And one more thing - after returning back to previous project id (com.project.id), everything works fine. Maybe someone there also faced it and could help.
Tested environment (Emulator? Real Device?)
Real device. Android version 6.0.1
Steps to reproduce the behavior
Try to use RNIap.buySubscription('subscription.id') method.

I'm also facing this error

@rayashi have you found the way to fix it?

@s-aleinik unfortunately not, have you ?

@rayashi same. Have wrote to the support and for now they're "investigating my issue".

@s-aleinik let me know the news

nothing useful from google so far

@rayashi Hi. I have update on it. After long discussions with Google, we tried to rollout app into production. App is published now, and only after that subscriptions have started working. But fore some reason, they're all "Test subscriptions" - free for users to use

facing same issue any body can help?

Hi i for me works for some devices , but not working for new license testers that am adding


Windows Android Prod Pool alert for not enough devices.

See why windows android prod pool does not have enough devices to run tasks.

This is due to github issue https://github.com/flutter/flutter/issues/107667


Feature: add #empty? method to result class

Purpose
I'm working on switching our Rails monolith from using the mysql2 adapter to trilogy.  One of the things that came up was the Public API varies from ActiveRecord::Result and Trilogy::Result
ActiveRecord::Result API difference
As you can see here there's a public method #empty? and other gems have implemented features around that API.
Gem impacted
composite_primary_keys expects for there to be a public method to respond to #empty?, but since there isn't one currently the user sees
NoMethodError: undefined method `[]' for nil:NilClass

I debated opening up a PR in the impacted gem or here, but I decided that this is where I'd start.
Test
I didn't see any current test for this file, it'd be pretty a simple test since we're just checking #empty?

@matthewd I was on the fence where this best first. I'll try another approach elsewhere. Cheers!