Where is .keys() method of underlying HashMap?

subj

There isn't one, at least not directly. You can use ReadHandle::for_each to iterate through all keys and optionally the values as well.
However, due to the nature of reading the shared maps, if any substantial computation is done while scanning the keys, this will block WriteHandles from refreshing. I'd suggest quickly finding the key/value you need, cloning the key/value and then using it outside after the for_each call.

My knowledge is not deep enough, but isnt it cheap to get just Vec of Keys
at once?
пт, 10 мая 2019 г., 2:48 Aaron Trent<EMAIL_ADDRESS>
There isn't one, at least not directly. You can use ReadHandle::for_each
https://docs.rs/evmap/5.0.2/evmap/struct.ReadHandle.html#method.for_each
to iterate through all keys and optionally the values as well.
However, due to the nature of reading the shared maps, if any substantial
computation is done while scanning the keys, this will block WriteHandles
from refreshing. I'd suggest quickly finding the key/value you need,
cloning the key/value and then using it outside after the for_each call.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jonhoo/rust-evmap/issues/27#issuecomment-491105740,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACPXFN4Z3SP7BXI2ER5SDIDPUSZ37ANCNFSM4HL6YO2Q
.

No.
The underlying hashmaps don't usually store the keys in contiguous memory, and .keys() for the standard library HashMap and hashbrown both return a lazily evaluated iterator rather than a Vec.


Remove log when key is not found

@tcheymol If you don't want logs to be in production then use something like this on production build https://github.com/babel/babili/tree/master/packages/babel-plugin-transform-remove-console
I think this can be closed @stefalda since removing console.log is not responsibility of this library

I don't think that using the babel transform is the best solution.
Can we use environment-variables and only trigger the log when in development?


Add XTTS support option

Now that Coqui has opened use of XTTS for non-commercial use, add support for using that instead of VITS.
Something like including:
tts = TTS("tts_models/multilingual/multi-dataset/xtts_v1", gpu=True)
and:
tts.tts_to_file(text = chapters_to_read[i], file_path = outputwav, speaker_wav="sample.wav", language="en")
Note this requires speaker sample file to be included.

Will not be doing this, XTTS seems nice for one-shot short clone attempts, but currently not suitable for long stuff like books.

XTTS v2 is so good, and works awesome. This has been added. It's slow (as expected), but worth the wait. Support for XTTS has been merged.


Links in service details page, should be separated

Rancher Version: v1.2.0-pre2-rc2
Steps to Reproduce:

Create a service with three links
Have one of the links be as "abc"
Go to the service details page it's active
Go to the Links tab

Results: The links text is just a run-on list of words that is hard to make sense of

Expected:  The links should either be in a table and on separate rows, or at least have some sort of separation between each one.

Version - v1.2.0-pre2-rc5
Verified fixed


UV Event Loop (unofficial ext-uv)

@clue @jsor right, rebased this PR against the latest master. Could you review?

what about to merge on this pr?
@WyriHaximus @clue @cboden

@clue @jsor @cboden updated PR and it fully works without odd hacks now, could you review this PR again?

You probably want to add a method to this loop implementation class to allow the user to get the underlying UV event loop, otherwise making use of the UV extension is limited to just the event loop implementation. A libuv-based adapter for react/filesystem will be impossible, as you can't get the UV event loop that is used by this loop implementation. And I don't see that this loop implementation will do 100% coverage of libuv. 😅

@CharlotteDunois there you go https://github.com/reactphp/event-loop/pull/112/commits/5d40fc519721f8af581b69c7d85d2c748839032c this was always my intention to do but I wanted to focus on a stable loop first. But since that cat is out of the bag I've added it. My intention is to add a ext-uv filesystem adapter as well once this PR has been working to my satisfaction. (Currently working out an issue with child processes in a real world project.)

@clue && @jsor && @cboden could you review this PR again. I feel it's ready to be merged and released into the wild :tada: .

FYI the issues I was having wheren't related to the event loop directly but due to file descriptors being passed on child processed by default, solving that down/upstream depending on your perspective: https://github.com/WyriHaximus/reactphp-child-process-messenger/pull/22


how to calculate the influence probability in Eq. 4

When calculating the influence probability from i to j, do you average all predicted conditional probability P(j|i)？Another question is that if the dataset contains N students, do you need to average the predicted conditional probability P(j|i)？
As the DKT paper didn't explain the details for calculating Eq.4, I want to know how to calculate this influence probability.
Thanks for your response.

You may check this, it's a great explanation that can help you through your questions.


faiss: init at 1.7.2

Description of changes
Adds faiss, a library for fast nearest-neighbour search.
The derivation can be built with cuda support and with python bindings.
The checkPhase does nothing, but passthru.tests include the pytest suite and a demo from the upstream.
For the python part, the derivation expects pythonPackages as a package set, rather than individual python dependencies.
Since the main derivation is outside the python package set, I also chose not to populate propagatedBuildInputs (otherwise they should contain numpy)
New attributes:
faiss
python3Packages.faiss

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

An other PR depends on this package. The work you did looks really great, hope it can get merged.

No major changes in the last force-push, just:

rebased on master,
renamed tests.

I checked nix-build -A python3Packages.faiss.tests and nix build .#faiss
This may be squashed-n-merged now

Unfortunately I'm unable to build and test it locally because the build process is eating my memory ^^ Not sure if this is normal but my system seems to weak for building it with nixpkg-review.

Result of nixpkgs-review pr 168197 run on x86_64-linux 1

2 packages built:

faiss (python310Packages.faiss)
python39Packages.faiss


Fix Linux platform (specifically getBinary(), exec(), and spawn())

There was a bug in the SudoerLinux.getBinary() function which replaced the path with an object, causing [object Object] to appear as the binary path.
There was another bug in SudoerLinux.exec() and SudoerLinux.spawn() which prevented the DISPLAY variable from being set correctly if options.env isn't provided.
A (good) side effect of the fix for the exec/spawn bug is that both functions now use env just like the native Node.js equivalents (Node passes your current process.env if you don't specify the env option).
Tested and working on my machine. :+1:

@facekapow I found a further bug in the Linux support, which only shows up if you don't have gksudo installed. If you fast-forward merge my commit, it will fix that (the explanation of the bug is in the commit message).

@malept Nice find, thanks! I've merged it in.

tnx, i'll fix it very soon

Now code is being refactored and i will add you fix in new code


Add RPGF1 Results

Adding RPGF1 recipients results

Original
Updated
Change
Reasoning

evm_grants.csv
n/a
added rpgf1 for Optimism
n/a

Nice!!!

great stuff!


As an Industry Reporter I want to see a 'More' column in my operations table in the reporting dashboard so that I can do additional actions for reporting

Description:
We need to let operators take some additional actions from the Reporting Dashboard page. This includes navigating to the"edit report" "report history" page, the "download .csv" page (TBC) and "download LFO report" page (also TBC)
Wireframe here

Acceptance Criteria:
Given that I am an external operator
And I view the operation list
Then the last column contains a 3 dot button
Given that I am an external operator
When I view the operation list
And I click on the 3 dot button
Then a menu opens with the above mentioned items
Given that I am an external operator
When I view the operation list
And I click on a menu item
Then nothing happens
Development Checklist:

[x] A contextual menu (MUI Menu type)
[x] Clicking on the 3 dots opens the menu
[x] Menu contains placeholder options which do nothing when clicked

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

[x] User story is included
[x] User role and type are identified
[ ] Acceptance criteria are included
[ ] Wireframes are included (if required)
[ ] Design / Solution is accepted by Product Owner
[ ] Dependencies are identified (technical, business, regulatory/policy)
[ ] Story has been estimated (under 13 pts)

Definition of Done (Note: If any of these points are not applicable, mark N/A)

[ ] Acceptance criteria are tested by the CI pipeline
[ ] UI meets accessibility requirements (TBC)
[ ] Configuration changes are documented, documentation and designs are updated
[ ] Passes code peer-review
[ ] Passes QA of Acceptance Criteria with verification in Dev and Test
[ ] Review with UX Designer
[ ] Ticket is ready to be merged to main branch
[ ] Can be demoed in Sprint Review
[ ] Bugs or future work cards are identified and created
[ ] Reviewed and approved by Product Owner

Blocked By
#217
Notes:

Design Review:

Flagging that we don't have 'Download LFO' anymore, and devs clarified that it is a placeholder text that can be removed easily


Search API called twice on search page load

Steps to Reproduce
Go to /search and view the search page
Expected Behavior
In the network tab you should see one call to POST to /search when the page loads.
Actual Behavior
There are two calls to POST to /search in the network tab on page load. Each subsequent search on the page only has one POST to /search.
Related Issues
This is likely a regression related to work from https://github.com/mitodl/course-search-utils/pull/17

This will be fixed in https://github.com/mitodl/course-search-utils/pull/19


Memory leak

In DownloadDispatcher.java, mRequest is a global variable. if mRequest set DownloadStatusListenerV1 and DownloadStatusListenerV1 contains Activity instance, this will lead to memory leak. Because gc will not collect mRequest if there is no new request for this Dispatcher.
If @smanikandan14 you also think this is a problem, i will create pr for this issue.
I create pr for this issus, link:https://github.com/smanikandan14/ThinDownloadManager/pull/88

PR Merged. Closing.


Exception with Queue Exception: Please install the Algolia client: algolia/algoliasearch-client-php. in vendor/laravel/scout/src/EngineManager.php:59

Hi,
I using laravel-scout-mysql-driver with Laravel 6 and I've got exception when execute in Queue, I've got exception:

Exception: Please install the Algolia client: algolia/algoliasearch-client-php. in vendor/laravel/scout/src/EngineManager.php:59

I've config scout to use mysql but still got issue when run it in Queue

It's my fault


Feat: Skip server setup

This PR has almost the same goal as:

#96

It simply turns off the configuration from ENVIRONMENT VARIABLES, which is great for migrating an existing server into this Docker.

The diff on GitHub looks really messy; it just wraps all the settings inside a if block.

Hey @miaulightouch - We ( @thejcpalma and me ) just added this feature, its called "SERVER_SETTINGS_MODE" in the environment variables.


Implement SummaSigner

To interact with the on-chain verifier, a signer is required in the backend.
Once PR #79 is merged, we can begin implementing this using ethers-rs in the backend.
More specified doc in here https://hackmd.io/0Dp2mudRRCKPov6jI8LYhg?view#Summa-Signer
There are two key features to focus on:

Signing messages for SignedAccountData
Sending the submitProofOfSolvency transaction to the on-chain verifier.

#99 is in progress.


Race all scope polling strategies at once; first one wins

This is a follow up to #346.

In this PR we refactor the scope polling strategies into a race between the relevant ones. The first one that wins cancels all others.

We always fire the detection synchronously.
We always employ the interval polling strategy.
IF the document is not yet interactive or complete we employ the DOMContentLoaded strategy.
IF the document is not yet complete we employ the window load event strategy.

In any event, the first strategy to result in the detection of the given wallet cancels all of the others.
Test plan
Loaded the React starter (not a very exhaustive test plan).
https://user-images.githubusercontent.com/13243/156705441-6d819ea7-c020-4051-84af-ef4d3b4e8324.mov

cc/ @safaiyeh.

@steveluscher appreciate the follow up! Looks good, Strat #2 will fix our use case


dynamic image load

Thanks for making this public. Would you accept a PR for enabling dynamic image loading?
https://github.com/ssomnoremac/react-image-zoom/pull/1

Hi,
you can youse react key property to update image
<ReactImageZoom
  width={400}
  height={250}
  zoomWidth={500}
  img='http://example.com/assets/jmg/1.jpg'
  key='http://example.com/assets/jmg/1.jpg'
/>

But in general i think it is good to have possibility to change image without key manipulation.
Could you update your fork and create PR with something like:
componentWillReceiveProps(nextProps) {
  if (this.props.img !== nextProps.img) {
    this.imageZoom.kill();
    this.imageZoom = new ImageZoom(this.refs.container, nextProps);
  }
 }

img change verification prevents unnecessary kill/create actions of js-image-zoom in case of parent rerenders without changing actual image source.

In current master this was implemented. I will publish version 0.1.0 of package till 03.10

@malaman , sorry, got caught up in something else.


Unfollow bug

when last_follow.object is a string, not an object? eg<EMAIL_ADDRESS>=><EMAIL_ADDRESS>Traceback (most recent call last):
...
  File "/Users/ryan/src/oauth-dropins/oauth_dropins/indieauth.py", line 224, in dispatch_request
    return self.finish(indie_auth, state=state)
  File "/Users/ryan/src/bridgy-fed/follow.py", line 209, in finish
    inbox = last_follow['object']['inbox']
TypeError: string indices must be integers

Fixed in https://github.com/snarfed/oauth-dropins/pull/286, moved on to a BF bug: https://console.cloud.google.com/errors/detail/CIHQk8v61sGIYA;time=P30D?project=bridgy-federated
ypeError: string indices must be integers
at .finish ( /workspace/follow.py:209 )
at .dispatch_request ( /layers/google.python.pip/pip/lib/python3.9/site-packages/oauth_dropins/indieauth.py:224 )
at .handle_exception ( /layers/google.python.pip/pip/lib/python3.9/site-packages/oauth_dropins/webutil/flask_util.py:208 )


Update dependency on cardano-ledger-specs

This brings in https://github.com/input-output-hk/cardano-ledger-specs/pull/2049
Also improve the shrinking of CardanoApplyTxErr. These shrinkers were added to help chase down the failure fixed in the PR above. Better to leave them in, in case it happens again.

bors merge


cannot browse homedir files or folders on freebsd when fd is installed

Description
Files and folders anywhere in my home directory are not shown in the file/folder browser. This behavior is specific to my homedir. It is possible to navigate the root filesystem, for example, using file_browser as usual, but no folders or files are shown in telescope if called anywhere in my homedir or a subdirectory of it.
This only happens on my FreeBSD system when I have fd installed. Removing fd fixes the problem, and this problem does not occur on any of my Linux system (with or without fd installed).
Neovim version
NVIM v0.7.2
Build type: Release
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -DNVIM_TS_HAS_SET_MATCH_LIMIT -DNVIM_TS_HAS_SET_ALLOCATOR -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wdouble-promotion -Wmissing-noreturn -Wmissing-format-attribute -Wmissing-prototypes -Wimplicit-fallthrough -Wno-c11-extensions -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/wrkdirs/usr/ports/editors/neovim/work/.build/config -I/wrkdirs/usr/ports/editors/neovim/work/neovim-0.7.2/src -I/usr/local/include -I/usr/include -I/wrkdirs/usr/ports/editors/neovim/work/.build/src/nvim/auto -I/wrkdirs/usr/ports/editors/neovim/work/.build/include
Compiled by root@130amd64-quarterly-job-02

Features: +acl +iconv +tui

Operating system and version
FreeBSD 13.1-RELEASE
Steps to reproduce

Navigate to $HOME or any subdirectory of it
Start nvim with the minimal config: (something like nvim -nu minimal.lua)
3 :Telescope file_browser

Expected behavior
Ordinarily, the files and folders in the current directory are shown and may be opened or navigated.
Actual behavior
No files or folders are shown except for ../. Only when file_browser is called from a location outside of $HOME does it show any files or folders.
Minimal config
vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvim/site]]
local package_root = '/tmp/nvim/site/pack'
local install_path = package_root .. '/packer/start/packer.nvim'
local function load_plugins()
  require('packer').startup {
    {
      'wbthomason/packer.nvim',
      {
        'nvim-telescope/telescope.nvim',
        requires = {
          'nvim-lua/plenary.nvim',
          'nvim-telescope/telescope-file-browser.nvim',
        },
      },
      -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. '/plugin/packer_compiled.lua',
      display = { non_interactive = true },
    },
  }
end
_G.load_config = function()
  require('telescope').setup()
  require('telescope').load_extension('file_browser')
  -- ADD INIT.LUA SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
end
if vim.fn.isdirectory(install_path) == 0 then
  print("Installing Telescope and dependencies.")
  vim.fn.system { 'git', 'clone', '--depth=1', 'https://github.com/wbthomason/packer.nvim', install_path }
end
load_plugins()
require('packer').sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua load_config()]]

Apologies, I'm a bit out of my depth here as I have never used BSD or any distributions thereof. A brief search on Github issues of fd and broader google search did not yield any results.
The one solution I could think if is making opting out of fd configurable, though generally of course it would be great to understand what's causing your problem to fix it.
What does
:lua vim.pretty_print(require "telescope.actions.state".get_current_picker(vim.api.nvim_get_current_buf()).finder._finder.results)

look like for you when launched when the file browser is opened in your home folder?

Output of the following command with file browser open in homedir: :lua vim.pretty_print(require "telescope.actions.state".get_current_picker(vim.api.nvim_get_current_buf()).finder._finder.results)
{ { "/usr/home",
    Path = {
      _cwd = "/usr/home/pureume",
      _sep = "/",
      filename = "/usr/home",
      <metatable> = {
        __concat = <function 1>,
        __div = <function 2>,
        __index = <function 3>,
        __tostring = <function 4>,
        _fs_filename = <function 5>,
        _read = <function 6>,
        _read_async = <function 7>,
        _split = <function 8>,
        _st_mode = <function 9>,
        _stat = <function 10>,
        absolute = <function 11>,
        close = <function 12>,
        copy = <function 13>,
        exists = <function 14>,
        expand = <function 15>,
        head = <function 16>,
        is_absolute = <function 17>,
        is_dir = <function 18>,
        is_file = <function 19>,
        is_path = <function 20>,
        iter = <function 21>,
        joinpath = <function 22>,
        make_relative = <function 23>,
        mkdir = <function 24>,
        new = <function 25>,
        normalize = <function 26>,
        open = <function 27>,
        parent = <function 28>,
        parents = <function 29>,
        path = {
          S_IF = {
            DIR = 16384,
            REG = 32768
          },
          home = "/home/pureume",
          root = <function 30>,
          sep = "/"
        },
        read = <function 31>,
        readbyterange = <function 32>,
        readlines = <function 33>,
        rename = <function 34>,
        rm = <function 35>,
        rmdir = <function 36>,
        shorten = <function 37>,
        tail = <function 38>,
        touch = <function 39>,
        write = <function 40>
      }
    },
    ordinal = "..",
    stat = {
      atime = {
        nsec = 985295000,
        sec =<PHONE_NUMBER>
      },
      birthtime = {
        nsec = 985295000,
        sec =<PHONE_NUMBER>
      },
      blksize = 4096,
      blocks = 1,
      ctime = {
        nsec = 112789000,
        sec =<PHONE_NUMBER>
      },
      dev = -2.1500489532239e+18,
      flags = 2048,
      gen = 0,
      gid = 0,
      ino = 34,
      mode = 16877,
      mtime = {
        nsec = 112789000,
        sec =<PHONE_NUMBER>
      },
      nlink = 3,
      rdev = -1,
      size = 3,
      type = "directory",
      uid = 0
    },
    <metatable> = {
      __index = <function 41>,
      cwd = "/usr/home/pureume",
      display = <function 42>
    }
  } }

Ok, that basically means the async_oneshot_finder is not appropriately populated with results from fd for you.
It's not quite the same, but does
:lua vim.pretty_print(require "plenary.job":new({ command = "fd", args = { "-t=f" } }):sync())

work for you and show you the list of files when launched from ~?
telescope actually uses a custom async linespipe, but let's try to diagnose a bit more simpler first.

It doesn't work, it just returns: {}  0. It also doesn't work when run in a place outside of ~/ that file_browser succeeds in showing files and folders, such as in /usr/local. It throws this error:
E5108: Error executing lua .../site/pack/packer/start/plenary.nvim/lua/plenary/job.lua:499:
'fd -t=f' was unable to complete in 5000 ms
stack traceback:
        [C]: in function 'error'
        .../site/pack/packer/start/plenary.nvim/lua/plenary/job.lua:499: in function 'wait'
        .../site/pack/packer/start/plenary.nvim/lua/plenary/job.lua:453: in function 'sync'
        [string ":lua"]:1: in main chunk

Thanks again for your help :)

Ah, sorry, my bad. The problem here is it runs fd on your entire home directory. Pick a folder with say ~10 files or something which you can look at easily in a few lines :sweat_smile:

In a subdir of $HOME with just a dozen or so files, the output of that command is exactly the same: {}   0.

Ok, just to make sure, if it's super easy for you, also run the same command on a linux distro, but it should show all absolute paths for files/folders in the folder and 0.
Does :Telescope find_files work for you on FreeBSD?
Sorry for the rodeo, but this will take a bit to pin down from afar :sweat_smile:

Sorry for the rodeo, but this will take a bit to pin down from afar

No problem at all. It's the least I can do to show gratitude for this wonderful tool.
So I have tried running that command on some Linux machines and made an interesting discovery: that this problem occurs on Linux, but only in the top level of $HOME. I will try to summarize all the relevant details below.
The command you asked me to run (:lua vim.pretty_print(require "plenary.job":new({ command = "fd", args = { "-t=f" } }):sync())) I will refer to below as plenary_fd_call.
FreeBSD

find_files: works everywhere except $HOME and its subdirs
file_browser: same behavior as find_files
plenary_fd_call: works only outside of $HOME, and only in directories that are not too large/deep (it times out if run from /)
fd: calling fd from the command line by itself (without arguments) returns results only outside of $HOME (and does not time out when called from the top level of /).  When it "fails" in $HOME the exit status is 0 (there is no error).

Linux (Debain Bullseye, amd64, nvim 0.7 appimage)

find_files: works everywhere except the top level of $HOME (works inside subdirs of $HOME and anywhere in /)
file_browser: same behavior as find_files
plenary_fd_call: same as find_files and file_browser, except that it times out if run from /.
fd: calling fd by itself on the command line (without arguments) returns results everywhere except the top level of $HOME. When it fails in$HOME the exit status is 0 (no error).

Summary
On FreeBSD, fd, file_browser, and find_files only work outside of $HOME, while on Debian they work everywhere, including subdirs of $HOME, but not in the top level of $HOME itself.
I hope this helps. Let me know if anything is unclear or if there's anything else I can do to debug this. Thanks again for your help :)

that this problem occurs on Linux, but only in the top level of $HOME.

Do you have any configuration (.gitignore, .fdignore or something with user read rights -- some "brute force" ideas) or something that may prohibit that? Simple fd (fd --version  == 8.4.0) on my arch linux machine on $HOME attempts to stdout all files/folders (wall of text). Seems quuite odd.

plenary_fd_call: works only outside of $HOME, and only in directories that are not too large/deep (it times out if run from /)

When you say works, does it give you the absolute paths now? Seems to conflict with earlier observation that

In a subdir of $HOME with just a dozen or so files, the output of that command is exactly the same: {} 0.

since there should be paths in the first table.
Side note: plenary_fd_call in the sync version by default times out after 5 seconds, so timeout in / is expected.
I'm a bit puzzled, I don't think telescope-file-browser.nvim is per se the problem, but maybe more fd itself? If it works outside in system folders, then at least the job launcher and passthrough to telescope can work as expected? This makes me think it might be worth opening an issue over at fd's repo? Thoughts?
Potential workarounds for the time being:

Remove fd as there doesn't seem to any utility on FreeBSD (telescope find_files falls back to rg, file-browser back to plenary)
Use an option that forces file-browser to use plenary, like { grouped = true }

Do you have any configuration (.gitignore, .fdignore or something with user read rights -- some "brute force" ideas) or something that may prohibit that?

This was it >_< I manage dotfiles by making $HOME a git repo that ignores all contents except those added manually via git add -f. The places where it was working in subdirs of $HOME were other git repos, and the directories I made for testing purposes ultimately could not work because they were ignored by the .gitignore in the $HOME root.
Sorry to have wasted your time with this, but I really appreciate all your help and time.
For anyone else who manages their dotfiles this way, a simple work around is to alias fd with some flags, such as fd -I to allow ignored files, or fd -uu to allow ignored and hidden files.

No worries, glad we managed to solve it :)


slurm sidecar: don't use container name for temp files

Short Description of the issue
Use pod UUID to uniquely identify the sbatch job and all the related files

Environment

Operating System:
Other related components versions:

Steps to reproduce

Logs, stacktrace, or other symptoms

output

Summary of proposed changes

addressed


Refactor tailscale nginx-auth module

Description of changes
Tailscale's nginx-auth proxy, despite the name, actually works just fine with caddy and traefik (see tailscale/tailscale#4680). However, the current nixos module is closely coupled with nginx. This change breaks that coupling.
All options of the existing module except virtualHosts (which is nginx-specific) have been moved to a new module without any nginx coupling. The options remain exposed on the nginx-specific module as aliases.
closes #290353
@phaer
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/3618

Good news! Thanks for bringing this to attention.
Do you think it would make sense to wait for results of the upstream issue you linked? I.e. merging this before a rename means, that the program is confusingly still called tailscale-nginx-auth and that it's missing the '/auth-forward' endpoint, suggested in tailscale/tailscale#4680.

Caddy officially documents support for the feature. Their suggested workaround for lacking '/auth-forward` is just three lines of caddy config. I don't think that should prevent this from going ahead. The confusing program name is really the worst bit.
The current upstream situation isn't ideal, but I think it's good enough. There have not been many signs of life on the upstream ticket in the past year, and it is unclear to me if/when improvements are coming.

I think I've addressed all feedback now.

Got my maintainers entry added in another PR, so I've just rebased this.

I've rebased again to resolve conflicts with #303841. Removed a remaining mkPackageOptionMD while I was at it. Does anyone have further feedback? Not sure what's needed now to get this merged.


[EOSF-238] Update license and description of scielo

Purpose
Update license and description of scielo
Ticket
https://openscience.atlassian.net/browse/EOSF-238

@hmoco Could you look into the tests? Your other PR passed.


test all input pins fire

stress testing. wire up all input pins of all can switches together to be able to simulate all switches at once. observe the current drawn.

simulated only in big chain, not when used separately. Fixed #51, seems like now traffic is sent all the time, but some nodes still set can error flag, so in the end do not encode receive buffer errors. Pending testing if that helped. But voltage drop is not there at all even if 3 inputs on 3 switches were wired together. Voltage was still in 5.04-5.06V, so should be fine.
Pending

test of fix #51 the latest data byte encoding
test all nodes including first floor, only 10 switches and 2 relays tested so far
test long cable in the middle, say 200m, so far tested only with about 18m long cable

Tested all. Configuration:
22 CanSwitches
2 CanRelays
1 USBTin connected to laptop for running socketCan
300m long CAT5 cable, split to 2 sections, about 120/180m long
end of the bus CanRelays connected together via power lines with the extra power jacket (so that no voltage drop on the line exists due to CanRelay)
In this config, all worked reliably. Probably rather need the power line connected. WIthout it and with 1 of the CanSwitches in DEBUG mode, I was getting close to 4.5V in some nodes and was getting CAN errors then (probably transceivers getting out of their supported voltage range).
So the power line needs to be connected in the real house in the end between CanRelays. With the proper setup, the lowest voltage I measured was 5.08V comparing to 5.1V on source, so only 0.02V drop across this. So we should be good. Probably will not need that long cable in the house and at least 1 less switch anyway.


syntaxError in include is hidden - leading to suspected false negative

test.h
enum Type
{
	ERROR
};

struct A
{
};

test.cpp
#include "test.h"

extern void f()
{
    A a; // unusedVariable
}

In Cppcheck 2.4 the header will generate a syntaxError with the Windows version:
test.h:1:1: error: syntax error [syntaxError]
enum Type
^

This leads to the unusedVariable in function f() not being reported making it seems like a false negative since the syntaxError is being suppressed as it didn't occur in the file we are analyzing.
We need to make this error visible - possibly via a global warning about this.
There's most likely other errors which may lead to the same problem.

I wonder if there is a hook to simply not run if there are syntax errors. I know that is how many people set up File Watchers in IntelliJ products.

A preview of the fix I am currently testing:

I am not sure if you can put links in such in messages. Being able to directly jump to the file/line in question would be awesome.

Note: A potential fix for https://trac.cppcheck.net/ticket/11913 might affect this.


Remove  and requestLegacyExternalStorage config from library manifest

The library AndroidManifest includes various permissions that the consuming app potentially does not need. These include:

requestLegacyExternalStorage
READ_PHONE_STATE
ACCESS_MEDIA_LOCATION

and others.
The library should not declare any of these permissions, nor requestLegacyExternalStorage, and instead make it the responsibility of the consuming app to declare what it needs.

I totally agree please fix this as scoped storage for android 11 is introduced and requestLegacyExternalStorage is no longer avilible.

Hi, Thank you for using this library. Above issue has been fixed in latest version.
https://github.com/afreakyelf/Pdf-Viewer/releases/tag/v2.0.1


Ensure correcty tying of API key's restrictIndices parameter

The restrictIndices of API keys should be typed as:

an array of strings OR
a comma-separated string

Both format should be handled at serialization/deserialization time.

duplicate of https://github.com/algolia/algoliasearch-client-javascript/issues/1071, only string is accepted

Sorry about the duplicate @Haroenv, I mixed things up with all the pending issues we had recently. Thanks for noticing.

@Haroenv I'm reopening since #1071 is about restrictSources while this issue is about restrictIndices (and the types are different).

Ah good call, since it  allows an array  here, which for consistency should also be just a string https://github.com/algolia/algoliasearch-client-javascript/blob/e6dec843932bdfaac13ffa1e0a11964975499078/packages/client-search/src/types/SecuredApiKeyRestrictions.ts#L12

Thanks for checking @Haroenv. Does it mean that both types are indeed accepted? Our concern with this issue was really about the possibility that some users may pass restrictIndices either as a coma-separated string or as an array in the past, and we want both format to be accepted when generating the secured API key. So do you confirm?

We stringify the parameters here:
https://github.com/algolia/algoliasearch-client-javascript/blob/e6dec843932bdfaac13ffa1e0a11964975499078/packages/client-search/src/methods/client/generateSecuredApiKey.ts#L8
which uses this:
https://github.com/algolia/algoliasearch-client-javascript/blob/e6dec843932bdfaac13ffa1e0a11964975499078/packages/transporter/src/serializer.ts#L22-L35
And thus is left as-is, and will accept any object


6.16

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

@conda-forge/core how to add -lrt to the link-libraries? i tried with  LDFLAGS="${LDFLAGS} -lrt" but this didn't resolve the issue:
min_unit_test.cpp:(.text._ZNK5boost9unit_test5timer5timer7elapsedEv[_ZNK5boost9unit_test5timer5timer7elapsedEv]+0x43): undefined reference to `clock_gettime'

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

I've hacked around the SSL issue locally and have code downloading and trying to build for 6.16 but I'm running into:
$SRC_DIR/src/PluginInterface.cpp: In member function 'void Dakota::PluginInterface::load_plugin()':
$SRC_DIR/src/PluginInterface.cpp:114:35: error: 'import' is not a member of 'boost::dll'
  114 |     pluginInterface = boost::dll::import<DakotaPlugins::DakotaInterfaceAPI>
      |                                   ^~~~~~

Looking at the cmdline, I don't see a -I for boost headers and I see -D Boost_NO_BOOST_CMAKE:BOOL=ON in the cmdline to cmake.  I'm looking into this.

Somewhere between Boost 1.64 and latest, boost::dll::import() was renamed(?) possibly to boost::dll::import_symbol().

This is fixed in latest Dakota at https://github.com/snl-dakota/dakota/blob/12f268404201e9b9a63eb600e76494776ff1fba5/src/PluginInterface.cpp#L16-L22

Now it's building but failing due to a dynamic symbol lookup failure at https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=616377&view=logs&j=d0d954b5-f111-5dc4-4d76-03b6c9d0cf7e&t=841356e0-85bb-57d8-dbbc-852e683d1642&l=15409
dakota: symbol lookup error: /home/conda/feedstock_root/build_artifacts/dakota_1669070970926/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/bin/../lib/./libscolib.so: undefined symbol: _ZNK6utilib10CharString10alloc_sizeEm

I'm building locally again so that I can sort this out.

Well, looks like libutillib.so is being packaged and installed by dakota.
(/home/conda/feedstock_root/build_artifacts/dakota_1669075745146/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold) conda tree who-owns /home/conda/feedstock_root/build_artifacts/dakota_1669075745146/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/lib/libutilib.so
dakota lib/libutilib.so

And if I run ldd on dakota, I see that the loader is finding it:
(/home/conda/feedstock_root/build_artifacts/dakota_1669075745146/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold) ldd $(which dakota) | grep libutil
	libutilib.so => /home/conda/feedstock_root/build_artifacts/dakota_1669075745146/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/bin/../lib/./libutilib.so (0x00007f6fee1fe000)

And nm seems to see the 'missing' symbol:
(/home/conda/feedstock_root/build_artifacts/dakota_1669075745146/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold) nm /home/conda/feedstock_root/build_artifacts/dakota_1669075745146/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/bin/../lib/./libutilib.so | grep CharString | grep alloc_size
000000000006c750 t _ZNK6utilib10CharString10alloc_sizeEm
00000000000a70e0 t _ZNK6utilib9ArrayBaseINS_10CharStringENS_10BasicArrayIS1_EEE10alloc_sizeEm

So... I'm confused about what the heck is happening here.  I'm going to try running dakota -i UQ.in in the build directory to see if this works before the packaging happens and maybe that will shed some light on what's going on.

It also happens before packaging, so it isn't that conda-build is breaking something or something isn't being installed.

Running LD_DEBUG=all dakota -i UQ.in I see the loader looking in libutilib.so and not finding the symbol

 LD_DEBUG output
It searches the correct library in the line before libm
25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=dakota [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libdakota_src.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libnidr.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libpecos_src.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libsurfpack.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libapproxnn.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libqueso.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libconmin.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libddace.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libdream.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libfsudace.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libhopspack.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libjega_fe.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libncsuopt.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libcport.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libnomad.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/liboptpp.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libpsuade.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libamplsolver.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libpython3.10.so.1.0 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libhdf5_hl.so.200 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libhdf5_cpp.so.200 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libgsl.so.25 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/liblapack.so.3 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libteuchoscomm.so.13 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libteuchoscore.so.13 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libstdc++.so.6 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libgcc_s.so.1 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/lib64/libc.so.6 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libdakota_src_fortran.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libboost_filesystem.so.1.78.0 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libboost_serialization.so.1.78.0 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libdakota_surrogates.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libcolin.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libinterfaces.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libscolib.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libteuchosnumerics.so.13 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libteuchosparameterlist.so.13 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libpebbl.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libutilib.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/lib64/libm.so.6 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libpecos_util.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/liblhs.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libdfftpack.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libsparsegrid.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libsurfpack_fortran.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libgfortran.so.5 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libmoga.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libsoga.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libeutils.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libjega.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libutilities.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libblas.so.3 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/lib64/libpthread.so.0 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/lib64/libdl.so.2 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/lib64/libutil.so.1 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/lib64/librt.so.1 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/./libhdf5.so.200 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/./libcrypto.so.3 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/./libcurl.so.4 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/./libz.so.1 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/./libcblas.so.3 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/./libgomp.so.1 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/./libquadmath.so.0 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/lib64/ld-linux-x86-64.so.2 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/./libboost_atomic.so.1.78.0 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libdakota_util.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libtinyxml.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/lib3po.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libteuchosparser.so.13 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/liblhs_mods.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/liblhs_mod.so [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/././libnghttp2.so.14 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/././libssh2.so.1 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/././libssl.so.3 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/././libgssapi_krb5.so.2 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/./././libkrb5.so.3 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/./././libk5crypto.so.3 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/./././libcom_err.so.3 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/./././libkrb5support.so.0 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/./././libkeyutils.so.1 [0]
     25081:	symbol=_ZNK6utilib10CharString10alloc_sizeEm;  lookup in file=/lib64/libresolv.so.2 [0]
     25081:	/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libscolib.so: error: symbol lookup error: undefined symbol: _ZNK6utilib10CharString10alloc_sizeEm (fatal)

And then I can see the symbol in one of the libraries where it is looking:
(/home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_build_env) nm /home/conda/feedstock_root/build_artifacts/dakota_1669142020167/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_plac/lib/libutilib.so | grep _ZNK6utilib10CharString10alloc_sizeEm
000000000006c750 t _ZNK6utilib10CharString10alloc_sizeEm

I'm obviously not understanding something correctly here.

Removing -fvisability-inlines-hidden from CXXFLAGS fixes the dynamic linking issue but then I hit a signature difference in rosenbrock() in the simple UQ.in test:
(/home/conda/feedstock_root/build_artifacts/dakota_1669156575234/_build_env) ./src/dakota -i UQ.in
Dakota version 6.16 released May 16 2022.
Repository revision 43c9862b3 (2022-05-06) built Nov 22 2022 22:45:09.
Running MPI Dakota executable in serial mode.
Start time: Tue Nov 22 23:48:32 2022

-----------------------
Begin DAKOTA input file
UQ.in
-----------------------
environment
    tabular_data
        tabular_data_file = 'rosenbrock_uq_sampling.dat'

method
    sampling
        sample_type lhs
        samples = 1000
        seed = 98765
        response_levels = 0.5

variables
    normal_uncertain = 2
        descriptors   = 'x1' 'x2'
        means         =  0.  0.
        std_deviation =  0.1  0.1

interface
    python
        numpy
        analysis_drivers = 'rosenbrock:rosenbrock'

responses
    response_functions = 1
    no_gradients no_hessians
---------------------
End DAKOTA input file
---------------------

Using Dakota input file 'UQ.in'
Writing new restart file 'dakota.rst'.
Python interpreter initialized for direct function evaluation.

>>>>> Executing environment.

>>>>> Running random_sampling iterator.

NonD lhs Samples = 1000 Seed (user-specified) = 98765

---------------------
Begin Evaluation    1
---------------------
Parameters for evaluation 1:
                      9.0615228786e-02 x1
                      9.9027992279e-02 x2

Pybind11 interface: invoking rosenbrock:rosenbrock
Error evaluating Python analysis_driver rosenbrock:rosenbrock:
TypeError: rosenbrock() takes 0 positional arguments but 1 was given
Failure captured: aborting due to failure in evaluation 1...

@looooo I've pushed changes that should show the rosenbrock call error in CI.  It looks like you added that test back in #9.  I'm starting to learn about Dakota and don't really know enough yet to understand how to update that test.  Do you know what needs to be done?

@looooo I've pushed changes that should show the rosenbrock call error in CI. It looks like you added that test back in #9. I'm starting to learn about Dakota and don't really know enough yet to understand how to update that test. Do you know what needs to be done?

Thanks for your efforts. Maybe the Rosenbrock function needs to be updated. Maybe the interface has changed. Can you try adding a **args to the rosenbrock function?

Interesting.  When I added *args to the rosenbrock function locally, I got a KeyError saying that stuff wasn't in **kwargs that we expected but the latest CI hits a segfault...
I'm going to look at what I did again.  I may have been trying to run our UQ.in with the pre-built 6.16 Dakota I downloaded from Sandia and hit the KeyError.

Looking at other direct python tests in my local build, it seems like they stopped using **kwargs and instead expect one arg passed that is a dict that looks the same as **kwargs used to.  I'm going to push that change to the rosenbrock and see if it works.
see https://github.com/snl-dakota/dakota/blob/6.16/test/driver_text_book.py#L14-L17

I see that we're still getting a segfault.  I'm going to run the build locally and see if I can reproduce and debug the segfault. 😞

I was able to reproduce it with Dakota built with debug info and generated the following stacktrace:
(/home/conda/feedstock_root/build_artifacts/dakota_1669254287311/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold) gdb $(which dakota) ./core.12514
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-conda-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/conda/feedstock_root/build_artifacts/dakota_1669254287311/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/bin/dakota...
[New LWP 12514]
[New LWP 12518]
[New LWP 12519]
[New LWP 12516]
[New LWP 12515]
[New LWP 12521]
[New LWP 12517]
[New LWP 12520]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `dakota -i UQ.in'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fe89053792f in dmax_ () from /home/conda/feedstock_root/build_artifacts/dakota_1669254287311/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/bin/../lib/liblapack.so.3
[Current thread is 1 (Thread 0x7fe88c150780 (LWP 12514))]
(gdb) bt
#0  0x00007fe89053792f in dmax_ () from /home/conda/feedstock_root/build_artifacts/dakota_1669254287311/_test_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold/bin/../lib/liblapack.so.3
#1  0x00007fe88de6dec9 in normal (j=1, idt=2) at /home/conda/feedstock_root/build_artifacts/dakota_1669254287311/work/packages/external/LHS/Normal.f90:207
#2  0x00007fe88de80999 in lhs_run (maxvar=2, maxobs=1000, maxnam=2, ierror=0, lstname=..., indxnam=..., ptvalst=..., numnam=2, smatx=..., numvar=2, rmatx=..., rflag=0, _lstname=0) at /home/conda/feedstock_root/build_artifacts/dakota_1669254287311/work/packages/external/LHS/Lhs_run.f90:140
#3  0x00007fe897b709fe in Pecos::LHSDriver::generate_samples (this=this@entry=0x55a1623037c8, random_vars=..., corr=..., num_samples=num_samples@entry=1000, samples=..., sample_ranks=..., active_vars=..., active_corr=...) at /usr/local/src/conda/dakota-6.16.0/packages/external/trilinos/packages/teuchos/numerics/src/Teuchos_SerialDenseMatrix.hpp:258
#4  0x00007fe89865d0ee in Dakota::NonDSampling::get_parameter_sets (this=this@entry=0x55a162301c00, model=..., num_samples=num_samples@entry=1000, design_matrix=..., write_msg=write_msg@entry=true) at /usr/local/src/conda/dakota-6.16.0/src/NonDSampling.cpp:324
#5  0x00007fe898663190 in Dakota::NonDSampling::get_parameter_sets (design_matrix=..., num_samples=1000, model=..., this=0x55a162301c00) at /usr/local/src/conda/dakota-6.16.0/src/NonDSampling.hpp:525
#6  Dakota::NonDLHSSampling::pre_run (this=<optimized out>) at /usr/local/src/conda/dakota-6.16.0/src/NonDLHSSampling.cpp:276
#7  0x00007fe89852e7eb in Dakota::Iterator::run (this=<optimized out>) at /usr/local/src/conda/dakota-6.16.0/src/DakotaIterator.cpp:1058
#8  0x00007fe8980d492c in Dakota::IteratorScheduler::run_iterator (sub_iterator=..., pl_iter=...) at /usr/local/src/conda/dakota-6.16.0/src/IteratorScheduler.cpp:429
#9  0x00007fe89851b0d2 in Dakota::Environment::execute (this=0x7fff7be99800) at /usr/local/src/conda/dakota-6.16.0/src/DakotaEnvironment.cpp:318
#10 Dakota::Environment::execute (this=this@entry=0x7fff7be99800) at /usr/local/src/conda/dakota-6.16.0/src/DakotaEnvironment.cpp:291
#11 0x00007fe89851b213 in Dakota::ExecutableEnvironment::execute (this=0x7fff7be99800) at /usr/local/src/conda/dakota-6.16.0/src/ExecutableEnvironment.cpp:70
#12 0x000055a16189412f in main (argc=3, argv=0x7fff7be9b798) at /usr/local/src/conda/dakota-6.16.0/src/main.cpp:54

Since the segfault is happening deep in the guts of of liblapack, called from fortran code, I'm a bit out of my depth here but I'll keep looking.  I suspect that build-time and test-time may be using incompatable liblapack somehow?

Thanks @looooo .  Are (7) and (9) referring to gcc versions or #7 and #9?

Sry. 7 / 9 referral to the GCC version.

Well, of course, making the build BLAS-specific enables it to not segfault like it is.  I'm going to push my changes that add host dep on {{ blas_impl }} and see if all of the builds succeed in CI.  I'm also going to revert the workaround for SSL on sandia.gov because they say it should be fixed.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Failed to even lint the recipe, probably because of a conda-smithy bug :cry:. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint . from the recipe directory.

Looks like the linter has stuff to substitute {{ c_compiler }} with c_compiler_stub for linting but the same type of thing doesn't exist for {{ blas_impl }}.  I'm going to PR a fix for it in case we end up wanting to use the matrix build of specifically built BLAS implementations.

The reversion of the SSL workaround dropped my new patch.  Pushing that now.

With the changes in https://github.com/timsnyder/conda-smithy/commit/687542e80ba41d543ca986beb364cdad03fca6cd and changing about.license to LGPL-2.1-or-later, the recipe lints cleanly.
I'm waiting to push the SPDX identifier change so that the current CI builds can finish or fail.  It looks like only openblas works.  First of all, blis doesn't seem to have an implementation of liblapack?  I haven't looked at the MKL failures yet but I will later.

Well, looking at the creation of the host-env and cmake output, I see some problems:

openblas versions of libblas are installed into host env I don't completely understand why openblas is selected there
MKL is a 'TPL' that isn't enabled in the build.  So, to enable MKL in Dakota, we'd likely need to tweak the cmake parameters

I'm going to poke around a little bit more before I just restrict it to openblas.

blis doesn't seem to have an implementation of liblapack?

Trying to install numpy using blis looks like it grabs the _netlib liblapack?  I thought the netlib packages were only reference headers but I guess they are more than that.  I'm going to try to see if not specifying blas_impl with liblapack will make the blis build work.

@isuruf could you re-review this and potentially help merge conda-forge/conda-smithy#1702 so that conda-forge-linter will pass here?
It seems to me like a runtime segfault when using dakota built against the netlib reference implementation that goes away when doing the matrix build against the specific BLAS implementations is a legit reason to do the matrix build.  If I get some time I might try to debug the segfault more but I'd prefer to merge this and move on to updating for the 1.17 release.

I've already debugged this issue. See https://github.com/conda-forge/openblas-feedstock/issues/84

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

I've already debugged this issue.

@isuruf, thanks for the pointer to https://github.com/conda-forge/openblas-feedstock/issues/84.  Reading through that issue, I'm unclear on whether you think we should just build Dakota using the matrix of actual {{ blas_impl }} instead of using the netlib reference lib to build once or if you think we should do something else here.
I'm thinking that you probably mean that we should do the matrix build but I'd appreciate you confirming before we merge this.  Thanks.

@timsnyder can we merge this one?

Coming here to help move the HDF5 migration forward.
You might want to rerender because I updated the HDF5 pinning. https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/3948

@looooo OOPS!  I completely missed this over the holidays and have been buried with other work the last few months.  I'm going to rerender, see if this can merge and also try to get 6.17 straightened out.


CI: build windows, add artifacts to release

Build Windows binaries in CI, add all artifacts to release (when CI is triggered by a tag) so they are more easily accessible.
Mostly adapted from this article.
I have renamed the artifacts so its more apparent which version does what (I was confused about the difference between manager and manager_dart at first):

manager_gui_macos.zip (macOS automatically renames the file ".zip" when downloading anyway)
manager_gui_linux.tar.gz
manager_cli_linux
manager_gui_windows.zip

If this is not desired the names can be reverted of course.
See my test-release

Good job!


Am looking to have a single horizontal bar ..if you could add that instead of a stacked multi chart that will be great

i have added the image of the chart am looking for , if you can help me out that will be great

@pendliforu https://github.com/chartjs/Chart.LinearGauge.js might be useful for you. It's an extension for Chart.js v1.0

@pendliforu I just did this using the extension mentioned by @etimberg and it worked a treat. To get the style you want you need something like this for the data:
{
	value: 7000,
	color: "#56b2e3",
	width: 25,
	offset: 0
}

Where width is actually the bar height. To get the background colour on the bar (the dark blue in your picture) use:
{
    axisWidth: 25,
    axisColor: "#444396"
}

in the chart settings.

We're looking to have horizontal bar charts as an option in v2.0 very soon.  If you would like to contribute, please send a PR.


free toposort cache after it goes out of scope [pr]

Interesting. I still don't understand why the other one doesn't work, I suspect it's an antipattern we use in other places. My expectation is that when the function goes out of scope the lru_cache is cleared.

Seems to be something related to how python deals with closures.
gpt wrote this to explain it to me:
import inspect

def outer_function(x):
  def inner_function(y):
    return x + y
  return inner_function

closure = outer_function(10)
print(closure(5)) # 15
print(inspect.getclosurevars(closure)) # ClosureVars(nonlocals={'x': 10}, globals={}, builtins={}, unbound=set())

Having Buffers on uop is such a good stress test for gc we've found like 3-4 bugs in ops just from this xd.


Custom Stringifier

This PR adds a more customized stringifier, which writes to a buffer in memory, instead of directly to a file. This way simplify can round numbers as strings, and use custom strings for special values.
Changes:

Custom Infinity & NaN strings (no more @inf@ and @nan@)
Infinity and NaN builtin constants
Fine rounding (3.9 = 3.9, not 3.899999999999999911182158029987476766109466552734375)
Compare numbers using the rounded strings.
Comparisons between expressions (x2 = x + x results in true now)
When expression_fprint is called it writes into a buffer, then prints the buffer to a file.
Correctly compare Inf and NaN (-NaN = 1 is now false. -Inf = +Inf is also false, and -Inf < +Inf is true)

Pull Request Test Coverage Report for Build 49

261 of 313 (83.39%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+5.6%) to 87.666%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/simplify/expression/stringify.h
17
20
85.0%

src/simplify/expression/evaluate.c
24
34
70.59%

src/simplify/expression/expression.c
109
120
90.83%

src/simplify/expression/stringify.c
111
139
79.86%

Totals

Change from base Build 41:
5.6%

Covered Lines:
1187

Relevant Lines:
1354

💛  - Coveralls


Allow gateway-api to function without Kubernetes RBAC

This implements most of
https://docs.google.com/document/d/1gDhj058q2PKKI9SWpxE23ExEXdOkLiueT8JA_oEJ8Mo/edit#heading=h.bmkc9oooxqbj
Another PR will try to figure out the multicluster change
I tried to capture context in the comments in the code

Put a hold to add better tests

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
06a46d73dfcd6599b8bf0614f5d95e63f5257766
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
06a46d73dfcd6599b8bf0614f5d95e63f5257766
link
/test lint_istio

unit-tests_istio
06a46d73dfcd6599b8bf0614f5d95e63f5257766
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

unit-tests_istio
06a46d73dfcd6599b8bf0614f5d95e63f5257766
link
/test unit-tests_istio

lint_istio
a737eee88ccb295b8ae21d7ab90ddad00bd6488d
link
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

lint_istio
a737eee88ccb295b8ae21d7ab90ddad00bd6488d
link
/test lint_istio

unit-tests_istio
a737eee88ccb295b8ae21d7ab90ddad00bd6488d
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@howardjohn: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


Vulnerable Cancer Patients

Pull Request for ML-Crate 💡
Issue Title:  Issue No 498

Info about the related issue (Aim of the project) :
Name:  Keshav Arora
GitHub ID:  CoderOMaster
Idenitfy yourself:  JWOC 2024
Please Mark this as hard:)

I understand sir.
I will try my best to implement these

@abhisheks008
Please check i have done the necessary changes now

Thank you


add provideXxx() methods

And check for other new cool-kid things to add from https://angular.io/guide/standalone-components#standalone-components-for-library-authors

There are only 2 angular modules in s-libs, NasModelModule and SlDialogModule. The former packages several directives that should continue to feel like a single nasModel, so it is not a good candidate. I'll leave things in module form for now.