Mock wallet backend

The mock wallet backend is a mockchain with HTTP interface that simulates wallets interacting with the blockchain (powered by the emulator). It lets us test Plutus contracts in the app platform without needing a test net / real wallet.
The mock wallet backend needs to maintain two pieces of state:

One Wallet.Emulator.Types.WalletState per simulated wallet
One Wallet.Emulator.TypesEmulatorState for the blockchain

It should have HTTP endpoints for

balancing a transaction (Language.Plutus.Contract.Wallet.handleTx)
adding an address to the wallet's list of interesting addresses, and querying for new transactions at the interesting addresses
asking for the current slot number

All of the functionality is already implemented somewhere, so this task is mostly about figuring out the right interface.

Suggested API:
listen :: ContractId
       -> Slot
       -- ^ The slot where we start listening for the Hook.
       -> Hook
       -- ^ The hooks are: watch address and wait for slot
       -> ()

runBlocks :: ContractId
          -> Slot
          -- ^ The slot where we start streaming events.
          -> Either Slot (Event, Slot)
          -- ^ There may be no trigger up to the current slot
          --   (left branch of the Either) or we have an event
          --   that needs processing, so we suspend streaming
          --   at _snd . fromRight_

balanceTx :: UnbalancedTx
          -> Error String Tx
          -- ^ We may be unable to balance the transaction.

currentSlot :: Slot

Seems reasonable, just a few clarifications

Does ContractId refer to an instance of the contract? If so then it will have to be generated by the app platform
Will the mock wallet delete events after they have been consumed by 'runBlocks'?

I'm slightly unclear about the architecture: I think what happens is:

The SCB is going to use this interface.
The SCB will probably have two threads for interaction with the wallet backend:

One which calls runBlocks so it can respond to notifications from the wallet backend
One which responds to user input and calls other things

I'm also not sure what a ContractId is. The wallet doesn't know about contracts, those are something the SCB knows about if anything. I think we could get away with just having ids for listeners, in which case they should probably be created by the wallet backend and returned when you register a listener.
What about signing and submitting transactions? That's the wallet's job.
runBlocks seems like an odd name me, since that doesn't really explain what we're getting back, which is a notification. I'd call it something like await.
When will runBlocks ever return Left?
There are two approaches to listeners and events which I think Jann and I discussed before in some old comment thread:

Registering and deregistering listeners are their own actions, awaiting just gets an event and doesn't do anything to the listeners.

Possibly this makes more sense in a multi-threaded model, since we may want to add more listeners after we call runBlocks but before it returns, e.g. in response to user input.

Listeners are removed as soon as they receive an event

If you want to listen to many events you have to resubscribe the listener each time.
The advantage is that you just need a single function, which takes the listener and returns when it triggers, also removing the listener.

Seems reasonable, just a few clarifications

Does ContractId refer to an instance of the contract? If so then it will have to be generated by the app platform

It is just an identifier I use in runBlocks, it can really be anything, but it should identify a contract, hence the name :)

Will the mock wallet delete events after they have been consumed by 'runBlocks'?

I would like to say no. This would be a hidden state and that makes life more complicated. At the same time I don't think we can offer any guarantees since wallet may not have all the blockchain downloaded.

I'm slightly unclear about the architecture: I think what happens is:

The SCB is going to use this interface.

The SCB will probably have two threads for interaction with the wallet backend:

One which calls runBlocks so it can respond to notifications from the wallet backend
One which responds to user input and calls other things

I'm also not sure what a ContractId is. The wallet doesn't know about contracts, those are something the SCB knows about if anything. I think we could get away with just having ids for listeners, in which case they should probably be created by the wallet backend and returned when you register a listener.
What about signing and submitting transactions? That's the wallet's job.
runBlocks seems like an odd name me, since that doesn't really explain what we're getting back, which is a notification. I'd call it something like await.
When will runBlocks ever return Left?
There are two approaches to listeners and events which I think Jann and I discussed before in some old comment thread:

Registering and deregistering listeners are their own actions, awaiting just gets an event and doesn't do anything to the listeners.

Possibly this makes more sense in a multi-threaded model, since we may want to add more listeners after we call runBlocks but before it returns, e.g. in response to user input.

Listeners are removed as soon as they receive an event

If you want to listen to many events you have to resubscribe the listener each time.
The advantage is that you just need a single function, which takes the listener and returns when it triggers, also removing the listener.
I'm slightly unclear about the architecture: I think what happens is:

The SCB is going to use this interface.

The SCB will probably have two threads for interaction with the wallet backend:

One which calls runBlocks so it can respond to notifications from the wallet backend
One which responds to user input and calls other things

I'm also not sure what a ContractId is. The wallet doesn't know about contracts, those are something the SCB knows about if anything. I think we could get away with just having ids for listeners, in which case they should probably be created by the wallet backend and returned when you register a listener.

That is what ContractId is. It identifies the sets of hooks we listen for when runBlocks is called.

What about signing and submitting transactions? That's the wallet's job.

This is one of the points where I think we may want to discuss a bit. Right now we give a lot of control to the users in the way they build their transactions, balance, etc. I was thinking of merging balance + fee management + signing + sending in one method. If we want this then there should only be one handleTx endpoint, if not we will probably need to add more.

runBlocks seems like an odd name me, since that doesn't really explain what we're getting back, which is a notification. I'd call it something like await.

I do not have any preference here. However, note that this method does not await, it's more like a filter / search over the blocks, starting from start block looking for events matching specified hooks. What about scanBlocks?

When will runBlocks ever return Left?

If from the specified slot up to the current slot there have been no events matching the conditions specified by the hooks.

There are two approaches to listeners and events which I think Jann and I discussed before in some old comment thread:

Registering and deregistering listeners are their own actions, awaiting just gets an event and doesn't do anything to the listeners.

Possibly this makes more sense in a multi-threaded model, since we may want to add more listeners after we call runBlocks but before it returns, e.g. in response to user input.

Listeners are removed as soon as they receive an event

If you want to listen to many events you have to resubscribe the listener each time.
The advantage is that you just need a single function, which takes the listener and returns when it triggers, also removing the listener.

We are going for the second approach, but we do have an inherently asynchronous model here. So we need to functions. One that specified the listener (adds the hooks - listen) and one that scans the chain up to the current slot for matches (runBlocks).

That is what ContractId is. It identifies the sets of hooks we listen for when runBlocks is called.

I think it would be cleaner to have one id per hook, rather than one per "set of hooks".

This is one of the points where I think we may want to discuss a bit. Right now, we give a lot of control to the users in the way they build their transactions, balance, etc.

"Users" now means the wallet, since we're talking about the wallet backend, right? I think it's okay for the wallet to have lots of control.
Having said that, I immediately realised that if we're talking about the wallet backend then it doesn't sign transactions, nor does it balance transactions (that's the wallet's job). I'm now confused again: which API is this?

I do not have any preference here. However, note that this method does not await, it's more like a filter/search over the blocks, starting from start block looking for events matching specified hooks. What about scanBlocks?

Ah I see, we have a fundamental disagreement about whether we're doing polling or callbacks.
I'd assumed we were doing callbacks (which is what the current design does), so you register a listener and a callback with the wallet backend, and it calls you when the listener triggers (maybe never, or maybe there's a timeout, or who knows).
The alternative is that the wallet has to poll the backend to find out if anything has happened, which I think is your solution.
My (limited) understanding is that:

If the server has lots of clients, polling can be better since callbacks requires the server to do more.

Our server (the wallet backend) has only one client.
-If the client cares more about its own schedule then polling is better, if it cares more about responding quickly to events then callbacks are better.
We care more about responding quickly, I think.

Polling systems are easier to shut down and start up again.

We do care about this, but I think we can work something out.

We should also check with the wallet folks what kind of interface they're expecting, but my guess is it's going to be callback-based.

@raduom wrote

I was thinking of merging balance + fee management + signing + sending in one method

That won't work because for one the signing is done by a different process. So the txn would go to the wallet to be balanced & have fees added, then to the signing process, then back to the wallet which submits it to the blockchain. Sending the txn around is part of what the SCB does.
For the mock wallet this means we need a separate HTTP endpoint for signing transactions, as well as one for submitting transactins to the chain.
@michaelpj  wrote

I think it would be cleaner to have one id per hook, rather than one per "set of hooks".

I agree

We should also check with the wallet folks what kind of interface they're expecting, but my guess is it's going to be callback-based.

I think it's going to be polling for the first iteration (this is what I told @raduom so that explains the proposed interface). I'll confirm in the call tomorrow.

I think it's going to be polling for the first iteration

Ah okay, then ignore me. In that case, what about calling the function poll/pollListeners?
(Incidentally, I know we've been calling these things "hooks", but we might be better off with "listeners" or "handlers" which I think is more standard.)

Suggested API:
listen :: ListenerId
       -> Slot
       -- ^ The slot where we start listening for the Hook.
       -> Hook
       -- ^ The hooks are: watch address and wait for slot
       -> ()

poll :: ListenerId
     -> Slot
     -- ^ The slot where we start streaming events.
     -> Either Slot (Event, Slot)
     -- ^ There may be no matching event up to the current slot
     --   (left branch of the Either) or we have an event
     --   that needs processing, so we suspend streaming
     --   at (snd . fromRight)

balanceTx :: UnbalancedTx
          -> Error String Tx
          -- ^ We may be unable to balance the transaction.

sendTx :: Tx
       -> Error String ()
       -- ^ We may be unable to send this transaction.

currentSlot :: Slot

I've made a new iteration of the API.

Renamed ContractId to ListenerId
Renamed runBlocks to poll (given the first type is ListenerId, it reads close to Michael's suggestion of pollListener I think, and it is smaller. However, we can change the names however we see fit).
Added a sendTx (I was unaware that the signing process was separate).
Note: This API should be able to support only the new contract API (this follows from conversations with Jann).

I think listen should be:
listen :: Slot
       -- ^ The slot where we start listening for the Hook.
       -> Hook
       -- ^ The hooks are: watch address and wait for slot
       -> m ListenerId`

i.e. the wallet backend should get to create ids.
We need a way to unregister listeners. We also possibly need a way to query them, or some notion of a session. Otherwise if the wallet crashes without unregistering its listeners, it may just re-register them when it comes back up, resulting in leakage.
That said, if we had a session, we would probably handle keeping it alive by sending keep-alive messages, and deregister its listeners when we hadn't heard from it in a while. We could just implement the same thing at the listener level, and say that if you haven't polled a listener for long enough it dies, but perhaps that's annoying.
As for poll, what about:
poll :: ListenerId
     -> SlotRange
     -- ^ The slot where we start streaming events.
     -> m [Event]

i.e. it asks for a range of slots (this can therefore include gradually polling segments of the past), and it gets back a list of events in order instead of just the first one. If the tail end of the slot range is later than the present, it could either give an error or just block until we get to that slot.
Or it could give you back some kind of fancy stream of events, and then asking for an unbounded slot range would be equivalent to the callback approach. Probably too complicated, but maybe worth thinking about.
IMO everything should just be in some monadic context that includes errors, so the signature of sendTx should just be:
sendTx :: Tx -> m ()

I still think balanceTx does not belong in this since this is the wallet backend API. The wallet backend doesn't know who the user is or what funds belong to them so it can't balance transactions.

Note: While I use Haskell syntax for functions, this is meant to be a REST endpoint API. By m () you mean to consider the fact that there may be errors?
Also, returning a [Event] is not very useful as the contract may update the list on hooks on each Event, so what we listen for may change whenever an Event is received.
How about this:

Note: While I use Haskell syntax for functions, this is meant to be a REST endpoint API. By m () you mean to consider the fact that there may be errors?

Yes, that's what I meant. I was confused because you had separate error handling for balance and submit, whereas I'd just shove that into the monad. That said, we obviously do want to distinguish between client recoverable errors like "transaction didn't validate" vs e.g. transport layer errors.

Ok so the call this morning with @rhyslbw and @mchakravarty clarified a few things:

We don't need to use polling for the blockchain events after all (my mistake, sorry for the confusion). We can do a subscription instead.
The signing of transactions is done by a separate process, as stated before. But the following points I had not considered until now.
(a) the signing process runs on the client, ie. in Javascript land - so we need to make sure that it comiles with GHCJS (the tricky part is the cardano-crypto package. For the mockchain we only need ED25519 for signing, and SHA2 / SHA3 256 for signatures. So the "mock signing process" could use an external JS implementation of those algorithms, via the JS FFI)
(b) Coin selection probably needs to happen in the same place as the signing. It's true that in theory you only need to know the public keys to do coin selection, but in practice new private/public keys pairs are generated all the time and so it makes sense to do the coin selection in the process that knows all the current keys. (in the mockchain each wallet has exactly one private/public key pair which is not realistic)

That means the mock wallet (native Haskell .exe) is only responsible for

Submitting signed and balanced transactions to the mockchain
Registering event triggers and informing clients when mockchain events happen

The mock signing process (JS library produced by GHCJS) will be responsible for

balancing (incl. coin selection) and signing transactions

I'll make a separate issue for the signing process.

That means the mock wallet (native Haskell .exe) is only responsible for

Mock wallet backend right? Sorry to keep going on about this, but I at least keep getting those two muddled.
I'm a bit confused about what is in this "signing process". I thought it would essentially just be a "keyring", i.e. a hardened piece of code that has one job which is to look after the keys and not leak them, and occasionally sign things. But if it's doing coin selection then it also needs access to a whole bunch of the wallet's state too...

Also, the more I think about this the more I worry about what happens when either or both of the wallet and the wallet backend crash. There must be existing approaches to this kind of callback/subscription/listener problem that handle this, we should poke around.

Mock wallet backend right?

Yes that's right. I'll call it blockchain client from now on as suggested in slack

I thought it would essentially just be a "keyring", i.e. a hardened piece of code that has one job which is to look after the keys and not leak them, and occasionally sign things.

Yeah that was my understanding as well but it's not the case

There must be existing approaches to this kind of callback/subscription/listener problem that handle this, we should poke around.

Like a message bus? I always assumed that the SCB would take that role.

Like a message bus? I always assumed that the SCB would take that role.

I honestly don't know. But here are some bad things that could happen:

Wallet crashes, and either never comes up or comes back up and forgets about a listener, blockchain client keeps listeners indefinitely. Result: blockchain client keeps accumulating information for that listener forever.
Blockchain client crashes and forgets about a listener. Wallet queries it later, gets error, no way (?) to get data that was missed while client was down/listener was forgotten.

Thinking about it, it would be really nice if we could have a stateless operation like Radu suggets:
poll :: SlotRange -> [Hook] -> m Event

If that works, then we can have a quasi-stateless solution:

The wallet can tell the blockchain client about information it may want: this allows the blockchain client to fetch it incrementally and ahead of time.
However, the wallet will always get the information it asks for, it might just be slower if it hasn't told the blockchain client to listen for it.

This way our state just affects how fast the blockchain client  can respond, so the worst case is performance degradation instead of incorrect behaviour.

Signing can not be in the node client (which may run on a server distinct from the client device of the end user UI/app) for a variety of reasons:

It may require a hardware dongle (which is with the user and only accessible on the client device).
We want it air gapped from the node client, which will typically run on the same machine as the untrusted contract code.
One node client may serve multiple end user devices.

All the issues related to dealing with crashes, restarting services etc is something the Application Platform needs to handle IMHO as it does orchestrate the system.

Suggested API:
data QueryResult = NoMatchFound
                   -- ^ No match was found when searching in SlotRange
                 | Synchronizing
                   -- ^ There is no data available, but the node client has
                   --   started to sync the requested data (try again later)
                 | FoundMatch [Event]

poll :: Maybe SlotRange
     -- ^ An optional slot range where we start polling events.
     -> Address
     -> m QueryResult

sendTx :: Tx
       -> m ()
       -- ^ We may be unable to send this transaction.

currentSlot :: Slot

Changes:

removed signing and balancing (which I understand will be done by the signing process).
removed the Hook and kept only watching addresses (the application platform can use currentSlot for polling the slot number)
added the QueryResult data type to mirror my (our) understanding of how the wallet currently works (it can fetch historical data about addresses we care about, and, optionally, limit the data to a slot range)

poll looks OK to me.
I think we should be clearer about the Event type though. In the current implementation Event = Ledger.Tx - the whole transaction that touched an output at the address. But the contracts just use the transaction to construct the UTXO set at the address, discarding all the other information. So maybe it's enough to say Event = [(Ledger.TxOut, Ledger.TxOutRef)] (we need both the output and the outref to spend the input), and then poll would return the UTXO set at the end of the slot range (or at the current time if it's unbounded).

I don't see a reason to have NoMatchFound as distinct from "here's a stream of events but it's empty".
I don't like Synchronizing. What does a user actually do in response? Just wait for some unspecified period of time? At the very least, it should be a Future or some kind of waitable thing so it can get notified when it's done, but I think it would really be nice for it to just return a stream of events.

Waiting on the stream does the right thing if the wallet is still synchronizing.
We can easily start processing the first event when we get it.
We probably want some way to send a cancellation request if we timeout or we've got enough data.
We can build a streaming interface on top of a simpler one if that's what the real implementation wants, so I think we might as well use it for our mock version.

I think we should be clearer about the Event type though. In the current implementation Event = Ledger.Tx - the whole transaction that touched an output at the address. But the contracts just use the transaction to construct the UTXO set at the address, discarding all the other information.

I think it's fine for our low-level API to get the whole transaction. We might care about other things in the future, so I think this makes sense and we can build other stuff on top of it.
Consider e.g. a contract that waits for person X to pay to a script address: then it's not enough to see the UTXO set, you also want to see how it was made.

NoMatchFound. I wanted to clarify this as an option. In hindsight, I agree we should remove it.
There is something I do not understand here. The specification is for a REST endpoint, that will probably talk to a javascript client. Are you saying you would like a web socket here that maintains a connection and feeds the data to the client?
I think that our low-level API should model the real application (or a future version thereof). If other people write contracts against the playground, they will (reasonably) expect them to run on the real chain as well. So we should check with the wallet if they can and will provide this data to us.

The specification is for a REST endpoint, that will probably talk to a javascript client.

Hm, I was thinking this is the functional interface for the node client, but I'd forgotten that we were actually planning to write this to be used by the app platform until the node client catches up. Hmm.
In that case I guess we either implement the streaming ourselves on top of some kind of repeated querying interface, or we see if we can use some kind of streaming HTTP API. We still don't want to make it too hard for the app platform to do its job.

I think that our low-level API should model the real application (or a future version thereof). If other people write contracts against the playground, they will (reasonably) expect them to run on the real chain as well. So we should check with the wallet team if they can and will provide this data to us.

My understanding from the call was that the wallet gets precisely the transactions that pay to that address. So passing that information on directly seems like the simplest thing, which is what I was suggesting.

That means the mock wallet (native Haskell .exe) is only responsible for
Submitting signed and balanced transactions to the mockchain
Registering event triggers and informing clients when mockchain events happen

I'd suggest not scoping this service to being a mock. The interface with the node will change as part of integration, but that's just standard progression of the software to support anything other than the mockchain. We will get a lot of value thinking about this service as a first-class node client

Registering event triggers and informing clients when chain events happen

This is the primary feature, and what I think the node client should be named after. In my early models I had this service termed chain subscriber.

Submitting signed and balanced transactions to the network

cardano-wallet is implementing this feature for Byron/Shelley now, but should be identical in the Goguen era codebase. The Haskell node design says that common functionality will be lifted to core libraries for clients to access, so best to align with @KtorZ and apply what's already in development. It makes sense for the new client to expose this API, but it's also conceivable in a scaled out system for the submission service to be separate since it's stateless (unlike the chain subscriber) and can be treated as ephemeral.
Subscription design
GraphQL subscriptions might be worth considering here to remove a lot of the implementation decisions, and result in conformance with an emerging common approach for push-based APIs
https://graphql.github.io/graphql-spec/June2018/#sec-Subscription
This approach puts the emphasis on defining the API, with transports then layered in for the particular use-case.
A good read to show how Apollo, a leading JS implementation has handled this:
https://github.com/apollographql/graphql-subscriptions
https://github.com/apollographql/graphql-subscriptions#pubsub-implementations


TypeError: Cannot perform 'get' on a proxy that has been revoked

I have a use case where I access the base state in an onSuccess callback of a mutation. Something along the lines of
create((base) => {
  // Make changes to base
  mutation.mutate(..., { onSuccess: () => ctx.route.invalidate(base.id) })
})

However, it seems like base is a proxy object that gets revoked at some point between the call to mutation.mutate() and the call to onSuccess(). Currently I'm copying the base into a separate object before every mutation like this
create((base) => {
  // Make changes to base
  base = { ...base }
  mutation.mutate(..., { onSuccess: () => ctx.route.invalidate(base.id) })
})

but that is not ideal.
Is mutative actually passing a proxy object as base? If so, is this addressable on your end and/or are there any other workarounds I could use?
Note: this issue does not occur if running React in Strict Mode.

@relsunkaev Mutative just drafts the baseState. I'm not sure how you're using it, but one thing is certain: the draft tree should not be used directly in any external function. You may encounter draft escaping,  for example:
  let a: any;
  const state = create({ a: { b: 1 } }, (draft) => {
    draft.a.b = 2;
    a = draft.a;
  });
  // Don't use 'a', 'a' is a draft.
  expect(() => {
    JSON.stringify(a);
  }).toThrowError(`Cannot perform 'get' on a proxy that has been revoked`);
  // state.a is a object, not a draft

It would be helpful if you could provide a minimal example to help identify and troubleshoot the issue.


ColumnValue introduction

Overview
An introduction of ColumnValue which was initially conceived by @MarkHerhold
Adds

The ColumnValue class which stores the results from the RDS and provides easy typed results

Updates

bump in tests to deal with the breaking change.

@MarkHerhold bummer, I have bumped into that socket hang up error as well

Fixes #6 - @MarkHerhold your idea behind ColumnValue I believe cements this usability issue.  Marking closed on this PR.

Fixes #7 - ColumnValue provides this and supports enum as denoted.

@cbschuld just taking a look at the new code and there will still be a problem with Decimal columns saving and reading.

@cbschuld just taking a look at the new code and there will still be a problem with Decimal columns saving and reading.


How to Inferance?

The documentation does not make it clear how to perform inference using the lambda attention.

Hello!
If you are questioning about generation, this section probably helps: https://github.com/Glaciohound/LM-Infinite#generation.
The function to be called is model.generate, which is implemented in models.model_base.Model_Base.generate(), which is worth checking  out ^_^.
Best


⚠ Bofrost.be has degraded performance

In 77ce3d1, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 945 ms

Resolved: Bofrost.be performance has improved in 9b2dc16 after 6 minutes.


v14 not running correctly in linear mode

i have problems with v14 when switching to linear:
no CVL limit is displayed there and the driver is no longer recognized under DVCC.
I have the feeling that the driver is not working properly.
During a comparison I noticed that in the new utils.py there is no longer an if LIMITATION_MODE query.
how does the driver know which settings to use for linear and step?

I see now that I left the Limitation mode setting a bit inconsistant to how the other settings are set. You switch between Step and Linear by commenting out line 37 and removing the comment from line 38.
So for the normal Step mode you should have
LIMITATION_MODE = "Step"
# LIMITATION_MODE = "Linear"

while if you want to use Linear mode you should have
# LIMITATION_MODE = "Step"
LIMITATION_MODE = "Linear"

All the Limit Attributes that are Enabled for Charge/Discharge will then be applied. So all their settings must be populated.
If something is nor working, can you please provide the serial battery log files

Hi Louis,
thanks - this is exactly how I did it and the result is like described above. Even the MPPT switch of due to missing BMS.

How can I retrieve the serial battery log file?

Identical to me. made the change. The only thing I didn't do was delete the comment after #
Please also instruct me how to get the log file.
Possible it is the firmware? i use 3.00 ~8

same Firmware on my site 3.00 ~8

It could be the firmware (I tested on 2.92). But might also be something else.
For the log file instructions see https://github.com/Louisvdw/dbus-serialbattery/wiki/Troubleshoot#check-the-log-files-on-your-gx-device

Hi Louis,
pls find attached the log files
„Serialbattery #14 (Step)“
root@einstein:~# tail -f /data/log/dbus-serialbattery.ttyUSB0/current
@40000000638e151e13254c6c INFO:SerialBattery:Testing Jkbms
@40000000638e151e1aeb903c INFO:SerialBattery:Connection established to Jkbms
@40000000638e151e1aebb364 INFO:SerialBattery:Battery connected to dbus from /dev                                                                                /ttyUSB0
@40000000638e151e1b7040fc INFO:SerialBattery:=== Settings ===
@40000000638e151e1b81cd2c INFO:SerialBattery:> Connection voltage 50.68V | curre                                                                                nt -0.62A | SOC 7%
@40000000638e151e1bf08104 INFO:SerialBattery:> Cell count 16 | cells populated 0
@40000000638e151e1c16f8ac INFO:SerialBattery:> CCL Charge NoneA | DCL Discharge                                                                                NoneA
@40000000638e151e1c73f944 INFO:SerialBattery:> MIN_CELL_VOLTAGE 2.9V | MAX_CELL_                                                                                VOLTAGE 3.5V
@40000000638e151e238a9c24 INFO:SerialBattery:DeviceInstance = 1
@40000000638e151e239955ac INFO:SerialBattery:com.victronenergy.battery.ttyUSB0
„Serialbattery #14 Linear“
root@einstein:~# tail -f /data/log/dbus-serialbattery.ttyUSB0/current
@40000000638e18f814a5e95c INFO:SerialBattery:Testing Daly
@40000000638e18f82665db5c ERROR:SerialBattery:>>> ERROR: No reply - returning
@40000000638e18f82676179c INFO:SerialBattery:Testing Daly
@40000000638e18f838351f3c ERROR:SerialBattery:>>> ERROR: No reply - returning
@40000000638e18f83849dbd4 INFO:SerialBattery:Testing Jkbms
@40000000638e18f90f33c304 ERROR:SerialBattery:>>> ERROR: No reply - returning
@40000000638e18f90f483d34 INFO:SerialBattery:Testing Lifepower
@40000000638e18f921a0aa5c ERROR:SerialBattery:>>> ERROR: No reply - returning
@40000000638e18f921b14074 ERROR:SerialBattery:>>> ERROR: Incorrect Data
@40000000638e18f921c2f79c INFO:SerialBattery:Testing Renogy
@40000000638e18f933cd96cc ERROR:SerialBattery:>>> ERROR: No reply - returning
@40000000638e18f933f22a14 INFO:SerialBattery:Testing Renogy
@40000000638e18fa09d612f4 ERROR:SerialBattery:>>> ERROR: No reply - returning
@40000000638e18fa09e6b8ac INFO:SerialBattery:Testing Ecs
@40000000638e18fa2b81e2d4 ERROR:SerialBattery:ERROR >>> No battery connection at                    /dev/ttyUSB0
root@einstein:~# tail -f /data/log/serial-starter/current
@40000000638e18ef0a1834a4 INFO: Create daemontools service vedirect-interface.ttyUSB1
@40000000638e18f52781b36c INFO: Start service vedirect-interface.ttyUSB1 once
@40000000638e18f93ae051ac INFO: Create daemontools service dbus-serialbattery.ttyUSB1
@40000000638e18fe075484ac INFO: Create daemontools service gps-dbus.ttyUSB0
@40000000638e19000ad644e4 INFO: Start service dbus-serialbattery.ttyUSB1 once
@40000000638e1904111c41b4 INFO: Start service gps-dbus.ttyUSB0 once
@40000000638e190e319c6aa4 INFO: Create daemontools service vedirect-interface.ttyUSB0
@40000000638e191437184944 INFO: Start service vedirect-interface.ttyUSB0 once
@40000000638e19181b4fdfec INFO: Create daemontools service dbus-cgwacs.ttyUSB0
@40000000638e191e2503b734 INFO: Start service dbus-cgwacs.ttyUSB0 once
„Switch to USB1“
root@einstein:~# tail -f /data/log/dbus-serialbattery.ttyUSB1/current
@40000000638e19001e529c84 INFO:SerialBattery:Testing Jkbms
@40000000638e190026366304 INFO:SerialBattery:Connection established to Jkbms
@40000000638e19002659871c INFO:SerialBattery:Battery connected to dbus from /dev/ttyUSB1
@40000000638e1900266c0964 INFO:SerialBattery:=== Settings ===
@40000000638e19002687a3cc INFO:SerialBattery:> Connection voltage 49.3V | current -0.2A | SOC 5%
@40000000638e190026aa9134 INFO:SerialBattery:> Cell count 16 | cells populated 0
@40000000638e190026bf8864 INFO:SerialBattery:> CCL Charge NoneA | DCL Discharge NoneA
@40000000638e190026e004cc INFO:SerialBattery:> MIN_CELL_VOLTAGE 2.9V | MAX_CELL_VOLTAGE 3.5V
@40000000638e19002d4a1014 INFO:SerialBattery:DeviceInstance = 3
@40000000638e19002d6aa004 INFO:SerialBattery:com.victronenergy.battery.ttyUSB1

i hope thats rigt

Hi Louis,
found another topic which is not clear for me. Changing the DCL to another value stays at the same level
Could you check this as well, please?
Thx
Dirk

@Bonzai10 you log show that the driver is running, so not sure what is happening there.
For @DirkReudenbach the log show that the driver is running normally when in Step and that it does not even pick up the JKBMS (or if there is a error that may be earlier in the logfile?) If the logfile show and error with the line numbers then I can check that.
For the DCL question you need to check each of the 3 limiting attributes. Between them which ever limits to the smallest value will be used.  You need to disable them one by one to see which one is the limiting value currenlty for you, or you can calculate it from the attributes and the limiting setting for those. It should be much easier when I have the GUI finished.

Can you show me the log file with the error when your run Linear please.

Cool work, thanks for that! I'm looking forward to setting all the magic in the UI. :-)
Now my problem:
Since I keep having problems with the internal SoC calculation of the Daly, I now open the lines in the "SOC limitation" section
CCCM_SOC_ENABLE = False
DCCM_SOC_ENABLE = False

set. The battery is now charged again up to 55.2V (3.45V*16). In places, the SoC had already jumped to 100% at 52.5V and charging was stopped.
2 questions:

can I leave the setting without "SOC limitation"?
what effects does the "System Setup/Battery Monitor" setting on Shunt instead of Daly have on your program?

You can disable the SOC attribute limitation, yes. That is no problem.
It is also no problem if you disable all the attribute limits. It will just mean that the charge currents your battery specify to be charge with will be a fixed value. Many batteries work like that.
All these limits do is that if possible problems arise then it will limit the current and hopefully reduce/prevent the problem.
For instance if your battery temperature becomes to high, then the reduced current would mean there would also be less heat and the battery will cool down.
The driver is not effrected if you do not choose it as your Battery Monitor. The GX system is effected by not using the data from your battery for it's control. The easiest explanation would be that when you choose as the battery monitor would be the device the the SOC for your system is being read from.

Thats above are the logs from linear

OK thanks for the answer.
Then I'll leave it like that and watch.
I think it works best for my setup.

There is a new patch release that fix a few issues and add more details to the log file. See if it helps.
https://github.com/Louisvdw/dbus-serialbattery/releases/tag/v0.14.1

with the new patch nothing is running. no step, no linear

Hi Louis, you do a very, very good job. many thanks.
but as i stay not at home this week, i have made a rollback to v0.14beta1.

@Bonzai10 it seems that the serialbattery has move to another USB port. You 3rd screenshot show it on ttyUSB1. That is why the log file on ttyUSB0 show nothing.
I see that CVL show empty. I'll see if I can replicate that.

I think some of the issues here have to do with https://github.com/Louisvdw/dbus-serialbattery/issues/334

try fix in #353 - build V0.14.2

Hi, sorry it took me so long.
Now it works, but under the linear function it takes the value as CVL that is set as FLOAT_CELL_VOLTAGE under "Step"?!
does anything else need to be changed here?

hi, since v 014.3 doesn't work for me in linear mode either (after testing for a long time, I found that it still uses the Step settings). I'm going back to 014.1 and waiting for new updates. Thank you for the excellent driver!

Hi, sorry it took me so long. Now it works, but under the linear function it takes the value as CVL that is set as FLOAT_CELL_VOLTAGE under "Step"?! does anything else need to be changed here?

I seem to be having the same issue, when linear is enabled i'm stuck with a CVL of 3.35v/13.4v and that's my float setting. Tried upping the max cell voltage in all the other areas with no luck. Disabled linear mode and CVL is back to 3.45/13.8v. I'm using V14.3.


additional information

See also:
https://www.striim.com/docs/en/replicating-oracle-data-to-azure-cosmos-db.html
https://www.striim.com/docs/en/cosmos-db-writer.html

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 92ee2601-48a3-58b0-1c39-c8a761f74482
Version Independent ID: e6eaac91-41ce-c4dc-5342-636d26183a5d
Content: Migrate data to Azure Cosmos DB SQL API account using Striim
Content Source: articles/cosmos-db/cosmosdb-sql-api-migrate-data-striim.md
Service: cosmos-db
GitHub Login: @SnehaGunda
Microsoft Alias: rimman

Closing this as duplicate of the following thread:
https://github.com/MicrosoftDocs/azure-docs/issues/37258
The links provided in this document will be added there as well.

@NavtejSaini-MSFT they're two sets of links. This page is for using Striim's CosmosDBWriter, which uses the Cosmos DB SQL API. The other one is for using Striim's DatabaseWriter with the Cassandra API.

Please use following link for Cosmos DB SQL API:
https://github.com/MicrosoftDocs/azure-docs/issues/37258
Please use following link for Cosmos DB Cassandra API
https://github.com/MicrosoftDocs/azure-docs/issues/37263


OS.get_window_safe_area() returns incorrect size on Android when not in fullscreen

Godot version
3.4.4, 3.5 RC2 and master
System information
Android 8
Issue description
OS.get_window_safe_area() uses the display size not the window size; so when Godot is not in full-screen mode e.g. when immersive mode is disabled, and the window size is not the display size, the calculations for get_window_safe_area() are wrong.
Steps to reproduce
Disable immersive mode. Call OS.get_window_safe_area().
Minimal reproduction project
No response

To clarify, Android API level < 28 refers to Android 8 and below.

Actually the problem applies to all versions of Android not just to earlier versions of Android. OS.get_windows_safe_area() is using the display size not the window size to calculate the safe area; so when immersive mode is disabled, and the window size is smaller than the display size, the OS.get_windows_safe_area() calculations are wrong.

¿are there any updates?.
this issue seems to be complately forgotten for 11 months.

get_display_safe_area ( ) const
Returns the unobscured area of the display where interactive controls should be rendered.

Does this description mean that the virtual keyboard should also be taken into account?

get_display_safe_area ( ) const
Returns the unobscured area of the display where interactive controls should be rendered.

Does this description mean that the virtual keyboard should also be taken into account?

yes, this means the safe area is smaller when the keyboard blocks part of the screen.

Did it work properly in the past?

get_display_cutouts ( ) const
Returns an Array of Rect2, each of which is the bounding rectangle for a display cutout or notch. These are non-functional areas on edge-to-edge screens used by cameras and sensors. Returns an empty array if the device does not have cutouts. See also get_display_safe_area.
Note: Currently only implemented on Android. Other platforms will return an empty array even if they do have display cutouts or notches.

This function does not return any data (on my Samsung Tab, Android 13)
and DisplayCutout cutout = insets.getDisplayCutout(); is also = null
https://github.com/godotengine/godot/blob/13a0d6e9b253654f5cc2a44f3d0b3cae10440443/platform/android/java/lib/src/org/godotengine/godot/GodotIO.java#L189
the following line means, from Android 9+
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P)

https://developer.android.com/develop/ui/views/layout/edge-to-edge
This topic is very complex, on my Google Pixel 4a can test it, cutout is not null

uses the display size not the window size

I am trying to find solutions for this, with no guarantee of success 😃

What else should be tested?
https://github.com/godotengine/godot/assets/41921395/6a08baad-aab7-4242-a43d-3a8bc320b650


Add the wtx project

For some reason wtx was removed... Let me explain the project again.
wtx is, among other things, a RFC6455, RFC7541, RFC7692 and RFC9113 implementation intended to allow the development of web applications through a built-in server framework, a built-in PostgreSQL connector, a built-in WebSocket handler and a built-in gRPC manager. There is also a built-in API client framework that facilitates the maintainability of large endpoints.
Here goes a list of related benchmarks:

https://c410-f3r.github.io/wtx-bench/
https://github.com/diesel-rs/metrics
https://i.imgur.com/Iv2WzJV.jpg
https://github.com/LesnyRumcajs/grpc_bench/pull/473
https://i.imgur.com/vf2tYxY.jpg

It's been more than 6 months.
ping @ibraheemdev
ping @giraffate

Sign... Closing due to the lack of feedback.


"Emoji Theft" mode.

When a Discord Nitro User uses an external emote, the bot should automatically add the external emote to its collection. (As an Opt-In)

yeetus reportus


Update master with latest changes

Refactor basic switch architecture (by @balloob)
Refactor basic light architecture (by @balloob)
Frontend: allow browsing different days in the logbook (by @balloob)
Frontend: allow browsing different days in history (by @balloob)
Media Player: Kodi platform added (by @ettisan)
Sensor: Forecast.io platform added (by @fabaff)
Sensor: systemmonitor platform upgraded (by @fabaff)
Device Tracker: TP-Link tracker added (by @michaelarnauts)
Notification: File platform added (by @fabaff)
Arduino support including switch and sensor platform (by @fabaff)
Frontend: Upgrade JavaScript backend to use NuclearJS (by @balloob)

I'm currently using this version and have no issues. :+1:


Hide Access denied finding property "net.dns?" log

Hi, is there any way I can remove or hide this kind of log? I know it's just a warning and I should be ignored it, but it's really hard to see my intended log, when 80% of log screen is full of this message.
Thanks

You can control it by calling the setLogFilter method.

Can you elaborate a bit on top of that @LichKing-2234?  Full command, maybe? Thanks !


arch: riscv: linker script: add support for rom_start section

With this change, we can put contents into rom_start section
by calling zephyr_linker_sources(ROM_START ...)
Signed-off-by: Dino Li<EMAIL_ADDRESS>Change-Id: If1169423b013d3e4df52d91cdb2fbdddc3bace7b

You also should update cmake/extensions.cmake's description of zephyr_linker_sources to include RISC-V in the ROM_START location description.

Done.


Please update documentation

Im trying to install this library in a new 0.60.0 react native project but i cant, im getting errors with react-native-swift (because is outdated) and if i dont install this library im getting a lot of errors:
:1:9: note: in file included from :1:
#import "react-native-track-player-umbrella.h"
^
/Users/fer/Documents/musapp/ios/Pods/Headers/Public/react_native_track_player/react-native-track-player-umbrella.h:25:9: note: in file included from /Users/fer/Documents/musapp/ios/Pods/Headers/Public/react_native_track_player/react-native-track-player-umbrella.h:25:
#import "Quick.h"
^
/Users/fer/Documents/musapp/node_modules/react-native-track-player/ios/RNTrackPlayer/Vendor/AudioPlayer/Example/Pods/Quick/Sources/QuickObjectiveC/Quick.h:9:9: note: in file included from /Users/fer/Documents/musapp/node_modules/react-native-track-player/ios/RNTrackPlayer/Vendor/AudioPlayer/Example/Pods/Quick/Sources/QuickObjectiveC/Quick.h:9:
#import "QuickSpec.h"
^
/Users/fer/Documents/musapp/node_modules/react-native-track-player/ios/RNTrackPlayer/Vendor/AudioPlayer/Example/Pods/Quick/Sources/QuickObjectiveC/QuickSpec.h:1:9: error: 'XCTest/XCTest.h' file not found
#import <XCTest/XCTest.h>
^
:0: error: could not build Objective-C module 'react_native_track_player'

@fcaride Getting the same error trace you've copied above. Did you manage to fix this, and how?
If this is still a bug, would suggest renaming this issue to mark it as a React Native 0.60 compatibility issue.

No, i couldnt solve it yet ☹

It seems that intermediate rc Versions of the player were set to build the examples and tests from react-native-track-player as well. Utimately failing on those.
Can you try
npm i react-native-track-player@next

which will install the latest rc10 which should then build properly

Do i still need react-native-swift for the project? How would be the instructions for installing it on a new react project. React in the 0.60 version changed the react-native link command and does other things under the hood.
Thanks for the response

Sorry for the late reply.
Can you try the following, this worked for me:

npm i<EMAIL_ADDRESS>cd ios && pod repo update && pod install

react-native link is not necessary with RN 0.60.0 anymore. If you linked the libraries previously either remove all non RN pods or use react-native cli to create a new project and copy the Podfile over. Or start over with a clean 0.60.0 project.
Inside the Podfile the line
  use_native_modules!

imports all pods from the node_modules.

@huntie @fcaride still an issue or were you able to solve it with one of the latest RCs ?

Yes i could fix it! with the last release just doing a npm install works (without react-native-swift)
Thanks

Perfect @fcaride !
@dcvz you can close this one.

@mhabegger I follow your steps but I am getting 25 compiler issues
Swift Compiler Error Group

node_modules/react-native-track-player/ios/RNTrackPlayer/Vendor/AudioPlayer/SwiftAudio/Classes/AudioSessionController/AudioSessionController.swift:104:70: 'interruptionNotification' has been renamed to 'NSNotification.Name.AVAudioSessionInterruption'

'interruptionNotification' has been renamed to 'NSNotification.Name.AVAudioSessionInterruption'

Type 'AVAudioSession' does not conform to protocol 'AudioSession'

react-native-track-player/ios/RNTrackPlayer/RNTrackPlayer.swift:157:57: Type 'AVAudioSession.Category' (aka 'NSString') has no member 'playback'

@maamounapprise you should probably specify SWIFT_VERSION, please see #673

So I'm really not sure which version of react-native track player is stable. The current version when we use yarn add react-native-track-player is 1.2.2, but the example repo of this library is using branch dev, I already tried to use 2.0.0rc but it's unstable and there are a lot of issues remaining to that version, so what should I do now, so desperate


Suggestion is not working

Type: Bug
React suggestion are not working like "crfe"
and i try all methode like enable all disable all
Extension version: 4.4.3
VS Code version: Code 1.75.0 (e2816fe719a4026ffa1ee0189dc89bdfdbafb164, 2023-02-01T15:23:45.584Z)
OS version: Windows_NT x64 10.0.22621
Modes:
Sandboxed: No

System Info

Item
Value

CPUs
11th Gen Intel(R) Core(TM) i5-11300H @ 3.10GHz (8 x 3110)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: disabled_off

Load (avg)
undefined

Memory (System)
7.79GB (0.96GB free)

Process Argv
D:\react\Product Page & Cart --crash-reporter-id d5fbb61d-90b5-43db-8bd3-0b62349f46ff

Screen Reader
no

VM
0%

A/B Experiments
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263cf:30335440
pythondataviewer:30285071
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593:30376534
pythonvs932:30410667
cppdebug:30492333
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
azure-dev_surveyone:30548225
vscccc:30610679
pyindex848cf:30577861
nodejswelcome1cf:30587006
282f8724:30602487
89544117:30613380
pythonsymbol12cf:30657549

Same problem. Broken with latest VS Code update (v 1.75.0).

Same here!

same here!

Same here. In my case, 'tsarfc', 'rfc' ... doesn't work at all.

same here!

How have I become dependent on this library 🥹 Please try fix.

Latest VS Code update seems to have fixed it for me as well, but I had to quit all VS Code windows to get a clean restart. Using the "reload" button did not seem to work because it only reloaded one workspace.

This can be closed with the latest VS Code update


Newsletters: add #19 (2018-10-30)

I'm terribly, terribly sorry this is so late.  :-(
Otherwise, hopefully it's ok.  I won't be around this evening to address feedback, but I will check first thing tomorrow morning (around 06:00 EDT) and make any requested changes then.

I'm terribly, terribly sorry this is so late. :-(

No problem! Thanks as ever for writing it. I'll review it this evening.
@moneyball - are you still at work and feel like reviewing?

I made a few minor changes - take a look at them to make sure they're correct.
I also read the entire newsletter and tested it locally. Well written! I do not have the technical depth and history to confirm all of the info in notable merges, but it all seems to make sense to me.
tACK

@harding - I've pushed a suggested change in a commit. Feel free to squash it or drop it.
Otherwise looks great. ACK fbb4746caf0cb7eb173e60180268e13ab8fad6f1
@moneyball - your changes look good. Thanks.

Thanks both of you!  @jnewbery your description of ASICBoost was much better than mine!
I made a final small tweak to the introduction in and rephrased the text about Pierre's blog posts given that the residency program had more days than he has posts.  For review, those changes are in commit  d91a415 on a preservation of the full branch.  Otherwise, I've squashed on this branch.
Thanks again!

Thanks Dave. I've pushed one final change.
The residency was over 5 days, but the guest speakers gave their presentations on Mon-Thurs (Friday was left for residents to finish their projects and give demos). I've reworded the section to make it clear that Pierre's articles summarize all of the presentations. Let me know what you think.

squashed and merged


Avoid blank lines with federated training

Right now we use LOG(CONSOLE) << msg to print messages during federated training. But the evaluation callback already puts a newline in the message, resulting in blank lines being printed.
@trivialfis

hmm , is the CI triggered?


Add E_TOO_FAR and E_RETRY_WITH_SAFE

Coverage remained the same at 98.66% when pulling 40355318b60d49327a058fa6c0e270db7a53bca3 on ajfriend:grid_errors2 into 5e1692cf9e964afec4b3ddf75fdce64358c9dd2d on uber:master.

Question: Whenever we'd consider returning E_RETRY_WITH_SAFE, it it the case that the reason the error happened is that we ran into a pentagon? Or, are there multiple reasons, and we might want to also relay that information along in the error codes somehow?


This fixes #1

Thanks.
Is it possible to test this?

See #1 for a simple test scenario description. The PR should pass any test suite used for the original plugin.

Can you please pull this and publish to npm?
It's probably related to babel-core or babel-runtime loose dependencies in fly, but it looks like  fly-cssnano stopped working in any scenario - you can test it by updating fly to the latest version.
Using the fat arrow in that context is not a good idea anyway...

Strangely enough, I just noticed the original plugin is failing npm run test on Node.js 5.0. So this has nothing to do with babel - there's a problem with this getting rebound by the arrow function. I'm kind of wandering how did it ever work...

^ Yep, can reproduce that. Strange indeed. Sorry, I haven't had time to review the code and test before, have a big project on at the moment. :smile:

Released as v1.1.1.

Happens to everyone :-)
Thanks for taking the time and best of luck with your project!

@ben-eb @icflorescu Thanks for fixing this :+1:


Add koa.js support

req.cookie[key], res.cookie(), and res.clearCookie() are all valid for Express framework, but not compatible with Koa. So I replaced them with cookies module. Please take a review and I'll be happy to see it merged and new version published on npm repository. (otherwise I'll need to point to my github repo url in package.json for a while ;))

@jaredhanson is this repo going to be actively maintained or abandoned?


Connection with Profile datasets only

Issue in ./help/connections/create-connection.md
Hi, as far as I know, in a connection for CJA you need to have at least 1 event based dataset. I've checked the documentation and it's not mentioned, and the UI also does not prevent you to create a connection with profile dataset only. Can you please check and update the documentation accordingly?

You are correct, @angeli-adobe - at least one event dataset is needed. I have added this to the documentation.
https://experienceleague.adobe.com/docs/analytics-platform/using/cja-connections/create-connection.html?lang=en
Note that I am still fixing some formatting errors on this page.


Fails to link to mysql-client 9.0

It looks like there's no support for identifying mysql-client 9.0, released today. This is causing build failures, which can be overcome by pinning the mysql version. Would be great to support the latest release, however!

I'm happy to accept a PR for that, otherwise this is currently expected behavior as the libmysqlclient headers change in a incompatible way between versions. That means we cannot just allow future versions without having checked that they are compatible in any way or at least without providing some compatibility layer.

I just noticed that it might be helpful to write down what needs to be done:

Use the rust docker image and install the new mysql-client version there
Install bindgen in the docker image
Use https://github.com/sgrif/mysqlclient-sys/blob/master/DEVELOPMENT.md to generate bindings for the various supported targets (need to install the right cross compiler for these targets as well)
Adjust the build script here to handle the new version: https://github.com/sgrif/mysqlclient-sys/blob/4f9afd960779b463e05363279678da56f025015c/build.rs#L118-L217
Optionally updating the submodule in mysqlclient-src to use the new release (I would strongly prefer having that in a separate PR)


[build] efr32_sdk/wiseconnect-wifi-bt-sdk submodule pointing to stale commit

Problem
fatal: Fetched in submodule path 'third_party/efr32_sdk/wiseconnect-wifi-bt-sdk', but it did not contain 30361d9e5e70d42b2dba4da27aa65cff4481ac18. Direct fetching of that commit failed.

Also https://github.com/SiliconLabs/wiseconnect-wifi-bt-sdk/tree/30361d9e5e70d42b2dba4da27aa65cff4481ac18 has warning that commit doesn't exist and may be to outside fork.
Proposed Solution
Fix  third_party/efr32_sdk/wiseconnect-wifi-bt-sdk to point to a valid commit.

@jepenven-silabs is someone from SiLabs able to look into this?

This submodule is blocking build on a fresh clone of the tree on macos:
$ ./gn_build.sh
.--------------------------------
-- Environment bringup
'--------------------------------
Submodule path 'examples/common/QRCode/repo': checked out '8518684c0f33d004fa93971be2c6a8eca3167d1e'
Submodule path 'examples/common/m5stack-tft/repo': checked out 'a1ece2c500cf179db8f0c7dbc7bb8f3ace562142'
Submodule path 'third_party/cirque/repo': checked out '262ea7724667229f0d21d6a1c1e96d90415f0906'
Submodule path 'third_party/efr32_sdk/repo': checked out '175cbe761d2fab133725dab01abb1a149e23eb20'
error: Your local changes to the following files would be overwritten by checkout:
	examples/at_commands/teraterm/bt_spp_slave/resources/receive-message.png
Please commit your changes or stash them before you switch branches.
Aborting
fatal: Unable to checkout '4491826e48bfaaa6ce4d42ad5769d7f6447b8cbb' in submodule path 'third_party/efr32_sdk/wiseconnect-wifi-bt-sdk'
mturon-macbookpro1:turon mturon$ ./gn_build.sh
.--------------------------------
-- Environment bringup
'--------------------------------
error: Your local changes to the following files would be overwritten by checkout:
	examples/at_commands/teraterm/bt_spp_slave/resources/receive-message.png
Please commit your changes or stash them before you switch branches.
Aborting
fatal: Unable to checkout '4491826e48bfaaa6ce4d42ad5769d7f6447b8cbb' in submodule path 'third_party/efr32_sdk/wiseconnect-wifi-bt-sdk'

Commit 60adc7e7afb925fd55256c2baaa4ca9663a65d17 seems to have fixed this issue for me.


Added function for watchers in GitHub repo #242

I added the 2 functions, one gives the number of watchers and another gives the username of all the watchers of a repository.
Issue #242

Great work buddy @Sar-thak-3
Do not forget to

Share your contribution on socials(twitter mainly), tag us and Clueless 🫂
Give this repository a star ✨
Follow Clueless Community on GitHub ✅


Problems with pipeline

Expected Behavior
When tests failed - pipe line must show it

Current Behavior
Build from master Look at "Run codegen tests" they are failed, but pipeline is green.

Possible Solution

Fix test ( will be in PR #316 )
Fix pipeline script

Thanks, we will fix the tests

But need fix pipeline too. He doesn't work properly...

It's fixed, https://dev.azure.com/TrustWallet/Trust Wallet Core/_build/results?buildId=2808
11 tests, 27 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed


Feature: Allow options for no caret and alternate hover text

I'd like to have options for not using the caret and being able to set my own title attribute (for hover text) instead of having the name of the event being the hover text.
PR on the way.

Thanks for accepting my ideas!


Updating issue templates to add StackOverflow links

Nagging Assignee @wt-huang: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

@martinwicke Can you please take a look at this PR? Thanks!


api_version is ignored for sub-versioned operations with SdkProfile

The current implementation of profile-versioned operations properties on the main client class will override the requested REST API version in favor of the one defined in the internal default profile.
eg:
c = ComputeManagementClient(
  adalcred,
  subscription_id=subid,
  api_version='2016-04-30-preview',
  base_url=active_cloud.endpoints.resource_manager
)

print(c.virtual_machines.api_version)
print(c.disks.api_version)

I'd expect to get 2016-04-30-preview for both of these, but since disks is defined in the internal profile, it uses that value first (returning 2017-03-30 in this case). Short of supplying a different profile, there doesn't appear to be a way to get the requested API version for versioned operations sets defined by the default profile.
This can be worked around by passing an empty dictionary for the profile, but it's not intuitive without looking at the SDK source to see the default profile behavior, and I'm not sure if it's "kosher" (eg, is it safe to assume that the profile will always be a simple dictionary, and that empty is OK?)...

Hi @nitzmahone
I thoughts about this one, and I think this is confusing and you're right. I will release soon the new major version (kwargs only args, new LRO implementation, etc.) and I want to take this opportunity to refactor this one as well.
I want to:

Make api_version and profile mutually exclusive. This solves this issue here. Profile can take a None key if you want to say "everything else I didn't define explicitly".
I'm adding a Profile class. By default the new signature will then be:

def __init__(self, credentials, subscription_id, api_version=None, base_url=None, profile=Profile.default)

And Profile.default will be by default valued Profile.latest.
Meaning you can create your client this way if you want to explictly say "I want latest":
client = ComputeMangementClient(creds, sub, profile=Profile.latest)

I will support the known profiles as well:
client = ComputeMangementClient(creds, sub, profile=Profile.v2017_09_03)

profilecan still get a dictionnary as right now, I don't change that.
If you use default, you could also change the default profile as the application level:
Profile.default = Profile.v2017_09_03

This would mutate all created client automatically to the new profile if you do that in the middle of your application.
I would really appreciate if you can give me your thoughts on this :)
Thanks!
FYI @johanste

Everything I just said was released recently, and I even made Compute/Resource as stable 4.0.0/2.0.0.
Feel free to email me or comment if necessary :)
Thanks!


http_Server revice unidentifiable Chinese code?

@sebt3 @TechPriest

The problem might be that you call request->content.string() several times, since the string() call consumes the content stream (meaning the second time you call request->content.string() it will return an empty string).

Also, the output does not correspond with the code. Could you try reformulate your issue with a more simple code example where your problem arises (with corresponding output)?


[#54] Change ordering of action buttons on email row

This matches the ordering of Done, Delete, and Snooze. The done button was the one that was primarily messing with my muscle memory, this should address that. I can't touch the Pin, as that will make the interaction with Pinned items weird.

@abasiri It looks like there should be more spacing between the Done icon and the Pin.
Side note: Recently I've noticed some weirdness with that pin icon.
A few of the problems were inherited from Gmail:

Unlike the other action icons, you need to hover precisely over the icon itself for the hover event to occur. This isn't just a visual problem, if you try to click the general area, you'll end up opening the email instead.
It seems like the on-hover circle that displays around the pin icon is larger, or wider, than the other icons. For example, try mousing over two of the other icons that are next to each other, and you'll notice they keep to their own space. The pin icon encroaches on the space of the icon to its left (this happens even without your changes in this PR, that seem to have reduced the space to the left of the pin).
The pin is the only one of the actions that doesn't have a tooltip. Seems like something the Gmail team should fix.

One of them seems unique to this extension:

When hovering over the enabled pin, it shifts to the right, one or two pixels

Merging this and adjusting the spacing between Done and Pin.
I'll turn the other things I brought up into new Issues.


test-branch/execute-job/comment-from-wrong-user-on-pr/2bdaa599-1019-4cae-8de1-24a969d09490

PR for testing 47cdae02b297a9585b50fe8b78cff5080bcbc5fb

/canonical/self-hosted-runners/run-workflows 47cdae02b297a9585b50fe8b78cff5080bcbc5fb


Network services and Scheduler infra stacks show multiple versions available for upgrade

Version : Upgrade from Rancher v1.6.14 to v1.6.27-rc1
Steps:

Create a setup in v1.6.14
Create few user stacks
Upgrade to v1.6.27-rc1
After upgrade, Network services and Scheduler infra stacks show two versions available for upgrade as below:

Network services infra stack:
There are two versions available for upgrade v0.2.10 and v0.2.11

Scheduler infra stack:
There are two versions available for upgrade v0.8.5 and v0.8.6

Set the maximum_rancher_version: v1.6.26 for the above two templates show that the older versions do not show up for upgrade.

Tested with updated catalog on v1.6.27-rc1

Create a setup in v1.6.14
Create few user stacks
Upgrade to v1.6.27-rc1

After upgrade, Network services and Scheduler infra stacks shows one version available for upgrade as below:
Network services infra stack:

Scheduler infra stack:


CI Support

Description of the pull request

Run tests on Github Actions

Codecov Report

Merging #387 (efbe505) into master (0a5f6c4) will decrease coverage by 1.53%.
The diff coverage is 93.39%.

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

@@            Coverage Diff             @@
##           master     #387      +/-   ##
==========================================
- Coverage   89.18%   87.65%   -1.54%
==========================================
  Files          50       51       +1
  Lines        3403     3167     -236
==========================================
- Hits         3035     2776     -259
- Misses        368      391      +23

Impacted Files
Coverage Δ

Sources/ObjC/Pusher+ObjectiveC.swift
8.33% <0.00%> (-2.78%)
:arrow_down:

.../Integration/PusherClientInitializationTests.swift
100.00% <ø> (ø)

Sources/Services/PusherConnection.swift
77.31% <20.00%> (-1.74%)
:arrow_down:

Sources/Models/PusherChannel.swift
83.92% <33.33%> (-6.27%)
:arrow_down:

Sources/PusherSwift.swift
79.06% <50.00%> (-1.42%)
:arrow_down:

Sources/Models/PusherChannels.swift
68.08% <66.66%> (+0.64%)
:arrow_up:

Tests/Unit/Models/PresenceChannelTests.swift
95.68% <94.28%> (-0.35%)
:arrow_down:

Sources/Models/PusherPresenceChannel.swift
82.81% <100.00%> (ø)

Tests/Helpers/TestObjects.swift
100.00% <100.00%> (ø)

Tests/Integration/AuthenticationTests.swift
99.46% <100.00%> (-0.01%)
:arrow_down:

... and 11 more

Continue to review full report at Codecov.

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


Not working like expected in Safari.

Check in safari Mac os.

Hello @perichiappan :smile:
Thank you for providing screenshot. Sorry for this, as I'm struggling to constantly check it in iOS. But I'm trying to work on this to be able to use in apple devices.
I will write back once this is solved. Thank you again! :hugs:

Hi Edlyn, first of all thanks for all the good work. Very nice app.
The NaN issue isn't only a Safari problem. It appears also with the following browser: IE. EDGE and Mozilla. On Chrome it runs smoothly.

Hello @Mookseberg, thank you for the appreciation! :smile:
I am working with this issue while fixing/adding new methods and events! Will check it also in other browsers. Thank you for the feedback and screenshots. :smile:

Hi @edlynvillegas and @Mookseberg ! I was dealing with the same issue on Safari and IE. Seems like they don't like the date format that was used. Here's what I did:

instead of _.$cal_months_labels, I created a new array _.$cal_months = ['01', '02', '03', '04', '05', '06', '07', '08', '09', '10', '11', '12']
I replaced _.$cal_months_labels with _.$cal_months everywhere inside the formatDate function
Line 259, I replaced the space with /01/ (calendarHTML +=  _.$formatDate(new Date(monthName +' '+ new_year), _.options.titleFormat, 'en'); -> calendarHTML +=  _.$formatDate(new Date(monthName +'/01/ '+ new_year), _.options.titleFormat, 'en');)

I might have missed something since I have changed the code quite a lot, but I hope this helps :)

Hi IngridRegina and edlynvillegas ,
Have a look. Although I altered the CSS a lot, it is still the EvoCalendar.  I made a workaround with the changes of IngridRegina  and it works on Firefox, Chrome, IE and Edge. I will check my iOS device later on and will revert on that. Thanks for now.

and have a look on the index page: https://radioclublimburg.nl/
tnx for all the good work

Hey @Mookseberg , glad I could help :) Also maybe you did it like this on purpose, but if you want the months on the left sidebar to still show as full month names instead of numbers, you can use the _.$cal_months_labels array only in the buildSidebarHTML function.

Hi @edlynvillegas and @Mookseberg ! I was dealing with the same issue on Safari and IE. Seems like they don't like the date format that was used. Here's what I did to fix it:

instead of _.$cal_months_labels, I created a new array _.$cal_months = ['01', '02', '03', '04', '05', '06', '07', '08', '09', '10', '11', '12']
I replaced _.$cal_months_labels with _.$cal_months everywhere inside the formatDate function
Line 259, I replaced the space with /01/ (calendarHTML +=  _.$formatDate(new Date(monthName +' '+ new_year), _.options.titleFormat, 'en'); -> calendarHTML +=  _.$formatDate(new Date(monthName +'/01/ '+ new_year), _.options.titleFormat, 'en');)

I might have missed something since I have changed the code quite a lot, but I hope this helps :)
Edit: I also opened a pull request with these fixes.

Thank you so much for the help. I really appreciate all the hard work behind this plugin,

@IngridRegina Which file do you make fix _.$cal_months_labels? Currently my site doesn't work on Safari but no clue how to fix it (https://gayatri-a-b.github.io/)

hi, thanks for all the good work edlyin.
I fixed problem in safari :
change title in EvoCalendar.prototype.buildCalendar :
   title = _.formatDate(new Date((_.$active.month + 1) + '/01/' + _.$active.year), _.options.titleFormat, _.options.language);

hi
i am using evo calander but eventheader and event body is not displyed on mozial you can i shared screen shot
IN CROME BROWSER

and in MOZILA FIRE FOX

please help me what can i do for this issuse

When the dates are not shown on iOS devices is a matter of the date format.
In the demo there ist used F/d/Y (February/15/1999) - which is NOT WORKING FOR IOS.
Use M d Y (Feb 15 1999) instead. It works everywhere.


fix crash and fix migration qqwry  #161

I noticed that qqwry.DownloadUrls should be updated when len(adb.DownloadUrls) == 0, but it currently isn't. Therefore, I modified the code logic accordingly.

Thank you!


I have failed to build docker-compose on Mac

I use Mac Os. After I installed Docker and clone, when I build docker-compose use Administrator, I failed. The error is "OSError: [Errno 5] Input/output error: '/tmp/pip_build_root/Flask/flask/testsuite/test_apps/moduleapp/apps'
Storing debug log for failure in /root/.pip/pip.log
ERROR: Service 'web' failed to build: The command '/bin/sh -c pip install /cert-viewer' returned a non-zero code: 2"
How can I do?

@downie does this sound like the docker issues you ran into when recently installing? I remember we noticed some different behavior in the latest docker version, and I'm not sure if we ever got past that.
thanks for reporting this @franklili3 -- I'll take a look

No, I got a more cryptic message, which I think is due to running on OS X Sierra beta. I'm still having issues with docker.

I updated the docker-compose file to use v2 file format. I recommend uninstalling whichever Docker version you had previously and installing Docker for Mac, since this is a more seamless experience.
I followed those steps and it works perfectly for me on mac. I updated the README.md accordingly.
Note that we don't want to get in the business of debugging Docker installation issues, so I'm trying to keep our install notes general, and point people to Docker help when it's actually Docker installation issues. If you guys have any guidance on how best to indicate that in the docs (other than the wording I picked), please let me know. There are many varieties of versions and os combinations, and we could easily spend most of our time supporting Docker. :)

My OS is OS X EI Capitan 10.11.6. I have uninstalled the Docker, and reinstall it. I have deleted the cert-viewer file folder, and clone it again, and do the left actions. I am successful to view the web page. Thanks.


Array.includes should not call hasitem

As per the spec, when looping for finding the value, the includes should not perform the
hasproperty call. Fixed that by passing param to Template* functions.

@abchatra @suwc please review.

:shipit:

:shipit:

@dotnet-bot test this please

@dotnet-bot test this please


Write a TypeScript program to find digital root of a number

Description
Write a TypeScript program to find digital root of a number
Digital root of a number is the recursive sum of its digits until we get a single digit number.
Input  : 1234
Output : 1

How to contribute

Save the solution in program/FindDigitalRootOfANumber.ts file
Add FindDigitalRootOfANumber.ts file in find-digital-root-of-a-number folder

assign me !

!assign


Pixi.js modules webpack and CustomEase plugin

Hi everybody, i'm using pixi.js with webpack v2, i pack all the pixi package with a general import (so i'll open another issue for using pixi to modules)
Import * as PIXI from 'pixi.js'

For the pixi libraries outside the general package use a require such as this example
require ('./assets/js/Pixi-sound.min.js')

Everything works great but...
...when I use the CustomEase plugin, there is no way to run it by using require. Like this:
Show this error:
CustomEase.min.js:12 Uncaught Error: Cannot find module "TweenLite"
require('./assets/js/CustomEase.min.js')

The solution might be to use import-loaders and export-loaders but with various tests I did not come to the solution
Do you have a solution?
Thanks
W

Related? https://github.com/greensock/GreenSock-JS/issues/193
This seems unrelated to Pixi.js and is an issue with CustomEase.

Oh sure, it's about GreenSock, sorry!
It's time to take a break
Thanks @bigtimebuddy and and again excuse me

No worries. If for some reason Pixi is the culprit here (which seems a little unlikely), please feel free to re-open. Thanks for using Pixi.


feat(transformers): Add beforeDeclarations transformers

Fixes #58880
Relates to #17146 and #41486 (not fully fixes them)
The custom transformers were lacking a beforeDeclarations allowing devs to do a AST transformation before the built-in transformers. If you wanted to use information from erased AST nodes (visibility, initializers, etc.) you were lost. With this change devs can improve their JSDoc comments or use other transformations specific for declarations.
Sorry for the PR without Backlog milestone issue. I still hope this makes it through.

To help with PR housekeeping, I'd prefer not to have PRs for bugs that aren't accepted yet. Discussion usually brings up new implementation requirements, and the codebase can change underneath the PR.

Unfortunately, I would not classify this as "low-hanging fruit". I'm very wary about adding a beforeDeclaration transformer given that the current declaration transformer expects to receive the original parse tree, not a transformed tree, and may be making many assumptions about the provenance of nodes in the tree. Adding a "before" parser to the transforms required a fair amount of consideration and rethinking of the ts transformer to ensure it worked properly with a transformed tree. I'd like to see far more test coverage of various potential tree mutations and their effects on declaration output before I'd feel confident about making this change.

may be making many assumptions about the provenance of nodes in the tree.

For example, src/compiler/transformers/declarations.ts contains at least 38 references to .parent, but a transformed source tree does not have reliable .parent pointers, and that's not taking into account imported functions that might also access .parent.

I understand your concern, but how is beforeDeclarations much different to normal before transformers? There are also plenty of built-in before transformers which run after the custom transformers:
https://github.com/microsoft/TypeScript/blob/dc535a7be8f40fde10110b0fc29a106499327118/src/compiler/transformer.ts#L133-L139
With your argumentation before transformers should be removed because devs might create transformers producing a nodes incompatible with the built-in ones. Is your concern that you are held responsible for custom transformers breaking the built-in ones causing too much support?

I understand your concern, but how is beforeDeclarations much different to normal before transformers?

With your argumentation before transformers should be removed because devs might create transformers producing a nodes incompatible with the built-in ones.

You misunderstand my concern. Prior to adding custom before transforms, the ts transform also had numerous places where it expected to only receive an original parse tree. When we added custom before transforms, the ts transform had to be updated to be more resilient to custom transforms by avoiding .parent pointers, making calls to getOriginalNode as needed, etc.
As far as the other JavaScript-emitting transformers, they were all initially written with the expectation that they were receiving a transformed tree, so they made no assumptions about provenance and avoided these pitfalls.
If we want to add a beforeDeclarations transform, the declarations.ts transform must also be made resilient.

Thanks a lot for clarfiying, makes totally sense. Once I find some time for this topic again, I might dive a bit deeper into the transformer codebase to see how they are currently organized compared to the normal before runners.
Are there already some good tests for before transformers which try to break the built-in transformers I could look at?

Are there already some good tests for before transformers which try to break the built-in transformers I could look at?

We have a number of tests in src\testRunner\unittests\transform.ts and src\testRunner\unittests\customTransforms.ts that exercise custom before transforms.


chore: add github issue templates

Description of the change

Add default github issue templates that match the organization defaults.
Existing or Associated Issue(s)

Fixes #87
Additional Information

Checklist

[ ] Chart version bumped in Chart.yaml according to semver.
[ ] Variables are documented in the values.yaml and added to the README.md. The pre-commit utility can be used to generate the necessary content. Use pre-commit run -a to apply changes.
[ ] JSON Schema template updated and re-generated the raw schema via pre-commit hook.
[ ] List tests pass for Chart using the Chart Testing tool and the ct lint command.

Will backtrack on this in favor for more generic templates


⚠ Bofrost.at has degraded performance

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

HTTP code: 200
Response time: 1271 ms

Resolved: Bofrost.at performance has improved in a2f6a5b after 309 days, 11 hours, 48 minutes.


Add connection parameters to the websocket scope

The Apollo client supports a websocket authentication method by passing "connection parameters" to the client, that end up in the connection_init message.
This changeset makes those parameters available in the WebSocket request's scope.

@abompard Great. Thanks!


Update dependencies

Now there are only 2 crates with multiple versions in our dependency tree

Is this related to #1909?

Oh, yes, sort of. I didn't depend on lz-fear but a different fork of the redox crate, lz4-compress, which is maintained and has a more similar API to the original than lz-fear.


[BUG] local cluster (RKE2) shows no possability to create ectd snapshots nor allows to manage nodes

Rancher Server Setup

Rancher version: 2.8.2
Installation option (Docker install/Helm Chart): Helm

If Helm Chart, Kubernetes Cluster and version (RKE1, RKE2, k3s, EKS, etc): RKE2

Information about the Cluster

Kubernetes version:
v1.27.10+rke2r1
Cluster Type (Local/Downstream): Upstream

User Information

What is the role of the user logged in? (Admin/Cluster Owner/Cluster Member/Project Owner/Project Member/Custom)
Admin

Describe the bug
The WebUI does not allow creating or restoring any etcd snapshots of the local cluster. In Fact there is no button for that like for the downstreamclusters. Also in the clustermanagement there is nothing really to manage like mentioned in the documentation. for example it shows the RKE2 version of the nodes but its not possible to update the RKE2 version of the nodes.
To Reproduce

setup at least one VM ans install RKE2
install rancher with helm
login to web UI - Click on "Cluster Management" - select "local" - click on three dots for submenu - click "Edit Config"
see no buttons for creating or restoring etcd snapshots
see no buttons for managing anything besides labels

Result
For the local (upstream) cluster there is no possibility to create or restore etcd snapshots as well as manage the local cluster in any meaningfull way like update the RKE2 nodes.
Expected Result
being able to create etcd snapshots
being able to update RKE2
Bonus question: Managing downstream clusters with the vSphere Provider works very good regarding node-lifecycle management (node deployment, node replacement, scaling etc.) so it would be nice to be able to do all these things also on the local (upstream) cluster. is this possible?
Screenshots

Additional context
all downstream- as well as the upstream cluster are deployed in an vSphere environment so it would be ideal to be able to manage the upstreamcluster the same way as the in rancher deployed downstreamclusters with the vSphere Provider in use.

seems like rancher is not able to do that. This doesn't mean that it's possible tough, its not really good documented imo.
To be able to do etcd snapshots on you local cluster you just need to manuall install the Application Apps - Charts - Rancher Backups

So this issue can be closed with the hint that that maybe better documented.


KAFKA-6567: Remove KStreamWindowReducer

This pull request removes the final reference to KStreamWindowReducer and replaces it with KStreamWindowAggregate
Signed-off-by: Samuel Hawker<EMAIL_ADDRESS>contribution is my original work and that I license the work to the project under the project's open source license.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

retest this please

Thanks for the PR @samuel-hawker and congrats to your first contribution to Kafka! 🎉


Maybe replace JSX with htm?

So we drop the babel dependency?

Nevermind, we adopted esbuild and babel was dropped anyway.


How to solve the action bug of butterfly knife

How to solve the action bug of butterfly knife

@M1XT3NZ    HELP ME..


Fixed CoW RuntimeError in DecodingTask.run()

To reproduce:
import whisper
import torch

model = whisper.load_model("tiny", device="cuda")
options = whisper.DecodingOptions(without_timestamps=True, fp16=True)
mels = torch.randn(10, 80, 3000, device="cuda")
with torch.no_grad():
    outputs = model.decode(mels, options)

Gives
tokens[:, self.sot_index + 1] = lang_tokens  # write language tokens
RuntimeError: unsupported operation: more than one element of the written-to tensor refers to a single memory location. Please clone() the tensor before performing the operation.

Replacing the expand by a repeat (or calling clone() after expand) solves the issue

Thank you!


Reduce binary size

for x86_64-unknown-linux-gnu

reduce ~90% size for release
reduce ~65% size for debug

Signed-off-by: Chojan Shang<EMAIL_ADDRESS>

Normally, the size on macos is already very small and no additional work is required

Interesting. @PsiACE could you elaborate a bit with the underneath. I'm curious about how this works.

Sorry I'm late.
Rust generates an absolutely massive amount of debug info by default. One easy workaround is to compress the debug info sections, on Linux with a .cargo/config like the PR. See https://github.com/MaterializeInc/materialize/pull/2691/

--compress-debug-sections=zlib-gabi # instructs the linker to compress debug info, most of the redundant debug info can be well compressed

debug = 1 # ask Rust to generate less debug info for release builds, this is usually the right tradeoff for a release build.

Some other optimizations from a tutorial min-sized-rust . Please check for more information. It is worth mentioning that

codegen-units = 1 # allow for maximum size reduction optimizations, but it may increase the compilation time

After investigation, it hardly adds much to the compilation time. If necessary, the number of codegen-units can be set for the specific crate, like

arrow = { codegen-units = 4 }

Maybe we can consider it when we have trouble with the binary size.

If it goes well, you'll need it soon. Whether you intend to provide the binary to users or use docker, 90% reduction in release size means only tens of megabytes of space are needed

we're starting the normal development cycle and it seems this PR should be rebased onto master.

It conflicts with the main branch, if necessary, I will reopen a new PR

@PsiACE thanks for your contribution and explanation, I suggest that we can evaluate this optimization when we have a large enough binary.


Use a separate token for GitHub repo check

The repository validation that happens when onboarding a new repository should prevent the adding of repos that cannot be cloned. This requires a token to be used that has the same permissions as the user who does the cloning.
Related to https://github.com/FundingCircle/shipment_tracker-deployment/pull/18 and https://github.com/FundingCircle/devtools/pull/273

LGTM! :+1:

Nice work :nail_care:, LGTM


Feature Request: System Agnostic

I noticed that this has an undisclosed DnD5e dependency. I only found one place in the code where it directly references DnD, and I tried hacking it myself to run it in a non-DnD system. From my testing, the macro triggering appears to work, although for some reason functions like findContained or findContainers don't function. From what I can tell it wouldn't be that much modification to make this system-agnostic, although it seems a bit beyond me without breaking something.

This is something I had planned to do, thanks for the reminder.


Allow complete mode deployment to subscription

Is your feature request related to a problem? Please describe.
Sorry if this is the wrong place to make this bugreport but I have no idea where else to put it.
$ az deployment sub create --mode Complete --template-file service.bicep --location northeurope
unrecognized arguments: --mode Complete

Describe the solution you'd like
I would like for it to be supported :)

Complete mode has always been a bit of a half-baked feature and if we supported it at the subscription scope a lot of people would accidentally delete other people's resource groups.
That being said, we are working on something called "Deployment Stacks" which will sort of be "Complete mode v2". More details here:
https://www.youtube.com/watch?v=-4E5DsC-RcU&t=1657s

Going to close this for now as it is not directly related to bicep, but let me know if you have any questions about stacks.

oh, I completely missed the part about your message where I was allowed to ask questions about stacks :) anyway stacks looks exactly like the thing I want, is there a preview somewhere?

No preview yet, but if you send @bmoore-msft your email he can add you to the private preview list that will hopefully start in the next two months.

Hi,
I am interested in the private preview for "Deployment Stacks", my I ask what is @bmoore-msft  email?
Thanks

just remove the "-msft" from my github username...

Hello, is there any news regarding Deployment Stacks progress? I can't find any resource besides the video your shared

Same here. We are looking into migrating all our ARM to Bicep orchestration with multiple modules on different scopes. The fact that Bicep is not fully idempotent by no cleaning up resources not present in the code and not producing the 'Desired State' ("You can develop one file that represents the desired state, rather than developing lots of separate files to represent updates.")

@maxipalle / @diogocatossi -- this capability is currently available in the private preview. Would you like to be onboarded?

Hi Alex,
already am, but currently no resources to evaluate this.
Jens
From: Alex Frankel @.>
Sent: Dienstag, 21. Februar 2023 15:56
To: Azure/bicep @.>
Cc: MaxiPalle @.>; Mention @.>
Subject: Re: [Azure/bicep] Allow complete mode deployment to subscription (#2096)
@MaxiPallehttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMaxiPalle&data=05|01||dfb1fb4b6e6d49dce2aa08db141bb702|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|638125881477712060|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=xXdnCVeSMTf7seNuwB4X7GRKjTV70sMGF9%2BXckY9HyI%3D&reserved=0 / @diogocatossihttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdiogocatossi&data=05|01||dfb1fb4b6e6d49dce2aa08db141bb702|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|638125881477712060|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=rvwpXsA3otKOwhZ%2BvKuT%2BgJ7Z8GoY6hl1kVGstel8GM%3D&reserved=0 -- this capability is currently available in the private preview. Would you like to be onboarded?

Reply to this email directly, view it on GitHubhttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fbicep%2Fissues%2F2096%23issuecomment-1438624838&data=05|01||dfb1fb4b6e6d49dce2aa08db141bb702|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|638125881477712060|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=s021Pk6qE4aFB0YWsIqMQ%2Fxuy9QC7EVNJXIg286pYQ8%3D&reserved=0, or unsubscribehttps://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAETJPYT74OTJ6OJHHDQSEYDWYTJPFANCNFSM42HGO7EA&data=05|01||dfb1fb4b6e6d49dce2aa08db141bb702|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|638125881477712060|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000|||&sdata=zShtkAGeWOZHVw5hSBiyDPmR8S%2FhaOkztj%2BJSyRIRVI%3D&reserved=0.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>