fix(kvm): check for existance of /dev/kvm

The issue arises from kernel modules not listed by lsmod. KVM check fails from this issue.
Instead of checking for kvm module, check for existence of /dev/kvm.
This is done by the kvm-ok tool as well, where I also took the CPU checking part.
Tested on Arch Linux running on WSL2 with debian bookworm arm64 and amd64.

Hello @glacion, thank you for the contribution! One thing - I had to revert EDK2 for x86 because it somehow breaks GitHub Actions tests (freezes on Wait for SSH step). It's fairly difficult to debug this behavior, however if you have ideas on how we can solve the issue please share. And once again thank you for the updates 🤗
PR with fix for GH Actions tests: https://github.com/andreygubarev/molecule-qemu/pull/27

Hi, I ran it on my M1 Pro device while making the edk II changes and there were no issues. Tried it on my WSL device as well now, I can't replicate the issue on GH actions with both test-platform-amd64 and test-platform-arm64. The failing case was test-platform-amd64.
Can't really debug it working on actions, but running the bare qemu invocation without molecule and with -nographic instead of -display none -daemonize on my local systems it's easy to see when it's going to work and when it's not.
However on my machine ubuntu on arm64 failed due to edk2 not being able to find the boot disk, probably related to the edk2 binary I pulled from arch linux, the previous QEMU_EFI.fd works with it. I'll try with edk2 binaries from debian packages.
If these work and GH actions still fail then the probable cause is that running QEMU on GH actions being so slow that it breaches the timeout waiting for SSH, increasing them could get that to work.

I ran it on my M1 Pro device while making the edk II changes and there were no issues.
Confirming, tested locally without any issues.

I'll try with edk2 binaries from debian packages.
I pulled bios from debian bullseye repo If I'm not mistaken. I'll try to debug this as well with bookworm repo. Approach you implemented seems very reasonable to me so I definitelly think this part should be released.

I'll keep you posted on results of debugging process.


Some buttons become inactive / non-clickable when extension is on

When the extension is enabled, some buttons become non-clickable. I can re-enable the buttons by toggling the extension off (no page reload required).
As an example, when I visit this page:

https://github.com/heroku/heroku-buildpack-go/pull/78#issuecomment-101049255

the "Subscribe" / "Unsubscribe" button is not clickable.
Another example, when I visit this page:

https://github.com/sparklemotion/nokogiri/issues/1292

and I try to use the "Labels" select menu, the "Labels" along with the gear icon are not clickable and do not respond to hover with a color change. (Keep in mind that I'm permissioned to set labels on that project -- you will likely need to repro on a project for which you're permissioned).
Let me know if I can provide additional information.

The "assign yourself" button issues don't work when expanded either.


[performance] Tune the latency performance

As per the discussion on akka-user group and akka scheduler documentation , akka scheduler executes (over)due tasks at every tick (configured by akka.scheduler.tick-duration, 10ms be default). This explains why I've witnessed mean receive latency of 20ms under not high load.
@clockfly

How about setting the tick duration to 1ms ?
Another issue is our netty conf netty.fulsh-check-interval is not used. Is it supposed to used in the duration value below (which is now fixed at 5ms) ?

  def messageHandler : Receive = {
    case msg: TaskMessage =>
      batch += msg
    case flush @ Flush(flushChannel)  =>
      if (channel != flushChannel) {
        Unit //Drop, as it belong to old channel flush message
      } else if (batch.size > 0 && flushChannel.isWritable) {
        send(flushChannel, batch.iterator)
        batch.clear()
        self ! flush
      } else {
        import context.dispatcher
        context.system.scheduler.scheduleOnce(new FiniteDuration(5, TimeUnit.MILLISECONDS), self, flush)
      }
  }

Good finding!
+1

Seems the is fixed by PR #785

Close this.


Check Current App

Is there a way to check what app is running on the device? More specifically which coin?
If not, is this a limitation of the firmware? Or is this just not implemented in C#?

That is a good question. Have you tried the GetFirmewareInfo ?

Thanks. I can see that messages are defined in LedgerWalletConstants. I don't think GetCoinVersion is defined there. Where can I see the full list of messages?
I found this file:
https://github.com/LedgerHQ/ledger-javacard/blob/master/src/com/ledger/wallet/LedgerWalletApplet.java
But, this also does not have GetCoinVersion .

just define it

Ah yes! I see what you mean. Actually the file can be found here:
https://github.com/LedgerHQ/blue-app-btc/blob/master/include/btchip_apdu_constants.h

@NicolasDorier , isn't this call (BTCHIP_INS_GET_COIN_VER) an APDU which is specific to the Bitcoin app?
Wouldn't I already have to be using the Bitcoin app to call this?
https://github.com/LedgerHQ/blue-app-btc

Yeah, take example on the GetFirmwareVersion which already exist in the LedgerClient. This is not that complicated.

Yes, actually, I uninstalled and reinstalled the Bitcoin app today.
I'm thinking that this is not possible because even the Ledger Live app doesn't do this. If I want to add a coin to my portfolio, I have to select it from a drop down list. It can't just automatically detect what app I am using.

Strange thing is that the code for it exists: https://github.com/LedgerHQ/blue-app-btc/blob/master/src/btchip_apdu_get_coin_version.c

That code was committed Nov 19, 2016 so I doubt it's a problem with the app being out of date...

Is it worth logging an issue with the repo?

I tested in my repo, your code is working on my ledger.

Is that nano? Firmware 1.4.2?

App version 1.2.6, firmware 1.4.2

Mine is 1.2.8. It might be broken in this version...

Hmm... It's working now.
I uninstalled and reinstalled the app and now it's OK...
OK. Pull request will be on its way soon I think

nice!

It works fine with Bitcoin and Bitcoin Gold but it doesn't seem to work with any of the other apps. I'm guessing that this APDU is an optional message. I'm thinking I'd better log issues with each of the other apps like Ethereum and so on?
Is there a list of all the app repos?

All bitcoin clones are on  https://github.com/LedgerHQ/blue-app-btc , eth you need to look on somewhere in https://github.com/LedgerHQ/

I expect it to work on all bitcoin clones.

Cool. Maybe I have to update all the apps...
This is probably the ETH app right?
https://github.com/LedgerHQ/blue-app-eth

yes

A quick look tells me that it is not implemented there but I could be wrong.
It seems like this APDU was only half implemented. If LedgerHQ wants to implement this, I think they'd need to force all the apps to implement it.

This is really a wider issue though...
Come to think of it, even GetWalletPubKey doesn't work for most apps. Even Bitcoin Gold expects a different parameter and throws an exception. It doesn't work with Ethereum etc.
There seems to be no real standardized interface across apps.

I am surprised Bitcoin Gold expects a different parameter, what parameter?

btw, I pushed new package including your changes. (<IP_ADDRESS>)


⚠ ClamAV has degraded performance

In 66186d0, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 200 ms

Resolved: ClamAV performance has improved in ea436b9.


Syntax issue for PRELIM task "Find all sudoers files"

Describe the Issue
Small syntax issue in the PRELIM task's name (missing number of a certain task).
Expected Behavior
This PRELIM task is needed for rule 5.3.5 as well.
Actual Behavior
The task's name includes only the number for task 5.3.4
Control(s) Affected
None really, just the title of
PRELIM | 5.3.4 | Find all sudoers files. is not quite accurate.
Environment (please complete the following information):

branch being used: [e.g. devel]

Additional Notes
Anything additional goes here
Possible Solution
I shall provide the fix in a PR.

hi @DianaMariaDDM
Thank you for your Issues and PRs, these are a great help. However it appears that they all fail the pipeline. I believe this maybe due to your fork not running not in sync with the latest commit in devel.
If you could see if you can sync your fork and then re push your PRs i believe this will fix the issue and the pipelines should pass.
Many thanks again
uk-bolly

Hello, thank you as well for your quick reaction!
Yes, I have synced the fork and now those three PRs seem to pass all of the checks.
Thank you for the solution!

hi @DianaMariaDDM
I believe that this issue has been addressed and the fix merged?
I will close this issue, please feel free to reopen or raise a new one if this particular problem still exists.
Many thanks
uk-bolly


Add TGG workflow and pipeline tests

issue: https://github.com/tenstorrent/tt-metal/issues/8321
pipeline: https://github.com/tenstorrent/tt-metal/actions/runs/9023745515/job/24796187446?pr=8327


Feature mma 469

We've changed AbstractSpringMigratorStep class visibility to public

Why didint you merg my request ?

Hi, @holiday-sunrise. Sorry about that. There were other changes in your PR but we wanted to include your contribution so we decided to add it ourselves and reduce the burden on you making all these PRs "atomic".
We are brainstorming ways to collaborate better between the forks and the main code base so we can keep your commits while helping with the cleanup.
Thanks for bringing this suggestion to our attention!


Use postProcessingResource instead of updateVideoIsMuted function.

Context

Summary
Use postProcessingResource instead of updateVideoIsMuted function. This handles duplicating processes that are called multiple times, meaning that mute update will not be called multiple times.
Relevant Technical Choices

To-do

User-facing changes

Testing Instructions

[ ] This is a non-user-facing change and requires no QA

This PR can be tested by following these steps:

Reviews
Does this PR have a security-related impact?

Does this PR change what data or activity we track or use?

Does this PR have a legal-related impact?

Checklist

[ ] This PR addresses an existing issue and I have linked this PR to it in ZenHub
[x] I have tested this code to the best of my abilities
[x] I have verified accessibility to the best of my abilities (docs)
[x] I have verified i18n and l10n (translation, right-to-left layout) to the best of my abilities
[x] This code is covered by automated tests (unit, integration, and/or e2e) to verify it works as intended (docs)
[x] I have added documentation where necessary
[x] I have added a matching Type: XYZ label to the PR

Fixes #

seems like this call was added after I started my work, meaning I missed it.


How config sharding (No master salve) and master slave(no sharding) together with Sharding-jdbc

Question
for example

sharding database(no master_slave):
ds0:
table_0
table_1
ds1:
table_0
table_1
master slave database(no sharding):
ds:
table1
table2
....

If the scenario is 2 unrelated data sources, you may create one sharding-datasource for sharding only, and create masterslave-datasource  for masterslave only

If the scenario is 2 unrelated data sources, you may create one sharding-datasource for sharding only, and create masterslave-datasource for masterslave only

are you mean create 2 sharding-jdbc datasorces,  change use in program? sharding-jdbc not support?

Yes, if they are two different datasource totally.

I am not saying ShardingSphere do not support, but the first thing is perhaps you need to design your business logic.

I just set this issue as invalid for now, we can discuss further about this issue.


Fix bin config

📦 Published PR as canary version: 1.1.1-canary.11.93.0

:sparkles: Test out this PR locally via:
npm install<EMAIL_ADDRESS># or
yarn add<EMAIL_ADDRESS>

:rocket: PR was released in v1.1.1 :rocket:


Journal replay script

WIP -- Waiting for #24 to work from existing game state.
Script takes two journals (one automatic and one with manual edits), merges them, and will apply the journal steps in order to recover correct game state.

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

Comparison is base (f21ccbd) 82.77% compared to head (15346f4) 82.77%.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##              dev      #26   +/-   ##
=======================================
  Coverage   82.77%   82.77%
=======================================
  Files           8        8
  Lines         180      180
=======================================
  Hits          149      149
  Misses         31       31

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

Closing as abandoned, going to try another approach with integrating a journal class directly in the code.


Avatar converted to Functional component

Enhancement
Description
Trying to Convert the Class-based to functional Components
Addition Information (if any)
For the trial basis, I just converted the Avatar component to functional and now the code is more concise.

@pkspyder007 Kindly let me know whether should I convert the rest to functional component or not if yes, give some label to this PR and I will do this as soon as possible

@Abhishek765 Please make the PR to the dev branch. Read the contribution guidelines before doing any changes. Else looks fine to me.

@Abhishek765 Please make the PR to the dev branch. Read the contribution guidelines before doing any changes. Else looks fine to me.

Done can you review and merge it with gssoc and level labels


Broken Link

https://birthday.play-with-docker.com/kubernetes-docker-desktop/
The link behind "voting app definition in Kubernetes" is broken.
Sames applies to the link in the command

kubectl apply -f https://raw.githubusercontent.com/docker/docker-birthday/master/resources/kubernetes-docker-desktop/vote.yaml

hey, thx for reporting. That code is open source, would you like to send a PR here to fix it? https://github.com/play-with-docker/play-with-kubernetes.github.io

I was doing the tutorial. I have no idea of kubernetes, i would be the wrong one to assess it. Sorry.


Move the tests folder outside of src

This has made doing the actual development tricky now that there are hundreds of test files

closed with #213


Adding ISO-639-3 codes to the table

For my own purposes (see https://github.com/commoncrawl/web-languages) one of my volunteers made a mapping from 333 Wikipedia names to the appropriate 3-letter ISO 639-3 language code. Are you interested in adding this information to the table?
Is a csv enough, or should I look more deeply into your code?

Hi, I believe you are offering the 3-letter language codes to create a new column in the table on Commons, generated by this program.
The tables on Commons have some overhead, and are designed with the NUMBEROF template in mind. When the NUMBEROF template is invoked on a Wikipedia page, the template downloads the table from Commons (one time, regardless of the number of invocations on that page). There might be millions of downloads (page views) each day. It has some minuscule effect on page render time. Thus I keep the tables svelte for efficiency only including the data needed by NUMBEROF. If the language codes are needed by another template, you could create a new table on Commons, and load into the template as needed, the same way NUMBEROF works. If you have a use case and want this program (Numberof) to generate a table for you, we can discuss it. I've done something like that before for others who wanted their own version of the table.

I'll make a new table. Thanks for the clue.


Runelite crashes unexpectedly on mouse button input

Type
Crash or hang
Operating System
Windows
OS Version
Windows 10
Bug description
Runelite has crashed twice today unexpectedly. The most I can gather is that it seems to happen on mouse inputs. No other major interface changes happened either time. One was at turoths on a right click, and the other was at the GE on a yellow left click. I don't have enough info about this to reproduce it effectively, but hopefully the crash logs can illuminate on the issue
Screenshots or videos
No response
RuneLite version
Runelite version: <IP_ADDRESS>
Launcher version: 2.6.2
Logs
jvm_crash_pid_34124.log
jvm_crash_pid_39496.log

Update: I'm beginning to think it may be a hardware issue on my end. If there's anything you guys can glean from the logs that can help me figure out what's going wrong, I would be immensely grateful

Duplicate of #10628, we don't know what causes this crash.


[prompt_sorin] Use ✘ and show return value for non-0 rtrns

If you do not want it to show the return code, you can set:
zstyle ':prezto:module:prompt' show-return-val false

If we're keeping the existing behavior as a default, I think we'd need to use -t... I'm not sure what the default should be... other than that it looks good.

I had the default to show the return value. See screenshot attached for how it looks with this change:

This is how it used to look:

This works for me. Better to avoid doublewide characters anyway since quite a few terminals don't handle them properly (as seen in the bottom screenshot).
Thanks!


Cannot open include file: 'cstdio'

Getting this error after trying to build:
Severity	Code	Description	Project	File	Line	Suppression State
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\Util.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3

Using Visual Studio 2017

Severity	Code	Description	Project	File	Line	Suppression State
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\WorkerData.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\BaseLocation.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\BaseLocationManager.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\BotAssert.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\BotConfig.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\BuildOrder.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\Building.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\CombatCommander.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\BuildingManager.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\BuildingData.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\CCBot.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\BuildingPlacer.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\BuildOrderQueue.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\DistanceMap.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\GameCommander.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'vector': No such file or directory (compiling source file ..\src\MapTools.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\maptools.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\JSONTools.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\MeleeManager.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\main.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\Condition.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\MetaType.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\ProductionManager.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\RangedManager.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\MicroManager.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\SquadOrder.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\StrategyManager.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\ScoutManager.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\SquadData.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\Unit.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\UnitInfoManager.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\UnitData.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\Squad.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\TechTree.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\Util.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\UnitType.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3
Error	C1083	Cannot open include file: 'cstdio': No such file or directory (compiling source file ..\src\WorkerManager.cpp)	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\botassert.h	3

Change the windows sdk version of the project in the settings to whatever one you have available

uhm , I've tried that.
Tried on : 8.1, 10.0.10586.0, 10.0.17134.0 and 10.0.17763.0 . not sure what else to try, I have re-done the Library and Include file link

uhm , I've tried that.
Tried on : 8.1, 10.0.10586.0, 10.0.17134.0 and 10.0.17763.0 . not sure what else to try, I have re-done the Library and Include file link

Got it working but getting this now:
Severity	Code	Description	Project	File	Line	Suppression State
Warning	C4244	'initializing': conversion from 'float' to 'int', possible loss of data	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\maptools.cpp	80
Warning	C4244	'initializing': conversion from 'float' to 'int', possible loss of data	CommandCenter	c:\users\the geekiest one\google drive\github\sc2-ai\commandcenter-master\src\maptools.cpp	81
Error	LNK1181	cannot open input file 'kernel32.lib'	CommandCenter	C:\Users\The Geekiest One\Google Drive\GitHub\sc2-ai\commandcenter-master\vs\LINK	1

Might be the space in the folder name, not sure. I can assure you that the compilation works and it's an issue with your system / VS setup, not the project


Display package test fails on local Windows build

What happened?
Building gittuf on a Windows machine in PowerShell or the basic terminal (cmd.exe) causes the test for the display package to fail. Switching to the git bash (i.e. using MinGW) makes this package test pass, but the ssh-keygen test fails instead.
Relevant log output
--- FAIL: TestNewDisplayWriter (0.02s)
    --- FAIL: TestNewDisplayWriter/simple_test_with_paging (0.02s)
        display_test.go:51: unexpected result with Display(), got stdout = Hello, world!
            , want Hello, world!
FAIL
FAIL    github.com/gittuf/gittuf/internal/display       1.332s
FAIL

Code of Conduct

[X] I agree to follow this project's Code of Conduct

looks like it's a newline mismatch, yes?

Fixed by #507


proxysetting: add class level test action

这个 PR 实现什么功能/修复什么问题:
proxysetting: add class level test action

[x] 冒烟测试

是否需要 backport 到之前的 release 分支:

release/3.1

/area region
/cc @zexi @swordqiu @ioito

Codecov Report

Merging #5746 into master will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #5746   +/-   ##
=======================================
  Coverage    6.93%    6.94%
=======================================
  Files         635      635
  Lines      107886   107886
=======================================
+ Hits         7486     7495    +9
+ Misses      99823    99812   -11
- Partials      577      579    +2

Flag
Coverage Δ

#aFlag
6.94% <ø> (+<0.01%)
:arrow_up:

Impacted Files
Coverage Δ

pkg/appsrv/response.go
67.64% <0.00%> (-2.95%)
:arrow_down:

pkg/cloudcommon/cronman/cronman.go
50.87% <0.00%> (+4.82%)
:arrow_up:

Continue to review full report at Codecov.

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


moved more types into common types package

This is a proposal for #57.
Feel free to let me know what may / may not need to change.  :tada:

Hi @david-driscoll, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;

Hi @david-driscoll, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

In order for us to evaluate and accept your PR, we ask that you sign a contribution license agreement. It's all electronic and will take just minutes. I promise there's no faxing. https://cla.microsoft.com.

TTYL, MSBOT;

@david-driscoll, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.
Thanks, MSBOT;

Can we please have a single source of every type (including request and notification type specifications) that is mentioned in the language server protocol specification and separate them from types not mentioned there?
Right now, it is just incredibly hard to generate code for other languages, as the specification is very inconsistent and thus hard to parse (its typescript even has syntactical errors) and the types here are mixed with implementation types that have nothing to do with the protocol (like TextEditChange or TextDocument).
Your pull request makes it even harder, as it adds another indirection with all member in the Methods class - getting the method out of { get method() { return 'textDocument/hover'; } }; is already hard enough when using the typescript parser API.

The idea of the types package is to have the types which are independent of the protocol in a separate package. So we should not move protocol specific types in there. @david-driscoll why do you need these types in a separate package. Do you want to implement your own client in TS ?
@hediet the idea for this is to have a JSON schema in the protocol repository which then can be used to generate 'interfaces' for other languages.
@aeschli any additional comment.

Yeah, I'm implementing the client for Atom.  Almost all of the types are reusable at the client level.  I hate to have to copy and paste things, but that's what I have at the moment.

+1 for a JSON schema description of all type protocol messages & types.
Maybe we should think of a language-service-module package, containing protocol types/messages plus a Connection implementation that can be used for server and client implementations, without any VSCode specific bindings. That would help David as well as other language client implementations that want to implement a client in NodeJS.

All these types are now available in the protocol npm module which is independent of server or client.


in 1.0.0  will show the error that library not found for -lRCTVideo

[ios] in 1.0.0  will show the error that 'library not found for -lRCTVideo',but in the 0,.9.0 will not .

having the same problem:
`
ld: library not found for -lRCTVideo
clang: error: linker command failed with exit code 1 (use -v to see invocation)
** BUILD FAILED **
The following build commands failed:
Ld build/Build/Products/Debug-iphonesimulator/ElectronCalculatorNative.app/ElectronCalculatorNative normal x86_64
(1 failure)
`


GPU Active Messages for all buffer types

This undoes this revert.
The change is pretty much the same, but I had to fix diffs as there were conflicts with the UCPListener change.
I upgrade UCX to 1.11.0-rc3 in this change also, and handle:

Once JUCX 1.11 is published with the change to setAmRecvHandler, the change would be to bring this back, and also set: UCP_AM_FLAG_PERSISTENT_DATA (for the use-after-callback pattern) and UCP_AM_FLAG_WHOLE_MSG (to prevent UCX to call us multiple times with eager fragments in the future).

I also tested https://github.com/NVIDIA/spark-rapids/issues/2892, and I can see that the issue is not reproducible with plain active messages (we no longer use tags).
Updating the docs for UCX 1.11.0 is tracked here: https://github.com/NVIDIA/spark-rapids/issues/2925. I am hoping we can fix the docs once 1.11.0 is not a release candidate.
Closes https://github.com/NVIDIA/spark-rapids/issues/2807.

build


Update citizens plugin

Updates the citizens plugin, minor code changes, mostly changes to .json files to add lots more citizens.

Leave this in please https://github.com/gc/citizens/compare/2e0e7f26652e007c7a33780c9b096c219cde518a...gc:96aaae1838432a4cb5b76dcf6996f356676c24c2#diff-a0331ae2e27e88f21b39edf8df82abee282ac4553de4e3ec8d3b3505d0feb2f4L113

Fixed: https://github.com/gc/citizens/commit/83020312e566b8135606524694de08d1f1292291


Whatsie don't load messages.

WhatSie
Version: 4.16.1
Source Branch: master
Commit Hash: b059958
Build Datetime: Sun Oct 20 12:59:18 2024
Qt Runtime Version: 5.15.15
Qt Compiled Version: 5.15.15
System: Arch Linux
Architecture: x86_64
Install mode: Unknown


mark external links and open them in a new tab

Use a special symbol :after: the link that go to an external resource.
Also, I think, we should use a new tab to open them.

Why not just use HTML? <a href=... target="_blank"> ?

@jorgeorpinel yep, that can be exactly the solution we are looking for 👍 . The only thing left is to integrate it into engine - generate different link with or w/o target blank.

I mean we can just enter HTML into the .md files. Or do you want to extend the MD language like [external](link)_blank ?
Another option would be to open links that go outside the website domain (dvc.org) in a new tab by default and let the

and let the user Cmd+click the other ones

Another option would be to open links that go outside the website domain (dvc.org) in a new tab by default

Yep. And I think the engine can detect those and put _blank automatically.


[RFC] Out of the box JSON/YAML serialization

Even though JSON::Serializable is a big improvement over JSON.mapping, having to include JSON::Serializable in every type feels like a burden.
In many other languages, for example, C#, Go, and I guess Java, serialization works out of the box through runtime reflection. We can do the same in Crystal, with compile-time reflection.
The way to do this is this: we define Object.from_json(string_or_io), on every Object. What this does is create an instance with allocate (unsafe), create a JSON::PullParser and pass it to an instance method named initialize_from_json. This method is very similar to the initialize(pull_parser) we have. Because this method will raise if a property is not found in the JSON source for a required property (a property without a default value, and not nilable), it's totally safe.
The benefit is not having to require JSON::Serializable in every object that needs to be serialized. You could do:
require "json"

record Point, x : Int32, y : Int32

# Works!
Point.from_json(%({"x": 1, "y": 2}))

and it will work right away. Serialization can still be controlled via attributes.
Take for example https://github.com/crystal-lang/crystal/pull/6308 . It's nice, but having to manually include the JSON::Serializable module feels redundant, especially for records and simple types.
Another benefit is that no module is included, which means #6194 won't trigger (for this case).
Yet another benefit is that imagine you define some simple types in your library. If people want to serialize them, they can do it right away, no need to reopen them and include JSON::Serializable in case the author forgot.
The diff to achieve this is very simple, ~except there's a compiler bug that prevents this from working (I can work on that)~ I have it working locally.
I'm pretty sure many will say it might be "dangerous" to allow serialization on every type. I don't find it like that. And given that there's precedent in basically every other language out there, I think it's fine.
Thoughts?

Another thing, right now the compiler complains in this case:
class Foo
  property x : Int32
end

The error is:

instance variable '@x' of Foo was not initialized directly in all of the 'initialize' methods, rendering it nilable

That's cool!
However, once we include JSON::Serializable that error is gone:
require "json"

class Foo
  include JSON::Serializable

  property x : Int32
end

# No error!

The reason is that the include defines an initialize method that makes sure to initialize all instance vars. So there's already an initialize doing that and the ability for the compiler to check that x wasn't initialized is lost. In fact... I just found a bug:
require "json"

class Foo
  include JSON::Serializable

  property x : Int32
end

p Foo.new # => #<Foo:0x104ff0ff0 @x=0>

This happens because of a compiler bug (what a surprise) related to these magic initializers that use @type inside them. There's a rule for making those initialize magically work, bypassing the usual checks. And it seems the checks are lost in other cases. I coded that specifically with JSON::Serializable in mind, and now I regret it because it's a complex thing to check, and it's magical.
By removing that "feature", the only way we can achieve this functionality is the way I propose above. It can be with a JSON::Serializable module or without one (I prefer it without one, less typing and works-out-of-the-box).
Even if we somehow fix the above bug, when we do Foo.new we'll get an error saying no overload matches... there's new(JSON::PullParser). That including JSON::PullParserdefines aninitialize method for you is a bit annoying, because it now participates in overloads too! And because the lookup for initialize methods is a bit different than regular methods (initializeis not inherited unless the child type doesn't define new constructors) we have to do thatmacro included/inherited` hack.
I think this change will simplify things a lot:

The methods are just defined once (from_json, initialize_from_json)
No need to include a module (less typing, and faster compile times and method lookup times (no need to go up the hierarchy to find something)
Doesn't rely on compiler hacks (the @type thing inside macros inside initialize), which we'll be able to remove after this change (well, the way I propose is unsafe, because it uses allocate, but the generated method will raise if any of the required instance vars are not present, making it safe... kind of similar to how Array uses Pointer internally but it's still safe)

Thoughts again? :-)

Ah... and the downside is that if you are defining models for consuming an API, you'll actually have to write a bit more:
require "json"

class SomeModel
  include JSON::Serializable

  property x : Int32
  property y : Int32
end

# Compiles

With the new way:
require "json"

class SomeModel
  property x : Int32
  property y : Int32
end

# Doesn't compile: neither x nor y were initialized in an `initialize`

The way to fix it is to define a constructor:
require "json"

class SomeModel
  property x : Int32
  property y : Int32

  # For example:
  def initialize(*, @x, @y)
  end
end

# Now compiles

If the model has a lot of properties, you might have to write a big constructor... Alternatively, define default values for some properties (if the API is guaranteed to return some properties, giving default values for them is acceptable because you know you'll get correct responses). Anyway, defining a constructor isn't that bad, you can just do def initialize(*, put all required properties here).
So, yeah, in some cases you'll have to write more, you won't have to write include JSON::Serializable but you'll have to write a constructor. But I think this is good, as it makes you think how the class should be initialized outside of JSON. Imagine someone decides to use that class for some reason, maybe in a test, and parsing it from JSON all of the time might not be ideal, so having a constructor is good.

Thinking on a broader scale: JSON/YAML are probably the most important serialization formats. But there are many similar use cases. Should this be the recommended approach for other mappings (XML, Message Pack, DB bindings, etc.) as well? I can't think there would necessarily be any downsides to this. Other than a bunch of methods available on every object, which will often not be really useful unless it's actually supposed to support serialization.

The way serde does it it by describing a "universal data model" then everything just maps to that data model. And then that data model is mapped to JSON or YAML or whatever. I think we should do the same. And Serde requires explicit #[derive(Serializable)] to work, why shouldn't we require explicit includes?

Regarding a constructor hack, maybe a better way to go is to allow a different way of declaring constructors that are not checked by the compiler and that is the programers responsibility to comply with some sound contract. That way there is no hack in the compiler, but a convention.

I don't think serialization should be enabled for all types. I'm ok in adding serialization by default in records for example.

Using the out-of-the-box serialization to avoid triggering #6194 is not worth it IMO.

@bcardiff

I don't like that - self.allocate is the unsafe way of declaring a constructor. We just need to automate adding finalizers so all constructors are always obj = Class.allocate; obj.initialize(*args); obj. Then that becomes API.

I'm thinking that allocate should add the GC finalizer, maybe. Then that problem will be solved.
I think Rust needs a Serializable attribute because they don't have reflection. With reflection you don't need an attribute.
Serde looks nice, but I can't understand how it works. It seems you have to define how a language type maps to a serde type, and then how to serialize that type into the output, and maybe also the other way around. And then you have generic serialization attributes.
If we could go that way, I think it would be awesome. Less repetition if a type is to be serialized into multiple formats.
I wonder how's the efficiency, though. If you have an Array, you have to map it to a serde array? And then serialize that array? Maybe Rust can do that efficiently, I don't think we can, so it will double the number of allocations...
However, I still think that being able to serialize any type without including a specific module would be nice. Again, the reason languages don't support this is because they lack reflection and the power to do it.
Alternatively, if it can be implemented without a compiler hack, that's another solution.

@asterite if you think of it in the JSON::Emitter and JSON::PullParser level - there's no efficiency problem. The "data model" is just a standardized interface to the pull parsers and emitters. So we'd have a Serialization::PullParser module with abstract methods which JSON::PullParser would implement and same for emitters.

@RX14 I still don't understand how you would avoid that indirection and those extra allocations. I guess I'd have to still a proof of concept implementation to understand it :-)
I was wrong about allocate adding the GC finalizer. new invokes allocate, then initialize, then adds the finalizer. But if initialize raises then the finalizer must not be added. So I guess we need a method that does all of that at once, as @bcardiff suggests.

i think include is not that bad, and this in ruby style also, when you extend class with some new behavior by include module to it. Adding it to Object would be more magical.

@asterite because there's no indirection. It's just a set of methods pull parsers and emitters implement.

Then, how about we keep JSON::Serializable but the deserialization doesn't happen through a constructor? That way we don't have to use the {{@type}} hack, which also currently breaks other constructors (as I showed above).

sounds cool, but how it would look like? any example?

@kostya This commit from this branch has it working. As you can see:

the included, inherited and dummy parameter are all gone
I had to fix specs to specify initialize, because now JSON serialization doesn't count as an initializer (and it avoids the bug I mentioned above). I think this is good, but some can find it annoying
new is replaced with from_json. To implement from_json we use allocate and initialize_from_json. It's "unsafe", but so was the old new method.

i think initialize is not big problem because it also can be generated: https://github.com/kostya/auto_initialize?

@kostya Looks good! So simple :-)
Well, everyone (cc @RX14 @straight-shoota @ysbaddaden) let me know if you think this is a good direction (using from_json instead of new), and I can send a PR for JSON and YAML

I'm not sure I like it. I'm not sure why we need to start adding all these fake constructors with this method. I also don't like that it means that any other library using this method now has to generate custom constructors too. So at the very least it should be coupled with a generic multi-format serialization interface. And making serialization implicit is a nono, we should have to include something every time.  People do write custom self.new(PullParser) methods, now either those manually written methods have to be unsafe and write a self.from_json and an initialize_from_json, or they have to write a self.from_json alias for their existing self.new.
And what about default initialized variables such as @foo = "" which were ignored in the parsing? Wouldn't they break with this new method?
And what are we trying to avoid here? Fixing a compiler bug? I don't get it.

So the issue is:

To fix the compiler bug, we need to revert the hacks, and make it impossible for JSON::Serializable to work as it is now.
The only way to make it work is to generate a "fake" constructor manually using self.allocate.

Okay that's fine, but why does the new constructor need to be called self.from_json. Why not self.new and rename the initialize to initialize_from_json just the same? Is there anything special about methods called self.new? I thought there wasn't.

Yes, if a type defines an initialize method, then all initialize and self.new methods are not inherited. So this doesn't compile:
class Foo
  # Let's assume this is the constructor that gets injected in JSON::Serializable
  def self.new(x, y)
  end

  def initialize(x : Int32)
  end
end

class Bar < Foo
  def initialize(x, y, z)
  end
end

Bar.new(1, 2) # This doesn't work

I'm not sure it's the right logic, it's hard because there's new and initialize where in many language there's just new and the constructor is a fixed construct (there's no self.new in other languages). But, well, it's how it works.
I think I'll close this issue... maybe someone will have to fix the compiler issues/hacks regarding this and we'll be fine.

@asterite No, I really can't imagine how a constructor which is also able to inspect all the instance variables using macros could work. I think this should be removed.
I think that manually-defined self.new should be inherited normally, only the autogenerated ones from def initialize  should not be inherited.
Besides, I don't know any other language which inherits global ("static") methods anyway. What's the usecase?

And how can serialization make sense with inheritance anyway. I think it only makes sense for Java and C# to have "magic" serialization and have inheritance because they can always stick null in all of their variables.

@RX14 Java and Python do too... Please, check your facts before posting.

Oh, I thought that java didn't inherit static methods. Never mind then. My bad.

I'm closing this. The state of the art for JSON/YAML looks good so far, even though there are some corner cases. Sorry for the noise.

@asterite maybe wait to have other opinions from e.g @ysbaddaden and @bcardiff, before closing abruptly like you did?

Nah. I opened it, I can close it.

I mean, I'm no longer interested in this happening.

I'm definitely interested in fixing the bug. And I think reverting the compiler patch that made the current JSON::Serializable work and then doing it manually using def initialize_with_json is fine. It's doable now.

Then you should open a separate issue. The original issue was to have from_json/to_json available in all objects. And you are right that initialize_with_json is unsafe, so that shouldn't be done.

I like the idea of taking a step back from an immediate implementation. Let's think about this for some time. The custom annotations feature is quite young (and awesome!), let's experiment with that. We can explore alternate ways to implementing serialization - it couldn't hurt to look more deeply at other implementations. For now, the current way should be fine. I'm pretty sure we'll end up with some changes sooner or later, but time will tell.

@RX14

Maybe we should have just a json_record macro which is literally JSON.mapping but it generates the whole class and force people to use that.

This sounds a bit like Java Beans. Might not a bad idea. But maybe it is. 🤷♂
It's definitely beneficial to question the current (and proposed) approaches and think about new ideas.

Aparte (not exactly this topic) about Rust's Serde: it's "data model" is an API interface to a fixed list of supported data types (29 in total) such as integers, floats, strings, arrays and hashes (but also structs, enums, tuples, ...).
There are 2 traits (interfaces) : Serialize and Deserialize to be implemented. They don't have to allocate more memory than needed, they're just an interface. It's similar to our X::PullParser and X::Emitter, but with a standard interface (e.g. emitter.map instead of json.object or yaml.mapping or ...).
Having a standard interface for (de)serialization would be as wonderful as having a standard interface for IO.

Going back to this topic: Rust's Serde can automatically generate the implementation using an explicit #[derive(Serialize, Deserialize)], similar to include JSON::Serialization but it doesn't have to generate a constructor, because Rust's structs have a global initializer, for example Point(x: i32, y: i32).

Following the forum discussion, I got this basic working draft in this gist, which may or may not be the right approach.
At least, it shows an idea of a possible API.
struct Point
  getter x : Int32
  @[Serialization(key: "YYY")]
  getter y : String

  def initialize(@x, @y)
  end
end

data = %({"x": 1, "YYY": "abc"})

point = Point.from(JSON, data)
puts point # => Point(@x=1, @y="abc")
{YAML, JSON}.each do |type|
  puts point.serialize type
  # => {"x":1,"YYY":"abc"}
  # ---
  # x: 1
  # YYY: abc
end

Or, do we want to go through bytes for serializing, like Go marshaling?
Additional note
Having multiple serialization mechanisms (2 actually) isn't ideal, even less by adding another one.
Having a plan to only keep 1, at most, would be a good to have before 1.0.

I have no idea if it's safe/unsafe on the C-implementation level. But it's really inconvenient to write lots of do; include JSON::Serializable; end statements in the code base. Especially for the data objects.
Example some api, there are like 15 of data objects and for everyone you had to include do; include JSON::Serializable; end. It contributes zero meaning to the code and is just an annoying boilerplate noise.

It contributes zero meaning to the code

That's not true. It explicitly declares these types as being serializable. That certainly does not apply to any type.
Automatically adding serialization methods for all types, including non-serializable types, is questionable at least. It taints the API with methods that are not good to be used.
I understand the record macro is typically used for simple data types that can also be expected to be serializable. So I think we could make types created by record automatically serializable. This was suggested before in this discussion.
Record types themselves should generally be suitable for serialization. But that must also be true for the types of their instance variables, which simply can't be expected in the general case.
Maybe that's still okay, I'm not sure. There will be compile time errors if some types of instance variables are not serializable (although they're might not be very user friendly). Some basic serialization methods are even defined on Object 🤷 (#5695).

macro json_record(*args, **kwargs, &block)
  record({{*args}}, {{**kwargs}}) do
    include JSON::Serializable
    {{block && block.body}}
  end
end

Auto serialize at least bad for security, imagine is someone accidentally store in some object link to internal object(with passwords or something else) for debug purposes. It silently would be serialized, without someone ever noticing it.

@kostya This is an interesting point, but I'm not sure I agree. Configuration data like passwords is very much serializable and often serialization is employed to store such data. There may be some advantage if serialization is only explicitly made available as that could make the developer aware of that. But I don't think that's much relevant. It's really a problem of protecting sensitive data inside the application, not of sensitive data being serializable. There's not much security benefit in my opinion. Every object has #to_s and #inspect and they could already be leaking information if the object is available in an unsafe scope.

@jhass Yes, that's an easy solution. Do you think it should be part of stdlib or a tool for user code?

I wouldn't be 100% against json_record and yaml_record in stdlib, but I also think it's simple enough to include into application code as needed. The latter also gives the potential to tailor it further to the application's domain (support multiple serializations, add some common helper methods etc).

When I code in Haskell it's so tedious to say that such and such type can be mapped to and from json (there are two typeclasses for that in Haskell, ugh).
However, if any object is serializable to json then you can accidentally pass an incorrect object to something that serializes it, and it will compile but it won't work as expected. Of course you should test all code, or as much as possible, but making things as serializable is more type safe than not doing it.

@straight-shoota to_s and inspect known to be unsafe, noone would use it in apis. But serialize should be, you get object from db and serialize it to web.

@kostya I wouldn't be so sure that #to_s is generally considered unsafe. It's used in string interpolation, for example. And serialized data is certainly not necessarily safe to put anywhere. The db object could contain exactly that kind of data you mentioned in your previous comment (confidential credentials for example).

@straight-shoota What @kostya is trying to tell you is that you don't want to unconditionally serialize all fields from the given record - which might come from the db for example - having fields like password, salt, or personally identifiable information (PII)

A fear that some non serialisable object will be serialised, reminds me a talk by DHH. When hi says, about the fear of method re-definition  "but what if programmer re-defines Array.map to shoot the firework?".
What was the last time you saw a serious bug caused by serialising some object that's not designed to be serialised?
The only serious concern is for things like passwords, but as someone mentioned, usually objects containing passwords are serialisable anyway.

I mean such cases:
Imagine some db driver which implemented like this, it store in the class User fields @username, @id and nothing else.
All works ok, tested and serialized as expected.
class User
  include DB::Model
  id : Int32
  username : String
end

get "/users/:id" do |env|
  id = env.params.url["id"].to_i
  user = User.find(id)
  user.to_json # => {"username" => "Vasya", "id" => 10}
end

But after some time driver was refactored, and now store instance variable @connection in the DB::Model, for it internal purposes.
Now users would get {"username" => "Vasya", "id" => 10, "connection" => {"host" => "", "port" => "", "password" => "..."}},
and this is was added silently (test and testers can miss this).

I understand, but such bugs are usually very easy to spot and fix. In JavaScript every object is serialisable to JSON, and there is no issues.

I think the main point here is that a mistake like this is easy to fix, if you have tests or if you run it and see it. The thing with static types is that it can make those guarantees even without a spec or without running it. It doesn't matter if a bug is easy to spot or not. It's more important (or better) to not have the possibility of a bug at all.

And just for the record, I happened to serialize Rails active record models, or some other entities, to JSON thinking they would work out of the box, and the code ran but produced an unexpected result. With Crystal right now that just can't happen.


ORM support

Any plan for adding sqlite orm? something like expo-sqlite-orm maybe.

@pritamsoni-hsr Thanks for looking at the plugin. i look at expo-sqlite-orm to understand the concept of ORM.  I have no plan yet but it is a quite interesting concept.

An ORM would require a lot of work, and they're hard to "finish" (users will report bugs and features no matter how much work goes into it).
If someone wanted to pursue it, I would recommend a separate package (@capacitor-community/sqlite-orm, for example). It could just be a JS library that uses @capacitor-community/sqlite as a driver.

@dwieeb you right, it is a lot of work and i agree it should be a separate package to not add complexity and bugs to the @capacitor-community/sqlite package. Any idea on how to add a capacitor plugin in another capacitor plugin as i think the plugin interface of the called plugin should not go through the bridge so do we have to manage two interfaces for that plugin one going through the bridge for standard use and one call directly for being called by another plugin?

@jepiqueau @dwieeb I don't think we need another capacitor plugin for this, having a serializer and de-serializer package would work.
A rough approach to this could be, we design models and/or queries and orm translates them to sql queries, and the model class would take an extra database argument which is a capacitor/sqlite plugin.

Correct, @capacitor-community/sqlite-orm wouldn't need to be a Capacitor plugin, just a JS layer that builds SQL queries from models and uses the sqlite plugin to actually perform the query. Luckily, I think it may be possible to use an existing JS ORM and build the part that connects the ORM to the driver (e.g. "dialects" for sequelize). Unfortunately, according to this issue, I'm not sure it's possible with sequelize, so we may need to investigate alternative ORMs.

i think using typeorm would make the most sense here. there are also similar plugins for cordova-sqlite and others that can be taken as a start.
Together with multiple database support (https://github.com/capacitor-community/sqlite/issues/1) this would make this plugin useful in many more use cases.

I downvoted this suggestion as there is a real risk of it being a huge time sink and will distract @jepiqueau from the core functionality of the plugin.
Let's keep this plugin lean and focused, and avoid bloat.
Also, ORM in itself is controversial, so I hope the idea will be rejected.
@jepiqueau: if you didn't know ORM before and what it does, please discard the request and don't look back.

Thanks for your clear advise. I agree that it will be a big work to refactor the plug-in and I have not take any decision yet as for the time I know that the plug-in is working as it is and requires a good maintenance and cleaning. It is also requiring demonstrating apps in different frameworks which is my current plan I have already Ionic/Angular, Ionic/React, React and I will come soon with Ionic/Vue and Vue Hope this clarify.

@accron-1 I agree that this should not be the responsibility of @jepiqueau, as he is responsible for the plugin only, drivers for orm can be for other members of the community, including me, of course. However, I do not believe that rejecting the request is the best. I believe we can move it to other discussions or maybe bring it to the typeorm itself, because the typeorm drivers are included in their repository
but definitely, that shouldn't be @jepiqueau responsibility

@danielprrazevedo If adding ORM support didn't require any additional work from @jepiqueau there wouldn't be a request here, you'd simply use his existing code/plugin as-is. So clearly this request does expect him to do some work in some shape or form.
The core function of this plugin is to provide cross platform access to Sqlite. It doesn't say anything about ORM, nor would I expect it to. ORM tries to solve problems which are unrelated to the purpose of this plugin (and it solves them poorly, many would argue, or at the expense of other metrics, e.g. performance, simplicity, etc...).
This plugin is very appreciated by many users, and much needed. A stable and bug free plugin will require continuous maintenance and updates by @jepiqueau, as the platforms (Android/iOS/Electron) and the different frameworks (Ionic Angular/React/Vue) evolve. We don't need code that introduce complexity, bloat, or worse, bugs. Adding ORM increases the surface area and potentially means more code that needs to be adequately maintained.
So let's not distract him with completely unrelated features, so that we have an awesome plugin that works great not only today, but also next year, and beyond.
Given the above, I hope the request is rejected.

@accron-1  I agree, we can add typeorm with some effort, this issue was more of a question to @jepiqueau and I agree it'll bring more complexity and bugs, add bloatware.

@pritamsoni-hsr,  @dwieeb ,  @noerw , @danielprrazevedo,  i am currently working on a refactor of the @capacitor-community/sqlite plugin in view of exposing it through a connection to the database, multiple database connection, ...
this should easy the way to create a driver to typeorm.
An alpha version for Android  is now available including some of the basic sqlite methods  https://github.com/capacitor-community/sqlite/tree/refactor. could be installed with npm i --save @capacitor-community/sqlite@refactor So if one of the community member wants to write the driver to typeorm and/ or to spatialite he will be welcome. I am concentrating myself on the refactor.

@jepiqueau i can have a look into the typeorm driver as soon as https://github.com/capacitor-community/sqlite/issues/1 is finalised

@chriswep This will be very nice if you can do it. You can even start quickly as the Android refactor is ready, only missing the json import/export. The iOS refactor will be there soon again without the json import/export so the interfaces  ISQLiteConnection and ISQLiteDBConnection will not really change now . I will only add a getExistingConnection(database:string) in ISQLiteConnection to retrieve an existing connection which will allow to use  a db connection created in one page of the app and using it in another page.

i'm not getting to this the next days anyway. maybe you have some basic documentation ready at some point? that would help getting started quickly.

@chriswep Ok fine, the documentation is there already
API_Documentation
API_Connection_Wrapper_Documentation
API_DB_Connection_Wrapper_Documentation

@chriswep sorry i close it by mistake

Now that the refactor release is launched, it would be easy for one to develop the typeorm driver  when required. I will not develop it myself so i close that issue

Now that the refactor release is launched, it would be easy for one to develop the typeorm driver  when required. I will not develop it myself so i close that issue

i just created a PR for the driver on the TypeORM repo: https://github.com/typeorm/typeorm/pull/7695
@jepiqueau you might want to mention it somewhere in the docs/README when it's released.

@chriswep For sure i will do, thanks for your contribution in making the sqlite plugin stronger and for providing the typeorm  driver. Tell me when it is released i will mention it in the README. Would be nice if you could have also a link to an or several examples. The best will be that you create a PR with a TypeORM-Usage.md in the docs which i can refer to in the README Documentation/API chapter. What do you think about it?

@chriswep I saw the PR  for the driver on the TypeORM repo has been merged.  Will you write a TypeORM-Usage.md so i can refer to it in the REAGME.md of the sqlite plugin?

done @jepiqueau

@chriswep I am currently travelling for the next 3 weeks with not really a viable Internet connection and I have also few issues that I want to solve. This PR will be merge to be part of the release 3. If I found a Internet connection I will merge it to be part of release 3.0.0-rc.2


[DOCS] Include types of attributes in widget documentation

The documentation generator for widget documentation should include the type of the property, such that it's more obvious which values can be used there. A short explaination of the fact that all of them have to be in quotes should be added to the top of the widget documentation.

@gilmirmo has taken on this issue. Poggers!

yes I'll do it

He'll, in fact, not do it 😄

Ill do it :sweat_smile:

This should be done now by #148

Yes, fixed in #148 ! Thanks!


Decide on an API

Decide between the MAL API or the Mangadex API for the pulling of all the series

Using the MAL API for the project


Ping url

Schedule ping url (optionally pass parameters)

v2 now supports a new then method to execute a callback after a job execution.
That method provides enough flexibility to implement a custom ping functionality.


0.15-0.16-rc Version of the problem

0.15-0.16 - rc version to execute commands run - android system CARDS maxed out, hope the official will give solution

Hey @qiepei123 . Thanks for the issue. But I didn't quite get what you said. Can you explain a bit?

@satya164 There is a red page after I upgrade the react native version to 0.16.0-rc.
Upon opening the app, the red page appears.
![Image of error]
(http://postimg.org/image/wfb42hddj/)

Cannot see the image. Can you re-upload?

@qiepei123 Any news?


check disease association slim

from
https://github.com/pombase/website/issues/989
check which disease genes don't slim, to see if we need to improve

covered by https://github.com/pombase/website/issues/1108
This will be a curation task. Will be able to evaluate once
https://github.com/pombase/website/issues/1108 done


mypy update

Describe the bug
a mypy update has changed their defaults and we need to update the code to match
Run mypy --show-error-codes --disable-error-code misc --disable-error-code import tableauserverclient test
##[debug]/usr/bin/bash -e /home/runner/work/_temp/a3351e84-6b1d-47fb-801e-82f612a2819f.sh
tableauserverclient/server/endpoint/exceptions.py:36: error: Incompatible default for argument "request_url" (default has type "None", argument has type "str")  [assignment]
tableauserverclient/server/endpoint/exceptions.py:36: note: PEP 484 prohibits implicit Optional. Accordingly, mypy has changed its default to no_implicit_optional=True
tableauserverclient/server/endpoint/exceptions.py:36: note: Use https://github.com/hauntsaninja/no_implicit_optional to automatically upgrade your codebase
tableauserverclient/models/revision_item.py:13: note: By default the bodies of untyped functions are not checked, consider using --check-untyped-defs  [annotation-unchecked]

In a recent PR I had to force mypy to use its previous behavior:
https://github.com/tableau/server-client-python/pull/1158/commits/a42515162f16c84b58f99c05f2f0d6eb484f7dfc
We can leave this issue open to cover fixing it the right way if we want.

This was addressed in 0bb9dd5d2bdaf4adbca9427deb26c9469e961d9b


Yarn and placeholder arguments

It's currently working fine, but when using the placeholder for arguments with yarn, you get the following warning:
My scripts:
  "scripts": {
    // [...]
    "bundle:client": "ng build --prod --progress=true --named-chunks=true",
    "bundle:server": "ng build --prod --app 1 --output-hashing=false --progress=true --named-chunks=true",
    "webpack:server": "webpack --config webpack.server.config.js --progress --colors",
    "build:ssr": "run-s \"bundle:** -- {1}\" webpack:server --",
    "start:ssr": "node dist/server",
    // [...]
  },

Yarn warning:
$ yarn build:ssr --env=dev
warning From Yarn 1.0 onwards, scripts don't require "--" for options to be forwarded. In a future version, any explicit "--" will be forwarded as-is to the scripts.

It might become a problem in the next versions to come.
If I don't use the --, as you don't need them in yarn, npm-run-all won't pass the arguments.

Hi here,
I confirm, I got this issue when using the latest versions of Yarn since the v1.
There are no way to pass arguments to the task now from the terminal.
For now, we still have to use these arguments in scripts and wrap them with the script between ' or ".
Here an example:
"scripts": {
    "clean": "rm -rf build/*",
    "commons:build": "yarn webpack build",
    "lint:js": "eslint '{src,test}/**/*.{js,jsx}'",
    "build": "npm-run-all --serial clean lint:js 'commons:build --production'"
}

Run yarn build will correctly end with yarn webpack build --production. But there is no way to do it directly using the command yarn build --production even if I use the -- before (I will get an error for invalid arguments from npm-run-all).

Its very unfortunate yarn has decided to diverge on behavior here.

Made my own yall-scripts tool specifically to address this. It's yarn-friendly, lightweight and does the job.

A partial workaround for this is to run-s in package.json in this manner:
{
 "scripts: {
    "start": "npx run-s \"commandA {@}\" \"commandB {@}\" --"
  }
}

Then start command can be executed with both yarn and npm, but it will use npm (not yarn) to run commandA and commandB scripts.

A partial workaround for this is to run-s in package.json in this manner:
{
 "scripts: {
    "start": "npx run-s \"commandA {@}\" \"commandB {@}\" --"
  }
}

Then start command can be executed with both yarn and npm, but it will use npm (not yarn) to run commandA and commandB scripts.

Yup, works for me with yarn 1.22.19 on linux:
I want to run
yarn start --port 8234 --cors

And my scripts are:
    "start": "run-s build 'serve {@}' --",
    "serve": "npx http-server bundles",

The trailing -- in the start script is key. Also, single quotes work fine instead of double quotes.


Java Container build fails on download

docker/javaruntime/docker-build.ps1 Calls Download.ps1.  it failed with the below. I suspect it is because of the requirement to login and accept the terms.
At C:\Users\colemans\Desktop\Docker\javaruntime\Download.ps1:7 char:5
+     throw ('Expected to retrieve only one URI but got {0}' -f $JreUri ...
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (Expected to ret...e URI but got 0:String) [], RuntimeException
    + FullyQualifiedErrorId : Expected to retrieve only one URI but got 0

I forgot to change the Version to 8u172.. It works fine


fix(controller): fixed client init and CR update

runtime client is now created using client.New() instead of from the manager. update on the disk/device CR now takes the latest resource version and updates the resource
Signed-off-by: Akhil Mohan<EMAIL_ADDRESS>

Codecov Report

Merging #234 into master will decrease coverage by 0.04%.
The diff coverage is 90.9%.

@@            Coverage Diff             @@
##           master     #234      +/-   ##
==========================================
- Coverage   51.48%   51.44%   -0.05%
==========================================
  Files          49       49
  Lines        2259     2255       -4
==========================================
- Hits         1163     1160       -3
+ Misses       1007     1006       -1
  Partials       89       89

Impacted Files
Coverage Δ

cmd/ndm_daemonset/controller/controller.go
15.55% <0%> (ø)
:arrow_up:

cmd/ndm_daemonset/controller/devicestore.go
85.45% <100%> (ø)
:arrow_up:

cmd/ndm_daemonset/controller/diskstore.go
89.52% <100%> (ø)
:arrow_up:

...md/ndm_daemonset/controller/sparsefilegenerator.go
65.85% <0%> (-0.42%)
:arrow_down:

cmd/ndm_daemonset/probe/udevprobe.go
63.24% <0%> (-0.09%)
:arrow_down:

Continue to review full report at Codecov.

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

In operator-sdk, controller-runtime's client is used for cluster interaction. By default SDK relies on manager.Manager to create a client.Client. But this client reads from the cache and writes to the API server, thus reducing read load on the API server. But this has issues that information regarding resource may not be updated in the cache. Due to this issue, the disk CR was not updated in the cache and when we try to Get() the resource it returned an error. In such cases, we can write a custom client using client.New(), which serves all requests from the API server.


Deprecate V1 modules

Description
When a V1 module is loaded, show a deprecation message saying that the use of V1 modules has been deprecated.
closes #4941
Self Check:

[x] Attached issue to pull request
[x] Changelog entry
[x] Type annotations are present
[x] Code is clear and sufficiently documented
[x] No (preventable) type errors (check using make mypy or make mypy-diff)
[x] Sufficient test cases (reproduces the bug/tests the requested feature)
[x] Correct, in line with design
[x] End user documentation is included or an issue is created for end-user documentation

Reviewer Checklist:

[ ] Sufficient test cases (reproduces the bug/tests the requested feature)
[ ] Code is clear and sufficiently documented
[ ] Correct, in line with design

Processing this pull request

Merged into branches master in b4fc737b4ca6c4330b1318226eb3abf5cfbcde45

Processing #5021.


Synthesis failed for nodejs-logging

Hello! Autosynth couldn't regenerate nodejs-logging. :broken_heart:
Please investigate and fix this issue within 5 business days.  While it remains broken,
this library cannot be updated with changes to the nodejs-logging API, and the library grows
stale.
See https://github.com/googleapis/synthtool/blob/master/autosynth/TroubleShooting.md
for trouble shooting tips.
Here's the output from running synth.py:
109d25e006628"
DEBUG: Call stack for the definition of repository 'com_googleapis_gapic_generator_go' which is a http_archive (rule definition at /home/kbuilder/.cache/bazel/_bazel_kbuilder/a732f932c2cbeb7e37e1543f189a2a73/external/bazel_tools/tools/build_defs/repo/http.bzl:296:16):
 - <builtin>
 - /home/kbuilder/.cache/synthtool/googleapis/WORKSPACE:301:1
Loading: 0 packages loaded
INFO: SHA256 (https://github.com/googleapis/gapic-generator-php/archive/v0.0.7.zip) = d79599f900a598d0c212554a07b0f7db97b8b144b3e8fa4323a1da3795eca16f
Loading: 0 packages loaded
DEBUG: Rule 'gapic_generator_php' indicated that a canonical reproducible form can be obtained by modifying arguments sha256 = "d79599f900a598d0c212554a07b0f7db97b8b144b3e8fa4323a1da3795eca16f"
DEBUG: Call stack for the definition of repository 'gapic_generator_php' which is a http_archive (rule definition at /home/kbuilder/.cache/bazel/_bazel_kbuilder/a732f932c2cbeb7e37e1543f189a2a73/external/bazel_tools/tools/build_defs/repo/http.bzl:296:16):
 - <builtin>
 - /home/kbuilder/.cache/synthtool/googleapis/WORKSPACE:365:1
INFO: SHA256 (https://github.com/googleapis/gapic-generator-csharp/archive/4304b1ae8684d28c92458155cd2d39e2eedc4ac7.zip) = 4db430cfb9293e4521ec8e8138f8095faf035d8e752cf332d227710d749939eb
DEBUG: Rule 'gapic_generator_csharp' indicated that a canonical reproducible form can be obtained by modifying arguments sha256 = "4db430cfb9293e4521ec8e8138f8095faf035d8e752cf332d227710d749939eb"
DEBUG: Call stack for the definition of repository 'gapic_generator_csharp' which is a http_archive (rule definition at /home/kbuilder/.cache/bazel/_bazel_kbuilder/a732f932c2cbeb7e37e1543f189a2a73/external/bazel_tools/tools/build_defs/repo/http.bzl:296:16):
 - <builtin>
 - /home/kbuilder/.cache/synthtool/googleapis/WORKSPACE:387:1
Loading: 0 packages loaded
INFO: SHA256 (https://github.com/googleapis/gapic-generator-ruby/archive/cc272f0905e45950873e04d3cd8df77a63f215ca.zip) = a14ec475388542f2ea70d16d75579065758acc4b99fdd6d59463d54e1a9e4499
DEBUG: Rule 'gapic_generator_ruby' indicated that a canonical reproducible form can be obtained by modifying arguments sha256 = "a14ec475388542f2ea70d16d75579065758acc4b99fdd6d59463d54e1a9e4499"
DEBUG: Call stack for the definition of repository 'gapic_generator_ruby' which is a http_archive (rule definition at /home/kbuilder/.cache/bazel/_bazel_kbuilder/a732f932c2cbeb7e37e1543f189a2a73/external/bazel_tools/tools/build_defs/repo/http.bzl:296:16):
 - <builtin>
 - /home/kbuilder/.cache/synthtool/googleapis/WORKSPACE:401:1
DEBUG: /home/kbuilder/.cache/bazel/_bazel_kbuilder/a732f932c2cbeb7e37e1543f189a2a73/external/rules_python/python/pip.bzl:61:5: DEPRECATED: the pip_repositories rule has been replaced with pip_install, please see rules_python 0.1 release notes
INFO: SHA256 (https://github.com/bazelbuild/bazel-skylib/releases/download/0.9.0/bazel_skylib-0.9.0.tar.gz) = 1dde365491125a3db70731e25658dfdd3bc5dbdfd11b840b3e987ecf043c7ca0
DEBUG: Rule 'bazel_skylib' indicated that a canonical reproducible form can be obtained by modifying arguments sha256 = "1dde365491125a3db70731e25658dfdd3bc5dbdfd11b840b3e987ecf043c7ca0"
DEBUG: Call stack for the definition of repository 'bazel_skylib' which is a http_archive (rule definition at /home/kbuilder/.cache/bazel/_bazel_kbuilder/a732f932c2cbeb7e37e1543f189a2a73/external/bazel_tools/tools/build_defs/repo/http.bzl:296:16):
 - <builtin>
 - /home/kbuilder/.cache/synthtool/googleapis/WORKSPACE:35:1
Analyzing: target //google/logging/v2:logging-v2-nodejs (1 packages loaded, 0 targets configured)
Analyzing: target //google/logging/v2:logging-v2-nodejs (15 packages loaded, 38 targets configured)
Analyzing: target //google/logging/v2:logging-v2-nodejs (15 packages loaded, 38 targets configured)
Analyzing: target //google/logging/v2:logging-v2-nodejs (16 packages loaded, 38 targets configured)
Analyzing: target //google/logging/v2:logging-v2-nodejs (22 packages loaded, 152 targets configured)
INFO: Call stack for the definition of repository 'zlib' which is a http_archive (rule definition at /home/kbuilder/.cache/bazel/_bazel_kbuilder/a732f932c2cbeb7e37e1543f189a2a73/external/bazel_tools/tools/build_defs/repo/http.bzl:296:16):
 - <builtin>
 - /home/kbuilder/.cache/bazel/_bazel_kbuilder/a732f932c2cbeb7e37e1543f189a2a73/external/com_google_protobuf/protobuf_deps.bzl:19:9
 - /home/kbuilder/.cache/synthtool/googleapis/WORKSPACE:57:1
WARNING: Download from https://github.com/madler/zlib/archive/v1.2.11.tar.gz failed: class com.google.devtools.build.lib.bazel.repository.downloader.UnrecoverableHttpException GET returned 502 Bad Gateway
ERROR: An error occurred during the fetch of repository 'zlib':
   java.io.IOException: Error downloading [https://github.com/madler/zlib/archive/v1.2.11.tar.gz] to /home/kbuilder/.cache/bazel/_bazel_kbuilder/a732f932c2cbeb7e37e1543f189a2a73/external/zlib/v1.2.11.tar.gz: GET returned 502 Bad Gateway
ERROR: /home/kbuilder/.cache/bazel/_bazel_kbuilder/a732f932c2cbeb7e37e1543f189a2a73/external/com_google_protobuf/BUILD:210:1: @com_google_protobuf//:protobuf depends on @zlib//:zlib in repository @zlib which failed to fetch. no such package '@zlib//': java.io.IOException: Error downloading [https://github.com/madler/zlib/archive/v1.2.11.tar.gz] to /home/kbuilder/.cache/bazel/_bazel_kbuilder/a732f932c2cbeb7e37e1543f189a2a73/external/zlib/v1.2.11.tar.gz: GET returned 502 Bad Gateway
ERROR: Analysis of target '//google/logging/v2:logging-v2-nodejs' failed; build aborted: no such package '@zlib//': java.io.IOException: Error downloading [https://github.com/madler/zlib/archive/v1.2.11.tar.gz] to /home/kbuilder/.cache/bazel/_bazel_kbuilder/a732f932c2cbeb7e37e1543f189a2a73/external/zlib/v1.2.11.tar.gz: GET returned 502 Bad Gateway
INFO: Elapsed time: 41.881s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (24 packages loaded, 252 targets configured)
FAILED: Build did NOT complete successfully (24 packages loaded, 252 targets configured)

Traceback (most recent call last):
  File "/home/kbuilder/.pyenv/versions/3.6.9/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/kbuilder/.pyenv/versions/3.6.9/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/tmpfs/src/github/synthtool/synthtool/__main__.py", line 102, in <module>
    main()
  File "/tmpfs/src/github/synthtool/env/lib/python3.6/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/tmpfs/src/github/synthtool/env/lib/python3.6/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/tmpfs/src/github/synthtool/env/lib/python3.6/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/tmpfs/src/github/synthtool/env/lib/python3.6/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/tmpfs/src/github/synthtool/synthtool/__main__.py", line 94, in main
    spec.loader.exec_module(synth_module)  # type: ignore
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/home/kbuilder/.cache/synthtool/nodejs-logging/synth.py", line 30, in <module>
    v2_library = gapic.node_library("logging", version, proto_path=f'google/logging/{version}')
  File "/tmpfs/src/github/synthtool/synthtool/gcp/gapic_bazel.py", line 58, in node_library
    return self._generate_code(service, version, "nodejs", False, **kwargs)
  File "/tmpfs/src/github/synthtool/synthtool/gcp/gapic_bazel.py", line 204, in _generate_code
    shell.run(bazel_run_args)
  File "/tmpfs/src/github/synthtool/synthtool/shell.py", line 39, in run
    raise exc
  File "/tmpfs/src/github/synthtool/synthtool/shell.py", line 33, in run
    encoding="utf-8",
  File "/home/kbuilder/.pyenv/versions/3.6.9/lib/python3.6/subprocess.py", line 438, in run
    output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['bazel', '--max_idle_secs=240', 'build', '//google/logging/v2:logging-v2-nodejs']' returned non-zero exit status 1.
2021-04-14 04:38:30,806 autosynth [ERROR] > Synthesis failed
2021-04-14 04:38:30,807 autosynth [DEBUG] > Running: git reset --hard HEAD
HEAD is now at 485347f fix(deps): remove dependency on through2 (#1023)
2021-04-14 04:38:30,813 autosynth [DEBUG] > Running: git checkout autosynth
Switched to branch 'autosynth'
2021-04-14 04:38:30,949 autosynth [DEBUG] > Running: git clean -fdx
Removing __pycache__/
Traceback (most recent call last):
  File "/home/kbuilder/.pyenv/versions/3.6.9/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/kbuilder/.pyenv/versions/3.6.9/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/tmpfs/src/github/synthtool/autosynth/synth.py", line 356, in <module>
    main()
  File "/tmpfs/src/github/synthtool/autosynth/synth.py", line 191, in main
    return _inner_main(temp_dir)
  File "/tmpfs/src/github/synthtool/autosynth/synth.py", line 336, in _inner_main
    commit_count = synthesize_loop(x, multiple_prs, change_pusher, synthesizer)
  File "/tmpfs/src/github/synthtool/autosynth/synth.py", line 68, in synthesize_loop
    has_changes = toolbox.synthesize_version_in_new_branch(synthesizer, youngest)
  File "/tmpfs/src/github/synthtool/autosynth/synth_toolbox.py", line 259, in synthesize_version_in_new_branch
    synthesizer.synthesize(synth_log_path, self.environ)
  File "/tmpfs/src/github/synthtool/autosynth/synthesizer.py", line 120, in synthesize
    synth_proc.check_returncode()  # Raise an exception.
  File "/home/kbuilder/.pyenv/versions/3.6.9/lib/python3.6/subprocess.py", line 389, in check_returncode
    self.stderr)
subprocess.CalledProcessError: Command '['/tmpfs/src/github/synthtool/env/bin/python3', '-m', 'synthtool', '--metadata', 'synth.metadata', 'synth.py', '--']' returned non-zero exit status 1.

Google internal developers can see the full log here.

Autosynth passed, closing! :green_heart:


SOLR-17140 - 9x backport

https://issues.apache.org/jira/browse/SOLR-17140

The above tidy/spotless check does not reproduce locally for me. Neither running gradlew spotlessApply nor running gradlew tidy tasks produce changes. The offending file is not changed in this change list and does not have this flaw on my local machine or in the branch I am merging? https://github.com/gus-asf/solr/blob/SOLR-17140_9x/solr/core/src/test/org/apache/solr/cloud/SolrCloudExampleTest.java#L44  ... seems to be seeing this: https://github.com/apache/solr/commit/9b9f56970b695f64769fd5dc277d3ca66819c034 which apparently broke things. sigh Would be nice if this PR interface identified that commits had happened, even if they don't interfere with the merge. Also @epugh maybe following a PR process when back-porting would have caught this without breaking others?

I cannot reproduce either, strange. Maybe open a new JIRA for that precommit failure and proceed with this one?

I am working on unmessing up branch_9x with post tool..  Sigh....


[C++][Parquet] Support pkg-config

Reporter: Kouhei Sutou / @kou
Note: This issue was originally created as PARQUET-928. Please see the migration documentation for further details.

Wes McKinney / @wesm:
Issue resolved by pull request 278
https://github.com/apache/parquet-cpp/pull/278


NOTICE: upcoming default branch name change

The master branch of this repository will soon be renamed from master to main, as part of a coordinated change across the USGS-R and USGS-VIZLAB organizations.  This is part of a broader effort across the git community to use more inclusive language. For instance, git, GitHub, and GitLab have all changed or are in the process of changing their default branch name.
We will make this change early in the week of February 6, 2022. The purpose of this issue is to give notification of the change and provide information on how to make it go smoothly.
When this change is made, forks and clones of the repository will need to be updated as well. Here are instructions for making the necessary changes.

[ ] On GitHub, change the default branch name from master to main (<your repository> -> Settings -> Branches).
[ ] Change the default branch on any forks you have, as well as local clones. (See details below)
[ ] If you have collaborators on this repository, let them know that they will need to change their forked/local repos. Point them to this issue to facilitate the process!
[ ] Search within your repository for "master" so that you can change references (e.g. URLs pointing to specific commit points of files) to point to "main" instead.
[ ] When you are done, feel free to close this issue!

Changing default branches on forks and local clones
First, update your local git configuration so that new repositories created locally will have the correct default branch: git config --global init.defaultBranch main.
Now, for any forks, do the following:

Go to <your fork> -> Settings -> Branches and edit the default branch from master to main.
Update the settings for your local clone of this fork to match this change.

git branch -m master main
git fetch origin
git branch -u origin/main main
git remote set-head origin -a

This repository has now been converted, and its default branch is now main instead of master. Please see above for instructions on how to adjust any forks and/or clones you have.
@cmitR, @jzwart, @limnoliver, @mbucknell, @AHeadman-USGS, @ldecicco-USGS, @mwernimont, @wdwatkins, @lindsayplatt, @lawinslow, @appling, @aappling-usgs, @jiwalker-usgs, @jread-usgs, please note that you have forks of this repository!


[Docs] Instructions added to run Meshery-Istio in local enviroment

Signed-off-by: Piyush Singariya<EMAIL_ADDRESS>Description
There isn't any information added for new contributors in the docs about running an instance of Meshery-Adapter locally to avoid errors related to Adapters.
The solution for such errors is to run an instance of Meshery-Adapter i.e. Meshery-Istio in the local environment. The current changes guide the newcomers to run meshery-istio locally.
This PR fixes #2464

Thank you for this update, @piyushsingariya!


Java load python trained mode by SavedModelBundle predict wrong result

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow):
No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04):
14.04
TensorFlow installed from (source or binary):
binary
TensorFlow version (use command below):
1.3/1.2.1
Python version:
2.7
Bazel version (if compiling from source):
CUDA/cuDNN version:
GPU model and memory:
Exact command to reproduce:

Describe the problem
I trained a simple model using python and save it with SavedModelBuilder. Then I loaded it using java. it's loaded successfully but predict wrong result.
Source code / logs
My python code is in
https://gist.github.com/fancyerii/af10e8cc35ffda4c983c6e9cf074b317
and java code https://gist.github.com/fancyerii/c1096f9f8c9bd9705da1b1c7d6ca2138

This question is better asked on  StackOverflow since it is not a  bug or feature request. There is also a larger community that reads questions there. Thanks!
(Though, from the gist of your Python code, I can see one problem - you're invoking tf.global_variables_initializer().run() inside the save_model function, which means that you're changing the weights to their initial (as opposed to trained) value before saving the model. As a result, the saved model doesn't have the trained weights so your predictions will be wrong)

I have the same issue.
fancyerii, did you solved this problem?
My python code is in
https://github.com/joyspark/TensorFlow/blob/master/simpleRegression.py
and java code
https://github.com/joyspark/TensorFlow/blob/master/loadPythonModel.java

@joyspark @fancyerii hi, have you resolved the problem? the SavedModelBundle document is so blurred... I  even cannot load the saved model successfully using SavedModelBundle.load() in java.

@gypleon : Feel free to file a new issue if you're having trouble loading the saved model - though do include a short example to reproduce the problem.
Haven't heard back from @fancyerii , but there was certainly a problem wherein the model was being exported with random weights, not the trained weights. Not sure about @joyspark 's issue


Large Memory Usage

I have a very large PDF (about 1000  pages).  Since I didn't think it would be wise to load the entire PDF into memory at the same time, I decided to iterate over the pages, calling pdf.load on each page individually thinking this would only load one page in at a time.  However, it seems that memory usage continues to grow every time pdf.load is called, like the previous data is not being released.  Any ideas?  I'm running out of memory (16GB) after about 400 pages.

load doesn't throw away previous results if you call it multiple times. If you do:
pdf = PDFQuery("example.pdf")
pdf.load(1)
pdf.load(2)

then you have both pages 1 and 2 loaded, and memory will increase. Meanwhile this should hopefully have flat memory use and perform almost as quickly:
pdf = PDFQuery("example.pdf")
pdf.load(1)
pdf = PDFQuery("example.pdf")
pdf.load(2)

If memory use increases with the second example, feel free to reopen.


Inconsistency by matching on UInt8.t

The complete coverage check when pattern matching on UInt8.t is completely bogus and allows one to prove false:
let f (i:FStar.UInt8.t) = if i = 0x00uy then 0x00uy else 0x01uy

let bad_lemma (i:FStar.UInt8.t) : Lemma (f i = 0x00uy) =
  match i with
  | 0x00uy -> assert_norm (f 0x00uy = 0x00uy)

let contra() : Lemma False =
  assert_norm (f 0x01uy = 0x01uy);
  bad_lemma 0x01uy

I think this is quite likely the same issue as the first part of #1535. UInt8.t has a single constructor, so that optimization might kick in but of course it's bogus since there is a subpattern. I can look in the afternoon.

For what it's worth, the following fails as expected:
type box (a:Type) = | C : a -> box a

let f (b:box int) : int = if b = (C 0) then 0 else 1

let bad_lemma (b:box int) : Lemma (f b = 0) =
  match b with
  | C 0 -> assert_norm (f (C 0) = 0)

Patterns are incomplete

The other thing that worries me is that Uint8.t is abstract type, so matching on its representation is shady anyway.

Indeed, the problem is a bit different. The culprit is this if:
https://github.com/FStarLang/FStar/blob/338a9fb5b8f64fc9f1edd90038d9e86ad383112c/src/typechecker/FStar.TypeChecker.TcTerm.fs#L2176-L2180
The pattern in this case, given the special desugaring for UInt8.t, is __uint_to_t 0. Which is not a data constructor. This should be rejected instead of succeeding happily without a guard. Trying a regression build with that.

For example as is done in the Tm_constant case above (after checking that args are all constants).

Or better, treat __uint_to_t n as a constant, it's special in the compiler anyway.

Please add plenty of negative tests to regression...

I don't know what's best, honestly. Should we even match on these integers? FWIW I removed the if not (Env.is_datacon .. and kept only the else branch in each case, and CI passes (branch guido_1572). This example fails then with (Error) Name "FStar.UInt8.__uint_to_t" not found

My thinking is: these are integer constants, so, from a user perspective it is fine to match on them ... just like it is fine to match on int or nat.
The compiler is treating these constants specially by desugaring them as __uint_to_t n. So, in this piece of code, we could treat them just like other constants.
On the other hand, any time we are returning [ ] from this code, it seems dangerous for the pattern exhaustiveness check. So may be @nikswamy can add some comments in this code so that we can convince ourselves that the remaining cases are ok. I don't know the original idea behind those.

I think I understand the code a little bit now. The top-level pattern is not supposed to be a Tm_app unless it is application of a data constructor (e.g. it would not even parse). It is this desugaring of machine integers that breaks the invariant.

Thta's right, and what really bothers me is that the parser seems to be a part of the TCB by enforcing this. I would expect that this should fail (by default) and hten maybe we have some special handling to uint_to_t above that.

I think it is ok to allow these terms for a dot pattern. So, may be this function needs to track that all these Tm_app nodes etc. (essentially all the cases when we are returning []) are when we are (recursively) inside a dot pattern.

Which would fail this example -- and then we should add special handling for __uint_to_t by treating it similar to Tm_const.

My understanding is that the code is incorrectly assuming that all non data-constructor applications in the expression corresponding to the pattern (pat_exp) are implicit arguments filled in by unification (I.e., "dot patterns"). This assumption is broken by the __uint_to_t introduced when desugaring machine-integer constants that appear in patterns.
The status of machine integers is a bit odd. On the one hand, they are defined in the libraries as abstract types modeled using mathematical integers. But, they have primitive syntax and primitive desugaring. We even elide trivial bounds checks on machine integer constants (e.g., v (0 uy) < 256 etc.) since these are enforced in ToSyntax.
One possible way to see it is that the machine integer types and their constants are built in to the language, but they have no operations aside from those provided by the FStar.[U]Int[N] libraries. But the line is pretty blurry.
In any case, I'm with @aseemr in that I think we should retain pattern matching on machine integer constants since these constants are already primitive in the language. This stle is pretty common already in many programs so it would be hard to remove.
Treating the occurrence of ___uint_to_t in pat_exp in the same way as Tm_constant sounds reasonable.
We could also be more defensive and check that when we encounter on non-data or variable sub-term in pat_exp then this really corresponds to an inaccessible sub-term (i.e., a dot pattern) in the orignial patttern. I think this is also one of Aseem's suggestions.
Finally, I'm surprised @mtzguido  that just removing the Env.is_datacon check worked. I guess it's just adding more guards, some of them possibly redundant, e.g., things like proj_0 (Mktuple3 #int #_ _ _ ) = int etc.

FYI, my status: I have a patch in nik_1572 that seems to mostly work. I have a failure in StreamAE.fst-ver (in TLSConstants.fst) which I need to investigate further.

The proof in TLSConstants seems to be failing because of an unrelated context pollution issue in miTLS. Trying to resolve that separately now.

Fixed and merged in master.

That said, if @aseemr and/or @mtzguido want to have a look at my diff in nik_1572 and comment on it, that would be most welcome.


MAINT - Update release docs and add issue template

Fixes #585

Description

This pull request:

Updates the release docs
Adds a release issue template

Pull request checklist

[ ] Did you test this change locally?
[x] Did you update the documentation (if required)?
[ ] Did you add/update relevant tests for this change (if required)?

Additional information

@trallard - Thanks for this PR! Currently, the release issue template is an empty file - did you mean to move over the checklist from the release process documentation?

@pavithraes  of course I forgot to push the last commit 🤦🏽♀  sorted now