Fix this extension

I like wakatime but i cant believe that this extension hasn't been updated for 2 years.
can we have either build instructions to build it myself (i cant get to build it in macos) or can we have the latest version published to the extension store
:@

Please @alanhamlett

@Eeems @danez Guys can you at least show me to build the extension. Im using MacOS Catalina and the build fails following the instructions, i tried a lot of things and i couldnt build it....
Can someone help me out publishing the latest version or showing me how to build the extension. Thank you.

@ecrider

It's been a long time since I've touched this. I believe you just need to follow the build instructions in the readme and then use web-ext build to create an extension zip.

Yes, these build instructions should be working. If not let me know and I'll help work through it:
https://github.com/wakatime/chrome-wakatime#development-instructions
We haven't forgotten about this extension, and will get it updated eventually. Currently, our top priorities are:

Rewriting the plugin cores from Python to Go for improved reliability and performance
Getting the WakaTime Desktop app (built with Electron) to v1.0 for improving plugin installation, upgrades, and detection & debugging of any plugin errors. Also, quick access to your stats via system tray icon.
Improving the Chrome & Firefox extensions with smarter project detection, and more options for configuring it's behavior.

What is the problem with just releasing the current version in the Chrome store?

Released the current version in Chrome Web Store.


feat(agents): support Azure deployment with --model

What does this implement/fix?
This PR removes the unnecessary environment variable AZURE_OPENAI_DEPLOYMENT and parses the model passed to the container/script instead.
Since the prefix of --model is used to discriminate whether to use OpenAI, Azure OpenAI, Ollama, Claude etc., the deployment name shouldn't be specified again  in keys.cfg.

See https://github.com/princeton-nlp/SWE-agent/pull/127

I closed it after realizing I was testing it with a deployment name that was "a lack valid name" :/
I find specifying twice the model a little inconvenient though.


Question about invite to which app

What
Nila asked:

question: when you invite someone through the Light Wallet, does it invite people to the Light Wallet or the Global Passport, or does it give them the option of either?

Lite wallet. We must keep it simple for MVP. We can review after release 1.


Adding monitoring for more types of interfaces

Scollector monitors interfaces whose interface names have a specific prefix.
Adding tun, wlan and ppp to be monitored too

https://github.com/bosun-monitor/bosun/pull/1353 also adds things.
What these need is for the interfaces to be categorized into the proper metric. So the scheme should be:
 [os|linux].net (physical interfaces)
 [os|linux].net.bond (for teams and bonds)
 [os|linux].net.tunnel (for tunnel interfaces)
 [os|linux].net.virtual (vlans)
 [os|linux].net.other (vlans)

See reference at bottom.
This way the aggregation of os.net.bytes should be total traffic and we don't double count things.

@kylebrandt : On it. Will send another PR soon.

@kylebrandt : I went through the source this weekend. However, I could not find where to add the metrics aggregation property. Can you please guide?

I am not sure what you mean by 'metrics aggregation property'. Can you expand?

"interface to be categorized into proper metric" and the scheme. => I renamed it to metics aggregation. And am confused where to edit for taking into account other interfaces.

The sample code is for snmp isn't very helpful. Shed some light please?

P.S. I am new to bosun and this is my first PR.
Bosun is awesome; we are just testing it out for now.

@krish7919 Sorry for the delay, was focused on getting 0.5.0 out the door. There is no aggregation property, but tsdb, i.e. opentsdb will do aggregation operations on tags for a metric when querying. So if you query say os.net.bytes with no tags specified and using the sum aggregator, all the series will be summed over time.
So the metric layout matches this schema so only i.e. physical interfaces are under os.net.bytes, so when you query it and aggregate you are not double counting bytes that also pass through virtual / tunnel / bond.
Make sense?


Create additional tests to METdataio to increase code coverage

To be assigned to John Sharples once he has accepted the invitation to join this repository.
Describe the Task
METdataio, specifically the METdbLoad modules require additional tests to increase the code coverage from its current status.  Add appropriate tests, with particular focus on database loading.
Time Estimate
Estimate the amount of work required here.
Issues should represent approximately 1 to 3 days of work.
Sub-Issues
Consider breaking the task down into sub-issues.

[ ] Add a checkbox for each sub-issue here.

Relevant Deadlines
List relevant project deadlines here or state NONE.
Funding Source
Define the source of funding and account keys here or state NONE.
Define the Metadata
Assignee

[ ] Select engineer(s) or no engineer required
[ ] Select scientist(s) or no scientist required

Labels

[ ] Review default alert labels
[ ] Select component(s)
[ ] Select priority
[ ] Select requestor(s)

Milestone and Projects

[ ] Select Milestone as a METdataio-X.Y.Z version, Consider for Next Release, or Backlog of Development Ideas
[ ] For a METdataio-X.Y.Z version, select the METdataio-X.Y.Z Development project

Define Related Issue(s)
Consider the impact to the other METplus components.

[ ] METplus, MET, METdataio, METviewer, METexpress, METcalcpy, METplotpy

Task Checklist
See the METplus Workflow for details.

[ ] Complete the issue definition above, including the Time Estimate and Funding Source.
[ ] Fork this repository or create a branch of develop.
Branch name: feature_<Issue Number>_<Description>
[ ] Complete the development and test your changes.
[ ] Add/update log messages for easier debugging.
[ ] Add/update unit tests.
[ ] Add/update documentation.
[ ] Add any new Python packages to the METplus Components Python Requirements table.
[ ] Push local changes to GitHub.
[ ] Submit a pull request to merge into develop.
Pull request: feature <Issue Number> <Description>
[ ] Define the pull request metadata, as permissions allow.
Select: Reviewer(s) and Development issue
Select: Milestone as the next official version
Select: METdataio-X.Y.Z Development project for development toward the next official release
[ ] Iterate until the reviewer(s) accept and merge your changes.
[ ] Delete your fork or branch.
[ ] Close this issue.

The additional tests contribute towards this issue: https://github.com/dtcenter/METplus-Internal/issues/50

Thanks for creating this ticket for me @bikegeek
I've spent some more time reading through the METdbLoad code and propose the following approach for testing.
No datatbase testing
Initially I'd like to write true "unit tests". These are tests that don't require a database and just check function behaviour. Since run_sql.py provides a convenient abstraction layer for all database reads/writes, we can create a mock of RunSql and use this to test all other modules.
Pros:

Tests can run anywhere, without needing MySQL
Avoids the overhead of setting up and managing a test database
Quickest way to increase test coverage

Cons:

Can't write meaningful tests for run_sql.py
Can't test database interactions

Testing with a datatbase
If we decide we want something more robust, we can have the tests operate on a real test database. This would be akin to "integration tests". To do this we'd need MySQL to be running in the test environment, and then write some test fixtures to manage the database state for each test.
Pros:

Tests are closer to real world functionality of METdbLoad
Tests database specific interactions (e.g. local-file configuration, database version)

Cons:

Requires MySQL to be running in test environment
Requires test infrastructure to setup and manage test database
Greater dev effort required

The above approaches are not mutually exclusive. We can start with the no database approach and transition to using a database later on.  It's likely we could come up with an implementation that can do either approach depending if MySQL is available. For example, the test infrastructure could use a real database when available, otherwise fall back to the mock RunSql.
Let me know if you're happy with this approach, or have any questions?


fix: wrong dgram compatibility info

That PR fix wrong compatibility info about node:dgram. In fact, the realization is quite partial and most popular libraries using dgram not working in Deno.
Proof: https://github.com/denoland/deno/issues/18324#issuecomment-1478034481
Some issues with dgram: https://github.com/denoland/deno/issues?q=dgram

My mistake, see https://github.com/denoland/deno/issues/18324#issuecomment-1737141836

Thanks for this @hey-ab - made a few suggestions. I will go ahead and commit them unless you object, and merge this in the next ~day or so unless I hear from you. Thanks again!


feat(client cli): add props optional param

As of today, if required array is missing in the Open API schema, we mark the properties as required.
Even though the correct behavior should be different, I added a new property called --props-optional (defaulted to false) to update this logic avoiding breaking changes.

semver-major

Good point! I created the issue, but I can't add any tag/label. I also added a comment in code, to make it more clear when we'll need to do the flip.


Is this a spelling mistake?

In the file _layouts/default.html, line 6, there's a variable 'site.baseur' never saw anywhere else, do you mean 'site.baseurl'?

Yeah, this was a typing error.
Thanks for reporting.


wip: fix(content): falco-probe terminology is not used anymore

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind user-interface

/kind content

/kind translation

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area blog

/area documentation
What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Still need to fix it in other langs.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign leogr
You can assign the PR to them by writing /assign @leogr in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: leodido
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [leodido]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: a59df319dfed3cbc437988c064b4fa4b6390026f


Project pre-review

A few things I noticed:

[x] There is a lot of "cruft" in your repo.  Directories that are not clearly labeled, e.g. the matlab code. There are two ways to deal with these.  One is to make sub directories like "prior_art" or "development" and another is to put an annotated directory structure in your README.md by running tree and adding comment lines and putting it in a markdown code block.  Get those example notebooks into the examples directory.  Make a doc directory that contains your use cases, component sketch, tech review presentation, and final poster.

[x] Your tests are pretty weak.  Or at least they appear that way.  One thing that would help with this is to add some docstrings to the tests that state how the tests actually provide a test of the system.  They seem to be "smoke tests" that check if something explodes but don't actually check if the output / result is correct.

[x] I dig the wiki - finish it!

[x] Great use of issues.

Overall looking good!

This is either being worked on or finished - should be all good by the Friday morning deadline.


Use applyChainTick before transaction validation

The mempool must be able to validate transactions which have not yet been included in a block. At the moment, it validates these transactions against the current ledger state, in the assumption that they will be included in the "next" block. The set of transactions in the mempool is then updated every time a block comes in, and reevaluated against the new current ledger state.
This is not correct. The transactions in the mempool will be part of the body of a block, but a block consists of a header and a body, and the full validation of a block insists of first processing its header and only then processing the body. This is important, because processing the header may change the state of the ledger: the update system might be updated, scheduled delegations might be applied, etc., and such changes should take affect before we validate any transactions.
We therefore need to make sure, consensus side, that the transactions in the mempool are validated against the current ledger state to which we have applied the "chain tick" function for the header of the block in which they will end up. Of course, we don't have that header yet; it turns out, all we need is a slot, but we don't even have that slot number yet. We will therefore have to make some assumptions in the mempool: when we are validating transactions without producing a block (that is, when adding transactions into the mempool), we could assume the slot number is the next available one; when we are actually producing a block, then at that point we do have the correct slot number and we should use it.
This will also require some changes to the Byron wrapper. At the moment, the chain tick function only updates the update proposal state; it does not change either cvsLastSlot or the delegation state; for the validation to be correct, it should change both. Technically this requires changes to the spec (see https://github.com/input-output-hk/cardano-ledger-specs/issues/1046), but since updates to the delegation state are idempotent, it's okay to (at least for the time being) do this consensus side (it will happen twice when we apply a block: once in the tick function and then again when ledger processes the block body, but that's not a big concern).

Unfortunately applyChainTick was only recently removed from the API (https://github.com/input-output-hk/ouroboros-network/pull/1226); we will have to bring it back.

https://github.com/input-output-hk/ouroboros-network/pull/1293 reintroduces the chain tick function and extends the Byron chain tick function.


Trying out to compile the source but the hand gesture to open the menu does not work.

Hi, I am a beginner here with Godot 4.3. I downloaded the source, which btw does not work via pc link, using Oculus Quest 3, and also did not work with the native Godot 4.4 dev on Oculus Quest 3, crashes. Probably has to do with the spatial data.
However, I ended up following all the steps (Godot 4.3 manual for install android skd) in compiling the source to an apk. And I am not sure about the settings under  -> Project Settings -> XR -> OpenXR ->Extension -> Hand Tracking etc. Had "Hand Tracking Aim" enabled the first time around, now only Hand Tracking is selected not sure if that does the trick for compiling again, which I am going to ry.
So the menu does not appear, not sure why. And is there a way to change it to a trigger or something?
Thanks for any help.

And, I just noticed that the Godot XR Tools are 4.4 dev is that alright when I use 4.3?

I figured it out. 4.3 --> Lastest source --> Default Hand tracking, and it works.


nltk.help.upenn_tagset should allow returning strings and not just print them

I wanted to write the explanations for parts of speech to a file but I couldn't because the default behavior just prints to the console.
In the mean time I used this work around:
>>>tagdict = nltk.data.load('help/tagsets/upenn_tagset.pickle')
>>>tagdict['JJ']
('adjective or numeral, ordinal', 'third ill-mannered pre-war regrettable oiled
calamitous first separable ectoplasmic battery-powered participatory fourth stil
l-to-be-named multilingual multi-disciplinary ... ')

Not that it's too difficult, it's just that the API in python does usually allow both options (eg pprint.pformat vs pprint.pprint).
I can add the patch if it's welcome.

How would the book need to be changed?  In chapter 5 there are some places where nltk.help is mentioned.  Would these just need to be changed to, e.g.: ">>> print nltk.help.upenn_brown_tagset('NN.*')"?  If so, this is fine, and we just need to leave this issue open until the book is fixed (or else open another issue for that).  Thanks.

Is the suffix problem you mentioned an issue with the code or the data?
How about we add a new function that returns these tuples, instead of modifying the existing function?

Well, there's problem with the data and the code imo. These suffixes need to be added:
fixes = {
    'FW': 'foreign',
    'NC': 'citations',
    'HL': 'headlines',
    'TL': 'titles'
    }

And the code should split on hyphens. I used the following to have it just work...
tagdict = nltk.data.load('help/tagsets/brown_tagset.pickle')
tagdict_b = nltk.data.load('help/tagsets/upenn_tagset.pickle')
tagdict_c = nltk.data.load('help/tagsets/claws5_tagset.pickle')

fixes = {
    'FW': 'foreign',
    'NC': 'citations',
    'HL': 'headlines',
    'TL': 'titles'
    }

def explain_one(part):
    """
    http://alias-i.com/lingpipe-3.9.3/docs/api/com/aliasi/corpus/parsers/BrownPosParser.html

    Each tag consists of a base tag and optional modifiers. This parser removes
    all of the modifiers. The modifiers include multiple tags separated by plus-signs
    (eg. EX+BEZ), multiple tags concatenated in the case of negation (eg. BEZ*),
     the prefix modifier FW- for foreign words (e.g. FW-JJ), the suffix modifier -NC for citations (e.g. NN-NC),
     the suffix -HL for words in headlines (e.g. NN-HL-TL in titles (e.g. NNS-TL).
    """
    # Doesn't work because it only prints: nltk.help.upenn_tagset('JJ')
    if part is None:
        return 'Unidentified'
    if part in tagdict:
        data = tagdict[part]
    elif part in tagdict_b:
        data = tagdict_b[part]
    elif part in tagdict_c:
        data = tagdict_c[part]
    else:
        if part in fixes:
            return fixes[part]
        return '?'

    return data[0]

def part_explained(part):
    result = explain_one(part)
    if result == '?':
        multi = part.split('-')
        return ' '.join([explain_one(i) for i in multi])
    else:
        return result

I think adding a different function would be great (like pprint has 2 functions).

>>> tags = nltk.data.load('help/tagsets/upenn_tagset.pickle')
>>> tags['NN']


Update to xavier_uniform and avoid legacy data.uniform_ initialization

Fixes #1820
@mthrok
I have also noticed that we use .fill_ and was wondering if we could replace with this.
https://github.com/pytorch/audio/blob/main/torchaudio/models/wavernn.py#L177
and when I tried doing that this is the error
----> 1 conv.weight.fill_(1)

RuntimeError: a leaf Variable that requires grad is being used in an in-place operation.

Hi @krishnakalyan3, thanks for working on this.

if we could replace with this.
https://github.com/pytorch/audio/blob/main/torchaudio/models/wavernn.py#L177

You can use torch.nn.init.constant_(tensor, val) to initialize the conv.weight.

I am really not sure why the grad tests and the flake8 tests are failing.

Hi @krishnakalyan3
Thanks for the help. Can we split the PR for the WaveRNN update?
The two changes seem to me a bit different.

Will do!

Thanks for the feedback @mthrok and @nateanl. I have made the necessary changes. Do we know why the CI Circle builds are failing?.

Hi @krishnakalyan3, the unittest failures are not related with the PR.
According to the style check, removing lines with math.sqrt should resolve it.

@krishnakalyan3 There seems some issue when importing the PR to fbcode. Let me close it and re-open it. Sorry for the inconvenience.