[BUG] Service Bus processing hangs on receiving message

Service Bus processing hangs on receiving messages within session. The only solution is to restart the process.
Thread dump:
"EE-ManagedExecutorService-ServiceBusExecutor-Thread-2" #445 daemon prio=5 os_prio=0 tid=0x000001a498c76800 nid=0x22a0 waiting on condition [0x0000007f554fe000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0x0000000698fbde80> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2044)
	at reactor.core.publisher.BlockingIterable$SubscriberIterator.hasNext(BlockingIterable.java:179)
	at java.util.Iterator.forEachRemaining(Iterator.java:115)
	at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566)
	at [COMPANY PACKAGE].servicebus.SessionsHandler.processSession(SessionsHandler.java:120)
	at [COMPANY PACKAGE].servicebus.SessionsHandler.processSessions(SessionsHandler.java:83)
	at [COMPANY PACKAGE].SessionsHandler$$Lambda$2084/1332643277.run(Unknown Source)
	at org.jboss.as.ee.concurrent.ControlPointUtils$ControlledRunnable.run(ControlPointUtils.java:125)
	at org.wildfly.security.auth.server.Scoped$$Lambda$2095/858682343.accept(Unknown Source)
	at org.wildfly.security.auth.server.Scoped$$Lambda$2098/1043870569.accept(Unknown Source)
	at org.wildfly.security.auth.server.SecurityIdentity.runAsConsumer(SecurityIdentity.java:376)
	at org.wildfly.security.auth.server.Scoped.runAsConsumer(Scoped.java:112)
	at org.wildfly.security.auth.server.Scoped.runAs(Scoped.java:60)
	at org.jboss.as.ee.concurrent.SecurityIdentityUtils.lambda$doIdentityWrap$1(SecurityIdentityUtils.java:63)
	at org.jboss.as.ee.concurrent.SecurityIdentityUtils$$Lambda$2086/1755134231.run(Unknown Source)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:117)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:750)
	at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:227)

Steps to reproduce the behavior: unknown, behaviour seems to be nondeterministic although we observed it for topics with lots of sessions  and maxWaitTimeOnReceivingMessage set to 1 sec
Code
 private void processSessions() {
        while (true) {
            try {
                if (stopSignalReceived) {
                    break;
                }
                processSession(serviceBusSessionReceiverClient.acceptNextSession());
            } catch (IllegalStateException e) {
                log.trace("Timeout happened on acceptNextSession(), ignoring.");
            } catch (AmqpException amqpException) { // https://github.com/Azure/azure-sdk-for-java/issues/28337
                log.warn("Received AMQP exception. Condition: {}, transient: {}, message: {}",
                        amqpException.getErrorCondition(), amqpException.isTransient(), amqpException.getMessage());
            } catch (Exception e) {
                log.error("Exception on receiving on topic {}", entityPath, e);
            }
        }
        log.info("Finished infinite acceptNextSession loop on {}", entityPath);
    }

    private void processSession(ServiceBusReceiverClient serviceBusReceiverClient) {
        // fix: https://github.com/Azure/azure-sdk-for-java/issues/28337
        if (serviceBusReceiverClient == null) {
            log.warn("serviceBusSessionReceiverClient.acceptNextSession() returned null");
            return;
        }
        final Instant sessionLockTimestamp = clock.instant().plus(maxAutoLockRenewal);
        final String sessionId = serviceBusReceiverClient.getSessionId();

        log.info("New session accepted {}", sessionId);

        String stoppingReason = "unknown";

        while (true) {
            try {
                if (stopSignalReceived) {
                    stoppingReason = "STOP_SIGNAL_RECEIVED";
                    break;
                }
                if (clock.instant().isAfter(sessionLockTimestamp)) {
                    stoppingReason = "SESSION_TIMEOUT_EXCEEDED";
                    break;
                }
                final List<ServiceBusReceivedMessage> receivedMessagesStream = serviceBusReceiverClient.receiveMessages(prefetchCount, maxWaitTimeOnReceivingMessage)
                        .stream().collect(Collectors.toList()); // hangs here

                if (receivedMessagesStream.isEmpty()) {
                    stoppingReason = "NO_MESSAGE_IN_SESSION";
                    break;
                }

                receivedMessagesStream.forEach(receivedMessage -> messageHandler.handle(receivedMessage, serviceBusReceiverClient));

            } catch (ServiceBusException e) {
                log.warn("Exception while receiving/processing messages sessionId {}", sessionId, e);
                stoppingReason = "EXCEPTION_OCCURRED";
                break;
            }
        }

        log.info("Closing session {} reason {}", sessionId, stoppingReason);
        serviceBusReceiverClient.close();
    }

Setup

OS: Windows Server 2019 Datacenter/Azure VM
Library/Libraries: com.azure:azure-sdk-bom:1.2.12, com.azure:azure-messaging-servicebus:7.13.4
Java version: 8
App Server/Environment: WildFly 26.1.3.Final

Would you be able to share the -10/+10 logs from the point when library stops emitting messages from a session?
Also, to understand a bit more about the use case – Is the application process one session at a time then move to next, as shown in the same code, or are there any concurrency involved?

Sorry I'm not able to provide any logs for this issue. There is part of the tread dump we caught

Hello @lidkowiak, there is a bug exists in version 7.13.4, which can leads the Session receiveMessages() API to hang. From the code and comment you provided, the application seems to hung on receiveMessages. The detail of the hang is here https://github.com/Azure/azure-sdk-for-java/issues/34597. Could you upgrade  to the latest version (7.14.3 as of today 8/21/2023)?

Recommendation to upgrade the SDK version provided as the older version 7.13.4 known to have the problem.


Remove unnecessary before_install.sh script

Only used on macOS and not required to successfully run tests, so remove
it. Instead, rely on the environment created by Travis CI.

Codecov Report

Merging #993 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #993   +/-   ##
========================================
  Coverage    89.76%   89.76%
========================================
  Files           12       12
  Lines         2677     2677
  Branches       459      459
========================================
  Hits          2403     2403
  Misses         186      186
  Partials        88       88


The bug in org.apache.rocketmq.store.DefaultMessageStore#getMessageIds line 1044

The issue tracker is ONLY used for bug report(feature request need to follow RIP process). Keep in mind, please check whether there is an existing same report before your raise a new one.
Alternately (especially if your communication is not a bug report), you can send mail to our mailing lists. We welcome any friendly suggestions, bug fixes, collaboration and other improvements.
Please ensure that your bug report is clear and that it is complete. Otherwise, we may be unable to understand it or to reproduce it, either of which would prevent us from fixing the bug. We strongly recommend the report(bug report or feature request) could include some hints as the following:
BUG REPORT

Please describe the issue you observed:

What did you do (The steps to reproduce)?
When I try to Use the method org.apache.rocketmq.store.DefaultMessageStore#getMessageIds,it returned wrong result.
I found that the ByteBuffers position has not modify to next messages position after get message`s offsetPy. This will cause an error in the messageId after the first message.Even if this method never been used,I think it is a bug.

What did you expect to see?

What did you see instead?

Please tell us about your environment:
jdk1.8 rocketm451
Other information (e.g. detailed explanation, logs, related issues, suggestions how to fix, etc):
Set next message`s position after get offsetPy.And if you agree with me ,I will create a PR later.My fix code in my repository now ...

yeah, we can fix by skip remaining 12 byte
 for (; i < bufferConsumeQueue.getSize(); i += ConsumeQueue.CQ_STORE_UNIT_SIZE) {
    long offsetPy = bufferConsumeQueue.getByteBuffer().getLong();
    bufferConsumeQueue.getByteBuffer().position(bufferConsumeQueue.getByteBuffer().position() + 12);
    final ByteBuffer msgIdMemory = ByteBuffer.allocate(MessageDecoder.MSG_ID_LENGTH);
    String msgId =
        MessageDecoder.createMessageId(msgIdMemory, MessageExt.socketAddress2ByteBuffer(storeHost), offsetPy);
    messageIds.put(msgId, nextOffset++);
    if (nextOffset > maxOffset) {
        return messageIds;
    }
}

yeah, we can fix by skip remaining 12 byte
 for (; i < bufferConsumeQueue.getSize(); i += ConsumeQueue.CQ_STORE_UNIT_SIZE) {
    long offsetPy = bufferConsumeQueue.getByteBuffer().getLong();
    bufferConsumeQueue.getByteBuffer().position(bufferConsumeQueue.getByteBuffer().position() + 12);
    final ByteBuffer msgIdMemory = ByteBuffer.allocate(MessageDecoder.MSG_ID_LENGTH);
    String msgId =
        MessageDecoder.createMessageId(msgIdMemory, MessageExt.socketAddress2ByteBuffer(storeHost), offsetPy);
    messageIds.put(msgId, nextOffset++);
    if (nextOffset > maxOffset) {
        return messageIds;
    }
}

@lazyfighter  position() method means setting the position to the specified value, not skipping. The PR
@ChaosYjh did is right.
@zongtanghu Could u please labeled bug to this issue?


Invalid dates in dropwizard/metrics commits

There's a number of commits in dropwizard/metrics that have a bad date in the author / commit line :
❯ git clone git@github.com:dropwizard/metrics.git
Cloning into 'metrics'...
remote: Enumerating objects: 69038, done.
remote: Counting objects: 100% (918/918), done.
remote: Compressing objects: 100% (499/499), done.
remote: Total 69038 (delta 541), reused 714 (delta 398), pack-reused 68120
Receiving objects: 100% (69038/69038), 19.76 MiB | 39.21 MiB/s, done.

Can these be fixed?    They cause issues with other git related tools (gitlab, etc)

Can these be fixed? They cause issues with other git related tools (gitlab, etc)

No, see also:

https://github.com/dropwizard/dropwizard/issues/1995
https://github.com/dropwizard/dropwizard/issues/1996
https://github.com/dropwizard/dropwizard/issues/3563

Unfortunately it's impossible to fix the corrupted commits without rewriting the history of the complete repository and thus invalidating any tag or verification which happened after these corrupt commits.


Seeded random for graphs generation

With @sim51, for the end-to-end testing of sigma v2, we would like to be able to make reproducible our examples (like this one for instance).
Is it possible to override the random generator used in the graphs generators?

It is already possible :). All those functions take a rng option so you do just that.


Mismatch in tut+example results when porting from py2 to py3

List of models that mismatch:

tut2
tut3
M1

What to check:

previous py3 also had same mismatch but I hadn't realized -- so not related to refactor
check version of packages and libraries in py2 vs py3

Unfortunately, the randomness of probabilistic conns in python2 depended on the ordering of dicts, see: https://github.com/Neurosim-lab/netpyne/blob/python2/netpyne/network/conn.py#L325
In python3 a major change is that dicts keep their insertion order: https://stackoverflow.com/questions/39980323/are-dictionaries-ordered-in-python-3-6
In summary, this means it's impossible to replicate python2 results in python3, due to essentially a bug in the python2 implementation, which introduced unreplicatable randomness for probabilistic connections.
Nonetheless, it seems that within python2, results were replicated across environments, i.e. the same dict ordering was kept, although this property shouldn't be relied upon.
In python3 the ordering depends on insertion, so there is no need to make any changes.

For tut2 and tut3 the results can be reproduced by starting to iterate the postCells dict by index 12 instead of 0. However, this rule doesn't fix tut5. Also, not sure if it applies to all python2 platforms:
"Python dictionaries and sets are stored using some efficient hashing algorithm. The precise algorithm is an implementation detail (and may differ from one version of Python to another as well as one platform to another (CPython, vs. PyPy, vs Jython or IronPython, and so on).
Iterating over the keys returns them in whatever order the underlying implementation chose to store them. Hashing provides for extremely efficient access to an item given its key. This typically has the effect of making them appear to be in a “random” order by human standards."

Can try to set some fixed iteration order that at least reproduces python2 results in my platform

collections.OrderedDict might be useful if you are wanting to guarantee order

Pattern doesn't follow simple rules -- could add rules to reproduce tuts and examples but too complex to implement for all cases, plus probably only applies to some platforms.
Added a flag in py2 branch to replicate previous results: cfg.useOldProbConn = True

Had to made other fixes to ensure results were independent of the number of cores in Python3 (due to Python3 handling of dicts). Therefore I removed the cfg.useOldProbConn and just added to CHANGES.md:
NOTE on backward replicability: Due to several performance improvements and bug fixes to ensure future replicability in both Python 2 and 3, it won't be possible to replicate results of previous versions.


Translations update from Hosted Weblate

Translations update from Hosted Weblate for Morse/Metadata.
Current translation status:

Thank you very much for your support! 😘


Update Constraint Datatype

This PR changes the simple Constraints datatype into ConstraintSet, adding a little more structure, namelly, it adds a conjunct :: Constraint lang meta -> ConstraintSet lang meta -> Maybe (ConstraintSet lang meta) which returns Nothing whenever it the resulting ConstraintSet would be trivially UNSAT.

The last commit introduces a hack for something we're not quite knowledgeable of: apparently, translation to SMT can fail and we would like to know exactly why and the implications of that.

Added some debugging code in here; plan for tomorrow is use the same debugging code on main and see how differently it behaves. I think we're pretty close.

While debugging this morning, I quickly spotted the issue. On the main branch, we collect the following constraints for cabal run spec -- -p /ohearn/ && /y == 11/:
b/sub $s2 1 == 0
∧ $s2 /= 0
∧ x ↦ D $s2 $s3
∧ __result ↦ D $s0 $s1
Body:   b/ite @Delta False (D $s2 42) (D $s2 $s3)
Assume: b/== $s1 42
Prove:  b/== $s3 11

Note how we actively collect b/sub $s2 1 == 0 and keep that! In our implementation of constraints, that is impossible to represent: we would gather that through TermEq [term| b/sub $s2 1 |] [term| 0 |], but that will trigger the unification algorithm to run and that will say /nope/: those are not unifiable. Consequently, that branch would be automatically pruned out and we would miss the counterexample, making the test run forever!
We need to record non-unification constraints in our ConstraintSet too and engineer it a little more carefully. A great plan for today would be to fix the bug then write tests for that module!

When I merge this to qa/z3_inline-c_faster-eval_batches and run the benchmarks the running-time of both Z3 and Pirouette seem to increase by ~2s (out of 20s for Z3 and 40s for Pirouette).

More precisely, here's the kind of benchmark results I get (after the PR / before the PR):
          Z3: 22.984s  count:  113600
     command: 30.788s  count: 1546100
launchSolver:  0.412s  count:     100
        main: 42.496s  count:       1
   readSExpr:  0.026s  count:   56800
  showsSExpr:  7.390s  count: 1659700

          Z3: 21.842s  count:  113600
     command: 29.886s  count: 2355500
launchSolver:  0.432s  count:     100
        main: 43.256s  count:       1
   readSExpr:  0.028s  count:   56800
  showsSExpr:  7.442s  count: 2469100

The time difference varies but the pre-PR version is consistently faster than the post-PR one. I don't see how the post-PR version could be sending less commands to the solver but still spend more time inside it.

Something else I haven't mentioned here is that the Z3 count is only incremented when a command with interesting results is sent, typically check-sat (whereas the command count is incremented for every command). So I would expect the Z3 count to be smaller post-PR since it should not be checking for satisfiability on trivial problems.

So, it makes intuitive sense to me that there are fewer problems the solver sees, but it has to think harder about them.
I agree with the fewer problems part, but why would the solver would have to think harder about them ? Aren't they supposed to be the same problems ?

Do you have any data on, say, the size of the problems?
Apart from the number of commands sent, no. What kind of data would help ?

I logged the commands sent to the solver pre- and post-PR and ran diff on the results. The output is huge but here are some interesting examples that I got by looking at the first lines (< is pre-PR and > is post-PR):
< (set-option :produce-models true)(declare-fun pir_greaterThan1 (Int) Bool)(declare-fun pir_greaterThan0 (Int) Bool)(declare-fun pir_add1 (Int) Int)(push 1)(declare-fun pir___result () Int)(declare-fun pir_x () Int)(check-sat)
---
> (set-option :produce-models true)(declare-fun pir_greaterThan1 (Int) Bool)(declare-fun pir_greaterThan0 (Int) Bool)(declare-fun pir_add1 (Int) Int)(push 1)(declare-fun pir___result () Int)(declare-fun pir_x () Int)(assert true)(check-sat)

and
< (pop 1)(push 1)(declare-fun pir___result () Bool)(declare-fun pir_s0 () Int)(declare-fun pir_x () pir_MaybeInt)(assert (= pir___result true))(assert (= pir_x ((as pir_JustInt pir_MaybeInt) pir_s0)))(check-sat)
---
> (pop 1)(push 1)(declare-fun pir___result () Bool)(declare-fun pir_s0 () Int)(declare-fun pir_x () pir_MaybeInt)(assert (and (= pir___result true) (= pir_x ((as pir_JustInt pir_MaybeInt) pir_s0))))(check-sat)

So it seems this PR is doing at least two things:

when a problem is trivial, the solution is sent to the solver as an assert (c.f. the additional assert true in the first example)
when several assertions are sent to the solver their are grouped under a conjunction (c.f. the second example).
The first point explains why the solver is sent as many problems pre- and post-PR, and the second point explains why there are still less commands sent to the solver overall (I assume the number of times Pirouette detects a problem is trivial is negligible compared to the number of assertions that can be merged). This still doesn't explain why the solver is spending more time on solving the problems post-PR though: if anything, it should be spending less time because some problems now come directly with their solutions.

I ran Z3 on the logfiles of the commands produced by Pirouette pre- and post-PR and I do get a noticeable difference in the running-times, although the files should be logically equivalent:

Command
Mean [ms]
Min [ms]
Max [ms]
Relative

z3 isunity.pre >/dev/null
190.3 ± 12.6
176.4
231.9
1.00

z3 isunity.post >/dev/null
230.2 ± 3.0
223.6
241.0
1.21 ± 0.08

Looking at the diff between both files more closely it really seems the only differences are that post-PR 1) a few trivial and negligible assertions are added, 2) some redundant declarations and assertions are removed and 3) assertions are merged together using conjunctions. This is to be taken with a grain of salt of course because there are too many lines for someone to go through every one of them.
My guess right now is that Z3 spends more time parsing one big assertion with conjunctions than it does parsing many small assertions consisting of simple (in)equalities. @facundominguez, you had a look at the internals of Z3's parser, does that sound plausible to you ?

I have no intuition on the cost of parsing larger expressions. But it could be checked by splitting the conjunctions into separate assertions ahead of feeding them to the SMT solver.

Ah, and there is a function that only does the parsing Z3_parse_smtlib2_string. You might be able to measure if it worsens with the large conjunctions. I modified the oneshot.c program to invoke it at some point:
#include<stdio.h>
#include<stdlib.h>
#include<stdarg.h>
#include<z3.h>

void my_parser_example(char const* const fileName) {
  Z3_config cfg;
  Z3_context ctx;
  cfg = Z3_mk_config();
  Z3_set_param_value(cfg, "model", "true");
  ctx = Z3_mk_context(cfg);
  Z3_del_config(cfg);

  FILE* file = fopen(fileName, "r");
  char* buffer = NULL;
  size_t len;
  ssize_t bytes_read = getdelim( &buffer, &len, '\0', file);

  Z3_ast_vector b =
      Z3_parse_smtlib2_string(ctx,
                              buffer,
                              0,
                                NULL,
                                NULL,
                                0,
                                NULL,
                                NULL);

  printf("%s", Z3_eval_smtlib2_string(ctx, buffer));
  fclose(file);
}

int main(int argc, char* argv[]) {
    char const* const fileName = argv[1];
    my_parser_example(fileName);
    return 0;
}

This doesn't seem to be the explanation: I merged the assertions on logfile produced by Pirouette pre-PR and I got

Command
Mean [ms]
Min [ms]
Max [ms]
Relative

z3 isunity.default >/dev/null
200.6 ± 13.5
182.1
226.7
1.00

z3 isunity_merge.default >/dev/null
203.2 ± 3.6
197.2
227.0
1.01 ± 0.07

Are those benchmarks still up-to-date with the merge of #150? I would expect so because #150 is not supposed to change the generated constraints, but who knows.

Are those benchmarks still up-to-date with the merge of #150? I

Yep, I'm ran them again and I'm not seeing any difference.


Fixed problem with bulk edit displaying an extra cell on the left side of each row

Fixed problem with the MTableEditRow component.
When mode of edit is 'bulk', no actions icons should show and no empty spaces should show.

Bulk edit mode instantiates a <TableCell> that consumes space on the left hand side. Bulk edit mode should never show any action icons nor any empty space there.

There is another corner case for the detail panel action button which is rendered separately from the other action buttons.

Thanks for this! Either myself or @Domino987 should be able to take a look tomorrow.


Asp.net Core MVC with Universal Rendering engine

We can create single page application using Asp.net core and Angular or React. But we don't have something like "zeit/next" for universal rendering.  If we can have universal rendering in Asp.net core then it will be the coolest framework for developing web application as it will have power of c# and SEO enabled SPAs, fastest initial rendering, state management using single source of truth, same rendering region on client and server and many more.
Regards,
<EMAIL_ADDRESS>
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: faf18d20-d28f-1efa-d329-181fff3630fa
Version Independent ID: 46a7c2e0-4871-491f-02c2-54f7df2237b1
Content: Get started with ASP.NET Core MVC and Visual Studio
Content Source: aspnetcore/tutorials/first-mvc-app/start-mvc.md
Product: aspnet-core
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

Hello @vijaytanwar ... thanks for the feedback. Note that this is the documentation repo and most issues opened here are only seen by a handful of documentation authors. I recommend you leave feedback at UserVoice or on the aspnet/Home issues.

https://aspnet.uservoice.com/forums/41199-general-asp-net
https://github.com/aspnet/Home/issues


Match works to DMPs

COKI Google BigQuery work for assisting the DMPTool with matching DMPs to research outputs in Crossref, DataCite and OpenAlex.
This PR consists of:

Initial Apache Airflow code (python)
Google BigQuery SQL queries (SQL with jinja2)
Using Google's latest text embedding models text-embedding-004 and text-multilingual-embedding-002

Supporting documentation can be found here (will be moved into the wiki as we get closer to finalizing the process):

Explanation of code
-Resource type matching doc

Addresses tickets:

dmsp_aws_prototype repo #77
dmsp_aws_prototype repo #107

looks good @jdddog and thanks for the walkthrough yesterday

Thanks Brian, you're welcome.
I've pushed the Apache Airflow workflow here. I need to integrate it with the DMPTool APIs and also run with queries in individual tasks in the workflow so that if one query fails everything doesn't need to be re-run.


Update interested-technical-writers.md

Add contact information for Anne Bonner

Thank you for your consideration!


The charm should use the default snap track instead of going for latest/stable

@tomponline with LXD not being seeded by default going forward, what do you think of changing the behaviour of the charm to:

change the snap-channel config to default to auto
when auto is used: check if lxd-installer is present and use it to pick the right track/channel
when auto is used: if no lxd-installer install from the current LTS (5.21/stable)

@simondeziel

change the snap-channel config to default to auto
Sounds good.

when auto is used: check if lxd-installer is present and use it to pick the right track/channel
Sounds good.

when auto is used: if no lxd-installer install from the current LTS (5.21/stable)
Lets not add more version logic into other components except lxd-installer and snap store.
The default track will be changing soon to 5.21, so the end result will be the same here without needing to code it into the charm.


Added a chat resource

Project URL
https://github.com/adium/adium
Category
Chat
Description
I added a resource named "Adium" in chat section by editing applications.json file.
Why it should be included to Awesome macOS open source applications  (optional)
Adium is a free instant messaging application and is one of the oldest and widely used chat application for macOS that can connect to XMPP (Jabber), IRC and more.
Checklist

[x] Edit applications.json instead of README.md.
[x] Only one project/change is in this pull request
[x] Screenshots(s) added if any
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

@dawoodwasif Thanks!


feat: add a positional indicator in the stack comment

Fixes MRGFY-2869
Change-Id: Iff0cbba91116d461cd2efbc5923d073bd8a694f8
Depends-On: #315

This pull request is part of a stack:

test: add pytest-asyncio (#313)
test: change working directory (#314)
test: add some tests on stack() (#315)
feat: add a positional indicator in the stack comment (#316)
chore: type GitHub comments (#317)


Add sound effect event

Adds a new API event for sound effects, soundEffectHeard, comparable to noteHeard.
Included in a new plugin 'sound.js' (the sound effects are more general than block_actions, seemed fitting to keep separate). This PR doesn't include the world_particles (0x28 packet) sound effects, only 0x29 named_sound_effect, but they could be added later in this same plugin.
Known sound effect names: http://wiki.vg/Protocol#Sound_Effect (example: mob.cow.say, maybe could somehow include this list in https://github.com/PrismarineJS/minecraft-data but I'm not sure what data would be associated with it, if any - for now the name from the packet is passed directly through to the event).

:+1:

I wonder why there are two packets for sound effect...
Anyhow, I'm in favor of adding a "sound API" to mineflayer. :+1:.

AFAIK all particles are graphical effects. Some of them include sounds, but are not sounds. It's a bit like the mobs, they make noise but are not sounds. I think it's okay not to include them :+1:

:+1:  merging


Animate images with image overlay

Description
PR to add a new Kotlin sample  "Animate images with image overlay" in Visualization category.
Links and Data
Sample issue: https://devtopia.esri.com/runtime/kotlin/issues/1138

a vTest Job for this PR has been run

[x] link: https://runtime-kotlin.esri.com/view/all/job/vtest/job/sampleviewer/64/

What To Review

Thanks for all the detailed suggestions @shubham7109 -- changes made!

Thanks @shubham7109 -- Sample in a much better state thanks to your suggestions!


Edge TPU Compiler doesn't use all on-chip memory

I have a small model that consists of MobileNetV3Small (without the head) and another convolutional layer after that, which returns a tensor with 128 elements.
When I compile the model using the edgetpu_compiler, it only uses a couple of 100 KiB for caching the model parameters and it puts the biggest part of the model in the off-chip memory, even though the model is quite small:
Edge TPU Compiler version 16.0.384591198
Started a compilation timeout timer of 180 seconds.

Model compiled successfully in 542 ms.

Input model: quantized_model.tflite
Input size: 4.04MiB
Output model: quantized_model_edgetpu.tflite
Output size: 4.13MiB
On-chip memory used for caching model parameters: 604.50KiB
On-chip memory remaining for caching model parameters: 511.50KiB
Off-chip memory used for streaming uncached model parameters: 3.45MiB
Number of Edge TPU subgraphs: 1
Total number of operations: 50
Operation log: quantized_model_edgetpu.log
See the operation log file for individual operation details.
Compilation child process completed within timeout period.
Compilation succeeded!

The code model and tflite conversion are done like this:
import numpy as np

import tensorflow as tf

from tensorflow.keras.applications import MobileNetV3Small
from tensorflow.keras.layers import Dropout, Flatten, Reshape, Lambda, ReLU, Dense, GlobalAveragePooling2D, Conv2D
from tensorflow.keras.models import Model

out_prefix = "/out/test"

try:
    # Disable all GPUS
    tf.config.set_visible_devices([], 'GPU')
    visible_devices = tf.config.get_visible_devices()
    for device in visible_devices:
        assert device.device_type != 'GPU'
except:
    # Invalid device or cannot modify virtual devices once initialized.
    pass

model = MobileNetV3Small(include_top=False, weights=None, input_shape=(224, 224, 3),
                         minimalistic=True)

x = Conv2D(
    128,
    kernel_size=(7, 7),
    strides=(7, 7),
    padding='same')(model.output)

x = Flatten()(x)

model = Model(model.input, outputs=x)

def representative_data_gen():
    for i in range(100):
        patch = np.random.normal(0.0, 10, (1, 224, 224, 3)).astype(dtype=np.float32)
        image = tf.convert_to_tensor(patch, dtype=tf.float32)

        yield [image]

converter = tf.lite.TFLiteConverter.from_keras_model(model)
# This enables quantization
converter.optimizations = [tf.lite.Optimize.DEFAULT]
# This sets the representative dataset for quantization
converter.representative_dataset = representative_data_gen
# This ensures that if any ops can't be quantized, the converter throws an error
converter.target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS_INT8]
# For full integer quantization, though supported types defaults to int8 only, we explicitly declare it for clarity.
converter.target_spec.supported_types = [tf.int8]
# These set the input and output tensors to uint8 (added in r2.3)
converter.inference_input_type = tf.uint8
converter.inference_output_type = tf.uint8
tflite_model = converter.convert()

with open(out_prefix + '/quantized_model.tflite', 'wb') as f:
    f.write(tflite_model)

Interestingly, when I replace the Conv2D layer with a globalAveragePooling2D, the whole model is put into the on-chip memory. So my question is: Is it normal that my model doesn't fit into the on-chip memory even though it is so small?
My suspicion is that there is a maximum tensor size that is allowed. Since the tensor returned by the MobileNetV3Small has 28224 elements, I thought that maybe it's too large and then the compiler puts the weights in the off-chip memory. If that's the case, it would be great to have some error message or warning.

Hi @muxamilian I think, its due to the parameter size of con2d layer (which might be too large for edgeTPU). Please let me know if you have any other models with same behavior. Thanks!
 Layer (type)                   Output Shape         Param #     Connected to
conv2d (Conv2D)                (None, 1, 1,<PHONE_NUMBER>     ['re_lu_22[0][0]']

I have experimented with other models and have come to the conclusion that there's probably a limitation of the maximum parameter size as you said. If this is the case, it would be great if it were documented. I spent a considerable amount of time trying to figure out why my model wouldn't fit into the Coral's 8 MB SRAM even though it was only around 4 MB.


[Map] FotW-_Unreal_Map1

If you're interested in technical issues - the translator messages are in German (not a problem of course but an issue for those who don't understand German, as one has no sense of the story, important in SP maps, and don't get any helpful hints/warnings, etc.  The universal translator doesn't seem to work - tried in OldSkool and tried in default UT using the translators produced by sektor and Buggie - perhaps it's just me or my system but I couldn't get anything to work.
I know the messages are in German as I had a look in the editor.

URL: https://unrealarchive.org/maps/unreal-tournament/single-player/F/fotw-_unreal_map1_45130ac6.html
Hash: 45130ac6cae82405ec96cf4e903c378ff78e65ee
Current name: FotW-_Unreal_Map1

Apologies for raising another issue - completely forgot I could add a comment to the other issue for this map - blame age and tiredness!

Perhaps a repack with .int files taking the place of German ones and the German lines being sent to a .det file?

That would help - though not sure why the Universal Translator doesn't work in OldSkool?

Perhaps the guys at #localization in the OldUnreal Discord channel may help? Sorry, I can't translate to other languages, just to spanish.


chore(config): add go config

Fixes #

Codecov Report

Merging #16 (cff5ac4) into main (bf90fbc) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head cff5ac4 differs from pull request most recent head effbadb. Consider uploading reports for the commit effbadb to get more accurate results

@@            Coverage Diff            @@
##              main       #16   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         2
  Lines           54        54
  Branches        12        12
=========================================
  Hits            54        54

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Improve CI

CI seems to have stopped failing for a while (see output of https://github.com/eth-cscs/stackinator/actions/runs/5486778221/jobs/9997318839?pr=122, for example). This PR improves how linting tools are run.
The whole code base is automatically re-formatted to make black and isort happy again.
Additionally, the docs and publish actions are only allowed to run from the main repo.

@RMeli why is this draft?

@teojgo I was giving precedence to #122, so I set this to draft to avoid potential merge conflicts. But I can take care of those if needed.


Possible fixes for umd build

#334
This is just one possible solution.
The current react-redux-form build has a webpack.config.base.js and a webpack.config.prod.js.
It wasn't clear to me what the goal of these two configs were, but the issue I was having with the umd build seemed to be related to having duplicated output sections and also specifying the output file both on the command line (in package.json) and in the prod output section.
So I removed the prod output section.  I also had to rename the output lib to 'ReactReduxForm' from 'react-redux-form' as I had an issue referencing a name with hyphens in my own project's webpack externals.  But that could be because I am doing it wrong.

This LGTM! I'm fine with ReactReduxForm being the output name.

Congrats on 1.0!
Are you planning on publishing the umd build to npm so it can be downloaded from the /dist again?

Yes, I'll do that soon!

@djkz @mdgbayly I must have forgotten to npm publish, because it's now available<EMAIL_ADDRESS>