text:
Updated COTS_priority column to use GBRMPA 2024-2025 data

Replaced the older CoCoNet COTS_priority data with updated data from GBRMPA for 2024/25 year.

Please detail the data used and the source of data in readme.
If the data attribution and license info can't be found in the source data file, let me know.

I added some details, but yeah I couldn't see any license information in the data or email from 5/8

I added some details, but yeah I couldn't see any license information in the data or email from 5/8

Just had a quick look. It's in the first tab "Creative Commons License": the data is provided under CC BY-NC 4.0, something like:
"CoTS data provided by GBRMPA under CC BY-NC 4.0 (http://creativecommons.org/licenses/by-nc/4.0)"

I added some details, but yeah I couldn't see any license information in the data or email from 5/8

Just had a quick look. It's in the first tab "Creative Commons License": the data is provided under CC BY-NC 4.0, something like:
"CoTS data provided by GBRMPA under CC BY-NC 4.0 (http://creativecommons.org/licenses/by-nc/4.0)"

Sorry I don't see where that is, but good to know thank you. I've put that into the README now

Sorry I don't see where that is, but good to know thank you. I've put that into the README now

Are you looking in the provided Excel spreadsheet?

Are you looking in the provided Excel spreadsheet or something else?

Yes, TargetReefs_202425.csv ? I only see a single sheet in there since it's a csv file. Maybe I am missing an attachment, hopefully i didn't add the wrong data in

Oh sorry, thought you were adding data from the recent Excel spreadsheet (CSVs are not excel files).

authors: BG-AIMS ConnectedSystems

repo: gbrrestoration/canonical-reefs


text:
Nice function to get the Monad value

I have this use case:
import {Option, some, none} from "fp-ts/lib/Option";
interface TestObj {
    a: number,
    b: Option<number>
}

const pairs: Array<TestObj> = [
  {a: 1, b: some(1)},
  {a: 1, b: none},
];

function add(a: number, b: number) {
   return a+b;
}

// I want to add only the ones when b is some, just discard the rest
pairs
   .filter((p) => p.b.isSome())
   .map((p) => add(p.a, p.b.getOrElse(() => 0));

getOrElse function will never be hit, but I need it to be there if I want to get the value from b out of the Option. I know it exists b._A but the underscore kind of tells it's an internal value and shouldn't be used, doesn't it?
Is there any other way to solve this or can it be added a public function/property to get the value?

I know it exists b._A

_A is a "phantom type", i.e. a field that doesn't contain any value (it's there for type checking purposes, also it helps to implement HKTs)
You can use Option#fold I guess
pairs.reduce((acc, obj) => acc + obj.b.fold(() => 0, n => n + obj.a), 0)

or even shorter:
pairs.reduce((acc, obj) => acc + obj.b.isSome() ? obj.a : 0, 0)

@afharo I think it's the only way because filter does not tell type-system that all filtered values are now Some<number>s, they are still Option<number>. So if you you need to add a to b you still need to check wether b is a Just when extracting its actual value. You can do it only with getOrElse.

Yeah, I can use those, but, at the end either .fold or .getOrElse is all about providing a value when I already know that value is enforced to exist, making the code cumbersome and providing a branch that will never be covered.
The adding example was a very simple one to illustrate the example, but there are some other use cases like (if all should have a some() element in b)
// If at least 1 is none
if (pairs.find((p) => p.b.isNone()) {
   return doSomething()
} else {
  // All values in here are some, fold or getOrElse are redundant.
  return doSomethingUsingB()
}

Another use case where fold or getOrElse are not the best option:
const pairs: Array<TestObj> = [
  {a: 1, b: some({c: "test", d:3})},
  {a: 1, b: none},
];

// I need to apply casting
pairs
   .filter((p) => p.b.isSome())
   .map((p) => doWhatEver(p.a, p.b.getOrElse(() => ({} as PairsBInterface)));

// Or build a similar object
pairs
   .filter((p) => p.b.isSome())
   .map((p) => doWhatEver(p.a, p.b.getOrElse(() => ({c:"", d:0})));

Any of those options: apply casting or build a similar object don't seem to me like a valid option because none of them are valid. Yeah, I know it won't ever get in there but when reading the code, it kind of tells it could happen and, if it does happen, it will pass either a non-type-matching var (in running time) or a randomly invented value.

@raveclassic

I think it's the only way because filter does not tell type-system that all filtered values are now Somes, they are still Option.

Could this be because (from https://github.com/gcanti/fp-ts/blob/master/src/Option.ts#L199)
  isSome(): boolean {
    return true
  }

Shouldn't it be something like:
  isNone(): this is None<A> {
    return true
  }
  isSome(): this is Some<A> {
    return true
  }

From my tests, it still fails because of Array.filter typing... but it works with simple ifs ;)

FWIW there's a top level isSome which is a type predicate and AFAIK filter has an overloading which understands type predicates
const xs = [some(1), none]
// ys: Some<number>[]
const ys = xs.filter(isSome)

@afharo you are traversing pairs twice (filter + map). reduce + fold let you traverse only once in a type-safe way

@gcanti I did the reduce + fold option but then got some other typing inheritance issue (still to work on that one, though... ). Thank you for the suggestion.
I've noticed about the top level isSome and used it somewhere else (where the typing is properly inherited (not in filter))
Some sort of
if (isNone(bar)) {
   return endOfProcess()
}
...
a ton of logic...
...
callFunction(bar.value) // It works because the compiler understands bar is a Some at this point

@afharo You can call toNullable and then coerce to non-nullable type with !:
const foo = fromNullable(123); //Option<number>
const fooExact = foo.toNullable()!; //number

@raveclassic, that's actually a good move! thanks :)

@raveclassic ! is awfully unsafe and is strictly forbidden in this repo 😛
If you want to go fancy, you could use filterMap (though is traversing twice)
import { filterMap } from 'fp-ts/lib/Filterable'
import * as array from 'fp-ts/lib/Array'

filterMap(array)<TestObj, number>(obj => obj.b.map(n => n + obj.a))(pairs).reduce(add, 0)

@gcanti I understand it and I'd use getOrElse with reduce =)

@gcanti Maybe toNullable should be dropped at all, what was the point in adding it? It's unsafe and moves developers to bypass type constraints.

@raveclassic , toNullable can be useful when working with the external APIs. Without it you will use fold. Unfortunately there is no function toUndefined that can be used for that. For example, when creating properties for react component. @gcanti , will you accept the PR with it's implementation?

@raveclassic for interop
@vegansk yes

@vegansk, @gcanti I see. But isn't getOrElse(constant(null)) or getOrElse(constant(undefined)) enough as it's more general?

@gcanti Also why does getOrElse accept a lazy value? Was it an intentional decision?

@raveclassic Immagine the alternate value being the result of a long computation, it would be nice to have it being executed only when required.

@sledorze Well, the typical usage is to provide a quick default value to get wrapped value from Option. At least in my practise I always end up with constant call. But I got the point though, thx

@raveclassic, your method doesn't work. The code:
let x: string | undefined = "a"

let y = option.fromNullable(x).getOrElse(constant(null))

fails to compile
ERROR in ./src/core/utils/fp.spec.ts
(80,46): error TS2345: Argument of type 'Lazy<null>' is not assignable to parameter of type 'Lazy<string>'.
  Type 'null' is not assignable to type 'string'

@vegansk Oops :) Now it does seem like a good place for toNullable/toUndefined

source: gharchive/issue

authors: afharo gcanti raveclassic sledorze vegansk

repo: gcanti/fp-ts

license: mit

license_type: permissive

license_source: bigquery


text:
Does not work correctly on Taylor & Francis journal

https://tandfonline.com/

Duplicate of #22 , preliminary fix in #27 but never merged/released because I'm thinking of an updated version that will fetch custom regex's per-site.

authors: gchenfc jackyzfy

repo: gchenfc/sci-hub-now

license: WTFPL

license_source: github-api


text:
Gh-1345 Extract Items

New Map and FlatMap operations implemented - these operations take in an Iterable, and an Iterable of Iterables respectively, returning an object and an iterable respectively.
This is achieved by executing a function on the input (see gchq/koryphe#60).
Should not be merged until the Koryphe branch above is completed and merged in.

Codecov Report

Merging #1481 into develop will increase coverage by 8.59%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             develop    #1481      +/-   ##
=============================================
+ Coverage      66.58%   75.18%   +8.59%
+ Complexity      1744      320    -1424
=============================================
  Files            723       58     -665
  Lines          23633      931   -22702
  Branches        2984       54    -2930
=============================================
- Hits           15737      700   -15037
+ Misses          6687      185    -6502
+ Partials        1209       46    -1163

Impacted Files
Coverage Δ
Complexity Δ

...hq/gaffer/commonutil/iterable/ChainedIterable.java

...va/uk/gov/gchq/gaffer/cache/impl/HashMapCache.java

...tion/handler/generate/GenerateElementsHandler.java

...peration/validator/function/FunctionValidator.java

...handler/job/tool/ImportElementsToAccumuloTool.java

...re/serialisation/impl/DoubleParquetSerialiser.java

.../gov/gchq/gaffer/operation/impl/output/ToList.java

...ffer/operation/impl/add/AddElementsFromSocket.java

...ion/handler/named/DeleteNamedOperationHandler.java

...operation/handler/output/ToEntitySeedsHandler.java

... and 652 more

Continue to review full report at Codecov.

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

source: gharchive/pull-request

repo: gchq/Gaffer


text:
Issue 309 - Create SQS message handlers

Resolves #309

I think it would probably be easier to just move most of the code in IngestJobQueueConsumer.ingest into its own class. Rather than trying to extract the SQS code out of IngestJobQueueConsumer, we can just make the only responsibility of IngestJobQueueConsumer the communication with AWS, and limit the number of integration tests that use that.

Closing, going with issues #311 and #312.

repo: gchq/sleeper


text:
IndexOutOfBoundsException at StreamEncoder.write TextWriter line 94

This was caused while investigating #419 with a pipeline with a TextWriter but no XSLT set in the pipeline.

Unable to reproduce

repo: gchq/stroom


text:
🛑 Inovamed is down

In 1fc15af, Inovamed ($INOVAMED) was down:

HTTP code: 200
Response time: 1085 ms

Resolved: Inovamed is back up in 236c556 after 5 hours, 38 minutes.

repo: gcommeuneidee/upptime

license: MIT


text:
Anchor links and Menu Nav issue

Originally created by Rick Massie on Sept. 18
When creating an anchor link, the page jumps to the correct anchor.
However, the anchor ends up being hidden underneath the top nav menu. I'm not sure exactly what is happening, but somehow the Nav menu seems to be "floating" above the rest of the content, and since the browser bring anchor links to the top of the content area, it actually ends up hidden under the nav menu.

Closed with pull request #132

authors: ethanWallace s-duffey

repo: gctools-outilsgc/design-system-code


text:
Add terminfo for kitty

I added a generated terminfo file for kitty.

@gdamore  Done.

I think you probably also want to add a reference to this to the extended/extended.go package, otherwise nothing will use it unless they explicitly import your package.

Added.

Thank you for your contribution.  I will point others at this who are submitting similar additions.

authors: Tyilo gdamore

repo: gdamore/tcell


text:
Mark tui-go as deprecated

As mentioned at on its homepage, the project is no longer being maintained and has been archived

I almost wonder if we should just remove it.


text:
Improve the quality of cards

The current implementation for API Card is not satisfactory and doesn't look good.
This should be improved.
Also, this should be implemented alongside with #7

Assign it to me. will be tweaking card UI little-bit

@Insomniac2904 raise a PR. I'll assign you then.

Sorry Currently Out of Town. Cant work on it .

@Insomniac2904 are you working on this? I created a mock UI for something that we can work on. Can you design cards in this format?
If not feel free to say NO!

@devsargam @Ryrahul  made a pr, please review it and let me know if an edit is required!

@devsargam  is reviewing the PR , looks good though!!

Fixed in #23 by @rajksd01!

repo: gdsc-fetju/api-collection


text:
CSIRIM STRING

Related Issue

Info about the related issue

Closes: #[issue number that will be closed through this PR]
Describe the changes you've made
I have added the solution of the codeforces  problem  .The solution is written in C++.
link - https://codeforces.com/contest/1579/problem/A
Type of change
What sort of change have you made:
solution to problem.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Programming language

[ ] C
[x ] C++
[ ] Java
[ ] Python
[ ] Javascript

Screenshots(optional)

Original
Updated

original screenshot
updated screenshot

hey what dose that 1/5 tasks or 2/10 tasks writen beside pr's name mean?

Hey! could you please raise an issue with problem link and then create a PR

add problem link in the code too
you need to add your file in a particular
platform

problem name

file

I'm closing this PR for now!

you can look at this PR #51

Hey! could you please raise an issue with problem link and then create a PR

add problem link in the code too

you need to add your file in a particular

platform

problem name

file

I'm closing this PR for now!

you can look at this PR upload problem 1560C #51

OHK i wiil do now.

repo: gdsc-gvp/Problem-Solving


text:
Aruba's data is incomplete

I would like to add Aruba's geographical info to the database.
Please assign me this issue.
Thanks in advance.

@shubhansu-kr you can work on this issue now

Hey @Boanerges1996,
Thanks for assigning me this issue. I have created a PR for the same.
Please review the Pull #108.
ThankYou

repo: gdsclpu/OpenWorldAPI


text:
导入Android studio 编译无法通过

Error:Configuration with name 'default' not found.
这个错报的我有点无语！ google了但是不懂，怎么调！

删除工程目录setting.gradle文件中的", ':library'"和"include ':networkimageloader'"
删除Fun模块build.gradle文件中的"compile project(path: ':library')"
继而，可以编译通过
但是当你运行时，依旧错误连连：有类名与java文件名不一致（OnRefreshListener.java等），有类文件找不到（TouchImageView.java）。

我的也是楼上的错误，作者能不能先自己测试一下再发布啊！照顾一下新人。还有总是提示缺少module，作者应该使用正确的删除module方法，而不是简单地使用delete。

你pull一下，是我忘记提交library了，应该可以了 ，如果OK的 话，顺便close issue

@ZhangLanqiu @LittleWaver @xlc1540697096 解决了吗？

编译通不过现在已经解决了
PS：两个类名和文件名不一致（FunAPP\Fun\src\main\java\com\xujun\funapp\model\PictureDetailModel.java; FunAPP\Fun\src\main\java\com\xujun\funapp\common\OnRefreshListener.java）

楼主，还是在报错，各种不存在
和楼上一样的错误，而且还有其他的错误

没法看,错误很多,建议作者再看下

现在已经是基本可以了的
pull一下或者重新导入AS
再修改文件名FunAPP\Fun\src\main\java\com\xujun\funapp\model\PictureDetailModel.java; FunAPP\Fun\src\main\java\com\xujun\funapp\common\OnRefreshListener.java
就可以编译通过并生成apk

我遇到这两个文件，将类改成小写的好像就行了

我的也弄好了，改名即可。

嘿嘿

我感觉我看不懂代码，咋办呢？好纠结

好，那就Ok了，那我就close掉这个issue

authors: LittleWaver ZhangLanqiu firstxia gdutxiaoxu xlc1540697096 zhangy163

repo: gdutxiaoxu/FunAPP


text:
🛑 COM GURU is down

In 0bd2fe4, COM GURU ($SITE_COM_GURU) was down:

HTTP code: 0
Response time: 0 ms

Resolved: COM GURU is back up in 42afe40 after 7 minutes.

repo: gedesco-git/uptime


text:
pushToken is null on android ios working fine

Description:
pushToken is always null userId has an actual value but pushToken is always null on android.
iOS is working fine returning both pushToken and userId
(your description here)
Environment
Android
3.2.7
following the installation guidelines from documentation

Please post more information than this. For example, what version of RN are you using? Is this occurring on all android devices, just some? Is it occurring on some specific version/s of android or all?
Closing due to a lack of detail - but I will reopen once you post more information.

i had the same issue and checked the RNOneSignal class. Looks like you have to call OneSignal.configure() to trigger ids events.
It fixed the problem for me.

did you call init(APP_ID) before ?

constructor(properties) {
    super(properties);
    OneSignal.setLogLevel(7, 0);
    OneSignal.init(onesignal_app_id);
    OneSignal.configure();
  }

componentDidMount() {
     this.onIds = this.onIds.bind(this);
     OneSignal.inFocusDisplaying(2);
     OneSignal.addEventListener('ids', this.onIds);
}

authors: Mubashirkhan Nightsd01 alimek

repo: geektimecoil/react-native-onesignal


text:
Remove deprecated method for RN 0.47 compat

The component doesn't compile in RN 0.47-rc5 - discussion at https://github.com/facebook/react-native/issues/15232

Recommend checking out #294, just removing the @Override marker - that should be compatible with 0.46.x and 0.47.x.
This change as-is, I believe, will break 0.46.x.

Yes. Seems my crying has been heard finally

I think I let this open until you decide which way to go.

As #294 has been merged it would nice to release a new npm version.

#294 already merged - this can indeed be closed and we need an npm version!  Thanks a lot.

authors: forki lukecwilliams tapz


text:
[Feature]: Cherry-pick commits when generating a changelog

Describe your feature
uplift provides functionality for excluding commits from a changelog through an --exclude flag. This works well for standalone repositories but can be problematic when mono-repos pepper the log with commits from multiple components.
uplift should provide a mechanism where it is possible to select (or cherry-pick) explicitly commits from the git log when generating a changelog.
Your potential solution
Introduce a new --include flag capable of cherry-picking commits.
Any additional information?
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Having both --include and --exclude options is an important capability. From client perspective, I think the appropriate behavior should be:

--include implicitly states you want to exclude everything else
You can support both --include and --exclude in the same execution. This will allow excluding some commits from the subset included commits. For example, --include myService --exclude wip will first filter commits that includes myService, and afterwards exclude from that set commits matching the wip. The result is what you want to show in the CHANGELOG.

WDYT?

I agree with everything you have said here. I have almost finished implementing this feature as described. 😄

@ga-paul-t I think there's a bug here; when I'm running --include with multiple params, the logic is AND instead of OR.
func filterCommits(commits []git.LogEntry, regexes []string, filter commitFilter) ([]git.LogEntry, error) {
	filteredCommits := commits
	for _, regex := range regexes {
		rgx, err := regexp.Compile(regex)
		if err != nil {
			return filteredCommits, err
		}
		filteredCommits = filter(filteredCommits, rgx) # the bug is here
	}

	return filteredCommits, nil
}

The loop iterates over commits, and filters them each time, passing the filtered commits instead of the original ones. This causes AND between the regex patterns, usually ending with an empty list.

Thanks for spotting this. Serves me right for coding at 5 am. A bit of shameful cut and pasting there :blush:

I pushed a possible fix for this 😄 indeed it looks like these can be abstracted as they share most of the code, but their logic is different. So it can't work with a commitFilter function.

authors: canidam ga-paul-t

repo: gembaadvantage/uplift


text:
Zfin import models

round 2 attempt for a clean PR into master of all ZFIN models, without spurious deletes that we saw in: https://github.com/geneontology/noctua-models/pull/182
The large number of commits is just a result of the number of files being too long to add in a single commit.
Travis is failing because the logging output is too long - should we just move to github actions?

@sierra-moxon The models I spot-checked look good! Unfortunately there's a bug we discovered in the ART workshop today that affects Noctua Form and ShEx. I'm testing a fix for this right now. Once it's merged into ontobio the models would need to be regenerated. Sorry!

@sierra-moxon OK, that bug's been fixed in ontobio so, if you git pull from master and regen, you should be good. Unfortunately, you'd also have to reset the modelstate to "production" again. Grr, need to add that option to the gocamgen code.

@dustine32 - ok, another attempt - these should have 'production' status, and providedBy tag.  (see accompanying dev PR: https://github.com/geneontology/noctua-models/pull/187) :) Would you mind taking a quick look? (not ready to merge until rest of testing has been done).

Here we go!

authors: dustine32 kltm sierra-moxon

repo: geneontology/noctua-models


text:
Specifications for BP only implementation of SAE

The form should allow curators to choose from a drop-down list (above the BP line) to specify the relation between the gene product and the Biological Process term.
The relations to include are (in order from top-to-bottom in the drop-down list):
acts upstream of or within (RO:0002264)
-acts upstream of or within, positive effect (RO:new)
-acts upstream of or within, negative effect (RO:new)
-acts upstream of (RO:0002263)
--acts upstream of, positive effect (RO:new)
--acts upstream of, negative effect (RO:new)
RO:new = pending a new relation in the Relations Ontology
@tmushayahama - you can wait on implementing this until we have unique ids for each of the RO:new entries.

@vanaukenk what is the status of the new RO ids?

@cmungall - do we have the new RO ids for these terms, and their cognate process-process relations?

Yes, these are in RO,

RO:0002263 ! acts upstream of
RO:0002331 ! involved in
RO:0002428 ! involved in regulation of
RO:0002429 ! involved in positive regulation of
RO:0002430 ! involved in negative regulation of
RO:0002431 ! involved in or involved in regulation of
RO:0004032 ! acts upstream of or within, positive effect
RO:0004033 ! acts upstream of or within, negative effect
RO:0004034 ! acts upstream of, positive effect
RO:0004035 ! acts upstream of, negative effect
RO:0002264 ! acts upstream of or within *

Note: the URLs above resolve to ontobee which lags behind the release, so don't be worried if the new ones do not resolve. For browsing I recommend OLS, from this node: https://www.ebi.ac.uk/ols/ontologies/ro/properties?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FRO_0002264
(It looks like OLS isn't displaying property chains, I'll check what the status of that is.)
We also sync this with a list on our wiki, in this category:
http://wiki.geneontology.org/index.php/Category:Gene_Product_to_Term_Relations

@thomaspd I am assuming acts upstream of or within, positive effect will map to directly positively regulates on BP Only?

I think RO is still missing:
causally upstream of or within, positive effect
causally upstream of or within, negative effect
Also, since we've got positive and negative effect for all of these, for completeness (so we don't lose the effect direction when we increase the specificity) do we also want:
part of, negative effect
part of, positive effect

I think RO is still missing:
causally upstream of or within, positive effect
causally upstream of or within, negative effect

we have these:
https://www.ebi.ac.uk/ols/ontologies/ro/properties?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FRO_0002304
https://www.ebi.ac.uk/ols/ontologies/ro/properties?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FRO_0002305
note these are occurrent-occurrent relations
we do not have these:

part of, negative effect
part of, positive effect

@thomaspd
part of, negative effect
part of, positive effect
is the intent that these would be available for curators to use in their models?  If so, do you have examples in mind that we could add to the documentation?
And yes, for the graphical editor, we will still need:
causally upstream of or within, positive effect
causally upstream of or within, negative effect

The BP only version of the form is currently not allowing me to save a BP annotation and the error message says:
Molecular Function: No evidence for 'Molecular Function'

@tmushayahama - we still need to add the acts upstream of or within, negative effect and acts upstream of or within, positive effect relations to the BP only dropdown.
In the graph editor they will have causally upstream of or within, negative effect and causally upstream of or within, positive effect relations to the MF term.  Thx.

@tmushayahama
I've also tested all of the BP only relations and everything looks good here, too.

authors: cmungall thomaspd tmushayahama vanaukenk

repo: geneontology/simple-annoton-editor


text:
Is idinvert suitable to do super-resolution?

If so, could you please give us a demo?
Thanks!

You can try to feed the low-resolution images into the encoder and check whether the output images are satisfying. For example, you have an image with the resolution 16x16. You can directly resize it to 256x256 and then feed it into the encoder, resulting in an inverted code. The generator will decode the code to a 256x256 image, which is assumed to be the super-resolution result of the original 16x16 image.

I see. Don't we need to optimize the inverted code that the encoder generated?

authors: ShenYujun juzuo


text:
Kazuha A4 does not distinguish between % based EM buffs and flat EM buffs

https://gcsim.app/v3/viewer/share/a8119d88-4f85-4fdc-9591-69073aa8aeec
in this config, Kazuha A4 is being boosted by Sucrose A4 which is not supposed to happen

//this ignores any EM he gets from Sucrose A4, which is: When Astable Anemohypostasis Creation
//- 6308 or Forbidden Creation - Isomer 75 / Type II hits an opponent, increases all party
//members' (excluding Sucrose) Elemental Mastery by an amount equal to 20% of Sucrose's
//Elemental Mastery for 8s.
//
//he still benefits from sucrose em but just cannot share it

this is commented above Kazuha A4's code but is not actually implemented

closing in favor of #1016

repo: genshinsim/gcsim


text:
Add option to increment counter by tapping display value

Fixes #25

Thanks!

authors: gentlecat silentmatt

repo: gentlecat/counter


text:
Malformed auth challenge header on layer upload

I am using the latest genuinetools/reg master api to move images from one registry to another.
Ping, Login, HasLayer and Listing are working fine on both the target and source registry.
However I get this error when I try to push the layer to the target registry which is in version 2.6.2.
"Post https://target.example.com/v2/pdr/tls-proxy/blobs/uploads/:
malformed auth challenge header: 'Bearer realm=\"https://docker.example.com/v2/token\",service=\"target.example.com\",scope=\"repository:pdr/tls-proxy:pull,push\"'"
time="2018-06-02T18:24:47+02:00" level=info msg="Tag := 1.3.2"

This is the log excerpt from the registry itself.
time="2018-06-02T21:25:09.957720975Z"
level=warning msg="error authorizing context: authorization token required"
go.version=go1.7.6
http.request.contenttype="application/octet-stream"
http.request.host=target.example.com
http.request.id=78dc7065-d1cc-4e09-923c-9d96527f0a3d
http.request.method=POST
http.request.remoteaddr=88.152.186.104
http.request.uri="/v2/pdr/tls-proxy/blobs/uploads/"
http.request.useragent="Go-http-client/2.0"
instance.id=19e1450d-f69e-4fe2-9463-025bd1d4426e service=registry
vars.name="pdr/tls-proxy" version=v2.6.2

172.18.0.5 - - [02/Jun/2018:21:25:09 +0000] "POST /v2/pdr/tls-proxy/blobs/uploads/ HTTP/1.1" 401 228 "" "Go-http-client/2.0"

I think I found the error, it is because of the push, pull scope
See Line 39

repo: genuinetools/reg


text:
transformer >99.98% test accuracy in ~30s

Transformer gets them all correct (occasionally). Feel free to only add the BS+1 in training.py.

some parameters tweaked
learning rate decay
displaying what transformer gets wrong if accuracy is high

Sample Output:
loss 0.37 accuracy 0.87: 100%|██████████████████| 50/50 [00:05<00:00,  8.66it/s]
100%|███████████████████████████████████████████| 16/16 [00:00<00:00, 25.79it/s]
test set accuracy is 0.865583
reducing lr to 0.0025
loss 0.28 accuracy 0.89: 100%|██████████████████| 50/50 [00:05<00:00,  9.25it/s]
100%|███████████████████████████████████████████| 16/16 [00:00<00:00, 19.07it/s]
test set accuracy is 0.884583
reducing lr to 0.0021
loss 0.19 accuracy 0.92: 100%|██████████████████| 50/50 [00:05<00:00,  9.14it/s]
100%|███████████████████████████████████████████| 16/16 [00:00<00:00, 26.34it/s]
test set accuracy is 0.911417
reducing lr to 0.0017
loss 0.14 accuracy 0.93: 100%|██████████████████| 50/50 [00:05<00:00,  9.30it/s]
100%|███████████████████████████████████████████| 16/16 [00:00<00:00, 26.27it/s]
test set accuracy is 0.939833
reducing lr to 0.0014
loss 0.11 accuracy 0.95: 100%|██████████████████| 50/50 [00:05<00:00,  9.17it/s]
100%|███████████████████████████████████████████| 16/16 [00:00<00:00, 25.50it/s]
test set accuracy is 0.960750
reducing lr to 0.0012
loss 0.06 accuracy 0.97: 100%|██████████████████| 50/50 [00:05<00:00,  9.17it/s]
100%|███████████████████████████████████████████| 16/16 [00:00<00:00, 21.51it/s]
test set accuracy is 0.978333
reducing lr to 0.0010
loss 0.02 accuracy 1.00: 100%|██████████████████| 50/50 [00:05<00:00,  9.29it/s]
100%|███████████████████████████████████████████| 16/16 [00:00<00:00, 26.97it/s]
test set accuracy is 0.993333
reducing lr to 0.0008
loss 0.01 accuracy 1.00: 100%|██████████████████| 50/50 [00:05<00:00,  9.22it/s]
100%|███████████████████████████████████████████| 16/16 [00:00<00:00, 26.46it/s]
test set accuracy is 0.999417
reducing lr to 0.0007
78 + 68 = 142 (correct: 146)
38 + 68 = 104 (correct: 106)
91 + 11 = 101 (correct: 102)
93 + 38 = 136 (correct: 131)
70 + 68 = 134 (correct: 138)
98 + 37 = 130 (correct: 135)
88 + 68 = 154 (correct: 156)
Wrong predictions: 7, acc = 0.9994
loss 0.00 accuracy 1.00: 100%|██████████████████| 50/50 [00:05<00:00,  8.84it/s]
100%|███████████████████████████████████████████| 16/16 [00:00<00:00, 21.46it/s]
test set accuracy is 1.000000
reducing lr to 0.0006
Wrong predictions: 0, acc = 1.0000
loss 0.00 accuracy 1.00: 100%|██████████████████| 50/50 [00:05<00:00,  9.23it/s]
100%|███████████████████████████████████████████| 16/16 [00:00<00:00, 26.55it/s]
test set accuracy is 0.999833
reducing lr to 0.0005
78 + 68 = 142 (correct: 146)
88 + 68 = 152 (correct: 156)
Wrong predictions: 2, acc = 0.9998

Yes because // is floor of / and you want ceil. There is probably a more pythonic way to do it, though.

On Dec 30, 2020, at 6:51 PM, George Hotz notifications@github.com wrote:
@geohot commented on this pull request.
In extra/training.py:

 Y_test_preds_out = np.zeros(list(Y_test.shape)+[num_classes])

for i in trange(len(Y_test)//BS, disable=os.getenv('CI') is not None):

for i in trange((len(Y_test)-1)//BS+1, disable=os.getenv('CI') is not None):
You sure you need this?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

’-(-x//BS)’
Sent from my iPhone

On Dec 30, 2020, at 8:46 PM, Marcel Bischoff mrclbschff@gmail.com wrote:
Yes because // is floor of / and you want ceil. There is probably a more pythonic way to do it, though.

On Dec 30, 2020, at 6:51 PM, George Hotz notifications@github.com wrote:
@geohot commented on this pull request.
In extra/training.py:

 Y_test_preds_out = np.zeros(list(Y_test.shape)+[num_classes])

for i in trange(len(Y_test)//BS, disable=os.getenv('CI') is not None):

for i in trange((len(Y_test)-1)//BS+1, disable=os.getenv('CI') is not None):
You sure you need this?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I think it is ready to go. I also fixed serious_mnist

I think it is ready to go. I also fixed serious_mnist

repo: geohot/tinygrad


text:
Command line options --geopm-barrier and --geopm-plugin don't match corresponding environment variable

The documentation states that the CLI options are the same as the environment variables but lowercase and with the hyphens replaced with underscores.  This is not true for these options.  Note that --geopm-ctl also does not match, but the option and the environment variable have slightly different behavior.

Also, GEOPM_RM could/should be renamed to GEOPM_LAUNCHER.

authors: bgeltz dianarg

repo: geopm/geopm


text:
Bug Fix for SELECT with uppercase columns (Approach 1)

Problem Statement
Select query for tables with tables with upper case columns wasn't working: Issue 1079

Solution
Since the design principle of EvaDB is that the columns are to be treated as lower case, the solution consisted of the following steps:

Modify CREATE TABLE command to convert columns passed as input to lower case. This means that table itself has lower cased columns from the start.
With above change, SELECT works successfully.
However, INSERT command still didn't convert columns to lower case, and was giving same error as column not found. Hence, also modified backend of INSERT command to convert columns to lower case.

Output after Bug Fix

Just a doubt: currently even though I have converted columns to always remain lower case, tupleexpression attributes still remain in original case, would that be an issue?
For example in they remain "featCol" instead of "featcol" in test case tests/unit_tests/parser/test_parser.py::ParserTests.test_create_index_statement().

Also, all test cases passed locally, except these three:
FAILED test/integration_tests/long/test_create_table_executor.py::CreateTableTest::test_should_create_table_from_select_lateral_join - AssertionError: False is not true FAILED test/integration_tests/long/test_single_document_similarity.py::SingleDocumentSimilarityTests::test_single_pdf_should_work - evadb.executor.executor_utils.ExecutorError: 'mypdf._row_number' FAILED test/unit_tests/test_eva_cmd_client.py::CMDClientTest::test_evadb_client - RuntimeError: There is no current event loop in thread 'MainThread'. ======================================================================================== 3 failed, 538 passed, 30 skipped, 13 deselected, 2 xfailed, 1 xpassed, 24 warnings in 5738.51s (1:35:38) ======================================================================================== FULL TEST CODE: --|1|-- FAILURE
However, when I ran each of them individually in visual code pytests, each of them passed without any issues. Not sure, why they weren't working when running them in bundle.

repo: georgia-tech-db/evadb


text:
Missing support for layer creation options

I need to pass OVERWRITE=YES in case the target layer already exists, so passing null_mut() as the last argument to OGR_DS_CreateLayer is counterproductive for me.
I propose to merge create_layer and create_layer_blank into a single function, create_layer, which takes a new struct LayerOptions that implements Default. This is consistent with how Dataset::open_ex works with DatasetOptions.
I'll create a PR soon, but if anyone already has some input, please give a shout.

sounds like a good idea

authors: jdroenner ttencate

repo: georust/gdal


text:
prevent SIGSEGV for non-strings on read string method

[x] I agree to follow the project's code of conduct.
[x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

I noticed that there is a segmentation fault when calling read_as_string for the MDArray if it is not of type string.
This is why I check for its datatype first.
Moreover, there are new Clippy lints that I had to consider.

What's wrong with the Eq derive and should GdalError even implement PartialEq?

What's wrong with the Eq derive and should GdalError even implement PartialEq?

PartialEq is currently derived and super practical when writing tests. However, if you have one error that is not PartialEq, e.g. from std::io, you are lost there and have to change it.
This is why I would like to not enforce Eq. Moreover, Eq already does not work for the ndarray gated error.
Then, the LTS does not know about this Lint at all… so I had to find a workaround there.

The crucial part of this PR are the spurious SIGSEGVs that sometimes occur. If I run it locally, I get these every 10-15 runs.
If I run something like
RUSTFLAGS="-Z sanitizer=memory -Zsanitizer-memory-track-origins" cargo +nightly-2022-06-16-x86_64-unknown-linux-gnu test -Z build-std --target x86_64-unknown-linux-gnu --all-features -- raster::mdarray::tests::test_array_names

I get
Uninitialized bytes in MemcmpInterceptorCommon at offset 0 inside [0x702000003040, 8)
==144725==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x55c8379013ce  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x803ce) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #1 0x7efddeac9934  (/lib/libgdal.so.30+0x10ed934) (BuildId: 965b1b7ee55bf9bdb5298fb4af151db56451b22c)
    #2 0x7efddeaf94ec  (/lib/libgdal.so.30+0x111d4ec) (BuildId: 965b1b7ee55bf9bdb5298fb4af151db56451b22c)
    #3 0x7efddeac5dbe  (/lib/libgdal.so.30+0x10e9dbe) (BuildId: 965b1b7ee55bf9bdb5298fb4af151db56451b22c)
    #4 0x7efddeac5f89  (/lib/libgdal.so.30+0x10e9f89) (BuildId: 965b1b7ee55bf9bdb5298fb4af151db56451b22c)
    #5 0x7efddeac7093  (/lib/libgdal.so.30+0x10eb093) (BuildId: 965b1b7ee55bf9bdb5298fb4af151db56451b22c)
    #6 0x7efddea83961  (/lib/libgdal.so.30+0x10a7961) (BuildId: 965b1b7ee55bf9bdb5298fb4af151db56451b22c)
    #7 0x7efddea83acf  (/lib/libgdal.so.30+0x10a7acf) (BuildId: 965b1b7ee55bf9bdb5298fb4af151db56451b22c)
    #8 0x7efdde4e4458  (/lib/libgdal.so.30+0xb08458) (BuildId: 965b1b7ee55bf9bdb5298fb4af151db56451b22c)
    #9 0x7efdde4e4544  (/lib/libgdal.so.30+0xb08544) (BuildId: 965b1b7ee55bf9bdb5298fb4af151db56451b22c)
    #10 0x7efdde053ddc  (/lib/libgdal.so.30+0x677ddc) (BuildId: 965b1b7ee55bf9bdb5298fb4af151db56451b22c)
    #11 0x55c83799cefe  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x11befe) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #12 0x55c8379b381e  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x13281e) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #13 0x55c839f0296d  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x268196d) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #14 0x55c8379b34c6  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x1324c6) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #15 0x55c837c2e8eb  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x3ad8eb) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #16 0x55c837cd2b3d  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x451b3d) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #17 0x55c837d1935e  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x49835e) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #18 0x55c837b0e095  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x28d095) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #19 0x55c837ed6fb5  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x655fb5) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #20 0x55c837ac13e2  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x2403e2) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #21 0x55c839039eb0  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x17b8eb0) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #22 0x55c83922e224  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x19ad224) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #23 0x55c83922e133  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x19ad133) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #24 0x55c839031e83  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x17b0e83) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #25 0x55c839100a0a  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x187fa0a) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #26 0x55c83910da34  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x188ca34) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #27 0x55c839128d21  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x18a7d21) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #28 0x55c83917a5a9  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x18f95a9) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #29 0x55c8391251a3  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x18a41a3) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #30 0x55c83902c50a  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x17ab50a) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #31 0x55c83922f87b  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x19ae87b) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #32 0x55c83922d660  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x19ac660) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #33 0x55c83922de52  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x19ace52) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #34 0x55c838f96391  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x1715391) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #35 0x55c839124824  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x18a3824) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #36 0x55c83910d522  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x188c522) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #37 0x55c8391288e1  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x18a78e1) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #38 0x55c83917a5a9  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x18f95a9) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #39 0x55c839125ac0  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x18a4ac0) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #40 0x55c83902c865  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x17ab865) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #41 0x55c839123f29  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x18a2f29) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #42 0x55c839032ab2  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x17b1ab2) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #43 0x55c839e9b98a  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x261a98a) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #44 0x55c839e9bcba  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x261acba) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #45 0x55c839658c85  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x1dd7c85) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #46 0x7efddd9a6608  (/lib/x86_64-linux-gnu/libpthread.so.0+0x8608) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
    #47 0x7efddd776132  (/lib/x86_64-linux-gnu/libc.so.6+0x11f132) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)

  Uninitialized value was created by a heap allocation
    #0 0x55c8378fd540  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x7c540) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
    #1 0x7efdda311b38  (/lib/x86_64-linux-gnu/libstdc++.so.6+0xaab38) (BuildId: c90e6603c7cdf84713cd445700a575d3ea446d9b)

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-95f474802ad15760+0x803ce) (BuildId: 0010e2250ad2ba7f4a92db43e0ed0f9ff4febf4c)
Exiting
error: test failed, to rerun pass '--lib'

Do you or anyone know how it can pinpoint me to the problem (e.g. line of code)?
I haven't used this before.

PartialEq is currently derived and super practical when writing tests.

I don't think it's worth the trouble. A couple of unwrap()s in tests are going to be fine.

The crucial part of this PR are the spurious SIGSEGVs that sometimes occur. If I run it locally, I get these every 10-15 runs.

Does that happen only in this PR, but not on master?

I get this backtrace on every test, it might be a false positive:
running 1 test
Uninitialized bytes in __interceptor_strlen at offset 24 inside [0x7020000021a0, 25)
==334233==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x7f80729164eb in VSIFileManager::GetHandler(char const*) (/usr/lib/libgdal.so.31+0x3164eb) (BuildId: d5ca43948a126d3ccc6e0373186f43ab677c25e9)
    #1 0x7f80729169d1 in VSIStatExL (/usr/lib/libgdal.so.31+0x3169d1) (BuildId: d5ca43948a126d3ccc6e0373186f43ab677c25e9)
    #2 0x7f80731e789a in GDALDriverManager::AutoLoadDrivers() (/usr/lib/libgdal.so.31+0xbe789a) (BuildId: d5ca43948a126d3ccc6e0373186f43ab677c25e9)
    #3 0x7f8072ea8c76 in GDALAllRegister (/usr/lib/libgdal.so.31+0x8a8c76) (BuildId: d5ca43948a126d3ccc6e0373186f43ab677c25e9)
    #4 0x55a2119cd11e in gdal::driver::_register_drivers::_$u7b$$u7b$closure$u7d$$u7d$::hbe592a9f2bb886d8 /home/grayshade/Projects/georust/gdal/src/driver.rs:22:13
    #5 0x55a211ae798e in std::sync::once::Once::call_once::_$u7b$$u7b$closure$u7d$$u7d$::h8c5a879f5913a6e1 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/once.rs:276:41
    #6 0x55a213e990ad in std::sync::once::Once::call_inner::hd45b00db8ff66d4d /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/once.rs:434:21
    #7 0x55a211ae7636 in std::sync::once::Once::call_once::hc896786934c25371 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sync/once.rs:276:9
    #8 0x55a211986ceb in gdal::driver::_register_drivers::h044c3b116d743ac5 /home/grayshade/Projects/georust/gdal/src/driver.rs:21:9
    #9 0x55a211e0793d in gdal::dataset::Dataset::_open_ex::hd4f38d57a5c2493c /home/grayshade/Projects/georust/gdal/src/dataset.rs:236:9
    #10 0x55a211f25fbe in gdal::dataset::Dataset::open_ex::h2b42e2e35abcb1a2 /home/grayshade/Projects/georust/gdal/src/dataset.rs:232:9
    #11 0x55a21196ff91 in gdal::raster::mdarray::tests::test_read_string_array::hc6a1025f849fc25e /home/grayshade/Projects/georust/gdal/src/raster/mdarray.rs:754:23
    #12 0x55a211a2e975 in gdal::raster::mdarray::tests::test_read_string_array::_$u7b$$u7b$closure$u7d$$u7d$::h39a8ae2f2c26515d /home/grayshade/Projects/georust/gdal/src/raster/mdarray.rs:747:5
    #13 0x55a211b67e22 in core::ops::function::FnOnce::call_once::h0e08a4c057889930 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:248:5
    #14 0x55a213026430 in core::ops::function::FnOnce::call_once::h78f67bbbc478e858 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:248:5
    #15 0x55a213221614 in test::__rust_begin_short_backtrace::h424c1b00664ff9a5 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/test/src/lib.rs:572:5
    #16 0x55a213221383 in test::run_test::_$u7b$$u7b$closure$u7d$$u7d$::h4b49505ef69968eb /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/test/src/lib.rs:563:30
    #17 0x55a21301fea3 in core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h5634564ee990e463 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:248:5
    #18 0x55a2130f9814 in _$LT$alloc..boxed..Box$LT$F$C$A$GT$$u20$as$u20$core..ops..function..FnOnce$LT$Args$GT$$GT$::call_once::h77f2eedd5f93afce /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1935:9
    #19 0x55a21328d124 in _$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h623069be585d6273 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panic/unwind_safe.rs:271:9
    #20 0x55a213110c11 in std::panicking::try::do_call::hea3db3f94db7109e /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:492:40
    #21 0x55a213168349 in __rust_try test.e9b8a699-cgu.3
    #22 0x55a21310e0d3 in std::panicking::try::h76022fd79b9780a6 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:456:19
    #23 0x55a212fda7ea in std::panic::catch_unwind::h7d8fa29bb3b59267 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:137:14
    #24 0x55a213222acb in test::run_test_in_process::hdff1463fa940207c /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/test/src/lib.rs:595:18
    #25 0x55a2132208b0 in test::run_test::run_test_inner::_$u7b$$u7b$closure$u7d$$u7d$::h00d76d275d162f11 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/test/src/lib.rs:489:39
    #26 0x55a2132210a2 in test::run_test::run_test_inner::_$u7b$$u7b$closure$u7d$$u7d$::hf359ab11c43d03d2 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/test/src/lib.rs:516:37
    #27 0x55a212fd5a31 in std::sys_common::backtrace::__rust_begin_short_backtrace::h3dd6b1570de93ee9 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:122:18
    #28 0x55a2130af534 in std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::haadda7250bd8d3e5 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:505:17
    #29 0x55a21328cf52 in _$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h430cdcfa434bee4f /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panic/unwind_safe.rs:271:9
    #30 0x55a21310fd91 in std::panicking::try::do_call::h3a880b2671530a30 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:492:40
    #31 0x55a213168349 in __rust_try test.e9b8a699-cgu.3
    #32 0x55a21310d540 in std::panicking::try::h4909ff5985009677 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:456:19
    #33 0x55a212fda5c5 in std::panic::catch_unwind::h58652b814c250840 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:137:14
    #34 0x55a2130aea49 in std::thread::Builder::spawn_unchecked_::_$u7b$$u7b$closure$u7d$$u7d$::h3e99447dc95bf747 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:504:30
    #35 0x55a213020a12 in core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::hd6fa08024ac1c9fc /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:248:5
    #36 0x55a213e6f5e4 in _$LT$alloc..boxed..Box$LT$F$C$A$GT$$u20$as$u20$core..ops..function..FnOnce$LT$Args$GT$$GT$::call_once::hdc3b7ab0e4eb8d17 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1935:9
    #37 0x55a213e6f2ef in _$LT$alloc..boxed..Box$LT$F$C$A$GT$$u20$as$u20$core..ops..function..FnOnce$LT$Args$GT$$GT$::call_once::had43e6129a688d3c /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1935:9
    #38 0x55a21370f6a5 in std::sys::unix::thread::Thread::new::thread_start::h49727342928fa407 /home/grayshade/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/thread.rs:108:17
    #39 0x7f80723b778c  (/usr/lib/libc.so.6+0x8678c) (BuildId: 7d4293a9bbe1f068ab7ae807c2d9377395eb5b41)
    #40 0x7f80724388e3 in clone (/usr/lib/libc.so.6+0x1078e3) (BuildId: 7d4293a9bbe1f068ab7ae807c2d9377395eb5b41)

  Uninitialized value was created by a heap allocation
    #0 0x55a211851550 in malloc /rustc/llvm/src/llvm-project/compiler-rt/lib/msan/msan_interceptors.cpp:895:3
    #1 0x7f80700a647c in operator new(unsigned long) /usr/src/debug/gcc/libstdc++-v3/libsupc++/new_op.cc:50:22
    #2 0x55a211846fc4 in __msan_test_shadow /rustc/llvm/src/llvm-project/compiler-rt/lib/msan/msan.cpp:527:7
    #3 0x7f80733fd8e3  (/usr/lib/libgdal.so.31+0xdfd8e3) (BuildId: d5ca43948a126d3ccc6e0373186f43ab677c25e9)

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/usr/lib/libgdal.so.31+0x3164eb) (BuildId: d5ca43948a126d3ccc6e0373186f43ab677c25e9) in VSIFileManager::GetHandler(char const*)
Exiting

PartialEq is currently derived and super practical when writing tests.

I don't think it's worth the trouble. A couple of unwrap()s in tests are going to be fine.

Okay, agreed, but should I really remove PartialEq from GdalError in this PR?

The crucial part of this PR are the spurious SIGSEGVs that sometimes occur. If I run it locally, I get these every 10-15 runs.

Does that happen only in this PR, but not on master?

I just added a new check, so this should happen on master. This is why I am looking into this because we thought (on Discord) of releasing a new version :smile: . Strangely, similar code runs without SIGSEGVs in Geo Engine. I basically wanted to switch it to this code, once released.

You've got a nicer backtrace for your memory checks, could you post your run command?

PartialEq is currently derived and super practical when writing tests.

I don't think it's worth the trouble. A couple of unwrap()s in tests are going to be fine.

Okay, agreed, but should I really remove PartialEq from GdalError in this PR?

The crucial part of this PR are the spurious SIGSEGVs that sometimes occur. If I run it locally, I get these every 10-15 runs.

Does that happen only in this PR, but not on master?

I just added a new check, so this should happen on master. This is why I am looking into this because we thought (on Discord) of releasing a new version smile . Strangely, similar code runs without SIGSEGVs in Geo Engine. I basically wanted to switch it to this code, once released.
You've got a nicer backtrace for your memory checks, could you post your run command?

I've merged the other PR into this, so we can focus on the MD stuff.
@lnicola You've got a nicer backtrace for your memory checks, could you post your run command?

I used the same command as you (maybe with a different nightly, rustc 1.64.0-nightly (affe0d3a0 2022-08-05)). It might be some OS thing, I'm not sure.
The point is, that's reported in GDAL itself, in GDALAllRegister. I think it's a false positive. I haven't looked closely at the code in this PR, or in what appears to be the test that's failing for you (test_read_string_array).
Unfortunately, I'll be AFK for the next couple of days.

So, all I did add was an additional check that we only use read_as_string when it is actually a string.
I've created the following script
#!/bin/bash

export RUSTFLAGS=-Zsanitizer=address RUSTDOCFLAGS=-Zsanitizer=address

while [ $? -eq 0 ]; do
    sleep 1

    cargo +nightly-2022-08-17-x86_64-unknown-linux-gnu test -Zbuild-std --target x86_64-unknown-linux-gnu -- raster::mdarray::tests
done

And this gets some SEGV after 10-30 calls:
running 14 tests
test raster::mdarray::tests::test_root_group_name ... ok
test raster::mdarray::tests::test_array_names ... ok
AddressSanitizer:DEADLYSIGNAL
=================================================================
test raster::mdarray::tests::test_no_data_value ... ==75256==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000040 (pc 0x7ff028740271 bp 0x000000000000 sp 0x7ff016ca0378 T11)
ok
==75256==The signal is caused by a READ memory access.
==75256==Hint: address points to the zero page.
test raster::mdarray::tests::test_read_as_string_array_for_non_string ... ok
    #0 0x7ff028740271  (/lib/x86_64-linux-gnu/libhdf5_serial.so.103+0xe6271) (BuildId: 544bb1e5cd401326097f2eac0d838f3af6f0b0a8)
    #1 0x7ff0288f256f  (/lib/x86_64-linux-gnu/libhdf5_serial.so.103+0x29856f) (BuildId: 544bb1e5cd401326097f2eac0d838f3af6f0b0a8)
    #2 0x7ff0288913cb  (/lib/x86_64-linux-gnu/libhdf5_serial.so.103+0x2373cb) (BuildId: 544bb1e5cd401326097f2eac0d838f3af6f0b0a8)
    #3 0x7ff02888591f  (/lib/x86_64-linux-gnu/libhdf5_serial.so.103+0x22b91f) (BuildId: 544bb1e5cd401326097f2eac0d838f3af6f0b0a8)
    #4 0x7ff028709572  (/lib/x86_64-linux-gnu/libhdf5_serial.so.103+0xaf572) (BuildId: 544bb1e5cd401326097f2eac0d838f3af6f0b0a8)
    #5 0x7ff028709735  (/lib/x86_64-linux-gnu/libhdf5_serial.so.103+0xaf735) (BuildId: 544bb1e5cd401326097f2eac0d838f3af6f0b0a8)
    #6 0x7ff0286e320f  (/lib/x86_64-linux-gnu/libhdf5_serial.so.103+0x8920f) (BuildId: 544bb1e5cd401326097f2eac0d838f3af6f0b0a8)
    #7 0x7ff028a40038  (/lib/x86_64-linux-gnu/libnetcdf.so.15+0x69038) (BuildId: 247fe0977349435c36af618374beb5458b40a0a0)
    #8 0x7ff028a3d077  (/lib/x86_64-linux-gnu/libnetcdf.so.15+0x66077) (BuildId: 247fe0977349435c36af618374beb5458b40a0a0)
    #9 0x7ff028a432d0  (/lib/x86_64-linux-gnu/libnetcdf.so.15+0x6c2d0) (BuildId: 247fe0977349435c36af618374beb5458b40a0a0)
    #10 0x7ff0289fe776  (/lib/x86_64-linux-gnu/libnetcdf.so.15+0x27776) (BuildId: 247fe0977349435c36af618374beb5458b40a0a0)
    #11 0x7ff0289fe7b6  (/lib/x86_64-linux-gnu/libnetcdf.so.15+0x277b6) (BuildId: 247fe0977349435c36af618374beb5458b40a0a0)
    #12 0x7ff02a38e107  (/lib/libgdal.so.30+0x86e107) (BuildId: 965b1b7ee55bf9bdb5298fb4af151db56451b22c)
    #13 0x7ff02a38ec8d  (/lib/libgdal.so.30+0x86ec8d) (BuildId: 965b1b7ee55bf9bdb5298fb4af151db56451b22c)
    #14 0x7ff02a6530d0  (/lib/libgdal.so.30+0xb330d0) (BuildId: 965b1b7ee55bf9bdb5298fb4af151db56451b22c)
    #15 0x56460aea853e  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x4fa53e) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #16 0x56460ae62752  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x4b4752) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #17 0x56460ade9409  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x43b409) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #18 0x56460af0e0e9  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x5600e9) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #19 0x56460b8769ba  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xec89ba) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #20 0x56460b96dc2a  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xfbfc2a) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #21 0x56460b96d7f9  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xfbf7f9) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #22 0x56460b86ac10  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xebcc10) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #23 0x56460b8dd068  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf2f068) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #24 0x56460b8dfd4d  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf31d4d) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #25 0x56460b8ecbc5  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf3ebc5) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #26 0x56460b9157aa  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf677aa) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #27 0x56460b8eb6e3  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf3d6e3) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #28 0x56460b845040  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xe97040) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #29 0x56460b96e746  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xfc0746) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #30 0x56460b96cde3  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xfbede3) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #31 0x56460b96d4b7  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xfbf4b7) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #32 0x56460b9e7e44  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x1039e44) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #33 0x56460b8eadfa  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf3cdfa) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #34 0x56460b8dfdae  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf31dae) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #35 0x56460b8ed31b  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf3f31b) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #36 0x56460b9157aa  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf677aa) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #37 0x56460b8ebaec  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf3daec) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #38 0x56460b844f0e  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xe96f0e) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #39 0x56460b8ea6e6  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf3c6e6) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #40 0x56460b86a10e  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xebc10e) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #41 0x56460bf71798  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x15c3798) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #42 0x56460bf71aa6  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x15c3aa6) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #43 0x56460bbab688  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x11fd688) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #44 0x7ff029aea608  (/lib/x86_64-linux-gnu/libpthread.so.0+0x8608) (BuildId: 7b4536f41cdaa5888408e82d0836e33dcf436466)
    #45 0x7ff0298ba132  (/lib/x86_64-linux-gnu/libc.so.6+0x11f132) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib/x86_64-linux-gnu/libhdf5_serial.so.103+0xe6271) (BuildId: 544bb1e5cd401326097f2eac0d838f3af6f0b0a8)
Thread T11 created by T0 here:
    #0 0x56460ac3c5dc  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x28e5dc) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #1 0x56460bbaaa37  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x11fca37) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #2 0x56460b8e9a23  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf3ba23) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #3 0x56460b8e8362  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf3a362) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #4 0x56460b8eaf06  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xf3cf06) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #5 0x56460b96ba05  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xfbda05) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #6 0x56460b96a41f  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xfbc41f) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #7 0x56460b95edb6  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xfb0db6) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #8 0x56460b7bf8c6  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xe118c6) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #9 0x56460b959b5e  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xfabb5e) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #10 0x56460b95a9a7  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0xfac9a7) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #11 0x56460af53112  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x5a5112) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #12 0x56460ad8dce3  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x3dfce3) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #13 0x56460bf42102  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x1594102) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #14 0x56460bf470ba  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x15990ba) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #15 0x56460bbcfa49  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x1221a49) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #16 0x56460bc33a6b  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x1285a6b) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #17 0x56460bf422da  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x15942da) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #18 0x56460bf470ba  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x15990ba) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #19 0x56460bbcfd39  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x1221d39) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #20 0x56460bc333d6  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x12853d6) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #21 0x56460ad8dc3d  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x3dfc3d) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)
    #22 0x56460af5313b  (/home/beilschmidt/git/rust-gdal/target/x86_64-unknown-linux-gnu/debug/deps/gdal-7a9fc38fd36df462+0x5a513b) (BuildId: ce039fc1ceba1dd90d5741a6e14595b29ea10f80)

==75256==ABORTING

I still have no clue how this can happen. And I don't know why you get nicer ASAN messages that point to some code :shrug: .

I let your script run for 20 minutes (maybe around 600 runs) and it didn't fail. Maybe it's something specific to your setup (version of GDAL or other dependencies)?

Maybe someone else can confirm that. Then, we can merge it. But I am still confused :smile:.

What's weird is that it also crashed on CI, didn't it?

Ah, yes, it does:
AddressSanitizer:DEADLYSIGNAL
=================================================================
==1306100==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000040 (pc 0x7f1c1dafae10 bp 0x7f1c207a0f9f sp 0x7f1c207a0d58 T11)
test raster::mdarray::tests::test_read_as_string_array_for_non_string ... ==1306100==The signal is caused by a READ memory access.
==1306100==Hint: address points to the zero page.
ok
    #0 0x7f1c1dafae10 in H5F_addr_decode (/usr/lib/libhdf5.so.200+0xfae10) (BuildId: e928e6d519578bc949985001081e2db55889095e)
    #1 0x7f1c1dceede8 in H5VL__native_blob_specific (/usr/lib/libhdf5.so.200+0x2eede8) (BuildId: e928e6d519578bc949985001081e2db55889095e)
    #2 0x7f1c1dcdfb97  (/usr/lib/libhdf5.so.200+0x2dfb97) (BuildId: e928e6d519578bc949985001081e2db55889095e)
    #3 0x7f1c1dce747c in H5VL_blob_specific (/usr/lib/libhdf5.so.200+0x2e747c) (BuildId: e928e6d519578bc949985001081e2db55889095e)
    #4 0x7f1c1dcd4153  (/usr/lib/libhdf5.so.200+0x2d4153) (BuildId: e928e6d519578bc949985001081e2db55889095e)
    #5 0x7f1c1dc5f4b2 in H5T__conv_vlen (/usr/lib/libhdf5.so.200+0x25f4b2) (BuildId: e928e6d519578bc949985001081e2db55889095e)
    #6 0x7f1c1dc508f0 in H5T_convert (/usr/lib/libhdf5.so.200+0x2508f0) (BuildId: e928e6d519578bc949985001081e2db55889095e)
    #7 0x7f1c1dac7f94 in H5D_get_create_plist (/usr/lib/libhdf5.so.200+0xc7f94) (BuildId: e928e6d519578bc949985001081e2db55889095e)
    #8 0x7f1c1dcef860 in H5VL__native_dataset_get (/usr/lib/libhdf5.so.200+0x2ef860) (BuildId: e928e6d519578bc949985001081e2db55889095e)
    #9 0x7f1c1dcd4d47  (/usr/lib/libhdf5.so.200+0x2d4d47) (BuildId: e928e6d519578bc949985001081e2db55889095e)
    #10 0x7f1c1dcdcd31 in H5VL_dataset_get (/usr/lib/libhdf5.so.200+0x2dcd31) (BuildId: e928e6d519578bc949985001081e2db55889095e)
    #11 0x7f1c1daa087c in H5Dget_create_plist (/usr/lib/libhdf5.so.200+0xa087c) (BuildId: e928e6d519578bc949985001081e2db55889095e)
    #12 0x7f1c1dead1a3 in nc4_get_var_meta (/usr/lib/libnetcdf.so.19+0xad1a3) (BuildId: 48973e4b6f0222041f0c5c3f1146768570870e69)
    #13 0x7f1c1dead920 in nc4_hdf5_find_grp_var_att (/usr/lib/libnetcdf.so.19+0xad920) (BuildId: 48973e4b6f0222041f0c5c3f1146768570870e69)
    #14 0x7f1c1deb3f37 in NC4_HDF5_inq_var_all (/usr/lib/libnetcdf.so.19+0xb3f37) (BuildId: 48973e4b6f0222041f0c5c3f1146768570870e69)
    #15 0x7f1c1de2fc96 in nc_inq_var (/usr/lib/libnetcdf.so.19+0x2fc96) (BuildId: 48973e4b6f0222041f0c5c3f1146768570870e69)
    #16 0x7f1c1de2fcd7 in nc_inq_varname (/usr/lib/libnetcdf.so.19+0x2fcd7) (BuildId: 48973e4b6f0222041f0c5c3f1146768570870e69)
    #17 0x7f1c2aab7e1d  (/usr/lib/gdalplugins/gdal_netCDF.so+0x62e1d) (BuildId: 811efbab181d578fd95384e0607ddf78cf328f2d)
    #18 0x7f1c2aab0b63  (/usr/lib/gdalplugins/gdal_netCDF.so+0x5bb63) (BuildId: 811efbab181d578fd95384e0607ddf78cf328f2d)
    #19 0x7f1c2aab7711  (/usr/lib/gdalplugins/gdal_netCDF.so+0x62711) (BuildId: 811efbab181d578fd95384e0607ddf78cf328f2d)
    #20 0x7f1c30c84cdb in GDALGroupOpenMDArray (/usr/lib/libgdal.so.31+0xc84cdb) (BuildId: d5ca43948a126d3ccc6e0373186f43ab677c25e9)
    #21 0x562249b0236e in gdal::raster::mdarray::Group::open_md_array::hffd87c63c741ffb5 /home/grayshade/Projects/georust/gdal/src/raster/mdarray.rs:402:29
    #22 0x562249ce5df2 in gdal::raster::mdarray::tests::test_read_string_array::h4f15a670359d58a1 /home/grayshade/Projects/georust/gdal/src/raster/mdarray.rs:770:28
    #23 0x562249cdc119 in gdal::raster::mdarray::tests::test_read_string_array::_$u7b$$u7b$closure$u7d$$u7d$::hd137cf6cab56e0f9 /home/grayshade/Projects/georust/gdal/src/raster/mdarray.rs:759:5

This is weird. I can still reproduce it after #[ignore]-ing all tests except test_read_string_array and test_read_as_string_array_for_non_string. It even happens if I comment out the read_as_string_array calls, but not if I comment out open_md_array. And it still happens with -j1.

Well, I have no clue how this PR could lead to that problem.
It must have been there already.

Yeah, I'm pretty sure that your PR only causes it because it calls the problematic function a second time.

TIL -j is not --test-threads :smile:.
I'm able to reproduce the crash in the following test:
    #[test]
    fn test_read_string_array() {
        for _ in 0..1000 {
            let t1 = std::thread::spawn(|| {
                let dataset_options = DatasetOptions {
                    open_flags: GdalOpenFlags::GDAL_OF_MULTIDIM_RASTER,
                    allowed_drivers: None,
                    open_options: None,
                    sibling_files: None,
                };
                let dataset =
                    Dataset::open_ex("fixtures/alldatatypes.nc", dataset_options).unwrap();

                let root_group = dataset.root_group().unwrap();

                let string_array = root_group
                    .open_md_array("string_var", CslStringList::new())
                    .unwrap();
            });
            let t = std::thread::spawn(|| {
                let dataset_options = DatasetOptions {
                    open_flags: GdalOpenFlags::GDAL_OF_MULTIDIM_RASTER,
                    allowed_drivers: None,
                    open_options: None,
                    sibling_files: None,
                };
                let dataset =
                    Dataset::open_ex("fixtures/alldatatypes.nc", dataset_options).unwrap();
            });
            t.join().unwrap();
            t1.join().unwrap();
        }
    }

This might be some threading issue in GDAL & friends.

https://github.com/OSGeo/gdal/issues/6253

@ChristianBeilschmidt if I'm not mistaking, making a copy of alldatatypes.nc and using it in one of the tests should fix the crashes. I haven't tested it yet.
(it's fine to commit a duplicate file, git will store it only once)

Wow, you really caught the problem! :+1: Kudos for that.
That seems to do the trick for the CI, I just merged the tests: 6ad91ed
But it's good that you opened that issue in the GDAL repo. This is really strange and concerning.

This is really strange

Not that strange, given that the approach netcdf takes to threading is a global mutex: https://www.unidata.ucar.edu/blogs/developer/en/entry/implementing-thread-safe-access-to.

What about read_into_slice and maybe others? Shouldn't they check the type too, or at least be marked as unsafe?

What about read_into_slice and maybe others? Shouldn't they check the type too, or at least be marked as unsafe?

The problem with read as string is that we treat the result as string pointers and dereference them.
This is catastrophic if the resulting values are not pointers to strings.
This happens here: https://github.com/georust/gdal/blob/6ad91edaafd113936850bafcdacd70559ca14a69/src/raster/mdarray.rs#L284
I don't see it happen in other places. There could be maybe another issue that you are referring to, but this PR fixes the string pointer issue.

There could be maybe another issue that you are referring to, but this PR fixes the string pointer issue.

I'm not saying it doesn't, I'm only saying that the API is still unsafe. Try this under ASAN:
            let string_array = root_group
                .open_md_array("uint_var", CslStringList::new())
                .unwrap();

            let values = string_array.read_as::<u8>(vec![0, 0], vec![1, 2]).unwrap();

There could be maybe another issue that you are referring to, but this PR fixes the string pointer issue.

I'm not saying it doesn't, I'm only saying that the implementation is still unsafe. Try this under ASAN:
            let string_array = root_group
                .open_md_array("uint_var", CslStringList::new())
                .unwrap();

            let values = string_array.read_as::<u8>(vec![0, 0], vec![1, 2]).unwrap();

This happens because GDALMDArrayRead takes the buffer type as argument, but we're passing GDALMDArrayGetDataType(self.c_mdarray), which is the array type. Normally, GDAL does some format conversions when needed. When we call GDALRasterIOEx, we pass T::gdal_type() instead.

Valid point, but I would look at this in a different PR:
https://github.com/georust/gdal/issues/290

Sure, but let's wait until tomorrow in case anyone else wants to take a look.

bors r+

authors: ChristianBeilschmidt lnicola


text:
fix test_std_geodesic_geodsolve76 failure

This standard Karney unit test currently fails. Fix geodesic to make it work.
Tests the "distance from Wellington and Salamanca (a classic failure of Vincenty)", using WGS84.

I'll plan on taking a pass through inverse behavior, looking for problems in general, but with a focus on this test case in particular.

I'll plan on taking a pass through inverse behavior, looking for problems in general, but with a focus on this test case in particular.

repo: georust/geographiclib-rs


text:
fix #20 test_arcdirect

Short version: At this point, it just needed to be unignored.
Previously affected by some direct bugs that were fixed as part of earlier commits. An earlier draft accidentally used too demanding of a tolerance for some parameters, also fixed in previous commits, but I had forgotten to merge that tolerance update into my test-heavy "establish-baselines" branch. My polyval suspicion turned out to be a red herring related to array comparisons where I had forgotten that the first element is unused and therefore shouldn't be checked.

[ ] I agree to follow the project's code of conduct.
[ ] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

bors r+
Great!

On Feb 2, 2021, at 23:26, stonylohr notifications@github.com wrote:

Short version: At this point, it just needed to be unignored.
Previously affected by some direct bugs that were fixed as part of earlier commits. An earlier draft accidentally used too demanding of a tolerance for some parameters, also fixed in previous commits, but I had forgotten to merge that tolerance update into my test-heavy "establish-baselines" branch. My polyval suspicion turned out to be a red herring related to array comparisons where I had forgotten that the first element is unused and therefore shouldn't be checked.
I agree to follow the project's code of conduct.
I added an entry to CHANGES.md if knowledge of this change could be valuable to users.
You can view, comment on, or merge this pull request online at:
https://github.com/georust/geographiclib-rs/pull/40
Commit Summary
Unignore test_arcdirect
File Changes
M src/geodesic.rs (1)
Patch Links:
https://github.com/georust/geographiclib-rs/pull/40.patch
https://github.com/georust/geographiclib-rs/pull/40.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

authors: michaelkirk stonylohr


text:
Update geo-types dependency

Allow patches to the dependency.
(It's currently 0.4.3)

bors r+

@urschrei bumped your permissions. Try again?

bors r+

bors retry

@peterbraden Published to crates.io as v0.7.1

authors: frewsxcv peterbraden urschrei

repo: georust/polyline


text:
From python parser

That's not tested, and with bad type. But to be able to work on it with other poeple, I think I'll merge it.

:tada: This PR is included in version 1.0.0-next.1 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: ger-benjamin jansule

repo: geostyler/geostyler-lyrx-parser


text:
GPX-442

inhibit-rule in template einpflegen

version hochgezogen und gemerged, wie besprochen

repo: gepaplexx/application-day-x-generator


text:
We should plot number of spots detected per regional barcode

@josephneos1010 @TLSteinacker

[x] stratified by FOV (2 heatmaps -- 1 filtered, 1 unfiltered spots)
[x] aggregated across FOVs (side-by-side barchart -- filtered and unfiltered for each regional barcode timepoint)

Examples:

repo: gerlichlab/looptrace


text:
laser mode

Hi
On the Settings panel, the $32 parameter is not labelled in the stringgrid
$32 is the boolean switch for laser mode for GRBL v1.1

Fixed in V1.0.9.9

authors: gerritv swarfer

repo: gerritv/Grbl-Panel


text:
Change servicePath in serverless.yml

This is a Feature Proposal
Description
For feature proposals:
For the case i would like to use bable to compile my code to another dest like "dist" folder.
and library can get the compiled source code and execute it.
Additional Data
like: babel services --out-dir dist/services

Please comment on my feature request and code.
This is my first open source pull request. = ]

@yoyeung thanks for contributing! @gertjvr and I have talked about this before. It's definitely a feature we need.
I've added some comments to your PR.

@johncmckim actually i am think about to integrate babel to this plugin.
is easy to add and watch babel logic.
in my design is look like use babel.transform to monitor src and dist folder.
Other config will use .babelrc provided by user.
Another step is monitor the serverless.yml.
When developer go to update js it will live compile
if developer change serverless.yml, it will live refresh.
Is it more close to the project goal? = ]

Hi @yoyeung
Firstly thanks for adding the service path change.
I have been using serverless-webpack combined with service path change in offline previously to achieve this.
I dont think plugins should have a single purpose, pulling in the babel or webpack isn't a foxus of this plugin.

@gertjvr Good to hear the more clear vision for this plugin

@gertjvr after research  serverless-webpack plugin. But it live compile and watch the src.
Am I overlooked??

Thanks for contributing @yoyeung. I've merged your PR. Will release an update soon.
I'm not exactly sure I understand your question. But if webpack or babel is re-building your dist file on changes, it will automatically use the newly built code. Please let us know if that doesn't answer your question.

@johncmckim yup ur correct.

Hi @johncmckim @gertjvr ,
I am not sure if I understand this correctly. But setting
simulate:
services: docker-compose.yml
dist: dist
My folder structure is /home/jenkins/git/src & /home/jenkins/git/dist
The dist folder contains src/index.js.
But when I do
./node_modules/.bin/sls simulate  --stage dev apigateway -p 5000 --lambda-port 4000
I always uses the servicePath to be /home/jenkins/git.
The config value dist does not take affect.
Thanks in advance.
-Ali

authors: ali-himindz gertjvr johncmckim yoyeung

repo: gertjvr/serverless-plugin-simulate


text:
Allow empty arrays in proxy

I have the following hocon config file:
database: {
  global: {
    volumes: []
  }
}

If the volumes array is empty, i get the following error when I try to read globalCfg.getVolumes(); :
org.github.gestalt.config.exceptions.GestaltException: Failed to get proxy config while calling method: volumes in path: database.global.

I noticed that the class ProxyInvocationHandler inside ProxyDecoder.java does not have any value related to null properties and empty array properties.

Thanks for the bug report, generally gestalt fails if there is no data.
But i will try and make it a little more flexible to meet your needs.

Yes, but in some formats, like hocon, an array with 0 elements is different than "null", it's impossible to get that property even if it's valid

Gestalt supports loading from 7 different formats, and has the capability to merge them. So we load each format, but then convert it into an internal representation. Unfortunately, From there we lose some of the special properties of each format.
I have added a new configuration flag treatEmptyCollectionAsErrors you can set on the builder. Please set this to false, to get your desired behavior. By default Gestalt will treat empty (null, size 0) collections as an error. By setting this to false, if there is an empty collection it will simply return an empty collection.
Hopefully this will resolve the issue. But i haven't tested specifically with a proxy object, but only with a list, set and array.
Once this is released please let me know if this works for you.

It doesn't work on empty arrays. Attempting to get the empty array causes the following error:
org.github.gestalt.config.exceptions.GestaltException: Failed getting config path: database, for class: it.cavallium.rockserver.core.config.DatabaseConfig
 - level: MISSING_VALUE, message: Array on path: database.global.volumes, has no value attempting to decode Array
 - level: ERROR, message: Decoding object : GlobalDatabaseConfig on path: database.global.volumes, field volumes results in null value

If I set .setTreatNullValuesInClassAsErrors(false), it still doesn't help:
org.github.gestalt.config.exceptions.GestaltException: Failed to get cached object from proxy config while calling method: volumes with type: class [Lit.cavallium.rockserver.core.config.VolumeConfig; in path: database.global.
	at org.github.gestalt.core/org.github.gestalt.config.decoder.ProxyDecoder$ProxyCacheInvocationHandler.invoke(ProxyDecoder.java:194)
	at jdk.proxy2/jdk.proxy2.$Proxy8.volumes(Unknown Source)

Can you try version 0.24.2.

It works, thanks!

repo: gestalt-config/gestalt


text:
Update coreFeatures.adoc

retry的一个示例代码，retry和elapsed的顺序错了

谢谢更正！

authors: EricLye get-set

repo: get-set/reactor-core


text:
🛑 CRM is down

In 4e37e98, CRM (https://20.rp.get6pm.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: CRM is back up in 02aa000 after 7 minutes.


text:
框架存在重复代码

如上图所示，想确认一下代码是否存在重复

小伙子，这个问题确实存在，感谢提醒，问题已经纠正，但这个问题无伤大雅，会在下个版本发布更新。

超过三天没有响应，关闭此 issue。

authors: akuruan getActivity

repo: getActivity/XXPermissions


text:
fix: parse the cached accounts only if it is a string

issue on orion: https://orionfeedback.org/d/3898-storagelocalget-automatically-parses-json

Issue on orion: https://orionfeedback.org/d/3898-storagelocalget-automatically-parses-json

Can I get this in to test Orion?
https://browser.kagi.com/ - works also maybe for iOS (iPad iPhone)

repo: getAlby/lightning-browser-extension


text:
chore(e2e): add test for change password

Describe the changes you have made in this PR
Adds e2e test for change password feature
Link this PR to an issue [optional]
Related: #2075
Type of change
(Remove other not matching type)

chore

How has this been tested?
Ran tests
Checklist

[x] My code follows the style guidelines of this project and performed a self-review of my own code
[x] New and existing tests pass locally with my changes
[x] I checked if I need to make corresponding changes to the documentation (and made those changes if needed)

@im-adithya can you add a comment about the test and how it works e.g. that it first changes the password and that the other tests then use the password

Done already!

authors: bumi im-adithya


text:
Improve Work Files tool aesthetics and functionality

Issue
The Avalon Work Files tool currently has the barebones functionality and I'd like to make it more trivial to use when working in a scene with many saved versions and files. And I believe it can offer some more things that one might want to use now and then.
Of course #412 is part of improving workflows too. But I think we can do much more.
Here are some ideas:

Remove the Duplicate button and add that under "right mouse" functionality on a file to avoid clutter.
Merge files of the same sequence. Say you have model_v001 to model_v114 then it would show model v114 and you could expose the other versions by right clicking or something. 95% of the time you're opening the latest anyway. Any reason to NOT do this?
Add "date modified" to the view (often requested by our artists). Funnily this is most useful when you don't do 2) or keep it simple to see the visual date differences between this and earlier files. Artists often told me they wanted to quickly see the date differences between different versions.
Allow to sort by date modified.
Add filter by name field.

The points 2) and 5) really are only useful if uses save with files with different names, which the workfiles currently disallows. It forces you to use a particular file path formatting. Bringing me to point 6). Should we allow work files to be saved as different steps or branches?
So like now you could have a character model that has a scene for character_model_v001.ma and character_model_v002_fix.ma where fix is a comment/description for that file. But what if someone wanted to save "another branch of work" like: "hires", "lowres", "proxy" or maybe just a part of the character "belt" or "head". I'm seeing other pipelines allowing to do so and I'm wondering whether we'd want to expose that too. It seems very logical, we often have artists saving manually outside of Work Files to allow just that.

Any better ideas? References or design mockups are also very welcome.

I dont really mind any of these improvements. The main purpose of the Workfiles app is to make it easier and quicker to access your work files than the DCCs "Open File"

Remove the Duplicate button and add that under "right mouse" functionality on a file to avoid clutter.

This needs to be explained/obvious to the end user somehow. Too often right-click functionality is lost to the user because its not explained or indicated.

Merge files of the same sequence. Say you have model_v001 to model_v114 then it would show model v114 and you could expose the other versions by right clicking or something. 95% of the time you're opening the latest anyway. Any reason to NOT do this?

Sounds good to me. We already have clique as a vendor to be able to do this.

But what if someone wanted to save "another branch of work"

We have worked with making another task if something needs branching. Maybe its a matter of making the Context Manager able to make tasks?

I like that

I did a quick survey in the studio and artists spoke quite loudly against this. They feel it's obscuring and confusing the simplicity it has right now. I actually agree with them on this one. Moreover, what happens when you have my_file_v01, my_file_v02, my_file_v02_testingSomething? The only way to know which is newer is by date, and that doesn't mean it's the one artist wants.

Yes, absolutely

Totally

YES.

But what if someone wanted to save "another branch of work"

Yeah we do this quite a lot for plethora of situations. I'd rather leave this a bit loose. Actually the "snapshot" system that is used in shotgun is perfect I think. People often want to save subversions of their current workfile. Currently we use comment for this, or simple maya "incemental save" but maybe some supported way would be good, on top of comment.
maybe having version, subversion,  comment? subversion and comment of coure being optional

authors: BigRoy mkolar tokejepsen

repo: getavalon/core