text:
Remove state-saving by default

Hotfix for #1091 and reports here. This PR makes it so that state is not automatically saved in a Chains object when sampling is completed -- people who want to resume the chain will have to explicitly plan ahead of time to resume sampling:
chain = sample(model, spl, N; save_state = true)

Please change prob"x = 1.0, y = 1.0 | chain = chain" to prob"x = 1.0, y = 1.0 | chain = chain, model = gdemo" in the docs, the guide.md file.

Or add both saying a word about the save_state kwarg.

@cpfiffer can you take a look at Mohamed's comment, and see whether we can fix them before merging?

Hi @yebai, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @yebai, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

@KDr2 Maybe reduce unnecessary replies (e.g. only reply to comments containing @BayesBot benchmark()  from the Benchmark bot?

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @yebai, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

This should be good to merge once the tests pass.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @BayesBot, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

Hi @yebai, I just got a benchmark command from you,
But I can't determine on which branches to run,
Please specify the branches in your command.

@KDr2 Maybe reduce unnecessary replies (e.g. only reply to comments containing @BayesBot benchmark() from the Benchmark bot?

OK :D


text:
Changes tests to use Docker containers

This basically works. I'm not sure it's got all the goodies, but it's got a few examples of how to run stuff inside the container should you need to. Closes #18

Lets just go with it and see where it gets us :)

source: gharchive/pull-request

authors: JJ Tux

repo: Tux/CSV

license_type: permissive

license_source: github-api


text:
✨[Feature] Agree on a file naming scheme

Is your feature request related to a problem? Please describe.
Currently we are naming our files using both camelCase and kebab-case.
Describe the solution you would like
We need to agree on one naming convention and stick to it.
Additional context
We'll rename the files when we have finished the MVP API on the backend and moved towards the frontend. This'll be done as to minimize merge conflicts.

I think upper CamelCase for constructors and lower camelCase for functions would be fine. However kebab-case is recommended for NPM packages, so if we wanted to refactor some modules into independent packages they would have to be renamed in kebab-case.

source: gharchive/issue

authors: Twaha-Rahman snowteamer

repo: Twaha-Rahman/e-commercify

license: MIT


text:
fix(updateElement): correctly remove previous properties

Fixes #22

I am not sure if setting them to '' is always desirable. This effectively leaves empty valued IDs and classes after removal:

authors: TylorS asabil


text:
Pluggable transformer design

LuaTransformer class now has a number of issues:

Ability to extend it isn't a plugin system - you can do it only once, you can override things you aren't meant to, we are limited with public/protected/private when designing visitor API
If you want to extend it, you always have to use it with API, so you also have to re-implement tstl even when you don't want to change anything there
5500 lines is too much

The idea is to make whole transformation be composed of plugins. A plugin is a function that receives context: TranspilerContext and returns an object. Context is an object with some state that may be passed to utility functions.
Project structure:

src/transformers

utils

index.ts
type-checks.ts
lua-ast-utils.ts
...

class.ts
call.ts
try.ts
...

Example transformer:
import { escapeString, isTupleReturnCall, isArrayType, createUnpackCall, transformLuaLibFunction } from "./utils";

export const someTransformer = (context: TranspilerContext): TranspilerPlugin => ({
    visitors: {
        [ts.SyntaxKind.StringLiteral]: node => escapeString(node.text),
        [ts.SyntaxKind.SpreadElement](node) {
            const innerExpression = context.transformExpression(node.expression);
            if (isTupleReturnCall(context, node.expression)) {
                return innerExpression;
            }

            const type = context.checker.getTypeAtLocation(node.expression);
            if (isArrayType(context, type)) {
                return createUnpackCall(innerExpression, node);
            }

            return transformLuaLibFunction(context, LuaLibFeature.Spread, node, innerExpression);
        },
    },
});

I'm archiving some of the discussion related to this issue on discord:
A possible way to achieve this design with mixins:
TypeScript playground demo
I still have to figure out what exactly are the pros and cons of this approach relative to the already suggested setup.
We also looked at a slightly different version to the code @ark120202 already provided above:
TypeScript playground demo
Personally I am not decided yet if I am happy with all transformation methods in a plugin hard-coupled to the same context. An alternative would be to pass the context to every transformation method as follows:
TypeScript playground demo
Further opinions/suggestions are always welcome!

repo: TypeScriptToLua/TypeScriptToLua


text:
Errors after 0.20.0 upgrade

upgrade 0.20.x
--excludeNotExported --ignoreCompilerErrors
I've been passed over some app which we need to maintain. They haven't had any maintenance for a few years and I'm in the middle of trying to update them to the latest packages. I've not used TypeDoc before and when we upgraded to 0.20.0 or higher we start hitting some errors which seem to be related to the switches --excludeNotExported --ignoreCompilerErrors which have now been depreciated. My question is what would be the alternative configuration to use now these have gone?
This is the configuration file we have been using since the upgrade:
typedoc.json
{
  "$schema": "https://typedoc.org/schema.json",
  "entryPoints": ["./src/index.tsx"],
  "out": "./docs",
  "excludeNotDocumented": true
}

I've also added the tsconfig.json as a command line to TypeDoc:
tsconfig.json
{
  "include": ["src", "types", "test"],
  "compilerOptions": {
    "target": "es5",
    "module": "esnext",
    "lib": ["dom", "esnext"],
    "importHelpers": true,
    "declaration": true,
    "sourceMap": true,
    "rootDir": "./src",
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true,
    "strictPropertyInitialization": true,
    "noImplicitThis": true,
    "alwaysStrict": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "noImplicitReturns": true,
    "noFallthroughCasesInSwitch": true,
    "moduleResolution": "node",
    "baseUrl": "./",
    "paths": {
      "@": ["./"],
      "*": ["src/*", "node_modules/*"]
    },
    "jsx": "react",
    "esModuleInterop": true
  }
}

Example of errors now appearing which aren't there pre 0.20.0:
node_modules/@aws-sdk/client-lex-runtime-service/dist-types/LexRuntimeServiceClient.d.ts:7:30 - error TS2305: Module '"@aws-sdk/smithy-client"' has no exported member 'DefaultsMode'.
7 import { Client as __Client, DefaultsMode, SmithyConfiguration as __SmithyConfiguration, SmithyResolvedConfiguration as __SmithyResolvedConfiguration } from "@aws-sdk/smithy-client";
~~~~~~~~~~~~
node_modules/@aws-sdk/client-lex-runtime-service/dist-types/models/LexRuntimeServiceServiceException.d.ts:1:10 - error TS2305: Module '"@aws-sdk/smithy-client"' has no exported member 'ServiceException'.
1 import { ServiceException as __ServiceException, ServiceExceptionOptions as __ServiceExceptionOptions } from "@aws-sdk/smithy-client";
~~~~~~~~~~~~~~~~
Thanks
Ed

excludeNotExported

No longer necessary since 0.20, typedoc only documents exports.

ignoreCompilerErrors

Using this is dangerous, the compiler doesn't follow its api contracts when there are compiler errors, so this can result in crashes.
Issues with undefined types in declaration files should be suppressed with TypeScript's skipLibCheck option if possible. If not possible, you could use TypeDoc's skipErrorChecks option with the caveat that any issues encountered when using that option are officially unsupported and will not be fixed.

repo: TypeStrong/typedoc

license_source: bigquery


text:
chore: Read @typeform packages from Github

Embed lib does not have any proprietary @typeform packages as dependency. It installs @typeform/jarvis in Travis CI for deployment but it is not saved.

Very nice!

But what would happen when we publish a new version? Do we have an NPM token in this shared config?

[BOT] Preview available: https://embed.typeform.com/01ae696d69ae2f65863cfd843988e29f1a359f21/embed.js

[BOT] Preview available: https://embed.typeform.com/ba4da76cbb78921a8543e29b15a69ef352a0bce0/embed.js

[BOT] Preview available: https://embed.typeform.com/bf87ea0e52500aa2a6ff6cbc784a7d16fec6e786/embed.js

[BOT] Preview available: https://embed.typeform.com/c4491aa2970c8336e4da0e745d9f2c860f071458/embed.js

[BOT] Preview available: https://embed.typeform.com/290aaa4b2f9735900f4787698ab77b39554d9e20/embed.js

[BOT] Preview available: https://embed.typeform.com/db1f2155b98202b09b1df92f9a87c68cefaaa0cf/embed.js

[BOT] Preview available: https://embed.typeform.com/f26f5125ff6db8687de43f0717eb5968c4ea925d/embed.js

[BOT] Preview available: https://embed.typeform.com/4e26183c4b3addcdf7996f6b47be3f376d52e565/embed.js

[BOT] Preview available: https://embed.typeform.com/974ecdee933580638488ebacb9d6422ac812143a/embed.js

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: mathio prilutskiy travis-tf

repo: Typeform/embed


text:
fix: eatContextual method and reduce keywords

This PR fixes the eatContextual method to reduce unnecessary overriding keywords.
I noticed that the eatContextual method is not working properly. This PR fixes it.
      eatContextual(name: string) {
        if (keywordsRegExp.test(name)) {
          if (this.ts_isContextual(tokTypes[name])) {
            this.next()
            return true
          }
          return false
        } else {

-          super.eatContextual(name)
+          return super.eatContextual(name)
        }
      }

Also, by correcting the eatContextual method, I was able to reduce the overriding keywords, and in doing so I was able to remove the isContextual method from the override. This PR does that too.

Codecov Report
Patch coverage: 57.14% and project coverage change: -0.06 :warning:

Comparison is base (6f0f1ae) 62.56% compared to head (d280912) 62.50%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##           master      #18      +/-   ##
==========================================
- Coverage   62.56%   62.50%   -0.06%
==========================================
  Files           1        1
  Lines        2941     2923      -18
  Branches      967      959       -8
==========================================
- Hits         1840     1827      -13
+ Misses       1094     1089       -5
  Partials        7        7

Impacted Files
Coverage Δ

src/index.ts
62.50% <57.14%> (-0.06%)
:arrow_down:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

I now realize that, this change fixes the bug without having to merge #17. Because async is no longer a keyword.

authors: codecov-commenter ota-meshi

repo: TyrealHu/acorn-typescript


text:
Skeleton

Added Jiwei and Arushi's plots and reformatted how the app looks.

Great work @voremargot !! App looks great!!


text:
[MS4] Lisa's Tasks

Fixes

[x] Change the colour scheme of the tree graph so that numbers are visible against square

Improvements

[x] Improve theme of the app (colour and fonts) or include a dark mode (that can be switched to using a radio button)

Testing

[x] Include at least 3 tests created with the package shinytests2

Reflection

[x] Document what you have implemented in your dashboard so far and explain what is not yet implemented (in docs/reflection-milestone4.md)

Completed all tasks as per PR #68

authors: LisaSeq shlrley

repo: UBC-MDS/VanArt


text:
Feedback

Hi Team,
Great job with your dashboard. My teammates and I were discussing your work and we found the idea behind your application is quite interesting are closely related to the rising mental concerns in the society now. The usage scenario in your proposal has articulated your idea very well.
Congrats, for putting up an awesome app.
Here is what we all liked about your application:

The layout of your graphs and global filters looks very nice.
The App sketch gives a clear description of the functionalities of your application
We liked the vast range of interactive options provided.
We also liked the way you are hiding the line plot when we clear the countries drop down.

Here is some improvements that we think may be helpful to your application:

There is a scroll bar in your graph, you may want to resize the frame or the graph to get rid of it
The year on your x-axis is now showing vertically, which could be hard to read. Maybe you would want to change the angle of it
Selecting the country doesn't see to make a difference in the dashboard, maybe we are missing something here, but a clear difference after changing the selection might be more helpful.
You may use a different color for the reset button and top 10 countries list.

Overall, you have done an amazing job and we all wish you the best with the final milestone.
Best regards,
DSCI532 Group4

Hi Debananda and team!
Thank you so much for the feedback, we've taken it into consideration!
Specifically:

Resized graphs to remove the scroll bar
Fixed the plots so that the axes are easy to read
Selecting countries has been implemented!
Color scheme and overall layout has been addressed

You can check out our new app here or from our new GitHub page here

authors: debanandasarkar rachelywong


text:
Implement imputer() function and add unit test for imputer()

[x] Code for imputer() function implementation
[x] The function should be written defensively. That is, it should handle incorrect input and errors detected during execution via throwing exceptions with useful error messages, and there should be tests to confirm that the exceptions result in the expected behaviour of the function.

PR: https://github.com/UBC-MDS/eda_utils_py/pull/26


text:
Fix auto-version update

Hi team, Tiffany has provided a fix to update the version accordingly every time we commit with a keyword and it doesn't have to start from 0.0.1. We can implement the suggested suggestions and test if they also work for our case.

Link to fix this issue - https://ubc-mds.slack.com/archives/C24GEK3PV/p1706574549274769

I have tried the steps suggested by tiffany. Let us see if it works.

This seems to work. Closing the issue!


text:
pixl-dcmd installation does not work as described in the documentation

Definition of Done / Acceptance Criteria
https://github.com/UCLH-Foundry/PIXL/blob/main/pixl_dcmd/README.md  describes a working installation procedure.
Testing
Follow the installation procedure defined in the README.
Documentation
No response
Dependencies
No response
Details and Comments
pip install -e ../../pixl_core/ . assumes that the user is in pixl_dcmd/src but this is not indicated.  When running in src the installation fails because setup.py imports pixl_dcmd which imports requests which is not installed at the time.  Consider:

moving pip install -r requirements.txt above pip install .
stop getting the version number in setup.py by importing pixl_dcmd

Hold this until #255 is complete

repo: UCLH-Foundry/PIXL


text:
evan-fixes-2023-06

a batch of small fixes/improvements

The change to CMI_CACHE_LINE_SIZE could fix issue #3469

The change to CMI_CACHE_LINE_SIZE could fix issue #3469

That's what I hoped too, but unfortunately it does not.

repo: UIUC-PPL/charm


text:
Fix communication over time display issues

Only allow data to be displayed in per second
rates and show correct label on y-axis

Why did you change the data being displayed to total (instead of rate), but then changed the labels from total to rate? Shouldn't the labels have remained the same? Otherwise, the rest of it seems sound.

I didn't change the data being displayed to total, it's still displaying rate, it's just that it's only allowing rates to be shown per second now, not per ms or us as before.

Ah nevermind. What I was seeing was the total that is displayed at the bottom of the screen, not the value on the y-axis.

authors: epmikida rbuch

repo: UIUC-PPL/projections


text:
Update scala-library to 2.13.11

About this PR
📦 Updates org.scala-lang:scala-library from 2.13.10 to 2.13.11
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

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

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-lang", artifactId = "scala-library" }
}]

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

Superseded by #24.

repo: UKHomeOffice/bluebus


text:
Polymorphic serialization fails in clang with -fvisibility-inlines-hidden

I have encountered a strange issue where polymorphic serialization fails when using shared linking with clang 3.8.0. The following is a minimal working example:
File FooBar.h:
#pragma once

#include <cereal/archives/binary.hpp>
#include <cereal/types/base_class.hpp>
#include <cereal/types/polymorphic.hpp>

class Foo {
 public:
  virtual ~Foo() = default;

  template <class Archive>
  void serialize(Archive& ar) {}
};

class Bar : public Foo {
 public:
  template <class Archive>
  void serialize(Archive& ar) {
    ar(cereal::base_class<Foo>(this));
  }
};

CEREAL_REGISTER_TYPE(Bar);

File FooBar.cpp:
#include "FooBar.h"

File main.cpp:
#include <fstream>
#include <memory>

#include "FooBar.h"

int main() {
  std::shared_ptr<Foo> obj;
  obj = std::make_shared<Bar>();
  std::ofstream file("/tmp/foobar.bin", std::ios::binary);
  cereal::BinaryOutputArchive ar(file);
  ar(obj);
}

Compile and run with:
clang -O0 -std=c++11 FooBar.cpp -I./cereal/include -shared -o libfoobar.so -fPIC -fvisibility-inlines-hidden
clang -O0 -std=c++11 main.cpp -I./cereal/include -lstdc++ -L. -lfoobar -ocereal_test
LD_LIBRARY_PATH=. ./cereal_test

The following error is outputted:
terminate called after throwing an instance of 'cereal::Exception'
  what():  Trying to save an unregistered polymorphic type (Bar).
Make sure your type is registered with CEREAL_REGISTER_TYPE and that the archive you are using was included (and registered with CEREAL_REGISTER_ARCHIVE) prior to calling CEREAL_REGISTER_TYPE.
If your type is already registered and you still see this error, you may need to use CEREAL_REGISTER_DYNAMIC_INIT.
Aborted (core dumped)

Note that the issue still occurs if:

CEREAL_REGISTER_POLYMORPHIC_RELATION is used
and/or CEREAL_FORCE_DYNAMIC_INIT / CEREAL_REGISTER_DYNAMIC_INIT are used.

And the issue does not occur if:

the flag -fvisibility-inlines-hidden is not specified
or gcc 5.4.0 is used instead of clang.

The issue goes away if in the file include/cereal/details/static_object.hpp the method StaticObject::create() is annotated with __attribute__ ((visibility("default"))).

@jcai1 switch to develop branch, it already has fix for that.

repo: USCiLab/cereal


text:
(3) MdisSensorModel: create imageToProximateImagingLocus

fill out imageToProximateImagingLocus in MdisSensorModel

What does the SET do with this method?

Right now it calls the imageToRemoteImagingLocus() method. It ignores the EcefCoord parameter.

authors: ihumphrey-usgs makaylas

license: unlicense


text:
Added ground-to-image notebook using vector math.

Tested it with (undistorted) 512,512 and 100,100.
Ping me on gitter if you have any questions.
Process to get XYZ values for a specific Line,Sample:

Modify MdisNacSensorModel::imageToGround to not use the distortion model (comment out the setFocalPlane() call).
Modify MdisNacSensorModelTest imageToGround1 with the line,sample you want.
Re-make.
Run the tests (./runTests).
The non-truth output for imageToGround1 test shows the resulting XYZ.
Update the notebook to use that XYZ as input to its groundToImage function.

This looks really sweet!  +100.  I am digesting now.

authors: ihumphrey-usgs jlaura


text:
Exploratory Data Analysis for Reach and Gage Features, and Streamflow Metrics

Explore NHD (reach) attributes, GAGES2.1 (site) attributes, and streamflow metrics

spatial coverage of the attributes in our regions of interest
identification and investigation of rogue/outlier data
visualization of features and flow metrics on maps of reaches for each region

Can make feature maps and analyses for all reaches and compare to only those reaches with GAGES2.1 sites. This relates to issue #31.
Covers project Task 3.1: Visualize predictors (watershed attributes) and responses (flow metrics) by making exploratory maps and figures (check data quality, identify errors, etc.)

Function that can be modified for attribute and metric visualizations: violin plot + map
https://github.com/USGS-R/drb-inland-salinity-ml/blob/main/3_visualize/src/plot_nhdv2_attr.R

@jds485  I'm getting started on this and have some code to produce the maps and violin plots of the metrics by cluster, but we have a lot of different metric and cluster targets now and I'm not exactly sure which  of these I should be using.  For metrics we have p1_HIT_metrics, p1_FDC_metrics, p1_FDC_metrics_season, p1_FDC_metrics_season_high, then for clusters targets, we have p3_gages_clusters, p3_gages_clusters_quants, p3_gages_clusters_quants_agg, and p3_gages_clusters_quants_agg_selected.  Do we need to look at all of these different clusterings or just the _selected?

Thanks for checking. p1_FDC_metrics and p1_HIT_metrics are the period of record metrics that we'll predict.
p3_gages_clusters_quants_agg_selected is the target with columns for 5 clusters (_k5 at the end of the column name). We'll use those clusters for model regions.

Let's use the 0.5-0.7 clusters for ma1', 'ml17', and 'ml18'. Most of the other HIT metrics are for 75th percentile flows, and rise/fall rates are not really dependent on quantile so I think the rest of the metrics can be grouped with the 0.75-0.95 clusters.

repo: USGS-R/regional-hydrologic-forcings-ml


text:
App to help pick sites.

First.... you'll need to pick the "normalized_streamdata.rds" file, then the "all_sites.rds" file. Maybe (probably) in the future, we can make this even more automated.

Note because of our conversation on Slack: Talked about potentially moving this into vizstorm-GIF once it's more formalized. For now, it's can be used as a resource from here.

Is the problem the snake case? Or just the folder name isn't descriptive enough?

😬 no, I just am seeing things. You're good - I thought the files were named vizstorm_app-server etc and didn't see vizstorm_app as the folder name. OY! Nevermind me. Merging!

authors: ldecicco-USGS lindsaycarr

repo: USGS-VIZLAB/viz-scratch


text:
Visualizing input TSDFs and grasp

Hi,
I'm trying to obtain:

TSDFs: A 3D visualization of the input TSDFs.
Grasp affordance: The visuals of the grasp affordance are not getting logged under the data/experiments/<>/meshes folder. There are no files with <name>_aff.obj> getting logged/saved (although the scenes are still getting saved as  <name>_aff.obj> .

Please let me know what I can do achieve the above.

Hey,

Thanks I’ll try that out!
I did use the —vis command but as I explained above, no affordance related files get saved as obj. [Btw, I’m using the pretrained giga model on piles dataset]

Works!
I have used --vis command and the following:
a. In clutter_removal.py: Tried saving to different path inside thelog_mesh, doesn't work
b. In clutter_removal.py: Added a line visual_mesh.export(f'newf/composed.obj', file_type='obj') in the loop, doesn't work

Hey,

Thanks I’ll try that out!
I did use the —vis command but as I explained above, no affordance related files get saved as obj. [Btw, I’m using the pretrained giga model on piles dataset]

Works! Thank you
Works, but I added a line in clutter_removal.py to export: `visual_mesh.export('path-to-save ',file_type='obj')

repo: UT-Austin-RPL/GIGA


text:
Directory shows officer information

If a club has officers on jupiter then it will list them on the club's directory page.
currently it doesn't show the president on the side or the officer list if there aren't any officers.
you can test this by looking at nebula to see a club with officers and any other club to see what it looks like without.

I fixed the alignment and changed the way it fetches the officers.

repo: UTDNebula/jupiter


text:
Should there be so many unlabelled areas?

I'm close to having a debugged version of blackstack working in docker containers on our fork of the project at https://github.com/BritishGeologicalSurvey/blackstack now.
However I'm seeing the annotator server fall over because the SQL JOIN is returning empty, the cause is that many of the areas in my set of test documents have not got labels - about 80% of them. Some of the test docs are intentionally low quality. Is this expected and is the best thing to do to limit the query to only labelled areas, or to track down the cause of no area labelling?

Is the join you are referring to this one - https://github.com/UW-Deepdive-Infrastructure/blackstack/blob/master/annotator/server.py#L197 ?

That's the one, it's the ON area_labels.area_id line that it fails to return data on ( without querying for the label and only up to the first join it ran ok)
I had roughly 1k labels for roughly 5k areas in the test set...

Interesting...that query is intended to fetch only the areas that have been labeled in order to show p values while tagging areas. Since it isn't a functional piece of the annotator it is safe to remove it if it is being problematic.
I'm assuming the labels you have for areas are stored in the area_labels table?

authors: jczaplew metazool

repo: UW-Deepdive-Infrastructure/blackstack


text:
Write documentation

[ ] Write sphinx documentation for the app.
[ ] Add docstrings for everything.

Added a user guide in #221

repo: UW-GAC/django-anvil-consortium-manager


text:
https://ubdanam.github.io/Portfolio/

https://ubdanam.github.io/Portfolio/

https://ubdanam.github.io/Portfolio/

Hi @UbdaNam  ,
Good job so far!
May I highlight the following:

The repo looks professional.:heavy_check_mark:
Your project looks awesome:heavy_check_mark:

STATUS: APPROVED :muscle::clap:
Congratulations! :tada:
Your project is complete!  It's time to merge it :shipit:

Optional suggestions

Please check the comment under the review.

Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers and Happy coding! :clap: :clap: :clap:
Feel free to leave any questions or comments in the PR thread and tag me @algerina if something is not 100% clear.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

If anything seems to be unclear to you, reach out and ask anything by commenting on this Pull Request and mention me as Algerina, I will receive a notification and will respond.
GitHub | LinkedIn | Twitter
Reviewed by Amel Khiri

authors: UbdaNam algerina

repo: UbdaNam/Portfolio


text:
Error 1101: An organization unit is required for this action

Hi, I encounter the above-mentioned error when I execute the command to get the UiPath asset. May I know if I have not provided any necessary information to execute the command?

Hello @josephchew02 this is a bug with the library. Will provide a fix soon.

Hi @rusanu . is it solved now? is OU supported now? thanks

authors: josephchew02 reesha-rsh rusanu

repo: UiPath/orchestrator-powershell


text:
🛑 Bio 34 is down

In ae48de4, Bio 34 (https://bio34.com/) was down:

HTTP code: 500
Response time: 8832 ms

Resolved: Bio 34 is back up in 4f71768.

repo: UnSeulT/upptime


text:
What are the packages required ?

Hello
Can you tell me what are the packages i have to install to run it?
Also,Can it run on Ubuntu??
Thanks

Please read README. This class required Boost and PCAP.
@lasdasdas is running this class in Ubuntu. Therefor, It is Yes.

repo: UnaNancyOwen/VelodyneCapture


text:
chore: support devcontainer

Hi all,
I added support for the devcontainer to the project. Devcontainer is a lightweight, reproducible development environment that runs inside a container, allowing developers to work on the project in a consistent environment regardless of their local setup.
I believe this will be a useful addition to the project, as it will make it easier for new developers to get up and running, and for everyone to ensure that their development environment is consistent.
Please let me know what you think, and if there are any issues or concerns.
Thanks!
resolve #21

I intend to merge this pull request as it includes important details regarding setup instructions.
Failure to include this information may cause confusion for other contributors.

repo: UniCourse-TW/Backend


text:
Expose dispatch layer so that users can add their own local binary format

Introduction
In order to enable the HYCOM model to be updated to the netCDF API, and to provide a general capability to users, I propose to expose the netCDF-C dispatch layer so that users can add their own local format. This feature, already available in the netCDF-C library internals, is not currently exposed to users.
Background
HYCOM Model and Data Format
The HYCOM modeling team would like to upgrade their model to netCDF, in part to take advantage of the ParallelIO libary, which provides a standard way to ensure good performance in the I/O layer, specifically in the case of asynchronous I/O to a subset of processors using parallel I/O to write to disk.
Many legacy tools have been written based on the existing HYCOM native binary format ("AB Format") Converting the model to netCDF would break all existing tools, leading to loss of significant investment of time and effort, as well as disrupting work with a need to convert all necessary tools at the same time.
Providing and Upgrade Path for HYCOM
With the NetCDF-C dispatch layer exposed, an external plug-in can be provided for the netCDF-C library. Once this plug-in is in place, HYCOM programmers can convert model code to the netCDF API, while still reading and writing their local binary format.
All tools based on the netCDF-C library will transparently read the AB Format (including all tools in Fortran 77, Fortran 90, C++, Python, Perl, Mathmatica, etc.) These tools will also be able to write the AB Format with the netCDF API, allowing them to be converted one at a time.
This will give HYCOM modelers an upgrade path for their existing large code base of code which works with the local binary format. One by one, as time permits, these tools can also be upgraded to the netCDF API.
Eventually, when all tools are converted, the arguments of the nc_create commands in the HYCOM model can be changed to use one of the supported netCDF formats. All tools will transparently read netCDF files, and files in their local format. Historical data (in AB Format) will still be transparently available to netCDF programs. When a file is opened, the netCDF-C library will recognize it as an AB file, and use the plug-in code to read the file. User applications will be able to access the file through the netCDF API.
NettCDF-Java Plug-Ins
The netCDF Java library allows users to write a plug-in which allows them to support read/writes to their own binary format, through the netCDF Java API. The plug-in enables the netCDF library to read/write an arbitrary local format. This feature is widely used in the netCDF-Java community.
The proposed changes will bring this capability to the netCDF-C user community.
General Applicability for the NetCDF Community
Although this work will directly benefit the HYCOM mode, the need for an upgrade path from a local format to netCDF is general. I propose that this become part of the netCDF release and become available  to all netCDF-C library users.
Technical Approach
The solution consists of two parts: a plug-in to read and write AB Format, and the changes to the C library necessary to support use of the plug-in, and others like it.
Changes to NetCDF-C to Expose the Dispatch Layer
The C library contains a "dispatch" layer which allows for other formats to be added to the C library. This is how netCDF-4/HDF5, OPENDAP, HDF4, and the parallel-netcdf library are currently supported.
But the C library does not expose this plug-in capability. Changing the C library source code is required in order to add a new version.
For the purposes of this discussion, AB Format, and other such formats, will be called "user-defined formats".
Dispatch Layer Library
The user is responsible for building a dispatch layer library.
This library, when linked with netCDF and a user application, allows the netCDF library to understand the user-defined format. The user-defined format dispatch library implements all the necessary functions from the netCDF dispatch table. (This is a subset of the entire netCDF API).
The user-defined format is registered with a new function, nc_def_user_format().
The AB Format
The local format for the HYCOM model is called "AB Format." It consists of two files, one with metadata, and one with the data stored in binary form.
An AB "file" consists of two files on disk, a binary file with extension "a", and an ASCII text file with metadata with a "b" extension. (The names of the file are part of the format definition.)
The A file is IEEE big-endian, direct access, with a fixed record length.
Converting the AB Format to the NetCDF Internal Model
For the netCDF library to read and write files in AB format, the plug-in must read the metadata file, and provide functions in accordance with the internal needs of the netCDF library. Reading and writing are handled separately.
Reading the AB Format
When reading the AB format the netCDF library needs functions which will:

identify the file as an AB format file
read metadata and provide it to netCDF internals
read the data in subsetted arrays.

Identifying AB Files
AB Files can be identified by name. When an nc_open call is made, and the file name is not found, but two files "FILENAME.a" and FILENAME.b" are found, then the library knows it will be opening an AB file.
Reading AB File Metadata
Once a file has been identified as AB Format, the netCDF library will need to read and understand all the metadata pertaining to that file. This includes the names, types, and sizes of all variables, attributes, and dimensions in the file.
With AB format, code will be written to read the .a file and provide metadata information to the netCDF library.
Reading Subsetted Arrays of AB File Data
The core data read operation of netCDF is nc_get_vara_TYPE (where TYPE varies). This call allows the user to read a subset of a data variable into an n-dimensional array. With this operation, the netCDF-C library implements most of the other read operations.
In the case of AB Format the subsetted array read will be straightforward. Based on the information in the metadata file, the exact offsets to any element of the data can be computed.
Writing the AB Format
In writing the AB Foramt, the netCDF library must:

Create the AB files.
Fill the metadata file.
Implement the subset array write operation.

Creating an AB File
The config file which is read at library load will contain the mode flag which indicates the AB format.
Writing the AB Metadata File
Once the nc_create call returns, no further disk access takes place until the nc_enddef() call. During the time between nc_create() and nc_enddef() the user can define variables, attributes, and dimensions for the file.
When nc_enddef() is called, the AB Plug-in code muse write the B file, which contains the metadata for the file.
Only the netCDF-classic data model will be supported by the AB Format Plug-in. Other restrictions on types and objects may be necessary.
Subset Write Operation
The netCDF subset write operation nc_put_vara() is the key write operation from which other write operations are built. Once implement for the AB format, all netCDF write operations will work for the files.
Conclusion
Exposing the netCDF-C library dispatch layer will benefit the HYCOM modeling group, and also other netCDF-C users (including all netCDF fortran, python, perl, etc.)
Comments and feedback welcome. Please add to this issue so that all can participate in discussion.

OK, I now have this working on HPC NetCDF. It's really neat. (@wkliao this is one of the interesting new features I mentioned).
To see it in use, take a look at this github project:
https://github.com/HPC-NetCDF/ab-dispatch
In this project, HPC NetCDF is used, and a new netcdf function is called: nc_def_user_format().
After that function is called, the AB Dispatch code is used to read the file. At the moment I've just stuck the HDF4 code in there, so instead of reading AB format, the AB Dispatch code is reading HDF4. ;-) However, that code just has to be swapped out for AB format code that does the same thing (i.e. read the file and present it in the netCDF data model).
Here's how it looks in code:
   printf("\nTesting AB format dispatch layer...");
   if ((ret = nc_def_user_format(NC_UF0, &AB_dispatcher, NULL)))
      return ret;

   if ((ret = nc_open(TEST_FILE, NC_UF0, &ncid)))
      return ret;
   if ((ret = nc_inq(ncid, &ndims, &nvars, &natts, &unlimdimid)))
      return ret;
   /* printf("ndims %d nvars %d natts %d unlimdimid %d\n", ndims, nvars, natts, unlimdimid); */
   if (ndims != 4 || nvars != 6 ||natts !=10 || unlimdimid != -1)
       return 111;
   if ((ret = nc_close(ncid)))
      return ret;

I have added 2 user formats, NC_UF0 and NC_UF1, so the user can define two different formats at the same time, and use the netCDF API to interchangeably read/write them.
It's a neat feature. I will announce it on the netCDF mailing list sometime this week.
It's going to take time to get this into Unidata netCDF, due to the backlog of my PRs. To prevent out of order merging I'll hold off on putting this up until all or most of my currently-pending PRs are merged.

Here's a slide showing how user formats will work.

Duplicate of comment at: https://github.com/Unidata/netcdf-c/pull/814#discussion_r168599105

In restrospect, I made a mistake in making the # of entries in the dispatch
table (include/ncdispatch.h) differ depending on whether or not netcdf4
was enabled. The IMO proper way to do this is to make all dispatch table
entries be included and implement them to return NC_ENOTNC4 in e.g.
libsrc and libdap2 and pnetcdf.
P.S Making the dispatch table fixed size will also help Ed attempt at dynamic loading.

One critical issue is telling the netcdf library where and how to load the
dynamic format .so (or .dll) file. It is instructive to see how HDF5 does this for
its filter plugins. I have a short description in docs/filters.md#Process.

But this turns out not to be necessary with this solution.
The user-format dispatch layer is a library, which uses the netCDF library. (And the netCDF library does not have to be re-compiled.)
Them the user writes a program, which uses the dispatch layer library he/she has just written. And that library uses netCDF.
So our code code does not have to deal with .so or .dll files. All functions are available at program compile time, either in the user-dispatch library or the netCDF library.

From my point of view, this is a bad and complicated solution.
This no different from our current situation of compiling library usage
into the netcdf library. To call it dynamic seems incorrect.

Let me paraphrase your proposal and tell me where I have it wrong.

You have wrapper library on top of netcdf-c
In order to add a new format, you implement the netcdf API
for that format
You then add the format implementation code to your wrapper
source code repo, establish some connections (e.g. pointer to the api/dispatch table
plus a mode flag + whatever).
You then recompile the wrapper (with the format code).
The user then uses this newly compiled wrapper in place of the netcdf
library.

First there are some changes in netCDF:
1 - I added function nc_def_user_format() which takes a pointer to a dispatch table, a mode flag (NC_UF0 or NC_UF1), and an optional magic number (not yet used).
2 - I modified the netCDF dispatch code in dfile.c so that when it gets NC_UF0 or NC_UF1 it uses the provided user-format dispatch table. (Magic number modifications still to come.)
Now for a user to implement their own binary format:
1 - User writes a library that implements the required netCDF dispatch functions. It is not a wrapper for netCDF. (Example here: https://github.com/HPC-NetCDF/ab-dispatch). It's the same code as lives in the existing dispatch directories (like HDF4), but it lives in its own repo and library. It is not mixed with netCDF code (but does use netCDF headers).
2 - Only the functions needed in a dispatch layer are required. It can easily reuse standard functions that will work (as the HDF4 layer reuses all the existing nc_inq_* functions). So not every function is implemented.
3 - The user writes a program that links to both netCDF and their own, separately compiled and installed, dispatch library. (It actually does not have to be separate from the user application, but it is separate from netCDF.)
4 - The user code calls nc_def_user_format(), with a pointer to the dispatch table in the user-format dispatch library. In this call, user also associates one of two pre-defined mode flags (NC_UF0 or NC_UF1) with the format.
5 - From then on, NC_UF0 in the mode flag means use this custom dispatch table. The netCDF library is not recompiled or wrapped.
6 - Other modeling groups, working on the same HPC with the same netCDF installation, can define their own NC_UF0, by writing and linking to their own dispatch layer. Each group can have up to two user-defined formats in use at the same time (in addition to all the usual netCDF formats).
This way the code for the user-defined dispatch layer is completely and always outside the netCDF code. Users can develop dispatch layers, exchange them, or whatever. They can write a custom dispatch layer for a proprietary format, and not release it. It's a separate library, which plugs in to netCDF. Dynamic loading is taken care of when a pointer to the dispatch table is passed to nc_def_user_format().
So this is quite different from the current situation, where each dispatch layer has to be built into the library, and then the library must be rebuilt.

Here's a little sneak preview of some code. This is all working code, BTW.

/* User-defined formats. */
NC_Dispatch* UF0_dispatch_table = NULL;
NC_Dispatch* UF1_dispatch_table = NULL;

/**
 * Add handling of user-defined format.
 *
 * @param mode_flag NC_UF0 or NC_UF1
 * @param dispatch_table Pointer to dispatch table to use for this user format.
 * @param magic_numer Magic number used to identify file. Ignored if NULL.
 *
 * @return ::NC_NOERR No error.
 * @return ::NC_EINVAL Invalid input.
 * @author Ed Hartnett
 */
int
nc_def_user_format(int mode_flag, NC_Dispatch *dispatch_table, char *magic_number)
{
   if (mode_flag != NC_UF0 && mode_flag != NC_UF1)
      return NC_EINVAL;
   if (!dispatch_table)
      return NC_EINVAL;

   switch(mode_flag)
   {
   case NC_UF0:
      UF0_dispatch_table = dispatch_table;
      break;
   case NC_UF1:
      UF1_dispatch_table = dispatch_table;
      break;
   }

   return NC_NOERR;
}

Later, in NC_open():
   /* Check for use of user-defined format 0. */
   if (cmode & NC_UF0)
   {
      if (!UF0_dispatch_table)
         return NC_EINVAL;
      model = NC_FORMATX_UF0;
      dispatcher = UF0_dispatch_table;
   }

   /* Check for use of user-defined format 1. */
   if (cmode & NC_UF1)
   {
      if (!UF1_dispatch_table)
         return NC_EINVAL;
      model = NC_FORMATX_UF1;
      dispatcher = UF1_dispatch_table;
   }

Then, in my sample user-defined format library, I have:
NC_Dispatch AB_dispatcher = {

NC_FORMATX_UF0,

AB_create,
AB_open,

AB_redef,
AB__enddef,
AB_sync,
AB_abort,
AB_close,
AB_set_fill,
AB_inq_base_pe,
AB_set_base_pe,
AB_inq_format,
AB_inq_format_extended,

NC4_inq,
NC4_inq_type,

AB_def_dim,
NC4_inq_dimid,
NC4_inq_dim,
NC4_inq_unlimdim,
AB_rename_dim,

NC4_inq_att,
NC4_inq_attid,
NC4_inq_attname,
AB_rename_att,
AB_del_att,
NC4_get_att,
AB_put_att,

AB_def_var,
NC4_inq_varid,
AB_rename_var,
AB_get_vara,
AB_put_vara,
NCDEFAULT_get_vars,
NCDEFAULT_put_vars,
NCDEFAULT_get_varm,
NCDEFAULT_put_varm,

NC4_inq_var_all,

AB_var_par_access,
AB_def_var_fill,

NC4_show_metadata,
NC4_inq_unlimdims,

NC4_inq_ncid,
NC4_inq_grps,
NC4_inq_grpname,
NC4_inq_grpname_full,
NC4_inq_grp_parent,
NC4_inq_grp_full_ncid,
NC4_inq_varids,
NC4_inq_dimids,
NC4_inq_typeids,
NC4_inq_type_equal,
AB_def_grp,
AB_rename_grp,
NC4_inq_user_type,
NC4_inq_typeid,

AB_def_compound,
AB_insert_compound,
AB_insert_array_compound,
AB_inq_compound_field,
AB_inq_compound_fieldindex,
AB_def_vlen,
AB_put_vlen_element,
AB_get_vlen_element,
AB_def_enum,
AB_insert_enum,
AB_inq_enum_member,
AB_inq_enum_ident,
AB_def_opaque,
AB_def_var_deflate,
AB_def_var_fletcher32,
AB_def_var_chunking,
AB_def_var_endian,
AB_def_var_filter,
AB_set_var_chunk_cache,
AB_get_var_chunk_cache,

};

Note the used of NC4_ and NCDEFAULT functions to lighten the load. I only implemented the functions that start AB_, and many of those just return NC_EPERM since this is read only.
To use the AB dispatch layer, I do this:
   printf("\nTesting AB format dispatch layer...");
   if ((ret = nc_def_user_format(NC_UF0, &AB_dispatcher, NULL)))
      return ret;

   if ((ret = nc_open(TEST_FILE, NC_UF0, &ncid)))
      return ret;
   if ((ret = nc_inq(ncid, &ndims, &nvars, &natts, &unlimdimid)))
      return ret;
   /* printf("ndims %d nvars %d natts %d unlimdimid %d\n", ndims, nvars, natts, unlimdimid); */
   if (ndims != 4 || nvars != 6 ||natts !=10 || unlimdimid != -1)
       return 111;
   if ((ret = nc_close(ncid)))
      return ret;

   printf("SUCCESS!\n");
   return 0;

Ok, I see. It is actually a pretty good solution. We ought to propose
a variant to the HDF5 group as a means for defining a filter plugin.
I might suggest we provide an extra function for the dispatch table
that return true/false if an existing file path or URL can be read
by that format. Netcdf-java has such, and it would simplify
the current NC_open code in libdispatch/dfile.c.
However, this solution would not work for existing systems that
use netcdf-c: systems like R and IDL. It would also be
difficult for python and Java users.
One problem I see is mode flag conflicts. We have a limited set of
available mode flags (about 16 bits).  We may need to consider extending
the arguments to nc_open and nc_create. We might also consider changing
the mode to be of type long so that is can be 64 bits on 64bit machines.

This system will work for R, IDL, Fortran, and any other layer that sits on top of the C library. BUT the user-format dispatch layer must be written in C. And there must be one C call to set the user format (although we can probably do this in most languages with a void *.)
Once that is done, it works completely within the C layer. If the Fortran program passes NC_UF0 in to nf_open() it will all work. Same with python, as it uses the C library.
It does nothing for Java but they already have this feature. We are just trying to catch up. ;-)
For most HPC users and modeling groups, this will be useful. There will be one or two non-netCDF formats, and some C programmer will write the dispatch layer, and all the fortran programmers will just link to the user-format dispatch library, just as they do to netCDF. Useful formats can even be distributed by helpful folk like @opoplawski if they become popular, and then users can just install them with some package management tool.
The user does not add mode flags. I provide two: NC_UF0 and NC_UF1. This allows two different user-defined formats to be in use in the same program. There are still some mode flags available after that. I agree about the eventual mode flag scarcity problem, but we have not run out yet.
So I would propose to separate any discussion of mode flag scarcity from the issue of user-defined formats.

Some other programming notes:

Agree with your proposed extra function.
Some functions now called NC4_inq_* will be renamed after the HDF5 code is separated from the internal metadata code, functions that use only the internal metadata will get some name like NCDEFAULT_ (to match existing usage).
Some easier provision can be made for functions that return NC_EPERM. I think read-only user-defined formats will be popular. So we can make it easier for programmers by defining NCDEFAULT style versions of those functions, which just return NC_EPERM.
When all this happens it will be useful to remove the distinction between classic and netCDF-4 dispatch tables.

This does not sound right. R and IDL are interpreters and have AFAIK no way
to access your format code when they are run.
There are a different set of problems for systems like fortran, java, and python.
writing the c accessing code in these languages is not trivial and generally
requires expert knowledge. So for every format handler, someone will also
have to write the fortran/java/python wrapper for it.

In thinking about this, I do not see why you need to us NC_UF0 and NC_UF1.
There is no obvious difficulty for the user to define multiple formats.

Ok, I take back part of what I said.
It see that the key is that you need to pass a reference to some
structure in the format implementation to the netcdf library so it can set up
the dispatch. So you still need to define a wrapper function in fortran/java/python
that wraps a single C function in the format code.
This function  returns the pointer to that structure.
And there needs to be such a function for every format to be used.
However for the languages like python and Java, the format code
needs to be encoded as a shared library.  For fortran/c/c++, a shared libary
can be avoided by including the .o files when linking the user's program.
Seems to me that with a little care in defining the passed structure an hdf5
plugin approach can be provided as well.

I believe that python, IDL, etc. already have a mechanism for dynamically loading C libraries. So they would use that method to load the dispatch library.
All of these languages will let you wrap a C function that actually calls nc_def_user_format(), so it is not even necessary to wrap that in Fortran, or any other language. As part of their dispatch layer use in a python program, they must load their dispatch library, then they must call a C function that calls nc_def_user_format(). From that point on, they are good to go.
Yes, for fortran and C programs the dispatch layer can just be built right into the user code. However, I am providing a sample library dispatch layer, so probably it will be easiest for users to just copy that and make it a separate library.
I will also say that the primary requirement here is C and Fortran. This is for models and they are not written in Python. However, as I say, I believe it will work just fine for python too.

To answer your questions about NC_UF0 and NC_UF1:

If we let users define as many modes as are open, then when we later want to add a new mode, we can't guarantee is is not already in use by a user. With UF0/UF1 we know that all the others are still free.
User code will be more clear if everyone uses the same mode flag for their user-defined format. If everyone start making up mode flags, then code will be confusing. But if you see UF0 you know that it is a user defined format.
If we let the user try to pick an unused mode flag, that will be a rich source of error. They will reuse one, and uproarious hilarity will ensue.

So those are my reasons. Not married to anything about this implementation, it's just my first pass.

Effectively you are just reserving some # of bits (2 in your case) in the mode flag
for user formats. The name is irrelevant.

One thing to remember is that there is no defined mapping between those mode flags
and the format because two different users can attach the same flag to
different formats.

Yes and yes.
The mode flags mean nothing until nc_def_user_format() is called to associate them with a dispactch table.
If the users uses a different dispatch table and then tries to read NC_UF0, then obviously it will not work.

@DennisHeimbigner I've been thinking about your remarks on ncdump on another thread. Now I understand. Without recompiling ncdump, it cannot understand user defined formats.
I think here is the case where libraries must be dynamically loaded by our code.
If a new command-line argument is added to ncdump which is the user-defined library name, then that library can be dynamically loaded in ncdump, and then ncdump can call its dispatch functions.

Before this goes much further, we need to have
a software architecture and design document to
codfy the API and the critical implementation
details. Something in markdown like a cross between
this https://github.com/Unidata/netcdf-c/blob/master/docs/filters.md
and this https://support.hdfgroup.org/HDF5/doc/Advanced/DynamicallyLoadedFilters/HDF5DynamicallyLoadedFilters.pdf

Some other issues that need to be addressed:

format specific error codes
NC_FORMAT_XXX, NC_FORMATX_XXX
nc_inq_format() and nc_inq_format_extended()

Another issue to consider:
we need to version the data structures we will be using.
Also, we need to consider at some point trying to
simplify the dispatch table. E.g. combine all the filter definition
related stuff into a single dispatch entry..

OK, I will assemble some documentation. Also, in light of these conversations I will do some of the dispatch work we have discussed first, to clear away the underbrush and make this feature's implementation more clear. So let me return to this after #856. That will make the necessary interfaces much more clear.

I am curious; why are you so resistant to documenting the major code changes
you are working on? Even doing it in parallel with the coding?

@DennisHeimbigner just joking about documentation! No resistance to documenting at all. I love documenting. The hard thing is to get me to shut up.
After the current HDF4 changes are merged I have another HDF4-only change that incrementally moves towards some of these changes. Basically I take the HDF4 only fields out of the netCDF-4 info structs and use a void pointer, as we discussed. In the case of HDF4, the void pointer points to the HDF4 info struct.
(In a future evolution, it will point to the HDF5 info. for HDF5 files.)
This cleans the HDF4 stuff out of the header files, and will allow me to start to isolate the internal API that is needed by the dispatch layer code.
As part of that I will start to add to the internal dispatch documentation, as needed, to explain the changes.

There has been a lot of development of the user-defined format feature in HPC NetCDF. And it's a very powerful feature.
I have been writing the ab-dispatcher, a dispatch layer for the AB format used in the HYCOM model.
Recently I have gotten ncdump working with user-defined formats in a general way. Now I can do an ncdump on an AB format file! It's neat!
In order for this to work, the user must build the user-defined format library, and then provide information about it at netCDF compile time. Then, with the use of the new -u option, ncdump can read files of user-defined format.
 ./ncdump -h -u 0 /home/ed/tmp/ab-dispatch/test/surtmp_100l.b
netcdf surtmp_100l {
dimensions:
	day = 123 ;
	j = 175 ;
	i = 258 ;
variables:
	float day(day) ;
	float surtmp(day, j, i) ;
		surtmp:day = 36495.5f, 36495.75f, 36496.f, 36496.25f, 36496.5f, 36496.75f, 36497.f, 36497.25f, 36497.5f, 36497.75f, 36498.f, 36498.25f, 36498.5f, 36498.75f, 36499.f, 36499.25f, 36499.5f, 36499.75f, 36500.f, 36500.25f, 36500.5f, 36500.75f, 36501.f, 36501.25f, 36501.5f, 36501.75f, 36502.f, 36502.25f, 36502.5f, 36502.75f, 36503.f, 36503.25f, 36503.5f, 36503.75f, 36504.f, 36504.25f, 36504.5f, 36504.75f, 36505.f, 36505.25f, 36505.5f, 36505.75f, 36506.f, 36506.25f, 36506.5f, 36506.75f, 36507.f, 36507.25f, 36507.5f, 36507.75f, 36508.f, 36508.25f, 36508.5f, 36508.75f, 36509.f, 36509.25f, 36509.5f, 36509.75f, 36510.f, 36510.25f, 36510.5f, 36510.75f, 36511.f, 36511.25f, 36511.5f, 36511.75f, 36512.f, 36512.25f, 36512.5f, 36512.75f, 36513.f, 36513.25f, 36513.5f, 36513.75f, 36514.f, 36514.25f, 36514.5f, 36514.75f, 36515.f, 36515.25f, 36515.5f, 36515.75f, 36516.f, 36516.25f, 36516.5f, 36516.75f, 36517.f, 36517.25f, 36517.5f, 36517.75f, 36518.f, 36518.25f, 36518.5f, 36518.75f, 36519.f, 36519.25f, 36519.5f, 36519.75f, 36520.f, 36520.25f, 36520.5f, 36520.75f, 36521.f, 36521.25f, 36521.5f, 36521.75f, 36522.f, 36522.25f, 36522.5f, 36522.75f, 36523.f, 36523.25f, 36523.5f, 36523.75f, 36524.f, 36524.25f, 36524.5f, 36524.75f, 36525.f, 36525.25f, 36525.5f, 36525.75f, 36526.f ;
		surtmp:span = 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f, 0.25f ;
		surtmp:min = 9.771892f, 10.78499f, 9.401492f, 6.62843f, 4.607868f, 3.897291f, 4.213979f, 4.424856f, 4.226626f, 4.022602f, 4.136856f, 4.622542f, 4.554771f, 4.664321f, 4.907145f, 5.749945f, 6.398822f, 6.757607f, 7.123997f, 7.393907f, 7.355556f, 7.199125f, 5.509292f, 4.769361f, 5.141631f, 5.896506f, 6.674411f, 7.204914f, 7.653955f, 8.095844f, 8.628254f, 9.426715f, 10.19681f, 10.8054f, 11.26849f, 11.75135f, 11.90478f, 12.05591f, 12.18285f, 12.18917f, 12.19639f, 12.15982f, 9.251261f, 4.093727f, 0.1810672f, -1.352509f, -0.3644944f, 2.234805f, 4.680813f, 5.819631f, 6.325951f, 6.385474f, 6.446225f, 7.241121f, 8.016541f, 9.304774f, 10.86362f, 11.90644f, 12.25582f, 12.66792f, 10.84867f, 7.711861f, 4.648007f, 3.113999f, 2.058515f, -0.4776078f, -1.811485f, -1.072346f, 1.302688f, 2.925264f, 4.287227f, 2.943427f, 2.069484f, -0.971903f, -2.7068f, -2.914489f, -3.389548f, -3.525549f, -2.487972f, -0.9476987f, 0.4470849f, 1.769978f, 2.568594f, 2.248194f, 1.012455f, 0.4613987f, 0.4744164f, 1.511067f, 3.196703f, 4.542253f, 5.570292f, 6.480618f, 7.03563f, 7.337607f, 7.424665f, 7.305072f, 6.841867f, 6.141395f, 5.669068f, 5.445779f, 5.857729f, 6.901529f, 7.535413f, 5.567883f, 4.132844f, 3.37798f, 3.25649f, 4.144887f, 4.801534f, 5.31437f, 6.164811f, 6.354491f, 5.865624f, 4.060117f, 2.045688f, 0.7715751f, -0.4165433f, -1.899319f, -3.70032f, -4.506866f, -3.937608f, -2.206423f, 0.7947709f ;
		surtmp:max = 28.59057f, 28.55973f, 28.51728f, 28.46502f, 28.42407f, 28.39497f, 28.36654f, 28.33718f, 28.35678f, 28.42611f, 28.45828f, 28.4539f, 28.40721f, 28.31663f, 28.22207f, 28.1251f, 28.05723f, 28.01744f, 27.99325f, 27.98465f, 28.02594f, 28.0898f, 28.17212f, 28.27229f, 28.32424f, 28.32764f, 28.31756f, 28.29471f, 28.29529f, 28.31963f, 28.32314f, 28.30661f, 28.28154f, 28.24656f, 28.22466f, 28.21485f, 28.23409f, 28.28334f, 28.33323f, 28.38336f, 28.41042f, 28.41478f, 28.42897f, 28.45376f, 28.46047f, 28.44769f, 28.43469f, 28.42205f, 28.41031f, 28.40067f, 28.36763f, 28.31886f, 28.28504f, 28.2104f, 28.14836f, 28.09814f, 28.03523f, 27.9609f, 27.90944f, 27.92048f, 27.92048f, 27.89946f, 27.87928f, 27.85905f, 27.87305f, 27.95421f, 28.03169f, 28.09938f, 28.16357f, 28.22428f, 28.19538f, 28.07429f, 28.00822f, 27.996f, 28.06264f, 28.20688f, 28.25077f, 28.19443f, 28.13398f, 28.06973f, 28.0083f, 27.95032f, 27.87952f, 27.79702f, 27.74094f, 27.71023f, 27.64829f, 27.55387f, 27.46205f, 27.3736f, 27.27755f, 27.17374f, 27.08916f, 27.0234f, 26.99387f, 27.00098f, 27.0039f, 27.00413f, 27.01702f, 27.04178f, 27.09779f, 27.1843f, 27.27128f, 27.35929f, 27.42496f, 27.46794f, 27.50336f, 27.53091f, 27.5569f, 27.58121f, 28.06085f, 27.65506f, 27.70081f, 27.75047f, 27.78866f, 27.81437f, 27.80693f, 27.76656f, 27.68389f, 27.55849f, 27.43142f, 27.30333f, 27.25132f ;
		surtmp:long_name = " sea surf. temp.  " ;
		surtmp:standard_name = "sea_surface_temperature" ;
		surtmp:units = "degC" ;

// global attributes:
		:att_0 = "FNMOC, 6hrly, degC" ;
		:Conventions = "CF-1.0" ;
}

Agreed. But (there is always a but...:-)
This assumes (as we have discussed)
some way to probe the added dispatch layer to
get information about the format. We need to make sure
that the probe information is sufficiently general.

There are two user-defined formats that can be used UF0 and UF1. When you build HPC netCDF you can provide an option like this:
--with-uf0=AB_dispatcher
(If this is provided, you must also provide LDFLAG and LADD options to point to the library that implements a dispatch table called AB_dispatcher, or the build will fail.)
This will tell ncdump that user-format 0 is associated with the AB_dispatcher dispatch table. ncdump registers the new dispatch table before calling nc_open().
When running ncdump, the user must provide the -u0 option, to indicate that user-format 0 should be used for this file. This causes ncdump to use the NC_UF0 for the nc_open() mode flag.
A different user format could also be used as user format 1. It's up to the user to keep straight which is which for their build. (But if they get it wrong, ncdump returns an unknown format error, so that's OK.)
Note sure what you mean by probing. Does the above answer your questions?

No. Put another way, how does the library locate the relevant dispatch table?

The library locates the relevant dispatch table using the symbol "AB_dispatcher" (provided to netCDF configure) which is the name of the dispatch table in my dispatch library. The library is specified by adding it to the LIBS flag when building netCDF.
So I can name my dispatch table whatever I like. When I build netCDF, I say --with-uf0=my_dispatch_name, and make sure that the linker can find my dispatch library. The configure defines macro UF0_DISPATCH in config.h. When ncdump is built, the symbol is substituted like this:
#ifdef USE_UF0
extern NC_Dispatch UF0_DISPATCH;
#endif /* USE_UF0 */

...

    /* If user-defined formats are in used, register the dispatch
     * table. */
#ifdef USE_UF0
   if ((ret = nc_def_user_format(NC_UF0, &UF0_DISPATCH, NULL)))
      return ret;
#endif /* USE_UF0 */

This will of course all be fully-documented in a new section of the docs for user-defined formats.
To address some of your other recent comments:

NC_FORMAT_XXX, NC_FORMATX_XXX - users must pick an unused (by netCDF) value for the format, and it's actually in the dispatch table. I am planning an NCDEFAULT_inq_format() and NCDEFAULT_inq_format_extended() which just return whatever the value in the dispatch table is.

User-defined error codes are, I think, an unneeded complexity. We can provide a general error for each user-defined format (NC_EUF0/NC_EUF1) which can be used like NC_EHDFERR is used in the HDF5 code. Other than that, they can use one of the already-defined errors, which provide a rich collection appropriate to reading and writing data in the netCDF model. Recall that the vast majority of users are not doing sophisticated return code handling.

I agree that a refactor of the dispatch table may be advisable before this feature goes public. Once it does the dispatch table becomes a little harder to change. (You will break all user-defined formats when you do.) I suggest that we ponder potential changes, and take a look after I present my PR for #856.

Another idea is an additional alternative, much slimmer (pseudo-)dispatch table which can be used for read-only formats, which only need 3 or 4 functions. The pseudo-table could be put into a full dispatch table by nc_def_user_format(), and would allow the user to ignore all the other functions, and just take the NCDEFAULT_ versions.

It turns out that some helper functions in libsrc4 (non-HDF5) code can help all dispatch layers make good use of the netCDF internal data model without exposing its internal elements. We already have many such functions, and with a little refactoring, they can do the job nicely. For example, we have various find, add, and delete functions. We just need to clean up their parameters a bit to hide most of the internals.

I have added to my todo list an item to extend this
to do dynamic loading using code from here:
https://github.com/DennisHeimbigner/cpoco

authors: DennisHeimbigner edhartnett

repo: Unidata/netcdf-c


text:
Wrong times reported by "ncdump -t"

Reproducible with ncdump from

netcdf library version 4.7.1 of Aug 31 2019 00:57:34
netcdf library version 4.7.3 of Jan 23 2020 04:18:16

timebug.nc.gz
ncdump -t timebug.nc
reports times starting from midnight, while the first time is at 07Z.
Thank you!

I believe this is a duplicate of Unidata/netcdf-c#1417.

Thank you! I would guess, it is not a duplicate, although, might be related. That one was caused by undesired conversion of UTC to local time. This one is about ignoring the time specification..

ncdump -t does not attempt to handle the time zone at all. I think the bug is that when the unit attribute parsing code encounters UTC, it sets the clock time to zero by mistake rather than simply dropping the timezone. See this comment (which appears to have a fix as well).
And now I see you had been involved in the conversation over on that issue - sorry about the duplicate info here!
I was able to take your example file and 1. drop UTC from the units string and get correct results (e.g. minutes since 2018-01-03 07:00:00), and 2. change UTC to MDT (or other string, e.g. minutes since 2018-01-03 07:00:00 ABCDEFG) and get correct results. I only see the bug when UTC is used.

Thank you!   That report was also from me :), and I got an impression that it been closed already, so did not check it. Sorry. So it is the same bug. So far I have just forced 00Z for all reference times as a workaround...

authors: lesserwhirls rkouznetsov


text:
NOAA model is reporting problem when upgrading past netcdf-c-4.2

We have a NOAA model (https://github.com/NOAA-EMC/nwps.git) that can't be upgraded past netcdf-c-4.2. 4.2 works, but 4.3 returns an error at some point:
NetCDF: Not a valid ID
At first I thought this was due to the fill value type checking that was added in the 4.3 release. But here's the CDL of a file successfully produced by the 4.2 library.
netcdf CG_UNSTRUC {
dimensions:
	time = UNLIMITED ; // (145 currently)
	points = 120028 ;
variables:
	int time(time) ;
		time:units = "seconds since 1970-01-01" ;
		time:calendar = "gregorian" ;
		time:standard_name = "time" ;
		time:long_name = "time" ;
	float longitude(points) ;
		longitude:units = "degrees_east" ;
		longitude:long_name = "longitude" ;
		longitude:standard_name = "longitude" ;
	float latitude(points) ;
		latitude:units = "degrees_north" ;
		latitude:long_name = "latitude" ;
		latitude:standard_name = "latitude" ;
	short hs(time, points) ;
		hs:units = "m" ;
		hs:standard_name = "sea_surface_wave_significant_height" ;
		hs:long_name = "hs" ;
		hs:scale_factor = 0.0007629627f ;
		hs:add_offset = 25.f ;
		hs:_FillValue = -32768s ;
	short xwnd(time, points) ;
		xwnd:units = "m s-1" ;
		xwnd:standard_name = "eastward_wind" ;
		xwnd:long_name = "U-Component of Wind" ;
		xwnd:scale_factor = 0.003051851f ;
		xwnd:add_offset = 0.f ;
		xwnd:_FillValue = -32768s ;
	short ywnd(time, points) ;
		ywnd:units = "m s-1" ;
		ywnd:standard_name = "northward_wind" ;
		ywnd:long_name = "V-Component of Wind" ;
		ywnd:scale_factor = 0.003051851f ;
		ywnd:add_offset = 0.f ;
		ywnd:_FillValue = -32768s ;
	short tps(time, points) ;
		tps:units = "s" ;
		tps:long_name = "tps" ;
		tps:scale_factor = 0.0007629627f ;
		tps:add_offset = 25.f ;
		tps:_FillValue = -32768s ;
	short theta0(time, points) ;
		theta0:units = "degrees" ;
		theta0:standard_name = "sea_surface_wave_from_direction" ;
		theta0:long_name = "theta0" ;
		theta0:scale_factor = 0.005493332f ;
		theta0:add_offset = 180.f ;
		theta0:_FillValue = -32768s ;
	short thetap(time, points) ;
		thetap:units = "degrees" ;
		thetap:long_name = "thetap" ;
		thetap:scale_factor = 0.005493332f ;
		thetap:add_offset = 180.f ;
		thetap:_FillValue = -32768s ;
	short xcur(time, points) ;
		xcur:units = "m s-1" ;
		xcur:standard_name = "eastward_sea_water_velocity" ;
		xcur:long_name = "x component of current" ;
		xcur:scale_factor = 0.0006103702f ;
		xcur:add_offset = 0.f ;
		xcur:_FillValue = -32768s ;
	short ycur(time, points) ;
		ycur:units = "m s-1" ;
		ycur:standard_name = "northward_sea_water_velocity" ;
		ycur:long_name = "y component of current" ;
		ycur:scale_factor = 0.0006103702f ;
		ycur:add_offset = 0.f ;
		ycur:_FillValue = -32768s ;
	short ssh(time, points) ;
		ssh:units = "m" ;
		ssh:standard_name = "sea_surface_height" ;
		ssh:long_name = "SSH" ;
		ssh:scale_factor = 0.0004577776f ;
		ssh:add_offset = 0.f ;
		ssh:_FillValue = -32768s ;
	short hswe(time, points) ;
		hswe:units = "m" ;
		hswe:standard_name = "sea_surface_swell_wave_significant_height" ;
		hswe:long_name = "wave height of swell part" ;
		hswe:scale_factor = 0.0007629627f ;
		hswe:add_offset = 25.f ;
		hswe:_FillValue = -32768s ;

// global attributes:
		:Conventions = "CF-1.5" ;
		:History = "Created with agioncmd version 1.4" ;
		:Directional_convention = "nautical" ;
		:project = "SWAN-FTPPAT2-CG1" ;
		:run = "0818" ;
		:_Format = "64-bit offset" ;
}

I don't believe this is a netcdf-c issue, but rather an issue with the model code. I will update here if I ever figure out what is going on.


text:
Use pytest parameters to avoid duplicate tests for BFD

title

Looks good, the only thing that confuses me is the grouping of the tests - why have the class TestJuniper for two tests and then the rest of the tests outside of a class?

I dont remember why but those two test juniper specific functions. Should maybe be similar tests for cisco, but I see that as outside the scope of this PR

repo: Uninett/zino


text:
fixed zero sent bytes recorded when profiling client

NetworkProfiler CurrentTick is not present at the time the message is sent.
related issue #368

Although it kinda fixes the problem it still feels a bit hacky in a way.

You should be able to send messages at any time, so it makes sense to open new tick if it's non existing...
StartTick could check if the current tick is existing before creating new one.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Nikola Durinec seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

@becksebenius-unity

@becksebenius-unity can you take a look at this?

authors: LukeStampfli MrCool92 TwoTenPvP unity-cla-assistant


text:
Add datatype validation

Currently, it is possible to use variables of any datatype to map them to message fields. This will eventually result in an error message on the rosbridge:
Reproduce the error:

Create a publisher on a topic with e.g. geometry_msgs/Pose
create variable with value 0
select this variable for frame_id(string)
Result: [ERROR] [1618848091.913749]: [Client 7] publish: geometry_msgs/PoseStamped message requires a string for field header.frame_id, but got a <type 'int'>

We should add a validation step on URCap side.
As far as I know, polyscope variables are not typed.
We should try to convert the variables to string / numbers in URScript to get a type check at runtime. Currently, we convert everything to a string, e.g. to_str(int_var). As this integer ends up in the jsonstring without quotes it will be treated as number on the rosbridge side. We'll have to make sure that the jsonstring actually contains surrounding quotes for a string variable and tries to convert it to_num for numeric values.

As I am not aware of any method of getting the type of a variable either on the java side nor in URScript, I don't know how to solve this currently.

@fmauch can yo provide a json example?

When writing my previous answer I had something different in mind. The issue described in the OP should actually be resolved by #37.
I'll open a separate issue describing the problems I had in mind when writing https://github.com/UniversalRobots/Universal_Robots_ROS_as_a_Service_URCap/issues/1#issuecomment-843915090

authors: fmauch urrsk


text:
DENT-408 unstable? (and MED-518?)

2024-11-10:
_"Hei,
Muokkasin Norppa-palautetta: lisäsin kysymyksiä ja asetin palautteen alkamisajankohtaa aikaisemmaksi kuin mitä se oli automaattisesti asetettu. Nyt sain opiskelijalta palautetta, että Norppa-palautesivu ei toimi. Hän oli kokeillut sekä tietokoneella että puhelimella. Missähän on nyt ongelma?
"_
11-12-2024_
_"Hei!
Yritän antaa palautetta kurssista DENT-408, mutta Norppa herjaa joka kerta samaa ongelmaa (kuvakaappaus alla, punainen ruutu alareunassa). Mitä teen?
Olen kirjautunut sisään HY-tunnuksilla onnistuneesti, olen yrittänyt antaa palautteen eri laitteilla ja eri selaimilla (kännykkä, työläppäri ja vapaa-ajan läppäri / Duckduckgo, Chrome, Edge).
"_
PUNAINEN: "jotain meni pieleen"

https://norppa.helsinki.fi/targets/81484332/feedback

The problem lies from this commit where the highest access status is tried to return. However this broke the old logic, which checked the student status first and returned it before anything else.

authors: HRemonen tttriple

repo: UniversityOfHelsinkiCS/palaute


text:
Projects Page (Functions)

Summary
This is the sub issue under Projects Page to add functions to the webpage
For Sub-Issue

Change Proposal

For upcoming projects (you can only make a testing section), add buttons for people to apply to roles
Link technical managers' introduction to their contact information (current projects only)

Deadline of the task: TBD

Additional Info

Closing issue to combine it with UI

authors: CatherineZM Felix-Deng

repo: UofT-VEEP/VEEP-Website


text:
Not working w. protractor 4

We're using protractor 4.0.14 in our project and protractor-console doesn't seem to work with it. I installed the package as described and added it to our protractor.conf.js:
exports.config = {
    plugins: [{
        package: 'protractor-console',
        logLevels: ['info'],
    }],
    seleniumAddress: 'http://localhost:4444/wd/hub'

Logs don't show up. I set the logLevel to 'debug' and also tried 'info' but nothing is displayed.
Might be related to the last part of the first sentence in the protractor 3.0.0 CHANGELOG:

and plugins now need to be explicitly required

Have you successfully used protractor-console before with another version of Protractor?
If you're looking specifically for info and debug level logs, it could be that they're suppressed. Please see: https://github.com/Updater/protractor-console/issues/4

No. My first time using protractor-console. I added a console.error to the code and also tried w. a throw, nothing changed.

FWIW, it's working for us and we've been on Protractor 4.0.10 for some time.
What browser(s) have you tried?

Just Google Chrome.

what happen with this issue?

authors: aperdomob mdix pmowrer

repo: Updater/protractor-console

license: mit


text:
insert link to blog post once published

There a dead link in the readme. Add the full link to the blogpost once it's published (tomorrow)

Closed in a238ab142f7023e21b30623def3d0e120be4c2db


text:
Fixed typo in index.html

Fixed typo:
There was a duplicate sentence, probably the result of adding a link to the Add datasets form.
@WillEngler <3

Thanks Nathan :smile:

🙇  You're the best, man!

😄

authors: HeyZoos NHDaly WillEngler

repo: UrbanCCD-UChicago/plenario


text:
MinimongoError: can't set field named $$hashKey

There seems to be a regression in 0.8.12 (problem does not happen in 0.8.10). In some cases calling scope.$apply causes this error:
MinimongoError: can't set field named $$hashKey [409]
Full trace:
"Meteor.makeErrorType/errorClass@http://localhost:3000/packages/meteor.js?43b7958c1598803e94014f27f5f622b0bddc0aaf:532:15
@http://localhost:3000/packages/mongo.js?3cfe0c5981c197df33036a37574850f057e934a6:984:19
.apply/stubReturnValue<@http://localhost:3000/packages/ddp.js?d1840d3ba04c65ffade261f362e26699b7509706:4269:20
.withValue@http://localhost:3000/packages/meteor.js?43b7958c1598803e94014f27f5f622b0bddc0aaf:955:17
.apply@http://localhost:3000/packages/ddp.js?d1840d3ba04c65ffade261f362e26699b7509706:4260:31
Mongo.Collection.prototype[name]@http://localhost:3000/packages/mongo.js?3cfe0c5981c197df33036a37574850f057e934a6:656:1
upsertObject@http://localhost:3000/packages/urigo_angular.js?f39a58528c9912d9069bc87495d9781c9d7c3fec:1036:11
save@http://localhost:3000/packages/urigo_angular.js?f39a58528c9912d9069bc87495d9781c9d7c3fec:1064:25
updateCollection/<.changedAt@http://localhost:3000/packages/urigo_angular.js?f39a58528c9912d9069bc87495d9781c9d7c3fec:1318:9
diffArray/<@http://localhost:3000/packages/urigo_angular.js?f39a58528c9912d9069bc87495d9781c9d7c3fec:473:9
_.forEach@http://localhost:3000/packages/underscore.js?0a80a8623e1b40b5df5a05582f288ddd586eaa18:164:13
diffArray@http://localhost:3000/packages/urigo_angular.js?f39a58528c9912d9069bc87495d9781c9d7c3fec:457:3
updateCollection@http://localhost:3000/packages/urigo_angular.js?f39a58528c9912d9069bc87495d9781c9d7c3fec:1306:1
setAutoBind/ngCollection.unregisterAutoBind<@http://localhost:3000/packages/urigo_angular.js?f39a58528c9912d9069bc87495d9781c9d7c3fec:1278:15
$RootScopeProvider/this.$get</Scope.prototype.$digest@http://localhost:3000/packages/angular_angular.js?9db7e8edebe9ba02ab378f03d9a52d49148583ee:14338:23
$RootScopeProvider/this.$get</Scope.prototype.$apply@http://localhost:3000/packages/angular_angular.js?9db7e8edebe9ba02ab378f03d9a52d49148583ee:14601:13
cleanup@http://localhost:3000/client/lib/pad.js?28277c20ced0c42fb697d3fe810cb506bd047d23:184:5
commit@http://localhost:3000/client/lib/pad.js?28277c20ced0c42fb697d3fe810cb506bd047d23:174:5
endDraw/strokeTimeout<@http://localhost:3000/client/lib/pad.js?28277c20ced0c42fb697d3fe810cb506bd047d23:164:7
timeout/timeoutId<@http://localhost:3000/packages/angular_angular.js?9db7e8edebe9ba02ab378f03d9a52d49148583ee:16329:28
completeOutstandingRequest@http://localhost:3000/packages/angular_angular.js?9db7e8edebe9ba02ab378f03d9a52d49148583ee:4954:7
Browser/self.defer/timeoutId<@http://localhost:3000/packages/angular_angular.js?9db7e8edebe9ba02ab378f03d9a52d49148583ee:5342:7

Should be fixed in the last commits. Will be in the next version..

authors: gpothier netanelgilad

repo: Urigo/angular-meteor


text:
feat: Added support for @import

added support for @import

Thanks for you contribution @yj1438, but sorry, I'm not going to support @import keywords. You may find a deeper explanation of this design decision at this link. Thanks again.

repo: UstymUkhman/vite-plugin-glsl


text:
Added upstream command

Fixes #61
Short description of what this resolves:

What Changes proposed in this pull request:

Added command to set upstream in the local repository in Readme.md

Checklist

[x] Added description of change
[x] Added file name matches File name guidelines
[x] Added documentation so that the program is self-explanatory and educational.
[x] Relevant documentation/comments is changed or added
[x] PR title follows semantic commit guidelines
[x] Search previous suggestions before making a new one, as yours may be a duplicate.
[x] I acknowledge that all my contributions will be made under the project's license.

Notes:

May you please add this pull request under hacktoberfest if find relevant. Thank You, Do let me know about any other required changes

Thank you!

@tanishagupta1 why you pushed these commits in this PR, please undo these changes which you have made later, and please make a new PR then push those commits.
I will suggest to you make a new branch otherwise you may face merging conflicts issues, I have given step by step instructions on how to use version control, please follow that.

Yes I completely got the point sorry for the inconvenience, I'll fix it

Can you pls guide me as to if I should fetch and merge with the upstream branch and again make the commit or as I reverted the commit, it doesn't seem to resolve the issue

Ok, you just have reverted both the commits:

Add upstream command and
Add code in java

Now just make a commit for the adding upstream command again and That's it.

reverted to added upstream commit hope the issue is resolved now

@tanishagupta1 yes you did it! Thank you!

Thank you for the help!

Now In the future contribution please make a new branch and then contribute in that only, don't do contribution in the main branch.

yes definitely! taking the learnings with me.


text:
why reduce is static?

Hi Vadim
First I have to thank you for your great article.
I'm wondering is there any specific reason that you used static function for reduce or feedbacks (whenLoading, userInput)?

While I'm not the author of the article, I can at least partly answer your questions 🙂
They are static, because you should never need to access self inside them.
In case of reduce, it's also in the article:
Some of the states have associated values in order to draw them on the UI or to pass to the next state. Similarly, events carry data, which is the only source of information when we produce a new state inside a reduce() function.

In essence, the associated values of State and Event must be enough for you to determine the next state.
In case of feedbacks, either the State should be enough, or dependencies should be passed in as parameters.
However, the author conveniently hardcoded MoviesAPI inside the feedbacks and basically threw any notion of testability straight out the window...
Instead, that dependency must be injected.
The only question is, should it come with the State or should it be a parameter to the feedback function (ex: static func whenLoading(moviesApi: MoviesApi) -> Feedback<State, Event>).
I'm leaning more towards the 2nd approach of passing it as a parameter to the function.

Makes sense. I am wondering whether you have figured out a way of making conditional presentation of modal views work with this approach. Since this would require to somehow set a Binding in the View based on the state of the viewModel and this does not work in the body func. Subscribing to state in init also does not work since this is an escaping func. Just wondering

authors: JonnyBeeGod mehdok

license: Unlicense


text:
Literally Useless

You're missing well over 90% of the bot setup instructions 🤔
Do you just imagine everyone wanting to use this knows exactly how to set up oauth uris, how to grant access tokens, the proper permissions required, so on, so forth?
Yet another half-baked project, I'm the only person using it, and no updates to be seen.
Would like to see even an ounce of forethought sometimes.

Pretty sure there's an error on line 155

I made some readme fixes. Check the pull. I'll finish it later.
Hook me up with an invite link so I can add Ziggy to my server.
I want to try and make Az and Ziggy talk to eachother.


text:
Entity Diagram

Mini and Expanded Entity Diagrams using Visx
Buttons allow for switching of orientation and size
Animation using react-transition-group and css

Thanks Brett.  The animation isn't really working for me (in Firefox).  The small version remains on the screen.  Was that the plan?

Thanks Brett.  The animation isn't really working for me (in Firefox).  The small version remains on the screen.  Was that the plan?

@bobular ts error is fixed; merge conflict is also fixed

Thanks @moontrip

authors: bfox6 bobular moontrip

repo: VEuPathDB/web-components


text:
Deleting html instead of replacing src

Not working for me at all.
It is just deleting everything in index.html file, starting from the part that have to be modified:
So this part:
<!-- build:js -->
<script src="../bower_components/jquery/dist/jquery.js"></script>
<script src="js/app.js"></script>
<!-- endbuild -->

And everything bellow it disappears.
Here is my gulp task.
gulp.task('htmR', function() {
   gulp.src('app/index.html')
      .pipe(htmlreplace({
         js: 'js/bundleB.min.js'
      }))
      .pipe(gulp.dest('app/'));
});

Is it compatible with node 0.10?

I've been observing the behavior described above since we upgraded from 1.1.0 to 1.4.1. Parts of HTML are either skipped or entirely removed because of this issue.
It seems to be related to the way the parser handles line breaks. I was able to make things work with 1.4.1 by manually inserting line breaks after and before HTML comments marking the beginning and end of a snippet to replace.

@charlescaron Could you provide that HTML file? Not copy and paste contents, just the file itself. I can't reproduce such behavior no matter what i try. I tried to create HTML files with different line breaks in different OS'es with no luck.

FYI: also putting nothing between the start and end comment: <!-- build:css --><!-- endbuild --> results in everything below being deleted. Adding a line-break between them solves the issue.

Here are the links to the source and the output I get with both 1.1.0 and 1.4.1. Note that I'm on Mac OS X, but I'm observing the same behavior on CentOS 6.3.
Gulp version: 3.8.10
Node.js version: 0.10.32
Source:
https://drive.google.com/file/d/0B0RIKmSzYfVCdHcxSXE5SVZCRmM/view?usp=sharing
Output with 1.1.0 (Good):
https://drive.google.com/file/d/0B0RIKmSzYfVCRUZOX3VfSk1EY2s/view?usp=sharing
Output with 1.4.1 (Wrong):
https://drive.google.com/file/d/0B0RIKmSzYfVCVTBDenE4ZUZYalk/view?usp=sharing

Ah, finally, i see the problem now. Thanks @charlescaron ! Please test 1.4.2 and close this issue if it works

@JeroenNoten noted, thank you

1.4.2 works fine for me now, thanks!

authors: JeroenNoten VFK alexlime charlescaron

repo: VFK/gulp-html-replace


text:
GPU Memory Requirement

How much memory does training Aug-NeRF require? For my RTX 3070 with 8GB memory, it keeps running out of memory even when I set --ray_chunk 32 and --pts_chunk 256. Shall I give up training Aug-NeRF on my RTX 3070?

Hey Wei,
Thanks for your interest. In current implementation, neither changing --ray_chunk nor --pts_chunk would save memory cost. To save memory, we would suggest reduce --batch_size . Hope you will find this helpful.
Best,
Peihao

Hello Peihao, I've tried your suggestion with a batch size as small as 1, but my memory still got exceeded. Perhaps my memory is just not enough. Thanks for your timely support anyway.

authors: Ailon-Island peihaowang

repo: VITA-Group/Aug-NeRF


text:
chore: actionlintを導入

内容
actionlintを導入します。
関連 Issue
ref VOICEVOX/voicevox_core#341
スクリーンショット・動画など
その他

https://github.com/qryxip/onnxruntime-builder/actions/runs/10149167755

repo: VOICEVOX/onnxruntime-builder


text:
Windows向けのマルチバイト処理を追加した

Mecab_loadがWindowsだと文字エンコードの違いにより読み込めないのでlocaleによってMultibyte文字列を変換する処理を入れた
refs https://github.com/VOICEVOX/voicevox_core/pull/208#discussion_r930838316

不要になった