[BUG] Can't pass felt252 array param

What happened
    data = [11,22]
    felt_serializer = FeltSerializer()
    array_serializer = ArraySerializer(felt_serializer)
    res = array_serializer.serialize(data)

    call = Call(
        to_addr=address, selector=get_selector_from_name("ins"), calldata=res
    )
    resp = await account.execute(calls=call, max_fee=int(1e16))

    await account.client.wait_for_tx(resp.transaction_hash)

The contract method ins param is core::array::Array::core::felt252
ValueError: Shortstring cannot be longer than 31 characters, got: 66.
Stack trace
Traceback (most recent call last):
File "/Volumes/Apple_SSD/starknet_new/sn.py", line 106, in
asyncio.run(test())
File "/Users/voyager-1/opt/anaconda3/lib/python3.9/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
File "/Users/voyager-1/opt/anaconda3/lib/python3.9/asyncio/base_events.py", line 647, in run_until_complete
return future.result()
File "/Volumes/Apple_SSD/starknet_new/sn.py", line 99, in test
resp = await account.execute(calls=call, max_fee=int(1e16))
File "/Users/voyager-1/opt/anaconda3/lib/python3.9/site-packages/starknet_py/net/account/account.py", line 409, in execute
execute_transaction = await self.sign_invoke_transaction(
File "/Users/voyager-1/opt/anaconda3/lib/python3.9/site-packages/starknet_py/net/account/account.py", line 277, in sign_invoke_transaction
execute_tx = await self._prepare_invoke(
File "/Users/voyager-1/opt/anaconda3/lib/python3.9/site-packages/starknet_py/net/account/account.py", line 180, in _prepare_invoke
wrapped_calldata = _execute_payload_serializer.serialize(
File "/Users/voyager-1/opt/anaconda3/lib/python3.9/site-packages/starknet_py/serialization/data_serializers/cairo_data_serializer.py", line 44, in serialize
return self.remove_units_from_serialized_data(serialized_data)
File "/Users/voyager-1/opt/anaconda3/lib/python3.9/contextlib.py", line 137, in exit
self.gen.throw(typ, value, traceback)
File "/Users/voyager-1/opt/anaconda3/lib/python3.9/site-packages/starknet_py/serialization/_context.py", line 104, in create
yield context
File "/Users/voyager-1/opt/anaconda3/lib/python3.9/contextlib.py", line 137, in exit
self.gen.throw(typ, value, traceback)
File "/Users/voyager-1/opt/anaconda3/lib/python3.9/site-packages/starknet_py/serialization/_context.py", line 81, in _wrap_errors
raise InvalidValueException(f"{self._error_prefix}: {err}") from err
starknet_py.serialization.errors.InvalidValueException: Error at path 'call_array.[0].to': Shortstring cannot be longer than 31 characters, got: 66.
Steps to reproduce
when send the transaction
SDK Version
lastest
Python version
3.9
What operating system are you using?
Mac
Is there an existing issue for this?

[ ] I have searched the existing issues and verified no issue exits for this problem.

@HorseXInsectCoder
Since there hasn't been a response for some time, I will be closing this issue. If you're still encountering this problem in the latest version, please don't hesitate to reopen it with updated details.


Website builds are failing in travis

https://travis-ci.org/flutter/website/builds/219182736
Fails analyzing an include:
Run flutter packages get on _includes/_code/stack
Running 'flutter packages get' in stack...               -\|/ 1.7s
Run flutter analyze on _includes/_code/stack
Analyzing /home/travis/build/flutter/website/_includes/_code/stack/main.dart...
    error • Invalid constant value at _includes/_code/stack/main.dart:1:1 • invalid_constant
1 error found.
(Ran in 5.4s)

Also fails when run locally.

My theory was that this was caused by https://github.com/flutter/flutter/pull/9151, but looks like that landed several days ago, and this just started failing today:
https://travis-ci.org/flutter/website/builds

No, wait, we just merged 16 hours ago, so this is likely related.

I don't know how to read this error from the analyzer. Line 1, column 1? That's a comment in https://github.com/flutter/website/blob/master/_includes/_code/stack/main.dart

The location of the error is clearly wrong, and a bug that we need to track down. Beyond that, please see https://github.com/dart-lang/sdk/issues/29281 for a discussion.

Thanks. Will follow up on https://github.com/dart-lang/sdk/issues/29281

Temporarily disabled the failing analysis in https://github.com/flutter/website/pull/496; we should remember to revert that PR once the root issue has been fixed.


More plot recipes

Will check once this is ready to get merged, right now this is still just a first draft.


gcc needed in OS X to compile examples

I cloned the current cpputest.
In OS X 10.11.4, I can only successfully compile (and run) the examples by using gcc (v5.3, installed via MacPorts).
When using clang, the examples fail to compile like so:
...
compiling FEDemoTest.cpp
AllTests/FEDemoTest.cpp:81:21: error: implicit conversion increases floating-point precision: 'float' to 'double'
      [-Werror,-Wdouble-promotion]
    DOUBLES_EQUAL(f / 3.0f, 3.333f, 0.001f);
    ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~

clang --version reports
Apple LLVM version 7.3.0 (clang-703.0.29)
Target: x86_64-apple-darwin15.4.0

Is this related to #864 ?

No, I don't think so.

I think I actually have a local fix for this one...

(double)(f / 3.0f) should fix it, right? Didn't have a chance to test that, though.

Fixed this one, I think.

The examples are working OK for me using v3.8-75-gb801207 of CppUTest, Apple LLVM version 7.3.0 (clang-703.0.31) on Target: x86_64-apple-darwin15.0.0
I ran:
$ make -f ./Makefile_using_MakefileWorker clean examples
and got as a result
...
OK (454 tests, 452 ran, 1415 checks, 2 ignored, 0 filtered out, 149 ms)
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C examples  all CPPUTEST_USE_STD_CPP_LIB=Y CPPUTEST_USE_MEM_LEAK_DETECTION=Y
Linking CppUTestExamples_tests
Running CppUTestExamples_tests
...................!!!!.......................`
OK (46 tests, 42 ran, 272 checks, 4 ignored, 0 filtered out, 3 ms)


Delete finished job in show action

Currently, the async_request_jobs table gets bigger and bigger with each async request. Since the client stops asking for a job once it is finished, it would be nice to have an automatic depuration in the table.
Another issue with the current behavior is that when you queue a job with a sensible parameter (like a password) it remains accessible for anyone that query the table.
I believe that this whole issue could be solved by performing a job destroy inside JobsController#show --> render_finished_job(job)

https://github.com/Wolox/async-requests/pull/20


Dockerizing Ord wallet

Dockerizing Ord wallet
It could be useful for developers to be able to set up the ord wallet using a containerization approach. This would lower the barrier for those in a windows-based environment, but also if it was formally supported by the repo it could be published to places like docker.io where people could use it.
Realisitcally you would still need some interface to the docker container, if thats done through a simple http API and a localhost web interface or something like that. That would lower the barrier for entry for many.

we use this for our internal ord server, maybe you can edit it to fit for windows-based environment?
EXPOSE 8080
RUN #apk add tar --no-cache

WORKDIR /ordinals
ADD https://github.com/casey/ord/releases/download/0.5.0/ord-0.5.0-x86_64-unknown-linux-gnu.tar.gz /ordinals/ord.tar.gz
RUN tar -zxvf ord.tar.gz

RUN chmod +x /ordinals/ord
RUN ls -la
ENV RUST_LOG=debug

ENTRYPOINT ["/ordinals/ord", "--data-dir", "/ordinals/index-data", "--cookie-file", ".cookie", "server", "--http-port", "8080"]

Adding another repository to the list that embed ord+bitcoin core(soon) and btcd(current) https://github.com/Magicking/ord-docker


Refresh Channel (and other) contents

I actually noticed this while using https://github.com/chrisgillis/slackwolf which has slack-client as a dependency.  It'd be nice if there was a way to 'refresh' the data for an object; in this particular case I'd like to re-get the list of users in a channel, but I imagine being able to refresh most things would be nice.  As it is now I can only force a disconnect and then re-connect, which repopulates all the objects with new data.
I see the actual API calls to fetch the data required are in ApiClient, but they're hidden away behind implementations of Channel and whatnot.

This will probably be fixed with #35.


feat: framework for SaaS

This commit adds a framework for logging and exiting in a way that conforms to the SaaS requirement. Logging in particular could be done in either the JSON mode or the text mode.
The main entry point to the framework is the with-framework function.
This commit does not yet switch Picus to use the framework. That will be done in a separate commit.
See framework-test.rkt for tests of the framework.

Example output from the actual tool (not included in this PR)
$ racket ./picus.rkt<EMAIL_ADDRESS>2023-10-02T20:26:18 [INFO]: [result] the circuit is underconstrained
2023-10-02T20:26:18 [INFO]: [result] counterexample:
2023-10-02T20:26:18 [INFO]: [result]  inputs:
2023-10-02T20:26:18 [INFO]: [result]    m1.main.inp: 0
2023-10-02T20:26:18 [INFO]: [result]  first possible outputs:
2023-10-02T20:26:18 [INFO]: [result]    m1.main.out[0]: 1
2023-10-02T20:26:18 [INFO]: [result]    m1.main.out[1]: 0
2023-10-02T20:26:18 [INFO]: [result]    m1.main.success: 1
2023-10-02T20:26:18 [INFO]: [result]  second possible outputs:
2023-10-02T20:26:18 [INFO]: [result]    m2.main.out[0]: 0
2023-10-02T20:26:18 [INFO]: [result]    m2.main.out[1]: 0
2023-10-02T20:26:18 [INFO]: [result]    m2.main.success: 0
2023-10-02T20:26:18 [INFO]: Exiting Picus with the code 0


AVT-914 [Spectron][Windows] Add test "Keep size and position of the windows in previous session"

Description

Add test "Keep size and position of the windows in previous session" AVT-914
Update a test in AVT-768

Run
Please refer attachment for more details
Jest Test Report.zip

Updated based on @vantruongt2 's feedback

@thaisym1912 Please rebase this PR.

@VishwasShashidhar Completed rebase

@VishwasShashidhar  Completed rebase and rerun. Added result again.
Jest Test Report.zip

@KiranNiranjan

2 tests in alwaysOnTop.spectron.js are fixed in PR: https://github.com/symphonyoss/SymphonyElectron/pull/443
"Generating & Sharing Logs" and "Bring to front" got failed on master as well. Will create tickets and fix on other branchese,
"pop outs" test passed on Run 2.


Do you plan to support rpc?

Do you plan to support rpc?
route:
id: rpc_call
rpc: xxx
predicates:
- Path=/test/**

There is an open issue for grpc. Anything else will be on a case by case basis


group_checkboxes removed?

In previous versions of theres a param called group_checkboxes, in the docs says "Allow entire groups to be toggled on or off with a global checkbox. Defaults to true."
The code for group_checkboxes is commented in Catalog.js and so, its not working at the moment, why it was removed from the present releases?

Were group_checkboxes previously working?  If so, how is the config the same or different?
If you're referring to this specific code, it has been commented since [2011] (https://trac.osgeo.org/geomoose/changeset/476/).
How to enable group_checkboxes might be better discussed on the email list.  Does mapbook.xml have something like:
<configuration> ... 		<param name="group_checkboxes">true</param> ... </configuration> ?

Yes, i'm referring to that code.
I add group_checkboxes to mapbook.xml but has no effect on the app.
I found a old questions about that in the mailing lists but is not aswered yet:
http://osgeo-org.1560.x6.nabble.com/Geomoose-users-group-checkbox-and-legend-icon-td5181092.html

Group checkboxes were problematic.  Specifically when someone was trying to turn on or off individual layers in the group, the checkbox could be found to be checked when not all the layers were checked, or exactly the opposite.  So the state could get very odd and show bugs.  Past that, it was quite a few years ago since we had support for the feature, so I don't remember all of the reasons for it.

This is an option to remove group_checkboxes from code, demo, and docs.  Can you review these?

Wow, this is like the best Issue ever.  Someone reports bug, someone fixes bug with pull requests.  YAY!


add dataset from workflow

 Create Dataset from Workflow

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

101 of 122 (82.79%)  changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.03%) to 83.859%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

operators/src/source/gdal_source.rs
7
8
87.5%

services/src/pro/server.rs
0
1
0.0%

services/src/handlers/workflows.rs
79
98
80.61%

Totals

Change from base Build<PHONE_NUMBER>:
0.03%

Covered Lines:
22517

Relevant Lines:
26851

💛  - Coveralls

There are lots of open TODOs and this is only a first step towards finishing the functionality.
Could you create a story that covers the things that you know by now?
Including TODOs and things that you didn't tackle, yet.

I added the TODO regarding indexing the created tiff to the wishlist , but I am not sure we actually need that right now. I didn't add the other ones because we agreed not to collect tasks that we wouldn't do in the near future.


[bug] area 9 receptor ebrains dataset fetched when hoc2 right is defined as roi

siibra version: 0.3a5
min repro:
import siibra
from siibra.core import Atlas, Parcellation

atlas:Atlas = siibra.atlases['human']
parc:Parcellation = atlas.parcellations['2 9']
regions = parc.find_regions('hoc2 right')
hoc2_right = regions[0]
print(hoc2_right)
features = siibra.get_features(hoc2_right, 'ebrains')
print([f.name for f in features])

expected return
[]

actual return
['Density measurements of different receptors for Area 9 [human, v1.0]']

additional information:
possibly also the case for Area hOc3d (Cuneus) left instead of hoc2 right

This problem was caused by a recent update which removed words included in the parcellation name from the region specifciations for region name matching. This  mechanism also removed the "9" from the are name because it was a 'word' in Julich-Brain 2 9. With  95d83a6, only alphanumeric words with more than 2 characters are being removed, which fixes the problem.


topbar hints

In message view topbar looks like is not user-friendly to much....
There 4 buttons in right top corner - just icons, w/o any title or suggest about function..
I see this like:
"some back button" (what really is REPLY)
"right arrow" probably Fwd function
"trash bin - delete" (this ok)
And ??? mail?? Compose new mail maybe? But no :) "Back to folder"
Please, add hints or just "title" attributes

There to mandatory buttons:


Remove and Blend Names Topic

This is a...

[x] Feature Request
[ ] Bug Report

Delete this topic. Blend the content into another topic.
Names

@steveperry-53, I'll work on this issue.

/lifecycle frozen

/language en

/priority backlog

I'm fairly happy with https://kubernetes.io/docs/concepts/overview/working-with-objects/names/ as it stands. Maybe it would have a better home inside https://kubernetes.io/docs/reference/ ?

Superseded by issue #26822.
/close


Markdown inline code format clean up for file names from P to Z

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Rockford Wei seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.


Better embeds tbh

Here we are

You also don't change the original text much, and when you do, you must keep the integrity of the original message.

tbh feel free to edit

I will only commit this when the embeds are good for me to use, I'll have Shadi edit it later lol.
@SilentSerenityy

I am sorry about this, but requiring my code to be pep8 is no bueno. I will not merge this pr.
However, I will manually change some changes I do like until my own release.

This is all.


Revert "Add 15 minute cache headers to all static assets in /public"

Reverts DFE-Digital/get-into-teaching-app#689

Opened as a failsafe, not required


It would be nice to disable automatically connect when the Socket Object is initialized

Hi,
I think it is a good idea ti allow developer to choose when to trigger the socket connection. Sometimes I just need to initialize the socket object first, write all the beautiful reactive codes then start the connection. Like this
override func react() {
        let socket = RxWebSocket(url: "ws://lcocalhost:1337")

        let connect = socket.rx.connect
            .do(onNext: { _ in
                self.socket.write(string: self.varUsername.value ?? "Unknown user")
                self.varIsConnected.value = true
            })
            .map { true }

        let disconnect = socket.rx.disconnect
            .do(onNext: { error in
                self.varIsConnected.value = false
            })
            .map { _ in false}

        Observable.of(connect,disconnect).merge() ~> varIsConnected => disposeBag
    }

Then somewhere in the app, I would call
 lazy var connectAction: Action<Void?, Void> = {
        return Action() { _ in
            if self.socket.isConnected {
                self.socket.disconnect()
            } else {
                self.socket.connect()
            }
            return .just(())
        }
    }()

But this cannot be achieved since the connection started by the time this happens
       let socket = RxWebSocket(url: "ws://lcocalhost:1337")

@hoanglu14 this may be interesting indeed, but I'm a bit hesitant of changing the current behavior, perhaps we could have a shouldAutoconnect: Bool argument on the initializer and set it to true by default. This way, you could send false and connect manually. What do you think about that?
Also, how do you feel about writing a PR for this?

[Inactive thread]


ros::ServiceClient client = node.serviceClient

do not need ros::ServiceClient client ？

Hi, can you please describe the issue better and point to the code that is causing your issue? I cannot really understand what you are asking based on the information you are providing.
Thanks.


BBP staging gives "503 Service Unavailable"

Hi,
Subj. Could you please have a look. Thanks.

Is back up


CashuWallet: update receive function

Review pls @gandlafbtc

after this is merged i will work on checking for changed keys before creating proofs


Temperature sensor not working in Apple homekit automation

Hi,
Is it possible to enable te temprature sensor in homekit automation?
The default temprature sensor seems not reconised as an automation sensor.
I also tested the motion sensor and that works fine.
Thx

I think Home app doesn’t support numerical value based automation. Please try use third party app like Eve or Hesperus to create automation.
Best Wishes,
Tian

On Jan 8, 2017, at 9:07 AM, Kevin Beckers<EMAIL_ADDRESS>wrote:
Hi,
Is it possible to enable te temprature sensor in homekit automation?
The default temprature sensor seems not reconised as an automation sensor.
I also tested the motion sensor and that works fine.
Thx
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/KhaosT/HAP-NodeJS/issues/375, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpU4NqoIyHGqVJR9uy0RV-AZHuW9bfcks5rQDbBgaJpZM4Ldkt0.

Thank you for the quick response.
You are right. Eve works fine!

The temperature sensor is greyed out in the Home app. Since it's inactive it doesn't show up in automation.  I've set the StatusActive characteristic, and in the Home app under Details for the temperature sensor a line for Status Active Yes appears but the icon is stilled greyed.   The Sensor doesn't have a Active characteristic.   It seems like it should, or Status Active should make it active.  Hue provides an Enabled characteristic, but that isn't present either.  What am I missing?

Today, i expect the same problem with my sonoff TH16.  I use MQTT and a good pluggin.  I see the temperature in Homekit but i can't use this information to do an automation.  Does it an apple problem (temperature sensor not supported with HomeKit) or i have misconfigured somethings in my iPhone?
Thanks for your suggest!
Richard


settle on a forwards-compatible exit format

[NEW] What is this issue for
So far we have anticipated WithdrawHelpers (they use callTo and data) and nitro guarantees (they use a magic value for callTo and also use data).
We would like a format that does not treat any single use of the data field in a special way, and can cope with multiple future usages of that field that we don't even know about yet (but certainly the various virtual funding optimizations to nitro that we are considering).
We can use some of the following tricks:

magic values
custom coders (other than abi.encode -- e.g. abi.encodePacked or a custom bytes manipulator)
self describing formats
versioned coders.

Questions:

do we need two fields, or can we use one field? Could the "data type" be indicated by the first couple of bytes of data itself?
how will we deal with using the data field in multiple interesting ways at the same time?

[Defined] How will we solve it
A clear and concise description of what you want to happen, which can include implementation suggestions
Include an estimate (~ 1point = 1day)
[Development]
[] This ticket has clearly outlined the expected outcome, and I can complete this ticket with no additional refinement
Additional context Add any other context or screenshots about the feature request here: notion doc, github discussion or ticket

Could the "data type" be indicated by the first couple of bytes of data itself?

What is the argument for using a "data type" at all?

If the data (now known as metadata) field is to be used in multiple distinct ways, there needs to be some way to declare which way in the format itself. For example, sometimes the metadata will encode a guarantee. Other times, it might encode the address and calldata for a WithdrawHelper. It seems to me that a  "data type" is the easiest way to declare which decoder to use on the metadata. This is essentially making the metadata a discriminated union type, with the "data type" being the discriminant. This is a pattern we already use in our current outcome format:
https://github.com/statechannels/statechannels/blob/5ced1f55e25947e2b10576beb61f683a12e599d2/packages/nitro-protocol/contracts/Outcome.sol#L23-L24
Whether that data type is actually a separate field on the exit format is a secondary question (it can be absorbed into the metadata field).
The only alternative I can think of is to have all of the anticipated uses of metadata "present" and decode-able in every outcome / exit. This is making metadata a product or intersection type. A downside is that this bloats the format with a lot of unused data (which grows as we add more and more uses for metadata). We would also need to have a way of switching the fields "off" -- say with a default or null value (like we currently do with the zero address). It's not clear to me that this will always be possible / straightforward.  Another thing to consider with this approach is forwards-compatibility. It's less clear that data encoded today will be decode correctly tomorrow when a newer decoder is expecting metadata to represent something different.

Closing via #42


feat：Use string array config include pattern for Spring API doc.

Use string array config include pattern for Spring API doc.

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

@PC-Chiu can you sign the CLA?

@PC-Chiu can you sign the CLA?

Yes, I have. I used my company's email address as the author, so there was no automatic link to CLA. I have added the company's email address to solve this problem. So sorry for the mistake.

Thanks @PC-Chiu for the contribution


Bugfix/inconsistent from bigint in curves

Fixed an inconsistency bug, where converting from BigInt to a Scalar and back again resulted in a different number - namely, the number modulo the curve order, which led to generating sign-verify keypairs on the curves from a given secret that were incompatible with other crypto libs such as NaCl.
The issue arose when generating an EdDSA keypair from a user-chosen seed.
However, the same issue was found in the Ristretto curve also and fixed.
A  new test for consistency on all curves has been added and currently passes.
The test uses a hardcoded value such that it is larger than the curve modulo.

Also verified with the underlying implementations of scalar multiplication of both curves that this should not hinder performance.

That is a very valid point.
I looked over NaCl's implementation for reference (where there is no scalar struct at all) and I agree that the situation here is different.
At this point it might be best to close this PR completely and modify code that uses curv s.t. it only uses the ECScalar struct for computing arithmetic on a curve.
In the documentation of ECScalar it is noted that a modulo operation is performed (as pointed out by @survived off-thread), so therefore any user of curv should be able to use ECScalar properly.
Essentially, the bug referenced above in EdDSA is a misuse of curv.


[Feature] Add Preview and Upload Options for Job Application Files

Is your feature request related to a problem? Please describe.
When users navigate to the job application section, there is no option to preview or directly upload a file, which can negatively impact user interaction.
Describe the solution you'd like

I will add a catalog box that provides two options: preview before uploading or directly upload the file.

Additional context

I have implemented a similar feature before:

Hi @Yashgabani845 , please assign this issue to me so I can implement it right away!


How to get value and inner text of options in a select?

I need to get a list of value and inner of each item of a select.
How could I do this via scrape-it?

Can you add an example?

Closing due to no reply. Maybe duplicate of #45.

This should do it
$('div.classname').first().contents().filter(function() {
    return this.type === 'text';
}).text();


error finding auth provider for type: basic

2023-06-09 07:08:52.253 ERR ../reva/internal/grpc/services/gateway/authprovider.go:49 > error getting auth provider client error="error: not found: gateway: error finding auth provider for type: basic" pid=239782 pkg=rgrpc traceid=495bf726b9525728566b383739f93c98

When trying to log in to reva-cli on mesh.pondersource.org
This is not happening on mesh.pondersource.com so there must be something wrong in the toml files!

I reset the configs to:

https://raw.githubusercontent.com/cs3org/ocm-test-suite/main/servers/revad/sciencemesh1.toml
https://raw.githubusercontent.com/cs3org/ocm-test-suite/main/servers/revad/sciencemesh2.toml
https://raw.githubusercontent.com/cs3org/ocm-test-suite/main/servers/revad/sciencemesh3.toml

And it works now


self signed certificate in certificate chain

Issue Summary
Send grid Mail send response {"statusCode":500,"body":"{"message":"self signed certificate in certificate chain","name":"Error","stack":"Error: self signed certificate in certificate chain\n    at TLSSocket. (_tls_wrap.js:1088:38)\n    at emitNone (events.js:86:13)\n    at TLSSocket.emit (events.js:188:7)\n    at TLSSocket._finishInit (_tls_wrap.js:610:8)\n    at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:440:38)"}","headers":{}}

This seems to be a JS error. You should file your issue over at sendgrid js


[stable/jenkins] add backup cronjob

Signed-off-by: Maor<EMAIL_ADDRESS>What this PR does / why we need it:
Adds a backup CronJob for Jenkins
Which issue this PR fixes

fixes #9987

Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/assign @viglesiasce
Thanks!


Add support for specifying glsl versions in defun-g

Currently is asserts the context is zero, but we really need this.

And done


1069 show message when no metadata is present

I added some messages here if there is no extractor or user metadata, for datasets or files.
@lmarini I used the text you had supplied in the issue for the user metadata, and came up with something else for machine metadata. I think the text in those spaces can be better, but I wanted this to be a draft now so others can weigh in on the messages.

It always says 'no user metadata provided for dataset', even for files.

I changed 'dataset' to 'resource' so that both messages just say 'resource'.


Google Drive storage provider

🚀 🚀 Pull Request
Checklist:

[x]  My code follows the style guidelines of this project and the Contributing document
[x]  I have commented my code, particularly in hard-to-understand areas
[x]  I have kept the coverage-rate up
[x]  I have performed a self-review of my own code and resolved any problems
[x]  I have checked to ensure there aren't any other open Pull Requests for the same change
[x]  I have described and made corresponding changes to the relevant documentation
[x]  New and existing unit tests pass locally with my changes

Changes
Added google drive storage provider.
Closes #1162.

There seems to be a limit on requests per second on google drive api (which the user can increase by upgrading) which makes rapid multiple requests (like uploading many small files) painfully slow. Uploading the same stuff in one file is much faster.

Can we somewhere have all the limitations documented? Preferably in a code.

Need to update workflow by adding --gdrive flag, client_secrets.json and change google drive test directory to hub's (currently using mine).

@tatevikh @FayazRahman this one's in the backlog, correct? Should it be left for someone else to be resolved?

@mikayelh Yes it is in the backlog.

@gaurav879 wanna help us out here? it would be super appreciated.

lmao you've been maintaining this PR for like 6 months


How can I know the index of the current node?

Let's say I have got 5 nodes connected  linearly in chain. How can I know from within each node its index in the chain?
Sorry for asking it here,I didn't find anything related to it in the docs.

Can you describe the problem in more detail, exactly, for what you need to get indexes?

A quick solution is to make the increment of the global variable in the workers, and before calling the process() to reset this variable

The problem is simple: I have a several nodes connected one with another like a chain. I want to know the ordered of the connected nodes. I see the editor keeps track of all the nodes,but as added nodes.It doesn't keep them necessarily in the order in which they're connected.

The nodes are processed according to the principle from left to right. The leftmost will be processed first, and the last will be the latest on the right.
First of all:
new D3NE.Node() it is instance of node in editor
node parameter in worker it is data of instance. I.e result of editor.nodes[0].toJSON()
Do you always have nodes that are connected only in a chain? What is the main task?
Maybe it's directly related to your task https://github.com/Ni55aN/d3-node-editor/issues/52#issuecomment-369727350


Fix sample of a command using YAML support in README

Fix sample of a command using YAML support.
A type errors occurred, if execute sample of a command using YAML support in README.
The reason is altsrc.NewIntFlag requires type "gopkg.in/urfave/cli.v1".IntFlag, but cli.IntFlag is type "github.com/urfave/cli".IntFlag in sample.
altsrc.NewIntFlag(cli.IntFlag{Name: "test"})
// cannot use "github.com/urfave/cli".IntFlag literal (type "github.com/urfave/cli".IntFlag) as type "gopkg.in/urfave/cli.v1".IntFlag in argument to altsrc.NewIntFlag

This PR is solves this error.

Given that this PR is from last year, I think I'm comfortable closing it 🙂 feel free to re-open / open a new PR if there's still interest here!


Removed redundant 'supports_autocommit' field in DbApiHook

Saw that it was in there twice.

:+1: Thanks for the contrib!

No problem, I also noticed there's some other duplicate stuff in master...  Making a ticket because I'm not actually sure what the best way to fix it would be.


Don't use authentication for retrieval of crate metadata.

As far as I can see it is not needed to be authenticated, and since some users might not be going to publish crates at all requiring them to have a token might be a bit annoying.

Thanks!


Enter our low hanging fruit into Hacktoberfest

DigitalOcean are running Hacktoberfest throughout the month of October.
This could be a nice way to attract some new contributors to RuboCop. I suggest we add the hacktoberfest tag label to some of our simpler issues. 😀
WDYT? @bbatsov, @jonas054?

Fine by me. By tag you mean label, right?

Good idea. I've created the label.

And a first candidate, #3103. View list here.

By tag you mean label, right?

Yes. Brain fart. 😁

I've created the label.

Awesome! 😄


Return edge type in edges(triple=True) as documented

This fixes StellarGraph.edges to return the edge type, as was intended based on the documentation. Previously it was returning an integer that had no connection to the edge type: the multigraph key, that is, the index of the given edge within all of the edges between the same source and destination.
This key could be set to an arbitrary hashable value using an appropriate version of add_edge/add_edges_from's constructor, which worked ok in reduced tests, but doesn't match how the rest of the library works, and doesn't work if there's multiple edges of a particular type:
import networkx as nx
g = nx.MultiGraph()
g.add_edges_from([(1, 2, "A"), (1, 2, "A")])
# ['A', 'A']
g.number_of_edges()
# 1

Using the data dictionary to store the label (like the rest of the library) means the edge keys are autogenerated and multiple edges are thus fine:
g2 = nx.MultiGraph()
g2.add_edges_from([(1, 2, {"label": "A"}), (1, 2, {"label": "A"})])
# [0, 1]
g2.number_of_edges()
# 2

See: #642

Hm, this currently seems to cause the accuracy of the RGCN notebook to plummet from 0.9 to 0.3-0.4, so something isn't quite right.


Language code table and Inconsistency about the benchmark test set & support languages

Hi!
It will be nice if we could have a language code explanation table as some of them are missing. By language code, I am referring to the output of
>>> from transformers import MarianMTModel, MarianTokenizer
>>>tokenizer = MarianTokenizer.from_pretrained('pretrained_models/opus-mt-en-mul')  # en-mul as an example here
>>>print(tokenizer.supported_language_codes)
['>>ewe<<', '>>sna<<', '>>lin<<', '>>toi_Latn<<', '>>ceb<<', '>>oss<<', '>>run<<', '>>mfe<<', '>>ilo<<', '>>zlm_Latn<<', '>>pes<<', '>>smo<<', '>>hil<<', '>>niu<<', '>>sag<<', '>>fij<<', '>>cmn_Hans<<', '>>nya<<', '>>tso<<', '>>war<<', '>>gil<<', '>>hau_Latn<<', '>>umb<<', '>>glv<<', '>>tvl<<', '>>ton<<', '>>zul<<', '>>kal<<', '>>pag<<', '>>cmn_Hant<<', '>>pus<<', '>>abk<<', '>>pap<<', '>>hat<<', '>>mkd<<', '>>tuk_Latn<<', '>>yor<<', '>>tuk<<', '>>sqi<<', '>>tir<<', '>>mlg<<', '>>tur<<', '>>ido_Latn<<', '>>mai<<', '>>ibo<<', '>>srp_Cyrl<<', '>>srp_Latn<<', '>>kir_Cyrl<<', '>>heb<<', '>>bos_Latn<<', '>>bak<<', '>>ast<<', '>>som<<', '>>tah<<', '>>chv<<', '>>kek_Latn<<', '>>lug<<', '>>vie<<', '>>wln<<', '>>isl<<', '>>hye<<', '>>mah<<', '>>yue_Hant<<', '>>crh_Latn<<', '>>amh<<', '>>nds<<', '>>pan_Guru<<', '>>xho<<', '>>ukr<<', '>>cat<<', '>>afr<<', '>>tat<<', '>>guj<<', '>>jpn<<', '>>mon<<', '>>eus<<', '>>nob<<', '>>glg<<', '>>ind<<', '>>sin<<', '>>cym<<', '>>zho_Hant<<', '>>zho_Hans<<', '>>tgk_Cyrl<<', '>>aze_Latn<<', '>>ltz<<', '>>bod<<', '>>asm<<', '>>tel<<', '>>urd<<', '>>kaz_Cyrl<<', '>>lat_Latn<<', '>>gla<<', '>>kan<<', '>>bul<<', '>>kin<<', '>>ina_Latn<<', '>>ron<<', '>>spa<<', '>>csb_Latn<<', '>>iba<<', '>>tha<<', '>>nno<<', '>>hrv<<', '>>fry<<', '>>bre<<', '>>mar<<', '>>sme<<', '>>swe<<', '>>deu<<', '>>jav<<', '>>snd_Arab<<', '>>ben<<', '>>cmn<<', '>>ces<<', '>>ita<<', '>>fin<<', '>>por<<', '>>hin<<', '>>hun<<', '>>mal<<', '>>pol<<', '>>fra<<', '>>nld<<', '>>epo<<', '>>slv<<', '>>hsb<<', '>>kur_Latn<<', '>>ori<<', '>>tam<<', '>>bel<<', '>>dan<<', '>>ara<<', '>>mya<<', '>>rus<<', '>>mri<<', '>>est<<', '>>uzb_Latn<<', '>>lao<<', '>>yid<<', '>>uzb_Cyrl<<', '>>uig_Arab<<', '>>lit<<', '>>zho<<', '>>lav<<', '>>ell<<', '>>kat<<', '>>gle<<', '>>mlt<<', '>>khm<<', '>>oci<<', '>>kur_Arab<<', '>>ang_Latn<<', '>>kaz_Latn<<', '>>wol<<', '>>sun<<', '>>chr<<', '>>tat_Latn<<', '>>mhr<<', '>>tyv<<', '>>rom<<', '>>cha<<', '>>kab<<', '>>nav<<', '>>arg<<', '>>khm_Latn<<', '>>bul_Latn<<', '>>udm<<', '>>quc<<', '>>cor<<', '>>san_Deva<<', '>>fao<<', '>>bel_Latn<<', '>>jbo_Latn<<', '>>yue<<', '>>grn<<', '>>sco<<', '>>arq<<', '>>ltg<<', '>>yue_Hans<<', '>>min<<', '>>nan<<', '>>bam_Latn<<', '>>ido<<', '>>ile_Latn<<', '>>wuu<<', '>>crh<<', '>>tlh_Latn<<', '>>lzh<<', '>>jbo<<', '>>lzh_Hans<<', '>>vol_Latn<<', '>>lfn_Latn<<', '>>arz<<']

Moreover, I've noticed that in the opus-mt-en-mul model card, Malay (ms/msa) is not listed as a support language and I couldn't find it in the output above, however, in the Benchmark section, there is a test set listed as Tatoeba-test.eng-msa.eng.msa and its corresponding scores are listed. So I am a little bit confused... Is Malay supported in this model? If yes, how am I suppose to test the model to translate English to Malay, more specifically, what kind of prefix should I append before each sentence to translate sentences from English to Malay?
A similar situation can be found in opus-mt-en-gem where Norwegian (no/nor) is not listed as a supported language, however, Tatoeba-test.eng-nor.eng.nor is listed as a test set. The output is listed below:
>>> tokenizer = MarianTokenizer.from_pretrained('pretrained_models/opus-mt-en-gem')
>>> print(tokenizer.supported_language_codes)
['>>isl<<', '>>nob<<', '>>nds<<', '>>afr<<', '>>deu<<', '>>swe<<', '>>nno<<', '>>fry<<', '>>nld<<', '>>ltz<<', '>>dan<<', '>>yid<<', '>>ang_Latn<<', '>>fao<<', '>>sco<<']

Thank you so much!

Yes, I need to document that in a better way. The problem is that I use macro languages in the Tatoeba data labels and they may contain various individual languages. msa is one of them and it will include zlm and zsm among others.
For Norwegian, there are two variants as well: nno and nob. You need to use those labels if you want to produce one of those variants.
The confusion is also caused by the conversion from 3-letter codes to 2-letter codes in the modelnames at huggingface. They decided to stick to 2-letter codes even though the model is trained with the 3-letter ISO code in mind.
I hope this explains at least a bit the situation.

Yes, I need to document that in a better way. The problem is that I use macro languages in the Tatoeba data labels and they may contain various individual languages. msa is one of them and it will include zlm and zsm among others.
For Norwegian, there are two variants as well: nno and nob. You need to use those labels if you want to produce one of those variants.
The confusion is also caused by the conversion from 3-letter codes to 2-letter codes in the modelnames at huggingface. They decided to stick to 2-letter codes even though the model is trained with the 3-letter ISO code in mind.
I hope this explains at least a bit the situation.

It helps a lot! Thank you so much!


Added docs for using Blackfire with Nitro

Added basic docs for using Blackfire with Nitro with browser extensions.

Thank you @bencroker!

@jasonmccallister I wanted to add the following screenshots to the docs but did not have permissions, will leave them here in case they are of any use to you.


v0.11: Redesign config and build system, split into sub-crates, and provide disk image builder

This pull requests implements the next version of the bootloader crate: v0.11. It contains multiple breaking changes:

Separate API crate: The bootloader is now split into two parts: An API crate to make kernels loadable by the bootloader and the actual bootloader implementation. This makes the build process for kernels much easier and faster.
New config system: Instead of configuring the bootloader via a special table in the Cargo.toml, the configuration now happens through a normal Rust struct, which is part of the entry_point! macro. The macro then serializes the config struct at compile time and places it in a special ELF output section. The compile time serialization happens through a manually implemented const fn of the config struct.
Load the kernel at runtime: The bootloader is now able to load files from FAT partitions at runtime. Thus, we don't need to link the kernel into the bootloader executable anymore. As a result, we don't need to recompile the bootloader on kernel changes anymore. We also load the config at runtime from the kernel's ELF section, which eliminates the second reason for recompiling the bootloader as well.
Split into sub-crates: Since the bootloader build process does not need access to the kernel executable or its Cargo.toml anymore, we can build the different parts of the bootloader independently. For example, the BIOS boot sector is now a separate crate, and the UEFI bootloader is too.
Library to create disk images: To create an abstraction the complex build steps of the different bootloader executables, we compile them inside cargo build scripts. At the top level, we provide a bootloader library crate, which compiles everything as part of its build script. This library includes functions for creating BIOS and UEFI disk images for a given kernel. These functions can be used e.g. from a builder crate or a build script of the downstream operating system.

Taken together, these changes should make the bootloader crate much easier to use and also more accessible to contributors.

This PR is still a work in progress. There are still many things missing, including:

[x] The BIOS implementation

[x] Integrate into build system
[x] Pure-Rust boot sector (16-bit real mode) that loads the second stage from a ~FAT partition~ MBR partition entry
[x] Pure-Rust second stage (16-bit unreal mode) that initializes the CPU and loads the kernel and third stage from the FAT partition

[x] Parse the FAT partition
[x] Locate the kernel-x86_64 file in the root folder
[x] Set up protected or unreal mode
[x] Load kernel to protected mode memory
[x] Create memory map and pass it to stage 3
[x] Set up framebuffer

[x] search VESA modes for a suitable one
[x] fill in framebuffer info in boot information
[x] enable the chosen VESA mode
[ ] consider config of kernel ELF (maybe later, not clear how we can read the config yet)

[x] Load third stage and jump to it

[x] Stage 3 (protected mode)

[x] Use framebuffer logger instead of VGA text mode
[x] Set up long mode and identity mapping

[x] Identity mapping
[x] Compatibility mode
[x] 64-bit mode

[x] Jump to stage 4

[x] Stage 4 (long mode)

[x] link with the common crate to handle the config and map the kernel

[x] Adjust README for new version
[ ] Create migration guides

[ ] From version 0.9.x
[ ] From version 0.10.x

[x] Clean up the repo and remove all legacy files

I've been working on a PXE bootloader based on the this branch. @phil-opp Would you prefer for me to create the pull request before or after you've finished working on this branch?

@Freax13 Sounds great!

Would you prefer for me to create the pull request before or after you've finished working on this branch?

Both are fine, so it depends on the state of your code. If it's ready already, feel free to send a PR! I just don't want to block the v0.11 release any longer than necessary.

So the BIOS implementation seems to need a lot of work done on it, but what about the UEFI implementation in this redesign? Less to do there?

@kennystrawnmusic The UEFI implementation is already done. It's much easier to load the kernel and the memory map there.

Now that the bootloader is independent from the kernel, we could compile the bootloader in CI and publish it that way. This would also make it easier for people who don't want to use bootloader::create_boot_partition, bootloader::create_uefi_disk_image etc and want to use their own build scripts instead.

Thanks a lot for taking the time to review! I know that this PR is huge and probably a nightmare to review. Fortunately, the control flow is quite linear, so we mostly need to check whether it is able to load different kernels and whether the given boot information is correct. Maybe it's a good idea to pre-publish an alpha release for this PR and try it out on different projects that are currently using bootloader v0.9 and v0.10?

Now that the bootloader is independent from the kernel, we could compile the bootloader in CI and publish it that way. This would also make it easier for people who don't want to use bootloader::create_boot_partition, bootloader::create_uefi_disk_image etc and want to use their own build scripts instead. This might be out of the scope for this pr though.

Interesting idea! I agree that there is definitely some value in creating GitHub releases with precompiled artifacts. However, the current form of the BIOS bootloader might make that difficult since it consists of many indepentent executables that have strict requirements about the partition and file system layout. So it's probably better to do this in a follow-up PR and maybe improve the BIOS setup beforehand.

The CI errors should be fixed by https://github.com/rust-lang/rust/pull/101413, which should be part of the next Rust nightly.

Thanks a lot for taking the time to review! I know that this PR is huge and probably a nightmare to review. Fortunately, the control flow is quite linear, so we mostly need to check whether it is able to load different kernels and whether the given boot information is correct.

I'll try to do another round of review today.

Maybe it's a good idea to pre-publish an alpha release for this PR and try it out on different projects that are currently using bootloader v0.9 and v0.10?

Github codesearch can be used to find projects using the bootloader: "bootloader = " ("0.9" OR "0.10") path:Cargo.toml
I've been using a fork of this branch for my own project for a while now (the fork was needed because the bootloader still relied on bindeps and that doesn't work with packages published to crates.io or used with git). I'll switch back to this branch and test.

I'll also test on some real platforms.

Github codesearch can be used to find projects using the bootloader: "bootloader = " ("0.9" OR "0.10") path:Cargo.toml

Good idea!

I've been using a fork of this branch for my own project for a while now (the fork was needed because the bootloader still relied on bindeps and that doesn't work with packages published to crates.io or used with git). I'll switch back to this branch and test.

Ah, I wasn't aware of that. I think the only remaining uses of bindeps are for the test framework, so it should no longer be a problem. But if you encounter any issues, please let me know!

I'll also test on some real platforms.

That would be great, I haven't done that at all yet.

Hmm, I'm getting a crash on one of my NUCs when booting with the UEFI bootloader:
!!!! X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID - 00000000 !!!!
ExceptionData -<PHONE_NUMBER>000000  I:0 R:0 U:0 W:0 P:0 PK:0 SS:0 SGX:0
RIP  -<PHONE_NUMBER>0E964F, CS  -<PHONE_NUMBER>000038, RFLAGS -<PHONE_NUMBER>010287
RAX  -<PHONE_NUMBER>107219, RCX - FFFFFFFD00000000, RDX -<PHONE_NUMBER>7FFB08
RBX  -<PHONE_NUMBER>000000, RSP -<PHONE_NUMBER>0E7360, RBP -<PHONE_NUMBER>000FFF
RSI  -<PHONE_NUMBER>000000, RDI -<PHONE_NUMBER>1536D3
R8   -<PHONE_NUMBER>107B88, R9  -<PHONE_NUMBER>7EC000, R10 -<PHONE_NUMBER>588018
R11  -<PHONE_NUMBER>108B90, R12 -<PHONE_NUMBER>0E7650, R13 -<PHONE_NUMBER>0E73F0
R14  -<PHONE_NUMBER>000002, R15 -<PHONE_NUMBER>001340
DS   -<PHONE_NUMBER>000030, ES  -<PHONE_NUMBER>000030, FS  -<PHONE_NUMBER>000030
GS   -<PHONE_NUMBER>000030, SS  -<PHONE_NUMBER>000030
CR0  -<PHONE_NUMBER>010013, CR2 - FFFFFFE834107219, CR3 -<PHONE_NUMBER>A01000
CR4  -<PHONE_NUMBER>000668, CR8 -<PHONE_NUMBER>000000
DR0  -<PHONE_NUMBER>000000, DR1 -<PHONE_NUMBER>000000, DR2 -<PHONE_NUMBER>000000
DR3  -<PHONE_NUMBER>000000, DR6 - 00000000FFFF0FF0, DR7 -<PHONE_NUMBER>000400
GDTR -<PHONE_NUMBER>6CCA98<PHONE_NUMBER>000047, LDTR -<PHONE_NUMBER>000000
IDTR -<PHONE_NUMBER>C43018<PHONE_NUMBER>000FFF,   TR -<PHONE_NUMBER>000000
FXSAVE_STATE -<PHONE_NUMBER>0E6FC0
!!!! Can't find image information. !!!!

I'll investigate what's going on.

The bounds check for the logger look wrong:
https://github.com/rust-osdev/bootloader/blob/960671c3669c7d1be95f1dfb40afdf9bea8172f8/common/src/logger.rs#L103-L110
It's mixing up width and height. I've ran into index out of bounds panics because of this.

Hmm, I'm getting a crash on one of my NUCs when booting with the UEFI bootloader:
!!!! X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID - 00000000 !!!!
ExceptionData -<PHONE_NUMBER>000000  I:0 R:0 U:0 W:0 P:0 PK:0 SS:0 SGX:0
RIP  -<PHONE_NUMBER>0E964F, CS  -<PHONE_NUMBER>000038, RFLAGS -<PHONE_NUMBER>010287
RAX  -<PHONE_NUMBER>107219, RCX - FFFFFFFD00000000, RDX -<PHONE_NUMBER>7FFB08
RBX  -<PHONE_NUMBER>000000, RSP -<PHONE_NUMBER>0E7360, RBP -<PHONE_NUMBER>000FFF
RSI  -<PHONE_NUMBER>000000, RDI -<PHONE_NUMBER>1536D3
R8   -<PHONE_NUMBER>107B88, R9  -<PHONE_NUMBER>7EC000, R10 -<PHONE_NUMBER>588018
R11  -<PHONE_NUMBER>108B90, R12 -<PHONE_NUMBER>0E7650, R13 -<PHONE_NUMBER>0E73F0
R14  -<PHONE_NUMBER>000002, R15 -<PHONE_NUMBER>001340
DS   -<PHONE_NUMBER>000030, ES  -<PHONE_NUMBER>000030, FS  -<PHONE_NUMBER>000030
GS   -<PHONE_NUMBER>000030, SS  -<PHONE_NUMBER>000030
CR0  -<PHONE_NUMBER>010013, CR2 - FFFFFFE834107219, CR3 -<PHONE_NUMBER>A01000
CR4  -<PHONE_NUMBER>000668, CR8 -<PHONE_NUMBER>000000
DR0  -<PHONE_NUMBER>000000, DR1 -<PHONE_NUMBER>000000, DR2 -<PHONE_NUMBER>000000
DR3  -<PHONE_NUMBER>000000, DR6 - 00000000FFFF0FF0, DR7 -<PHONE_NUMBER>000400
GDTR -<PHONE_NUMBER>6CCA98<PHONE_NUMBER>000047, LDTR -<PHONE_NUMBER>000000
IDTR -<PHONE_NUMBER>C43018<PHONE_NUMBER>000FFF,   TR -<PHONE_NUMBER>000000
FXSAVE_STATE -<PHONE_NUMBER>0E6FC0
!!!! Can't find image information. !!!!

I'll investigate what's going on.

I'm pretty sure this crash is caused by the custom UEFI memory type we use for the kernel. The address in CR2 seems to be linearly dependent on the provided memory type. There used to be a bug in edk2 that stopped those custom memory types working, but that bug was fixed more than 10 years ago in https://github.com/tianocore/edk2/commit/10fe0d814add860a1040e648b1f5782c0de350e6. I don't know why this bug would be present on platforms I've acquired less than a year ago. Just to be sure I checked grub and they also seem to be using the standard memory type LOADER_DATA (https://github.com/jiazhang0/grub-efi/blob/cb3fa40dae2cd397e63bd0b1195fec085564ed7e/efi/efimm.c#L91-L95). I also found someone else coming across the same issue. Changing the memory type to LOADER_DATA fixed the crash.

Changing the memory type to LOADER_DATA fixed the crash.

With that patched I was able to test the UEFI bootloader in 6 platforms (3 Intel, 3 AMD) and it worked on all of them.

Changing the memory type to LOADER_DATA fixed the crash.

With that patched I was able to test the UEFI bootloader on 6 platforms (3 Intel, 3 AMD) and it worked on all of them.

I've published the kernel I used for testing under https://github.com/Freax13/test-kernel.

Thanks a lot for testing and debugging this!

It's mixing up width and height. I've ran into index out of bounds panics because of this.

Fixed in https://github.com/rust-osdev/bootloader/pull/232/commits/47a4c85d96e285f8b208142e455a04eb0a61bcf6.

Changing the memory type to LOADER_DATA fixed the crash.

Interesting! So we need to find another way to recognize the bootloader memory region after allocation, right?

Interesting! So we need to find another way to recognize the bootloader memory region after allocation, right?

Yes, but do we even need to mark LOADER_DATA regions are usable? AFAICT we only use LOADER_DATA for the kernel and the memory map and we don't want to mark either of those as usable after exiting boot services. Unless I'm missing something, us marking the memory map as usable is a bug, isn't it?

Yes, but do we even need to mark LOADER_DATA regions are usable? AFAICT we only use LOADER_DATA for the kernel and the memory map and we don't want to mark either of those as usable after exiting boot services. Unless I'm missing something, us marking the memory map as usable is a bug, isn't it?

I think loader data is also used for the UEFI application itself, i.e. storing the data sections of the bootloader executable. The memory map is converted later to a common format and copied into a new region. So we don't need the UEFI-specific memory map anymore after switching to the kernel.

Ah that explains it.
I guess we need something similar to https://github.com/rust-osdev/bootloader/blob/130d5f0ac8b3cd340ea25ce3306068db48112f70/common/src/legacy_memory_region.rs#L113-L130 for the kernel. Damn the custom memory type would have been so much cleaner.

I guess we need something similar to [...]

Done in https://github.com/rust-osdev/bootloader/pull/232/commits/08e4b5829bf5882d9d396e641e32b65de72704b2

https://github.com/rust-osdev/bootloader/blob/667e57f552e214f9c19848306e03b00d91a8114f/api/src/info.rs#L175-L177
This is unsound because create_buffer creates a mutable reference which is not allowed to alias other references created by buffer().

Thanks a lot a for reviewing!
I try to create add a basic migration guide later, then I think we can merge :tada:.

Hello,
I tried this version with the test-kernel from @Freax13, with UEFI works fine. But with legacy BIOS on bare metal doesn't work.
I get a PANIC on bios/stage-2/src/main.rs on the line 111:10, the cause is an unwrap on a None value of an Option.
Thanks for this amazing project.

@asensio-project Thanks for testing! Seems like this is related to the VESA config here:
https://github.com/rust-osdev/bootloader/blob/f95e9a97190c118f94f914b0c2483b137b8be39d/bios/stage-2/src/main.rs#L108-L111
I'll look into it!

getting
UEFI bootloader started; trying to load kernel
panicked at 'called `Option::unwrap()` on a `None` value', common\src\lib.rs:67:27

It seems to be coming from https://github.com/rust-osdev/bootloader/blob/next/common/src/lib.rs#L67-L69 and,
only happens when I compile in release mode with lto = true

It seems to be coming from https://github.com/rust-osdev/bootloader/blob/next/common/src/lib.rs#L67-L69 and, only happens when I compile in release mode with lto = true

@TheBotlyNoob You probably need a custom linker script specifying to KEEP those custom sections.

@TheBotlyNoob Thanks for reporting! There was a bug in the entry_point macro so that the config was not marked as used properly. I pushed a fix in 076bea9 and added a test to prevent regressions.

Seems like this is related to the VESA config here:
https://github.com/rust-osdev/bootloader/blob/f95e9a97190c118f94f914b0c2483b137b8be39d/bios/stage-2/src/main.rs#L108-L111
I'll look into it!

Whew, that took a lot of debugging. It turns out that there were two bugs in the VESA code related to segmented memory. Apparently QEMU doesn't use segments in that case, so it was only triggered by real hardware. I pushed fixes for the bugs in https://github.com/rust-osdev/bootloader/pull/232/commits/6eb0abbb7e5b4b6088fb49452c7dc976183a946a and https://github.com/rust-osdev/bootloader/pull/232/commits/a6d69e9b4bd9daf4dc006d25b9d11d6c06edaab2. Now it boots fine with both UEFI and BIOS on my old laptop.

Just did another test run: Tested the UEFI bootloader on 6 platforms (4x Intel, 2x AMD) and the BIOS bootloader on 1 platform (Intel). all successful

Hmm, I'm getting a crash on one of my NUCs when booting with the UEFI bootloader:
!!!! X64 Exception Type - 0E(#PF - Page-Fault)  CPU Apic ID - 00000000 !!!!
ExceptionData -<PHONE_NUMBER>000000  I:0 R:0 U:0 W:0 P:0 PK:0 SS:0 SGX:0
RIP  -<PHONE_NUMBER>0E964F, CS  -<PHONE_NUMBER>000038, RFLAGS -<PHONE_NUMBER>010287
RAX  -<PHONE_NUMBER>107219, RCX - FFFFFFFD00000000, RDX -<PHONE_NUMBER>7FFB08
RBX  -<PHONE_NUMBER>000000, RSP -<PHONE_NUMBER>0E7360, RBP -<PHONE_NUMBER>000FFF
RSI  -<PHONE_NUMBER>000000, RDI -<PHONE_NUMBER>1536D3
R8   -<PHONE_NUMBER>107B88, R9  -<PHONE_NUMBER>7EC000, R10 -<PHONE_NUMBER>588018
R11  -<PHONE_NUMBER>108B90, R12 -<PHONE_NUMBER>0E7650, R13 -<PHONE_NUMBER>0E73F0
R14  -<PHONE_NUMBER>000002, R15 -<PHONE_NUMBER>001340
DS   -<PHONE_NUMBER>000030, ES  -<PHONE_NUMBER>000030, FS  -<PHONE_NUMBER>000030
GS   -<PHONE_NUMBER>000030, SS  -<PHONE_NUMBER>000030
CR0  -<PHONE_NUMBER>010013, CR2 - FFFFFFE834107219, CR3 -<PHONE_NUMBER>A01000
CR4  -<PHONE_NUMBER>000668, CR8 -<PHONE_NUMBER>000000
DR0  -<PHONE_NUMBER>000000, DR1 -<PHONE_NUMBER>000000, DR2 -<PHONE_NUMBER>000000
DR3  -<PHONE_NUMBER>000000, DR6 - 00000000FFFF0FF0, DR7 -<PHONE_NUMBER>000400
GDTR -<PHONE_NUMBER>6CCA98<PHONE_NUMBER>000047, LDTR -<PHONE_NUMBER>000000
IDTR -<PHONE_NUMBER>C43018<PHONE_NUMBER>000FFF,   TR -<PHONE_NUMBER>000000
FXSAVE_STATE -<PHONE_NUMBER>0E6FC0
!!!! Can't find image information. !!!!

I'll investigate what's going on.

I'm pretty sure this crash is caused by the custom UEFI memory type we use for the kernel. The address in CR2 seems to be linearly dependent on the provided memory type. There used to be a bug in edk2 that stopped those custom memory types working, but that bug was fixed more than 10 years ago in tianocore/edk2@10fe0d8. I don't know why this bug would be present on platforms I've acquired less than a year ago. Just to be sure I checked grub and they also seem to be using the standard memory type LOADER_DATA (https://github.com/jiazhang0/grub-efi/blob/cb3fa40dae2cd397e63bd0b1195fec085564ed7e/efi/efimm.c#L91-L95). I also found someone else coming across the same issue. Changing the memory type to LOADER_DATA fixed the crash.

Turns out that there is a very similar (yet unpatched) bug that someone else found about three years ago: https://bugzilla.tianocore.org/show_bug.cgi?id=2372 and this is actually what went wrong when I was testing. I confirmed by attaching a debugger and reverse engineering the part of the firmware that crashed. This bug hasn't been patched yet, so, sadly, we still can't use custom memory types.

Thanks for looking into this! Even if this is fixed at some point, there will still be systems with older firmware in the wild, right? So we should probably just keep using the default memory type.

Yup, I don't think we'll ever get to the point where all devices are patched. It would be nice not to rely on the workaround, it's really a shame that this bug exists, I liked the custom memory types :disappointed:. I mainly looked into this because I couldn't believe that reputable vendors would push firmware that contained bugs that have been patched more than 10 years ago.

When the alpha was released, docs.rs failed to build documentation for it: https://docs.rs/crate/bootloader/0.11.0-alpha.0/builds/539317. The build.rs script tried to build the uefi and bios bootloaders, but didn't have network access to download the dependencies and failed.

I think this is ready to be merged :tada:.


a way of creating a water instead of air

Is your feature request related to a problem? Please describe.
the ability to set a variable sea level instead of complete air
Describe the solution you'd like
config option
Describe alternatives you've considered

Maybe this could be expanded so that you can specify what block to place until a specific layer. Like fill_world_until_y = 63 and block_to_fill_until_layer = minecraft:air so this can be done with Lava, Diamond Blocks or whatever else.
If this were added the mod could allow to create Stoneblock like maps but with any block that you choose.

Yeah thats would be great

Also a way to maybe have a biome as well?

Maybe this could be expanded so that you can specify what block to place until a specific layer. Like fill_world_until_y = 63 and block_to_fill_until_layer = minecraft:air so this can be done with Lava, Diamond Blocks or whatever else.
If this were added the mod could allow to create Stoneblock like maps but with any block that you choose.

My plan is to implement a way to set in the config something like the flat world generation. So you can specify multiple layers, which block type the layer should be and the thickness of that layer. Additionally a config for sea level.
This allows a high configurable world.

Also a way to maybe have a biome as well?

I’m not sure about that. I already tried a bit with that but it wasn’t good. Maybe I need help with that and more inspiration how to implement it/what to implement exactly.

closed by https://github.com/MelanX/SkyblockBuilder/commit/9fc2ac13058451559c1151f54ad5cebaf08fddbb (not uploaded yet but I forgot to add 'closes #9' to commit message and I will forget it when I push)


Improve test coverage of subscriptions

In this area we have been leaning to heavily on @klauer as a human unit test.

As the @klauer unit test framework is fundamentally broken, I think that this issue needs attention very soon.


Meeting a question

RuntimeError: Attempting to deserialize object on a CUDA device but torch.cuda.i s_available() is False. If you are running on a CPU-only machine, please use tor ch.load with map_location=torch.device('cpu') to map your storages to the CPU.
good moring ,sir, how to solve this question,thank you?

It seems that you don't have a CUDA environment, please configure correctly first. If you want to run the code on CPU (not recommended), you can simply modify the code to remove .cuda().

Oh. Appreciate
------------------ 原始邮件 ------------------
发件人<EMAIL_ADDRESS>发送时间: 2019年10月17日(星期四) 上午10:49
收件人<EMAIL_ADDRESS>抄送: "黄倩倩"<836895752<EMAIL_ADDRESS>主题: Re: [hyk1996/Single-Human-Parsing-LIP] Meeting a question (#4)
It seems that you don't have a CUDA environment, please configure correctly first. If you want to run the code on CPU (not recommended), you can simply modify the code to remove .cuda().
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


[Feature-request] optional button on right side or left side

Like it could be a close button so that It would give the user a better indicator to tap it to close. Or an action like delete or invite or go to XYZ location, etc.
What do others think about this? Open to suggestions

I think it is alright, as long as it wont block user to keep interacting with the UI while showing the DropdownAlert.
like something shows here RKDropdownAlert

Yeah I agree. #7 would help address this.

Not going to do this.


adding my name to students.md

Pull request for the hands-on

This looks good!

thanks both! merging this in now


Why is this project not shown in google?

Every time I try to find this project, I have to go to the comments in
https://www.flamingo-tech.nl/2021/05/03/xiaomi-air-purifier-3h-reverse-engineering-part-3-esp32-dump/
For example, a search for "Air Purifier 3H esphome github" doesn't list it. Maybe not everyone gets the same results, of course..
Yes, bookmarking.. But it should show up.

That's indeed very weird, but I think it has improved a bit (at least for me). Searching for "mi Air Purifier esphome" no shows this repo and the corresponding thread on the home assistant forum as the first two results.


chore: blank_issues_enabled: true

Codecov Report

Merging #16 (30e9969) into master (5cdb8f9) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #16   +/-   ##
=======================================
  Coverage   91.69%   91.69%
=======================================
  Files         140      140
  Lines        6803     6803
  Branches     1850     1850
=======================================
  Hits         6238     6238
  Misses        445      445
  Partials      120      120

Continue to review full report at Codecov.

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


Adding users search

Make the users/search/ end point usable.
UsersAction
Adding methods to search users by query, and get the next page for specific requests.
UsersSearchRequest
I made multiple constructor to match the possible needs put in the UsersAction class.
UsersSearchResponse
It contains the results of the UsersSearchRequest. It is useful to get the next page of the request.

I wanted to make directly all the search end point

fbsearch/topsearch_flat/
tags/search/
- fbsearch/places/

However they are very similar, so first I wanted to know if the way I made them was good enough.


⚠ Syncthing-KA-TM has degraded performance

In d414e9b, Syncthing-KA-TM ($URL_SYNCTHING_MERZ_NIMBUS_TM) experienced degraded performance:

HTTP code: 200
Response time: 3681 ms

Resolved: Syncthing-KA-TM performance has improved in 86b83fe after 5 minutes.


add some cargo test tests for compression

we're starting to know fairly clearly at least what the top few inventions should be. Or perhaps just go by their scores. Would be great to catch regressions or improvements to expressivity. I also made the choice of invention deterministic among the set of options so it should be safe to go by exact invention. But going by scores may be quicker to adapt to as things change. Do whichever you think though

done :)


Added languages for syntax highlighting

Added PowerShell, HTTP, HCL and BICEP syntax highlighting support to Prism. details: https://docusaurus.io/docs/markdown-features/code-blocks#supported-languages)
Fixed up PowerShell language tag on Azure Storage.

there was one powerShell tag not powershell still hence the last commit


StdOut publisher

This is a spike exploring the proposal layed out in https://github.com/kbialek/deye-inverter-mqtt/issues/89

Included in beta image ghcr.io/kbialek/deye-inverter-mqtt:2023.06.1-beta-2

Let me know if you are happy with that PR, especially looking for feedback on:

naming of the thing and its config knob: DeyeStdoutPublisher, DEYE_FEATURE_STDOUT_PUBLISHER, ...
general implementation, integration & testing
docs

Let me know if you are happy with that PR, especially looking for feedback on:
* naming of the thing and its config knob: `DeyeStdoutPublisher`, `DEYE_FEATURE_STDOUT_PUBLISHER`, ...

okay

* general implementation, integration & testing

okay

* docs

comments left


v.0.6.0 broke the usual x-target behavior

Just wanted to let you know that upgrading from 0.5.1 to 0.6.0 broke things for me. No errors in console, just not working. Am I unlucky? Here's the screencast:
https://github.com/imacrayon/alpine-ajax/assets/914320/bee9dfb3-51e9-4da6-ad87-e28c3173afbb

Thanks for the quick feedback!
Sorry, I think you might have found a loophole in v0.5. x-target was intended to only work on <a> and <form> elements, but I think there was a regression recently that allowed it to unintentionally work on <button>s too. 😓
I'm assuming that the <Button> component in your project compiles down to a plain <button>? If that's not the case, let me know, but switching to an <a href="..."> or wrapping that button in a <form action="..."> should make it work again. We strictly only those two elements so that they gracefully degrade without JavaScript.

I'm afraid it's , not !
https://github.com/imacrayon/alpine-ajax/assets/914320/fba0a4eb-501d-4fc0-871d-b47223dcc61d

Ok, thanks for the clarification. I'm wondering if the link click events aren't bubbling up to document in  Astro for some reason.  Would you mind trying it out and taking a look at the results:
npm install "https://github.com/imacrayon/alpine-ajax.git#debug"

You should see output in the console when loading the page and clicking a link like this:
[x-target]  (Element)
Event: "click" captured
Requesting [...arguments]
Rendering [..arguments]

Thanks for your help!

Hey, so sorry for the delay, got drowned in work. Anyway, here's what the console said:
===
[astro] Prefetching http://localhost:8002/partials/clicked/?id=tgt-1 with fetch
@imacrayon_alpine-ajax.js?v=1c33ba91:14 Event: "click" captured
Abort: Insignificant click event
Navigated to http://localhost:8002/partials/clicked/?id=tgt-1
Here's the code:
https://github.com/vladstudio/aaui/tree/main/src/pages

Also if I'm the only one experiencing this, I think you can safely ignore the bug. I'm not (yet) using this code in any real product, so the impact is minimal.

No worries! I got this spun up on my machine just now, I'm gonna try to figure out what's going on. Thanks for sharing the repo.

Ok, so the problem is caused by Astro's View Transitions feature, specifically, this line. When view transitions are enabled, the framework listens for link clicks and navigates to the next page before Alpine AJAX has a chance to perform an AJAX request.
If you remove <ViewTransitions /> in Layout.astro things will start working again.
In v0.5 Alpine AJAX registered link click listeners before Astro's click listeners, but in v0.6 we deferred the click listeners so that other libraries have a chance to handle the click event before Alpine AJAX handles it.
We made the change to event listeners in v0.6 to support some future client-side routing features, but I might have to rethink that approach to make sure we can stay compatible with frameworks like Astro...

good catch! I will disable view transitions meanwhile.

Following up on this: We reworked event handling a bit so that Alpine AJAX will work if you install it using the installation instructions in the Alpine AJAX docs.
Using the Astro Alpine.js integration will break Alpine AJAX because Astro integrations are initialized after Astro View Transitions. I think this is the best we’re able to do without requesting changes to the Astro repo.


Add a weather API client

What's needed?
We need to provide a weather API client.
Proposed solution
Write a client based on what we have for the microgrid API.
This should live in frequenz.sdk.weather.client to also follow the microgrid API.
Use cases
No response
Alternatives and workarounds
No response
Additional context
Dispatching will be a core part of building actors and apps, so we need to include support for it in the SDK.
FYI @sahas-subramanian-frequenz @thomas-nicolai-frequenz

@llucax Is this essential if we want to use weather forecasts in our forecasting actor?

This is being done as a separate repo.


[Bug] Status field being populated with field options

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the issue
After upgrading from version >=0.8.0, and running a full refresh of the Jira data, the status field on both jira__daily_issue_field_history and jira__issue_enhanced is being populated with values from the jira.field_options table, instead of the status id it was previously, or a value from the jira.status table.
Relevant error log or model output
No response
Expected behavior
I would expect the status field to either contain the status_id, or the name from the jira.status table.
dbt Project configurations
version: '1.0.0'
config-version: 2
vars:
  jira:
    issue_field_history_columns: ['Work Type', 'Story Points', 'Squad']

Package versions
packages:

package: fivetran/jira
version: [">=0.8.0", "<0.9.0"]

What database are you using dbt with?
redshift
dbt Version
1.0.7
Additional Context
No response
Are you willing to open a PR to help address this issue?

[ ] Yes.
[ ] Yes, but I will need assistance and will schedule time during our office hours for guidance
[ ] No.

Hi @austensd thanks so much for opening this issue. That definitely seems strange and something we should take a closer look at. Would you mind sharing an example or two of this behavior?

Thanks for the quick response, here are some samples from our warehouse.
The first image shows a sample of the issue_id, status_id, and status fields for some records from our jira__issue_enhanced

the second shows some of the records from our jira.status table

and the third shows a sample from our jira.field_option table.

If we look at the status_id of 10035, the name from the status table should be To Do, but is instead showing as Internet Explorer, which is the field option that has the overlapping id.
Hopefully this helps.

status is the only field I've noticed an issue with, in terms of the other fields on the jira__daily_issue_field_history, we are not currently using the sprint field, and all of our custom fields appear to be correct. And I cannot see any issues with any other field on the jira__issue_enhanced table.

Thanks for the update @austensd! I will be OOO the remainder of the week, but will come back to this ticket when I return on Tuesday.

@austensd I just wanted to post back that I am still investigating this issue. I will be sure to post back once I identify a possible solution.

Hi @austensd I apologize for the delayed response, but we think we may have identified a solution. We will start working on the fix in coming week and will share a working version of the package for you to try. If all goes well there, we can include the changes in our next release!

Hey @fivetran-joemarkiewicz
Noticed I am finding this issue aswell after creating some dashboards in tableau. using the same table and finding the status field being populated with random values

How are you coming along in implementing a solution? :)

Hi @jamienewcomb thanks for reaching out and sharing that you are experiencing this as well. I should have a working branch early next week that I can share for you to test out and confirm if the issue still persists.
I hope to get this fix addressed by the middle of next week.

Thanks for the update @fivetran-joemarkiewicz
OOI: Do you know of anyone (of where I could ask) who has managed to create a burndown chart using this table (jira__daily_issue_field_history)? Have managed everything else but struggling with this one. Thanks!

Hi All,
I have been able to get a working version of the package that should address this issue. The changes are linked in the PR above. It would be great if you would be able to test the version of the package with these changes and let me know if the issue still persists. To test these changes you can use the following config in your packages.yml
packages:
  - git: https://github.com/fivetran/dbt_jira.git
    revision: bugfix/status-correction
    warn-unpinned: false

Please note this will be a breaking change since adjustments have been made to the incremental model. As such, you will need to run a dbt run --full-refresh in order for the changes to be reflected in your warehouse. Let me know how it goes!
Additionally, @jamienewcomb

Do you know of anyone (of where I could ask) who has managed to create a burndown chart using this table (jira__daily_issue_field_history)? Have managed everything else but struggling with this one. Thanks!

Unfortunately, I do not know of any current implementations of this. There may be some folks in dbt Slack that have experience putting this together!

Thanks @fivetran-joemarkiewicz . I will pass this onto our data team and let you know if it fixes the issue

@jamienewcomb and @austensd I had found an issue with the previous state of the branch I shared. However, I know feel I have been able to address it and the current build of the branch I shared above should be working as intended.
Let me know if this addresses your issues.

Thank you @fivetran-joemarkiewicz
It's on my data teams backlog so I am hopeful they can test this within the next week

This issue has since been addressed in the latest release of the package. Feel free to upgrade the package to see the updates. If the issue still persists please reopen this issue.


helm: Support configuring imagePullSecrets for spire agent/server pods

I've been noticing spire failing to pull images in conformance tests a few times recently, and noticed we don't have anyway to configure image pull secrets for these pods, so let's start there.
Note: the spire images come from a different registry than the rest of our images, however, the image pull secret format supports configuring multiple credentials based on the registry URI in the same file. Additionally, it's possible to configure multiple image pull secrets on a pod. So there shouldn't be any major issues with this using the same .Values.imagePullSecrets as the rest of the components, since you can configure it by registry (either in a single secret, or via multiple secrets).
Since this might be helpful for CI, I'm nominating it for backport to v1.16.
 Support configuring imagePullSecrets for spire agent/server pods

/test


update chef url and catch failures

[x] catch failures on the curlpipesudobash cmd by setting pipefail, and passing --fail to curl (to fail on unsuccessful http code).
[x] update chef url, per https://docs.chef.io/install_omnibus.html

Travis fixes in https://github.com/caskdata/coopr-provisioner/pull/216


 Thanks

I am able to install using pip install with the package name and the Git repository.
Can you check this answer? I hope it will help.
https://stackoverflow.com/a/69207780

This occurs due to files names with the '~' prefix in site-packages. Please remove those files / folders. It will solve your problem.
You can list them with
ls -a /xx/xx/xx/lib/pythonx.x/site-packages | grep "^~"
Then remove files/folders prefixed by '~'.


Tfrecords not getting read during training

I'm getting this error while running deeplab2/trainer/train.py' --config_file"deeplab2/configs/coco/max_deeplab/max_deeplab_s_os16_res641_400k.textproto" --mode "train" --model_dir checkpoint/max_deeplab_s_os16_res641_400k_coco_train --num_gpus 0
Traceback (most recent call last):
  File "/volumes2/Other/deeplab2/trainer/train.py", line 76, in <module>
    app.run(main)
  File "/usr/local/lib/python3.6/dist-packages/absl/app.py", line 312, in run
    _run_main(main, args)
  File "/usr/local/lib/python3.6/dist-packages/absl/app.py", line 258, in _run_main
    sys.exit(main(argv))
  File "/volumes2/Other/deeplab2/trainer/train.py", line 72, in main
    FLAGS.num_gpus)
  File "/volumes2/Other/deeplab2/trainer/train_lib.py", line 191, in run_experiment
    steps=config.trainer_options.solver_options.training_number_of_steps)
  File "/volumes2/Other/models/orbit/controller.py", line 240, in train
    self._train_n_steps(num_steps)
  File "/volumes2/Other/models/orbit/controller.py", line 439, in _train_n_steps
    train_output = self.trainer.train(num_steps_tensor)
  File "/volumes2/Other/models/orbit/standard_runner.py", line 146, in train
    self._train_loop_fn(self._train_iter, num_steps)
  File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/eager/def_function.py", line 885, in __call__
    result = self._call(*args, **kwds)
  File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/eager/def_function.py", line 950, in _call
    return self._stateless_fn(*args, **kwds)
  File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/eager/function.py", line 3040, in __call__
    filtered_flat_args, captured_inputs=graph_function.captured_inputs)  # pylint: disable=protected-access
  File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/eager/function.py", line 1964, in _call_flat
    ctx, args, cancellation_manager=cancellation_manager))
  File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/eager/function.py", line 596, in call
    ctx=ctx)
  File "/usr/local/lib/python3.6/dist-packages/tensorflow/python/eager/execute.py", line 60, in quick_execute
    inputs, attrs, num_outputs)
tensorflow.python.framework.errors_impl.FailedPreconditionError:  /volumes2/Other/data; Is a directory
	 [[{{node MultiDeviceIteratorGetNextFromShard}}]]
	 [[RemoteCall]]
	 [[while/body/_1/IteratorGetNext]] [Op:__inference_loop_fn_123475]

Function call stack:
loop_fn

Process finished with exit code 1

/volumes2/Other/data has 3000 .tfrecord files as a result of running build_coco_data.py file. Isn't this file supposed to return just three sharded tfrecord files?
Any help would be much appreciated!

Hi Kishaan,
Based on the provided log, could you please try to update the  file_pattern as follows:
file_pattern: "/volumes2/Other/data/train*.tfrecord"
Also, please read carefully the comments in the provided configs (e.g., here)
Hope that helps.
Cheers,

Closing the issue as there is no active discussion for a while.
Please feel free to reopen or create a new one if you have any question.


Easy to inject environments into container_definitions

Problem
I need to inject environment variables to the ECS container_definitions regarding the API tokens for different terraform providers (like fastly, pagerduty, etc.)
Ideas
Initially I was thinking to create a new container_definition module to override the existing one.
Per this code, container_definitions = "${var.custom_container_definitions == "" ? module.container_definition.json : var.custom_container_definitions}"
But then I realize it is pretty parameterized already inside this module and what I want is just override the environment list. So I guess maybe I just need to override the list?
What would be the better way?

Also just ran into this problem. Another approach is to allow passing custom environment / secrets through which will be included on the container
environment = [
  {
    name  = "ATLANTIS_ALLOW_REPO_CONFIG"
    value = "${var.allow_repo_config}"
  },
  ...
  "${var.custom_environment_variables}",
]

secrets = [
  {
    name      = "${local.secret_name_key}"
    valueFrom = "${local.secret_name_value_from}"
  },
  ...
  "${var.custom_environment_secrets}",
]

@stephencoe Does this work for you, somehow, my atlantis still complain about retrieving the credentials?


Add CoqCommandComplete and g:coqtail#event

Fixes #367.

@katrinafyi could you see if the approach described in the docs here does what you want?

I'll give it a try today, thanks!

Thanks for working on this!
Using the autocmd in the documentation seems to hang the editor. Is there a cycle with CoqJumpToEnd triggering it again?
I tried this and it did not seem to fix the problem, but my Vimscript is not good:
let g:coqautocommanding = v:false
augroup CoqtailFollowChecked
autocmd!
autocmd! User CoqCommandComplete
\  if ! g:coqautocommanding && g:coqtail#event.cmd =~# 'step\|rewind\|to_line\|to_top'
\|   let g:coqautocommanding = v:true
\|   CoqJumpToEnd
\|   let g:coqautocommanding = v:false
\| endif
augroup END

I can confirm that the autocmd works if I replace the CoqJumpToEnd with a simple echo.

Ah, I bet it's the same root problem as #360. I was able to work around it then but I guess I'll have to figure out how to actually solve it. In the meantime, it works for me at least using Vim instead of NeoVim.


userLibraryWays should override flavourLibraryWays

getLibraryWays currently looks like this:
-- | Combine default ways with user modifications
getLibraryWays :: Expr [Way]
getLibraryWays = fromDiffExpr $ mconcat [ defaultLibraryWays
                                        , userLibraryWays
                                        , flavourLibraryWays ]

I think the order of userLibraryWays and flavourLibraryWays should be reversed. The user is always right.

Here is why I chose this ordering: it's easier to change the command line (say, by adding --flavour=quick) than to change Settings/User.hs. So, I thought that command line settings should apply last. Changing them is very cheap, as no recompilation of Hadrian is needed, so presumably users will be using them for most frequent tweaks.

The user is always right.

But both the current flavour and Settings/User.hs are set by the user, right?
Maybe I'm misunderstanding the purpose of build flavours. Can you provide a more arguments why you think the ordering should be reversed?

In my opinion, users shouldn't be encouraged to control build settings using command line flags. If they come back to a project after a short break, they will just want to type make or hadrian/build.sh etc, and it should be a zero-build. They wouldn't remember which command line flags they used previously.
I don't think --haddock, --flavour, --split-objects need to exist at all. They can all just be User.hs settings.
Build flavours are just a combination of build settings that have turned out to be useful during ghc development. There are different ones for different use cases, for example working on the stage1 compiler vs the stage2 compiler, or creating a profiled ghc. A ghc developer doesn't usually create new build flavours, but they might override or add one or two settings compared to the build flavour they have chosen.
Example:

By default, the build system creates a release build, fully optimized and including documentation
A ghc developer might choose the devel2 build flavour, which builds the stage2 compiler unoptimized, skips the documentation, doesn't build prof libs, doesn't split-objs, and adds the -DDEBUG and -dcore-lint flags
But they do want to build the documentation, so they change User.hs to override just that setting

In my opinion, users shouldn't be encouraged to control build settings using command line flags.

@thomie This is quite a big step in the design space, away from the familiar territory of the Make build system. This also sounds as a dangerous diversion from the current project of migrating from Make to Shake, so I'm not sure now is a good time to attempt such changes. Note that in Make we could also dump all command line flags and use only build.mk, yet this is not how things are done. Let me invite others to this discussion: @ndmitchell, @hvr, @bgamari, @thoughtpolice, @simonmar -- what do you think?

I don't think --haddock, --flavour, --split-objects need to exist at all. They can all just be User.hs settings.

There is at least one important reason for --flavour to exist: CI. Without it, we will run out of time on our CI instances. Somehow patching Settings/User.hs on CI seems unnecessary complicated. There are other similar scenarios, when Hadrian is called as a part of a bigger script and therefore should support tuning via command line flags.

quick 2cents until I get more time to elaborate: I always considered mk/build.mk to be a configuration file in spirit. I don't like the idea that Settings/User.hs takes it places, requiring a recompile of hadrian everytime I want to change/tweak a setting. I'm used to the ./configure mental model which makes configuration flags/choices sticky. So that when I run make it keeps using whatever state configure persisted. I do, however, also like to inject CFLAGS or similiar via make CFLAGS=...  some/foo.o when I'm debugging/experimenting, that's something the dynamic nature of GNU make makes easy, having to recompile hadrian everytime, with the risk of invalidating  previous builds may break this workflow.

This is quite a big step in the design space, away from the familiar territory of the Make build system.

No?

This also sounds as a dangerous diversion from the current project of migrating from Make to Shake

I'm not sure why you think this.
Users can edit mk/build.mk to select a build flavour and set some other settings they would like to persist. There is no way to select a build flavour using command line flags.
Keeping the --flavour flag for CI is fine.
Anyway, this was a minor feature request to let users override settings from Settings/Flavours/*.hs by editing User.hs. Just like they can now override settings from mk/flavours/* by editing mk/build.mk (make sure they're below the include mk/flavours/$(BuildFlavour).mk line!).

I thought that command line settings should apply last.

Command line flags should apply last, indeed. So if nothing else changes, this issue can be closed.
Sorry, while writing my previous comments, I mistakenly assumed it was already possible to select the build flavour from User.hs. I now see that isn't the case (though I think it should be, and maybe a new ticket should be opened for that).

Sorry, while writing my previous comments, I mistakenly assumed it was already possible to select the build flavour from User.hs. I now see that isn't the case (though I think it should be, and maybe a new ticket should be opened for that).

I think what we can do is to let the user choose the default flavour in User.hs. And in general, this may be a good approach: the user can change default settings for all command line settings in User.hs, and then override them from command line if need be. Does this sound good?
Note, there is an open issue dedicated to build flavours: #188. Currently we only have two: Default (default) and Quick. I can see how some users may want to set the default flavour to Quick, e.g. I would do that. We can continue flavour-specific discussions there, in which case we can probably close this issue.

I'm fine to also have a more general discussion to elaborate on your comment that users shouldn't be encouraged to control build settings using command line flags. Feel free to open a new issue for that.
The current Make instructions do list command line settings like EXTRA_HC_OPTS=-dcore-lint, FAST=YES, and others: https://ghc.haskell.org/trac/ghc/wiki/Building/Using#Buildconfiguration. Plus @hvr's example.

There is no way to select a build flavour using command line flags.

Ah, I didn't know that. I always thought you can just do make BuildFlavour=quick.

Does this sound good?
Yes.

I'm closing this issue, as it was mostly just misunderstanding.


Fix missing libraries for external projects linking against RTK

@SimonRit This should allow calling find_package(RTK) to access variable such ${RTK_USE_CUDA}
I am still working on having CUDA libraries linking properly. I'll keep you posted!

@LucasGandel That does not seem to work. RTK_USE_CUDA is still not known in the FirstReconstruction example... BTW, I don't have a linking problem if I remove the condition on RTK_USE_CUDA in this example.

@SimonRit The last commit should fix the failures when finding package CUDA_wrap.
You should now have access to all variable if using find_package(RTK)

@SimonRit That might work if you set the RTK_DIR to ~/ITK_build/Modules/Remote/RTK. But you are right, it would be much better to export the remote module configuration in ITK, I'll check it!


Effect types

Users suggest that we need to treat the effects in a disciplined way, especially these:

Async functions
Exceptions
Access of database and other external resources

Consider using Koka's row polymorphic effect types.

Duplicate effects.
Koka:
catch : ∀ a u . (() → <exn | u> a, exception → u a) → u a

Labels should be able to duplicate since u could be <> or <exn>

RowScript:
catch
  : {a : type}
  → {u : row}
  → {v : row}
  → (args : ((args: unit) → u a) * ((args : exception * unit) → v a) * unit)
  → {auto p : u = v + (exn : effect)}
  → v a

Eh, the basic Koka effects that could be used in RowScript is only exn... and yes the effects are extensible in Koka, but how could users define their own domain-specific effects?

The type signature of Koka's await looks like call/cc, but the semantics should not be related to it since it confuses our users. And we need to introduce a new syntax for the continuation-passing version of RowScript's await.
For now, we would have 3 kinds of asynchronous constructs in RowScript:

__await__: The method of interface Await, for internal use only
await: The JavaScript compatible version of await, but it's a sugar using __await__
await next with block/expr: The continuation-passing version of await, again a sugar using __await__

Next we need to consider the CPS for await, awat { ... } and Await.{all, any, race}.

Notice that the await(expr0, expr1, ...) syntax, it's a direct call to interface method __await_let__:
interface AsyncLet {
    __await_let__<Args>(...: Args): Args;
}

So the arguments would actually be the resolved results, not the executor list. The ability of fine-grained executor control is not available in this syntax.
If we really need to have this support, e.g.:
await(
  { resolve(42) },
  { resolve(69) }
);

We actually need much dependent types magic like List<type> as input and the function signature as the output (i.e. larget elimination), and then generate the function in compile time, which is quite annoying.


Clarify OAS versions support

Description
Hello there! I was wondering whether your plugin supports OAS 3.1 documents. Thank you!

Motivation and Context
I believe OAS 3.1.0 support is relevant and it's probably a good idea to have that mentioned in the README.md file, in case it is supported by now.

How Has This Been Tested?
For the moment, I can see in<EMAIL_ADDRESS>that 3.1 is accepted, however I'd like to know whether there's actual support, or it's just treating 3.1 docs the same way it treats 3.0 docs.

Types of changes

New feature (non-breaking change which adds functionality)

Checklist

[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes if appropriate.
[ ] All new and existing tests passed.

Hi @valp0, thanks for the question. Unfortunately support for OpenAPI 3.1 is not available, yet, but it's on the roadmap for our upcoming v2.0.0 release. ETA rough 2-3 months out (or sooner).

Understood! Thank you very much for your quick answer!


Color of inputs

Hi, please I need help, how to change color of input? In materializecss i can do this:
.input-field label   {     color: $primary-color;   }   .input-field input[type=text]:focus + label {   color: $primary-color; } .input-field input[type=text]:focus {   border-bottom: 1px solid $primary-color;   box-shadow: 0 1px 0 0 $primary-color; }
But in ng2-materialzie it does not work :(

You have to use ::ng-deep to override the input component style.
You can have more details at this page : https://angular.io/guide/component-styles#deprecated-deep--and-ng-deep

It works on unfocused inputs, but when I focus input it does not work and still same default color
`
$primary-color: #ff5722;
::ng-deep .tabs .indicator
{
background-color: $primary-color;
}
::ng-deep .input-field label
{
color: $primary-color;
}
::ng-deep .input-field input[type=text]:focus + ::ng-deep label
{
color: $primary-color;
}
::ng-deep .input-field input[type=text]:focus
{
border-bottom: 1px solid $primary-color;
box-shadow: 0 1px 0 0 $primary-color;
}
::ng-deep .input-field input[type=password]:focus + ::ng-deep  label
{
color: #ff5722;
}
::ng-deep .input-field input[type=password]:focus
{
border-bottom: 1px solid $primary-color;
box-shadow: 0 1px 0 0 $primary-color;
}
`

Can you make a StackBlitz example ?
https://stackblitz.com/edit/ngx-materialize
I will be easier to help you.

@scote here is my StackBlitz https://stackblitz.com/edit/ngx-materialize-epmy8o?file=app%2Fapp.component.scss

Add a class on your input-container tag and add the class name to your scss before each selector. This should fix your problem.

Tank yoy very much :)


How does the [Feature Request] dialog component and the message-box component operate in the vuex?

Existing Component
是
Component Name
dialog、message-box
Description
dialog组件和message-box组件如何在vuex中操作关闭？

I am also figuring this out. I want to open the dialog using state in vuex because the dialog will be used (triggered) by many different button components. I have made an example and understand the open and close events on the dialog, but how to open it from state in the store?

Listening for @open & @close events are not necessarily needed when using a setter for the computed state in vuex like so:
// in the store
const state = {
  modalOpen: false
}

const mutations = {
  UPDATE_MODAL(state, value) {
    state.modalOpen = value
  }
}

const actions = {
  updateModal({ commit }, value) {
    commit('UPDATE_MODAL', value)
  }
}

const getters = {
  getModal: state => {
    return state.modalOpen
  }
}

// in component with modal
computed: {
  modal: {
    get() {
      return this.$store.getters.getModal
    },
    set(value) {
      this.$store.dispatch('updateModal', value)
    }
  }
}

// in template
<el-dialog :visible.sync="modal">

@rugor Click 'Open from store` no response.

For you @fengyun2


Redirect to not found page, when no app is found.

Description of problem, that is solved in this PR is in #187 .
In few words, last part of url in app details https://www.flathub.org/apps/details/org.inkscape.Inkscape is parameter, that is taken to request for app details data. If it is not found on backend side, 200 OK is returned with empty response body. That resulted with empty white page, that is unfriendly.

If you have better idea for not-found page, feel free to suggest it in comments, I just don't wanted it to be dry, casual 404 page ;)

Thanks for your contribution!

I might change the not-found page a little to make it less geeky when I have time


Update community links to discourse.firez.one

Should merge this after it is set up.

Thanks for updating this. I'm working fixing some CI issues and I'll get this merged once everything's ready.


getting "/app does not exist" error when trying to run image created with oci_image

hello. I'm trying to apply the rules as shown in https://github.com/aspect-build/bazel-examples/blob/main/oci_go_image/BUILD.bazel to a go repo https://github.com/a8m/ent-graphql-example and when I'm trying to run the following
$ bazel build //cmd/todo:service.tar
$ docker load --input $(bazel cquery --output=files //cmd/todo:service.tar)
$ docker run --rm gcr.io/example:latest

and I get the following:
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/app": stat /app: no such file or directory: unknown.

I'm able to run the binary just fine with bazel run //cmd/todo:app. Thanks!

I encountered the same behavior. I checked using docker cp <container name>:/ test and the binary exists.

There must be something wrong in the BUILD file which i can't tell anyhing about without seeing it.
Also, can you use dive to see if the directory actually exists?

Going to close as there's nothing for us to fix here. Feel free file another issue, if you think there's something needs fixing here.


readme in English?

Hi!
I so interested for this project, but I don't know Chinese languadge :(
Can you write the readme in English?
It would be great for whole Vue's community!
Regard, Alex.

#42

Awesome! Thanks!


Major Refactoring

Memberships Fixed, Counter Fixed, Contact Section Refactor, and footer change

Removed form and replaced with video. Works good