text:
AttributeError on BIDSLayout.get_entities()

Dataset: ds005 from datasets repository

AttributeError                            Traceback (most recent call last)
 in ()
----> 1 avail_entitities=layout.get_entities()
1 frames
/usr/local/lib/python3.7/dist-packages/ancpbids/pybids_compat.py in get(self, return_type, target, scope, extension, suffix, **entities)
132         ops = []
133         target_type = self.schema.File
--> 134         if scope.startswith("derivatives"):
135             context = self.dataset.derivatives
136             # we already consumed the first path segment
AttributeError: 'NoneType' object has no attribute 'startswith'

Fixed.
Regression test available at:
tests.auto.test_regressions.RegressionsTestCase.test_get_entitites_no_scope

repo: ANCPLabOldenburg/ancp-bids


text:
Fail to parse circular reference defined in external file: wrong file path is updated to ref value

file1.json:
{
"swagger": "2.0",
"paths": {
"/:analyze-text": {
"post": {
"parameters": [
{
"$ref": "common.json#/parameters/ApiVersionParameter"
}
],
"responses": {
"default": {
"description": "Unexpected error",
"schema": {
"$ref": "common.json#/definitions/ErrorResponse"
}
}
}
}
}
},
"definitions": {
"DocumentError": {
"type": "object",
"required": [
"error"
],
"properties": {
"error": {
"type": "object",
"description": "Document Error.",
"$ref": "common.json#/definitions/Error"
}
}
}
}
}
File2.json
{
"swagger": "2.0",
"paths": {},
"definitions": {
"ErrorResponse": {
"type": "object",
"description": "Error response.",
"additionalProperties": false,
"properties": {
"error": {
"description": "The error object.",
"$ref": "#/definitions/Error"
}
},
"required": [
"error"
]
},
"Error": {
"type": "object",
"description": "The error object.",
"additionalProperties": true,
"required": [
"code",
"message"
],
"properties": {
"message": {
"type": "string",
"description": "A human-readable representation of the error."
},
"target": {
"type": "string",
"description": "The target of the error."
},
"details": {
"type": "array",
"description": "An array of details about specific errors that led to this reported error.",
"items": {
"$ref": "#/definitions/Error"
}
}
}
}
},
"parameters": {
"ApiVersionParameter": {
"name": "api-version",
"in": "query",
"required": true,
"type": "string",
"description": "Client API version."
}
}
}
After deference with option circular: ignore
{
swagger: "2.0",
paths: {
"/:analyze-text": {
post: {
summary: "Request text analysis over a collection of documents.",
operationId: "AnalyzeText",
consumes: [
"application/json",
],
produces: [
"application/json",
],
parameters: [
{
name: "api-version",
in: "query",
required: true,
type: "string",
description: "Client API version.",
},
],
responses: {
default: {
schema: {
$ref: "common.json#/definitions/ErrorResponse",
},
},
},
},
},
},
definitions: {
DocumentError: {
type: "object",
required: [
"error",
],
properties: {
error: {
$ref: "#/definitions/Error",//wrong filepath since Error is defined in external file
type: "object",
},
},
},
},
}

Same here...

source: gharchive/issue

authors: SomaticIT xiaoxuqi-ms

repo: APIDevTools/json-schema-ref-parser

license: MIT

license_type: permissive

license_source: github-api


text:
这个demo启动有报错，好坑

这demo工程，默认使用apijson-framework，可以做到无任何配置即可体验apijson的各种能力。
		<!-- 需要的 APIJSON 相关依赖 -->
		<dependency>
			<groupId>com.github.APIJSON</groupId>
			<artifactId>apijson-framework</artifactId>
			<version>LATEST</version>
		</dependency>

但是这个apijson-framework工程里面写了很多test代码。比如下面这种。比如下面这个plus自定义函数，触发就会报错。
Log.i(TAG, "plus(1,-2) = " + function.invoke("plus(i0,i1)", request));
		Log.i(TAG, "count([1,2,4,10]) = " + function.invoke("countArray(array)", request));

这里也会报错。搞不懂这个apijson-framework工程这么搞意义是啥。
		try {
			request = JSON.parseObject("{\"Comment\":{\"id\":0, \"userId\":0, \"momentId\":0, \"content\":\"apijson\"}}");
			Log.d(TAG, "test  verifyRequest = " + AbstractVerifier.verifyRequest(RequestMethod.POST, "", JSON.parseObject(requestString), request, APIJSON_CREATOR));
		} catch (Exception e) {
			e.printStackTrace();
		}

但是基于这个工程 apijson-java-server启动，并且刷入mysql目录下所有表。启动有报错，具体2类错误

Function表里面很多函数，没有在apijson.framework.APIJSONFunctionParser中定义。报错。自己实现后解决。
还有一个如下的校验错误。apijson.framework.APIJSONVerifier#testStructure

java.lang.IllegalArgumentException: POST请求，Comment 里面不能缺少 momentId 等[userId,momentId,content]内的任何字段！
	at apijson.orm.AbstractVerifier.parse(AbstractVerifier.java:794)
	at apijson.orm.AbstractVerifier.verifyRequest(AbstractVerifier.java:541)
	at apijson.orm.AbstractVerifier$1.onParseJSONObject(AbstractVerifier.java:579)
	at apijson.orm.AbstractVerifier.parse(AbstractVerifier.java:835)
	at apijson.orm.AbstractVerifier.verifyRequest(AbstractVerifier.java:541)
	at apijson.orm.AbstractVerifier.verifyRequest(AbstractVerifier.java:505)
	at apijson.orm.AbstractVerifier.verifyRequest(AbstractVerifier.java:491)
	at apijson.framework.APIJSONVerifier.testStructure(APIJSONVerifier.java:396)

搞不懂这个demo工程，和apijson-framework工程。是怎么协同的。作者自己是否有部署启动过过这个demo，启动日志是否有Exception。。。。

这个是启动时自检，看 APIJSON 对请求参数的校验是否生效，不影响使用，只要最后显示 “APIJSON 已启动” 就行了。
不过确实让挺多人困惑，以为时启动出了问题，后面我们优化下，感谢反馈

其实默认是要配置的，Access 表对应权限配置、Request 表对应参数校验配置。
APIJSONDemo 关掉了所有校验，不需要以上配置，只需要数据库配置正确即可体验校验之外的所有功能。
https://github.com/APIJSON/APIJSON-Demo/tree/master/APIJSON-Java-Server

已更新，优化了启动时自检
https://github.com/APIJSON/APIJSON-Demo/releases/tag/4.6.3

authors: TommyLemon minshiwu

repo: APIJSON/APIJSON-Demo


text:
v2.0.0-rc20

docker run --rm -it apisguru/graphql-faker:v2.0.0-rc.20 --extend https://api-ci.stages.k8s.enapter.ninja/graphql
Unable to find image 'apisguru/graphql-faker:v2.0.0-rc.20' locally
v2.0.0-rc.20: Pulling from apisguru/graphql-fakercbdbe7a5bc2a: Already exists
4b0cddaf9d69: Already exists
63fc8294ef6b: Already exists
7d5b7d51bbb9: Already exists
a1a7e9f49854: Pull complete
5b86c6b50aa6: Pull complete
Digest: sha256:8fb479f7f63ab24e6aca7e6509639cc5866c1698e749a661836139c4f5627dae
Status: Downloaded newer image for apisguru/graphql-faker:v2.0.0-rc.20
Default file ./schema_extension.faker.graphql is used. Specify [file] parameter to change.

Your schema constains a validation error:

Cannot extend type "_Query_" because it is not defined. Did you mean "Query"?

./schema_extension.faker.graphql:13:13
12 |
13 | extend type _Query_ {
   |             ^
14 |   pet: Pet

Using local npm package all is ok.
[Finished: 2020-06-02 10:20:26.117836098+03:00][Spent: 7.555s]--------------------------------------------------------
[/home/andrey] >>> graphql-faker --extend https://api-ci.stages.k8s.enapter.ninja/graphql
Default file ./schema_extension.faker.graphql is used. Specify [file] parameter to change.

✔ Your GraphQL Fake API is ready to use 🚀
  Here are your links:

  ❯ Interactive Editor: http://localhost:9002/editor
  ❯ GraphQL API:        http://localhost:9002/graphql

@IvanGoncharov

@Antiarchitect Release new version right now.
Before running graphql-faker can you please delete schema_extension.faker.graphql and test it one more time?

I confirm that v2.0.0-rc21 works!

@Antiarchitect Great to hear 🎉

authors: Antiarchitect IvanGoncharov

repo: APIs-guru/graphql-faker

license: mit

license_source: bigquery


text:
Add air support and etc.

Makes nautilus mod more configurable by settings (the limit for fuel, air, etc).
Little reformated code (replaces some tabs by spaces).
Add air support (defaultly available when vacuum mod is enabled)
Refill submarine with air when cover is open on water surface
Some air lost when the cover is open underwater.
Add nautilus place check (cannot be placed on shallow water, have to be placed on the open water surface)

Nice!!!! I merged it! Thank you!!!!!! I'll test a bit more and I'll make a new release at content db soon.

Done

source: gharchive/pull-request

authors: APercy sfence

repo: APercy/nautilus


text:
Online documentation is not accessible

Documentation is generated, but not accessible at commonly expected links:
https://arm-software.github.io/CMSIS-RTOS2_Validation/
https://arm-software.github.io/CMSIS-RTOS2_Validation/main/index.html
https://arm-software.github.io/CMSIS-RTOS2_Validation/latest/index.html
Probably some redirects are missing in gh_pages/ structure.

Hi,
the first two links should now work. Since this repository does not have any release yet, latest/index.html is not functional and won't work.

Works now, thanks! Understand the limitation for /latest/.

authors: VladimirUmek vovamarch


text:
armnnTfParser CreateNetwork from pb file as String instead of path

The TF parser so far supports 3 ways of loading a model: from text file (prototxt), from binary file (pb), and from a string (basically the content of the prototxt in a string).
Would it be possible to create a network from the content of the pb file (like theCreateNetworkFromString function but for .pb) ?
The reason why it's important to have this is because using files via paths is not always possible to do in Android. Also, for security reasons, the models are usually encrypted and they are decrypted on runtime in memory. For example, both TensorFlow and the Qualcomm SNPE SDK accept "InputStream" in Java to load a model instead of paths.
Kind regards,

Thanks @mobicham that's good feedback on the Tensorflow parser. I'll add it to the list of improvements that we would like to make.
If you are interested in developing the feature yourself, it looks like google::protobuf::io::CodedInputStream can be created directly from a byte buffer (see https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.io.coded_stream#CodedInputStream), so adding a new method called TfParser::CraeteNetworkFromBinaryData that is similar to the existing CreateNetworkFromBinaryFile would be possible.
All the best,
Matthew

Thank you @MatthewARM !
Just to mention something, it is still possible to use the TF parser from the content of a prototxt file by exporting the model via tf.train.write_graph with the flag as_text=True. I tested that and it works.
However, the model file as text (.prototxt) is much larger in size compared to the binary version (.pb), which can create some out of memory problems when reading the file on an Android device.
Kind regards,

Hi @mobicham yes we have also noticed that the binary format is a lot more efficient. In practice the text format is only useful for small tests.
All the best,
Matthew

authors: MatthewARM mobicham

repo: ARM-software/armnn


text:
FWTS patch application failure while building BBR FWTS

Patch application failure warnings when building FWTS through build_sbbr.sh
HEAD is now at f09402bb lib: fwts_version.h - update to V23.01.00
~/BBR-BUILD/bbr-acs/sbbr/scripts
edhcha01@a074700:~/BBR-BUILD/bbr-acs/sbbr/scripts$ ./build-scripts/build_sbbr.sh
~/BBR-BUILD/bbr-acs/sbbr/scripts ~/BBR-BUILD/bbr-acs/sbbr/scripts
~/BBR-BUILD/bbr-acs/sbbr/scripts
~/BBR-BUILD/bbr-acs/sbbr/scripts/fwts ~/BBR-BUILD/bbr-acs/sbbr/scripts
~/BBR-BUILD/bbr-acs/sbbr/scripts
~/BBR-BUILD/bbr-acs/sbbr/scripts/fwts ~/BBR-BUILD/bbr-acs/sbbr/scripts
/home/edhcha01/BBR-BUILD/bbr-acs/sbbr/scripts/../..
2 out of 2 hunks FAILED
Applying FWTS Patch ...
patching file src/lib/src/fwts_framework.c
1 out of 1 hunk FAILED
1 out of 1 hunk FAILED
The same issue may exist in build_ebbr.sh too.
Also please check if the same issue exists when building FWTS in SystemReady ACS.

I can reproduce this issue with WSL on a x86 system
sunny@xxxxx: /mnt/c/src/bbr-acs/sbbr/scripts$ ./build-scripts/build_sbbr.sh
/mnt/c/src/bbr-acs/sbbr/scripts /mnt/c/src/bbr-acs/sbbr/scripts
/mnt/c/src/bbr-acs/sbbr/scripts
/mnt/c/src/bbr-acs/sbbr/scripts/fwts /mnt/c/src/bbr-acs/sbbr/scripts
/mnt/c/src/bbr-acs/sbbr/scripts
/mnt/c/src/bbr-acs/sbbr/scripts/fwts /mnt/c/src/bbr-acs/sbbr/scripts
/mnt/c/src/bbr-acs/sbbr/scripts/../..
2 out of 2 hunks FAILED
Applying FWTS Patch ...
patching file src/lib/src/fwts_framework.c
1 out of 1 hunk FAILED
1 out of 1 hunk FAILED
Applying FWTS build patch ...
patching file src/lib/include/fwts_fileio.h
patching file src/lib/src/fwts_fileio.c
./build-scripts/build-fwts.sh: line 111: autoreconf: command not found

Build failed: error while running do_build at line 111 in ./build-scripts/build-fwts.sh for [][].

Hello @sunnywang-arm,
Can you please check with latest bbr-acs code if the SBBR/EBBR working fine on WSL environment, the issue seems to be due to autoconf tool dependency not met in build enviroment.
Thanks,
Chetan

@chetan-rathore it somehow doesn't work and I still need to manually install the the autoconf.  After installing autoconf, I ran into another build error
root@PF4Q726R:/mnt/c/src/bbr-acs/sbbr/scripts# ./build-scripts/build_sbbr.sh
ln: failed to create symbolic link '/mnt/c/src/bbr-acs/sbbr/scripts/build-scripts/framework.sh': File exists
ln: failed to create symbolic link '/mnt/c/src/bbr-acs/sbbr/scripts/build-scripts/parse_params.sh': File exists
ln: failed to create symbolic link '/mnt/c/src/bbr-acs/sbbr/scripts/build-scripts/build-sct.sh': File exists
ln: failed to create symbolic link '/mnt/c/src/bbr-acs/sbbr/scripts/build-scripts/build-uefi-apps.sh': File exists
ln: failed to create symbolic link '/mnt/c/src/bbr-acs/sbbr/scripts/build-scripts/build-fwts.sh': File exists
/mnt/c/src/bbr-acs/sbbr/scripts /mnt/c/src/bbr-acs/sbbr/scripts
/mnt/c/src/bbr-acs/sbbr/scripts
/mnt/c/src/bbr-acs/sbbr/scripts/fwts /mnt/c/src/bbr-acs/sbbr/scripts
/mnt/c/src/bbr-acs/sbbr/scripts
/mnt/c/src/bbr-acs/sbbr/scripts/fwts /mnt/c/src/bbr-acs/sbbr/scripts
/mnt/c/src/bbr-acs/sbbr/scripts/../..
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
aclocal: warning: couldn't open directory 'm4': No such file or directory
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: configure.ac: not using Intltool
autoreconf: configure.ac: not using Gtkdoc
autoreconf: running: /usr/bin/autoconf --force
configure.ac:7: warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete
./lib/autoconf/programs.m4:716: _AC_PROG_LEX is expanded from...
./lib/autoconf/programs.m4:709: AC_PROG_LEX is expanded from...
configure.ac:7: the top level
configure.ac:9: error: possibly undefined macro: AC_PROG_LIBTOOL
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
autoreconf: error: /usr/bin/autoconf failed with exit status: 1

Build failed: error while running do_build at line 111 in ./build-scripts/build-fwts.sh for [][].

Hi @sunnywang-arm,
It could be due to some missing dependencies in WSL system.
Can you provide information on OS and its version installed as part of WSL system.
Thanks,
ACS team

sunny@PF4Q726R:~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

Thanks, @chetan-rathore
I'm fine with closing the issue now as it works on my WSL after I re-do everything (clone the bbr-acs source code and re-run all the commands mentioned in readme again).
@edhay  do you want to give the latest bbr-acs a try on your side?

Thanks @sunnywang-arm for the confirmation.
@edhay Please let us know if bbr acs build works at your side also and the ticket can be closed.

Hi @chetan-rathore ,
Tried the build on the latest code. I am still getting the same error:

Hi @edhay,
Can you share the OS version details of the machine on which you are building.
It more seems to be system dependency issue rather than bbr-acs.
The daily scheduled builds are working fine: https://github.com/ARM-software/bbr-acs/actions
Thanks,
ACS team

Details shared by email.

Hi @edhay,
The error on the terminal is due to patch command -R (reverse)  failure when applied to file where patch is already not applied.
https://github.com/ARM-software/bbr-acs/blob/main/common/scripts/build-fwts.sh#L90
The logic checks if "patch is not applied" then apply the patch...else if patch already applied then skip applying patch and proceed.
Thanks,
Chetan

Hi @edhay,
With latest changes as mentioned above, no patch reverse failure prints should be coming.
Please reopen if you have any further queries.
Thanks,
Chetan

authors: chetan-rathore edhay sunnywang-arm

repo: ARM-software/bbr-acs


text:
lisa.analysis: Add hints for autocompletion

Since jedi autocompletion is mostly oriented toward static code
analysis, it does not pick up dynamic attributes. Add a function to give
hints to jedi, so it knows what attributes are available and their type
as well.
That's an ugly PR, but it should be relatively robust against more breakages in jedi, and we care specifically about good autocompletion on that part of LISA, so let's bite the bullet. Should not be a big maintenance hassle anyway, and can go away at anytime if jedi becomes more stable.

Seeing as we have dynamic attributes all over the place (worst offender probably is our Target class), can we not just disable jedi? AFAIR, like @derkling said, we didn't use to have these issues.

can we not just disable jedi ?

That can be done, but that will probably not buy us a long life of working autocompletion. Builtin autocompletion is being deprecated, although IPython maintainers seem to still keep it alive until other jedi issues have been fixed. That builtin autocompletion apparently had a number of issues on its own, and it seems that maintainers would be happy to delegate that to another lib. Unfortunately, jedi is mostly oriented on static analysis to avoid running code partly for security reasons.
https://ipython.readthedocs.io/en/stable/whatsnew/version6.html

worst offender probably is our Target class

That's right, forgot about this one. It could be solved by just inheriting from devlib's Target generic class, which should not create issues (unless they rely on special methods called through builtins, since they are not resolved using __getattr__, but that is quite unlikely as it does not define any)

Doesn't this patch kind of invalidate the dynamic loading?
Every time we add a new "named" analysis method we have to remember to add it to this list too, isn't it?

Every time we add a new "named" analysis method we have to remember to add it to this list too, isn't it?

If we want completion to work with jedi yes. It seems to require that (at least in its current state), I've tried many combination of __dir__ and setattr() that gave no results. That makes sense since it is based on parsing the code, not dealing with built objects, even in its Interpreter mode which seems to only replace type inference by the actual type apparently (haven't checked the code, only based on my experiments).

Doesn't this patch kind of invalidate the dynamic loading?
Every time we add a new "named" analysis method we have to remember to add it to this list too, isn't it?

That's a shame, really. I'd be tempted to say I'd rather have no autocompletion than to have to maintain this dynamic members list...

I'd rather have no autocompletion than to have to maintain this dynamic members list

That's your call, I don't mind either. Since that list is relatively stable and short, it's not a big deal to maintain. IMHO it's better to end up with such list than fighting IPython's default, which will prevent from using what good things jedi can bring and is bound to being deprecated one day. We can track how that issue evolves, as it is likely to be the same that we have:
https://github.com/ipython/ipython/issues/11609

Cannot we make that list dynamically created whenever the module is first used?
That's what we used to do in lisa master before re-organizing all the analysis code...

IOW, cannot we build those bindings as part of the loop we have in:
https://github.com/ARM-software/lisa/blob/next/lisa/analysis/__init__.py#L25
so fare it seems we have a pretty straightforward translation from module name to the Analys class it provides, e.g.
   self.MODULE = lisa.analysis.MODULE.MODULEAnalysis()

there MODULE is just all small case and _ separated apart from the last usage which is camel case.

Cannot we make that list dynamically created whenever the module is first used?

That is what we currently do as well. jedi find the files and parses them, without executing anything. As I said before, tricks based on setattr() (lisa legacy) give the same results as implementing __getattr__() (I tried it): jedi does not care, since it won't execute anything anyway. The link to Ipython issue tracker (https://github.com/ipython/ipython/issues/11609) is most_ likely caused by the same issue: they want jedi to look at what a function returns (a property), but jedi won't execute it so it does not know what that is (and does not try to be smart in that case apparently).

That's what we used to do in lisa master before re-organizing all the analysis code...
ipython and jedi changed in the meantime, I've seen no evidence so far that this reorganization is the source of the issue. On the other hand, I've seen evidences that jupyter nowadays do not complete on things set with setattr() anymore by default, which is what LISA-legacy used to do. Completion would be as broken using LISA-legacy style as LISA-next using a march 2019 installation of jupyter.

IOW, cannot we build those bindings as part of the loop we have in

The only loop that can buy us anything would be a loop creating new files, or worse, patching existing files. jedi is basically blind on anything that involves meta-programming, since it won't execute that loop (or anything else). It's also a very bad idea, as python modules may not even be files at all (executed from a zip file, bundled using pyfreeze etc). The location where the package is installed is also typically not writeable as a regular user  (/usr/lib/python3.7/site-packages/), and it would introduce race conditions when multiple processes importing lisa are started.

repo: ARM-software/lisa