Polybar starts, but is blank after update

I updated yesterday Polybar to 3.4.0 and today it says it runs, but I can't see nor interact with it and the height of it is much larger, since the bottom border of my windows are pushed up.
If there are some informations I can provide, pleas say so.
Here is a preview of my desktop:

Please use the template... Without any information we can't figure what's going on. We need the log, launch polybar in a terminal with: -l trace.

What WM are you using?

What WM are you using?

I'm using the i3-gaps WM

Does this happen with any config or just with your particular one?
Maybe try the following minimal setup:
[bar/example]
modules-left = text

[module/text]
type = custom/text
content = Filler

Does this happen with any config or just with your particular one?
Maybe try the following minimal setup:
[bar/example]
modules-left = text

[module/text]
type = custom/text
content = Filler

This produced a bar at the top like here:

But I am not sure how to debug my config.
The new update must have changed something.

Please post your config. So it was definitely working in version 3.3.1?

Please post your config. So it was definitely working in version 3.3.1?

After some more thinkering I found out what is causing this.
I wanted to make my bar kinda centered and floating, so I used a transparent border around it with the following setup:
border-color = ${color.trans}
border-left-size = 	        100%
border-right-size = 	        100%
border-bottom-size = 	10%
border-top-size = 	        5%

But the values of the percentages have been changed because of the polybar update or because something else updated which also has an influence on it.
I will just have to work a bit more now on finding a sweet spot for it, so it looks like it used to.

Before 3.4.0, having a percentage for your border sizes was not allowed. Polybar would have just treated it as a number (100pixels for the left and right borders in this case). So you should use smaller percentages or directly use pixel values.


feat: improve InfoPanel

closes https://github.com/zakodium-oss/react-science/issues/710

@lpatiny is this ok? Seems not great that the panel does not reveal its content when opened, because it is not at the right scroll position.
https://github.com/zakodium-oss/react-science/assets/4118690/c4bad4e5-f06f-4d8e-9e55-fc5b729d29b9

I think there should be I lay one sticky header and they should not accumulate

Indeed I didn't test with 2 sections and it is very confusing currently. I was not thinking that the title of the section were not scrolling but only that it does not scroll behind the search bar. On the other hand seeing in which section you are is an added value as well.
I agree with Michael that we should not accumulate the sticky header because it does not bring anything and it yields to the issue Daniel pointed out.


EID-942 - Create GOV.UK sign-in interstitial page for Check your State Pension

Create service sign in page for Check your State Pension, to make
the introduction to eIDAS option easier
Include option on the sign in page so user can select to confirm
their identiy with another european country. For now until eIDAS is enabled
on verify, this will take them to the usual verify sign in page.
Radio button grouping for the sign in page is situated within the choose_sign_in_presenter.rb
within the government-frontend repo. Where the last option in the order will be after the or.
For now, this will not be linked to the current check-state-pension start page.

The current start button uses the cross-domain tracking stuff powered by the data-tracking-code and data-tracking-name attributes:
Start now

I imagine you want to keep this?

Yes, they want Google Analytics data on these pages. Would that require any additions here? We will need to carry out tests on these pages before it is connected to the service page.

I think so, but I'm not sure exactly what the change needs to be: https://govuk-publishing-components.herokuapp.com/component-guide/button/with_data_attributes

Who would be best to speak to about this?

I assume the other services user service_sign_in pages use GA to monitor, but can't spot anything distinct in there.

Maybe ask in #frontend


SimpleLinkingKey not found when used in spring boot starter.

I'm building a Spring boot starter including spring-lnurl-auth-starter.
In my spring boot starter tests, I can do this:
LinkingKey linkingKeyTest1 = SimpleLinkingKey.fromHex("02c3b844b8104f0c1b15c507774c9ba7fc609f58f343b9b149122e944dd20c9362");`

In my spring boot starter code, I can't do the same thing:
LinkingKey linkingKeyTest1 = SimpleLinkingKey.fromHex("02c3b844b8104f0c1b15c507774c9ba7fc609f58f343b9b149122e944dd20c9362");`

because I get this error: java: package org.tbk.lnurl.simple.auth does not exist
I'm forced to add this to my POM:
<dependency>
   <groupId>io.github.theborakompanioni</groupId>
   <artifactId>lnurl-simple</artifactId>
   <version>0.11.0</version>
</dependency>

This is done intentionally. The idea is that the "simple" packages are just the most basic implementation of the functionality. If you really want to use them, you should declare them as dependency explicitly.
At least that's the concept... do you think it's a bad idea?

Nope, i just wanted to be sure it was intentional because it's not described in the tutorial :)
In fact, what I find strange is that you asl for to implement this method:
Optional<LinkingKey> findPairedLinkingKeyByK1(K1 k1);

And without SimpleLinkingKey, I don't know how to return a LinkingKey.
I add this step to the tutorial
Thx for the release :)

Nope, i just wanted to be sure it was intentional because it's not described in the tutorial :)
In fact, what I find strange is that you ask for LinkingKey to implement this method:
Optional<LinkingKey> findPairedLinkingKeyByK1(K1 k1);

And without SimpleLinkingKey, I don't know how to return a LinkingKey.
I add this step to the tutorial Thx for the release :)

Hmm.. that's true. I mean.. you do not really need access to SimpleLinkingKey if you use the in-built default InMemoryLnurlAuthPairingService.. and "enterprise" apps would probably provide their own implementations. However.. I'd see a value in adding it when you use the spring-lnurl-auth-starter (and hence, opting into "automagic" setup).
Would you say it is sufficient to add it to the starter module only (not the spring-lnurl-auth-autoconfigure module)?

Nope, i just wanted to be sure it was intentional because it's not described in the tutorial :)
In fact, what I find strange is that you ask for LinkingKey to implement this method:
Optional<LinkingKey> findPairedLinkingKeyByK1(K1 k1);

And without SimpleLinkingKey, I don't know how to return a LinkingKey.
I add this step to the tutorial Thx for the release :)

Hmm.. that's true. I mean.. you do not really need access to SimpleLinkingKey if you use the in-built default InMemoryLnurlAuthPairingService.. and "enterprise" apps would probably provide their own implementations. However.. I do see a value in adding it when you use the spring-lnurl-auth-starter (and hence, opting into "automagic" setup). Would you say it is sufficient to add it to the starter module only (not the spring-lnurl-auth-autoconfigure module)?

Sorry, i'm not yet capable to replay, i first need to understand more :D
I know I have to implement Optional<LinkingKey> findPairedLinkingKeyByK1(K1 k1);  from LnurlAuthPairingService but I don't understand yet what calls this method and why.
With my understanding (partial for the moment), your framework needs a cache manager to store the k1 proposed for logins, then, when the wallet will reply with the k1 signed and the public key, you will do the verification by calling the pairK1WithLinkingKey() I implemented.
pairK1WithLinkingKey() returns true if user has been created or found (i guess).
It's all I could guess for the moment, so I did not understand when and why Optional<LinkingKey> findPairedLinkingKeyByK1(K1 k1);  is called :)

I think I can image where the missing link is.
It might also be that the current approach is a bit weak, but stay with me.
The LnurlAuthPairingService is the class that brings the wallet and the web session together.
There are two filters with respective AuthenticationProvider:

LnurlAuthWalletAuthenticationProvider invoked by the WALLET which calls pairK1WithLinkingKey
LnurlAuthSessionAuthenticationProvider invoked by BROWSER (e.g. by polling) which calls findPairedLinkingKeyByK1

After that - an attempt is made to receive a user (in AbstractTokenAuthenticationProvider which both provider inherit from) via userDetailsService.loadUserByUsername(<linking_key_in_hex>).
I hope that clarifies the current approach.
What I am wondering now, if this can be simplified by defining LnurlAuthPairingService in the following way:
public interface LnurlAuthPairingService {

    UserDetails markUserWithLinkingKeyAndK1(LinkingKey linkingKey, K1 k1); // called by wallet flow

    Optional<UserDetails> findPairedUserByK1(K1 k1); // called by web session flow
}

I have not thought this through entirely. It will tightly couple the Pairing Service to UserDetails.. not sure if this is good, but it definitely looks easier for downstream users.

Thanks !
 UserDetails markUserWithLinkingKeyAndK1(LinkingKey linkingKey, K1 k1); will make lots of sense !

With the latest changes in #117 and the introduction of LnurlAuthUserPairingService, importing lnurl-simple should not be strictly necessary anymore.

I think it's not necessary anymore
But as I need to build my own k1Manager, I'm forced to import lnurl-simple.
But I don't think it's a bug, I think you can close this issue.

I think it's not necessary anymore But as I need to build my own k1Manager, I'm forced to import lnurl-simple. But I don't think it's a bug, I think you can close this issue.

lnurl-simple is now imported in spring-lnurl-auth-starter with 9430e5a040b5a8bddf2b9d32b34da6a37627ff87.


⚠ Bofrost.at has degraded performance

In c63b796, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2235 ms

Resolved: Bofrost.at performance has improved in ebe448c after 17 minutes.


Feature: synth init

Required Functionality
Currently synth init will initialise the current directory. This is means that to get started you need to:
$ mkdir workspace && cd workspace && synth init

It would be much cleaner to optionally pass a directory
$ synth init workspace

Synth should then build this directory and initialise the workspace.
Proposed Solution
The required changes should be local to CliArgs structopt enum and the init function in synth/src/cli/mod.rs.

Closed by #47 .
@all-contributors please add @baile320 for code and docs.
@baile320 thank you very much. Much appreciated.


Context not bound on OSX 10.10.3

Is there a reason that makeCurrent does not actually make current on OSX with the NULL swapchain? I have to patch like the below in order to run - the demos run properly with this mod, and not at all otherwise. The reason it doesn't run is that there is no GL context bound when rendering starts, and the GL dispatch table is therefore uninitialized. RenderContextGL::submit calls m_glctx.makeCurrent(NULL), but the implementation does nothing. The patch ensures that a context is bound and fixes all the crashes I see. This is on 10.10.3.
diff --git a/src/glcontext_nsgl.mm b/src/glcontext_nsgl.mm
index d39f7da..c10b3ad 100644
--- a/src/glcontext_nsgl.mm
+++ b/src/glcontext_nsgl.mm
@@ -176,6 +176,8 @@ namespace bgfx { namespace gl
{
if (NULL == _swapChain)
{

  	NSOpenGLContext* glContext = (NSOpenGLContext*)m_context;

  	[glContext makeCurrentContext];
  }
  else
  {

Don't remember. Which example crashes without this fix (other than 22-windows)?

Even 01-cubes crashes without the fix. I have a clean pull with no other modifications. I assume you don't see the issue ~ I'm wondering if it's an OSX version problem, I've seen it since 10.10.1 I think.

Yeah, you can make pull request.

Cool, PR: https://github.com/bkaradzic/bgfx/pull/440


[WIP] Store data in sqlite

If we stop using IPC shared memory, the only IPC in asgi_ipc is in the semaphores, which is kinda weird, naming-wise.
While I'm on it: asgi_ipc uses assert statements all over the place. While I agree that python -O is a mostly theoretical option, I think running a protocol server like this is one of the more probable use cases for -O. Mind if I rewrite those as explicit exceptions?
All tests pass in the current state, but as I deleted the memory specific tests, I should probably add some for the sqlite part. Not really sure how to add meaningful tests for that, though.

Naming: I agree it's a bit weird, and maybe it should be renamed asgi_sqlite, but if it still uses IPC and the name is already out there I'm sort of averse to changing it without good reason.

assert: I am a Lazy Programmer and regularly use assert where I should use something a bit more serious, though in this case I'd say it fits with -O as you can turn off the extra checking after it's run for a while. Feel free to change things to real exceptions as you want.

The memory dict tests were testing that giant chunk of code you also deleted, so I think that evens out overall. I don't have a problem with the conformance suite being all this runs - it's supposed to be comprehensive!

Yeah sure, no need to change the name without need, I just wanted to mention it in case it was important to you.
Reasonable point about the assertions, I'll just be lazy here too.
The build was failing because of type annotations … didn't even notice those. Now it's breaking in Python 2 due to some byte/string fuckup, I'll look into this later today.

The prefix is back to being included in db names and semaphore.
The only remaining issue was a string/unicode compatibility issue - I solved it by checking version_info and using decode where appropriate in one place, but if you'd prefer, I could also go look for the appropriate six method …

Yeah, the pattern I've used elsewhere is if isinstance(value, six.binary_type): for that sort of check, so it would be great if you could switch that over.
Otherwise, I'm very happy with this, and if you think it's ready to merge over I'm happy to do so. If you have spare time and a love for nasty testing environments, you could try benchmarking both the old and new versions, but I can do that later on - and besides, the code simplification alone here makes me much happier.

If you have spare time and a love for nasty testing environments

Neither, really, but for the sake of a clean conscience I'd like to test this for a bit next week. I'll ping you when I'm done.

Haha, alright. I'll try to give it a test drive too.

@rixx did you get a chance to play around with this? I'm going to sit down tomorrow, check, and merge it, just wanted to see if you had.

Nope, I haven't, sorry, been terribly busy. Rebased against master just now.

Just tested it out, looks like there's some thread safety issues, but I'll merge it in and address those in the master branch!

Ooookay, hopefully it's not too bad. 🙈

Nah, nothing worse than what I had to deal with before with shared memory and threading. I'm pushing the commits up to the master branch now as I fix it - almost there!

Will semaphores be needed still, since SQLite can operate in serialized mode (effectively using semaphores itself then)? I too find it odd to move the IPC project to use a database. I think enough improvements can be made to make actual IPC work sufficiently well, and then asgi_sqlite would be a welcome alternative. If we turn asgi_ipc into asgi_sqlite without changing the name, eventually some asgi_real_ipc will come along.

@thijsvandien I've since moved back from this to a different approach to shared memory as SQLite's locking was failing badly on some platforms, so I guess what you asked for happened already.


chore(avm): separate some fixed tables

An experiment in separating fixed tables and (for now mannually)
creating a merge_into function to merge them into the main trace.
TODO:

Avoid having to create dummy relations
autogen merge_into
apply concept to other non-fixed tables

#7163  👈
master

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @fcarreiro and the rest of your teammates on  Graphite

Benchmark results
Metrics with a significant change:

avm_simulation_time_ms (Token:transfer_public): 52.3 (+68%)
protocol_circuit_witness_generation_time_in_ms (private-kernel-inner): 1,096 (+18%)
protocol_circuit_witness_generation_time_in_ms (private-kernel-tail-to-public): 6,884 (-18%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Proof generation
Each column represents the number of threads used in proof generation.

Metric
1 threads
4 threads
16 threads
32 threads
64 threads

proof_construction_time_sha256_30_ms
11,695 (+1%)
3,171
1,436 (+2%)
1,435
1,466

proof_construction_time_sha256_100_ms
44,696 (-3%)
11,724 (-6%)
5,448 (-7%)
5,370 (-7%)
5,382 (-5%)

proof_construction_time_poseidon_hash_ms
78.0 (-1%)
34.0
34.0
57.0 (-2%)
87.0 (-1%)

proof_construction_time_poseidon_hash_30_ms
1,513 (-1%)
415 (-2%)
200 (-2%)
222
266 (-1%)

proof_construction_time_poseidon_hash_100_ms
5,721 (-2%)
1,576 (-1%)
727 (-1%)
787 (+1%)
795 (-1%)

L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
4 txs
8 txs
16 txs

l1_rollup_calldata_size_in_bytes
1,412
1,412
1,412

l1_rollup_calldata_gas
9,464
9,468
9,476

l1_rollup_execution_gas
610,285
610,289
610,297

l2_block_processing_time_in_ms
758 (+1%)
1,415
2,699

l2_block_building_time_in_ms
25,671
51,756 (+1%)
100,679

l2_block_rollup_simulation_time_in_ms
25,574
51,465 (+1%)
100,324

l2_block_public_tx_process_time_in_ms
21,936
47,649 (+1%)
96,535

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 8 txs.

Metric
3 blocks
5 blocks

node_history_sync_time_in_ms
7,019 (+1%)
9,918 (+1%)

node_database_size_in_bytes
12,169,296
16,085,072

pxe_database_size_in_bytes
16,254
26,813

Circuits stats
Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Function
time_ms
bytecode_size_in_bytes

GasToken:_increase_public_balance
65.7 (-9%)
13,873

GasToken:set_portal
17.1 (+2%)
3,495

Token:constructor
91.1 (+1%)
24,207

FPC:constructor
61.0 (-2%)
13,893

GasToken:mint_public
51.9 (+1%)
10,241

Token:mint_public
61.1 (-22%)
19,216

Token:assert_minter_and_mint
214 (-1%)
13,034

AuthRegistry:set_authorized
32.7 (+3%)
7,869

FPC:prepare_fee
177 (-6%)
15,187

Token:transfer_public
:warning: 52.3 (+68%)
31,425

FPC:pay_refund
123 (+6%)
20,080

Benchmarking:increment_balance
2,720 (+1%)
15,465

Token:_increase_public_balance
55.6 (-23%)
15,089

FPC:pay_refund_with_shielded_rebate
147 (-10%)
21,167

Public DB Access
Time to access various public DBs.

Function
time_ms

get-nullifier-index
0.152 (-3%)

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
256 leaves
512 leaves
1024 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.3
16.6
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.8
31.7
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.597
0.511
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
48.1
77.6 (+2%)
136 (+4%)
245
467

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
95.9
159
287
543
1,055

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.491
0.477 (+2%)
0.467 (+4%)
0.444
0.438

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
59.3
113
183
353
690

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
109
207
355
691
1,363

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.501
0.505
0.483
0.478
0.475

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
72.7
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
133
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
0.518
N/A
N/A
N/A
N/A

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
85,672
670,983

Transaction size based on fee payment method
| Metric |  |
| - |  |


UI element positioning bug updating TargetCamera on cursor transition between Viewports in multi-camera setup

Bevy version
0.13
What you did
From trying to upgrade bevy_mod_picking to support bevy 0.13 I noticed some odd behavior when using multiple active cameras and updating the TargetCamera for some text that follows the cursor.
clean room example: https://github.com/StrikeForceZero/bevy-cleanroom/blob/example/multi_camera_target_camera_update/src/main.rs
What went wrong

what were you expecting?

The text to continue follow the cursor after changing TargetCamera when entering a new viewport

what actually happened?

The text gets stuck at an arbitrary location and stops updating until moving back into the other viewport
Additional information
The workaround I have proposed in that PR for now is just maintaining a UI node for each camera and toggling their visibility when the cursor enters or leaves the viewport.
See this comment for observation details
Here is a video show casing the cleanroom example. 2 cameras split vertically.
https://github.com/bevyengine/bevy/assets/983413/6e7e5978-0a36-49fd-85b8-6822d14a20d7

Poking at the engine source it might be related to somewhere near here https://github.com/bevyengine/bevy/blob/dedf66f72bd8659b744e12b341a7f8de4ed8ba17/crates/bevy_ui/src/layout/mod.rs#L420-L420
Logging absolute_location I can see it update normally as I move the mouse cursor around. Once I back to the side that it breaks for the value stops updating until I move back to the other viewport.

This partially fixes it, but at the cost of incrementing the taffy ids each time the TargetCamera is updated.
Index: crates/bevy_ui/src/layout/mod.rs
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/crates/bevy_ui/src/layout/mod.rs b/crates/bevy_ui/src/layout/mod.rs
--- a/crates/bevy_ui/src/layout/mod.rs	(revision HEAD)
+++ b/crates/bevy_ui/src/layout/mod.rs	(revision Staged)
@@ -370,8 +370,13 @@
     ui_surface.remove_entities(removed_nodes.read());

     // update camera children
-    for (camera_id, CameraLayoutInfo { root_nodes, .. }) in &camera_layout_info {
-        ui_surface.set_camera_children(*camera_id, root_nodes.iter().cloned());
+    for (camera_id, _) in cameras.iter() {
+        let root_nodes = if let Some(CameraLayoutInfo { root_nodes, .. }) = camera_layout_info.get(&camera_id) {
+            root_nodes.iter().cloned()
+        } else {
+            [].iter().cloned()
+        };
+        ui_surface.set_camera_children(camera_id, root_nodes);
     }

     // update and remove children

Ok, I think this fixes it without extraneously incrementing the taffy ids. Not sure if there's any consequences to having the camera taffy nodes living on root of the tree along with the UI nodes, but for my clean room example it works. I'm gonna try to figure out how to run the tests and if they pass I'll make a PR.
Index: crates/bevy_ui/src/layout/mod.rs
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/crates/bevy_ui/src/layout/mod.rs b/crates/bevy_ui/src/layout/mod.rs
--- a/crates/bevy_ui/src/layout/mod.rs	(revision HEAD)
+++ b/crates/bevy_ui/src/layout/mod.rs	(revision Staged)
@@ -167,6 +167,7 @@
             ..default()
         };

+        let camera_node = *self.entity_to_taffy.entry(camera_id).or_insert(self.taffy.new_leaf(viewport_style.clone()).unwrap());
         let existing_roots = self.camera_roots.entry(camera_id).or_default();
         let mut new_roots = Vec::new();
         for entity in children {
@@ -181,24 +182,16 @@
                         self.taffy.remove_child(previous_parent, node).unwrap();
                     }

+                    self.taffy.add_child(camera_node, node).unwrap();
+
                     RootNodePair {
-                        implicit_viewport_node: self
-                            .taffy
-                            .new_with_children(viewport_style.clone(), &[node])
-                            .unwrap(),
+                        implicit_viewport_node: camera_node,
                         user_root_node: node,
                     }
                 });
             new_roots.push(root_node);
         }

-        // Cleanup the implicit root nodes of any user root nodes that have been removed
-        for old_root in existing_roots {
-            if !new_roots.contains(old_root) {
-                self.taffy.remove(old_root.implicit_viewport_node).unwrap();
-            }
-        }
-
         self.camera_roots.insert(camera_id, new_roots);
     }

@@ -370,8 +363,13 @@
     ui_surface.remove_entities(removed_nodes.read());

     // update camera children
-    for (camera_id, CameraLayoutInfo { root_nodes, .. }) in &camera_layout_info {
-        ui_surface.set_camera_children(*camera_id, root_nodes.iter().cloned());
+    for (camera_id, _) in cameras.iter() {
+        let root_nodes = if let Some(CameraLayoutInfo { root_nodes, .. }) = camera_layout_info.get(&camera_id) {
+            root_nodes.iter().cloned()
+        } else {
+            [].iter().cloned()
+        };
+        ui_surface.set_camera_children(camera_id, root_nodes);
     }

     // update and remove children

Please ping me on the PR: I'm keen to get this fixed.

Ok, I think this fixes it without extraneously incrementing the taffy ids.

@StrikeForceZero Hmm... this seems to be creating one "implicit viewport node" per camera (viewport) rather than one for each direct child of the camera (viewport). I think this will break the case when there are multiple ui trees as children of a camera which are currently laid out independently (but I think the proposed patch will cause them to be laid out in a grid).

Negative test here: https://github.com/bevyengine/bevy/pull/12268/commits/76426f6772a33c46b718b95f8d9651fdffde3413

Please ping me on the PR: I'm keen to get this fixed.

@alice-i-cecile I've created a draft PR https://github.com/bevyengine/bevy/pull/12268 . It does fail a couple of tests that expect only UI nodes to exist in the UiSurface.entity_to_taffy hash. Gonna circle back after dinner.

Ok, I think this fixes it without extraneously incrementing the taffy ids.

@StrikeForceZero Hmm... this seems to be creating one "implicit viewport node" per camera (viewport) rather than one for each direct child of the camera (viewport). I think this will break the case when there are multiple ui trees as children of a camera which are currently laid out independently (but I think the proposed patch will cause them to be laid out in a grid).

I was concerned that stuffing those nodes in the root of taffy might have consequences. What is the ideal way to test this?

Ok, I think this fixes it without extraneously incrementing the taffy ids.

@StrikeForceZero Hmm... this seems to be creating one "implicit viewport node" per camera (viewport) rather than one for each direct child of the camera (viewport). I think this will break the case when there are multiple ui trees as children of a camera which are currently laid out independently (but I think the proposed patch will cause them to be laid out in a grid).

Unless I'm not understanding, it appears to have no visible effect on the root child nodes.
Below is an example of two text nodes height and width set to 100%, taking up the entire viewport.

    commands.spawn((
            TextBundle {
                text: Text::from_section("hello world static", TextStyle { ..default() }),
                style: Style {
                    width: Val::Percent(100.),
                    height: Val::Percent(100.),
                    ..default()
                },
                background_color: Color::srgb(1., 0., 0.).into(),
                ..default()
            },
            TargetCamera(left_camera_entity),
        ));

    commands.spawn((
        TextBundle {
            text: Text::from_section("hello world static", TextStyle { ..default() }),
            style: Style {
                width: Val::Percent(100.),
                height: Val::Percent(100.),
                ..default()
            },
            background_color: Color::srgb(0., 0., 1.).into(),
            ..default()
        },
        TargetCamera(right_camera_entity),
    ));

and here's one with children on one side

    commands.spawn((
            TextBundle {
                text: Text::from_section("hello world static", TextStyle { ..default() }),
                style: Style {
                    display: Display::Flex,
                    width: Val::Percent(100.),
                    height: Val::Percent(100.),
                    ..default()
                },
                background_color: Color::srgb(1., 0., 0.).into(),
                ..default()
            },
            TargetCamera(left_camera_entity),
        ));

    commands.spawn((
        NodeBundle {
            style: Style {
                display: Display::Flex,
                flex_direction: FlexDirection::Column,
                width: Val::Percent(100.),
                height: Val::Percent(100.),
                ..default()
            },
            background_color: Color::srgb(0.5, 0.5, 0.5).into(),
            ..default()
        },
        TargetCamera(right_camera_entity),
    )).with_children(|children| {
        children.spawn((
            TextBundle {
                text: Text::from_section("b", TextStyle { ..default() }),
                style: Style {
                    display: Display::Flex,
                    height: Val::Percent(50.),
                    ..default()
                },
                background_color: Color::srgb(0., 0., 1.).into(),
                ..default()
            },
        ));
        children.spawn((
            TextBundle {
                text: Text::from_section("a", TextStyle { ..default() }),
                style: Style {
                    display: Display::Flex,
                    height: Val::Percent(50.),
                    ..default()
                },
                background_color: Color::srgb(0., 1., 0.).into(),
                ..default()
            },
        ));
    });

@alice-i-cecile  PR is no longer in draft and ready for review.

Hmm... prior to the target camera changes it was possible to spawn multiple NodeBundle's at the root level of the viewport. I had thought this was still possible, but if you have to put the TargetCamera entity on the ui root node then I guess not. I had assumed that TargetCamera would get set on the parent of each ui root


[ISSUE #6668] Fix error unlocking issue during interruption

fix #6668

What does IMO mean？
Should I restore the interrupt state when an interrupt occurs？


rm extension

make it look like a typical license file without extension

Any particular reason, or just for consistency?


expectRevert ergonomics

We should have two more expectRevert signatures:

expectRevert(bytes4) so you can do e.g. expectRevert(Contract.CustomError.selector)
expectRevert(string) so you can do e.g. expectRevert("foo")

Currently you can achieve both of these but it requires casting and/or abi.encodeWithSelector

FYI @brockelmore

Not sure what the plan is for forge-std but this could technically be implemented in "userland" as a wrapper around the already existing expectRevert

Errors dont have selectors i dont believe. They are second class functions :(

i literally tried this when i was implementing expectRevert lmao i must have messed it up

:thinking: weird it works now at least. i haven't been able to get it to work with some parameters to the errors though, like strings. seems like they are encoded slightly differently even though the solidity docs say errors are encoded in exactly the same way as a function with some calldata


Enable read-only scenarios

There are times when you don't want to register a service / instance with Eureka, but only want to discover other registered apps (i.e. read-only).
Currently, this module requires passing in an instance object with certain values set; however, I think it would be desirable to pass in an option like registerInstance: false that then makes the instance object optional as part of constructing a Eureka client.

I think my question would be if you still want the client to refresh the registry on interval or if you want to call fetchRegistry(callback) yourself. It seems like it might be useful to still be able to call start() and have the client keep the registry up to date, but make the register() call be a no-op.

Yes, I agree. Calling start() should still be a thing and the registry should fetch by default per usual, unless explicitly disabled.

Hi jquatier,
any update on this? I am in the same situation as @mhamann  where I don't want to register each client ui that needs access to the registry.

@trinakria PR is in flight for this.


build(datasets): Bump s3fs

Description
Different approach to #348 to bump s3fs, to solve failing tests in:

https://github.com/kedro-org/kedro-plugins/pull/348
https://github.com/kedro-org/kedro-plugins/pull/458

The problem that surfaced in #348 is described here: https://github.com/aio-libs/aiobotocore/issues/755 Lots of people have provided patches, so I have used one of the most up to date ones and it seems to work almost perfectly.
Development notes
Tests that are still broken and have been commented out for the time being:

tests/dask/test_parquet_dataset.py test_pass_credentials
tests/spark/test_spark_dataset.py test_no_version

See https://github.com/kedro-org/kedro-plugins/pull/459 for some more things I tried to get these tests passing. We just need to change the way the mocking is done in these, but I'm out of ideas at the moment. Probably won't be too hard to fix with a fresh pair of eyes.
Checklist

[ ] Opened this PR as a 'Draft Pull Request' if it is work-in-progress
[ ] Updated the documentation to reflect the code changes
[ ] Added a description of this change in the relevant RELEASE.md file
[ ] Added tests to cover my changes

Thanks @merelcht for picking it up and fixing the failing tests! This approach is cleaner than what I initially thought it would.
I still believe my approach (with moto in server mode) could work, but I wasn't able to figure out why it didn't. The s3fs package is using it for their tests, so if I have time, I will look into their approach to see what they do differently than what I had.


ImportError: cannot import name Keras

Traceback (most recent call last):
  File "test_multi_label_baselines.py", line 7, in <module>
    from skmultilearn.ext import Keras
ImportError: cannot import name Keras

Why?

Hi, can you give more information about the version you are using?

@Jopepato
python 2.7.5
scikit-multilearn  0.2.0


183249829 Unit Conversion Issues

This PR attempts to tackle multiple issues with units and conversion between them.

Remove many built-in units.
Improve infrastructure for adding custom units, including the ability to add built-in units.
Give each variable its own math library, which refresh whenever custom units are added.

Additional hodgepodge upgrades:

Stop considering unit messages errors, to avoid the unit canceling message.
Stop shifting expandable input content to left.

looks like you were adding those tests just as I was reviewing it. :)


Jupiter Code runs only once

Right after launching the code runs OK and that is all.
All subsequent attempts gives attached messages until next total relaunch.

look this https://wiki.sipeed.com/soft/maixpy3/zh/tools/MaixPy3_IDE.html or https://wiki.sipeed.com/soft/maixpy3/zh/tools/0.MaixII-Dock.html

Use the latest version


Fix shared/_form_name_feedback.html.erb

Was passing the wrong arg for form
Fixes a bug reported by Excited Delirium

Coverage: 93.578%. Remained the same when pulling<PHONE_NUMBER>ac3fa2aac5b7436e0e7f1072288738 on nimmo-fix-form-name-feedback into 8b0189f093f6345c5f5512e6f21496efd762b283 on main.


Docker resize volume

Summary
I using rexray, docker plugin rexray/scaleio and mesos/marathon to deploy apps. But a can't resize volume docker container. For example:
Step1: default, I configure size : 100GB
root@mesos-192-168-6-113:/home/manhnv# docker run -itd --volume-driver=rexray -v test:/tmp nginx
2d71c3eae38f710acdd21b65aac536653551daee777cda2dab54ea3a99b71805
root@mesos-192-168-6-113:/home/manhnv# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 894.3G  0 disk
├─sda1   8:1    0   976M  0 part /boot
├─sda2   8:2    0     1K  0 part
├─sda5   8:5    0  29.8G  0 part [SWAP]
└─sda6   8:6    0 863.5G  0 part /
sdb      8:16   0 894.3G  0 disk
└─sdb1   8:17   0 894.3G  0 part /data
sdc      8:32   0 894.3G  0 disk
└─sdc1   8:33   0 894.3G  0 part /data1
scinia 251:0    0   104G  0 disk /var/lib/libstorage/volumes/test

Step2: Stop container (100gb), and resize volume by ScaleIO GUI, 100gb --->200GB
Step3: Restart container
Step4: Checking "lsblk"
root@mesos-192-168-6-113:/home/manhnv# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 894.3G  0 disk
├─sda1   8:1    0   976M  0 part /boot
├─sda2   8:2    0     1K  0 part
├─sda5   8:5    0  29.8G  0 part [SWAP]
└─sda6   8:6    0 863.5G  0 part /
sdb      8:16   0 894.3G  0 disk
└─sdb1   8:17   0 894.3G  0 part /data
sdc      8:32   0 894.3G  0 disk
└─sdc1   8:33   0 894.3G  0 part /data1
scinia 251:0    0   200G  0 disk /var/lib/libstorage/volumes/test

But container check 'df -h ':
root@mesos-192-168-6-113:/home/manhnv# docker exec -it 2d71c3eae38f bash
root@2d71c3eae38f:/# df -h
Filesystem                                              Size  Used Avail Use% Mounted on
none                                                    850G   68G  739G   9% /
tmpfs                                                    48G     0   48G   0% /dev
tmpfs                                                    48G     0   48G   0% /sys/fs/cgroup
/dev/scinia                                             103G   60M   97G   1% /tmp

I wanna /dev/scinia has 200gb

@tumanh i've gone ahead and cleaned up the markdown formatting for your request.
Today, REX-Ray doesn't have the feature to extend/expand disk partitions. Your process is correct, but you will have to go into the container and issue the commands necessary for your container to resize it based upon the OS used in your container image.
please close this issue if this answered your question

@tumanh There are multiple expansions that need to take place. A df looks at the space as reported by a filesystem. A lsblk looks at the raw block device size. So you have a raw block device that has grown and is recognized, but you have not grown the filesystem.
Assuming it's ext4, run resize2fs /dev/scsinia followed by e2fsck /dev/scinia.

@clintonskitson Thank but  I try
`e2fsck /dev/scinia
e2fsck 1.43.4 (31-Jan-2017)
/dev/scinia is mounted.
WARNING!!!  The filesystem is mounted.   If you continue you WILL
cause SEVERE filesystem damage.
Do you really want to continue? yes
e2fsck: No such file or directory while trying to open /dev/scinia
Possibly non-existent device?
`
and try
'root@2d71c3eae38f:/# resize2fs /dev/scsinia 200gb
resize2fs 1.43.4 (31-Jan-2017)
open: No such file or directory while opening /dev/scsinia'

@kacole2  Thank you !! I Next time I will write more clearly

Ok, a couple of basic things.. 1) Make sure the filesystem is not mounted 2) Make sure the device is actually attached. You can use the rexray attach command to just make the device present. From there the commands specified should work if you are using the path that gets returned from REX-Ray.

Going to close this for now. Feel free to re-open if more guidance is needed.

@codenrhoden i have the same issue


list of all available events for xbox.on()

I'm having a hard time to understand all the events that are available for xbox.on(). There are, obviously, those listed in the Readme (like lefttrigger or right:move), but I also saw rightshoulder:release used by xbox-parrot.
I've yet to find a complete list of all available events and couldn't find anything helpful in the resources mentioned on top of the readme. So probably it's terribly obvious and I'm just missing it, but is there such a list anywhere?

The full list of buttons is in this file: https://github.com/andrew/node-xbox-controller/blob/master/lib/buttons.json
We should add those to the readme as well

That would be great :) Maybe that then could be referenced to a graphic like that, so everyone knows what's what.

FYI, I added all (I think?) to the example.js, check it out:
https://github.com/andrew/node-xbox-controller/blob/master/example.js.

Ah yes, good point @gordonturnerolson, I've linked to the example in the readme now: https://github.com/andrew/node-xbox-controller/commit/9b8340b67fec7df55e212b33590e56367e1afc61

Doh, that was my  corporate alter ego commenting there...

I'm no longer supporting this library as I don't use it any longer so I'm going to close this issue.


Signatures Not Syncing?

Hey there,
I have installed this addon through Thunderbird (not Github) and I think all the settings are correct, but nothing seems to be actually syncing. I am sure I missed a setting or something.
LinuxAndCoffee

Hey, have you tried clicking on the Sync now button in the settings? Do you see a message Last sync: xxx in settings?

Hey @kam193
So I just went back and realized I never connected the plugin to my Google account, so there was nothing to sync with. I am so sorry, not enough coffee or sleep lately. Once I did that, everything works perfectly and I cannot thank you enough for your help!
LinuxAndCoffee

No problem - I'm happy it helps you!
Have a great sleep and tasty coffee ;)


Zend_Validate_File_Count PHP 5.x compatibility

Could you please maintain also PHP 5.x compatibility as original Zend1 does?
Fix in Zend_Validate_File_Count broke compatibility, because it uses null coalescing operator available from PHP 7.0.

Patched it for you, next major release I'm about to do should be working for you


Create a Bountysource team for Apostrophe

Lately I've been really interested in the idea of getting paid to work on open-source projects. Fortunately a service called Bountysource already solves a lot of this problem. Here's how it works:

You create a Bountysource team and authorize GitHub. These become integrated.
All GitHub issues become mirrored to Bountysource where people can pay money to place a bounty on an issue they want fixed.
Developers fix the issue, verify it with the team, then get paid the bounty.

This would benefit Apostrophe by increasing its engagement with a broader community. Receiving funds for fixing issues is more enticing to developers than the satisfaction of being altruistic. Part of me is still concerned about the consequences of bringing money into free software at all; will it encourage sabotaging behavior among developers rather than collaboration? But the appeal of being able to sustain oneself with free software outweighs my skepticism. As long as money is necessary to live, we should enable its ability to be obtained. The introduction of Bountysource now means that a child with an internet connection anywhere in the world can teach themselves programming using online resources and then use their skills to accrue money with little dependency on anything else.
Anyway, let me give an example of how an issue looks on Bountysource. Here's a popular issue for OwnCloud:

As you can see, this issue has 30 backers. Quite a few different people care about this issue, so they've contributed money to up the ante in the hopes it will further entice someone to develop a solution.

Even if you don't plan to contribute money towards issues yourself, just having the Bountysource page allows other people to. So it's worth having either way, as long as someone will review the pull requests, which you are already doing. If you do want to engage the community, posting bounties on issues is a useful tool.

There's also a feature that works like a little built-in mini Patreon. People who want to support the project can contribute a monthly dollar amount, which means Apostrophe can generate a passive income to delegate towards development.
You can read the full FAQ for Bountysource here: https://github.com/bountysource/core/wiki/Frequently-Asked-Questions

Alright, we out there, looking lonely https://www.bountysource.com/teams/apostrophecms
We should maybe add this to our Community page in the marketing site redesign


Date before 1970-01-01 not possible to select

Is there a way to get around this? thanks

Try v3.2.4


sort, update bottom pins for deps

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Notes:

updates bottom pins for some deps
sort the deps

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@conda-forge-admin please rerender

@conda-forge/conda-lock ready for review :turkey:

Thanks!


Invoking non-llvm_clang compiler when building with brew LLVM OpenMP results in xcrun script failing

[x] Ran brew update and retried your prior step?
[x] Ran brew doctor, fixed as many issues as possible and retried your prior step?
[ ] Confirmed this is problem with Homebrew/brew and not specific formulae? If it's a formulae-specific problem please file this issue at https://github.com/Homebrew/homebrew-core/issues/new

I'm fairly certain this is my fault...
Normally, when llvm_clang is invoked, Cmd#tool replaces llvm_clang with the path to the clang executable installed as part of brew LLVM. However, when clang is invoked, brew replaces clang with llvm_clang, which causes the xcrun script to fail:
bash-3.2$ llvm_clang
Undefined symbols for architecture x86_64:
  "_main", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang-3.9: error: linker command failed with exit code 1 (use -v to see invocation)
bash-3.2$ clang

Failed to execute llvm_clang -isystem/usr/local/include -isystem/usr/include/libxml2 -isystem/opt/X11/include -isystem/opt/X11/include/freetype2 -isystem/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -I/usr/local/opt/tcl-tk/include -I/usr/local/opt/ncurses/include -I/tmp/brew-llvm-openmp -L/usr/local/opt/tcl-tk/lib -L/usr/local/opt/ncurses/lib -L/usr/local/lib -L/tmp/brew-llvm-openmp -L/opt/X11/lib -L/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries -Wl,-headerpad_max_install_names

Xcode and/or the CLT appear to be misconfigured. Try one or both of the following:
  xcodebuild -license
  sudo xcode-select -switch /path/to/Xcode.app

bash-3.2$

This occurs when using brew LLVM to compile fftw --with-mpi --with-openmp. ./configure tests the OpenMPI installation by invoking /usr/local/bin/mpicc, which in turn invokes clang, which causes configuration to fail with the above error.
A dirty fix would be to replace the HOMEBREW_CC environment variable with the full path to the clang executable installed as part of brew LLVM, but obviously a cleaner fix would be preferred.
Thoughts?

A dirty fix would be to replace the HOMEBREW_CC environment variable with the full path to the clang executable installed as part of brew LLVM

Not sure I understand the dirtiness here; seems ok to me?

I thought that HOMEBREW_CC wasn't supposed to be a full path, given the way Cmd#tool was written. I guess changing it wouldn't be too bad, though...

I thought that HOMEBREW_CC wasn't supposed to be a full path, given the way Cmd#tool was written.

In that case: do we just need to fix up the PATH?

That might work? Only thing that comes to mind is that the LLVM bin/ directory contains a few executables that are also in the default Xcode toolchain, and I'm not sure whether finding those first would break anything. It doesn't look too likely, though:
rp:bin awang$ unalias ls
rp:bin awang$ ls >> ~/Desktop/bin
rp:bin awang$ rm ~/Desktop/bin
rp:bin awang$ ls /usr/local/opt/llvm/bin/ >> ~/Desktop/bin
rp:bin awang$ ls /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ >> ~/Desktop/bin
rp:bin awang$ cat ~/Desktop/bin | sort | uniq -c | sort | tail -n 10
   1 yaml2obj
   2 clang
   2 clang++
   2 llvm-cov
   2 llvm-dsymutil
   2 llvm-dwarfdump
   2 llvm-nm
   2 llvm-objdump
   2 llvm-profdata
   2 llvm-size

And I'm not entirely 100% sure I'm correct about whether HOMEBREW_CC is supposed to be a full path or not...

Only thing that comes to mind is that the LLVM bin/ directory contains a few executables that are also in the default Xcode toolchain, and I'm not sure whether finding those first would break anything.

I think it's reasonable (perhaps even better) for those to be used if it's using the LLVM Clang.

That is true. I'll give that a shot then.

Pretty sure this will be fixed by https://github.com/Homebrew/brew/issues/2298 but let me know if not @aw1621107.


Create Whereami Helm chart

Still in progress...
Create and expose the public Whereami Helm chart. Adding another option to deploy Whereami if you want to use Helm.
To install Whereami via its Helm chart it's as easy as running:
helm install whereami oci://us-docker.pkg.dev/google-samples/charts/whereami \
    --version 1.2.13

Via Config Sync, you can configure your R*Syncs like this too:
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync-whereami-helm
  namespace: config-management-system
spec:
  sourceFormat: unstructured
  sourceType: helm
  helm:
    repo: oci://us-docker.pkg.dev/google-samples/charts
    chart: whereami
    version: 1.2.13
    releaseName: whereami
    auth: none

[X] Create Helm chart
[ ] Test consistency between Helm chart and Kustomize overlays's outputs
[ ] Tests in GKE cluster for both Kustomize overlays and Helm chart
[ ] Document in README.md
[ ] Publish the Helm chart in google-samples's registry
[ ] Automate the push of the Helm chart in registry

In order to have consistency between Helm chart and Kustomize overlays's outputs, I simplified a bit some namings in the plain Kubernetes manifests:

ConfigMap is not anymore suffixed by -configmap
ServiceAccount is not anymore suffixed by -ksa
Add app label for all the resources, that's what the Kustomize overlays are doing anyway, so added them in the bases k8s and k8s-grpc too.

I have done multiple tests in order to make sure there is no issues/regressions, let me know if you see anything I may have missed.

unless you want me to review while you're working through it

@theemadnes, I will give you a heads up when it's ready for your review, I have still couple of tests/work to do, almost there :)

super cool. thanks for doing this. i'm still on chat and itching to do some work before i get back to the office on the 12th.

Ready for your review @theemadnes, thanks!

need to spend some more time with this (and this won't effect non-Googlers) but there are some guides (go/mci-asm-setup that will break because they use Kustomize overlays that reference the configmap suffixes

the problem is that the guide was taken over by PSO (i think) and it's really difficult to update directly - there's a buganizer link at the top of the doc to submit edits. let's chat about best way to address, cool?

i know it's sloppy to have the configmap and ksa suffixes - do we have to remove them for now? anyways, don't have a strong opinion either way, but don't want to break stuff for folks that use the internal guides so yeah let's chat

Hi @theemadnes, yeah really good point about the breaking changes involved with the name changes: whereami-configmap, whereami-ksa, whereami-grpc-conigmap and whereami-grpc-ksa. FYI I did a Code Search internally, and they are not used in our public docs, that's a good news.
But yeah, the guide you mention is. Are they used elsewhere? That's difficult to answer and yes that could break them out there. I can contact the authors of the guide you shared to update it accordingly, but for the others that will be very difficult.
2 options:

We live with that, knowing/guessing that maybe the impact is minimal?
We don't want to guess/ we don't want any breaking change, so I find another way to keep existing and adapt the Helm chart.

I'm totally fine with 2., Helm chart are very flexible. Let me know what you want me to do :)

Hi @theemadnes, yeah really good point about the breaking changes involved with the name changes: whereami-configmap, whereami-ksa, whereami-grpc-configmap and whereami-grpc-ksa. Thanks for raising this!
FYI I did a Code Search internally, and they are not used in our public docs, that's a good news.
But yeah, the guide you mention is. Are they used elsewhere? That's difficult to answer and yes that could break them out there. I can contact the authors of the guide you shared to update it accordingly, but for the others that will be very difficult.
2 options:

We live with that, knowing/guessing that maybe the impact is minimal?
We don't want to guess/ we don't want any breaking change, so I find another way to keep existing and adapt the Helm chart.

I'm totally fine with 2., Helm charts code is very flexible (if...then...else, etc.). Let me know what you want me to do :)

i'm the author of the doc, but it's gone through all sorts of formatting that i dont control any more. but i think i like your first option. we use your changes and i make the required updates to the internal guide(s).

i'll make the updates monday and merge the changes then if that's cool - i saw some folks in the doc so i want to make sure they happen at roughly the same time.


feat: Remove deprecated methods from FeatureChecker

Closes https://github.com/denoland/deno_core/issues/901

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 81.50%. Comparing base (0c7f83e) to head (9151622).
Report is 120 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #905      +/-   ##
==========================================
+ Coverage   81.43%   81.50%   +0.06%
==========================================
  Files          97       98       +1
  Lines       23877    24788     +911
==========================================
+ Hits        19445    20203     +758
- Misses       4432     4585     +153

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Add error catch when executing pipeline deploy

Fix #433.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

You're the best! Are there tests for the error case? If not, would you mind adding them :)


BUG/PERF: Stata value labels

This PR fixes a minor bug and introduces some performance enhancements, all related to value label reading in Stata files.
The bug is that when reading a Stata file incrementally, the value labels will be read even when specifying convert_categoricals=False (this does not happen when reading the entire file at once).
The performance enhancements are:

Read key/value information as an ndarray using np.frombuffer rather than as a Python loop.

When splitting the value labels at the offsets, we currently pass txt[off[i]:] to null_terminate, which creates many copies of large segments of a potentially large byte array.  I changed it so that
only the relevant part of the string is copied.

Relating to 2, further performance improvements might be possible since there is no trailing null byte to remove except for the last element of txt (thus some of the work in _null_terminate is superfluous).
Background:  This is an issue when processing large Stata files with millions of distinct value labels.

ok, sounds gr8!.
just confirm that we have reasonable benchmarks in asv (the packers.py) file is the only one for stata.

Is there a place to put data files for ASV to read in?  The stata writer is more limited than the stata reader, so it's hard to test some features like strls that are not part of dta version 114.

you can just make a directory under the asv_benchmarks

@kshedden want to update

I added a test but haven't been able to get asv to run it.  I don't have conda so switched the asv conf file to use virtualenv.  It fails when using pip to install pytables:
Collecting pytables
  Could not find a version that satisfies the requirement pytables (from versions: )
No matching distribution found for pytables```

I'm using 3.4.2rc1 (and also switched asv conf to use python 3.4)

asv can work with pip but needs a slighty modified config file (e.g. a different one) as pip uses tables (not that conda accepts both of these).

pls add a whatsnew note (in performance). you don't necessarily need to include an asv benchmark (though nice if its easy), but post a perf comparison at the top of the issue.

Re conda vs. virtualenv, this may be of interest: https://github.com/spacetelescope/asv/issues/322#issuecomment-150848137 https://github.com/spacetelescope/asv/pull/329

@pv that's a nice feature....care to do a PR to upgrade pandas/asv.conf.json

@kshedden can you update

@kshedden can you update

Sorry for the delay... I wasn't able to test this in ASV.  I updated whatsnew, not sure what else needs to be done.

looks good
can u run flake8 on the diff and fix any issue

minor comments. pls squash. ping when green.

@jreback should be good to go

merged via https://github.com/pydata/pandas/commit/449ab6b6646812c21e859f71d4aabda2288e8ec4
thanks!


Update README_zh-CN.md

remove repeat net/http
Describe the PR
I found the net/http is repeated in Chinese version.

@tzxdtc Thanks for your contribution


Does not have a member named 'location'

Following the usage instructions for a search request in the README, I tried using the sample code in a ViewController and got the following error:
'ViewController' does not have a member named 'location'
Where am I supposed to make a search request?

Well, the code in readme is just a snippet. There is a demo project in repository. You can check out ExploreViewController.swift and see how to get a location.


Implement game rooms (frontend)

The browser side should communicate with the websockets (depends on #4) and update the page as it receives information. Game room ECR also needs to be changed to be able to show information such as players joining/submitting/quitting and game room settings.

Work has been started in gameroom.js but it doesn't do anything to update the page yet.


When using SPM PinLayoutImpl.swift generates 52 Errors

This happens because in the file we are missing
import UIKit
after
#if os(iOS) || os(tvOS)

Thanks, I'll fix that immediately

LOL I just finished and was about to submit a pull request and you beat me to it. Thanks for the super fast support.

Haha!  A new release is available (1.1.5).
Let me know if you have any comments or suggestions

will do. Thanks.


[WIP] dynamic custom operator support

Description
Enhancements to dynamic library loading to support custom operators in libraries.

Created a new example library with an operator in "example/lib_ops"
added MXTensor/MXDtype structure to lib_api.h
added similar NNVM register op-like capability for custom ops
operators are found in the library, and re-registered in MXNet during library loading
operators are re-registered from mx.nd.op to mx.nd and mx.sym.op to mx.sym shortcuts

Initially, this project was proposed on the CWiki, however the design has evolved since the initial proposal. The current design is described below.
Design
The goal of this PR to to enable operators to be implemented in separate libraries and loaded at runtime
The main constraint is to maintain a low-level C-types only boundary between MXNet and the library to simplify the building and compiling of external libraries.
Working backwards from the user, users register operators with easy-to-use function prototypes like:
int myFCompute(std::map<std::string,std::string> attrs,
               std::vector<MXTensor> inputs,
               std::vector<MXTensor> outputs);

Users' FCompute functions are called by a helper function _opCallFCompute that converts the C-types passed across the library boundary. This function is implemented in the lib_api.h header file that users compile with their library.
int _opCallFCompute(fcomp_t fcomp, const char* const* keys, const char* const* vals, int num,
                    const int64_t** inshapes, int* indims, void** indata, int* intypes, int num_in,
                    const int64_t** outshapes, int* outdims, void** outdata, int* outtypes, int num_out);

In MXNet's C API, the _opCallFCompute is found in the library. A lambda function fcomp_conv is created for each operator loaded from the library to convert from MXNet-types to C-types. Then these C-types are passed to _opCallFCompute.
auto fcomp_conv = [=](const nnvm::NodeAttrs& attrs,
                      const OpContext& ctx,
                      const std::vector<TBlob>& inputs,
                      const std::vector<OpReqType>& req,
                      const std::vector<TBlob>& outputs);

The same design is used for: parseAttrs, inferShape, and inferType.
Finally, an operator is re-registered in MXNet with the lambda function like:
nnvm::Op &regOp = dmlc::Registry<nnvm::Op>::Get()->__REGISTER_OR_GET__(name);
regOp.set_attr<FCompute>("FCompute<cpu>",fcomp_conv);

Once the C API returns back to Python in the load function in library.py, we regenerate the Python bindings and re-register the operator shortcuts to mx.nd and mx.sym.
After the load function returns back to the user's Python code, they can then use their operators just like any other operate:
mx.nd.myCustomOp(A,B,C)

Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

updated path to be absolute in example/lib_api/test.py

Comments

@wkcn while this PR is not quite done yet, it would be great to get some early feedback since the design/implementation has changed since our initial discussion. Let me know what you think, thanks!

Hi @samskalicky , is it possible to use mshadow in dynamic custom operator?
It will be convenient to leverage some math helpers.

Hi @samskalicky , is it possible to use mshadow in dynamic custom operator?
It will be convenient to leverage some math helpers.

Sure, users can compile whatever they want into their libraries. But they will compile mshadow separately from MXNet.
The main goal in architecting the custom op support is to lower the barrier for entry to compiling custom operators. Currently users have to recompile all of mxnet to integrate their custom ops. So we want to do better with this project. If users have a custom op that does not uses mshadow they shouldnt have to compile with it.

@samskalicky Nice! We can provide some higher-level language (e.g. C++) examples with mshadow.

@wkcn any thoughts on how we can modify this to re-register an operator multiple times?
https://github.com/apache/incubator-mxnet/pull/15921/files#diff-3288207540b433242fe8da1390c68d3fR423-R427
Im thinking of the scenario when a user loads multiple libraries that each have the same operator. So its possible that an operator can be re-registers over and over (obviously only the last registered one will be used). But it would suck if a user couldnt use an operator in another library if it also defined an operator they already loaded from a different library.

@samskalicky It may be helpful to define a namespace to avoid re-registering an operator multiple times. The namespace can be defined in the source code of custom operators, or when loading the library, like mx.library.load('myop.lib', namespace='mynamespace'), then  users call mx.nd.mynamespace.myop.
If the name conflict still exists, we will raise a warning or an exception.

@wkcn the problem is in NNVM, not python.
Here, we register attributes on an operator:
https://github.com/apache/incubator-mxnet/blob/711f9a364d463018395f84059edb8e2b3eabb052/src/c_api/c_api.cc#L423-L427
set_attr takes a pvalue that defaults to 10:
https://github.com/dmlc/nnvm/blob/master/include/nnvm/op.h#L237-L239
And here in the set_attr function theres a check that makes sure attributes are not re-registered with the same pvalue:
https://github.com/dmlc/nnvm/blob/master/include/nnvm/op.h#L461-L464
So my though was to just set it to 11, so that lets us re-register it once. But the 2nd time it will fail since there already is an 11.
But my question was if you had any suggestions on how to extend this so that we can re-register over and over.
The use case is the following:

Library1 has {opA, opC, opD}
Library2 has {opB, opC, opE}

Lets say the user wants to use: opA, opB, and opD. So they load both Library1 & Library2. So loading Library1 succeeds registering opC. But then loading Library2 fails since opC is already registered. In this case the user doesnt care about opC, so we are ok with opC being overwritten by the implementation in Library2.

@samskalicky I see. Could we add a prefix name to avoid name conflict?
For example,
Library1 has {opA, opC, opD}
Library2 has {opB, opC, opE}
Firstly, we load lib1. They are registered as 1_opA, 1_opC, 1_opD.
Then we load lib2, and lib2 registers 1_opB, 2_opC, 1_opE.
If we load lib2 again, they are called as 2_opB, 3_opC, 2_opE.
There is not any name conflict in nnvm.
In the front end, we can map them to some new names.
e.g.
lib1 = mx.library.load(“lib1.so”, namespace=“lib1”)
op = mx.nd.lib1.opA(...)
op2 = lib1.nd.opA(...)

Hi @rondogency , do you have any idea?

I think that hurts the ease of use to force namespacing. Plus if we internally set lib1.opA then users wont know how to call mx.nd.lib1.opA or mx.nd.lib1_opA (whatever the naming scheme is). If we give them a way to set the namespace name, its still not as easy to use as mx.nd.opA. Plus we want users to be able to override internal MXNet ops.
For example mx.nd.Convolution does not support FP16 on CPU. So if a user had a need for that they could write their own. So we need ops to be overwritten, and be in the mx.nd namespace.
Im thinking the best solution might be to track the number of times an operator is registered and just increment the pvalue for now.

Agree that users is allowed to define the namespace manually and override internal operators.
In the case you gave,
Library1 has {opA, opC, opD}
Library2 has {opB, opC, opE}

Users may want opA, opB, opE, opD, and opC in library1. They likewise choose opA, opB, opE, opD, and opC in library2.
I don't think pvalue can address the problem.

@wkcn should we consider removing the nnvm pvalue restriction that attrs can be set multiple time here:
https://github.com/dmlc/nnvm/blob/dab5ce8ab6adbf4edd8bd2fa89f1a99f343b6e38/include/nnvm/op.h#L461-L464
Or add an argument to optionally allow override, but default to current behavior?
Like this:
‘’’
inline Op& set_attr(const std::string& attr_name,  // NOLINT(*)
const ValueType& value,
int plevel = 10, bool override=false);
template
inline Op& Op::set_attr(  // NOLINT()
const std::string& attr_name,
const ValueType& value,
int plevel,
bool override) {
CHECK_GT(plevel, 0)
<< "plevel in set_attr must be greater than 0";
// update the attribute map of the key by creating new empty if needed.
UpdateAttrMap(attr_name,
[this, attr_name, value, plevel](any pmap) {
// the callback is in lockscope so is threadsafe.
if (pmap->empty()) {
OpMap pm;
pm.attr_name_ = attr_name;
*pmap = std::move(pm);
}
CHECK(pmap->type() == typeid(OpMap))
<< "Attribute " << attr_name
<< " of operator " << this->name
<< " is registered as inconsistent types"
<< " previously " << pmap->type().name()
<< " current " << typeid(OpMap).name();
std::vector<std::pair<ValueType, int> >& vec =
nnvm::get<OpMap >(*pmap).data_;
// resize the value type.
if (vec.size() <= index_) {
vec.resize(index_ + 1,
std::make_pair(ValueType(), 0));
}
std::pair<ValueType, int>& p = vec[index_];
CHECK(p.second != plevel && !override)
<< "Attribute " << attr_name
<< " of operator " << this->name
<< " is already registered with same plevel=" << plevel;
if (p.second < plevel) {
vec[index_] = std::make_pair(value, plevel);
}
});
return *this;
}
‘’’

We don't need to change the NNVM code. For multiple registration, we can use different names to register them in the back-end. Users only focus on the front-end, which uses namespace to distinguish different implementations of CustomOp.
For example, users want to register a ConvOp to override the original Convolutional Op:
mx.library.load('MyConvOp.so', override=True)
# mx.nd.Convolution will be the custom operator

If users doesn't want to override the original ConvOp,
mx.library.load('MyConvOp.so', namespace='myop')
# mx.nd.myop.Convolution is the custom operator, and mx.nd.Convolution is not overrided.

The flag override is False by default. If users don't set it True and register an operator multiple times, it will raises the exception to prompt that The operator xxx has been registered. Please rename it.

That’s a good idea @wkcn but we have users that will be using c or cpp APIs with custom ops. So it will need to go into the backend.
@junrushao1994 any thoughts?

@wkcn just talked to @junrushao1994 offline and its not ideal and will be a pain-in-the-@$$ to get that functionality merged into nnvm and then update the submodule dependency commit in MXNet for that. Especially since nnvm is not high priority now that we're moving to relay.
So I think for now i'll implement a map that track the operator re-registrations and just uses incremented plevel values to allow calling set_attr multiple times. its definitely a hack, but i think its the best option for now.

@samskalicky @wkcn @szha @junrushao1994 @eric-haibin-lin This PR is ready for review.
c_api.cc and lib_api.h files are the most important
c_api.cc loads custom op and register in nnvm; lib_api.h has all prototypes used in custom library
example/extensions/*.cc(py) are simple custom operator examples
other files include unittest, build change and python wrapper change

Failing centos-gpu job is failing with Numpy issue #16358 unrelated to this PR. We've sync'ed with the authors and they confirmed. Assume all CI jobs are passing at this point until they can address the issue

Hey, thank you guys for the nice work! BTW, would you mind if you guys clearly state why DLTensor is not adopted, which I believe would be useful for other community members for refenrece

Hey, thank you guys for the nice work! BTW, would you mind if you guys clearly state why DLTensor is not adopted, which I believe would be useful for other community members for refenrece

@wkcn (who implemented DLTensor support in MXNet) and I had a long discussion about this. In fact, we did investigate supporting DLTensor:
https://github.com/samskalicky/incubator-mxnet/blob/custom_op/example/custom_op/test.cc#L14
One takeaway we had was that it would not be easy or convenient to modify the structure of DLPack. The reason is that DLPack is used commonly in multiple deep learning frameworks, and we should keep the consistence of DLPack. So building MXNet custom operators on top of DLTensor would limit our future extensibility of MXNet and custom operator support.
One example of this would be adding a "layout" field to the tensor structure (ie. NCHW). This is something that I have heard as a request, but is not currently something the DLPack community is willing to accept. The MXTensor structure in this work is compatible with DLPack/DLTensor, so any user that wants to convert from MXTensor to DLTensor can do so by simply setting the fields in a DLTensor without copying data, and with a very small overhead.
Just because we're not using DLTensor now, does not mean that we cannot support it directly in a future PR. If enough users want this feature, the work in this PR can easily be extended to simply pass DLTensors from MXNet to the custom operators in the external library.

@samskalicky Thank you Sam for the explanation!

Note: the two failing CI jobs are related to numpy:
sanity:
************* Module mxnet.numpy_op_signature

python/mxnet/numpy_op_signature.py:21:0: E0402: Attempted relative import beyond top-level package (relative-beyond-top-level)

unix-gpu:
Setting test np/mx/python random seeds, use MXNET_TEST_SEED=1746065449 to reproduce.

ERROR

@samskalicky the pylint issue in ci is really weird. very often i failed it, did nothing but retrigger, it disappears

Just talked with @szha and he found out a better way to make MXTensor not diverge from the de facto standard tensor format DLTensor -- we can have a MXTensor class which contains a DLTensor as its member. Just like what TVM did for its own tensor format.

Just talked with @szha and he found out a better way to make MXTensor not diverge from the de facto standard tensor format DLTensor -- we can have a MXTensor class which contains a DLTensor as its member. Just like what TVM did for its own tensor format.

Thanks @junrushao1994  & @szha thats a good idea. I added the DLTensor to the list of features for the next custom Op PR.

Sounds nice!

talked with @szha offline and we agree on putting DLTensor support to the next PR

Hi @szha, this PR provides an approach to create ABI-compatibility custom operator.
There is some limitation in the existing interface ‘MXCustomOpRegister’, which creates custom operator as a task of mx.nd.Custom (https://github.com/apache/incubator-mxnet/blob/master/src/operator/custom/custom-inl.h#L216). It drops the performance, because of the thread lock and restricted workers. Additionally, ‘ MXCustomOpRegister’ does not provide the CUDA stream.
This PR will register custom Op, which is a NNVM op, rather than a task of a NNVM op(mx.nd.Custom).  It does not drop the performance, and it is available to handle all resources, like CUDA stream, memory allocation.

@szha Because we want to make lib_api.h self-contained without any dependencies. The end goal is that the user will only copy lib_api.h to their workspace, install MXNet pip wheel, and write their operator based on the tutorial doc and examples we provided. Using existing MXNet interfaces both introduces extra dependencies, and complicate user experience for users who are not familiar with MXNet source code

@szha we can also copy the implementation of dmlc::registry & dlpack to lib_api.h, but it doesn't solve the diverge problem you described. Plus those changes are not necessarily go to this PR as it focuses on backend registration, and if user really wants the complete MXNet solution we can refactor it in the upcoming PRs.

@yzhliu any idea why this is failing?
Traceback (most recent call last):
  File "/work/mxnet/contrib/tvmop/compile.py", line 20, in <module>
    import tvm
  File "/work/mxnet/3rdparty/tvm/python/tvm/__init__.py", line 23, in <module>
    from . import tensor
  File "/work/mxnet/3rdparty/tvm/python/tvm/tensor.py", line 20, in <module>
    from ._ffi.node import NodeBase, NodeGeneric, register_node, convert_to_node
  File "/work/mxnet/3rdparty/tvm/python/tvm/_ffi/node.py", line 24, in <module>
    from .node_generic import NodeGeneric, convert_to_node, const
  File "/work/mxnet/3rdparty/tvm/python/tvm/_ffi/node_generic.py", line 23, in <module>
    from .base import string_types
  File "/work/mxnet/3rdparty/tvm/python/tvm/_ffi/base.py", line 60, in <module>
    _LIB, _LIB_NAME = _load_lib()
  File "/work/mxnet/3rdparty/tvm/python/tvm/_ffi/base.py", line 52, in _load_lib
    lib = ctypes.CDLL(lib_path[0], ctypes.RTLD_GLOBAL)
  File "/usr/lib/python3.5/ctypes/__init__.py", line 347, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: /work/build/3rdparty/tvm/libtvm.so: file too short
ninja: build stopped: subcommand failed.

@wkcn can you please restart the unix-cpu job and see if it was transient?

@samskalicky , I do not have the permission to retrigger the one of CI, but I push a empty commit to retrigger the all.

Thanks @wkcn, i ran into some flaky test failures and had to push another empty commit:
=====================================================================
FAIL: test_quantization_mkldnn.test_requantize_int32_to_int8
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/usr/local/lib/python3.5/dist-packages/nose/case.py", line 198, in runTest
    self.test(*self.arg)
  File "/usr/local/lib/python3.5/dist-packages/nose/util.py", line 620, in newfunc
    return func(*arg, **kw)
  File "/work/mxnet/tests/python/mkl/../unittest/common.py", line 177, in test_new
    orig_test(*args, **kwargs)
  File "/work/mxnet/tests/python/mkl/../quantization/test_quantization.py", line 186, in test_requantize_int32_to_int8
    check_requantize_with_symbol((3, 4, 10, 10))
  File "/work/mxnet/tests/python/mkl/../quantization/test_quantization.py", line 181, in check_requantize_with_symbol
    assert_almost_equal(qdata_int8.asnumpy(), qdata_int8_np)
  File "/work/mxnet/python/mxnet/test_utils.py", line 624, in assert_almost_equal
    raise AssertionError(msg)

AssertionError:
Items are not equal:
Error 1562.500000 exceeds tolerance rtol=1.000000e-05, atol=1.000000e-20 (mismatch 0.083333%).
Location of maximum error: (2, 0, 9, 8), a=63.00000000, b=64.00000000
 ACTUAL: array([[[[ 106,   17,  -56, ...,   88,   -9,  -38],
         [ 107, -120,  -49, ...,  -78,   81,   93],
         [-100,  -90,  -17, ...,   84,   49, -118],...
 DESIRED: array([[[[ 106,   17,  -56, ...,   88,   -9,  -38],
         [ 107, -120,  -49, ...,  -78,   81,   93],
         [-100,  -90,  -17, ...,   84,   49, -118],...

-------------------- >> begin captured stdout << ---------------------

*** Maximum errors for vector of size 1200:  rtol=1e-05, atol=1e-20

  1: Error 1562.500000  Location of error: (2, 0, 9, 8), a=63.00000000, b=64.00000000

======================================================================
FAIL: test_operator_gpu.test_fast_lars
----------------------------------------------------------------------

Traceback (most recent call last):
  File "C:\Python37\lib\site-packages\nose\case.py", line 198, in runTest
    self.test(*self.arg)
  File "C:\jenkins_slave\workspace\ut-python-gpu\tests\python\gpu\../unittest\common.py", line 177, in test_new
    orig_test(*args, **kwargs)
  File "C:\jenkins_slave\workspace\ut-python-gpu\tests\python\gpu\test_operator_gpu.py", line 328, in test_fast_lars
    check_fast_lars(w_dtype, g_dtype, shapes, ctx, tol1, tol2)
  File "C:\jenkins_slave\workspace\ut-python-gpu\tests\python\gpu\test_operator_gpu.py", line 310, in check_fast_lars
    assert_almost_equal(ref_new_lrs.asnumpy(), mx_new_lrs.asnumpy(), atol=tol2, rtol=tol2)
  File "C:\jenkins_slave\workspace\ut-python-gpu\windows_package\python\mxnet\test_utils.py", line 624, in assert_almost_equal
    raise AssertionError(msg)

AssertionError:
Items are not equal:
Error 2.844314 exceeds tolerance rtol=1.000000e-06, atol=1.000000e-06 (mismatch 1.724138%).
Location of maximum error: (33,), a=0.01896909, b=0.01897199
 ACTUAL: array([0.00013492, 0.00045911, 0.00021266, ..., 0.00068631, 0.0002449 ,
       0.00085557], dtype=float32)
 DESIRED: array([0.00013493, 0.00045911, 0.00021266, ..., 0.00068631, 0.0002449 ,
       0.00085556], dtype=float32)
-------------------- >> begin captured stdout << ---------------------

*** Maximum errors for vector of size 58:  rtol=1e-06, atol=1e-06

  1: Error 2.844314  Location of error: (33,), a=0.01896909, b=0.01897199

More flaky test failures:
======================================================================
FAIL: test_operator_gpu.test_bulking_operator_gpu
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/nose/case.py", line 198, in runTest
    self.test(*self.arg)
  File "/work/mxnet/tests/python/gpu/../unittest/common.py", line 177, in test_new
    orig_test(*args, **kwargs)
  File "/work/mxnet/tests/python/gpu/test_operator_gpu.py", line 2398, in test_bulking_operator_gpu
    _test_bulking(_test_bulking_in_process)
  File "/work/mxnet/tests/python/gpu/test_gluon_gpu.py", line 553, in _test_bulking
    time_per_iteration):
  File "/work/mxnet/tests/python/gpu/../unittest/common.py", line 334, in run_in_spawned_process
    assert p.exitcode == 0, "Non-zero exit code %d from %s()." % (p.exitcode, func.__name__)
AssertionError: Non-zero exit code -6 from _test_bulking_in_process().
-------------------- >> begin captured logging << --------------------
common: INFO: Setting test np/mx/python random seeds, use MXNET_TEST_SEED=298254377 to reproduce.
--------------------- >> end captured logging << ---------------------

pipeline timed out, for centos-cpu, had to push again.

@wkcn 1.6 code freeze is tomorrow, so are you ok with this one not going into the 1.6 release? It is because none of us have time to maintain it until late November. After code freeze then we can merge it on Friday, and user can use nightly build to access this feature.

@rondogency No problem : )

Hi @samskalicky and @rondogency , is it ready to merge this PR?

Hi @samskalicky and @rondogency , is it ready to merge this PR after CI passes?

Yes! We're soooooo ready to merge :)
Thanks @zachgk for reruning the unix_cpu job!

I will merge this PR after the CI passes.
Thank all contributors!

@wkcn Big thank to Jackie for the merging work!


#17: Added a link to the tech blog article about Kinesis Connector.

Closes #17

How about adding something like to Readme.md line 9:

Kinesis Data Streams (KDS) is a real-time data streaming service provided by Amazon. It lets you continuously collect and temporarily store data from multiple sources. You can create custom applications that process or analyze streaming data. This connector provides you a function that consumes these data from a stream so that you can write them into an Exasol table. Since the data on kinesis Streams will be lost if you don't consume them you have to schedule the run of that function.

linking the blog aricle is however a good idea! ;-)


Sending audio message issue

Is the bug present in the demo Chat SDK project? Didn't check

What modifications have you made to the Chat SDK? No changes made

Android Version: 10.0

Steps taken to reproduce the problem: Sending an audio message

Expected result: Should be able to send an audio message

Actual result: Getting exception - java.lang.NullPointerException: Attempt to invoke interface method 'io.reactivex.Completable sdk.chat.core.handlers.AudioMessageHandler.sendMessage(android.content.Context, java.io.File, java.lang.String, long, sdk.chat.core.dao.Thread)' on a null object reference

Comments:

@bensmiley  Thank you for this wonderful library and for your reply. I am able to fix the issue by adding a line  .addModule(AudioMessageModule.shared()) in configuration. One more doubt, can I use AudioMessageModule without purchasing a license, if I am implementing the audio message feature on my own? I just want to use the method ChatSDK.audioMessage().sendMessage. recording the audio, showing it in chat and playback are handled by me. I am not using any ChatSDK UI modules.

Hi @basims you would need to have a license if you were to include the AudioMessageModule class OR :chat-sdk-pro-message-audio Gradle dependency in your project. If you use any of the code from the audio message module then you need a license.
If you don't use the module and re-implement all the functionality independently using your own unique approach and code, then you would not need a license.


flatcam.x86_64-linux is broken

Describe the bug
Flatcam fails to build
To Reproduce
With flakes: nix build -L github:NixOS/nixpkgs/b3ea24a4144884ab07ed4b8c48fddf4a292f1417#flatcam
Or build from master.
Or just look at Hydra: https://hydra.nixos.org/job/nixpkgs/trunk/flatcam.x86_64-linux
Additional context
Complains about libspatialindex_c.
Git bisect is going poorly, seems like there was a version bump in mesa (very long rebuilds) and a period where python3Packages.pillow and python3Packages.shapely were broken causing an unrelated breakages in Flatcam.
Notify maintainers
@trepetti
Maintainer information:
attribute:
flatcam
# a list of nixos modules affected by the problem
module:

Sorry, I wasn't paying attention when I was trying to bisect this. The error is in python38Packages.Rtree, Flatcam just depends on it.

Fixed by #116128.


Set coin_cbc verbosity

Hi,
I was wondering how I can set the verbosity level of coin_cbc through this crate.  I found https://github.com/KardinalAI/coin_cbc/issues/3 which looks to be what I want.  I also saw that I can get an &Model from CoinCbcProblem::as_inner().  The problem is that Model::set_parameter() requires an &mut reference while I can only obtain an immutable one.
Is there a different solution which I missed?  If not, maybe a second method could be added to CoinCbcProblem for getting a mutable reference?  If this could prove hazardous for upkeeping internal invariants, making this method unsafe would seem like a good compromise to me.

I think a good solution would be to depend on the almost universal log crate, and set the cbc verbosity based on the standard rust log level. What do you think ?

I think exposing parameters is a good idea: there is log, bit also solver tunning available.
The log crate has a complicated syntax, and levels that doesn't really match with coin.

We don't want people changing the solver parameters, and for instance removing parameters from under our feet, do we ?
How is the log crate syntax complicated?

I would prefer having direct access to the parameter here.  I feel like wiring this up to log is be not a good idea:

log provides a mechanism for libraries and applications to write log messages and an implementation of a filtering mechanism to only show some of those messages.  Especially, behind log you'll always need a backend which actually takes care of logging the generated messages somewhere and initializing the filters.  CBC doesn't care about all this and just writes its messages to stdout directly.  So it wouldn't really tie into the log ecosystem at all.  The only "connection" which could be made is by asking log of the (default!) log-level and setting something similar in CBC.
The log-levels from log don't really map to the verbosity levels from CBC well, I think.  So it would be confusing for downstream users to understand what log-level from log corresponds to which setting from CBC.
There might also be a mismatch between what the user wants to see logged from the application and what they want to see logged from CBC.  To some degree, applications might want to control this, too.  You could use a magic module name for setting the CBC log-level but that feels like a hack to me.

In the end I think this wouldn't gain us much and just make the original task I wanted to accomplish more complicated.  I think what I wanted to do is what most people will care about: silencing CBC to keep the console free for actually interesting messages.

We don't want people changing the solver parameters, and for instance removing variables from under our feet, do we ?

That's why I would suggest making the access to the CBC model "unsafe":
unsafe fn as_inner_mut(&mut self) -> &mut Model {
    // ...
}

This way people can't possibly destroy invariants assumed by good_lp without unsafe code.
In parallel to adding the above (which is probably useful beyond this issue alone), for logging in particular, maybe adding another method specifically to set the verbosity might be a good idea?  It would certainly help people searching through good_lp documentation for terms like "log" or "verbosity" to find what they need... For example:
fn set_solver_verbosity(&mut self, v: &str) {
    // ...
}

You can also add a fn set_parameter(key: &str, value: &str) without any invariant breaking.

I would like to add that we are experiencing the same problems in the highs solver. Any way of changing the verbosity would be extremely appreciated. I think being able to set the options on the models themselves would be extremely useful.


Update build.gradle to remove compile warning

Description
With the latest react-native version RN >= 0.57 the android build tools were updated and now using compile in the build.gradle file generates the following error:
WARNING: Configuration 'compile' is obsolete and has been replaced with 'implementation' and 'api'.
It will be removed at the end of 2018. For more information see: http://d.android.com/r/tools/update-dependency-configurations.html
Please note that this also happens to people that manually updated their android build tools from the previous defaults
Compatibility

OS
Implemented

iOS
✅

Android
✅

Windows
✅

Checklist

[X ] I have tested this on a device/simulator for each compatible OS
[ ] I added the documentation in README.md.
[ ] I mentionned this change in CHANGELOG.md.

Items 2 and 3 in the checklist are not needed as this change doesn't affect any functionality. It just removes a compile warning.

This PR should have been opened to the upstream master, not to my fork


Logo and Mascot

Im was wondering why this language dient have any Logo yet. So, i want to Start a discussion about that. And a discussion How it should look like?
My example is this one here
https://thumbs.dreamstime.com/z/vector-logo-design-template-colorful-hexagon-infinity-loop-shap-shape-business-technology-abstract-symbol-letter-g-icon-46763997.jpg
It's just not Mine, but i felt this Kind of direction for the Logo would be really nice.
I mean If the Word Gluon, comes from this
https://en.m.wikipedia.org/wiki/Gluon, then its great. The g on the picture have los of Edges and different colors just to represent the glue Effect. Hope that make sence!

I did make some logo ideas a while back and shared them on Gitter:

They weren't the greatest though! 🤔

I mean If the Word Gluon, comes from this https://en.m.wikipedia.org/wiki/Gluon, then its great.

Yep, the Gluon name comes from the elementary particle and the fact that it sounds like "glue-on" which seemed appropriate :) (I also studied Engineering Physics in university which is why I were digging around in physics concepts for a name).
The main reason it does not have a logo though is that I have little to no artistic skill or knowledge what makes a good logo. But perfect shouldn't be the enemy of good so even "just" a good logo would be an improvement!
Only actual input I can think of right now is that I think a lowercase g in the right font would probably give the same feel as the "squigglies" in https://github.com/gluon-lang/gluon/issues/325#issuecomment-326866146 and https://en.m.wikipedia.org/wiki/Gluon 🤔

Intresting idears @ all! @Marwes i think so too, because of the symbol "g"! U mentioned, the Logo style from brendanzab's First logo Design, it look cool but i think it has, How to say, somekind of too much grinds. The colors are great. But prefer just the "g" in right Font style. Maybe somekind what i posted, but I didnt find any Logo in a short time, so i decided hmmm... Okay ill take this one. But anyway, a "g" with flowing "hairstrains" would be not looking great. Maybe a Mix of the g with the grinds would be cool! But honestly, i would go for just the "g"!

Maybe a glue like "g", like this one ->
https://ae01.alicdn.com/kf/HTB1bnj2LVXXXXXbapXXq6xXFXXX4/2017-Sale-Fake-Septum-Wholesale-6-Pairs-12pcs-Acrylic-Spiral-font-b-Ear-b-font-Gauges.jpg

This is my work, hope you guys like?!

@BadFactor Nice! I appreciate the work you put into this! I like how the font looks a bit like a diagram would, ie lines without any extra adornment. The logo itself may not work quite as well, since I know it is supposed to be a stylized 'g' I can make it out but it might be difficult otherwise. Maybe that is not actually a problem though since there is nothing that say that it must be a 'g'. Maybe it would work if it took some looks from the letter gamma ɣ? The loop at the bottom might be hard to work in while still making it look like a g... Perhaps some colour or shading would work to combine them yet keep the parts distinguished? ( "gluing" them together to make a bad pun).

Thanks, :) ill try my Best, the looping from the symbol gamma, Sounds like a good idear, ill try my Best to figure out, How to combine it with the "g"!

Forget to say, i think the Blue "Splines" or "Wales" hasnt the right colors! Should i take. Another one or wich colors u prefer?  I could integrate it! I try to push it more, meaning the "g" and the Gluish Aspect! With just colors or shadows or such stuff it's not really good working, but i try as good as i can, maybe i find a really good way! See u guys in the next days, maybe in a couple of hours,  who knows!   Not Wales, Waves!

What about this one: it just came to my Head.
I use the big g from above copy it tenTimes in a row, make the coming Version more and more transparent and place it behind the big g??

I use the big g from above copy it tenTimes in a row, make the coming Version more and more transparent and place it behind the big g??

Might make to busy? Maybe it would work though.

Another one or wich colors u prefer?

I'd be fine with just a logo and the name in some nice text/font.
The colours in the image with the background look good but perhaps they are to dark when the text is on top as the text partly blends in to the background?

both are the same, but the second one has a slightly thin line on the outside of the "g"

https://github.com/gluon-lang/gluon/issues/325#issuecomment-329303223

I feel it may be a bit to stylized, looks more like a pair of moons than g. While it sort of makes sense since gluon is inspired by lua it is perhaps somewhat misleading since it does not take that much inspiration from lua.
This is what I were thinking of in https://github.com/gluon-lang/gluon/issues/325#issuecomment-327309062 (only it is terrible).

hope u like it!!!

@BadFactor I am not really feeling it with that logo but can't really put my finger on it 🤔

Looks like a p from the PS of PlayStation, in some way, right?

Anyway, i will try it as long as it is good enough for u guys ;)  i think now, that im on the right way! To keep u satisfied

what about these guys here? are there in ur way of  feeling it or not, i mean just a "g" a normal g written down with the Arial font is kinda boring, and i tink not in ur opinion, maybe, right?

First of thanks,......i didnt have a clue, which kind of font would fit, but i think it must be created from the ground up, ...so im not a font designer,....welll okay there are free tools for that, but im not into it so much... sorry for that....BUT i written down some gluon names with different fonts, there is one type i would prefer, the most fonts are free to use or u have to name the athor from the font, ...but i like the

And here are some of the fonts i use, or used! instead u can go for a certain website,.... called freefonts.com or thou, ...here u can type the name and u get the name in different fonts as a results !

OTHERWISE, i would go for a FontDesigner,....or maybe here in the community is one who can create the font,...who knows!!!???