INCOHERENT instance causes unpredictable type inference

I came across a type inference wobble when using effectful with OverloadedRecordDot. See the GHC issue for details: https://gitlab.haskell.org/ghc/ghc/-/issues/25070
The diagnosis seems to be that the root cause is that the INCOHERENT pragmas on the instances for Subset/KnownPrefix. I'm sure those would have been avoided if possible, but it's perhaps helpful to have a concrete example of the cost. Maybe we can think again if they're avoidable?

I've spent a while looking at how Subset works and it's very clever. I can't see a way to make it work without the INCOHERENT, since it really wants a way to do something different when it gets to uninstantiated type variables, which is exactly the sort of thing GHC gets fussy about with merely overlapping instances.
(Perhaps a better type-wizard can see a way!)
I wonder if we could have a different function like
class KnownEffects es => SubsetKnown es xs
injectKnown :: (SubsetKnown xs es) => Eff xs a -> Eff es a

I think it should be possible to define that without any incoherence because it can just walk down the known list. But perhaps it's too narrow. I currently find myself wanting to inject Effs with fixed lists of known effects, but maybe I'll want something different later...

As you already noticed, incoherence is unfortunately necessary for inject to work in full generality. However, looks like in your specific case KnownSubset can be a trivial wrapper class to solve your problem as the following compiles:
class Subset xs es => KnownSubset xs es
instance KnownSubset '[] es
instance (e :> es, KnownSubset xs es) => KnownSubset (e : xs) es

knownInject :: KnownSubset xs es => Eff xs a -> Eff es a
knownInject = inject

data Test = Test { act :: Eff '[IOE] () }

test2 :: forall es . IOE :> es => Test -> Eff es ()
test2 t = knownInject (t.act)

Ah, that's a nice trick, using the superclass constraints to force us into only using the coherent ways of solving Subset!
Would you be interested in having knownInject (under whatever name) in effectful as something to try if you have trouble with type inference? I don't know if it's generally useful enough.

I'm not sure 🤔 it's a small addition, but it seems to be only useful when you work with fully monomorphic effect lists, which are generally discouraged. I guess you have a specific use case for this? Is it related to https://github.com/lexi-lambda/freer-simple/issues/30?
Will it ruin your day if you have to define knownInject yourself as a util for now?

So what we're doing is this: we have the usual "handle pattern", e.g.
data FooHandle = FooHandle { doIt :: Args -> IO () }

f :: IOE :> es ... => FooHandle -> Effs es ()
f h = do
  ...
  liftIO $ h.doIt args
  ...

This is fine. I wanted to make the handles have tracked effects. There are a few options:

Handle fields have types like forall es . (SomeEffect :> es) => Args -> Eff es (). This would be nicest, no need to use any kind of lifting function. But OverloadedRecordDot doesn't work with polymorphic fields.
Handle fields have types like Args -> Eff [SomeEffect] (). This would work with you just calling inject, which is comparably annoying to the current need to liftIO. But it doesn't work because of this issue.

We might define injectKnown, but it's not necessarily obvious that you need it, which will be annoying for devs.

So overall it's a somewhat annoying little corner where we're quite constrained by OverloadedRecordDot. I was really hoping that I could just somehow fix inject to work, but I think we might just leave it the way it is for now. If we really want to make the handlers use Eff we can go the injectKnown route.

I wonder if this would suffice?
data FooHandle es = FooHandle { doIt :: IOE :> es => Args -> Eff es () }

f :: IOE :> es ... => FooHandle -> Effs es ()
f h = do
  ...
  liftIO $ h.doIt args
  ...

That also works, but:

You need to commit to the set of es when you create the handle, which is annoying and in some sense much stronger than you need.
You then need to pass lots more type variables around and make sure they line up.
If you need to use the handle with two different es (I don't know if we do!) then you're going to be annoyed.

@michaelpj to be honest, this is somewhat peculiar scenario.
"The" way would be to convert the FooHandle into an effect, then foo becomes the operation and everything falls into place (and if you have multiple FooHandleS, tag it with additional type parameter).
Using handles with fields polymorphic in es would also somewhat work, but you want to use OverloadedRecordDotwhich doesn't work with them. Also, calling inject every time you're calling your effectful operations isn't ideal. It's not very expensive, but not free either.
I'll not question your choices since I'm sure you have your reasons for sticking with this design, but under these conditions using effectful might not be worth it.

I agree it's a bit odd! And we are clearly making our lives more difficult - e.g. by really wanting to access the fields with OverloadedRecordDot. I definitely don't think this is worth making extreme efforts to support, but I think it's mildly interesting in that it's a real example of the INCOHERENT biting us, which might happen in other weird cases too. Or I guess I had a faint hope that someone might come up with a truly brilliant workaround :)

"The" way would be to convert the FooHandle into an effect

It would simplify things a lot to make the handle into an effect. However, I think they aren't that well suited to that, because they really are "handles": there will be multiple of them, potentially an unknown number determined at runtime, so while we could use labelled effects that would be quite awkward. With value-level handles we can just stick them in a list, no problem.

I'll not question your choices since I'm sure you have your reasons for sticking with this design, but under these conditions using effectful might not be worth it.

We definitely don't want to stop using effectful, we use it very heavily throughout the whole codebase, it's great! It's just this wrinkle is annoying at the moment, but we can certainly work around it.

I'm working with @michaelpj on this project and the conclusion that "you're holding it wrong" is kind of what I expected. What I think could be interesting for us is to explore the non-handle approach and if that's not ergonomic see if we can improve that space. It ultimately might be more productive, and we haven't actually tried labelling these effects - maybe it's not as bad as we think!

You can also keep OverloadedRecordDot, but you need to write instances yourself (or write a TH utility function for generating them):
import Effectful
import GHC.Records

data Foo = Foo { _act :: forall es. IOE :> es => () -> Eff es () }
data Bar = Bar { _act :: forall es. IOE :> es => Eff es () }

instance
  (HasField "act" Foo a
  , IOE :> es
  , a ~ (() -> Eff es ())
  ) => HasField "act" Foo a where
  getField Foo{..} = _act

instance
  (HasField "act" Bar a
  , IOE :> es
  , a ~ Eff es ()
  ) => HasField "act" Bar a where
  getField Bar{..} = _act

test :: IOE :> es => Foo -> Bar -> Eff es ()
test foo bar = do
  foo.act ()
  bar.act

If the instance context looks peculiar to you, that's because including the instance head in the context is a somewhat dirty trick that lets you ignore the coverage condition.

If the instance context looks peculiar to you, that's because including the instance head in the context is a somewhat dirty trick that lets you ignore the coverage condition.

OMG. I tried this and I did not figure out this particular evil trick. I bow to your knowledge of the typeclass resolution system, although I admit that I'm amazed that's allowed. I'm unsure if I'm willing to write (or generate) all those instances, but it's a cool trick indeed.

I guess this can be closed?

Yes, I think there's nothing for effectful to do here.

Since lend/borrow was adjusted to take a list of effects because of #233 and it needed addition of KnownSubset to work, perhaps it would be good to actually add injectKnown :thinking:  Does that still benefit your case?

Maybe? I'm actually coming back to this and I think I may just argue for us to bite the bullet and give up on OverloadedRecordDot here.
Is it a problem for lend/borrow? I thought the only reason there was a problem here was the unusual functional dependencies from HasField?

No, for lend/borrow the problem is that the subset should really be statically known. In theory you can write something like localSeqBorrow @localEs and get a Eff (localEs ++ handlerEs), but then ++ doesn't reduce, GHC is not smart enough to realize that x :> localEs implies `x :> (localEs ++ handlerEs) and complains, which is not great UX.
Ok, I'll refrain from adding injectKnown for now then ;)


Better init for SPAlert with preset only

Goal
Preset color was not defined and layout was wrong (top margin > bottom margin, preset not centered).
Checklist

[x] Testing in compability platforms
[x] Installed correct via Swift Package Manager and Cocoapods

Updated to new version. Closed like not related now.


Create Atom feed with html content

I want to publish the content of a blog in an Atom feed.
I create my SyndicationItem object and set it's Description property to the html and see that it creates an Atom content element.  So far so good.  However I have two questions:
On Atom fields I've seen in the wild (including your own test atom feed, the content element has an attribute named "type" that I don't see how to set.  This often appears as "xhtml" or "html".  Shouldn't SyndicationItem have a property for an additional class that would allow to set this attribute?
My additional question is how to make the information within the Atom content element to be non-encoded.  My html angle brackets appear as "<p>" instead of
, making my html useless.
thanks

IAtomEntry has property ContentType.
If you like to write Atom Text Construct with custom type, you can use AtomFeedWriter.WriteText method.
Regarding the second question:
RFC 4287 section <IP_ADDRESS>

If the value of "type" is "html", the content of the Text construct
MUST NOT contain child elements and SHOULD be suitable for handling
as HTML [HTML].  Any markup within MUST be escaped; for example,
"" as "
".

You can use xhtml type and it will appear unescaped, wrapped in  (according to RFC 4287 section <IP_ADDRESS>).
<content type="xhtml">

       This is XHTML content.

 </content>

Note that the current released version 1.0 has a bug #6 dealing with XHTML type content. It was addressed with #7.

Thanks.  I see the way to create the content type in IAtomEntry.  Previously I went down the wrong path because I was using SyndicationItem.
AtomEntry atomEntry = new AtomEntry(); atomEntry.ContentType = "xhtml";
Looking forward to the update, and thanks for the library.


data-placeholder is not translated in select2 form fields.

It seems, that the value of data-placeholder is not translated in select2 form fields.
The code which should do the translation is located in:
https://github.com/cross-solution/YAWIK/blob/develop/module/Core/src/Core/Form/View/Helper/FormSelect.php
But as you can see in our demo at least in the JobsByMail Form and the Orders Settings form, the value is not translated.
Order Settings.
placeholder for Salutation is not translated

Jobs By Mail form
Location is not translated

this was implemented in https://github.com/cross-solution/YAWIK/commit/304c104ed8e5b73c77d536ab44cb070b0b1c0b54
thanks to sergey


Load MuLaN from last checkpoint

@lucidrains Could you please pass an argument to the MuLaNTrainer class to enable/disable loading from last available checkpoint?

Alternatively if i do this:
model = torch.load(MODEL_SAVE_PATH + '/'  + last_checkpoint)

# create new OrderedDict that does not contain `module.`
from collections import OrderedDict
new_state_dict = OrderedDict()
for k, v in model.items():
    name = k[7:] # remove `module.`
    new_state_dict[name] = v

mulan.load_state_dict(new_state_dict)

trainer = MuLaNTrainer(
    mulan = mulan,
    dataset = dataset,
    num_train_steps = 50001,
    batch_size = 4,
    save_model_every = 5000,
    force_clear_prev_results = False,
)

trainer.train()

It throws the followinfg error:
  File "/venv/lib/python3.8/site-packages/musiclm_pytorch/musiclm_pytorch.py", line 168, in forward
    sim = einsum('b h i d, b h j d -> b h i j', q, k) * self.scale
RuntimeError: CUDA out of memory. Tried to allocate 232.00 MiB (GPU 0; 23.65 GiB total capacity; 16.83 GiB already allocated; 102.56 MiB free; 16.88 GiB reserved in total by PyTorch) If reserved memory is >> allocated memory try setting max_split_size_mb to avoid fragmentation.  See documentation for Memory Management and PYTORCH_CUDA_ALLOC_CONF

Plus, i am not sure if the trainer will start counting the num_train_steps from last checkpoint? or from 0 and override the already saved checkpoint?

Solved by setting trainer.register_buffer('steps', torch.Tensor([checkpoint_number])) before trainer.train()

@ukemamaster oh sure, you mean like automatically loading the last saved model from the results folder?
for your second comment, it works for me
are you sure your path is correct?
trainer.save('./test.pt')
trainer.load('./test.pt')

In my fork I have been doing something similar when I was testing out training SoundStream.
I'm guessing the relevant issue is that, although these trainers do periodically save a checkpoint by default in trainer.train(), these checkpoints are not the same as the ones you'd get when you run trainer.save(), and the latter is what trainer.load() expects, not the default-saved ones. I got around this by using a separate directory (in the notebook, currently called actual_soundstream_results) to store the results of trainer.save() and totally ignoring the auto-generated checkpoints.

@lucidrains

@ukemamaster oh sure, you mean like automatically loading the last saved model from the results folder?

Yes. but controlled by an argument.

for your second comment, it works for me
are you sure your path is correct?
trainer.save('./test.pt')
trainer.load('./test.pt')

It may work for single-gpu trained checkpoints. Have you tried for a multi-gpu saved checkpoint? I think it has something to do with the fact that the state_dict keys are model.module.layer_names in case of multi-gpu trained model (instead of model.layer_names in case of single-gpu).

In my fork of AudioLM I have been doing something similar when I was testing out training SoundStream.
I'm guessing the relevant issue is that, although these trainers do periodically save a checkpoint by default in trainer.train(), these checkpoints are not the same as the ones you'd get when you run trainer.save(), and the latter is what trainer.load() expects, not the default-saved ones. I got around this by using a separate directory (in the notebook, currently called actual_soundstream_results) to store the results of trainer.save() and totally ignoring the auto-generated checkpoints.

oh yes! you are absolutely right. i wasn't even using the right save function
should be fixed in this repository, let me fix audiolm too

@LWprogramming @ukemamaster ok, both should be fixed now!

@ukemamaster i'll get to the load checkpoint functionality tomorrow morning

@lucidrains Now it seems fine. And i think there is no need to pass argument to the trainer class.
The following works as expected:

trainer = MuLaNTrainer(
    mulan = mulan,
    dataset = dataset,
    num_train_steps = 50000,
    batch_size = 4,
    save_model_every = 1000,
    force_clear_prev_results = False,
    results_folder = MODEL_SAVE_PATH
)

checkpoints = os.listdir(MODEL_SAVE_PATH)

if checkpoints:
   trainer.load(MODEL_SAVE_PATH + last_checkpoint)

   # to start counting further steps from the loaded checkpoint
   trainer.register_buffer('steps', torch.Tensor([last_checkpoint_number]))

   print(f'Loaded from last checkpoint: [{last_checkpoint}]')

trainer.train()

@ukemamaster oh yes, that could be an issue. may have fixed this in 0.0.26, if you'd like to try again

@lucidrains fixed. thanks


Test-ModuleManifest grinds to a halt when RequiredModules are specified

Steps to reproduce
New-ModuleManifest m.psd1 -RequiredModules sub
Test-ModuleManifest m.psd1 -verbose

Note that it tries to load every version of every module.
This is being used by psake build scripts, making them almost unusable.
Expected behavior
Performance very similar to
New-ModuleManifest m.psd1
Test-ModuleManifest m.psd1 -verbose

Actual behavior
measure-command {Test-ModuleManifest m.psd1}
Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 54
Milliseconds      : 312
Ticks             : 543125777
TotalDays         : 0,000628617797453704
TotalHours        : 0,0150868271388889
TotalMinutes      : 0,905209628333333
TotalSeconds      : 54,3125777
TotalMilliseconds : 54312,5777

Environment data

Name                           Value
----                           -----
PSVersion                      5.1.15063.138
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.138
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           <IP_ADDRESS>

This repros on Windows PowerShell 5.1 for me, but not in PSCore6 where I have the same PSModulePath from 5.1
PS C:\users\slee\repos> measure-command {New-ModuleManifest m.psd1 -requiredmodules sub; Test-ModuleManifest m.psd1}
Test-ModuleManifest : The specified RequiredModules entry 'sub' in the module manifest 'C:\users\slee\repos\m.psd1' is
invalid. Try again after updating this entry with valid values.
At line:1 char:66
+ ... duleManifest m.psd1 -requiredmodules sub; Test-ModuleManifest m.psd1}
+                                               ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (m.psd1:String) [Test-ModuleManifest], DirectoryNotFoundException
    + FullyQualifiedErrorId : Modules_InvalidRequiredModulesinModuleManifest,Microsoft.PowerShell.Commands.TestModuleM
   anifestCommand

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 351
Ticks             : 3518615
TotalDays         : 4.07247106481481E-06
TotalHours        : 9.77393055555556E-05
TotalMinutes      : 0.00586435833333333
TotalSeconds      : 0.3518615
TotalMilliseconds : 351.8615

Would still be nice to fix on Windows, right?

@powercode the unfortunate reality is that fixing an issue in the in-box Windows PowerShell is a much more involved process than fixing something on GitHub.  At this time we are really only taking security fixes for Windows PowerShell and focusing our engineering efforts on PSCore6.

So the workaround I found was that you have to call the Install-Module for each dependent module BEFORE attempting to publish the module with dependencies.

The other way to work around this is to rely on the #Requires in the psm1 argument instead of RequiredModules in the psd1.
#Requires -modules Module1,Module2,Module3

While this does break the auto install of RequiredModules during the Install-Module it does solve the Test-ModuleManifest issue and causes psake to function as expected during build.

One last approach worth mentioning is that you can temporarily change the $ENV:PSModulePath to a folder where you download your required modules. I have used this to work around the import issue.

@SteveL-MSFT - You said that you could reproduce this error on PowerShell version 5.1 but it works for you on PowerShell 6?  I'm not having the same luck. Running PowerShell version 6.0.4 on a Docker container on Ubuntu 16.04 and running PowerShell version 6.0.4 on Windows Server 2016, throws the DirectoryNotFoundException error when running Test-ModuleManifest if I don't install the required modules first. Did you do the workaround of installing all of the dependent modules to get it work?


Adding time sync offset key to statistics causes ascope to hang

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Load the attached wpilog
Create statistics page
Add /photonvision/.timesync/matt-desktop/offset_us or rtt2 to measurements
inspect devtools

Screenshots

Depending on time/data range:

This causes the UI to not respond to further attempts to change ranges.
Version (required):
Version: 4.0.0-beta-2
Distributor: FRC 6328
Platform: win32-x64
Build Date: 10/19/2024, 02:29:37 UTC
Electron: 32.0.2
Chromium: 128.0.6613.84
Node: 20.16.0
Additional context
ascope_kaboom.zip

See #238, the fix is ready for the next release.

Updating to the latest beta, I can still cause ascope to hang if i change the data range to something stupid like -1e9->1000 with a step size of 100. I guess that's just a skill issue? Or how should big numbers with small variations be handled?

Sounds like that’s probably a different bug that should be fixed with a sensible limit on the number of bins. Could you open another issue just to keep track?


Update jinja_filters.rst

Modified example for regex_replace to show how backreferences can be used.
So far, the documentation did not contain any backreferences, which may led users to the assumption
they cannot be used.

Merged into master - thanks!


New Fragment added on top of previous one each time the activity is recreated

In RecyclerViewToFragmentActivity you add the fragment but you don't test if savedInstanceState is null first.
When re-creating the Activity, a new fragment will be added on top of the previous one because you used add() and not replace().
It's recommended to add it once, when savedInstanceState is null.

This has been fixed in #5. It will be merged when I have time to update the changed code in the blog posts.

I missed that one, thank you for the fix :)


server.respondImmediately doesn't work with jQuery 1.x

See also https://github.com/jquery/jquery/issues/2453.
The basic test:
QUnit.test( 'request', function (assert) {
    var i = 1;
    this.server.respondImmediately = true;
    this.server.respondWith( /mode=api/, function ( request ) {
        request.respond(
            200,
            { 'Content-Type': 'application/json' },
            '{ "value": "' + (i++) + '" }'
        );
    } );

    $.ajax('/foo&mode=api')
        .then(function (data) {
            assert.equal(data.value, '1', 'response');
            return $.ajax('/bar&mode=api');
        } )
        .then(function (data) {
            assert.equal(data.value, '2', 'response');
            return $.ajax('/quux&mode=api');
        } )
        .then(function (data) {
            assert.equal(data.value, '3', 'response');
        } );
} );

JSFiddle (Sinon 1.15.4; jQuery 2.x): FakeServer http://jsfiddle.net/zc7drrcb/ (passing)
JSFiddle (Sinon 1.15.4; jQuery 1.11.3): FakeServer http://jsfiddle.net/en8pu6br/ (failing)
Using latest stable Chrome.
After figuring out the lack of event handling in jQuery 1.x, I added a fake timer to work around the problem. However this makes the test rather repetitive and less intuitive (putting a clock.tick after each request).
I found sinon.fakeServerWithClock but that doesn't seem to help in this case:
JSFiddle (Sinon 1.15.4; jQuery 1.11.3) FakeServerWithClock: http://jsfiddle.net/h66s57qw/ (failing)

Hey @Krinkle, respondImmediately cuts out any source of asynchrony within the sinon library but as you've discovered, other ajax libraries are designed to be asynchronous.
One possible fix for this is to use the $.ajaxSetup method at the top of your tests. You can specify async: false and it should make all of the ajax queries synchronous. In the docs it says the use of this method is not advisable, but I imagine that warning is geared more towards production code and less for tests.

@Krinkle Since this issue is intrinsic to the asynchronous nature of the jQuery library, would you be comfortable closing this issue?

Yes, thank you.


Add comment section  #1514

I have add comment section in all the slides.
fix:#1514
Pull Request Checklist

[ ] I have added screenshots and videos to show before and after the working of my code.
[ ] I have ensured that the screen size is set to 100% while making the video.
[ ] I have synced the latest fork with my local repository and resolved any conflicts.
[ ] I have mentioned the issue number which I created before making this PR .(format to mention issue number is : fixes #(issue number) )
[ ] I understand that if any the above conditions are not met , my PR will not be MERGED .

before:

After:
light mode:
https://github.com/user-attachments/assets/59194856-3cdd-4464-9dae-8eefc1ef0012
Dark mode:
https://github.com/user-attachments/assets/6318603e-ccfc-42ad-b361-8e7e07734fc2
@ANSHIKA-26 Please review my change .

Kindly refork and resync


fix: use correct schemaLocation for urlset (v4 compat)

Description
@ThePixelDeveloper re PR https://github.com/ThePixelDeveloper/Sitemap/pull/69 - it seems this has been tagged in 4.5.6 but it looks like it should have been tagged as 5.1.4?
The change in this PR would be the change needed if we wanted to patch 4.*
I think this may be breaking for anyone on ^4 - is it possible to delete the 4.5.6 tag / make a new one with the changes in this PR?

@ThePixelDeveloper Would it possible to tag a new version 5.1.4 as suggested by @redjam13

I agree, as it is you have to use dev-master or 4.5.6 to make it work.


Using CDN to host EE packages

I often see some users fail to install some packages because of network issues.
I am planning to add a CDN from where we can distribute packages/files needed during EE setup.
But as EE installs too many things, I am finding it hard to judge which stuff we need to host on CDN.

I often see some users fail to install some packages because of network issues.

I see lots of issue when users are not able to install packages and the reason for this issue is not network connectivity but GPG keys not fetch properly.
In EE 2.X we created safe guard for this issue
Refer: https://github.com/rtCamp/easyengine/blob/old-stable/config/easyengine/ee.conf#L5
https://github.com/rtCamp/easyengine/blob/old-stable/src/lib/ee_lib_gpg_key_fix.sh
@gau1991 @harshadyeola in EE 3.x we have this feature ?

I see lots of issue when users are not able to install packages and the reason for this issue is not network connectivity but GPG keys not fetch properly.

What are common reasons for GPG keys not getting fetched?
Can we retry like 5 times?
Or cache keys on a CDN. May be have a cron job fetching keys and saving on a CDN location. (Not sure if this is allowed in terms of security)

What are common reasons for GPG keys not getting fetched?

Unable to contact server in default timeout, Server is not responding.

Can we retry like 5 times?

Yup we need to run following code 5 times with different keyservers.
		# Fix GnuPG key problems
		apt-get update > /dev/null 2> /tmp/gpg_key

		for ee_gpg_key_check in $(grep "NO_PUBKEY" /tmp/gpg_key |sed "s/.*NO_PUBKEY //")
		do
			ee_lib_echo "Processing GnuPG key: $ee_gpg_key_check"
			gpg --keyserver subkeys.pgp.net --recv $ee_gpg_key_check &>> $EE_COMMAND_LOG \
			&& gpg --export --armor $ee_gpg_key_check \
			| apt-key add - &>> $EE_COMMAND_LOG
		done


Configure the Viewport of the site

Google PageSpeed insights is reporting that the Viewport has not been defined.
This should be resolved by adding the following to the head template:
<meta name=viewport content="width=device-width, initial-scale=1">

More info here: https://developers.google.com/speed/docs/insights/ConfigureViewport

Fixed in 77e94ea.


fix: subscription closed does not comply with proposal

Thank you for creating a great lightweight library.
I have fixed the difference between proposal-observable and the closed type in subscription.
The following are subscription types for proposal-observable.
interface Subscription {

    // Cancels the subscription
    unsubscribe() : void;

    // A boolean value indicating whether the subscription is closed
    get closed() : Boolean;
}

Current wonka subscription type.
interface ObservableSubscription {
  /** A boolean flag indicating whether the subscription is closed.
   * @remarks
   * When `true`, the subscription will not issue new values to the {@link ObservableObserver} and
   * has terminated. No new values are expected.
   *
   * @readonly
   */
  closed?: boolean;
  /** Cancels the subscription.
   * @remarks
   * This cancels the ongoing subscription and the {@link ObservableObserver}'s callbacks will
   * subsequently not be called at all. The subscription will be terminated and become inactive.
   */
  unsubscribe(): void;
}

Confirmed

pnpm build passes
pnpm check passes
pnpm lint passes
pnpn test passes

Nice catch!
I think I can see how I made this mistake. I think I wrote it as optional because of ObservableLike for fromObservable to make that type more flexible 🤔
Would you mind updating the return type here: https://github.com/0no-co/wonka/blob/990c8da89b2d6e5be3d5f8ca2bd79b2a3a9fb00c/src/observable.ts#L79
To something like { unsubscribe(): void } please?
I think that'd help out a lot to keep fromObservable flexible while making toObservable more strict ✌

ok! It took me a while, but I understand what you're saying and I'll fix it right away!


Failed to fetch data from devices_by_id, falling back to Masa API

System Health details
System Information

version
core-2024.10.2

installation_type
Home Assistant Core

dev
false

hassio
false

docker
false

user
root

virtualenv
true

python_version
3.12.3

os_name
Linux

os_version
6.8.12-1-pve

arch
x86_64

timezone
Asia/Jerusalem

config_dir
/root/.homeassistant

Home Assistant Community Store

GitHub API
ok

GitHub Content
ok

GitHub Web
ok

HACS Data
ok

GitHub API Calls Remaining
5000

Installed Version
2.0.1

Stage
running

Available Repositories
1441

Downloaded Repositories
47

Home Assistant Cloud

logged_in
true

subscription_expiration
March 17, 2025 at 2:00 AM

relayer_connected
true

relayer_region
eu-central-1

remote_enabled
true

remote_connected
true

alexa_enabled
false

google_enabled
true

remote_server
eu-central-1-15.ui.nabu.casa

certificate_status
ready

instance_id
---

can_reach_cert_server
ok

can_reach_cloud_auth
ok

can_reach_cloud
ok

Dashboards

dashboards
4

resources
19

views
17

mode
storage

Recorder

oldest_recorder_run
October 11, 2024 at 11:11 AM

current_recorder_run
October 13, 2024 at 9:01 AM

estimated_db_size
1551.14 MiB

database_engine
mysql

database_version
11.3.2

Spotify

api_endpoint_reachable
ok

Checklist

[X] I have enabled debug logging for my installation.
[X] I have filled out the issue template to the best of my ability.
[X] This issue only contains 1 issue (if you have multiple issues, open one issue for each issue).
[X] This issue is not a duplicate issue of any previous issues..

Describe the issue
Error is being logged every HA restart
Reproduction steps

Restart HA

Debug logs
2024-10-13 09:16:16.904
 2024-10-13 09:16:16.903 DEBUG (MainThread) [iec_api.commons] HTTP GET Response <200>: {"pageSize":10,"pageNumber":1,"moreRecords":false,"totalRecords":1,"pageCookie":0,"items":[{"accountId":""***","accountType":279830001,"accountName":"בר אלעד חביב","addressId":""***","areaId":""***","regionId":""***","fullAddress":""***","siteId":"***","iec_ContractNumber":""***","siteType":16,"activeConnections":1,"connections":[{"connectionId":""***","connectionNumber":""***","hasOpenOrders":false,"shovalOpenOrder":null,"powerConnectionSize":279830009,"isLowVolte":true,"isCanIncrease":false,"meterId":""***","meterNumber":""***","voltType":279830001,"currentReader":"27.71","currentAmpere":null,"currentVoltLevel":{"id":null,"name":null}}],"possible2ShiftBit":true,"building":{"id":""***","name":"masaapi","hasSAOrders":null,"shovalSAOrder":null,"multiResidentialBuilding":false,"isMaxPublicSitesSum":false,"isResidentialBuilding":false,"numOfRelatedSitesInt":1},"backuplineOrder":null,"hasBackuplineOrders":false}]}

2024-10-13 09:16:15.885
 2024-10-13 09:16:15.883 DEBUG (MainThread) [iec_api.commons] HTTP GET: https://masaapi-wa.azurewebsites.net/equipments/get?accountId=***&pageNumber=1&pageSize=10
2024-10-13 09:16:15.885
 2024-10-13 09:16:15.882 DEBUG (MainThread) [iec_api.commons] HTTP GET Response <200>: {"regions":[{"regionId":"909a5d57-d7db-ea11-a813-000d3aabca53","name":"חיפה והצפון","code":7},{"regionId":"32d0f7a8-d7db-ea11-a813-000d3aabca53","name":"ירושלים והנגב","code":9},{"regionId":"788f411f-756e-e811-8101-1458d043c6c0","name":"דן והחוף","code":8},{"regionId":"26d3dc4f-756e-e811-8101-1458d043c6c0","name":"מחוז דרום","code":3},{"regionId":"e3693c7a-756e-e811-8101-1458d043c6c0","name":"מחוז חיפה","code":1},{"regionId":"dec95d9e-756e-e811-8101-1458d043c6c0","name":"מחוז ירושלים","code":6},{"regionId":"3a4e6dc2-756e-e811-8101-1458d043c6c0","name":"מחוז צפון","code":2}],"connectionSizeTypes":[{"id":"7ddab873-671f-e911-a961-000d3a29f1fd","name":"6","sizeType":279830001,"voltType":279830001,"code":"Z01","description":"חד פאזי 6 אמפר (1X6)","index":1,"isEnlargeable":true,"isAllowResidence":false},{"id":"81dab873-671f-e911-a961-000d3a29f1fd","name":"16","sizeType":279830002,"voltType":279830001,"code":"Z02","description":"חד פאזי 16 אמפר (1X16)","index":2,"isEnlargeable":true,"isAllowResidence":false},{"id":"82dab873-671f-e911-a961-000d3a29f1fd","name":"25","sizeType":279830003,"voltType":279830001,"code":"Z03","description":"חד פאזי 25 אמפר (1X25)","index":3,"isEnlargeable":false,"isAllowResidence":null},{"id":"83dab873-671f-e911-a961-000d3a29f1fd","name":"35","sizeType":279830004,"voltType":279830001,"code":"Z04","description":"חד פאזי 35 אמפר (1X35)","index":4,"isEnlargeable":false,"isAllowResidence":null},{"id":"84dab873-671f-e911-a961-000d3a29f1fd","name":"40","sizeType":279830005,"voltType":279830001,"code":"Z05","description":"חד פאזי 40 אמפר (1X40)","index":5,"isEnlargeable":true,"isAllowResidence":true},{"id":"85dab873-671f-e911-a961-000d3a29f1fd","name":"3X25","sizeType":279830006,"voltType":279830001,"code":"Z06","description":"תלת פאזי 25 אמפר (3X25)","index":6,"isEnlargeable":true,"isAllowResidence":true},{"id":"86dab873-671f-e911-a961-000d3a29f1fd","name":"3X26","sizeType":279830007,"voltType":279830001,"code":"Z07","description":"תלת פאזי 26 אמפר (3X26)","index":7,"isEnlargeable":false,"isAllowResidence":null},{"id":"87dab873-671f-e911-a961-000d3a29f1fd","name":"3X35","sizeType":279830008,"voltType":279830001,"code":"Z08","description":"תלת פאזי 35 אמפר (3X35)","index":8,"isEnlargeable":false,"isAllowResidence":null},{"id":"88dab873-671f-e911-a961-000d3a29f1fd","name":"3X40","sizeType":279830009,"voltType":279830001,"code":"Z09","description":"תלת פאזי 40 אמפר (3X40)","index":9,"isEnlargeable":true,"isAllowResidence":true},{"id":"89dab873-671f-e911-a961-000d3a29f1fd","name":"3X50","sizeType":279830010,"voltType":279830001,"code":"Z10","description":"תלת פאזי 50 אמפר (3X50)","index":10,"isEnlargeable":false,"isAllowResidence":null},{"id":"8adab873-671f-e911-a961-000d3a29f1fd","name":"3X63","sizeType":279830011,"voltType":279830001,"code":"Z11","description":"תלת פאזי 63 אמפר (3X63)","index":11,"isEnlargeable":true,"isAllowResidence":true},{"id":"8bdab873-671f-e911-a961-000d3a29f1fd","name":"3X80","sizeType":279830012,"voltType":279830001,"code":"Z12","description":"תלת פאזי 80 אמפר (3X80)","index":12,"isEnlargeable":true,"isAllowResidence":true},{"id":"8cdab873-671f-e911-a961-000d3a29f1fd","name":"3X100","sizeType":279830013,"voltType":279830001,"code":"Z13","description":"תלת פאזי 100 אמפר (3X100)","index":13,"isEnlargeable":true,"isAllowResidence":true},{"id":"8ddab873-671f-e911-a961-000d3a29f1fd","name":"3X125","sizeType":279830014,"voltType":279830001,"code":"Z14","description":"תלת פאזי 125 אמפר (3X125)","index":14,"isEnlargeable":true,"isAllowResidence":true},{"id":"8edab873-671f-e911-a961-000d3a29f1fd","name":"3X160","sizeType":279830015,"voltType":279830001,"code":"Z15","description":"תלת פאזי 160 אמפר (3X160)","index":15,"isEnlargeable":true,"isAllowResidence":true},{"id":"90dab873-671f-e911-a961-000d3a29f1fd","name":"3X200","sizeType":279830016,"voltType":279830001,"code":"Z16","description":"תלת פאזי 200 אמפר (3X200)","index":16,"isEnlargeable":true,"isAllowResidence":true},{"id":"91dab873-671f-e911-a961-000d3a29f1fd","name":"3X250","sizeType":279830017,"voltType":279830001,"code":"Z17","description":"תלת פאזי 250 אמפר (3X250)","index":17,"isEnlargeable":true,"isAllowResidence":true},{"id":"92dab873-671f-e911-a961-000d3a29f1fd","name":"3X315","sizeType":279830018,"voltType":279830001,"code":"Z18","description":"תלת פאזי 315 אמפר (3X315)","index":18,"isEnlargeable":true,"isAllowResidence":true},{"id":"94dab873-671f-e911-a961-000d3a29f1fd","name":"3X350","sizeType":279830019,"voltType":279830001,"code":"Z19","description":"תלת פאזי 350 אמפר (3X350)","index":19,"isEnlargeable":false,"isAllowResidence":null},{"id":"96dab873-671f-e911-a961-000d3a29f1fd","name":"3X400","sizeType":279830020,"voltType":279830001,"code":"Z20","description":"תלת פאזי 400 אמפר (3X400)","index":20,"isEnlargeable":true,"isAllowResidence":false},{"id":"97dab873-671f-e911-a961-000d3a29f1fd","name":"3X500","sizeType":279830021,"voltType":279830001,"code":"Z21","description":"תלת פאזי 500 אמפר (3X500)","index":21,"isEnlargeable":true,"isAllowResidence":false},{"id":"98dab873-671f-e911-a961-000d3a29f1fd","name":"3X630","sizeType":279830022,"voltType":279830001,"code":"Z22","description":"תלת פאזי 630 אמפר (3X630)","index":22,"isEnlargeable":true,"isAllowResidence":false},{"id":"99dab873-671f-e911-a961-000d3a29f1fd","name":"3X800","sizeType":279830023,"voltType":279830001,"code":"Z23","description":"תלת פאזי 800 אמפר (3X800)","index":23,"isEnlargeable":true,"isAllowResidence":false},{"id":"9adab873-671f-e911-a961-000d3a29f1fd","name":"3X910","sizeType":279830024,"voltType":279830001,"code":"Z24","description":"תלת פאזי 910 אמפר (3X910)","index":24,"isEnlargeable":true,"isAllowResidence":false},{"id":"9bdab873-671f-e911-a961-000d3a29f1fd","name":"3X1000","sizeType":279830025,"voltType":279830001,"code":"Z25","description":"תלת פאזי 1000 אמפר (3X1000)","index":25,"isEnlargeable":false,"isAllowResidence":null},{"id":"9cdab873-671f-e911-a961-000d3a29f1fd","name":"3X1030","sizeType":279830026,"voltType":279830001,"code":"Z26","description":"תלת פאזי 1030 אמפר (3X1030)","index":26,"isEnlargeable":false,"isAllowResidence":null},{"id":"9ddab873-671f-e911-a961-000d3a29f1fd","name":"3X1130","sizeType":279830027,"voltType":279830001,"code":"Z27","description":"תלת פאזי 1130 אמפר (3X1130)","index":27,"isEnlargeable":false,"isAllowResidence":null},{"id":"9edab873-671f-e911-a961-000d3a29f1fd","name":"3X1200","sizeType":279830028,"voltType":279830001,"code":"Z28","description":"תלת פאזי 1200 אמפר (3X1200)","index":28,"isEnlargeable":false,"isAllowResidence":null},{"id":"9fdab873-671f-e911-a961-000d3a29f1fd","name":"3X1250","sizeType":279830029,"voltType":279830001,"code":"Z29","description":"תלת פאזי 1250 אמפר (3X1250)","index":29,"isEnlargeable":false,"isAllowResidence":null},{"id":"a0dab873-671f-e911-a961-000d3a29f1fd","name":"3X1260","sizeType":279830030,"voltType":279830001,"code":"Z30","description":"תלת פאזי 1260 אמפר (3X1260)","index":30,"isEnlargeable":false,"isAllowResidence":null},{"id":"a1dab873-671f-e911-a961-000d3a29f1fd","name":"3X1280","sizeType":279830031,"voltType":279830001,"code":"Z31","description":"תלת פאזי 1280 אמפר (3X1280)","index":31,"isEnlargeable":false,"isAllowResidence":null},{"id":"a2dab873-671f-e911-a961-000d3a29f1fd","name":"3X1310","sizeType":279830032,"voltType":279830001,"code":"Z32","description":"תלת פאזי 1310 אמפר (3X1310)","index":32,"isEnlargeable":false,"isAllowResidence":null},{"id":"a3dab873-671f-e911-a961-000d3a29f1fd","name":"3X1400","sizeType":279830033,"voltType":27983
2024-10-13 09:16:14.765
 2024-10-13 09:16:14.764 DEBUG (MainThread) [iec_api.commons] HTTP GET: https://masaapi-wa.azurewebsites.net/lookup/all
2024-10-13 09:16:14.765
 2024-10-13 09:16:14.764 DEBUG (MainThread) [iec_api.commons] HTTP GET Response <200>: {"data":[{"accountNumber":"***","accountType":***,"id":"***","email":null,"telephone":null,"governmentNumber":"***","name":"***","viewTypeCode":1}],"reponseDescriptor":{"isSuccess":true,"code":"0","description":""}}
2024-10-13 09:16:14.664
 2024-10-13 09:16:14.662 DEBUG (MainThread) [iec_api.commons] HTTP GET: https://iecapi.iec.co.il/api/outages/accounts
2024-10-13 09:16:14.663
 2024-10-13 09:16:14.662 DEBUG (MainThread) [custom_components.iec.coordinator] Last Reading for contract ***, Meter ***: MeterReading(reading=32203, reading_code='25', reading_date=datetime.datetime(2024, 8, 21, 0, 0, tzinfo=<DstTzInfo 'Asia/Jerusalem' IDT+3:00:00 DST>), usage='1533', serial_number=None)
2024-10-13 09:16:14.663
 2024-10-13 09:16:14.662 DEBUG (MainThread) [custom_components.iec.coordinator] Last Reading for contract ***, Meter ***: MeterReading(reading=123382, reading_code='01', reading_date=datetime.datetime(2023, 6, 15, 0, 0, tzinfo=<DstTzInfo 'Asia/Jerusalem' IDT+3:00:00 DST>), usage='3453', serial_number=None)
2024-10-13 09:16:14.663
 2024-10-13 09:16:14.661 DEBUG (MainThread) [iec_api.commons] HTTP GET Response <200>: {"data":{"contractAccount":"***","lastMeters":[{"meterReadings":[{"reading":123382,"readingCode":"01","readingDate":"2023-06-15T00:00:00","usage":"3453","serialNumber":null},{"reading":119929,"readingCode":"01","readingDate":"2023-05-04T00:00:00","usage":"2461","serialNumber":null},{"reading":117468,"readingCode":"01","readingDate":"2023-02-27T00:00:00","usage":"3113","serialNumber":null},{"reading":114355,"readingCode":"11","readingDate":"2022-12-29T00:00:00","usage":"2541","serialNumber":null},{"reading":111814,"readingCode":"11","readingDate":"2022-10-30T00:00:00","usage":"4017","serialNumber":null}],"serialNumber":"***","materialNumber":"***","registerNumber":"000000000000000001"},{"meterReadings":[{"reading":32203,"readingCode":"25","readingDate":"2024-08-21T00:00:00","usage":"1533","serialNumber":null},{"reading":28056,"readingCode":"25","readingDate":"2024-06-24T00:00:00","usage":"1296","serialNumber":null},{"reading":26760,"readingCode":"01","readingDate":"2024-05-31T00:00:00","usage":"2907","serialNumber":null},{"reading":26375,"readingCode":"01","readingDate":"2024-05-21T00:00:00","usage":"2907","serialNumber":null},{"reading":23853,"readingCode":"25","readingDate":"2024-04-19T00:00:00","usage":"2475","serialNumber":null},{"reading":21378,"readingCode":"25","readingDate":"2024-02-21T00:00:00","usage":"3338","serialNumber":null},{"reading":18040,"readingCode":"25","readingDate":"2023-12-21T00:00:00","usage":"3294","serialNumber":null},{"reading":14746,"readingCode":"25","readingDate":"2023-10-24T00:00:00","usage":"5491","serialNumber":null},{"reading":9255,"readingCode":"25","readingDate":"2023-08-31T00:00:00","usage":"1241","serialNumber":null},{"reading":8014,"readingCode":"25","readingDate":"2023-08-21T00:00:00","usage":"7860","serialNumber":null},{"reading":154,"readingCode":"03","readingDate":"2023-06-21T00:00:00","usage":"154","serialNumber":null}],"serialNumber":"***","materialNumber":"***","registerNumber":"000000000000000001"}]},"reponseDescriptor":{"isSuccess":true,"code":"00","description":""}}
2024-10-13 09:16:13.371
 2024-10-13 09:16:13.370 WARNING (MainThread) [homeassistant.components.sensor] Setup of sensor platform solaredgeoptimizers is taking over 10 seconds.
2024-10-13 09:16:10.856
 2024-10-13 09:16:10.852 DEBUG (MainThread) [iec_api.commons] HTTP GET: https://iecapi.iec.co.il/api/Device/LastMeterReading/***/***
2024-10-13 09:16:10.856
 2024-10-13 09:16:10.852 DEBUG (MainThread) [custom_components.iec.coordinator] DevicesById Response: Devices(counter_devices=None, mr_type='00')
2024-10-13 09:16:10.856
 Arguments: (TypeError("'NoneType' object is not subscriptable"),)
2024-10-13 09:16:10.856
 Message: 'Failed to fetch data from devices_by_id, falling back to Masa API'
2024-10-13 09:16:10.856
     self.emit(record)
2024-10-13 09:16:10.856
   File "/srv/homeassistant/lib/python3.12/site-packages/homeassistant/util/logging.py", line 41, in handle
2024-10-13 09:16:10.856
     hdlr.handle(record)
2024-10-13 09:16:10.856
   File "/usr/lib/python3.12/logging/__init__.py", line 1762, in callHandlers
2024-10-13 09:16:10.856
     self.callHandlers(record)
2024-10-13 09:16:10.856
   File "/usr/lib/python3.12/logging/__init__.py", line 1700, in handle
2024-10-13 09:16:10.856
     self.handle(record)
2024-10-13 09:16:10.856
   File "/usr/lib/python3.12/logging/__init__.py", line 1684, in _log
2024-10-13 09:16:10.856
     self._log(WARNING, msg, args, **kwargs)
2024-10-13 09:16:10.856
   File "/usr/lib/python3.12/logging/__init__.py", line 1551, in warning
2024-10-13 09:16:10.856
     _LOGGER.warning("Failed to fetch data from devices_by_id, falling back to Masa API", e)
2024-10-13 09:16:10.856
   File "/root/.homeassistant/custom_components/iec/coordinator.py", line 638, in _estimate_bill
2024-10-13 09:16:10.856
     total_kva_price, estimated_kwh_consumption = await self._estimate_bill(contract_id, device.device_number,
2024-10-13 09:16:10.856
   File "/root/.homeassistant/custom_components/iec/coordinator.py", line 423, in _async_update_data
2024-10-13 09:16:10.856
     self.data = await self._async_update_data()
2024-10-13 09:16:10.856
   File "/srv/homeassistant/lib/python3.12/site-packages/homeassistant/helpers/update_coordinator.py", line 354, in _async_refresh
2024-10-13 09:16:10.856
     await self._async_refresh(
2024-10-13 09:16:10.856
   File "/srv/homeassistant/lib/python3.12/site-packages/homeassistant/helpers/update_coordinator.py", line 281, in async_config_entry_first_refresh
2024-10-13 09:16:10.856
     await iec_coordinator.async_config_entry_first_refresh()
2024-10-13 09:16:10.856
   File "/root/.homeassistant/custom_components/iec/__init__.py", line 18, in async_setup_entry
2024-10-13 09:16:10.856
     result = await component.async_setup_entry(hass, self)
2024-10-13 09:16:10.853
   File "/srv/homeassistant/lib/python3.12/site-packages/homeassistant/config_entries.py", line 594, in async_setup
2024-10-13 09:16:10.853
     await self.async_setup(hass, integration=integration)
2024-10-13 09:16:10.853
   File "/srv/homeassistant/lib/python3.12/site-packages/homeassistant/config_entries.py", line 742, in async_setup_locked
2024-10-13 09:16:10.853
     self._context.run(self._callback, *self._args)
2024-10-13 09:16:10.853
   File "/usr/lib/python3.12/asyncio/events.py", line 88, in _run
2024-10-13 09:16:10.853
     handle._run()
2024-10-13 09:16:10.853
   File "/usr/lib/python3.12/asyncio/base_events.py", line 1987, in _run_once
2024-10-13 09:16:10.853
     self._run_once()
2024-10-13 09:16:10.853
   File "/usr/lib/python3.12/asyncio/base_events.py", line 641, in run_forever
2024-10-13 09:16:10.853
     self.run_forever()
2024-10-13 09:16:10.853
   File "/usr/lib/python3.12/asyncio/base_events.py", line 674, in run_until_complete
2024-10-13 09:16:10.853
     return loop.run_until_complete(setup_and_run_hass(runtime_config))
2024-10-13 09:16:10.853
   File "/srv/homeassistant/lib/python3.12/site-packages/homeassistant/runner.py", line 189, in run
2024-10-13 09:16:10.853
     exit_code = runner.run(runtime_conf)
2024-10-13 09:16:10.853
   File "/srv/homeassistant/lib/python3.12/site-packages/homeassistant/__main__.py", line 209, in main
2024-10-13 09:16:10.853
     sys.exit(main())
2024-10-13 09:16:10.853
   File "/srv/homeassistant/bin/hass", line 8, in <module>
2024-10-13 09:16:10.853
 Call stack:
2024-10-13 09:16:10.853
 TypeError: not all arguments converted during string formatting
2024-10-13 09:16:10.853
           ~~~~^~~~~~~~~~~
2024-10-13 09:16:10.853
     msg = msg % self.args
2024-10-13 09:16:10.853
   File "/usr/lib/python3.12/logging/__init__.py", line 392, in getMessage
2024-10-13 09:16:10.853
                      ^^^^^^^^^^^^^^^^^^^
2024-10-13 09:16:10.853
     record.message = record.getMessage()
2024-10-13 09:16:10.853
   File "/usr/lib/python3.12/logging/__init__.py", line 703, in format
2024-10-13 09:16:10.853
            ^^^^^^^^^^^^^^^^^^
2024-10-13 09:16:10.853
     return fmt.format(record)
2024-10-13 09:16:10.853
   File "/usr/lib/python3.12/logging/__init__.py", line 999, in format
2024-10-13 09:16:10.852
           ^^^^^^^^^^^^^^^^^^^
2024-10-13 09:16:10.852
     msg = self.format(record)
2024-10-13 09:16:10.852
   File "/usr/lib/python3.12/logging/handlers.py", line 1475, in prepare
2024-10-13 09:16:10.852
                  ^^^^^^^^^^^^^^^^^^^^
2024-10-13 09:16:10.852
     self.enqueue(self.prepare(record))
2024-10-13 09:16:10.852
   File "/usr/lib/python3.12/logging/handlers.py", line 1493, in emit
2024-10-13 09:16:10.852
 Traceback (most recent call last):
2024-10-13 09:16:10.852
 During handling of the above exception, another exception occurred:
2024-10-13 09:16:10.852
 TypeError: 'NoneType' object is not subscriptable
2024-10-13 09:16:10.852
                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^
2024-10-13 09:16:10.852
     last_meter_read = int(devices_by_id.counter_devices[0].last_mr)
2024-10-13 09:16:10.852
   File "/root/.homeassistant/custom_components/iec/coordinator.py", line 632, in _estimate_bill
2024-10-13 09:16:10.851
 Traceback (most recent call last):
2024-10-13 09:16:10.851
 2024-10-13 09:16:10.850 DEBUG (MainThread) [iec_api.commons] HTTP GET Response <200>: {"data":{"counterDevices":null,"mrType":"00"},"reponseDescriptor":{"isSuccess":false,"code":"08","description":"No authorization for this product: PV Product"}}
2024-10-13 09:16:10.851
 --- Logging error ---
2024-10-13 09:16:09.810
 2024-10-13 09:16:09.809 DEBUG (MainThread) [iec_api.commons] HTTP GET: https://iecapi.iec.co.il/api/Device/***/***
2024-10-13 09:16:09.810
 2024-10-13 09:16:09.807 DEBUG (MainThread) [iec_api.commons] HTTP POST Response <200>: {"status":0,"futureConsumptionInfo":{"lastInvoiceDate":null,"currentDate":"2024-10-12","futureConsumption":53.847,"totalImport":35842.651,"totalImportDate":"2024-10-12"},"fromDate":"2024-10-11","toDate":"2024-10-11","totalConsumptionForPeriod":43.373,"totalImportDateForPeriod":"2024-10-11","meterStartDate":"2023-06-16","totalImport":35799.278,"data":[{"status":0,"date":"2024-10-11T00:00:00.000000","value":1.653},{"status":0,"date":"2024-10-11T00:15:00.000000","value":0.567},{"status":0,"date":"2024-10-11T00:30:00.000000","value":0.527},{"status":0,"date":"2024-10-11T00:45:00.000000","value":0.587},{"status":0,"date":"2024-10-11T01:00:00.000000","value":0.544},{"status":0,"date":"2024-10-11T01:15:00.000000","value":0.7},{"status":0,"date":"2024-10-11T01:30:00.000000","value":0.553},{"status":0,"date":"2024-10-11T01:45:00.000000","value":0.574},{"status":0,"date":"2024-10-11T02:00:00.000000","value":0.475},{"status":0,"date":"2024-10-11T02:15:00.000000","value":0.474},{"status":0,"date":"2024-10-11T02:30:00.000000","value":0.494},{"status":0,"date":"2024-10-11T02:45:00.000000","value":0.621},{"status":0,"date":"2024-10-11T03:00:00.000000","value":0.526},{"status":0,"date":"2024-10-11T03:15:00.000000","value":0.469},{"status":0,"date":"2024-10-11T03:30:00.000000","value":0.486},{"status":0,"date":"2024-10-11T03:45:00.000000","value":0.457},{"status":0,"date":"2024-10-11T04:00:00.000000","value":0.49},{"status":0,"date":"2024-10-11T04:15:00.000000","value":0.632},{"status":0,"date":"2024-10-11T04:30:00.000000","value":0.538},{"status":0,"date":"2024-10-11T04:45:00.000000","value":0.49},{"status":0,"date":"2024-10-11T05:00:00.000000","value":0.47},{"status":0,"date":"2024-10-11T05:15:00.000000","value":0.497},{"status":0,"date":"2024-10-11T05:30:00.000000","value":0.496},{"status":0,"date":"2024-10-11T05:45:00.000000","value":0.461},{"status":0,"date":"2024-10-11T06:00:00.000000","value":0.466},{"status":0,"date":"2024-10-11T06:15:00.000000","value":0.658},{"status":0,"date":"2024-10-11T06:30:00.000000","value":0.495},{"status":0,"date":"2024-10-11T06:45:00.000000","value":0.454},{"status":0,"date":"2024-10-11T07:00:00.000000","value":0.328},{"status":0,"date":"2024-10-11T07:15:00.000000","value":0.386},{"status":0,"date":"2024-10-11T07:30:00.000000","value":0.257},{"status":0,"date":"2024-10-11T07:45:00.000000","value":0.386},{"status":0,"date":"2024-10-11T08:00:00.000000","value":0.928},{"status":0,"date":"2024-10-11T08:15:00.000000","value":0.749},{"status":0,"date":"2024-10-11T08:30:00.000000","value":0.288},{"status":0,"date":"2024-10-11T08:45:00.000000","value":0},{"status":0,"date":"2024-10-11T09:00:00.000000","value":0},{"status":0,"date":"2024-10-11T09:15:00.000000","value":0},{"status":0,"date":"2024-10-11T09:30:00.000000","value":0.047},{"status":0,"date":"2024-10-11T09:45:00.000000","value":0},{"status":0,"date":"2024-10-11T10:00:00.000000","value":0},{"status":0,"date":"2024-10-11T10:15:00.000000","value":0},{"status":0,"date":"2024-10-11T10:30:00.000000","value":0},{"status":0,"date":"2024-10-11T10:45:00.000000","value":0},{"status":0,"date":"2024-10-11T11:00:00.000000","value":0},{"status":0,"date":"2024-10-11T11:15:00.000000","value":0},{"status":0,"date":"2024-10-11T11:30:00.000000","value":0},{"status":0,"date":"2024-10-11T11:45:00.000000","value":0},{"status":0,"date":"2024-10-11T12:00:00.000000","value":0},{"status":0,"date":"2024-10-11T12:15:00.000000","value":0},{"status":0,"date":"2024-10-11T12:30:00.000000","value":0},{"status":0,"date":"2024-10-11T12:45:00.000000","value":0},{"status":0,"date":"2024-10-11T13:00:00.000000","value":0},{"status":0,"date":"2024-10-11T13:15:00.000000","value":0},{"status":0,"date":"2024-10-11T13:30:00.000000","value":0},{"status":0,"date":"2024-10-11T13:45:00.000000","value":0},{"status":0,"date":"2024-10-11T14:00:00.000000","value":0},{"status":0,"date":"2024-10-11T14:15:00.000000","value":0},{"status":0,"date":"2024-10-11T14:30:00.000000","value":0},{"status":0,"date":"2024-10-11T14:45:00.000000","value":0},{"status":0,"date":"2024-10-11T15:00:00.000000","value":0},{"status":0,"date":"2024-10-11T15:15:00.000000","value":0.007},{"status":0,"date":"2024-10-11T15:30:00.000000","value":0.037},{"status":0,"date":"2024-10-11T15:45:00.000000","value":0.245},{"status":0,"date":"2024-10-11T16:00:00.000000","value":0.256},{"status":0,"date":"2024-10-11T16:15:00.000000","value":0.243},{"status":0,"date":"2024-10-11T16:30:00.000000","value":0.557},{"status":0,"date":"2024-10-11T16:45:00.000000","value":0.501},{"status":0,"date":"2024-10-11T17:00:00.000000","value":0.557},{"status":0,"date":"2024-10-11T17:15:00.000000","value":0.811},{"status":0,"date":"2024-10-11T17:30:00.000000","value":1.007},{"status":0,"date":"2024-10-11T17:45:00.000000","value":1.391},{"status":0,"date":"2024-10-11T18:00:00.000000","value":0.751},{"status":0,"date":"2024-10-11T18:15:00.000000","value":0.628},{"status":0,"date":"2024-10-11T18:30:00.000000","value":0.515},{"status":0,"date":"2024-10-11T18:45:00.000000","value":0.438},{"status":0,"date":"2024-10-11T19:00:00.000000","value":0.364},{"status":0,"date":"2024-10-11T19:15:00.000000","value":0.61},{"status":0,"date":"2024-10-11T19:30:00.000000","value":0.399},{"status":0,"date":"2024-10-11T19:45:00.000000","value":0.36},{"status":0,"date":"2024-10-11T20:00:00.000000","value":0.344},{"status":0,"date":"2024-10-11T20:15:00.000000","value":0.366},{"status":0,"date":"2024-10-11T20:30:00.000000","value":0.597},{"status":0,"date":"2024-10-11T20:45:00.000000","value":1.35},{"status":0,"date":"2024-10-11T21:00:00.000000","value":1.185},{"status":0,"date":"2024-10-11T21:15:00.000000","value":0.98},{"status":0,"date":"2024-10-11T21:30:00.000000","value":0.95},{"status":0,"date":"2024-10-11T21:45:00.000000","value":1.752},{"status":0,"date":"2024-10-11T22:00:00.000000","value":1.241},{"status":0,"date":"2024-10-11T22:15:00.000000","value":0.818},{"status":0,"date":"2024-10-11T22:30:00.000000","value":0.91},{"status":0,"date":"2024-10-11T22:45:00.000000","value":0.747},{"status":0,"date":"2024-10-11T23:00:00.000000","value":1.058},{"status":0,"date":"2024-10-11T23:15:00.000000","value":1.023},{"status":0,"date":"2024-10-11T23:30:00.000000","value":0.663},{"status":0,"date":"2024-10-11T23:45:00.000000","value":0.489}]}

Diagnostics dump
No response

@elad-bar is this a WARN or an ERROR?
Also - this looks the IEC API doesn't consider your account as a private producer .
Can you check the response of contracts? specifically fromPrivateProducer field (in the response it's fromPativteProducer 🤦🏻 )

an assumption why it happens,
I have PV panels and i'm producing on top of consuming on the same meter,
maybe bill estimation is not supported for PV Products device type (3) as there is no isolation between incoming and outgoing support by IEC.
more details about the questions:
it looks like unhandled error, weird thing about this error is - it is not available in the regular log of HA, it is being catch as system error (sent to my Syslog Server),
I can see that the function that it happens in is _estimate_bill line 632 but there is an issue logging it as states in the exception:
File "/srv/homeassistant/lib/python3.12/site-packages/homeassistant/util/logging.py", line 41, in handle

the root cause is this line:
last_meter_read = int(devices_by_id.counter_devices[0].last_mr)

the response of devices by devices id is:
{
    "data": {
        "counterDevices": null,
        "mrType": "00"
    },
    "reponseDescriptor": {
        "isSuccess": false,
        "code": "08",
        "description": "No authorization for this product: PV Product"
    }
}

which makes extracting the last_mr of the first device to fail (it is null / None as stated in the error),
according to the error in the description of the request - No authorization for this product: PV Product.
regarding the second question - fromPativteProducer is false
Response of contract:
{
    "data": {
        "contracts": [
            {
                "address": "***",
                "contractId": "***",
                "dueDate": "1900-01-01",
                "totalDebt": 0.0,
                "frequency": 2,
                "status": 1,
                "fromPativteProducer": false,
                "cityCode": "***",
                "cityName": "***",
                "streetCode": "***",
                "streetName": "***",
                "houseNumber": "***",
                "debtForInvoicesDueDateNotPassed": 0.0,
                "isTouz": false,
                "smartMeter": true,
                "producerType": 2,
                "isDomestic": true
            }
        ],
        "contractAmount": 1,
        "totalToPay": 0.0
    },
    "reponseDescriptor": {
        "isSuccess": true,
        "code": "0",
        "description": ""
    }
}

This is indeed a full and correct analysis.
The reason device_by_device_id is needed is for last meter reading, i wonder if I could get this from a different api.

Also, @elad-bar  - any idea what's producerType:2 - I only saw 1 so far. Is it PV producer?

looked over the api/translation files couldn't find what is producer type enums values,
found an article about IEC:

https://www.lnrg.technology/2024/08/07/overview-of-the-israeli-electricity-market-2024/
maybe values are IEC, P2IEC, P2P
I'm have PV panels so i'm producer and consumer
tried to find over the api some indication for the estmations, but it's not available so I guess for my consumer type, which is ok, but the code should not allow those entities and claculation for producerType == 2

I agree, but I want to cover more ground here.
For example - I want to get few questions answered -

Is this your only contract (from API)? Only Account? (I'm assuming you're using just a single customer).
Using GET https://iecapi.iec.co.il/api/Device/{{contract_id}}/{{device_id}} - can you get last meter (consumption) reading?
In IEC API - do you see your current consumption details, if so - (using Network tab in DevTools) - can you find from which API?

I have 1 contract in the array of contracts (from Postman),
I have 1 device although in the website of IEC I have 2 devices (1 was available up until 1.5 years ago, so I guess it's just for reviewing historical data).
I can see the current consumption and wanted to open another issue for that,
I see today's consumption in 1 day lag, meaning, in the result i can see today's consumption, but the data that available in the integration is for yesterday (compared to IEC portal).
Endpoint:
https://iecapi.iec.co.il/api/Consumption/RemoteReadingRange/{{contract_id}}
in the following endpoint I can see both devices:
https://iecapi.iec.co.il/api/Device/LastMeterReading/{{contract_id}}/{{bp_number}}
If you would like me to check it though Postman you created I think it would be much faster, I can also change the code locally according to your suggestion and test it.

Thanks. Ill keep you posted on this thread with check requests.
Which sensor/state do you see in 1 day delay?

Today's consumption,
Thanks a lot for the integration and the super quick response

TodayConsumption is fetched by trying to get (and sum) today's hourly readings.
Often you'll see in IEC site discrepancy between hourly view and daily view etc. I think this is what causes this

is fetched by trying to get (and sum) today's hourly read

opened another issue about it, there are huge gaps and suggested solution following what is being done in IEC portal (different resolution, no need to aggregate / calculate)

@elad-bar - correct, only the data is usually behind the hourly check


classifier giving wrong result

I have started learning Natural Language Processing and have already started stumbling.
Problem
I am training my document with several scenarios as shown below
/// importing package
var natural = require('natural');
var classifier = new natural.BayesClassifier();

/// traning document
classifier.addDocument("h", "greetings");
classifier.addDocument("hi", "greetings");
classifier.addDocument("hello", "greetings");
classifier.addDocument("data not working", "internet_problem");
classifier.addDocument("browser not working", "internet_problem");
classifier.addDocument("google not working", "internet_problem");
classifier.addDocument("facebook not working", "internet_problem");
classifier.addDocument("internet not working", "internet_problem");
classifier.addDocument("websites not opening", "internet_problem");
classifier.addDocument("apps not working", "internet_problem");
classifier.addDocument("call drops", "voice_problem");
classifier.addDocument("voice not clear", "voice_problem");
classifier.addDocument("call not connecting", "voice_problem");
classifier.addDocument("calls not going through", "voice_problem");
classifier.addDocument("disturbance", "voice_problem");
classifier.addDocument("bye", "close");
classifier.addDocument("thank you", "feedback_positive");
classifier.addDocument("thanks", "voice_problem");
classifier.addDocument("shit", "feedback_negeive");
classifier.addDocument("shit", "feedback_negeive");
classifier.addDocument("useless", "feedback_negetive");
classifier.addDocument("siebel testing", "siebel_testing")

classifier.train();

/// running classification
console.log('result for hi');
console.log(classifier.classify('hi'));
console.log('result for hii');
console.log(classifier.classify('hii'));
console.log('result for h');
console.log(classifier.classify('h'));

Output
result for hi:
greetings

result for hii:
internet_problem

result for h:
internet_problem

As you can see in the result of the key work hi the value is coming correct but if I misspelled hi for hii or ih then it's giving a wrong result. I am not able to understand how does classification works and how should I train the classifier or is there a way to find out that the result of classification is wrong so that I can request an user to input again.
Any help or explanation or anything is highly appreciated. Many thanks in advance.
Please consider me as a noob and forgive for any mistake.

This doesn't seem too unexpected. Neither 'h' nor 'hii' occur in the training data, and when the classifier doesn't know what to do with the input, it gives you the most frequent class from training, which is "internet_problem" with 7 instances.


Document request size limits for Workers

Expected Behavior
https://developers.cloudflare.com/workers/platform/limits includes documentation about the maximum size of an HTTP request to Workers (e.g. 30MB, 500MB, unlimited).
Actual Behavior
There is no documentation explaining what the maximum size for a request can be.
Section that requires update
https://developers.cloudflare.com/workers/platform/limits#worker-limits
Additional information
Google App Engine documents the max request and response size.

Trial-and-error on my own worker indicates that, for a paid account, the limit is above 100 MB and below 200 MB. I don't have the hard numbers and don't know where to find them, but I'll have more time to bounce files around later.
Good luck with this.

Alright, both free and paid workers throw 413's (Request entity too large) above 100 MB, with an error margin of 1 MB. I'll make a pr declaring 100 MB as the maximum body size in the limits chart :^)

~Alright, both free and paid workers throw 413's (Request entity too large) above 100 MB, with an error margin of 1 MB. I'll make a pr declaring 100 MB as the maximum body size in the limits chart :^)~
Request size is limited by your cloudflare plan (100MB for Free/Pro, 200MB for Business, 500MB+ for enterprise.

where did you get this info from?

Information from here https://support.cloudflare.com/hc/en-us/articles/200172516-Understanding-Cloudflare-s-CDN
Reasoning is: If Pages runs after entry to the CDN, and tested upload limits match the CDN's, then the cloudflare CDN should set the upload limit. I also noticed the response for POSTs that were too big (413) responded 3-10x quicker than a 200 response which reaches the worker, indicating that Cloudflare's gateway and not the workers server rejected this request. Unsure of internal limits the workers server may impose, but this should be a good start.

Information from here https://support.cloudflare.com/hc/en-us/articles/200172516-Understanding-Cloudflare-s-CDN
Reasoning is: If Pages runs after entry to the CDN, and tested upload limits match the CDN's, then the cloudflare CDN should set the upload limit. I also noticed the response for POSTs that were too big (413) responded 3-10x quicker than a 200 response which reaches the worker, indicating that Cloudflare's gateway and not the workers server rejected this request. Unsure of internal limits the workers server may impose, but this should be a good start.

sounds good! remember to rebase :) https://github.com/cloudflare/cloudflare-docs/pull/1372#issuecomment-862537763


New package: Problox v0.1.0

Registering package: Problox
Repository: https://github.com/femtomc/Problox.jl
Created by: @femtomc
Version: v0.1.0
Commit: f94894f85d6c25095e7583541c74a532b42ffe6b
Reviewed by: @femtomc
Reference: https://github.com/femtomc/Problox.jl/issues/1#issuecomment-665341886

I fixed the compat issue - but there's a bigger issue. This package requires a Python package be installed, which cannot be installed through Conda.jl (i.e. it's not available on normal channels, only through pip). How do I get around this?

@femtomc I assume you found a way around it and now this PR should be fine?

@giordano Yes, I included a chunk of code which does the right thing on arbitrary local machines (at least, it passes CI) to setup the Python side.

I've added the [noblock] text to all these messages, otherwise this PR won't ever be automerged

Ah - thank you! I did not read carefully 😃
[noblock]


Make the Flake8 tox builder nicer + instructions nicer

Current coverage is 57.46%

Merging #492 into master will not affect coverage as of 411b912

@@            master    #492   diff @@
======================================
  Files           51      51
  Stmts         9192    9192
  Branches      1547    1547
  Methods          0       0
======================================
  Hit           5282    5282
  Partial        516     516
  Missed        3394    3394

Review entire Coverage Diff as of 411b912

Powered by Codecov. Updated on successful CI builds.

:+1: the easier it is to run flake8 the more likely it gets run before the pull-request and inevitable "flake8" commit ;)


ExoPlayer: Android 6.0 - Video disappears

I'm using a full screen background video which seems to disappear after minimizing the app. This works just fine on other OS versions and on 6.0 if using the standard MediaPlayer build.

Can u provide a reproduction repo?
Also, what do you mean by minimizing the app?
If you can try to test this the Exoplayer instead of MediaPlayer and let us know if it's still happened it would be great.

Tried on a few devices and it looks like this may be device specific too. Can't recreate on Nexus 5 Android 6.0.1 but happens sometimes on Lenevo A7020a48 Android 6.0. Seems quite intermittent and a bit more rare than I had originally thought.
Thanks for looking into this.

A little more info for you @cobarx. This is happening only upon a video switch which is followed by a minimize. My app uses a full screen video background and we tried several times and this is the only case where this happens. Seems pretty corner case. Feel free to ignore and close out the issue.


Update highlight background when forced colors are active (bug 1759886)

When forced color are active this updates the background of highlights to use CSS system colors, so Windows HCM mode will pick a highlight color that strongly contrasts the text.

Ideally we could add outlines for highlights and remove the background to provide better contrast, but I don't think this is possible without forced-color-adjust: none or color: transparent support.

/botio-linux preview


Fuzzing against verified fork of spec interpreter

Following discussions with @fitzgen, @alexcrichton, @cfallin, and @abrown, and at the Feb 17th meeting, this is a patch to update the previously disabled spec-interpreter differential fuzzing to instead use my verified Wasm interpreter (https://github.com/conrad-watt/spec/tree/wasmtime_fuzzing/interpreter). Currently all post-MVP features are disabled, although I'm working towards enabling SIMD.
Unfortunately I couldn't find a way to make the OCaml build system automatically find the gmp library (a new dependency, along with the zarith OCaml library), so the wasm-spec-interpreter/ocaml makefile now uses a LIBGMP_PATHS var to manually feed in this information.

Nice work! Looks like there's just a few annoying bits to fix. I suggest that however we solve the "ocamlfind is not present" error (and the gmp paths as well), we make it easy on ourselves when we set up the environment for this to run on oss-fuzz. I had to tweak this Dockerfile a few times to get the OCaml bits in place; maybe we should just have a script in Wasmtime to do this for us?

I'm not sure how to tackle the fuzzing CI failures. Should I be looking at one of the scripts in the ci folder?

The fuzz targets CI seems to be working now (fingers crossed).
BTW, the tests I fixed in my latest commit don't appear to be run as part of the CI. Is this intended? They can be run manually with cargo test --features build-libinterpret in the crates/fuzzing/wasm-spec-interpreter subdir.

To get this fuzzed on oss-fuzz we also need to update oss-fuzz's Dockerfile for wasmtime. I attempted a patch that adds libgmp-dev and then uses opam install for ocamlfind as well as zarith (and I had to tweak the CFLAGS for zarith to get it to compile right since it shouldn't use the default fuzzing flags since we're using the system compiler at the docker-image-build-time rather than the llvm compiler). When building wasmtime though I get:
error: failed to run custom build command for `wasm-spec-interpreter v0.1.0 (/src/wasmtime/crates/fuzzing/wasm-spec-interpreter)`

Caused by:
  process didn't exit successfully: `/src/wasmtime/target/release/build/wasm-spec-interpreter-2c2fa92e1c9017fb/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=ocaml/interpret.ml
  cargo:rerun-if-changed=ocaml/Makefile
  make -C spec/interpreter libopt
  make[1]: Entering directory '/src/wasmtime/crates/fuzzing/wasm-spec-interpreter/ocaml/spec/interpreter'
  ls binary/decode.ml binary/decode.mli binary/encode.ml binary/encode.mli binary/utf8.ml binary/utf8.mli exec/eval.ml exec/eval.mli exec/eval_num.ml exec/eval_num.mli exec/eval_vec.ml exec/eval_vec.mli exec/f32.ml exec/f32_convert.ml exec/f32_convert.mli exec/f64.ml exec/f64_convert.ml exec/f64_convert.mli exec/fxx.ml exec/i16.ml exec/i32.ml exec/i32_convert.ml exec/i32_convert.mli exec/i64.ml exec/i64_convert.ml exec/i64_convert.mli exec/i8.ml exec/ixx.ml exec/v128.ml exec/v128.mli host/env.ml host/spectest.ml host/spectest_isa.ml main/flags.ml main/main.ml runtime/func.ml runtime/func.mli runtime/global.ml runtime/global.mli runtime/instance.ml runtime/memory.ml runtime/memory.mli runtime/table.ml runtime/table.mli script/import.ml script/import.mli script/js.ml script/js.mli script/run.ml script/run.mli script/script.ml syntax/ast.ml syntax/free.ml syntax/free.mli syntax/operators.ml syntax/types.ml syntax/values.ml tests/smallint.ml text/arrange.ml text/arrange.mli text/lexer.mli text/lexer.mll text/parse.ml text/parse.mli text/parser.mly text/print.ml text/print.mli util/error.ml util/error.mli util/lib.ml util/lib.mli util/sexpr.ml util/sexpr.mli util/source.ml util/source.mli valid/valid.ml valid/valid.mli verified/WasmRef_Isa_m.ml verified_wrapper/ast_convert.ml verified_wrapper/f32Wrapper.ml verified_wrapper/f32Wrapper_convert.ml verified_wrapper/f64Wrapper.ml verified_wrapper/f64Wrapper_convert.ml verified_wrapper/i32Wrapper_convert.ml verified_wrapper/i64Wrapper_convert.ml verified_wrapper/implWrapper.ml verified_wrapper/implWrapperTypes.ml verified_wrapper/libAux.ml \
        | sed 's:\(.*/\)\{0,1\}\(.*\)\.[^\.]*:\2:' \
        | grep -v main \
        | sort | uniq \
        >wasm.mlpack
  echo >_tags "true: bin_annot"
  echo >>_tags "true: debug"
  echo >>_tags "true: optimize(classic)"
  echo >>_tags "<{util,syntax,binary,text,valid,runtime,exec,script,host,main,tests,verified,verified_wrapper}/*.cmx>: for-pack(Wasm)"
  ocamlbuild -use-ocamlfind -lexflags -ml -cflags '-w +a-3-4-8-11-20-26-27-32-39-42-44-45 -warn-error +a-3 -unboxed-types' -I util -I syntax -I binary -I text -I valid -I runtime -I exec -I script -I host -I main -I tests -I verified -I verified_wrapper -pkgs zarith -libs bigarray -quiet wasm.cmx
  + ocamlfind ocamlc -c -w +a-3-4-8-11-20-26-27-32-39-42-44-45 -warn-error +a-3 -unboxed-types -g -bin-annot -package zarith -I exec -I text -I binary -I runtime -I host -I util -I script -I verified_wrapper -I syntax -I valid -I verified -I main -I tests -o exec/fxx.cmo exec/fxx.ml
  File "exec/fxx.ml", line 1:
  Error (warning 70 [missing-mli]): Cannot find interface file.
  Command exited with code 2.
  rm wasm.mlpack _tags
  make[1]: Leaving directory '/src/wasmtime/crates/fuzzing/wasm-spec-interpreter/ocaml/spec/interpreter'

  --- stderr
  Cloning into 'ocaml/spec'...
  make[1]: *** [Makefile:101: _build/wasm.cmx] Error 10
  make: *** [Makefile:33: spec/interpreter/_build/wasm.cmxa] Error 2
  thread 'main' panicked at 'Failed to build the OCaml library using 'make'.', crates/fuzzing/wasm-spec-interpreter/build.rs:58:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I'm not familiar enough with ocaml builds to know what's going on here, but @conrad-watt do you know what the error is here? If you'd like to reproduce locally you can check out https://github.com/google/oss-fuzz, apply the patch above, and then run python infra/helper.py build_fuzzers wasmtime

I think this is a new warning (promoted to error by -warn-error) specific to Ocaml 4.13, so this environment must be building with a very new version of OCaml. Since the error is occuring in the repo I have control over, I've just pushed a small change to the makefile that should get rid of it.

Ah that worked perfectly, thanks!

https://github.com/google/oss-fuzz/pull/7346 managed to get in in time and the latest build of wasmtime on 2022-03-02 succeeded and differential_spec is in the logs there, so we should start seeing fuzzing on oss-fuzz soon, although hopefully no crashes!
This reminds me actually, if we get a crash we'll reduce it and figure out what's causing it, but @conrad-watt if it's a bug in the spec interpreter where would you prefer issues to be filed? I think the two options are here with you cc'd or your spec repo, and either way should work for us

As a default, if it's a Wasm-semantics bug in the spec interpreter I'd prefer it as an issue in my repo - if it's a bug with the build or Rust FFI I guess it can go here (or as a new issue in this repo).

I wonder if this is related to this issue (the amount leaked is the same!).

Follow-up thought: maybe it would make sense to pin a specific version of OCaml (I'm personally using 4.11.2 locally), since this appears to be the second gotcha introduced because the fuzz setup is grabbing the latest release. It looks like the opam install script the Dockerfile is using can be configured with a --version flag.

Ah yeah that looks like precisely the issue, shame on me for not doing a google search... Otherwise though we are clearly novices in working with ocaml on the Wasmtime side of things, and pinning to a single working version of ocaml sounds good to me. I'll see if I can frob the docker script to force 4.11.2


Extract ViolationHash class

I've been studying the RuboCop engine as I work on an engine for Reek.
There's a lot happening in rubocop.rb, with many mixed levels of
abstraction. It seems that extracting out the responsibility of
building the violation hash would make things easier to understand and
maintain.
I've not yet updated the tests to reflect the new structure. I'll await
feedback on this proposal first.

Closing due to staleness.


Update upstream testsuite

Required tweaking a few error messsages for handling passive memory when
bulk memory is not enabled.

@alexcrichton do you want to do a publish now?

Sure thing


Implement Rate Saturation for Actuator Signals

Objective:
The goal is to enhance the project by introducing rate saturation for the actuator signals. Currently, the system lacks rate limitation for the signals applied to the actuators. This enhancement aims to include saturation in both the amplitude and the time derivative of the actuator signals, providing more comprehensive testing framework for the controllers designed.
Proposed Changes:
To implement rate saturation effectively, the following changes are proposed:
Introduce positive and negative rate saturation for the signals of the three actuators.
Extend the experiment and log files by incorporating six new columns to handle the rate saturation parameters.
These new columns will allow for the proper configuration and recording of the actuator rate saturation, providing valuable data for testing and evaluating the performance of designed controllers.

Rate of change limitation was included as an experiment disturbance for all actuators. Therefore, new columns were added in the experiment files.


Populate development and staging with 100,000 and 200,000 facilities and identify capacity issues

Overview
Populate development and staging with 100,000 and 200,000 facilities and identify capacity issues
Is your feature request related to a problem? Please describe.
100,000 to 200,000 is an estimate on the total number of facilities globally. We are not sure how large our Dedupe model will be at this size and if tile queries will remain performant.
Describe the solution you'd like

Ensure that there is a staging database snapshot that can be restored after testing
Document and/or script the process of generating synthetic facility data and loading it into development and staging.
Load development and staging up to 100,000 records.

Measure the memory footprint and training time for model
Run the k6 load tests and record results https://github.com/open-apparel-registry/open-apparel-registry/tree/develop/load-tests

Load development and staging up to 200,000 records

Measure the memory footprint and training time for model
Run the k6 load tests and record results https://github.com/open-apparel-registry/open-apparel-registry/tree/develop/load-tests

I increased this from 150,000 to 200,000 after a discussion with the OAR management team. It is a more reasonable upper bound looking 5 years into the future.


[Scroll] Include content insets in scroll events

When calculating how far the user has scrolled, it is necessary to know the content insets where:
number of pixels scrolled = content offset + leading content inset for the scroll axis

This diff adds the contentInset field to native scroll events.

Thanks @nicklockwood (#792)

👍


Roll Flutter Engine from c9ec468c7592 to 18d544b867e4 (3 revisions)

https://github.com/flutter/engine/compare/c9ec468c7592...18d544b867e4
2024-08-09<EMAIL_ADDRESS>Roll Dart SDK from 1cc09f3f3642 to 35bc5c866149 (1 revision) (flutter/engine#54468)
2024-08-09<EMAIL_ADDRESS>Roll Skia from 0bedf6746d9e to 31c432c02665 (1 revision) (flutter/engine#54467)
2024-08-09<EMAIL_ADDRESS>Roll Dart SDK from 9222e4c96f4d to 1cc09f3f3642 (2 revisions) (flutter/engine#54465)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC jsimmons@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


Added Antipatterns.tla

[ ] Tests added for any new code
[ ] Ran make fmt-fix (or had formatting run automatically on all files edited)
[ ] Documentation added for any new functionality
[ ] Entries added to ./unreleased/ for any new functionality

closes #2497

We should make sure that if someone finds this spec in a couple of years from now, they understand why it is relevant and what it is meant to be used for.
Can you please add some context on what motivates this, ideally to both the spec and either to this PR description or the issue closed by it?

Codecov Report

Merging #2498 (b14c584) into main (44e7331) will decrease coverage by 0.01%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #2498      +/-   ##
==========================================
- Coverage   78.39%   78.39%   -0.01%
==========================================
  Files         441      441
  Lines       15443    15443
  Branches     2520     2520
==========================================
- Hits        12107    12106       -1
- Misses       3336     3337       +1

see 1 file with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

From the file:
The purpose of this file is to collect known antipatterns, so we can measure just how
much they affect performance, across various versions of Apalache.
As a side-effect of the work done on ADR20, the performance hit when using anipatterns,
while still present, is expected to be less drastic than before.

Looks good for me too. I may suggest one more pattern: build a list from a function by folding. Happened to me a few times.

You mean a seq of the form <<f[1], f[2], ..., f[n]>>?

Looks good for me too. I may suggest one more pattern: build a list from a function by folding. Happened to me a few times.

You mean a seq of the form <<f[1], f[2], ..., f[n]>>?

Yes


New demo - adding a track to the queue WITH METADATA!!

I have been experimenting with the new music services code. It looks as though we can now add a track to the queue, given only its id (eg Spotify or Deezer track_id).  All the metadata is filled in automatically.
Please test and comment.
https://gist.github.com/lawrenceakka/2d21dca590b4fa7e3af2

Works fine. Tested with Deezer.
Thanks!!
-Rolf

Hi @lawrenceakka
This demo was used for inspiration for the work in #455 which has been merged and should be release soon, so I think we can close this one. Feel free to re-open if you think we need it still.


Better error message when Link fails invariant

When a Link fails an invariant (eg. because it's missing params) the warning message I get is:
ReactRouter.min.js:6 Uncaught Error: Invariant Violation: Missing "id" parameter for path "/foo"
Which makes it incredibly hard to tell where in my application the link that I need to fix is. I pretty much have to search for everywhere I Link to "/foo" and then identify which one is missing the parameter.
 It'd be a lot cleaner if it said something like:
MyComponent.js:77 Link to "/foo" is missing parameter "id".

Or also if you have a  with no "to" field then the error message I get is "Uncaught TypeError: Cannot read property 'charAt' of undefined"

yeah we could have better error messages all around, we'll get back to this after 1.0 unless you want to take a stab at a pull request :)

to is required now and params are gone, so there's nothing to revisit here.


fix: move all EmailActionTypes to mailer package

What kind of change does this PR introduce?
Moves the mail related refactors from #1496  into a new PR so the hook related PR is easier to review. This PR moves all EmailActionTypes to mailer package to establish an explicit link between mailer and the packages it is used in.
The changes are cosmetic and should not affect underlying functionality.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

31 of 34 (91.18%)  changed or added relevant lines in 3 files are covered.
10 unchanged lines in 1 file lost coverage.
Overall coverage remained the same at 65.127%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

internal/api/verify.go
20
21
95.24%

internal/api/mail.go
5
7
71.43%

Files with Coverage Reduction
New Missed Lines
%

internal/mailer/mailer.go
10
73.33%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
8025

Relevant Lines:
12322

💛  - Coveralls


mismatched types; Rust type core::option::Option<alloc::string::String> (as SQL type VARCHAR) is not compatible with SQL type VARBINARY

Description
create table with field like varbinary(20) will result in error with find_by_id(id)
error occurred while decoding column
mismatched types; Rust type `core::option::Option<alloc::string::String>` (as SQL type `VARCHAR`) is not compatible with SQL type `VARBINARY`

Steps to Reproduce

Expected Behavior

Actual Behavior

Reproduces How Often

Versions

Additional Information

Hello, @ttys3! Thank you for the report. Can write a small example which reproduces error?

And I think varbinary is not equal to String. You can use Binary instead of String.

Hey @ttys3, I think varbinary should represented as Vec<u8> in Rust

@ikrivosheev  @billy1624  I updated the issue with re-produce steps.
I think the problem is sea-orm-cli generate entity does not support table has VARBINARY fields


binwalk extracts empty cramfs-root directory lot of *.zlib files

Hi,
You can find the .bin file in the following location:
https://www.phoenixcontact.com/online/portal/us?uri=pxc-oc-itemdetail:pid=2832658&library=usen&pcck=P-08-08-10-01-01&tab=5
Under Software
Firmware Package
FW_3.49.zip
I used binwalk -e <file.bin> and got empty "cramfs-root" directory and many zlib files. I want to extract the file system in this firmware.
Advise please.

Same here, any new information on that problem?

No updates as of right now, but I can put it on my to-do list to try and take a look at some point.

Temporary workaround - If you just need to extract the CramFS filesystem, a workaround is to use p7zip directly:
$ 7z x FL_SWITCH_LM_3_49.bin -o_FL_SWITCH_LM_3_49.bin.extracted_cramfs

This should successfully extract the /bin, /en and /img directories for that firmware image into a local folder named _FL_SWITCH_LM_3_49.bin.extracted_cramfs
Additional Debugging Info
Here are some additional steps I took while trying to figure out what was going wrong.
Swapping Extractor with -D
For whatever reason I'm not able to swap out the extractor using -D. I tried:
$ binwalk -e -D 'cramfs:cramfs:7z x %e' FL_SWITCH_LM_3_49.bin
$ binwalk -e -D 'cramfs filesystem:cramfs:7z x %e' FL_SWITCH_LM_3_49.bin
$ binwalk -e -D 'cramfs filesystem:cramfs:7z x %e -o%%cramfs-root%%' FL_SWITCH_LM_3_49.bin
$ binwalk -e -D 'cramfs filesystem:cramfs:7z x %e -o'%%cramfs-root%%'' FL_SWITCH_LM_3_49.bin

Running with sudo Privs
It appears that one of the fallback cramfs extraction options only works when you run with sudo:
https://github.com/ReFirmLabs/binwalk/blob/2e5a6af9d4643e206bf773858e100084ffbae5db/src/binwalk/config/extract.conf#L70
Testing this, running sudo binwalk -e FL_SWITCH_LM_3_49.bin did not result in successful extraction. An empty volume gets mounted, and no additional information is extracted.
As noted above, using the 7z tool directly worked fine.

Got stuck with a similar problem, running cramfsck directly should reveal more details. For ex:
$ cramfsck -v -x out_folder FL_SWITCH_LM_3_49.bin
cramfsck: superblock magic not found

or in my case:
$ cramfsck -v -x out_folder 1F4000.cramfs
...
l 0777         7   501:245 out_folder/bin/wget -> busybox
d 0755      1900   501:245 out_folder/dev
c 0644    5,   1   501:245 out_folder/dev/console
cramfsck: mknod failed: out_folder/dev/console: Operation not permitted

It's kind of bad that it fails silently, had no idea extraction had failed halfway trough since it produced some files.

This appears to extract correctly with Binwalk v3


Distribute CA cert without key

The CA cert that is distributed contains the key, which is not needed.
PR 520 removed the server.crt and server.key, but the ca.key is still distributed.
I do not see this being used, so is it perhaps a good idea to remove the key and only keep the ca.crt?
In file vault_controller.go:
// We need the CA certificate only
	delete(currentSecret.StringData, "server.crt")
	delete(currentSecret.StringData, "server.key")
	delete(currentSecret.StringData, "ca.key") // add this
	delete(currentSecret.Data, "server.crt")
	delete(currentSecret.Data, "server.key")
	delete(currentSecret.Data, "ca.key") // and this

I'm happy to create a PR, but first wanted to check up in case I'm missing a very good reason for the key to be present.

Yes, "ca.key" it is absolutely not needed, happy to review the PR!

Okay, I'll send one tonight (kids 😉)


docs: trivial change to highlight a term

Testing if prow/tide will auto-merge this PR despite some cirrus-ci status checks having failed/incomplete.

/lgtm
/approve

LGTM, vendor isn't happy?

@TomSweeneyRedHat thx for looking.  We're testing something here, sorry for not making that obvious.

okay, this is only sort-of-good. The 'Cirrus CI' status requirement is not the one we want.  It should have gone red but still shows pending even though all the tasks are complete.
The good news is that tide did not merge (despite saying 'in merge pool' quite a while). Let's let this sit here in this state, to be sure it won't merge.  If it doesn't, that means it is sensitive to the general github statuses (wouldn't be surprising to me).  Meaning I can point github at the more general 'success' task from cirrus, and we can use that for now.

Okay, still no merge in over an hour.  Also based on some docs I found, I'm going forward believing prow/tide to honor the branch-protection based status set by github.
I'll set it up with the list of checks we have now, while I investigate a better long-term solution.

@mheon @baude just for ref. you can see the rules I set here: https://github.com/containers/libpod/settings/branch_protection_rules (under master)
The branch-protection based checks I added are imperfect, but better than we had before: There's no way to have it monitor matrix tasks, since the name includes the axis items (like image name).  For now let's leave this PR as-is, while I look into fixing this more permanently from the prow/tide side...

@cevich branch protection settings are being managed by automation and your changes will get removed ...

You also misinterpreted the documentation there. Please submit a pull request to add non-Prow managed contexts to your branch protection rules in openshift/release

@stevekuznetsov  oh thanks for responding.  Okay, fair enough about the branch-protection, that was just a band-aid anyway until I could figure out a better way.  I sent you an e-mail re: the github-actions API calls we need to make from tide (?).  Simply adding a job won't be enough, since the github-actions run in parallel.  It's got to happen near the very end, like when tide (?) is polling for label changes.
Hints on where I could add this and the docs. that cover it?

/hold

We're going to fix this a different way.


v0.10.1

Are you kidding me? PR is not a PR without failed LGTM check.
Why pip hasn't installed tomlkit deps?
Why Python 2.7 was identified on the prepare step?
Why Python 2.7 is by default at all in 2018...

No comments. Absolutely not obvious.
[2018-10-25 11:12:13] [build] Configuration file:
[2018-10-25 11:12:13] [build] extraction:
[2018-10-25 11:12:13] [build]   python:
[2018-10-25 11:12:13] [build]     python_setup:
[2018-10-25 11:12:13] [build]       version: 3

[2018-10-25 11:12:14] [build] ++ python -V
[2018-10-25 11:12:14] [build] Python 2.7.15rc1
[2018-10-25 11:12:14] [build] ++ pip -V
[2018-10-25 11:12:19] [build] pip 10.0.1 from /usr/local/lib/python3.6/dist-packages/pip (python 3.6)

LGTM pull request analysis was skipped for 0f3bb01c4b577a8eaaab947d8b5853b44c662b46 by narimansafiulin. Analysis of future commits will happen as normal.

Comment posted by LGTM.com


Running make failed

I imported the cert and put the Apple Developer app inside the the Server folder and renamed it to orig.ipa

+1

+1

A friend tried it as well with this as result^

I don’t like you coolstar❤
I have all your tweaks pirated🥶
all of them are on our discord -
https://discord.com/invite/VM2ZVWqxsj
🔥
and guess what?

Also unable to build due to errors, same as a friend of mine.

It might only compile on Ventura. I was looking at the source and it looks like task_map_kcdata_object_64 is MacOS 13.0+ based on the apple docs
https://developer.apple.com/documentation/kernel/3943647-task_map_kcdata_object_64

It might only compile on Ventura. I was looking at the source and it looks like task_map_kcdata_object_64 is MacOS 13.0+ based on the apple docs
https://developer.apple.com/documentation/kernel/3943647-task_map_kcdata_object_64

Worked fine for my friend on 12.6

It might only compile on Ventura. I was looking at the source and it looks like task_map_kcdata_object_64 is MacOS 13.0+ based on the apple docs
https://developer.apple.com/documentation/kernel/3943647-task_map_kcdata_object_64

Worked fine on 12.6 for a friend of mine

Installing Xcode 14.1 fixed the issues for me, please try the same @Fr0st3h @SammyGuichelaar @Judgemite.

ohhhh yesssssss that worked mate i gonna sleep nowwww yessssssss


SLING-6658:

always reigster the model with its implType, even not specified as adapter explicitly

Can you prepare a patch for https://svn.apache.org/repos/asf/sling/site/trunk/content/documentation/bundles/models.mdtext as well which explains this change (and in the best case links this JIRA issue)?