mask 2 json

Hi, thanks for the code.
I have a mask (binary file) and original image.
How can I change it to JSON file ? I tried run the script in ur guide. But it's failed to get the information of area value 1 in mask file.

Thanks for issuing.
you can follow this script for converting masks to jsons.  https://github.com/guchengxi1994/mask2json/blob/test/test_scripts/mask2json.py
also, following codes maybe helpful.
from convertmask.utils.methods import getMultiShapes

imgPath = 'D:\\testALg\\mask2json\\mask2json\\static\\multi_objs_test.jpg'
maskPath = 'D:\\testALg\\mask2json\\mask2json\\static\\multi_objs_json\\label.png'
savePath = 'D:\\testALg\\mask2json\\mask2json\\static\\multi_objs_json\\1109\\'
yamlPath = 'D:\\testALg\\mask2json\\mask2json\\static\\multi_objs_json\\info.yaml'
getMultiShapes.getMultiShapes(imgPath, maskPath, savePath, yamlPath)  # with yaml

getMultiShapes.getMultiShapes(imgPath, maskPath, savePath)  # without yaml

with a yaml file or without a yaml file is very different, you can test by yourself.

Thanks for the reply, but the url is broken. I'll appreciate if you refresh the url.
I have a question with yaml file. Is it created by some script or which script I can create that file in your code file?

you can copy the url and open it in your browser, it works for me. Otherwise, you can copy the code into your script , change your file path and have a try.
The yaml file is a file saves the label information like this.
label_names:
  _background_: 0
  fruit1: 1
  fruit2: 2
  fruitn: 3

Besides, those files in my script/code can be found in the 'static' folder.

you can create the yaml file by yourself, just like i posted.


[AMO-Dev] New submited theme is not listed in Editor Tools pending queue

Steps to reproduce:

Sign in AMO-dev with an admin account https://addons-dev.allizom.org/en-US/
Upload a new theme (i.e. New-Theme-Color)
Go to Editor Tools and review the theme

Expected results:
The new submitted theme is listed in the pending queue.
Actual results:
The theme is not listed.
Notes/Issues:
Verified on FF43(Win 7). Issue is only reproducing on AMO-dev.
Screencast for this issue: http://screencast.com/t/F3I8Kjf9uUo
Don't know if is for sure a js error, but until it will be checked I am adding this to the tracker: #1197

I don't see this being a JS error - I didn't see any JS errors through the submission process with persistent logs turned on.
I've just added a theme can you look for it in the queue I don't yet have admin on -dev? The slug is "my-test-theme-of-win".

There is something strange happening.
When I make a search after your theme slug... my themes are listed.
Please see the screenshot:

Also, my themes and your theme are listed in the pending queue NOW. Maybe is a time/caching issue. On stage things happen instantly.

At this point, we will have to ignore these timing problems on dev because the infrastructure is just different. That's a shame, I know, but let's worry about stage.


Get Wit.AI Story Bot Answer

First of all, thank you very much for this awesome Repo.
I already tried the GetAnswer() function and I get the right intent.
Is there any way how I can get the Bot answers from my story?

I'll try to take a look tonight.

Hi thank you very much. I'll also try to find a solution, should work via the /converse Request from Wit.ai. I already worked with the https://github.com/tgallice/wit-php repo but don't understand the /converse Request with the Session_ID part.

Hi @christophrumpel just tried the following solution and hope you can propably work with this.```
`<?php
$ch = curl_init();
$Input="TEXT";
$Input=urlencode($Input);
curl_setopt($ch, CURLOPT_URL,"https://api.wit.ai/converse?v=20160526&session_id=SESSIONID&q=$Input");
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,$vars);  //Post Fields
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$headers = [
'Content-Type: application/json',
'Authorization: Bearer TOKEN',
'Accept: application/json'
];
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
$server_output = curl_exec ($ch);
curl_close ($ch);
$output=json_decode($server_output, true);
echo $output["msg"];
?>`

Hi @christophrumpel I'm sorry for the late reply. Well you're right, basically I thought that it's much more easier to use a wit story than to code a own "storyline". If you want to work with Wit.ai there currently two options:

You use Wit.ai as an "interpreter" and use their technology to filter entities from messages and afterwards code your own actions and replies.

You use the stories and directly reply to users in that way.

Well for me the 2nd choice was quite tempting because if you do it in the right way you can build a working chatbot and connect it to almost every plattform without any bigger efforts.
What's your opinion on api.ai and their system? I already checked out their interface but was not as satisfied as with the wit.ai one. I'm currently looking around for an solution to build chatbots with a minimum of efforts and waste of own ressources.

Hey @TobiM93 , sry for the late reply. I missed your answer.
I am working a lot with botman.io right now which is a multiple-channel chatbot library for PHP. It is not that easy to start but has lots of features.
I still want to keep this boilerplate as simple as possible to give people an easy entrance point to building a chatbot. I am sure there is place for improvements though.


Update RainWeatherEffect to Foundry VTT 0.7.9

Which class should be updated?
RainWeatherEffect
For which version should the class be updated?
Foundry VTT 0.7.9

Taking this

Fixed by #312


Engine build issue

With the latest version of the pipeline merged, I now get the following at the jre building stage :
rm("target/classes");                                \
exec(env("JAVA_HOME", "F:/Nextcloud/Devs/pipeline-ui/engine/src/main/jre/OpenJDK17U-jdk_x64_windows_hotspot_17.0.7_7/jdk-17.0.7+7"),               \
     "mvn.cmd", "-f", "build-jre.xml", "jlink:jlink", "-Pbuild-jre-win64");
[INFO] Scanning for projects...
[INFO]
[INFO] -----------------------< org.daisy.pipeline:jre >-----------------------
[INFO] Building jre 0.0.0-SNAPSHOT
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- maven-jlink-plugin:3.1.0:jlink (default-cli) @ jre ---
[ERROR] The given project F:\Nextcloud\Devs\pipeline-ui\engine\target\classes does not contain a module-info.java file. So it can't be linked.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.594 s
[INFO] Finished at: 2024-04-17T08:56:58+02:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-jlink-plugin:3.1.0:jlink (default-cli) on project jre: The given project F:\Nextcloud\Devs\pipeline-ui\engine\target\classes does not contain a module-info.java file. So it can't be linked. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
make[1]: *** [Makefile:488: -Pbuild-jre-win64] Error 1
make[1]: Leaving directory 'F:/Nextcloud/Devs/pipeline-ui/engine'

Checking the engine develop branch, it seems this commit is breaking the build chain : https://github.com/daisy/pipeline-assembly/commit/8c8149112f83e3efbc6c7d0c970bb63645589bdc
If I revert it, it builds correctly again.

Darn

Don't know why this suddenly started happening for you. I can't reproduce it. And I thought the rm("target/classes") makes sure this error can not happen. Could you check if the target/classes directory is present? Can you check if this branch works better?

Can we close this - does it work now?

Seems good to me in my latests tests.
I'll close it right now.


Issue 434: Add VCV IDs to evidence strings

Closes #434

End-to-end tests will pass once the OT schema is updated.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>4
Details

6 of 6 (100.0%)  changed or added relevant lines in 2 files are covered.
2 unchanged lines in 2 files lost coverage.
Overall coverage decreased (-0.05%) to 80.613%

Files with Coverage Reduction
New Missed Lines
%

cmat/trait_mapping/main.py
1
96.2%

cmat/output_generation/evaluation/ols_utils.py
1
86.67%

Totals

Change from base Build<PHONE_NUMBER>9:
-0.05%

Covered Lines:
1867

Relevant Lines:
2316

💛  - Coveralls


Add versioning to MIOpen config and cache paths

To reduce the chance of collisions between schema as a result of version change, this PR versions the MIOpen config and cache directories.

I see several aspects to discuss. What we are going to change and why, plus how we are doing that.
First about "how".
MIOpen versioning is already used for find-db. files I highly recommend employing the similar approach, i.e. encoding the version information into the filename. Please see https://github.com/AMDComputeLibraries/MLOpen/issues/1139 for some discussion. Implementation generates parts of the filename ("suffixes") and then using these suffixes as appropriate.
To avoid duplication, I would recommend defining the variable for version info to be encoded into database paths. I would propose something like
set(MIOPEN_VERSION_SUFFIX "${MIOpen_VERSION_MAJOR}_${MIOpen_VERSION_MINOR}_${MIOpen_VERSION_PATCH}" CACHE PATH "Allows different versions of the library to use different database files")

This can be reused in definition of MIOPEN_USER_DB_SUFFIX.
About "what we would like to do and why" -- this topic worth ticket, I think. I would better dedicate a ticket to it. However we can discuss right here, if you would like to. Please let me know and I will proceed.

@atamazov we can discuss it here.

@JehandadKhan okay, thanks.
I am assuming that the purpose is to support several installations of MIOpen (built with different installations of ROCm) on the same machine, right?
The obvious solution is including ROCm version into the db pathnames. What I am missing?
What is the purpose of "tweak" in the db pathname?
I think that need to change the User find-db pathname as well.
Is it so that OCL and HIP backends share the same binary cache and perf-db?
Do we need to support two installations of MIOpen built with different backends (OpenCL and HIP) on the same machine? (single ROCm installation)

This change is required by this blocking ticket:
http://ontrack-internal.amd.com/browse/SWDEV-220965
The only change we require is to separate the user files based on the ROCm version components used.

What is the purpose of "tweak" in the db pathname?
The purpose is to associate a version of MIOpen that is build with the components of a specific ROCm release's tools.

Do we need to support two installations of MIOpen built with different backends (OpenCL and HIP) on the same machine? (single ROCm installation)

No.

@daniellowell Thanks for feedback.

This change is required by this blocking ticket: http://ontrack-internal.amd.com/browse/SWDEV-220965

[Clarification] This is P2 "must solve", not a P1 blocker.

The only change we require is to separate the user files based on the ROCm version components used.

[Clarification] Separation needs to be done for the binary cache and for find-db. WRT perf-db I agree with @pfultz2 that this is not needed.

What is the purpose of "tweak" in the db pathname?

The purpose is to associate a version of MIOpen that is build with the components of a specific ROCm release's tools.

But TWEAK does not depend on ROCm release's tools.
Perhaps I am too dumb, but let me repeat my previous question: The obvious solution is including ROCm version into db pathnames. What I am missing?

It is a P2 for now, but it is a requirement to get this all nailed down so I am treating it like a P1.

WRT perf-db I agree with @pfultz2 that this is not needed.

I don't see how that is going to work. The data base is continuously updated in functionality. We are adding 3D convolutions which means the ~/.config/miopen/miopen.udb will become obsolete. If that isn't versioned then that's a problem.

But TWEAK does not depend on ROCm release's tools.

True, but it does have a build number. That should be suffienct.
Versioning the individual files seems less tidy than versioning their directories. I mean we can do both if that makes you happy. It seems confusing if there are 5 version of the same file under 2.4.0 if we don't change the version of MIOpen over 5 releases (for example).

I don't see how that is going to work. The data base is continuously updated in functionality. We are adding 3D convolutions which means the ~/.config/miopen/miopen.udb will become obsolete. If that isn't versioned then that's a problem.

What do you mean obsolete? Is the schema changing? Isn't 3D convolutions just a different key lookup?
We probably do need to version perfdb but it should based on if we make backwards compatible changes instead of using the rocm version.

But TWEAK does not depend on ROCm release's tools.

It does. In rocm 3.0, the version was <IP_ADDRESS>17-rocm-rel-3.0-6-948938d and in 3.1 it was <IP_ADDRESS>33-rocm-rel-3.1-35-9218683. That last part of the version is the tweak. It gets set to a commit number(ie 7617), the build id(ie rocm-rel-3.0-6) and the commit hash(ie 948938d).

What do you mean obsolete? Is the schema changing? Isn't 3D convolutions just a different key lookup?

Schema yeah, for 3D convolutions. @JehandadKhan I think that should it should just be insertion warning if an new 3D record is going to be inserted into an, so that we maintain backward compatibility if users want to keep their old user performance database.

Schema yeah, for 3D convolutions.

Why is it a schema change?

Schema yeah, for 3D convolutions.

Why is it a schema change?

Because we added new fields, unlike a text file we do not concatenate string to form a key, the different parameters are fields in a table which get a SELECT query on them. Since 3D convolutions require new fields, therefore the schema changed.

Schema yeah, for 3D convolutions.

Why is it a schema change?

We can do that programmatically by being more smart about creating the database. Currently we don't do that since it requires the database being locked for longer during creation.

Since 3D convolutions require new fields, therefore the schema changed.

But shouldn't that be in a different table?

Since 3D convolutions require new fields, therefore the schema changed.

But shouldn't that be in a different table?

Adding columns to a table is also a schema change.

@daniellowell , @atamazov , @pfultz2 do we have a consensus on what we want to do ?

I think we should version perfdb but only change the version when there are non-backwards compatible changes(such as schema changes). It shouldn't be based on the rocm version.

I think we should version perfdb but only change the version when there are non-backwards compatible changes(such as schema changes). It shouldn't be based on the rocm version.

That is what I think as well. To be specific we are talking about the user perf db versioning.

@pfultz2

It does. In rocm 3.0, the version was <IP_ADDRESS>17-rocm-rel-3.0-6-948938d and in 3.1 it was <IP_ADDRESS>33-rocm-rel-3.1-35-9218683. That last part of the version is the tweak. It gets set to a commit number(ie 7617), the build id(ie rocm-rel-3.0-6) and the commit hash(ie 948938d).

What I'am seeing on my ROCm 3.0 machine differs a bit. It is <IP_ADDRESS>60-a02171c92, where a02171c92 is a MIOpen commit hash. However 7760 looks like commit number and should be sufficient for our purposes.
It seems like we can use tweak to detect ROCm version and build number info, so I will eventually try to use it for "compiler version detection" instead of checks at run time.
Thanks for the explanation.

@JehandadKhan

do we have a consensus on what we want to do ?

I think so, yes.

@atamazov @pfultz2 I have updated the code in light of the discussion above, a few salients:

SQLite schema has its own version now, which is set in the CMake file.
I have removed the subdirectories for the MIOpen version. This appeared to be redundant now.
I have applied the changes to the perf db and the binary cache.

It seems like we can use tweak to detect ROCm version and build number info, so I will eventually try to use it for "compiler version detection" instead of checks at run time.

You should not use this for compiler version detected. The compiler version could be unrelated to the rocm version. We install newer compiler version on older rocm all the time.
Instead, you should use feature detection instead(ie try to compile a test program to see if it will pass). This can be done at cmake time or at runtime. I believe this was done before.

Also, the versioning for finddb needs to include the tweak if it isn't already.

@daniellowell @pfultz2 @atamazov All reviewer comments addressed

@JehandadKhan, would you be able to get this change in this week?

@aserio Yes, if the CI passes.

Great! We have promised this feature for the next release.


Unreleased semaphore blocks httprc indefinitely  if a Transform panics

Description
The semaphore acquired here https://github.com/lestrrat-go/httprc/blob/e71784b6c22397cb2a0cf2579a4b90083c797fc0/cache.go#L155 isn't released with a defer
If a Transform panics the semaphore is never released, and the next call to a Cache.Get will block indefinitely

I've open #33 which should fix the issue

IIRC, that releaseSem is intentional: I wanted it to be released BEFORE the next lock happened in the same function happened, not when the function returned. I think if a Transoform could panic it would be better to protect the call to Transform itself, not the locks.

I think it's troublesome that a Transform could block the cache
Since a Transform is intended to do things like parsing XML, RSS, and it can happen for one of those to panic
We run this lib in a REST/GQL service and I as a client did not expect that panic would block my GQL resolvers/REST handlers :D
I've already protected my Transform function, but I still think this behaviour should not be expected
At the very least could we add a note in the README?

No, I'm not arguing against putting a fix, but I'm suggesting that you could protect the call to e.transform.Transform in fetchAndStore instead of mucking with the locks.
(As an side: I don't disagree with needing to handle error cases like this, but TBH if you have the leeway to do so, I'd reconsider using RSS/XML libraries that panic instead of returning errors)

Ah, I misunderstood, I'll try to give it a go maybe this weekend on protecting the Transform itself and leaving the semaphore alone


Control over method names

First, thanks for this!
I find this most useful for allowing read-only access to some data members. I guess being able to allow for setters and get_mut is useful in some cases (though why would anyone want a private setter?). But so far, my main usage pattern is:
#[derive(Property)]
#[property(get(public), set(disable), get_mut(disable))]
struct Foo {
    bar: Bar,
    ...
}

It would be nice if this combination was the default (the only safer combination is disabling everything). But of course, writing this single line is a pleasant alternative to writing all these getters...
Speaking of getters, I find the get_ method prefix to be an eyesore. I'd rather write foo.bar() to access the bar data member. Likewise, if I offered mutable access, I'd rather call it foo.mut_bar().
I understand the need to distinguish between the three method families. A set_ prefix makes sense. But for getters, whether or not one wishes to have get_ prefix seems debatable.
So... is there any chance to have a #[property(get_prefix(disable), ...)] or something along these lines?

Thanks for your suggestion!

It would be nice if this combination was the default ...

pub(crate) is the default visibility for all getter and setter.
I think it's safe enough for most cases.

So... is there any chance to have a #[property(get_prefix(disable), ...)] or something along these lines?

I will do this feature in few days, asap.
(I have to finish several tasks for my job before I have time to do this).
In next version, I will try adding three attributes: name, prefix, suffix.
Then, users can define names like this:
#[derive(Property)]
#[property(get(prefix = "get_"), get_mut(prefix = "", suffix = "_mut"))]
struct Foo {
    #[property(get(name = "read_bar"))]
    bar: Bar,
    ...
}

And, if nobody like the get(prefix = "get_") prefix, I will set get(prefix = "") as the default (BREAKING CHANGE).

Just found this crate and it’s exactly what I’d like, except for the naming convention with get_*. I’d love for this to be implemented.

I have finished this feature, and I will publish a new version in few hours.
But, to be honest, I didn't do enough tests.

Just tried it, seems to work fine. Thanks!


Improve error message when a target cannot be found

Follow up on PR https://github.com/microsoft/qdk-python/pull/245

/azp run


Fix nucelotide.pony (sic)

The file itself is misspelled, but as well this file contains the amino acid primitives which should be moved to an amino_acid.pony or similarly named file.

Fixed in eb701c434b783cd3e955670d1645ee67f0194be9


Stacktrace file references

Is there a way to configure the stack traces such that they're a bit more helpful?
My error messages via Chrome dev tools almost never point to a specific project file.  I wouldn't think anything of it, but webpack/React setups I've used in the past have generally pointed to the file/line of the error.
I'm still learning both techs, so it's not clear to me if that's a result of different configs (hoping that it is & this is relatively easy to activate).
Here's an example of an error I'm currently tracking down.
warning.js:44Warning: React.createElement: type should not be null, undefined, boolean, or number. It should be a string (for DOM elements) or a ReactClass (for composite components).warning @ warning.js:44

invariant.js:45Uncaught Invariant Violation: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object.

After another ~month of working in this kit, I've learned the above super-vague errors can be thrown by nearly anything, e.g.:

using an undefined variable or un-imported component
forgetting to use {destructuring} brackets on import statements
passing certain invalid props to components

Unfortunately, without even the file name to go on, it becomes a game of ctrl+z and prayer.
Just wanted to ask again: is this normal behavior?  I haven't tried to adjust any settings in the guts of the kit, but I've used other projects where the error messages had actual useful info in them, so I'm assuming this is something unique to this kit.
This sort of no-details error comprises about 70-80% of the errors I encounter, and in some instances it's taken an hour to track down even a simple typo. Is anyone else having a similar experience here?
Welcoming any sort of ideas or tips if anyone has a second to weigh-in.

@brandonmp: there was an awful bug for a while after we dropped react-transform for hot reloading and instead rendered redbox errors ourselves.
Check out this commit: https://github.com/davezuko/react-redux-starter-kit/commit/20c8078aafa3df71bc24b8efdfe1d0e060ec600b and see if this change has been made in your project. If not, it's likely that this will solve the issue... since we were trying to render an undefined component.

Will have to browse commits in past ~90 days to see if there's anything else I've missed.
Thanks a ton @davezuko

Glad that fixed it, it was indeed super annoying and I apologize for not catching it myself (and sooner). Lucky for you, there really hasn't been a ton of activity in the repo lately, as that's the most significant fix I can recall in the recent past.


Option to place element attributes on new lines

Hi,
Very useful extension.  Thank you.
Would it be possible to add an option to place each elements attributes on a new line when formatting?
i.e. xmlTools.splitAttributesOnFormat
In the case where elements may have a large number of attributes this makes the xml much more readable.

Would also love the same.
For example:
    <report
        id="report_web_quote"
        string="Web Quotation"
        model="sale.order"
        report_type="qweb-pdf"
        file="website_quote.report_quotation"
        name="website_quote.report_quote"
        menu="False"
    />

+1 to this suggestion, it will be super helpful to have it!
Thanks!

@nknganda using Odoo? :)

Yes @lekhnath. Currently training on it.


0-stor blocks forever when reconstructing missing shards

Same scenario as https://github.com/threefoldtech/0-stor_v2/issues/76 (after recompiling the fix), no more missing-key errors but the zstor hook doesn't return and the retrieving and reading blocks forever.
Random info:

zstor.log:

2021-11-15 09:25:00 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:9900
2021-11-15 09:25:00 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:9900
2021-11-15 09:25:00 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:9900
2021-11-15 09:25:00 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:9900
2021-11-15 09:25:00 +00:00: WARN NopExplorer started, automatic capacity managment is disabled
2021-11-15 09:25:00 +00:00: DEBUG Backend manager actor started, loading backends to monitor
2021-11-15 09:25:00 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:8800
2021-11-15 09:25:00 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:8800
2021-11-15 09:25:00 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:8800
2021-11-15 09:25:00 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:8800
2021-11-15 09:25:00 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:9900
2021-11-15 09:25:00 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:9900
2021-11-15 09:25:00 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:9900
2021-11-15 09:25:00 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:9900
2021-11-15 09:25:01 +00:00: WARN Could not get 0-db-fs stats: Not a tty (os error 25)
2021-11-15 09:25:02 +00:00: WARN Could not get 0-db-fs stats: Not a tty (os error 25)
2021-11-15 09:25:03 +00:00: WARN Could not get 0-db-fs stats: Not a tty (os error 25)
2021-11-15 09:25:14 +00:00: DEBUG Handling new client connection from (unnamed)
2021-11-15 09:25:14 +00:00: DEBUG encoding file "/tmp/zdb.hook.sTwb4LuS.tmp/i0" with key path "/data/index/zdbfs-data/i0"
2021-11-15 09:25:14 +00:00: DEBUG Handling new client connection from (unnamed)
2021-11-15 09:25:14 +00:00: DEBUG file checksum: 9966251d486c80096be6ad05cf343eb4 ("/tmp/zdb.hook.sTwb4LuS.tmp/i0")
2021-11-15 09:25:14 +00:00: DEBUG Finding backend config
2021-11-15 09:25:14 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:8800
2021-11-15 09:25:14 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:8800
2021-11-15 09:25:14 +00:00: DEBUG found valid backend configuration
2021-11-15 09:25:14 +00:00: DEBUG Saving metadata for key /hamada/meta/30fedb5562c093176136eda518fdb0d9
2021-11-15 09:25:14 +00:00: DEBUG Writing data to zdb metastore
2021-11-15 09:25:14 +00:00: DEBUG encoding file "/data/data/zdbfs-data/d0" with key path "/data/data/zdbfs-data/d0"
2021-11-15 09:25:14 +00:00: DEBUG file checksum: 0b9ea60a5af2a2cf300704c071f76f20 ("/data/data/zdbfs-data/d0")
2021-11-15 09:25:15 +00:00: DEBUG Finding backend config
2021-11-15 09:25:15 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:8800
2021-11-15 09:25:15 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:8800
2021-11-15 09:25:15 +00:00: DEBUG found valid backend configuration
2021-11-15 09:25:16 +00:00: DEBUG Saving metadata for key /hamada/meta/b76d074c120d900d6f3065e45bdad1a7
2021-11-15 09:25:16 +00:00: DEBUG Writing data to zdb metastore
2021-11-15 09:25:29 +00:00: DEBUG Handling new client connection from (unnamed)
2021-11-15 09:25:29 +00:00: DEBUG Loading metadata for key /hamada/meta/b76d074c120d900d6f3065e45bdad1a7
2021-11-15 09:25:29 +00:00: DEBUG Reading data from zdb metastore for key /hamada/meta/b76d074c120d900d6f3065e45bdad1a7
2021-11-15 09:25:29 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:8800
2021-11-15 09:25:29 +00:00: DEBUG connecting to zdb at <IP_ADDRESS>:8800
2021-11-15 09:25:31 +00:00: INFO rebuild data from shards

strace -p <zstor-hook-pid>:
epoll_pwait(16,
ls -la /proc/<zstor-hook-pid>/fd/16
/proc/202679/fd/16 -> 'anon_inode:[eventpoll]'
strace -p <zstor-daemon-pid> blocks forever and cant even CTRL+C

Fixed in 261ffba132d3c5d17648b829551d4df97d3730bb


Add master excel submission spreadsheet to the dashboard

Add empty spreadsheet for now, it will be populated withe the extracted information in the future

Closing as Duplicate of #190


Multiple Installations On Windows

Chromiums is a portable installer but when I install it twice or more times all the settings are shared across each installment. Is it possible to make it each installment of Ungoogled Chromium is fully separate from eachother? I know Vivaldi browser allows this with its own portable installation.

In Chromium, you can change the user data directory to a custom path via a command-line argument. This is a commonly-used feature you can search online for.

Is it possible to create an installer that is an portable installer where you can select the user directory path for a more user friendly setup?

where you can select the user directory path

What do you mean by a "user directory path"?

By choosing the user data directory custom path without a command line but instead use a installer to select the data directory

Chromium's default installer does not support this. If you want this functionality, please develop it as a standalone wrapper around Chromium.


Enable ccache on Travis

Let's see how this goes...

Looks like ccache shaved 20-30 seconds off the build... Maybe. One more build just to check.

Hmm... Just a tiny bit faster for subsequent builds...


drivers: eth: e1000: Add driver Intel PRO/1000 Gigabit Ethernet contr…

…oller
This patch adds a driver for Intel PRO/1000 Gigabit Ethernet controller.
The driver currently supports only a single instance of the NIC.
Signed-off-by: Oleg Zhurakivskyy<EMAIL_ADDRESS>

@galak can you re-review please?

Also, would be nice to get info on how to actually use this with qemu_x86. For starters, this info in quick form can go into a commit message, but ideally, it should be documented in Zephyr docs, as it will be important feature everyone will want to use.

“depends on” is fixed.

Thanks.

There’s nothing wrong with the macros here.
Register names are mostly 3 characters long, using READ/WRITE would visually dominate over the register names.

Well, we don't control readability of register names in vendor hardwares. But we control readability of Zephyr source code. So, please just follow  conventions as used by other drivers:
$ zephyr/drivers/ethernet$ grep read *.c
eth_dw.c:	int_status = eth_read(context->base_addr, REG_ADDR_STATUS);
eth_enc28j60.c:		eth_enc28j60_read_reg(dev, ENC28J60_REG_MISTAT,
eth_sam_gmac.c:	i2c_burst_read_addr(dev, CONFIG_ETH_SAM_GMAC_MAC_I2C_SLAVE_ADDRESS,
phy_sam_gmac.c:	retval = phy_read(phy, MII_ANAR, &ability_adv);

e1000_read/e1000_write would be good names to use.
Related suggestion of using SYS_LOG_ERR() and friends directly also remains.

So, please just follow conventions as used by other drivers
I can’t see any convention. Using functions here is technically worse, since we would lose the context in diagnostic output. Try to actually run the code and observe the difference with your proposal.

I can’t see any convention.

It's what I already said: the names are/should be descriptive.

Using functions here is technically worse, since we would lose the context in diagnostic output.

Ah, that's not what I mean. Those don't have to be functions. And if you want to name them in caps to follow the standard macro convention, that's fine. As long as they aren't named "D" for debug, "W" for warning... No, wait, "W" means "write"! Well, that's exactly what I mean re: descriptive naming.

[...] No, wait, "W" means "write"!

OK, addressed this. There's no such problem now.

@ozhuraki:

[...] No, wait, "W" means "write"!

OK, addressed this. There's no such problem now.

Better, better, thanks! Now only D and E are left to go ;-).
Let me reiterate again on arguments, though most of them were already given:

D and E are too short names and thus confusing (definitely will be for beginners).

But mot importantly, there's SYS_LOG_DBG and friends, which can be used directly. And most other drivers use those. (I write "most", but I actually didn't see a counter-example.)
If we let those in, we open a road for "in my special way" for individual programmers. For example, you like D and E, programmer1 likes DBG and ERR, programmer2 - DBG and ER (sic), programmer3 - DGB and ERR, and I like ABC and CDF (I like it weird).
Again, using standard API is useful for searching, grepping for "SYS_LOG_" will give any places where logging happens.

And well, I don't want this to look as personal nitpicking - @jukkar, you approved this PR, what do you think about usage of adhoc macros like D and E instead of standard API?

what do you think about usage of adhoc macros like D and E instead of standard API?

The other ethernet drivers seem to be using SYS_LOG_xxx() macros so it might makes sense do the same here too. Those syslog macros will be converted to new logging macros anyway pretty soon so I do not see here a big issue with the printing. I would like to see this merged quite soon after 1.14 opens as this is a useful driver to have.

I would like to see this merged quite soon after 1.14 opens as this is a useful driver to have.

Me too, so I really hope that @ozhuraki would listen to suggestions on how to improve it, and avoid introducing potentially problematic precedents into the codebase. There's a couple of days to think about that yet before 1.14 window opens ;-).

But mot importantly, there's SYS_LOG_DBG and friends, which can be used directly.

SYS_LOG_* aren’t circumvented here.

If we let those in, we open a road for "in my special way" for individual programmers

This isn’t "in my special way", but a standard way to do it. SYS_LOG_* are too visually noisy and do not aid code readability.
I am surprised you miss this issue and on the level of pickiness here.
Anyway, I addressed this.
It would be more interesting to see the arguments on why the device tree is needed for this this driver and on needless limitations of IRQ_CONNECT(), since both of them ruin the idea of auto detection in emulators (where this driver is targeting).

@ozhuraki :

This isn’t "in my special way", but a standard way to do it.

If you grep Zephyr codebase, then you'll see that not in Zephyr.

SYS_LOG_* are too visually noisy and do not aid code readability.

If it's visually noisy, then it's visually noisy everywhere. Please don't go for "partisan" tactics of patching individual files, go for an RFC to replace it globally in Zephyr, and if ack'ed, go to implement it as such, and then everyone will use something different that SYS_LOG_*. (Indeed, some guy recently did just that. No everyone has to drop everything and convert.)

on the level of pickiness here.

That's the impression I'd like to avoid. If we want to develop really high-quality product, we have to agree on some baseline rules and then constrain ourselves to follow them. In personal usage, I have no issues with D() and E(), but I truly believe they're wrong for a project like Zephyr.

Anyway, I addressed this.

#define dev_dbg(fmt, args...) SYS_LOG_DBG(fmt, ## args)
#define dev_err(fmt, args...) SYS_LOG_ERR("Error: " fmt, ## args)

I don't know why you can't use SYS_LOG_* directly, but I appreciate doing at least something.
Let me +1 this PR, thanks for developing it! But please mind suggestions from @jukkar on squashing fixup commit(s).

@ozhuraki:
I'm not a specialist on these matters, so just 2 cents from me:

It would be more interesting to see the arguments on why the device tree is needed for this this driver

Because devicetree is accepted standard for detailed hardware configuration in Zephyr. If this driver did complete PCI autoconfig, it wouldn't be needed. But as it doesn't, it follows standard way of using devicetree. (Thanks for that.)

and on needless limitations of IRQ_CONNECT(), since both of them ruin the idea of auto detection

My understanding that IRQ_CONNECT() is declarative directive which arranges static, the most efficient IRQ mapping. You understand how it works - it arranges something (ISR address/structure) to be put in ROM, just at the right address.
We also should have way to dynamically set ISR, including allowing drivers to do that. I don't know how much of that "should have" we actually have, we definitely need to elaborate that stuff in Zephyr further.
Note that  device tree was a big step in allowing flexibility of Zephyr hw configuration, even if not autoconfiguration.

in emulators (where this driver is targeting).

I won't be surprised if this driver will find wider usages than just for emulators. I won't be surprised even to find a device, where E1000 is used, but without PCI machinery attached. In this case, devicetree support will be right at spot, so thanks again for adding it.

@tbursztyka

actually it is "ok" to create new macros for logging on top of SYS_LOG_* but: such should be in capital letters.

It's ok if it's really needed, here the talk was that it's not really needed and about naming.

@pfalcon
A few key issues have been ignored here. As explained above:

There are no non-PCI variants of E1000.
This driver primarily targets emulator/simulator cases (qemu, simics) cases. Being able to auto-discover the configuration is a major usability and productivity point here.

Because devicetree is accepted standard for detailed hardware configuration in Zephyr.

This absolutely doesn’t mean that it should be mindlessly and needlessly applied, disregarding the context and usability.

@ozhuraki, as I told, I'm not a DT expert, mostly try to follow the stuff. So, I hope other folks might answer in more details. But according to my knowledge:
You had (and still have!) in the Kconfig:
config ETH_E1000_BASE_ADDRESS
	default 0XFEBC0000

We no longer configure such addresses via Kconfig in Zephyr, only via DT. That's why (per my understanding) you were asked to use DT.

@pfalcon
Kconfig is able to override DT and this is still supported.

That's why (per my understanding) you were asked to use DT.

To me, using it here is a solution looking for a problem and solution in a wrong place that actually introduces a problem.

ping @galak, could you re-review the changes so we could get this one merged.

@galak : Ping about approving/merging this. Besides pure usefulness of this driver, it's also the first ethernet driver to use DTS (no such in the tree), so would help with my work on adding smsc9220 support too.

@galak

I agree w/Paul, we do we need to support non-DTS Kconfig?

What exactly is still not clear in explanations above on non-DTS use cases?

@pfalcon

Besides pure usefulness of this driver, it's also the first ethernet driver to use DTS (no such in the tree), so would help with my work on adding smsc9220 support too.

Besides, as already explained a few times, irrationally insisting on DTS support here, is making it nearly unusable.

Could we please get this driver included with the current functionality? There are two other more than capable developers on this thread, @pfalcon and @galak, that can come with the additional patches, especially since there aren't any non-PCI hw configurations available.

Besides, as already explained a few times, irrationally insisting on DTS support here, is making it nearly unusable.

The project as a whole is using device tree for such information and moving away from Kconfig.  The idea of adding new driver support and still providing Kconfig options is against the direction the project is moving in.
Maybe I'm misunderstanding something, but I'm not seeing what the Kconfig support is providing that we can't do with device tree for the SoC that is being supported at this point.

@nashif

agree with @galak, we should be able to move the base address Kconfig to DTS

It’s actually already in DTS.

[…] if we need to change that for some specific platform configuration, we can use overlays or fixups.

Kconfig here does exactly that.

other [...] developers [...] that can come with the additional patches,

Exactly my attitude, we rarely get everything perfect from the first time, and I +1'ed from my side. But I'm just a developer, and just learn about DT usage in Zephyr, as many other folks too.

Kconfig here does exactly that.

the point is that we are trying to deprecated Kconfig usage for this purpose and thus dts overlay is the way to do that right now until PCI bus scanning & irq setup is supported for your needs.
Thus the desire to remove the Kconfig bits.

Kconfig here does exactly that.

ok, then I am confused. Why do you carry the same configuration in two places? Why don't we just move to DTS and skip the kconfig part?

@galak

Maybe I'm misunderstanding something, but I'm not seeing what the Kconfig support is providing that we can't do with device tree for the SoC that is being supported at this point.

I think there’s lack of understanding that the base address even on one SOC can change due to PCI enumeration/assignment and might depend on what PCI devices are present.
In case of emulators/simulators (where this driver is targeting), this might even depend on the order of PCI device instantiation (for example, in qemu).
Requesting DT here is solving the wrong problem in a wrong place.
And, without an ability to override, this DT only solution will be just unusable.

And, without an ability to override, this DT only solution will be just unusable.

you can override using overlays or fixup files. see https://docs.zephyrproject.org/latest/application/application.html#application-dt

@nashif

you can override using overlays or fixup files. see https://docs.zephyrproject.org/latest/application/application.html#application-dt

OK, thanks for the input. If Kconfig is deprecated for DT overrides, let’s use this.

@ozhuraki : Did you have a chance to look into this?

@ozhuraki ping

@pfalcon @nashif
Removed Kconfig entries for the base address and IRQ. Please take a look.

@ozhuraki : Thanks for making changing and squashing everything related to eth_e1000.c into one commit.
@galak, @nashif : Ping for re-review.

@galak

I noticed some logging support, not sure if that needs updating for the new logging subsystem.

Forgot to mention: I also updated it to use the new logging.

So, just as with https://github.com/zephyrproject-rtos/zephyr/pull/10097, I'm trying to "reverse engineer" how to get this to run. But unlike the above patch, I failed. My steps:

Enable the e1000 driver:

+++ b/samples/net/echo_server/prj.conf
+CONFIG_PCI=y
+CONFIG_PCI_ENUMERATION=y
+CONFIG_ETH_E1000=y
+CONFIG_NET_SLIP_TAP=n
+CONFIG_NET_L2_ETHERNET=y

Start with:
sudo /home/pfalcon/opt/zephyr-sdk-0.9.3/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-i386 \
-m 8 -cpu qemu32,+nx,+pae -device isa-debug-exit,iobase=0xf4,iosize=0x04 \
-no-reboot -nographic -vga none -display none \
-clock dynticks -no-acpi -balloon none \
-machine type=pc-0.14 -pidfile qemu.pid \
-serial mon:stdio \
-netdev tap,id=n1 \
-device e1000,netdev=n1 \
-object filter-dump,id=f1,netdev=n1,file=dump.dat \
-kernel /home/pfalcon/projects-3rdparty/Embedded/Zephyr/zephyr/samples/net/echo_server/outdir/qemu_x86/zephyr/zephyr.elf

What I get on Zephyr console is:
W: /etc/qemu-ifup: no bridge for guest interface found
qemu-system-i386: warning: Unknown firmware file in legacy mode: genroms/multiboot.bin

e1000: TDH wraparound @0, TDT 1, TDLEN 0
e1000: TDH wraparound @0, TDT 1, TDLEN 0
***** Booting Zephyr OS zephyr-v1.13.0-935-gb307be0382 *****
Zephyr Shell, Zephyr version: 1.13.99
Type 'help' for a list of available commands
shell> e1000: TDH wraparound @0, TDT 1, TDLEN 0
e1000: TDH wraparound @0, TDT 1, TDLEN 0
e1000: TDH wraparound @0, TDT 1, TDLEN 0

Pings to <IP_ADDRESS> don't work, per Wireshark, there're no replies to ARP, "net stats" shows:
Global statistics
=================
IPv6 recv      0	sent	5	drop	0	forwarded	0
IPv6 ND recv   0	sent	5	drop	0
IPv6 MLD recv  0	sent	0	drop	0
IPv4 recv      0	sent	0	drop	0	forwarded	0
IP vhlerr      0	hblener	0	lblener	0
IP fragerr     0	chkerr	0	protoer	0
ICMP recv      0	sent	0	drop	0
ICMP typeer    0	chkerr	0
UDP recv       0	sent	0	drop	0
UDP chkerr     0
TCP bytes recv 0	sent	0
TCP seg recv   0	sent	0	drop	0
TCP seg resent 0	chkerr	0	ackerr	0
TCP seg rsterr 0	rst	0	re-xmit	0
TCP conn drop  0	connrst	0
Bytes received 0
Bytes sent     288
Processing err 0

Result of PCI detection:
0:2 8086:100e class: 0x2, 0, 0, MEM,addrs: 0xfebc0000-0xfebdffff, IRQ 11

IRQ matches what's hardcoded in the DTS, but I don't see the driver ISR firing.

e1000: TDH wraparound @0, TDT 1, TDLEN 0

This message doesn't appear eth_e1000.c, and it was an unmonotonic thought to imagine it may come from QEMU, and indeed it is, as mentioned e.g. here: https://pdos.csail.mit.edu/6.828/2016/labs/lab6/

e1000: TDH wraparound @0, TDT 1, TDLEN 0

Well, these appear to be coming before e1000_init() is called, none after it.

@pfalcon
Looks to me you got everything almost right, just sort out the details with setting the tap interface.
A quick way to check if problems are tap related, is something like this:
qemu ... -device e1000,netdev=net1 -netdev socket,id=net1,udp=localhost:port1,localaddr=localhost:port2
and then look with the wireshark.
To smoke test the receive path this way, net-test-suites would work almost out of the box.
It might be easier to troubleshooting this with the static IP address configuration of your app, enable the debug output for the driver, get the signal through with the outgoing traffic, and then incoming.
e1000: TDH wraparound @0, TDT 1, TDLEN 0

Our usage is legal here. That warning is extra and, perhaps, needs a patch to qemu.

/home/pfalcon/opt/zephyr-sdk-0.9.3/sysroots/x86_64-pokysdk-linux/usr/bin/qemu-system-i386

I also tried with Zephyr SDK 0.9.4-rc3. With it, iPXE BIOS (or whatever it's called) is visibly booting, and there're no "e1000: TDH wraparound @0, TDT 1, TDLEN 0" warnings.
The rest of behavior is the same - pings don't go thru, IRQs not firing.

So, looking thru the captured traffic (-object filter-dump,id=f1,netdev=n1,file=dump.dat in my command above), seems that the e1000 manages to send out something which Wireshark on Linux side sees. So again, the reverse direction doesn't work, starting with getting a RX interrupt.
4	1.352135	::	ff02::1:ff12:3456	ICMPv6	78		Neighbor Solicitation for fe80::5054:ff:fe12:3456
6	1.355723	::	ff02::1:ff00:1	ICMPv6	78		Neighbor Solicitation for 2001:db8::1

@ozhuraki:

A quick way to check if problems are tap related, is something like this:
qemu ... -device e1000,netdev=net1 -netdev socket,id=net1,udp=localhost:port1,localaddr=localhost:port2

As I mentioned, I initially tried a similar approach with https://github.com/zephyrproject-rtos/zephyr/pull/10097, where everything worked, so there're no suspicions re: TAP interface.
I also initially started with "QEMU SLIRP" networking https://wiki.qemu.org/Documentation/Networking#User_Networking_.28SLIRP.29 , but that didn't work and that's shy I switched to TAP.
So, I'm not sure what your expectations re: the commandline params you gave, but mine were fully satisfied when I used -netdev socket,id=n1,udp=localhost:4242,localaddr=localhost:4242, then nc -u localhost 4242 on Linux side. So, for Zephyr to respond to something, it first need to resolve something's address via ARP, and of course, that can't work over "socket,id=n1,udp", so in Wireshark, I got the expected ICMP Destination unreachable.
And still not RX interrupts. (I have
 static void e1000_isr(struct device *device)
 {
+printk("e1000_isr\n");

obviously).

@ozhuraki : Can we go the other way, can you please provide the exact commands showing the complete IP communication cycle (e.g, ping running), which work for you with the latest master?

@jukkar : What about you, does this driver work for you?

I used this command line
qemu-system-i386 -m 8 \
      -cpu qemu32,+nx,+pae -device isa-debug-exit,iobase=0xf4,iosize=0x04 \
      -no-reboot -nographic -machine type=pc \
      -display none -clock dynticks -no-acpi -balloon none \
      -pidfile qemu.pid \
      -serial mon:stdio \
      -net nic,model=e1000,netdev=znet \
      -netdev tap,id=znet,script=no,downscript=no,ifname=znet \
      -kernel zephyr/zephyr.elf

@jukkar: My system qemu:
$ qemu-system-i386 --version
QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.5)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

So, when I tried to run the command as provided by you, I got complains about various "bios" files missing, e.g. efi-e1000.rom, so I picked it/them up from internets/local hdd.
Then it started to start.
I also changed -netdev line to:
-netdev tap,id=znet

so it created tap0 for me, which I ifconfig tap0 <IP_ADDRESS>'ed. Then the situation is absolutely the same as with my previous attempts - pings don't work, the driver doesn't see a single packet, I assume RX interrupts don't fire as before.
This is a cute situation as in https://github.com/zephyrproject-rtos/zephyr/issues/8869 , where everything works for me, but doesn't work for @nniranjhana and @nashif . Except we here try to call qemu versions and commandlines, but guys there don't provide any additional info.

I installed zephyr-sdk_0.9.4-rc3, it is missing some rom files but those can be temporarily picked from host system. With that qemu the ping works for about 6 seconds, after which the network connectivity stops.
What is also weird that I have now same symptoms with host qemu (connectivity stops after 6 seconds), I really wonder what has happened because this connectivity worked ok yesterday when I was testing it.


Create 2019.08 release notes (2019-10-01)

Adding new release notes

@rachael-phillips I made a bunch of updates if you want to review and update the PR:
# 2019.08 release notes (2019-10-01)
Packages released:
-<EMAIL_ADDRESS>
## Components
- **Charts:**
  - Adjust padding for pie and donut charts ([#2247](https://github.com/patternfly/patternfly-next/pull/2247))
  - Set mix-blend-mode for better color contrast ([#2239](https://github.com/patternfly/patternfly-next/pull/2239))
  - Update area chart opacity ([#2233](https://github.com/patternfly/patternfly-next/pull/2233))
- **Copy to clipboard:** Wrapped code in pre which allows the code to preserve line-breaks and spaces and also applies styling such as the monospace font. ([#2260](https://github.com/patternfly/patternfly-next/pull/2260))
- **Data list:** Make data list borders consistent with table ([#2289](https://github.com/patternfly/patternfly-next/pull/2289))
- **Data toolbar:**
  - Updated clear button mods ([#2248](https://github.com/patternfly/patternfly-next/pull/2248))
  - Added in examples for expandable ([#2273](https://github.com/patternfly/patternfly-next/pull/2273))
- **Flex layout:** Wrapped flex items, update css ([#2214](https://github.com/patternfly/patternfly-next/pull/2214))
- **Wizard:**
  - Re-enabled wizard modal demos ([#2259](https://github.com/patternfly/patternfly-next/pull/2259))
  - Updated in page wizard demos to use dark sidebar/nav ([#2296](https://github.com/patternfly/patternfly-next/pull/2296))
- **Navigation:** Added styling updates to dark nav ([#2283](https://github.com/patternfly/patternfly-next/pull/2283))
- **Page:** Added ability to keep sidebar collapsed between sizes ([#2264](https://github.com/patternfly/patternfly-next/pull/2264))
- **Pagination:** Added compact variation ([#2275](https://github.com/patternfly/patternfly-next/pull/2275))
- **Radio:** Updated the radio component example to single components ([#2231](https://github.com/patternfly/patternfly-next/pull/2231))
- **Table:**
  - Fixed a11y issues in org documentation/html/table ([#2282](https://github.com/patternfly/patternfly-next/pull/2282))
  - Added empty and loading state table demos ([#2254](https://github.com/patternfly/patternfly-next/pull/2254))
- **Tooltip:** Added text align left modifier ([#2284](https://github.com/patternfly/patternfly-next/pull/2284))
- **Select:**
  - Added typeahead form wrapper, udpated css ([#2255](https://github.com/patternfly/patternfly-next/pull/2255))
  - Add top expanded example ([#2026](https://github.com/patternfly/patternfly-next/pull/2026))
- **Chip group:** Add overflow to group ([#2278](https://github.com/patternfly/patternfly-next/pull/2278))
- **Button:** Add control modifier ([#2005](https://github.com/patternfly/patternfly-next/pull/2005))

## Other
- **Shield:** Added missing components, missing var to brand docs js ([#2263](https://github.com/patternfly/patternfly-next/pull/2263))

@mcoker just added the updates!

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add configurable DNS client for ConnectionPool

Fixes #6346
Motivation
Currently DNS client for PulsarClient cannot be configured and we are struck with default one. Specifically I needed to be able to configure the dns server list
Modifications

Added a new method: ClientBuilder.dns
Used configured dns builder instead of creating a new default one if provided in ConnectionPool

Verifying this change

[ ] Make sure that the change passes the CI checks.

This change is essentially a trivial rework, it just expose the ability to provider a custom DnsNameResolverBuilder and use it if provided.
Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): (yes / no) yes (added dependency on netty-dns-resolver to client api)
The public API: (yes / no)
The schema: (yes / no / don't know)
The default values of configurations: (yes / no)
The wire protocol: (yes / no)
The rest endpoints: (yes / no)
The admin cli options: (yes / no)
Anything that affects deployment: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no) yes
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented) JavaDocs
If a feature is not applicable for documentation, explain why?
If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

I'll add a configuration bean then :)

@diegosalvi Any updates on this PR? Move this PR to 2.7.0 and If there is any update, move it back.

Any updates on the state of this?

We support part of DNS configuration in #15219 by @lhotari.
To allow passing a DnsNameResolverBuilder in ClientBuilder, it can be a significant public interface change and I'd suggest go through a PIP process.
Closed as stale and conflict.


bug-UI(home page - hero): "Let's get Started" button does not function when Services section is hidden

Environment:
Production 6-11-2018
Steps to Recreate:
Navigate to openforge.io on any browser that is smaller than 1400px wide
Expected Result:
"Let's Get Started" button scrolls to Services section
Actual Result:
"Let's Get Started" button does not function (occurs when Services section is hidden)

Production:

@Wholloran
So with this issue, it is occurring because the 'services' section is currently hidden when it is in a smaller viewport (pending design updates for smaller viewports).
As a result, it will not scroll to a section that is hidden.
Should we change this temporarily to scroll to our process instead?

Yeah, I would think that's the best idea. The only other option would be to hide the button. But I feel just having it scroll to the Process is better.

@Wholloran - this is now QA ready on https://openforge-dev.firebaseapp.com/
Instead of doing any fixes on the button, I styled out the services section to be visible and responsive down to the smallest mobile viewport.  We don't have mobile designs for this yet, so horizontal scrolling is used to deal with the mobile navigation on the tabs (start up, enterprise, etc).

button now operates correctly closing the ticket


mesh.from_file throws Assertion Error if matplotlib figure is open when speedups=True

I run into troubles loading .stl files with stl.Mesh.from_file when there is some instance of matplotlib or Qt running in the same process. That is
import stl
import matplotlib.pyplot as plt

mesh=stl.Mesh.from_file(pathToStlFile)

works great. However, if before initiate a matplotlib figure, that is
plt.figure()
mesh=stl.Mesh.from_file(pathToStlFile)

I get the following Assertion Error:
 File "/usr/local/lib/python2.7/dist-packages/stl/stl.py", line 316, in from_file
    fh, mode=mode, speedups=speedups)
  File "/usr/local/lib/python2.7/dist-packages/stl/stl.py", line 85, in load
    name, data = cls._load_binary(fh, header, check_size=True)
  File "/usr/local/lib/python2.7/dist-packages/stl/stl.py", line 102, in _load_binary
    count, MAX_COUNT)
AssertionError: File too large, got 909389366 triangles which exceeds the maximum of 100000000

Looking through the code in BaseStl and reading through this issue https://github.com/WoLpH/numpy-stl/issues/37, I realized that this is due to the fallback if _load_ascii throws a runtime error such as
 File "/usr/local/lib/python2.7/dist-packages/stl/stl.py", line 212, in _load_ascii
    return _speedups.ascii_read(fh, header)
  File "stl/_speedups.pyx", line 132, in stl._speedups.ascii_read (stl/_speedups.c:2613)
RuntimeError: (0, "Can't read vertex (4:vertex 176.46 176.46 0)")

So it seems that somehow the speedup is not working properly (some Cython clash with Qt/matplotlib?). Turns out that
plt.figure()
mesh=stl.Mesh.from_file(pathToStlFile,speedup=False)

works great. This took me a while to figure out and I thought it might be interesting.

Hmm, that's unfortunate.
Would you be able to attach the stl file so I can check what's wrong? It seems your file uses a slightly different format which breaks the parser.

I've generated the stl file using openscad. I've attached both the .scad that was used to generate the  .stl
file and the .stl file itself. It should only be a simple cube.
I am not completely sure if there is an issue with the file itself, since I can load the file without problem when I do not generate a MPL figure before.
meshfiles.zip

I'm still not sure what's causing it exactly, I'm not able to reproduce it myself but I suspect that matplotlib is somehow wrapping the file handlers.
For the time being it makes no sense to me... perhaps a namespace clash somehow but I have no idea what. Are you certain you are runing the latest version? It seems the line numbers in your stacktrace don't line up with the current release: https://github.com/WoLpH/numpy-stl/blob/develop/stl/_speedups.pyx#L132

I was running version numpy-stl 2.0.0, however after upgrading to version 2.2.0 I still end up with the same error message:
Traceback (most recent call last):
  File "debug_stl_from_file_error.py", line 13, in <module>
    mesh=stl.Mesh.from_file(sys.argv[1],speedups=True)
  File "/usr/local/lib/python2.7/dist-packages/stl/stl.py", line 318, in from_file
    fh, mode=mode, speedups=speedups)
  File "/usr/local/lib/python2.7/dist-packages/stl/stl.py", line 87, in load
    name, data = cls._load_binary(fh, header, check_size=True)
  File "/usr/local/lib/python2.7/dist-packages/stl/stl.py", line 104, in _load_binary
    count, MAX_COUNT)
AssertionError: File too large, got 909389366 triangles which exceeds the maximum of 100000000

I hope the lines make more sense now. But stl.__about__.__version__ returns 2.2.0.

Can you tell me a bit more about what software versions you are running?
Linux, Windows, osx and version?
Matplotlib version
Python version and release (2.7 regular, pypy, etc.)?

Probably should have done this in the first post:
OS: Xubuntu 14.04 (3.13.0-61-generic)
Python: Python 2.7.6 standard installation
Matplotlib: 1.4.3
Cython (if this is any important): 0.20.1post0
Numpy: 1.12.1

For the time being I've created a new release which falls back to the regular ascii version.
Thinking about it I may know what the issue was, I was using universal-wheels which work great if you're only running pure Python. The speedups might have been broken for everyone not running OS X

Note that for the related https://github.com/Ultimaker/Cura/issues/1785 I was not using the wheel.

Good to know! The search goes on I suppose ;)

Wild guess, but could it have something to do with the back-end matplotlib is using (interactive or non-interactive and some interference)?
I cannot recreate the issue unfortunately. :<

The problem seems to have resolved itself, noone appears to be able to reproduce it anymore so that's arguably a good thing...
If anyone has the problem again let me know and I can reopen. Linked issue: https://github.com/Ultimaker/Cura/issues/1785

Once again https://bugzilla.redhat.com/show_bug.cgi?id=1589520

I'll try to reproduce it again :)

Yet again It only fails on me in Cura:
2018-06-10 21:08:05,827 - ERROR - [Thread-1] UM.Logger.logException [81]: Exception: Exception occurred while loading file /home/churchyard/tmp/test.stl
2018-06-10 21:08:05,828 - ERROR - [Thread-1] UM.Logger.logException [85]: Traceback (most recent call last):
2018-06-10 21:08:05,829 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib64/python3.6/site-packages/stl/stl.py", line 75, in load
2018-06-10 21:08:05,829 - ERROR - [Thread-1] UM.Logger.logException [85]:     fh, header, speedups=speedups)
2018-06-10 21:08:05,829 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib64/python3.6/site-packages/stl/stl.py", line 218, in _load_ascii
2018-06-10 21:08:05,830 - ERROR - [Thread-1] UM.Logger.logException [85]:     return _speedups.ascii_read(fh, header)
2018-06-10 21:08:05,830 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "stl/_speedups.pyx", line 129, in stl._speedups.ascii_read
2018-06-10 21:08:05,830 - ERROR - [Thread-1] UM.Logger.logException [85]: RuntimeError: (0, "Can't read vertex (18:b'vertex 0 2.22045e-15 -10')")
2018-06-10 21:08:05,830 - ERROR - [Thread-1] UM.Logger.logException [85]:
2018-06-10 21:08:05,830 - ERROR - [Thread-1] UM.Logger.logException [85]: During handling of the above exception, another exception occurred:
2018-06-10 21:08:05,830 - ERROR - [Thread-1] UM.Logger.logException [85]:
2018-06-10 21:08:05,830 - ERROR - [Thread-1] UM.Logger.logException [85]: Traceback (most recent call last):
2018-06-10 21:08:05,830 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib/python3.6/site-packages/UM/FileHandler/ReadFileJob.py", line 62, in run
2018-06-10 21:08:05,831 - ERROR - [Thread-1] UM.Logger.logException [85]:     self.setResult(self._handler.readerRead(reader, self._filename))
2018-06-10 21:08:05,831 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib/python3.6/site-packages/UM/Mesh/MeshFileHandler.py", line 27, in readerRead
2018-06-10 21:08:05,831 - ERROR - [Thread-1] UM.Logger.logException [85]:     results = reader.read(file_name)
2018-06-10 21:08:05,831 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 56, in read
2018-06-10 21:08:05,831 - ERROR - [Thread-1] UM.Logger.logException [85]:     self.load_file(file_name, mesh_builder, _use_numpystl = use_numpystl)
2018-06-10 21:08:05,831 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 35, in load_file
2018-06-10 21:08:05,831 - ERROR - [Thread-1] UM.Logger.logException [85]:     self._loadWithNumpySTL(file_name, mesh_builder)
2018-06-10 21:08:05,831 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 87, in _loadWithNumpySTL
2018-06-10 21:08:05,832 - ERROR - [Thread-1] UM.Logger.logException [85]:     for loaded_data in stl.mesh.Mesh.from_multi_file(file_name):
2018-06-10 21:08:05,832 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib64/python3.6/site-packages/stl/stl.py", line 355, in from_multi_file
2018-06-10 21:08:05,832 - ERROR - [Thread-1] UM.Logger.logException [85]:     raw_data = cls.load(fh, mode=mode, speedups=speedups)
2018-06-10 21:08:05,832 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib64/python3.6/site-packages/stl/stl.py", line 91, in load
2018-06-10 21:08:05,833 - ERROR - [Thread-1] UM.Logger.logException [85]:     name, data = cls._load_binary(fh, header, check_size=True)
2018-06-10 21:08:05,833 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib64/python3.6/site-packages/stl/stl.py", line 108, in _load_binary
2018-06-10 21:08:05,833 - ERROR - [Thread-1] UM.Logger.logException [85]:     count, MAX_COUNT)
2018-06-10 21:08:05,833 - ERROR - [Thread-1] UM.Logger.logException [85]: AssertionError: File too large, got 538976266 triangles which exceeds the maximum of 10000000

2018-06-10 15:45:22,552 - DEBUG - [MainThread] CuraEngineBackend.CuraEngineBackend.slice [235]: Build plate 0 has no objects to be sliced, skipping
Gtk-Message: 15:45:22.914: GtkDialog mapped without a transient parent. This is discouraged.
2018-06-10 15:45:25,489 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [277]: file:///usr/lib64/qt5/qml/QtQuick/Controls/TextField.qml:638:5: QML TextInputWithHandles: Binding loop detected for property "text"

It is once again a very long shot, but as the issue is not reproducible to me, or to Miro when not using Cura, I'll ask about this long shot. :)
Is it possible that the Cura application tries to open a dialog, and this dialog sees part of the ASCII file as a user response; effectively consuming data which should be loaded as part of the stl?

The stacktrace does offer me something useful, it seems it's actually trying to load the file as a binary which is useless when using from_multi_file because binary files cannot contain multiple STLs.
By default the MODE is set to ASCII so the actual error is hidden right now. I'll change the code to raise when it's in ASCII mode since it shouldn't try to fall back to binary unless it's in AUTOMATIC mode.

It appears to indicate that it is only getting stuck on the third facet. Might be nice for purposes of narrowing it down to test a few outlier cases:
@hroncok : 1. what happens if you try to read the same file, but with only the first 2 facets? How do the loaded vertex coordinates look for those 2 facets?
2. what happens if you remove the third facet?  I'm actually secretly hoping for it to raise RuntimeError: (0, "Can't read vertex (19:b'vertex 0 2.22045e-15 -10')") if you strictly remove the third facet. :)

what happens if you try to read the same file, but with only the first 2 facets?

with cura? it says it's too small to load. no exception.

what happens if you remove the third facet?

RuntimeError: (0, "Can't read vertex (19:b'vertex 0 2.22045e-15 -10')")

absolutely perfect!
That means the problem is in the scientific notation in the middle vertex coordinate. Alas we didn't get to see what happens with the scientific notation at the 3d coordinate, but we narrowed it down.
if sscanf(line, '%*s %f %f %f\n',
                        facet.v[i], facet.v[i]+1, facet.v[i]+2) != 3:
                    raise RuntimeError(state.recoverable,
                        'Cannot read vertex (%i:%s)' % (state.line_num, line))

is thus not compatible with the consecutive numbers "2.22045e-15 -10" here.
My mastery of C and methods of testing in this direction are so-to-say ... well... limited, but it should be reproducible now.

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    float a, b, c;
    if (sscanf("vertex 0 2.22045e-15 -10", "%*s %f %f %f\n", &a, &b, &c) != 3) {
        printf("oh my\n");
    }
    printf("%f %f %f\n", a, b, c);
}

This seems to work juts fine.

It seems to be compiler dependent as far as I can gather: https://stackoverflow.com/questions/24342982/reading-scientific-notation-in-c
It could also be size related, perhaps %lf will work in more cases but I'll try with %e

@hroncok actually... I don't see the newline in your error message, perhaps that's stripped somehow?

Perhaps, yet in the C example it's not there either.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904919

Thanks for linking the bug report, @hroncok .
It's really odd though: I can load the file from the bug report just fine, and I'm actually the one maintaining the Cura packages in Debian.
I should note though that I'm testing with Cura built locally on my workstation, so perhaps there is something different about the build environment?

Yes, possibly. So far I've not been able to reproduce it either...
That certainly makes it challenging to fix

I'm still getting this on Fedora 29.
Reproducer:

get Fedora 28 or 29 Workstation (or Xfce spin) up and running
sudo dnf install cura python3-numpy-stl
cura
load an ASCII STL

solid OpenSCAD_Model
  facet normal 0 1 -0
    outer loop
      vertex 10 10 -10
      vertex 0 10 2.22045e-15
      vertex 10 10 2.22045e-15
    endloop
  endfacet
  facet normal 0 1 0
    outer loop
      vertex 0 10 2.22045e-15
      vertex 10 10 -10
      vertex 0 10 -10
    endloop
  endfacet
  facet normal 0 -1 -2.22045e-16
    outer loop
      vertex 0 2.22045e-15 -10
      vertex 10 0 0
      vertex 0 0 0
    endloop
  endfacet
  facet normal 0 -1 -2.22045e-16
    outer loop
      vertex 10 0 0
      vertex 0 2.22045e-15 -10
      vertex 10 2.22045e-15 -10
    endloop
  endfacet
  facet normal 0 -2.22045e-16 1
    outer loop
      vertex 0 10 2.22045e-15
      vertex 10 0 0
      vertex 10 10 2.22045e-15
    endloop
  endfacet
  facet normal 0 -2.22045e-16 1
    outer loop
      vertex 10 0 0
      vertex 0 10 2.22045e-15
      vertex 0 0 0
    endloop
  endfacet
  facet normal 1 0 0
    outer loop
      vertex 10 10 2.22045e-15
      vertex 10 2.22045e-15 -10
      vertex 10 10 -10
    endloop
  endfacet
  facet normal 1 0 -0
    outer loop
      vertex 10 2.22045e-15 -10
      vertex 10 10 2.22045e-15
      vertex 10 0 0
    endloop
  endfacet
  facet normal 0 0 -1
    outer loop
      vertex 0 2.22045e-15 -10
      vertex 10 10 -10
      vertex 10 2.22045e-15 -10
    endloop
  endfacet
  facet normal -0 0 -1
    outer loop
      vertex 10 10 -10
      vertex 0 2.22045e-15 -10
      vertex 0 10 -10
    endloop
  endfacet
  facet normal -1 0 0
    outer loop
      vertex 0 2.22045e-15 -10
      vertex 0 10 2.22045e-15
      vertex 0 10 -10
    endloop
  endfacet
  facet normal -1 0 0
    outer loop
      vertex 0 10 2.22045e-15
      vertex 0 2.22045e-15 -10
      vertex 0 0 0
    endloop
  endfacet
endsolid OpenSCAD_Model

Result:
2018-09-28 21:42:24,381 - ERROR - [Thread-1] UM.Logger.logException [81]: Exception: Exception occurred while loading file /home/churchyard/tmp/test.stl
2018-09-28 21:42:24,396 - ERROR - [Thread-1] UM.Logger.logException [85]: Traceback (most recent call last):
2018-09-28 21:42:24,397 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib/python3.7/site-packages/UM/FileHandler/ReadFileJob.py", line 62, in run
2018-09-28 21:42:24,398 - ERROR - [Thread-1] UM.Logger.logException [85]:     self.setResult(self._handler.readerRead(reader, self._filename))
2018-09-28 21:42:24,398 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib/python3.7/site-packages/UM/Mesh/MeshFileHandler.py", line 29, in readerRead
2018-09-28 21:42:24,399 - ERROR - [Thread-1] UM.Logger.logException [85]:     results = reader.read(file_name)
2018-09-28 21:42:24,399 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 66, in read
2018-09-28 21:42:24,399 - ERROR - [Thread-1] UM.Logger.logException [85]:     self.load_file(file_name, mesh_builder, _use_numpystl = use_numpystl)
2018-09-28 21:42:24,399 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 45, in load_file
2018-09-28 21:42:24,400 - ERROR - [Thread-1] UM.Logger.logException [85]:     self._loadWithNumpySTL(file_name, mesh_builder)
2018-09-28 21:42:24,400 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib/uranium/plugins/FileHandlers/STLReader/STLReader.py", line 97, in _loadWithNumpySTL
2018-09-28 21:42:24,400 - ERROR - [Thread-1] UM.Logger.logException [85]:     for loaded_data in stl.mesh.Mesh.from_multi_file(file_name):
2018-09-28 21:42:24,401 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib64/python3.7/site-packages/stl/stl.py", line 364, in from_multi_file
2018-09-28 21:42:24,401 - ERROR - [Thread-1] UM.Logger.logException [85]:     raw_data = cls.load(fh, mode=mode, speedups=speedups)
2018-09-28 21:42:24,401 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib64/python3.7/site-packages/stl/stl.py", line 75, in load
2018-09-28 21:42:24,401 - ERROR - [Thread-1] UM.Logger.logException [85]:     fh, header, speedups=speedups)
2018-09-28 21:42:24,402 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "/usr/lib64/python3.7/site-packages/stl/stl.py", line 224, in _load_ascii
2018-09-28 21:42:24,402 - ERROR - [Thread-1] UM.Logger.logException [85]:     return _speedups.ascii_read(fh, header)
2018-09-28 21:42:24,409 - ERROR - [Thread-1] UM.Logger.logException [85]:   File "stl/_speedups.pyx", line 132, in stl._speedups.ascii_read
2018-09-28 21:42:24,410 - ERROR - [Thread-1] UM.Logger.logException [85]: RuntimeError: (0, "Cannot read vertex (18:b'vertex 0 2.22045e-15 -10')")

I've just remembered something. This might do with locale. My decimal separator is comma, not a dot. I'll try reset LC_NUMERIC to C.utf-8 and reproduce. Qt + sscanf + LC_NUMERIC is problematic and cura uses Qt. https://stackoverflow.com/questions/20555696/why-does-qt-change-behaviour-of-sscanf
(cannot test it immediately unfortunately, reporting from my cell phone, as this idea came up while I couldn't sleep)

from stl import mesh
try:
    from PySide2 import QtWidgets
except ImportError:
    from PyQt5 import QtWidgets

app = QtWidgets.QApplication([])

your_mesh = mesh.Mesh.from_file('tests/stl_ascii/Star.stl', speedups=True)

$ LC_NUMERIC=C.utf-8 python reproducer.py
$ LC_NUMERIC=en_US.utf-8 python reproducer.py
$ LC_NUMERIC=cs_CZ.utf-8 python reproducer.py
Unable to read the file with speedups, retrying

Same goes to cura, setting LC_NUMERIC to C.utf-8 makes the crash go away.

That explains why I've been completely unable to reproduce it, I have my default set to C.utf-8
Excellent work @hroncok! Thank you so much :)

This was not closed, as there was no commit with "Fixes #52". Let's close it after a release?

Yes, that's the plan. I'm working on a release as we speak :)

I've got a few small issues getting the tests to run on my laptop (osx), which effectively results in not being able to deploy a new release. For safety I have a auto-test system in place as a pre-deploy step.

skip the test on mac?

I'm giving it the old college try to get it working. If it turns out to be problematic I'll skip it :)
No worries, I'll push out a release today either way

It turned out to be a weird local error. After starting with a clean project it worked out just fine :)
Thanks again @hroncok

revise max_count


new AndroidLogAdapter() error

AndroidLogAdapter must be public

@Winfred1989 As default Logger was using AndroidLogAdapter. That's why it wasn't public. But with 2.0 LogAdapter functionality is changed. All built-in adapters are public now.


Analyzer Feedback from IntelliJ

Version information

IDEA AI-193.69<IP_ADDRESS>14223
2.7.0
AI-193.69<IP_ADDRESS>14223, JRE 1.8.0_242-release-1644-b01x64 JetBrains s.r.o, OS Windows 10(amd64) v10.0 , screens 1366x768

I think some information is missing here. Do you have more information about the problem?

Please re-open if you see this problem again.


Crashes when booting installed vpk

We're trying to port the game MetaWare High-School (Demo) (here's a link if you wanna check the code out) via the distribution tool, once installed, however, we found that when booting it'd crash right after the developer's logo would show up. (For context, when you boot up the game the developer logo shows up, fades out, then 5 character icons move slowly through the screen before going into the actual main menu shortly after they stop moving. If this makes no sense I can record it off of my pc and upload it here later)
The log file mentions an Out of memory error which will probably not be a surprise since you do say some games will run into memory issues. You also mention tweaking them as necessary though so we were wondering if you could do that?
I'd like to think I'm somewhat decent at Python and Ren'py, but actual vita development is something I can't understand at ALL, so sorry if I didn't provide enough info. Here's the log file that mentions the out of memory thingie.
log.txt

Tried myself and ended up with the same crash. Normally the first thing to look at if you get an out of memory error are the assets. So, I took a quick look at the assets myself and it looks as though there are icons (for character heads) that are 2000x2000 in resolution, which is decently sized. It's either an issue with the allocation for the newlib heap for surfaces (that renpy by itself uses) or the SceLibc heap (that the OpenGL ES 2.0 driver uses). HOPEFULLY a tweaking of those allocations should fix the issue. Until then, I'll keep this open, but if those changes fix it, I'll update it soon afterwards and keep you posted.

Gotcha, thank you so much

Any update on this?


Web worker extension host transiently failed to start

Reloading the page fixed things, and I had not seen this error before:
Failed to load resource: the server responded with a status of 504 ()
webWorkerExtensionHostIframe.html?parentOrigin=https%3A%2F%2Finsiders.vscode.dev&salt=63f71486-a847-45f5-97f8-498e62aaaa41&vscodeWebWorkerExtHostId=6c8b46a0-45f9-430f-8edf-4879e827556a:104

       undefined undefined
worker.onerror @ webWorkerExtensionHostIframe.html?parentOrigin=https%3A%2F%2Finsiders.vscode.dev&salt=63f71486-a847-45f5-97f8-498e62aaaa41&vscodeWebWorkerExtHostId=6c8b46a0-45f9-430f-8edf-4879e827556a:104
error (async)
start @ webWorkerExtensionHostIframe.html?parentOrigin=https%3A%2F%2Finsiders.vscode.dev&salt=63f71486-a847-45f5-97f8-498e62aaaa41&vscodeWebWorkerExtHostId=6c8b46a0-45f9-430f-8edf-4879e827556a:103
(anonymous) @ webWorkerExtensionHostIframe.html?parentOrigin=https%3A%2F%2Finsiders.vscode.dev&salt=63f71486-a847-45f5-97f8-498e62aaaa41&vscodeWebWorkerExtHostId=6c8b46a0-45f9-430f-8edf-4879e827556a:50
await in (anonymous) (async)
(anonymous) @ webWorkerExtensionHostIframe.html?parentOrigin=https%3A%2F%2Finsiders.vscode.dev&salt=63f71486-a847-45f5-97f8-498e62aaaa41&vscodeWebWorkerExtHostId=6c8b46a0-45f9-430f-8edf-4879e827556a:54
(anonymous) @ webWorkerExtensionHostIframe.html?parentOrigin=https%3A%2F%2Finsiders.vscode.dev&salt=63f71486-a847-45f5-97f8-498e62aaaa41&vscodeWebWorkerExtHostId=6c8b46a0-45f9-430f-8edf-4879e827556a:119
log.ts:324   ERR An unknown error occurred. Please consult the log for more details.: undefined
abstractExtensionService.ts:925

       Extension host (LocalWebWorker) terminated unexpectedly. Code: 81, Signal:
_onExtensionHostCrashed @ abstractExtensionService.ts:925

log.ts:318  WARN Ignoring the error while validating workspace folder vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a342c226964223a2231666234653661346532346230663130393466363265633930316464373432633635356637653033227d7d/PKief/vscode-material-icon-theme - No file system provider found for resource 'vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a342c226964223a2231666234653661346532346230663130393466363265633930316464373432633635356637653033227d7d/PKief/vscode-material-icon-theme'
log.ts:312  INFO Initial editor state Object
log.ts:312  INFO Found additional builtin gallery extensions in env Array(6)
log.ts:330 CRITI Extension 'ms-vscode.remote-repositories' wants API proposal 'localization' but that proposal DOES NOT EXIST. Likely, the proposal has been finalized (check 'vscode.d.ts') or was abandoned.
log.ts:312  INFO [vscode.typescript-language-features]: Command `typescript.sortImports` appears multiple times in the `commands` section.
log.ts:312  INFO [vscode.typescript-language-features]: Command `javascript.sortImports` appears multiple times in the `commands` section.
log.ts:312  INFO [vscode.typescript-language-features]: Command `typescript.removeUnusedImports` appears multiple times in the `commands` section.
log.ts:312  INFO [vscode.typescript-language-features]: Command `javascript.removeUnusedImports` appears multiple times in the `commands` section.
v--0qkm3jiogscs4pj6lb1dfgdknsot0afnsols9gg6j7fdtkum17jc.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/base/worker/workerMain.js:1

       Failed to load resource: the server responded with a status of 504 ()
webWorkerExtensionHostIframe.html?parentOrigin=https%3A%2F%2Finsiders.vscode.dev&salt=63f71486-a847-45f5-97f8-498e62aaaa41&vscodeWebWorkerExtHostId=6c8b46a0-45f9-430f-8edf-4879e827556a:104

       undefined undefined
worker.onerror @ webWorkerExtensionHostIframe.html?parentOrigin=https%3A%2F%2Finsiders.vscode.dev&salt=63f71486-a847-45f5-97f8-498e62aaaa41&vscodeWebWorkerExtHostId=6c8b46a0-45f9-430f-8edf-4879e827556a:104
error (async)
start @ webWorkerExtensionHostIframe.html?parentOrigin=https%3A%2F%2Finsiders.vscode.dev&salt=63f71486-a847-45f5-97f8-498e62aaaa41&vscodeWebWorkerExtHostId=6c8b46a0-45f9-430f-8edf-4879e827556a:103
(anonymous) @ webWorkerExtensionHostIframe.html?parentOrigin=https%3A%2F%2Finsiders.vscode.dev&salt=63f71486-a847-45f5-97f8-498e62aaaa41&vscodeWebWorkerExtHostId=6c8b46a0-45f9-430f-8edf-4879e827556a:50
await in (anonymous) (async)
(anonymous) @ webWorkerExtensionHostIframe.html?parentOrigin=https%3A%2F%2Finsiders.vscode.dev&salt=63f71486-a847-45f5-97f8-498e62aaaa41&vscodeWebWorkerExtHostId=6c8b46a0-45f9-430f-8edf-4879e827556a:54
(anonymous) @ webWorkerExtensionHostIframe.html?parentOrigin=https%3A%2F%2Finsiders.vscode.dev&salt=63f71486-a847-45f5-97f8-498e62aaaa41&vscodeWebWorkerExtHostId=6c8b46a0-45f9-430f-8edf-4879e827556a:119
log.ts:324   ERR An unknown error occurred. Please consult the log for more details.: undefined
abstractExtensionService.ts:925

       Extension host (LocalWebWorker) terminated unexpectedly. Code: 81, Signal:
_onExtensionHostCrashed @ abstractExtensionService.ts:925
log.ts:324   ERR Error received from starting extension host (kind: LocalWebWorker)
log.ts:324   ERR Error
log.ts:312  INFO Cannot resolve the path because it cannot be handled ObjectfileUri: fauthority: "github+7b2276223a312c22726566223a7b2274797065223a342c226964223a2231666234653661346532346230663130393466363265633930316464373432633635356637653033227d7d"fragment: ""path: "/PKief/vscode-material-icon-theme/src/commands/activate.ts"query: ""scheme: "vscode-vfs"_formatted: undefined_fsPath: nullfsPath: (...)[[Prototype]]: hopenOnlyIfExists: trueoptions: {selection: {…}}viewColumn: undefined[[Prototype]]: Object
log.ts:324   ERR ENOPRO: No file system provider found for resource 'vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a342c226964223a2231666234653661346532346230663130393466363265633930316464373432633635356637653033227d7d/PKief/vscode-material-icon-theme'
    at l.withProvider (https://main.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/workbench/workbench.web.main.js:606:12920)
    at async l.doWatch (https://main.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/workbench/workbench.web.main.js:606:26687)
    at async https://main.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/workbench/workbench.web.main.js:606:26553
log.ts:324   ERR No file system provider found for resource 'vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a342c226964223a2231666234653661346532346230663130393466363265633930316464373432633635356637653033227d7d/PKief/vscode-material-icon-theme': ENOPRO: No file system provider found for resource 'vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a342c226964223a2231666234653661346532346230663130393466363265633930316464373432633635356637653033227d7d/PKief/vscode-material-icon-theme'
    at l.withProvider (https://main.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/workbench/workbench.web.main.js:606:12920)
    at async l.doResolveFile (https://main.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/workbench/workbench.web.main.js:606:14002)
    at async l.resolve (https://main.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/workbench/workbench.web.main.js:606:13725)
    at async https://main.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/workbench/workbench.web.main.js:2754:49534
    at async Promise.all (index 0)
    at async o.openReadme (https://main.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/workbench/workbench.web.main.js:2754:49443)
    at async o.run (https://main.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/workbench/workbench.web.main.js:2754:48879)
log.ts:324   ERR An unknown error occurred. Please consult the log for more details.: undefined
log.ts:324   ERR No file system provider found for resource 'vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a342c226964223a2231666234653661346532346230663130393466363265633930316464373432633635356637653033227d7d/PKief/vscode-material-icon-theme/.vscode': ENOPRO: No file system provider found for resource 'vscode-vfs://github%2B7b2276223a312c22726566223a7b2274797065223a342c226964223a2231666234653661346532346230663130393466363265633930316464373432633635356637653033227d7d/PKief/vscode-material-icon-theme/.vscode'
    at l.withProvider (https://main.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/workbench/workbench.web.main.js:606:12920)
    at async l.exists (https://main.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/workbench/workbench.web.main.js:606:15518)
    at async https://main.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/workbench/workbench.web.main.js:2354:7619
    at async Promise.all (index 0)
    at async T._initWorkspaceFolderSnippets (https://main.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/workbench/workbench.web.main.js:2354:7784)
log.ts:312  INFO Updating additional builtin extensions cache
2log.ts:324   ERR Timed out waiting for authentication provider to register
log.ts:318  WARN Settings Sync: Accounts are not initialized
log.ts:324   ERR Error while registering log channel vscode-log:/20221026T110338/remoteTunnel.log Timed out while waiting for file to be created
log.ts:324   ERR Error while registering log channel file:///20221026T110338/ptyhost.log Timed out while waiting for file to be created
[Violation] 'setTimeout' handler took 52ms

@joyceerhl What is the root cause here of the failure here? Is it Failed to load resource: the server responded with a status of 504?

That is what I am guessing, since that looks like the webWorkerExtensionHostIframe.html failed to load as a result, but I'm not sure since I didn't have a network capture going at the time that I encountered this, and it did not repro on a reload

We use code 81 for an UnexpectedError. Looking at the stack:
webWorkerExtensionHostIframe.html?parentOrigin=https%3A%2F%2Finsiders.vscode.dev&salt=63f71486-a847-45f5-97f8-498e62aaaa41&vscodeWebWorkerExtHostId=6c8b46a0-45f9-430f-8edf-4879e827556a:104

it seems the error is printed at webWorkerExtensionHostIframe.html#L104. That means we try to create a Worker and it emits an error undefined. Looking above, I think the following request fails:
v--0qkm3jiogscs4pj6lb1dfgdknsot0afnsols9gg6j7fdtkum17jc.vscode-cdn.net/insider/c3eebaead9d3bf1cb961b91fca1b8af31990d328/out/vs/base/worker/workerMain.js:1
       Failed to load resource: the server responded with a status of 504 ()

504 is a Gateway Timeout. Maybe we can try tracking this down on our server side infrastructure.
cc @lszomoru

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


[BUG] estimate_fee_sync always fails with TRANSACTION_FAILED

Python version
3.9.12
Expected Behavior
estimate_fee_sync should successfully complete
Current Behavior
It returns the following error:
{"code": "StarknetErrorCode.TRANSACTION_FAILED", "message": "Error at pc=0:392:\nUnknown value for memory cell at address 12:0.\nCairo traceback (most recent call last):\nUnknown location (pc=0:534)\nUnknown location (pc=0:468)"}

Possible Solution

Steps to Reproduce
(nonce,) = keeper_contract.functions["get_nonce"].call_sync()
task_address_felt = int(task["address"], 16)
args, signature = get_account_message_args_sig(keeper_address, registry, "executeTask", [task_address_felt], nonce, key)
unsigned_invocation = keeper_contract.functions["execute"].prepare(*args)

# This is where the error occurs
estimation = unsigned_invocation.estimate_fee_sync()

# This normally runs perfectly fine if I don't do gas estimation for all these transactions that are failing with `estimate_fee`
invocation = unsigned_invocation.invoke_sync(signature=signature, max_fee=0)

FYI - I'm using an older version of an account contract to issue transactions but I'm assuming that this should not impact estimate fee as the other starknet.py apis are working fine?
Context (Environment)
I've been using the excellent starknet.py library to power Yagi Keepers (http://www.yagi.fi/automation).
I'm trying to upgrade keepers now to use fees on testnet before they are officially mandated.
Detailed Description

Possible Implementation

I've tried to replicate using both testnet and devnet using a simple balance contract I've deployed through cairo-lang CLI (I don't have the access to a contract you're using but I don't think that matters), but unfortunately/fortunately it works on my side. Intentionally changing parts of the prepared invoke function caused multiple errors but no like the one you provided.
Parhaps older account contract actually is an issue? In starknet.py 0.8.0 we've changed the way we're signing transactions to reflect changes made in the cairo-lang library itself. The way estimate_fee works it first has to construct the same InvokeFunction as invoke creates, but with signature=None and then passes it to estimate fee feeder gateway endpoint.
Or this may be an issue with contract/calldata/something but it's hard for me to speculate.

Thanks so much @cptartur for the attempts to repro, I think I see what you mean - let me redeploy the latest account contract and I'll report back the findings!

Unfortunately this didn't fix it, can I add you to my repo to have a look? Promise it's not super complex/nested at all :)

Hey, I'd prefer if we kept this discussion here. Have you tried making the same calls are you trying to do in code through starknet CLI? Are they successful?
The error you've posted is from starknet, just forwared through starknet.py. There's of course a chance we have some bug in  starknet.py code that's causing this but we'd need more details to verify it though.
Perhaps the ABI you're using to create a Contract instance isn't correct and that's why you don't get any errors in code but do on starknet?

@Pet3ris can you create a full repro showing your issue detached from your codebase? Ideally it would include deploying a simple contract before interacting with it.

Hey @cptartur @Solpatium - thanks a lot for your guidance, I've done the above and created a separate repository to show how I'm using starknet.py.
The code and readme is available below:
https://github.com/Pet3ris/gas-estimation-example
FYI - I'm running gas estimation on a transaction that succeeds as an invoke with the same arguments, so I think the issue is not in the ABI but rather there is some behavioral difference between estimation and invocation.

@Pet3ris thank you for preparing a repro, it allowed us to find the issue - PreparedFunctionCall had no way of passing the signature. Usually AccountClient is used with Contract and it signs the tx automatically, but when using a bare Client that doesn't happen. This is why we couldn't reproduce it. We added a signature parameter to estimate_fee.
Fix: https://github.com/software-mansion/starknet.py/pull/217
It was already included in the latest release: https://github.com/software-mansion/starknet.py/releases/tag/0.3.4-alpha. Make sure you add your signature when calling estimate_fee.
Apart from that, I suggest using AccountClient instead of bare Client when sending txs. It hides signing and offers a higher-level api :)

Legends @Solpatium !

@Solpatium - I updated starknet.py to latest version but it's unfortunately still failing with the same error. Is there any other change I need to make in terms of how I'm using Client for this to work? I also tried to upgrade the openzeppelin account contract to latest and compiling it with 0.9.0 with no luck.

Are you providing the same signature to Contract.estimate_fee() as you'd be using in Contract.invoke()?
It's
# create my_signature signature somehow
estimate = my_invoke.estimate_fee_sync(signature=my_signature)

That fixed it thanks (and makes sense)!


Terms

I'll handle definitions and glossary at separate branch so it's easier to review.
https://github.com/katalysteducation/adaptarr-front/pull/34

Solved as inlines in #24


v2.1.1 - Fix command-line parameter and lower-case seq issues

Fix command-line parameter parsing issue #61
Fix lower-case sequence issue
version bump from 2.1.0 to 2.1.1

@glabbe @kbessonov1984 Updated in PyPI and should be updated in Bioconda soon

@peterk87. Hi Peter, is the bioconda update automatic or your would open PR on their repository. The wrapper code will be also updated or we need to create PR too? Thank you for clarifying on how to go forward.

Hi @kbessonov1984
The Bioconda recipe needs to be manually updated with the version and sha256sum. Unfortunately, Bioconda doesn't yet have bots that automatically update recipes like Conda-Forge does.
Yes, the wrapper code would need to be updated (version bump) as well after the latest version of biohansel makes it into Bioconda.


How to set up incremental key?

It is not actually an issue. But I don't know where to ask a question like this.  In javascript (indexedDB), one can use an objectstore.app() function to store value into a key, which is incremental automatically. like
key           value
0               {object1}
1               {object2}
The setitem() function in localForage could not accomplish this. Is there a simple function I can use to  make that happen, or I have to use service to setup a logic?
Thanks.

You will have to make it yourself, sorry :)

Can I use this to fetch the number of keys in the storage?
   $localForage.length().then(function(data){
            var keylength = data;
       });

I was trying to get the length of the db and use the key = length +1 to setup the new key for the next data entry. I manage to make it work by using the following codes. It seems the setItem function have to live within the length() function to make it work.
// the way that won work
$scope.add = function() {
       $localForage.length().then(function(data){
           var keylength = data;
       });
      $localForage.setItem(service.keyvalue(keylength), $scope.movie).then(function() {
               $location.path('/tab/dash');       // once a new data is stored, return to dash
		});
};

// the way that works
$scope.add = function() {
       $localForage.length().then(function(keylength){
           $localForage.setItem(service.keyvalue(keylength), $scope.movie).then(function() {
               $location.path('/tab/dash');       // once a new data is stored, return to dash
		});
       });
};
//in the factory

.factory('service', function(){
       return {
         keyvalue: function (keylength){
         var k= keylength+1;
         return k;
         }
    }
});

Yes if you use an async database such as IndexedDB or WebSQL the length function will be async too anyway, I'm glad that you figured out how to do this.

But when you delete a item, you will get problem.


RMC thruster needs to be added

version of the thruster which doesnt actually behave as a thruster and drops into RMC metal instead of an upstream machine frame
add to migrations
all upstream things that drop upstream materials should be removed

for the LV 624 crashed shuttle thrusters


Demo site is dead

Demo site is not working on Oct 25 07:21PM New York time.

There was a DNS issue.
Thanks for reporting!


[AutoRelease] t2-rdbms-2024-04-18-24756(can only be merged by SDK owner)

https://github.com/Azure/sdk-release-request/issues/5058
Live test success
https://dev.azure.com/azure-sdk/internal/_build?definitionId=1020

issue link:https://github.com/Azure/sdk-release-request/issues/5058


Checking existence of archive and GWS 'latest' links

Moved test_single_version_already_correctly_symlinked to a more suitable location in the test regime.
Added the following tests to check for the existence of 'latest' links in the archive and gws:

test_single_version_gws_correctly_symlinked_no_arc_latest
test_single_version_gws_symlinked_no_gws_latest_but_arc_latest

Symlark was modified to print the archive latest link path and check the gws latest link exists or show an error message.
Assertions in test_old_gws_version_needs_deleting_and_symlink were modified to include the additional messages.
This resolves Issue #6.

@knappett: I pulled your branch to my local version - and all tests passed! Excellent.