Bad ranking because of the .TOP domain? (SEO)

The password generator at passwordgenerator.top seem to have bad ranking with Google (and maybe other search engines). As the result of it, the organic traffic to this project is very low. It's required to clarify if the TLD .top affects it. The background is that on most of the .top TLDs primarily spam sites are hosted.
The task is to find out (among SEO community) if it's really the case or are there any other reasons for the bad ranking / low traffic?
If this suspicion is confirmed, then we'll need to move to a different TLD.
Some background info about .top domains: https://www.tamrazyan.com/what-is-top-dot-top-domain/

It might be because of very little text on the front page. Added some description to the front page, let's see if it will affect the ranking somehow.


Delegate email validation format to more_core_extensions

Replaces the regex we've defined in app/models/user.rb with that in
more_core_extensions.
This breaks one of the existing tests that provides curly braces as
invalid characters. These, even though unlikely, are valid, so the test
was updated to use an unquoted comma as an example of an invalid
character.
Addresses https://github.com/ManageIQ/manageiq/issues/12781 (in part)
Note: I intend to follow this up with some more PRs to:

separate specs which test that it validates properly formatted email address with those that specify what kinds of things are valid/invalid and move the latter into more_core_extensions
update the regex in more_core_extensions to be more permissive WRT length of the TLD, which is unbounded before this change and limited to 6 after UPDATE: see https://github.com/ManageIQ/more_core_extensions/pull/31 (EDIT by @Fryguy: Merged!)

Thank you @chessbyte for the suggestion and @Fryguy for further suggestions!
@miq-bot add-label core, refactoring
@miq-bot assign @Fryguy

Marked as euwe/yes as this technically fixes a bug.

BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1412251


CSS color - delete redundant challenge

Pre-Submission Checklist

[x] Your pull request targets the staging branch of freeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm test. Use git commit --amend to amend any fixes.

Type of Change

[x] Small bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds new functionality)
[x] Breaking change (fix or feature that would change existing functionality)
[ ] Add new translation (feature adding new translations)

Checklist:

[x] Tested changes locally.
[x] Closes currently open issue (replace XXXX with an issue no): Closes #13463

Description

Removed the challenge "Adjust the Color of an Anchor Tag" as color has already been introduced in another challenge. Modified the next challenge accordingly.
Closes #13463

Tested locally and LGTM. Keep 'em coming @Manish-Giri 👍 💯 🌮 🦅


Add timeout or browser verification when using -interactive

When running Get-AzToken with the -Interactive switch, if no login is performed and the browser window is closed, the command seems to hang.
Steps to reproduce
Make sure no active sessions are available
Run
Get-AzToken -Interactive

Close the opened browser window without logging in.
Expected behaviour
If possible, I would prefer the command to either simply stop, or return an error (no account logged on or similar, something we can catch in a catch block)
If not, at least a timeout of n+1 seconds before throwing an error to prevent pipelines from hanging.

It doesn't seem like there's a built-in timeout function, but I'll add a way to configure it using the provided cancellationtoken to the method. Thanks for the report!


Added Logically Weighted Regression

Have you read the Contributing Guidelines on Pull Requests?
YES
Description
I have implemented a Logically Weighted Regression Model on a given dataset contained in a .csv file.
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
#2000

@shraddhavp i have added the program. Kindly let me know if any changes are required. Thank you

@shraddhavp i have added the program. Kindly let me know if any changes are required. Thank you

Hi @infiniteoverflow
Thanks for making this PR. Please make these changes:

Add a line at the End of the File
Remove  .DS_Store from the Commits
Use dashes or underscores in Logically Weighted Regression
Remove the Dataset and add a Kaggle/G-Drive Link instead

Hi @infiniteoverflow
Thanks for making this PR. Please make these changes:

Add a line at the End of the File
Remove  .DS_Store from the Commits
Use dashes or underscores in Logically Weighted Regression
Remove the Dataset and add a Kaggle/G-Drive Link instead

thank you @HarshCasper  , I have made changes accordingly.

thank you @HarshCasper  , I have made changes accordingly.

@HarshCasper I have updated the files as per the requirements. Kindly have a look.
The .DS_STORE file in my commits is not present in my repo , it is pointing the same file in the parent repo.

@HarshCasper I have updated the files as per the requirements. Kindly have a look.
The .DS_STORE file in my commits is not present in my repo , it is pointing the same file in the parent repo.

@HarshCasper Can you please add the DWOC and Level label for this issue #2000

@HarshCasper Can you please add the DWOC and Level label for this issue #2000


Sensu client should provide an HTTP input on 3031

The Sensu client should provide an HTTP input on port 3031. The input should essentially be an HTTP API, beginning with endpoints that implement the functionality of the current client TCP socket, e.g. accept external check results. The Sensu client HTTP input should use em-http-server, the same library used by the Sensu API.
This proposal is an alternative to https://github.com/sensu/sensu/pull/1352
Expected Behavior
HTTP 3031 POST /results
HTTP 3031 GET /info
Future endpoints:
HTTP 3031 BASIC AUTH GET /settings
Current Behavior
The Sensu client currently provides a TCP socket on port 3030, responding to "ping", and accepting JSON check results.
Examples:
echo ping | nc localhost 3030
pong

echo '{"name": "test", "output": "WARNING", "status": 1}' | nc localhost 3030
ok

I've taken a stab at implementing this on PR #1488

Merged into release/0.27


Have links and references to GetEnvoy.io on EnvoyProxy.io

Also, update dates on getenvoy.io blog posts.

@liamawhite open a PR to https://github.com/envoyproxy/envoy/tree/master/docs/root/start/distro too?


Render artifacts on linux

As of 1d84a5f52 master game screen start to stutter after some time or window switch.

Probably some double buffering bug, because seems like it is handled poorly now (GetGLWidget()->swapBuffers(); can be called twice).

@kremius, I wrote you email about this, earlier.

@Lourens-Rich It is better to link exact commit then you talk about a specific build version, because it is unclear that do you mean by "this". 30% CPU does not sounds bad, so probably you imply that before the load was less. In that case it will be helpful to provide the previous CPU load too.

Temporally in 0.4 - I have an idea how to fix it quickly. If the idea will not work out then the issue will be postponed.

@Lourens-Rich if you have similar problems, please report version of qt, drivers and xorg you have installed.

I use Arch Linux. Xorg: 1.19.1 Qt: 5.8 (I saw this problem on 5.7 too.)

@mechmind @Lourens-Rich
Can you test changes? There might be a possibility that the issue was fixed.

Now after changing window focus, game looks and plays very smooth. But sometimes pipes under floors was flick.

Seems like everything is fixed on @mechmind machine.
Anyway there will be more changes in OpenGL in the future.


Misleading record.whenReady and record.isReady

Versions:

npm: @deepstream/client v4.0.5
docker: deepstreamio/deepstream.io:latest

In this test the hello-world record contains a simple object: {hello: 'world'}. The test file:
const deepstream = require('@deepstream/client');
const client = deepstream('ws://localhost:6020');

client.login();

const record = client.record.getRecord('hello-world');

record.whenReady(() => {
  console.log('event: whenReady', `ready: ${record.isReady}`, JSON.stringify(record.get()));
});

record.subscribe(() => {
  console.log('event: subscribe', `ready: ${record.isReady}`, JSON.stringify(record.get()));
});

What I expected to see in my console is the following:
event: subscribe ready: false {}
event: whenReady ready: true {"hello": "world"}
event: subscribe ready: true {"hello": "world"}

But what I get is this:

The first log shows that record.isReady is true when it's clearly not. The second log is triggered by whenReady but as you can see the document is still empty so it's not actually ready. The third log is a total mystery why it happens because nothing has changed since the first subscribe event. Only in the fourth log the record contains all the data from the server.
Question: How do I know when the record is truly ready?

Wrong repository...


Add Circle CI 2.0 config

Closes #244
Signed-off-by: Michael Lavers<EMAIL_ADDRESS>

@pselle This also fixes a few bugs that were found:

Fixes a Python 2.7 compatibility issue with ThreadPoolExecutor arguments
Fixes system reads, reads as binary instead of text
Fixes prematurely closing a IO stream in logging plugin


[Keyboard Navigation - Makecode - Microbit Controls] Focus indicator is not visible on the tree View of Microbit Menu controls.

User Experience
If Focus indicator is not visible on the tree view of the menu controls then the user with visual disabilities might be confuse where the focus is on the screen.
Test Environment
OS: RS2 Version 1703(OS Build 15063.2)
Platform: Edge.
Tool: Color contrast Analyzer
Repro Steps
1-Navigate to https://makecode.microbit.org/acc
2-Navigate to the Micro bit section element and select Code control given on it.
3-Navigate to menu controls and verify the issue.
Actual Result
Focus indicator is not visible on the tree View of Micro bit Menu controls.
Expected Result
Focus indicator should be visible on the tree View of Micro bit Menu controls.
MAS Reference
https://microsoft.sharepoint.com/teams/msenable/Documents/LCA/MAS - July 1, 2017 Release/MAS 2.4.7 – Focus Visible .docx?d=w3b98b04f4fab4d3e81afa0906a34849c&csf=1
Suggested fix
1.Using user interface components that are highlighted by the user agent when they receive focus
2.Using CSS to change the presentation of a user interface component when it receives focus
3.Using the default focus indicator for the platform so that high visibility default focus indicators will carry ov
4.Using an author-supplied, highly visible focus indicator
5.Using script to change the background color or border of the element with focus
#div a:hover, #div a:active, #div a:focus {
  background-color: #DCFFFF;
  color:#000066;
}
To provide an outline around the element we can use the below
a { outline: none; }
Refer Attachment
MAS 2.4.7_Makecode_Focus indicator is not visible.zip

This is part of Blocky, a third-part component.

We have got exception for Blockly bugs from Julia Liuson (CVP). Closing these as Won't Fix. Following is the reasoning.

MakeCode can be used in either Text editor or Block editor.
Blocks editor is inherently visual and is based on google blockly. Usage requires drag and drop functionality and we don’t have a equivalence in MakeCode for this w.r.t accessibility.
We have evaluated couple of research projects which tries to find a equivalence to block based coding for accessibility needs:
•	Project Torino (Requires students to buy physical blocks)
•	Accessible blockly (This is text based coding without syntax errors)
Both these are drastic departure from the blockly and provides a complete new experience. These are still in research and we intend not to use them in MakeCode at this point of time.
As workaround, the text editor in MakeCode is the way we see students with the need of accessibility using MakeCode.


Support handling of transient faults

Add a capability of dealing with transient network outages via the following retry policy:

Let the client code define a maximum amount of retry attempts, preferably via the DeliveryClientConfig class.
If not specified in the config, the retry policy should be disabled by default.
If specified, the Delivery client should retry in exponential retry intervals.
The interval, in milliseconds, is always calculated as a power of the number 2. The exponent is the ordinal number of the next attempt. The result is then multiplied by 100. The order is one-based. For instance, the first retry attempt interval equals to (22 * 100), the second equals to (23 * 100), etc.
When all retry attempts fail, the SDK should notify the client code about it, preferable via an exception.

Released in v2.5.3

Retry functionality is now enabled by default and set to 3 attempts.

excellent, thanks @Enngage


Add flash message to logout dialog

Add flash message to logout dialog

@daftspunk Wouldn't it would be a better idea to throw the usual ApplicationExceptions and give the developer the freedom to use Flash API or any other kind of alerts on the front end side? I feel it would give a greater level of flexibility to the programmer. For example, I replace the default JS alerts in my web apps with sweet alert so even ApplicationExceptions turn up pretty.

Sorry I delete repository fork by mistake... I will create new one.


Mutually Exclusive

Use this issue to discuss the mutually exclusive component in the ONS Design System

When an option is toggled on or off programatically, a change event should be fired so that any JavaScript listening to change events on the options is notified of the change.

As discussed with @will-madebymoon, we should remove the mutually exclusive select option, as this functionality can be achieved with a standard select.

Mutually exclusive does not work when there is no legend supplied for checkboxes, e.g. when wrapping the field in a question component.

Since updating fields to use p tags (#417) the mutually exclusive checkbox has broken:

When used within a question component, the mutually exclusive checkbox is not the correct width

The layout of mutually exclusive is still broken but only on singular "input-type" inputs like the currency input

Theres not enough space between the textarea character count and the mutually exclusive option:

The mutually exclusive tests aren't clearing their templates after each test which could pollute other tests.

Can't add custom attributes to a mutually exclusive checkbox


Change font of audio notches to default font

I use code font bigger than the editor font.
I also increased the width of audio bus to not cut the text Add Effect.
before -> after

Ready to merge. I was thinking in implement other things but I'll do it in another PR.

Thanks!


rust inlay_hints render bug

system: macOS 13.1
neovim: NVIM v0.8.2

same problem
rust-analyzer version: 2023-01-02

// code snippet
#[derive(Debug)]
enum Color {
Black,
Blue,
Brown,
Custom(String),
Gray,
Green,
Purple,
Red,
White,
Yellow,
}
#[derive(Debug)]
struct ShoesColor(Color);
impl ShoesColor {
fn new(c: Color) -> Self {
Self(c)
}
}
#[derive(Debug)]
struct ShirtColor(Color);
impl ShirtColor {
fn new(c: Color) -> Self {
Self(c)
}
}
#[derive(Debug)]
struct PantsColor(Color);
impl PantsColor {
fn new(c: Color) -> Self {
Self(c)
}
}
fn print_clothe_color(c : Color) {
println!("{:?}", c)
}
fn main() {
let shoes = ShoesColor::new(Color::Red);  // <- edit on this line after will trigger this bug
}

Duplicate of #300

I'll second that the #307 PR fixes the problem.

thanks

@FrankReh I have replaced the plugin in my config with the fork from kdarkhan and it works good for me :)


Document Development Guidelines

Cesar (@cbrzn) created this document walking through some things: https://docs.google.com/document/d/1M09dmkP5j5dubb4vtM8WMWxoO8JMEaE1-IHYZ83fWUc/edit

Add notes about "how codeownership works"


KeyDiscoveryConvention shouldn't try to create a key on a property on which a non-unique fk is defined

This is really hard to hit so not a priority


Allow different window assigners / time windows in WindowGraphAggregation

Fixes #2 (mostly). I did not try tuple-based windowing, I don't think flink itself can do it very efficiently. Tumbling and Sliding windows both work well.

Hi @drfloob,
thank you for the PR. I don't quite understand what is the intention here. Issue #2 refers to supporting the streaming sliding window model or tumbling window model, i.e. apply computations on a stream of graph snapshots as these are created by a sliding or tumbling window.
Regarding the window graph aggregation, this is intentionally implemented using a tumbling window internally, as this makes partial state merging more efficient. I don't see why someone would do single-pass connected components with a sliding window to merge state. Was there something else you had in mind that I'm missing here?

@vasia thanks, I'm fairly new to flink, maybe there is a simpler way to accomplish what I'm after? I am computing connected component over a sliding window without aggregation -- emitting the connected components that exist in each window. The Connected Components example was (apparently) tightly coupled with the WindowGraphAggregation class, so I found modifying it to be the shortest path to a working solution. Can it be done another way?
Cheers,
-aj

Issue #2 refers to supporting the streaming sliding window model or tumbling window model, i.e. apply computations on a stream of graph snapshots as these are created by a sliding or tumbling window.

To clarify, I taught WindowGraphAggregation how to do this (with any arbitrary window assigner). See the included test case, it uses sliding windows.

Thank you for the explanation @drfloob. The Connected Components example is indeed tightly coupled to the WindowGraphAggregation class. In fact, the idea is to showcase window graph aggregation usage. I think the way to go in your case would be to create a new example or even a new abstraction to expose the contents of a sliding window as a graph snapshot. This way it would be more general than aggregation and would allow us to do any kind of operation on the window contents. What do you think?

@vasia That makes a lot of sense, it seems there's no need for this PR. I'm not sure how to build this more general abstraction at the moment, I'll need to get more familiar with the project. Do you already have an architecture in mind, or any suggestions as to where this new abstraction would live?
Also, if I understand correctly, I believe the changes we're talking about would fix #2: enabling computation over snapshots from arbitrary windowing models. Is that right? If not, there's still some subtlety in #2 that I don't understand.

Hi @drfloob,
it could be as simple as slice(), e.g. a slidingSlice() method on the GraphStream and wrappers for UDFs. The abstraction could look like GraphWindowStream which now only works with tumbling. alternatively, we could actually generalize slice() and GraphWindowStream to work for both.
#2 is an old issue and doesn't really provide helpful information. If you'd like to work on this, maybe it's a good idea to open a new issue and we can discuss details there.

I've added another example as a unit test, along with a WindowConnectedComponents library class that better showcases the specific use case. It spares quite a bit of redundant code compared to the alternative.


Adding the Polyglot Solutions section

Hi @mekoda, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;


Remote xbee sensor

Hi, can we connect remote xbee sensor (wall router), that is not connect to xbee sensor that is connect to PC (via USB), via this xbee-api library and obtain data from the remote xbee sensor?

This library's purpose is to create and parse 802.15.4/ZigBee/ZNet API frames. These frames might be read from/written to xbee devices connected to a PC through a USB/serial connection - but even the serial connection logic is not part of this module.
If you have problems with device compatibility, try the digi support forums: https://www.digi.com/support/forum/).
This library will also not simplify network configuration for you - i.e. if you can't make the devices talk to each other using the first party tools such as XCTU  (because of incompatibility or lack of understanding of the protocols), this library won't help you either. Again, if you need help with configuring your network, try the digi support forums.
Good luck!

I don't have problems with devices compatibility, configuration or anything like that.
I just want to connect my remote sensors to node-red, in order to obtain data (temperature etc.) from them for my node-red app.

Sorry if I sound snarky, but googling for "node-red xbee", gives you this: https://github.com/ramonmata/node-red-contrib-xbee - did try that?
Please make an effort on your own before asking for help. If you don't have an issue in particular, it is hard to help you. At least read the README's first, and provide all information in your original post right away.

Of course i try everything i found in node-red library, but every library example (like node-red-contrib-xbee) is looking for serial port, but the remote wireless sensors doesn't have one. So i can't connect them.

You can't just connect to xbee devices without also connecting an xbee node to your PC.
If that's what you are doing, and your issue is that the xbee doesn't show up as a serial port, please ask on the digi forums for help.
As I wrote before, and as stated in the README, this library also needs to use a serial port to do the actual communication with xbee devices.

I wanted to connect remote xbee devices to the xbee node that is physically (serial port) connect to
PC or RPI, and obtain sensor data from the remote one (i know how to connect them with XCTU, but i want to use them with node-red, in order to create my app), but it seems like there is no such node-red library, correct?
The closest option is this one, but it's not exactly what I need.
https://flows.nodered.org/node/ncd-red-wireless

As long as I know, officially there are only Arduino, C, C++, Java, Python libraries to talk to the XBee.
and yes you need a serial port (or SPI) locally to your PC

@MartinSokolov15
If you have an xbee on your local machine and have set up the remote xbee with a node ID (or have its serial number which doubles as its address) then you should be able to use the remote AT command to work with the remote xbee, including reading from sensors or setting up polling sensor packets from the module.
I have made a library that connects to a local xbee called xbee-rx based on xbee-api.  I have an example script to send a remote AT command here that I have used myself to send a command to an xbee elsewhere in my house from an xbee connected to my computer.  Another script I was using to get regular temperature sensor readings remotely is here.


failed in extent pool

I created a capacity pool with:
CU = 1, SU = 1, duration unit = Day and Time to live = 1

it's created with this resource:
CU = 86400 and SU = 86400
after that i try to extend this pool with:
CU = 1, SU = 2, duration unit = Day and Time to live = 2

calculate cu and su after extent should be:
calculated_cu = (1 + 1) * 2 * 60 * 60 * 24 = 345600
calculated_su = (2 + 1) * 2 * 60 * 60 * 24 = 518400
but i get:
CU = 259200
SU = 432000
pool ID: 7000

your calculation is incorrect
extension should be
cu = (1 * 1 * 60 * 60 * 24) + (2 * 1 * 60 * 60 * 24)
su = (1 * 1 * 60 * 60 * 24) + (2 * 2 * 60 * 60 * 24)


Error when Starting Bot! [NOOB]

Hi Everyone!
Im new to Javascript, and i need some help here :)
So i (almost) copied the Example.js beacuse i wanted to try it out :)
But when i start my bot it gives me this Error ;(
Thanks :)
ERROR:
/home/ubuntu/workspace/node_modules/steam/node_modules/steam-crypto/index.js:6
  var cryptedSessionKey = crypto.publicEncrypt(publicKey, sessionKey);
                                 ^
TypeError: Object #<Object> has no method 'publicEncrypt'
    at Object.exports.generateSessionKey (/home/ubuntu/workspace/node_modules/steam/node_modules/steam-crypto/index.js:6:34)
    at SteamClient.handlers.(anonymous function) (/home/ubuntu/workspace/node_modules/steam/lib/steam_client.js:226:44)
    at SteamClient._netMsgReceived (/home/ubuntu/workspace/node_modules/steam/lib/steam_client.js:167:26)
    at Connection.emit (events.js:95:17)
    at Connection._readPacket (/home/ubuntu/workspace/node_modules/steam/lib/connection.js:50:8)
    at Connection.emit (events.js:92:17)
    at emitReadable_ (_stream_readable.js:427:10)
    at emitReadable (_stream_readable.js:423:5)
    at readableAddChunk (_stream_readable.js:166:9)
    at Connection.Readable.push (_stream_readable.js:128:10)

**MY CODE: **
var SteamTradeOffers = require("steam-tradeoffers");
var Steam = require('steam');

var steamClient = new Steam.SteamClient();
var steamUser = new Steam.SteamUser(steamClient);
var steamFriends = new Steam.SteamFriends(steamClient);

steamClient.connect();
steamClient.on('connected', function() {
  steamUser.logOn({
    account_name: 'USERNAME',
    password: 'PASSWORD'
  });
});

steamClient.on('logOnResponse', function(logonResp) {
  if (logonResp.eresult == Steam.EResult.OK) {
    console.log('Logged in!');
    steamFriends.setPersonaState(Steam.EPersonaState.Online);
  }
});

From README:

Note: only Node.js v0.12 and io.js v2.x are supported.


slip_models.pkl

I'm sorry to interrupt, I didn't quite understand how files like slip_models.pkl are generated.

Hi! Thank you for your question. In our implementation, create_data.py is a script that creates terrain maps, including their associated colors and heights, as well as latent slip models assigned to each terrain class. The SlipModelsGenerator class plays this role either by randomly generating latent slip models or loading generated slip models. You can try to run the script to see how all the files are generated. If there are any questions, please let me know!

Ok, thanks for the answer, I was the one who didn't look at the code carefully, I thought it just generated the map.


Anime Information Inbuilt browser.

Describe your suggested feature
The feature I'm requesting it should be work with the tracker if some-one logged into Anilist or myanimelist account they have an Inbuilt browser(Not necessary) in both anime and manga section, anime for anime section and Manga for manga section, Because anilist and myanimelist both provides anime and manga info, so it's use to watch anime when the anime have many seasons or ova etc...
Thanks! If you give a thought on that.
Other details

Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] If this is an issue with an extension, I should be opening an issue in the extensions repository.
[X] I have updated the app to version <IP_ADDRESS>.
[X] I will fill out all of the requested information in this form.

Sorry, I didn't understand, what you are suggesting. Can you elaborate?

Sorry, I didn't understand, what you are suggesting. Can you elaborate?

as far as I understood suggestion is to add webview or something of anilist and mal in both anime and manga section so it could be checked how many seasons or ovas it got including other information.

Sorry, I didn't understand, what you are suggesting. Can you elaborate?

as far as I understood suggestion is to add webview or something of anilist and mal in both anime and manga section so it could be checked how many seasons or ovas it got including other information.

That's not necessary, because u already can access this info, with the tracking section.
Just click at the (f. Example) MAL icon, and the info will be opened.

Sorry, I didn't understand, what you are suggesting. Can you elaborate?

as far as I understood suggestion is to add webview or something of anilist and mal in both anime and manga section so it could be checked how many seasons or ovas it got including other information.

That's not necessary, because u already can access this info, with the tracking section.
Just click at the (f. Example) MAL icon, and the info will be opened.

yup just track, click on 3 dots and press open in browser.
@NewbieAnimeManga if this fulfills your issue then you can close it or you may need to give more details about what you actually want here.

Ok! lemme make it more easy just like you said click on three dots and open in webview it kinda hassle to users.. so we need some kinda shortcuts to see information/details about anime/manga when we open the anime/manga.

Sorry, I didn't understand, what you are suggesting. Can you elaborate?

as far as I understood suggestion is to add webview or something of anilist and mal in both anime and manga section so it could be checked how many seasons or ovas it got including other information.

That's not necessary, because u already can access this info, with the tracking section.
Just click at the (f. Example) MAL icon, and the info will be opened.

yup just track, click on 3 dots and press open in browser. @NewbieAnimeManga if this fulfills your issue then you can close it or you may need to give more details about what you actually want here.

It will be Quite helpful. If you Directly add this feature on Aniyomi!

your suggestion likely won't work unless u track it, and I'm not so sure if someone would need that much "quick access" to information page. regardless of it you'll still need to pick which tracker's webview you want to see. so after all this effort you'll still save only 1 click. I don't see how it could be that useful at this point.
still you can ask for "open in webview" instead of "open in browser"
but again if you have default link set up for mal and anilist apps (if you have them) it'll open directly in their apps. which could be better than using webview.

there is an UNOFFICIAL Anilist extension thet you can use if you want
it can't play videos tho

also if a feature affects the manga section you should suggest it to Tachiyomi.

Link please?
Anime one
Manga one

Link please?

Anime one Manga one

Thanks so now I'm closing this issue okay!


As a user, I can find important items on the board by using the customisable "Quick Filters" above >> Try clicking the "Only My Issues" Quick Filter above

Creating Quick Filters
You can add your own Quick Filters in the board configuration (select Board > Configure)

➤ James McLean commented:
Joined Sample Sprint 2 1 days 4 hours 10 minutes ago


chore: Convert features views APITestCase and TestCase to a normal test function

Thanks for submitting a PR! Please check the boxes below:

[x] I have run pre-commit to check linting
[x] I have added information to docs/ if required so people know about the feature!
[x] I have filled in the "Changes" section below?
[x] I have filled in the "How did you test this code" section below?
[x] I have used a Conventional Commit title for this Pull Request

Changes
I'm working through re-writing the TestCase and APITestCase classes into normal test functions. I rewrote the existing classes and replaced with fixtures instead of recreating everything. There are other PRs that are similar to this one.
How did you test this code?
I manually changed the tests one at a time to refactor them as I went then ran the full test suite afterwards.

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

Project coverage is 95.86%. Comparing base (7451032) to head (bfb088a).
Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3822      +/-   ##
==========================================
- Coverage   95.93%   95.86%   -0.08%
==========================================
  Files        1103     1103
  Lines       34842    34797      -45
==========================================
- Hits        33427    33357      -70
- Misses       1415     1440      +25

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


Can I run LigandMPNN on my Windows Laptop?

I followed the installation instructions but when I try to run:
py run.py --seed 111 --pdb_path "./inputs/1BC8.pdb" --out_folder "./outputs/default"
I get the following error message:
PS C:\LigandMPNN> py run.py --seed 111 --pdb_path "./inputs/1BC8.pdb" --out_folder "./outputs/default"
Traceback (most recent call last):
File "C:\LigandMPNN\run.py", line 24, in
from sc_utils import Packer, pack_side_chains
File "C:\LigandMPNN\sc_utils.py", line 17, in
from openfold.data.data_transforms import atom37_to_torsion_angles, make_atom14_masks
File "C:\LigandMPNN\openfold\data\data_transforms.py", line 24, in
from openfold.np import residue_constants as rc
File "C:\LigandMPNN\openfold\np_init_.py", line 11, in
modules = [(m, importlib.import_module("." + m, name)) for m in all]
File "C:\LigandMPNN\openfold\np_init.py", line 11, in
modules = [(m, importlib.import_module("." + m, name)) for m in all]
File "C:\Users\EmilyRobertsKang\AppData\Local\Programs\Python\Python310\lib\importlib_init.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "C:\LigandMPNN\openfold\np\protein.py", line 23, in
from openfold.np import residue_constants
File "C:\LigandMPNN\openfold\np\residue_constants.py", line 24, in
import tree
ModuleNotFoundError: No module named 'tree'
No version of pip installing tree seems to work. Openfold only has installation instructions for Linux, does this mean I can't run Openfold and/or LigandMPNN on my Windows Laptop (Windows 11 Pro operating system)?

does this mean I can't run Openfold and/or LigandMPNN on my Windows Laptop

LigandMPNN works well on Windows, OpenFold does not.🙃 https://github.com/dauparas/LigandMPNN/pull/16

Try using the requirements.txt file to make conda env


Shortcut to open recently closed script/scene

Godot version:
3.1
Issue description:
When you close a script/scene, there's no way to restore the tab quickly. You need to manually open the file. There should be a shortcut to open recently closed scripts/scenes like you can do e.g. in web browsers. There's one for recently opened, but it only works when you open something, not when you load a project with already opened stuff.
Steps to reproduce:

Accidentally close something :(

Something like Undo Close Tab above Close Tab when right clicking on a scene/script tab (similar to most web browsers) could be a good fit.

Generally it would be nice to know what can be undone and cannot be undone. https://github.com/godotengine/godot/issues/25919
If we had a proper project undo log, maybe it would also make sense to have two proper undo logs, one for any project related action (changing, adding or removal of components, code assets ect) and one for all editor related actions (positioning https://github.com/godotengine/godot/issues/25920 and sizing of panels, opening and closing of panels, scripts, scenes, ect)

Sorry, but reopening :/
This issue was about scripts too, not only scenes.


M564 Axis Limit --> dropped tools

I forgot to add M564 S0 to my tfreeX.g macros.
TAMV finished with the tool, moved as far as the axis limit (in config.g) would allow. And unlocked the tool.
Not TAMV's fault, but probably worth noting.
https://reprap.org/wiki/G-code#M564:_Limit_axes

Thanks for bringing this up. It definitely warrants a note in the instructions, once I have the final updated version ready, complete with a proper walkthrough of how to set up!
And you're right, this is a machine-dependent macro thing, but worth noting for sure.


Current app does not run

Describe the bug
A clear and concise description of what the bug is.

This happens in pvnet_app = 2.3.21 but not in 2.3.20
Expected behavior
Work with no errors
Additional context
We upgraded torch, and pytorch lightning version in this release

This is odd, because the CI test do not catch this but, but only when run in docker

Tests are run with python3.12 and docker is 3.10, I will try to upgrade and see if it helps

Could try rolling back torch upgrades, or perhpas look at hydra versions

Althought hydra seems like the same version in each

It might be that there's a mistake in a different package, should be m=4

Difference between 2.3.20 and 2.3.11
old
Cartopy-0.23.0
PVNet-summation-0.3.0
PyYAML-6.0.1
geopandas-1.0.1
huggingface-hub-0.20.3
nowcasting_datamodel-1.5.45
numpy-1.26.4
ocf_datapipes-3.3.35
pvnet-3.0.47
pyogrio-0.9.0
pytorch-lightning-2.1.3
new
Cartopy-0.23.0
PVNet-summation-0.3.0
PyYAML-6.0.1
geopandas-1.0.1
huggingface-hub-0.20.3
nowcasting_datamodel-1.5.45
numpy-1.26.4
ocf_datapipes-3.3.35
pvnet-3.0.47
pyogrio-0.9.0
pytorch-lightning-2.1.3

for n in new:
...     if n not in old:
...             print(n)
...
artopy-0.23.0
PVNet-summation-0.3.2
beautifulsoup4-4.12.3
bs4-0.0.2
fiona-1.9.6
geopandas-0.14.4
huggingface-hub-0.24.1
nowcasting_datamodel-1.5.52
numpy-2.0.0
ocf_datapipes-3.3.39
pillow-10.4.0
pvlive-api-1.3.0
pvnet-3.0.50
pytorch-lightning-2.3.3
pyyaml-6.0.1
soupsieve-2.5
torchvision-0.19.0

when running docker locally, i cant import import pvnet.models.multimodal.multimodal as i get a torchvision error

COuld try wrapping this in a try and except - https://github.com/openclimatefix/PVNet/blob/main/pvnet/models/multimodal/multimodal_base.py#L3, so that the import works

Ok - this is due to a torch vision import error - https://github.com/openclimatefix/pvnet_app/actions/runs/10157687269

This is solved in 2.3.23 #114


What is the purpose of this project?

As per your description, this project is the same as electron-updater except it features improved differential update support.
So why did you decide to create a separate project to add these features as opposed to making PRs to add these features directly to electron-builder repository?

@JonathanLydall - the whole purpose for separating the project is to support the differential update feature on mac for .zip format. We do not want to complicate the electron-updater with this feature for mac.

I feel it's unfortunate you've decided to take the decision to copy the source repo for the following reasons:

By not using GitHub's fork feature, it's no longer possible to use standard Git tools to see what changes are in your repository compared to the electron-builder repository.
Similarly to the above point, I see it being difficult for you to integrate upstream changes into your own repo, meaning that improvements to the upstream repo are unlikely to be added to yours.

So I feel it's to risky for me to use your project because it has a high risk of becoming incompatible with the upstream project which (at least for the moment) has a lot more momentum behind it.
So I feel said you didn't opt to try PR your features into the upstream repo as a lot of people in my position would have then felt comfortable using your work.

@JonathanLydall - in future we can fork the electron-builder repo and move the functionalities there..

@JonathanLydall - in future we can fork the electron-builder repo and move the functionalities there..


fix: merge modifiers by name

As mentioned on Spectrum, the new data structure allows for this and should be done by default I think. It's not too large and handles custom modifiers.
Modifiers later in the array override earlier modifiers in the array. It also deep-merges data and options objects, but not their values. Expected behavior? Will it break existing merge setups?

Filename
Size
Change

dist/umd/popper-base.min.js
1.8 kB
+29 B (1%)

dist/umd/popper-lite.min.js
2.86 kB
+38 B (1%)

dist/umd/popper.min.js
5.29 kB
+4 B (0%)

compressed-size-action


0 out sequence values when termination occurs before nsteps is over

https://github.com/oxwhirl/treeqn/issues/3

Thanks for looking into this :)


CAMEL-19327: camel-jpa support singleResult option

Description
A common use case is that a query (or a find) should return exactly one object, and any other result is to be considered an error. camel-sql supports thehttps://issues.apache.org/jira/browse/CAMEL-19327# outputType=SelectOne option which will cause the component to throw an exception if the query does not return a single row. camel-jpa does not have such an option and thus user must manually check for body size.
This PR addresses that. It adds a boolean option singleResult, which, if set to true:

in case of a query will cause the component to put the single fetched object into the message body, not in a List, or throw an exception otherwise
in case of a find, if no object is found the component will throw an exception rather than put null into the body

it has no effect on updates, and doesn't alter the consumer.

Target

[x] I checked that the commit is targeting the correct branch (note that Camel 3 uses camel-3.x, whereas Camel 4 uses the main branch)

Tracking

[x] If this is a large change, bug fix, or code improvement, I checked there is a JIRA issue filed for the change (usually before you start working on it).

Apache Camel coding standards and style

[x] I checked that each commit in the pull request has a meaningful subject line and body.

[x] I formatted the code using mvn -Pformat,fastinstall install && mvn -Psourcecheck

Thanks we then need to cherry-pick to main as well


Simplecov not merging in Sinatra app

I have a Sinatra app with RSpec and Cucumber running tests. If I set SimpleCov.use_merging false, the tests will run and a report will be created but only for the last type of tests run. If I do not use that option, then the tests never finish and no report is created. No other output is given on the console.

Closing due to lack of response. Feel free to reopen and add more info.


Chart Legend (Point Color)

Hi Beto,
Good day, I'm trying to build a line graph without the line just the points. When I tried to show the legend, I see no point (shape) in it, just the title. So I tried to investigate and found out that the color and stroke of the shape in the legend are actually the color of the fill property and the thickness of the line stroke.

Will it be much better if we bind the color to the PointForeground property and not the fill?
What do you think?
Thank you very much.
Regards,
Billy Joel

Hello Billy
You are right, this was wrong, last commit should fix it, but I will keep this issue open because, in this cases where you don't need a line, it is not recommended to use LineSeries the algorithm of a lin series is much more complex than BubbleSeries but the current implementation of BubbleSeries seems not enough to support this (custom points shapes)
So I will keep this issue open to remind me to fix:

Rename BubbleSeries to ScatterSeries, this will help users to understand that this series is more useful than what it seems, BubbleSeries draws points according to X,Y and weight, the size of every point scales according the weight of the point, but if you only pass X, Y coordinates all points will take the same size, I need to explain this better.
Add support to custom Point shapes to this series.

Yeah, I was thinking of the same thing but failed to mention it.
Renaming it to ScatterSeries will be a great idea.... :)
Thank you very much Beto for the reply... I'm loving this control more each day... :)
Regards,
Billy Joel

This should be already supported correctly. this fix should improve the way every one using this library sees the BubleSeries, changes:

BubbleSeries is now called ScatterSeries
Renamed BubbleSeries.MinBubbleDiameter and BubbleSeries.MaxBubbleDiameter to BubbleSeries.MinPointShapeDiameter and MaxPointShapeDiameter to keep it consistent.

Here is an example:
<lvc:CartesianChart LegendLocation="Right" Background="White">
        <lvc:CartesianChart.Series>
            <lvc:LineSeries Values="1,2,5,4"
                            PointGeometry="{x:Static lvc:DefaultGeometries.Diamond}"
                            PointGeometrySize="20"
                            Fill="Transparent"
                            PointForeround="IndianRed"/>
            <lvc:StepLineSeries Values="3,2,5,6"
                                PointGeometry="{x:Static lvc:DefaultGeometries.Square}"
                                PointGeometrySize="20"
                                Fill="Transparent"
                                PointForeround="IndianRed"/>
            <lvc:ScatterSeries Values="2,1,3,4"
                               PointGeometry="{x:Static lvc:DefaultGeometries.Trangle}"
                               MinPointShapeDiameter="10"
                               MaxPointShapeDiameter="35"/>
        </lvc:CartesianChart.Series>
    </lvc:CartesianChart>


[API] Best way for issues and PRs and it's count

Gitea 1.8.0
Currently reop info API return open issue count of issues.
https://try.gitea.io/api/swagger#/repository/repoGet
While issues API return both PRs and issues.
https://try.gitea.io/api/swagger#/issue/issueListIssues
If let's say there are 10 open issues and 2 open PRs, open issue count is 10. While issues API return 12 records inlcuding PRs.
Just an idea, inlucde the open PRs in the count OR exlucde PRs from the issues API.

with https://github.com/go-gitea/gitea/pull/12275 X-Total-Count header can be used

@mmarif4u does  #12275  close this?

@6543 I guess this is pretty much resolved.


karma init error on windows

Got this error when running karma init
Karma cli version 0.13.16
Clean install of node with jasmine and karma npm packages
readline.js:525
  this.line = this.line.slice(this.cursor);
                       ^

TypeError: Cannot read property 'slice' of undefined
    at Interface._deleteLineLeft (readline.js:525:24)
    at suggestNextOption (C:\project\node_modules\karma\lib\init\state_machine.js:43:9)
    at nextQuestion (C:\project\node_modules\karma\lib\init\state_machine.js:119:12)
    at process (C:\project\node_modules\karma\lib\init\state_machine.js:135:10)
    at Object.exports.init (C:\project\node_modules\karma\lib\init.js:247:6)
    at Object.exports.run (C:\project\node_modules\karma\lib\cli.js:237:25)
    at requireCliAndRun (C:\Users\user\AppData\Roaming\nvm\v5.3.0\node_modules\karma-cli\bin\karma:44:16)
    at C:\Users\user\AppData\Roaming\nvm\v5.3.0\node_modules\karma-cli\bin\karma:54:12
    at C:\Users\user\AppData\Roaming\nvm\v5.3.0\node_modules\karma-cli\node_modules\resolve\lib\async.js:44:21
    at ondir (C:\Users\user\AppData\Roaming\nvm\v5.3.0\node_modules\karma-cli\node_modules\resolve\lib\async.js:187:31)
    at C:\Users\user\AppData\Roaming\nvm\v5.3.0\node_modules\karma-cli\node_modules\resolve\lib\async.js:153:39
    at onex (C:\Users\user\AppData\Roaming\nvm\v5.3.0\node_modules\karma-cli\node_modules\resolve\lib\async.js:93:22)
    at C:\Users\user\AppData\Roaming\nvm\v5.3.0\node_modules\karma-cli\node_modules\resolve\lib\async.js:24:18
    at FSReqWrap.oncomplete (fs.js:82:15)

+1
Same thing for me. This also was happening when executing karma from node_modules.

+1

Even the windows command line not working for me. :-1:

Yes, as @Doormouse2House said it works fine in Windows CLI.
Probably you're using the Git Bash terminal, MinTTY, which doesn't have full support for TTY.
You have 4 options to fix the problem:

Use CMD terminal with the Windows shell (the default Windows console)
Use CMD terminal with the Bash shell (execute "C:\Program Files\Git\bin\bash.exe" --login -i in cmd terminal)
Use Powershell (an alternative terminal typically installed by default in Windows environments)
Use an alternative terminal (or develop a new one :stuck_out_tongue_winking_eye: )

If you just need execute isolated interactive commands like karma init, I recommend option 1 for it and then come back to Git Bash. However I would give a try to Powershell.

Same problem here. I have tried everything stated above. I even issue karma command from within node_modules/karma/bin folder.
Its not working


Crash

Type: Bug
Crash
VS Code version: Code 1.80.1 (Universal) (74f6148eb9ea00507ec113ec51c489d6ffb4b771, 2023-07-12T17:20:23.298Z)
OS version: Darwin arm64 22.1.0
Modes:

System Info

Item
Value

CPUs
Apple M2 Pro (10 x 24)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabledwebgpu: enabled

Load (avg)
3, 4, 4

Memory (System)
16.00GB (0.07GB free)

Process Argv
--crash-reporter-id 4e9d4a46-6ca6-43f7-a49c-9d1fe4cbceaf

Screen Reader
no

VM
0%

Extensions (12)

Extension
Author (truncated)
Version

Bito
Bit
1.1.2

codium
Cod
0.6.28

gitlens
eam
14.1.1

chatgpt-gpt4-gpt3-vscode
Eas
1.0.2

prettier-vscode
esb
9.19.0

vscode-jest-runner
fir
0.4.64

vscode-drawio
hed
1.6.6

base64
m4n
0.0.4

git-graph
mhu
1.30.0

vscode-thunder-client
ran
2.9.2

tabnine-vscode
Tab
3.6.77

carbon
who
0.4.0

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
vserr242cf:30382550
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vsdfh931cf:30280410
vshan820:30294714
vstes263:30335439
vscoreces:30445986
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30410667
py29gd2263cf:30792227
vsclangdc:30486549
c4g48928:30535728
dsvsc012cf:30540253
pynewext54:30695312
azure-dev_surveyone:30548225
3biah626:30602489
f6dab269:30613381
showlangstatbar:30737416
vsctsb:30748421
03d35959:30757346
pythonfmttext:30731395
pythoncmvfstrcf:30756944
fixshowwlkth:30771522
hideindicator:30785051
pythongtdpath:30769146
i26e3531:30792625
pythonnosmt12:30779714
pythonidxpt:30784022
pythonnoceb:30776495
h7j2d465:30786200
dsvsc013cf:30789518
dsvsc014:30791935
cmakesidepanelv2:30779593

/confirmPlease

Please perform the following three tasks to diagnose the root cause of the issue:

[ ] 1.) Disable Extensions

Select View and pick Command Palette...
Run Developer: Reload With Extensions Disabled
👉 See if the issue reproduces

[ ] 2.) Disable Configuration

Select View and pick Command Palette...
Run Profiles: Create a Temporary Profile
👉 See if the issue reproduces

[ ] 3.) Try VS Code Insiders

Download VS Code Insiders
Install and Run it
👉 See if the issue reproduces

Then pick one of the three resolutions depending on which step has helped:

Disabling my Extensions helped
Please run the command Start Extension Bisect and follow the instructions to find the extension that is causing this issue.

Please report the issue to the extension causing this.

Disabling my configuration helped
Please report back more details about your configuration, including settings.

Using VS Code Insiders has helped
✅ This likely means that the issue has been addressed already and will be available in an upcoming release. You can safely use VS Code Insiders until the new stable version is available.

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


Investigation: assembling documents seems slow

Using the ALDocument class seems to slow down document assembly. Maybe something to do with it raising more exceptions than normal attachment assembly would?
Can we find a way to test if this is correct and speed it up if it really is a problem?

I've found document display through ALDocument to be much slower than a built-in attachment. For a while, the table doubled the time because it was building each bundle twice - once for download and once for view - but I stopped that duplication of work. It still remained significantly slower than the built-in attachment.

So that's two anecdotes anyway. It would be nice to isolate and fix it.

If we move some of the files to the Weaver's download package instead of generating them in runtime in AL, it would reduce ALDocument's workload thus speed it up. This approach could also solve a bunch of file related open issues.

Jonathan just added a bunch of changes in DA 1.2.35 that we should experiment with. They might do a safer job of handling exceptions w/o slowing down document generation

We might consider also generating the document in the background. We will need to trigger document generation in the interview order block that the weaver generates.
There may be other places where we can trigger definitions in interview order block to help reduce code running multiple times. That would happen in the weaver too.

Changelog showing 1.2.35

I think a major factor here is idempotency. If we trigger all of the "metadata" type variables of the addendum early, it could help. E.g.: trigger .enabled, .has_addendum, .overflow_fields, etc. so they are defined before the list starts getting generated. A lot of those variables won't be defined until needed.

See #84 for probably the best overall resolution of this.

I decided to dive into actual profiling results for this issue. It just seems really strange that it should take 10 seconds to assemble some relatively simple PDFs. After some setup, I now have actual profiling results on this. This mostly would drive improvements upstream in DA core, but maybe we can deduce some other workarounds
out of this anyway.
Results
The below graph is the call chain of functions that happen when as_pdf() is called. Each box is a function, the % is the percentage of time spent calling that function over the whole time profiled, and the __ x is the number of times that function is called.

Here's the top functions where the most time is spent.

It's definitely weird that inspect.getmodule is called so much, and that it spends so much time there. I'll have to take a look at that next when I have time.
Profile setup**
In  any interview, add the following sections:
modules:
  - cProfile
  - pstats
---
objects:
  - download_file: DAFile
---
code: |
  download_file.initialize(filename='test.prof')
  # Put whatever python expression you want to profile here in the quotes
  runctx('al_user_bundle.as_pdf()', globals=None, locals=locals(), filename=download_file.path())
---
# Somehow later on, allow the user to download the file
  download_file.url_for()

Then run the interview, and download the profile file. Locally, have both kcachegrind and pyprof2calltree installed.
sudo apt install kcachegrind
pip install pyprof2calltree

pyprof2calltree -i ~/Downloads/test.prof -k

** I accidentally overwrote all of the setup code I had, so this might not work as written. But it's close.

This is very interesting, Bryce. I am not sure what inspect.getmodule does, but the number of times it is called definitely screams some idempotency issue to me. I think we can probably reduce the number of exceptions that are triggered by doing things higher up the stack.

qsteenhuis@GBLS-0783457:~/docassemble$ grep -r "inspect.get" -n
docassemble_base/docassemble/base/mako/ext/turbogears.py:34:        for kw in compat.inspect_getargspec(Template.__init__)[0]:
docassemble_base/docassemble/base/mako/doc/_sources/changelog.txt:40:      additionally replace the use of ``inspect.getargspec()`` under
docassemble_base/docassemble/base/mako/doc/changelog.html:235:additionally replace the use of inspect.getargspec() under
docassemble_base/docassemble/base/mako/doc/build/changelog.rst:40:      additionally replace the use of ``inspect.getargspec()`` under
docassemble_base/docassemble/base/mako/compat.py:23:    from inspect import getfullargspec as inspect_getfullargspec
docassemble_base/docassemble/base/mako/compat.py:25:    def inspect_getargspec(func):
docassemble_base/docassemble/base/mako/compat.py:27:            *inspect_getfullargspec(func)[0:4]
docassemble_base/docassemble/base/mako/compat.py:30:    from inspect import getargspec as inspect_getargspec  # noqa
docassemble_base/docassemble/base/mako/compat.py:174:        return inspect.getargspec(fn)
docassemble_webapp/docassemble/webapp/server.py:3002:            source_file = inspect.getsourcefile(the_name)
docassemble_webapp/docassemble/webapp/server.py:3111:                    pg_code_cache[val] = {'doc': noquotetrunc(inspect.getdoc(user_dict[val])), 'name': str(val), 'insert': str(val) + '()', 'tag': str(val) + str(inspect.formatargspec(*inspect.getargspec(user_dict[val]))), 'git': source_code_url(user_dict[val])}
docassemble_webapp/docassemble/webapp/server.py:3120:                    pg_code_cache[val] = {'doc': noquotetrunc(inspect.getdoc(user_dict[val])), 'name': str(val), 'insert': str(val), 'git': source_code_url(user_dict[val], datatype='module')}
docassemble_webapp/docassemble/webapp/server.py:3133:                    methods = inspect.getmembers(user_dict[val], predicate=lambda x: public_method(x, user_dict[val]))
docassemble_webapp/docassemble/webapp/server.py:3139:                        method_list.append({'insert': '.' + str(name) + '()', 'name': str(name), 'doc': noquotetrunc(inspect.getdoc(value)), 'tag': '.' + str(name) + str(inspect.formatargspec(*inspect.getargspec(value))), 'git': source_code_url(value)})
docassemble_webapp/docassemble/webapp/server.py:3143:                    pg_code_cache[val] = {'doc': noquotetrunc(inspect.getdoc(user_dict[val])), 'name': str(val), 'insert': str(val), 'bases': bases, 'methods': method_list, 'git': source_code_url(user_dict[val], datatype='class')}

And on line 3023 of server.py, it looks like most of the calls to inspect.* are in get_vars_in_use. I think that would definitely be used for assembling a DOCX template. I wonder if it's also used when skip undefined: True is turned on for a PDF.

I'm not sure if idempotency is it: the defined_fields method is only called 4 times and defined and value are called a combined 48 times (at least in the one as_pdf call I profiled), which doesn't seem bad? I did it on the AL Test interview, so I think there about 20 fields in there now, so the number of fields roughly matches the times value_if_defined is called on our side. I think inspect.stack is incredibly expensive though, which is mentioned briefly in the DA documentation:

The value() function is relatively inefficient. If you can use regular Python expressions instead of value(), you should do so.

There looks to be quite a few speed ups in core, that I need to test out a bit before trying to push them upstream:

Instead of stack() grabbing the entire stack at once, just call current_frame(), and go up one at a time
Using stack(context=0) might be much faster since it doesn't need to read in file info
defined() and value() have a lot of overlap, and our value_if_defined() (which is equivalent to showifdef()) is essentially doing the same work twice.

There's less to do on our side, but I think we could:

make a separate ALAddendumFieldDict::has_overflow() method that break out of the defined() loop on the fields.
Dedup some of the work that's being done in safe_value and overflow_value when they're called from the same place (i.e. https://github.com/SuffolkLITLab/docassemble-AssemblyLine/blob/4a9fa91d4a434392de92bd6e3330d16b691e9417/docassemble/AssemblyLine/al_document.py#L107).

I'll take a look there first. I think most of the value() etc. functions are only triggered when an addendum is involved, and only for the fields that need to handle overflow, so I don't know if that could be the only explanation.

The speedup in #205 makes me wonder if it's worth using a pattern where every addendum field needs to be defined, or at least we have an explicit "optional" flag. That will be more confusing to use though.

Update: I've been trying the different ideas I had in the previous comment out, but none of them seem to be having any noticeable effect in the generation times. It could be a few things:

The profiling I tried to do last time doesn't seem to actually catch much of the entire process: if DA has to stop and search for the definition of a variable at anytime, the profiling is just stopped and doesn't continue.  I do have a new way to profile which seems to catch much more of the whole processing step:

---
modules:
  - cProfile
  - pstats
---
objects:
  - download_file: DAFile
---
code: |
  profile = Profile()
---
code: |
  profile.enable()
  start_profile =True
---
code: |
  profile.disable()
  profile.dump_stats(download_file.path())
  del profile
  stop_profile = True
---
code: |
  download_file.initialize(filename='test.prof')
  new_stuff = True
---
# In the question that asks for the thing you're trying to time, for example, al_user_bundle, or tenant_repair_letter_bundle
id: download_conditions_checklist_docs
event: download_conditions_checklist_docs
question: |
  Your documents are ready  ${start_profile}
subquestion: |

  ${new_stuff}
  [prof](${ download_file.url_for() })
  ...
  ${ stop_profile }
---

I just don't know which interview that the above results were on. I'm kicking myself right now for just not writing it down at all. It could be an outlier, or the few forms that I'm trying could be the outliers, I'm not sure.
It could be the fact that I'm running things locally and not on a AWS hosted - S3 enabled Docassemble server.

Whichever it is, I ran the above code on Quinten's Housing Code Checklist, which seems to be a good stress test: it takes ~18 seconds consistently to generate the final doc. I generated
test.zip
on that interview, and it looks to be taking most of the time (75%) on word_to_pdf(). It still doesn't look like it's too much of an idempotency issue though, it's only called 8 times.

I'm stuck trying to figure out why the subprocess.run in word_to_pdf is taking so long (~15 seconds, to convert 7 files to pdfs seems ridiculous).  But I don't think I can make much more progress here tbh. The other changes seem to work fine, but they just aren't giving the speed up I'd hoped for.

@BryceStevenWilley can we see how performance changes if we enable convertAPI or cloudconvert? I don't have an API key for either one but they both have free tiers.
https://docassemble.org/docs/config.html#libreoffice

I have suspected that starting up LibreOffice to convert files could be pretty slow. I think paying for an API (especially as expensive as the two options Docassemble supports) is probably non-starter, but maybe we could run LibreOffice in a listen mode instead of starting a new process for each conversion and assign a Lightsail instance or ec2 to run just conversions.

Welp, I tried it once with convertAPI, it took ~42 seconds to convert the documents, so I don't think either api will make it much faster tbh.
I need to look into what libreoffice is doing more I think. It's trying to use a macro to convert the files, but I can't actually get that macro to run outside of docassemble on the command line. Libreoffice in general shouldn't be too slow: there's another option to convert to PDF (I don't know if it's equivalent to what the macro is doing), libreoffice --convert-to pdf my_docx_file.docx takes no where near that time to convert several documents
brycew@fossa 15:38:22:~/Developer $ time libreoffice --convert-to pdf *.docx # converting 3 docxs

real	0m0.482s
user	0m0.005s
sys	0m0.005s
brycew@fossa 15:38:28:~/Developer $ time libreoffice --convert-to pdf Evidence_packet.docx

real	0m0.217s
user	0m0.006s
sys	0m0.008s

It looks like this was used before (there's still a commented out line with the same command), so I might ask Johnathan to see why that was changed.

I have a vague memory of some macro support being added to help update things like dynamic TOCs. Not sure if that's related--if so, maybe it should be an option in the attachment block.
I think this is the base of Jonathan's macro--at least the name seems to come from here: https://www.xml.com/pub/a/2006/01/11/from-microsoft-to-openoffice.html

Good job finding the actual macro: https://github.com/jhpyle/docassemble/blob/master/docassemble_base/docassemble/base/data/macros/Module1.xba
Noticing that it contains 4 Waits totaling 1600 milliseconds. So maybe we can optimize that macro...

This idea is a little far out, but when I used to run Linux as my desktop I preferred AbiWord for every day use--it was much faster. It has a convert to PDF feature. An idea to keep in the back pocket.
I was also thinking re: your profiling, I greatly reduced the number of calls to value() so maybe that threw off your old profile?

Per Jonathan:

One problem might be that I set it up with a spinlock, so only one instance of LibreOffice can run at one time in a container.  I did this because I was encountering difficult issues where LibreOffice, though launched in "headless" mode, was still acting like a desktop application, so that if you tried to run LibreOffice while LibreOffice was already running under the same user account, it wouldn't start.  It might be the case that the recent version of LibreOffice doesn't have that problem, so you could experiment with turning the spinlock off.
I might have tried the listen mode thing and couldn't get it to work, although I could try it again now that LibreOffice is several versions ahead of where it was the last time I worked on the issue.

Notes from our 7/7/21 call:
Why is the built-in file generation faster w/o ALDocument?
Is the difference as big w/ idempotency fixes, caching, and reduced calls to value()?
Problems w/ the value() function
Could we use the all_variables() function to basically get a cache of all of the lookups? Is that slower or faster?
Bryce is working on some fixes that should have at least a small improvement but they need more testing to do a PR.
Would using mako templates instead of DOCX be faster?
Do we need to do a new fork for libreoffice each time? Can it just be waiting?
Look at Jonathan’s macro
Can we remove waits? Is the retry 3 times enough to handle whatever the waits were added to accomplish?
Can we make the slow maco optional?

DA's 1.2.89 update removed those waits, which is exciting.  I tested the same interview generation before and after the update, and it went from ~1.77 seconds per call to word_to_pdf() to ~0.91 seconds per call, so about 2x speed up!
Like I mentioned before, it does seem like ALDocument is just a stress test of a lot of different components: each time I try to profile a different interview, I get a different function that's taking the most time. First it was showifdef, then it was word_to_pdf, and on my most recent profiling, it's pdf_concatenate that's taking the longest (which makes sense, because I added a lot of images and extra documents where I could this last time, and more of them were probably originally PDFs. There were 25x calls to pdf_concatenate(), vs only 11 last time).
This "investigation" ticket may have reached it's end, but IMO we should focus on the background assembly, and then slowly chip away at what makes things take so long. I can make a ticket to properly triage all the different ways that assembling documents can be slow, and see what could improve things.

Per @BryceStevenWilley's comment above, I think this issue feels ready to close for now. We can keep tracking undiscovered issues in #238


As a user, I want to set all supported fields on collection create

Currently missing:

Expiration Time
Auto Renew Account
Auto Renew Period
Memo

This is currently blocked by a potential bug in Hedera SDK
https://github.com/hashgraph/hedera-sdk-js/issues/2140


[WIP] Upgrade to mongodb 3.x.x

Thank you for your effort here! Please don't upgrade vows. All versions other than 0.8.0 which it is strictly fixed to are horribly buggy and causing tests to hang up and also show some other bugs. We decided to remove vows completely in favour of lab, unfortunately that did not happen for a few drivers yet.

Is there anything I can help you with so we can merge this PR?

Hey @BorntraegerMarc Glad you ask. Since I am very rarely a mongodb user, it would be actually great to get help from someone that is using it more often. If you could test this PR for functionality and identify potential regressions should you have a project at hand where you could test against that would be tremendous help!

and also the db.close issue mentioned in the thread earlier has to be taken care of.

Just made sure the tests are running again on travis though

Sorry, I was swamped at work the last weeks. Looking into this now

Could someone tell me what exactly this PR wants to solve? Because it seems like on master we already use the v3 of mongodb: https://github.com/db-migrate/mongodb/blob/master/package.json#L30

Could someone tell me what exactly this PR wants to solve? Because it seems like on master we already use the v3 of mongodb: https://github.com/db-migrate/mongodb/blob/master/package.json#L30

Yes, package.json is updated, but the tests fail. With the db.close() we get errors in tests, without it, the number of connections "balloon up" to 10+ during the test, which seems weird, but might be okay. I plan to test this on a real db migration soon.

Yes, package.json is updated, but the tests fail. With the db.close() we get errors in tests, without it, the number of connections "balloon up" to 10+ during the test, which seems weird, but might be okay. I plan to test this on a real db migration soon.

Ah, so this PR is to fix the tests 🙂 Thx for the help! I'll also start looking into it

Yes, package.json is updated, but the tests fail. With the db.close() we get errors in tests, without it, the number of connections "balloon up" to 10+ during the test, which seems weird, but might be okay. I plan to test this on a real db migration soon.

Ah, so this PR is to fix the tests 🙂 Thx for the help! I'll also start looking into it

Well not just the tests -- the new version of mongo manages connections/sessions differently -- so we're looking into whether db.close is needed in index.js
https://github.com/db-migrate/mongodb/pull/41/files#diff-168726dbe96b3ce427e7fedce31bb0bcL307
The node mongodb driver's changelog for 3.0.0 notes that the way mongo handles sessions is different, so we probably need to close the connection differently or not at all.

Version 3.6 of the server introduces the concept of logical sessions for clients. In this driver, MongoClient now tracks all sessions created on the client, and explicitly cleans them up upon client close. More information can be found in the Driver Sessions Specification.

https://github.com/mongodb/node-mongodb-native/blob/master/CHANGES_3.0.0.md

Closing this, as I am not working on this, and don't want it to appear like I am working this


Tiktok Photomode Photoslide downloader

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm reporting a new site support request
[X] I've verified that I have updated yt-dlp to nightly or master (update instructions)
[X] I've checked that all provided URLs are playable in a browser with the same IP and same login details
[X] I've checked that none of provided URLs violate any copyrights or contain any DRM to the best of my knowledge
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue
[ ] I've read about sharing account credentials and am willing to share it if required

Region
No response
Example URLs
https://www.tiktok.com/@addisonre/photo/7338943586698054958
Provide a description that is worded well enough to be understood
I wrote this code that download tiktok photo slide, i am sure someone with more skills can integrated with yt-dlp or improve on it
tiktokphotomode.zip
Provide verbose output that clearly demonstrates the problem

[X] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[ ] If using API, add 'verbose': True to YoutubeDL params instead
[X] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
none

Downloading photos is out-of-scope for this project.
Duplicate of #6168, #6217, #8360, #9990


Use embedded shapeless 2.0?

Is there any chance shapeless can be "embedded" under the sqltyped package so as to allow the use with libraries dependent on shapeless 1.x? (ie, spray uses shapeless 1.x and there is little chance it well get upgraded anytime soon.)

(necroposting)
You can user assembly shading for that


Record where plugins were installed from

As a secondary request, #1580 suggests that we display where plugins were installed from.  We can't do that at the moment because we don't record that information.  This PR records manifest locations in a .install.json file in the plugin directory (next to <plugin>.license).
The code is based on the template origin recording code, although there are some changes to reflect existing differences, such as registry origins, and recording info in JSON instead of TOML.
NOTE: This PR does not include displaying the plugin source, which is what #1580 asks for, because at the moment there would be nothing to show - it is merely laying the ground for the future feature.

@kate-goldenring Is there a good place in which to test this?

https://github.com/fermyon/spin/issues/1580 seems to request an experience like templates, showing where plugins were installed from. "where" seems to have a dual meaning for plugins: where the manifest came from and where the plugin binary came from. This seems to decide that the former is what the user in interested in, possibly since then you can find the latter by inspecting that manifest? Could we also list the location for yet to be installed plugins if they are from the plugins repository? So like the following?:
$ spin plugins list --verbose
+---------------------------------------------------------------------------------------------------------------------+
| Name               Version             Description                  Location                             |
+=====================================================================================================================+
| cloud [installed]     0.1.0          The Fermyon Cloud Plugin   /User/kagold/my/manifests/cloud.json           |
| cloud                 0.1.1          The Fermyon Cloud Plugin<EMAIL_ADDRESS>         |
| js2wasm               0.4.0          JS Plugin                  https://github.com/fermyon/spin-plugins/manifests/js2wasm/js2wasm.json            |
+---------------------------------------------------------------------------------------------------------------------+

Or just installed?
$ spin plugins list --installed --verbose
+---------------------------------------------------------------------------------------------------------------------+
| Name               Version             Description                  Location                             |
+=====================================================================================================================+
| cloud [installed]     0.1.0          The Fermyon Cloud Plugin   /User/kagold/my/manifests/cloud.json           |
+---------------------------------------------------------------------------------------------------------------------+

@kate-goldenring That's a great question about what the issue is actually asking for.  For me, "where I installed it from" is kind of "what did I actually write to install it, where would I go to reinstall it", which is the manifest location.  I am not sure what a user would do with the "where the binary was downloaded from" location.  @mikkelhegn as the issue author, what did you have in mind?

Another thought is that we can use this info to skip the badger check on plugins that do not come from the registry.  I was also thinking about upgrade --all and upgrade --ask, though I concluded we couldn't use them against URLs the way we do templates (because the versioning approach is different).

@kate-goldenring That's a great question about what the issue is actually asking for. For me, "where I installed it from" is kind of "what did I actually write to install it, where would I go to reinstall it", which is the manifest location. I am not sure what a user would do with the "where the binary was downloaded from" location. @mikkelhegn as the issue author, what did you have in mind?

The former, and thinking about it, a command to actually print the manifest would be great :-) But I can open an issue when this becomes more of a thing. E.g., doing jq commands against that output, could give me what @kate-goldenring is looking for, and a whole lot of other stuff. Just a a side note to nerdsnipe a bit, having a json formatted output of these types of command would be great for many scenarios, e.g., selectively delete templates, based on querying the ones I have installed.

@mikkelhegn Please, yes, raise separate, specific issues.  At least then I can have some structure to my nerdsnipings...!
And please raise separate issues for plugins and templates.  They share some DNA but there are sufficient differences in the way they're implemented that a feature in one doesn't come for free in the other I'm afraid.


Default value never fetched in Twig Extension

There is a bug here, if no save action is performed in admin before using this function, then the result will be always null.
https://github.com/monsieurbiz/SyliusSettingsPlugin/blob/master/src/Twig/Extension/SettingsExtension.php#L79
The default value in the config file must be used if present.
I will open a PR for this soon.

Hi @TonySma !
Do you still have this issue?
Thanks!


How to leverage the output of proguard rather than the result of the jar task?

 This is part of a LibGDX project hence the reliance on the dist task and the reference to an android module with regard to the proguard-rules. Currently I am registering a task called proguard which takes the result of the jar task and runs it through my rules like so:
tasks.register('proguard', ProGuardTask) {
  dependsOn 'dist'
  configuration files("../android/proguard-rules.pro")

  // Java 17
  libraryjars files(
          "${System.getProperty('java.home')}\\jmods\\java.base.jmod",
          "${System.getProperty('java.home')}\\jmods\\java.desktop.jmod",
          "${System.getProperty('java.home')}\\jmods\\java.sql.jmod",
          "${System.getProperty('java.home')}\\jmods\\java.xml.jmod",
          "${System.getProperty('java.home')}\\jmods\\java.logging.jmod"
  )

  injars files("build/lib/Mirage Realms-1.0.0.jar")
  outjars files("build/lib/Mirage Realms Proguard-1.0.0.jar")
}

// Equivalent to the jar task; here for compatibility with gdx-setup.
tasks.register('dist') {
  dependsOn 'jar'
}

My question is, what is the correct / ideal way to get construo to package the output of my proguard task rather than the output of the jar task? I would prefer to keep the jar and the proguard tasks separate as it really helps to have both jar files to hand when it comes to debugging proguard output issues.

Right now this isn't possible unfortunately. I think one way of doing this would be to add an extra property in the plugin extension and change the way the task is obtained to consider that property, if present.
Right now I don't have a lot of time to work on this though, if you want to make a PR I'd be happy to review and publish a new plugin version, otherwise it'll have to wait until I have more time

Actually, this won't work :thinking: ProguardTask is not a JarTask

Now it works! You can update to 1.3.0, and specify a custom jarTask and mainClass in the config (see readme)


Development

Not sure this PR was meant to be pushed to Wave. 🤔 Also, your .env file is getting tracked, which should never be tracked and pushed into version control, those contain secrets that should not be publicly available, that's a huge security risk. I recommend stopping tracking it immediately and reading "Removing sensitive data from a repository" from GitHubs' documentation on how to proceed next.
@bobbyiliev you can close this PR. 👍

Thanks for the message. I was troubleshooting through some connectivity
issues. I switched to a private repo yesterday for my main project, and
just deleted the old one.
On Sun, Feb 26, 2023 at 4:29 AM Bobby Iliev @.***>
wrote:

Closed #89 https://github.com/thedevdojo/wave/pull/89.
—
Reply to this email directly, view it on GitHub
https://github.com/thedevdojo/wave/pull/89#event-8609350483, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AROANW5YPDEKTM4FKNBFTF3WZM5BPANCNFSM6AAAAAAVID74SM
.
You are receiving this because you authored the thread.Message ID:
@.***>

That’s great an all, but I’d still suggest refreshing any secret keys and switching any passwords that was in the file. 👍 As soon as it has been public you can be sure some bot has snatched up the credentials.

On 26 Feb 2023, at 9:33 PM, dschiffer12 @.***> wrote:
Thanks for the message. I was troubleshooting through some connectivity
issues. I switched to a private repo yesterday for my main project, and
just deleted the old one.
On Sun, Feb 26, 2023 at 4:29 AM Bobby Iliev @.***>
wrote:

Closed #89 https://github.com/thedevdojo/wave/pull/89.
—
Reply to this email directly, view it on GitHub
https://github.com/thedevdojo/wave/pull/89#event-8609350483, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AROANW5YPDEKTM4FKNBFTF3WZM5BPANCNFSM6AAAAAAVID74SM
.
You are receiving this because you authored the thread.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub https://github.com/thedevdojo/wave/pull/89#issuecomment-1445460190, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQ6NMTQI7OYAO2OXEACWKLWZO4YTANCNFSM6AAAAAAVID74SM.
You are receiving this because you commented.

Thanks for the tip, they were all temporary passwords and credentials.
On Sun, Feb 26, 2023 at 1:40 PM Kim Hallberg @.***>
wrote:

That’s great an all, but I’d still suggest refreshing any secret keys and
switching any passwords that was in the file. 👍 As soon as it has been
public you can be sure some bot has snatched up the credentials.

On 26 Feb 2023, at 9:33 PM, dschiffer12 @.***> wrote:
Thanks for the message. I was troubleshooting through some connectivity
issues. I switched to a private repo yesterday for my main project, and
just deleted the old one.
On Sun, Feb 26, 2023 at 4:29 AM Bobby Iliev @.***>
wrote:

Closed #89 https://github.com/thedevdojo/wave/pull/89.
—
Reply to this email directly, view it on GitHub
https://github.com/thedevdojo/wave/pull/89#event-8609350483, or
unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AROANW5YPDEKTM4FKNBFTF3WZM5BPANCNFSM6AAAAAAVID74SM

.
You are receiving this because you authored the thread.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub <
https://github.com/thedevdojo/wave/pull/89#issuecomment-1445460190>, or
unsubscribe <
https://github.com/notifications/unsubscribe-auth/AAQ6NMTQI7OYAO2OXEACWKLWZO4YTANCNFSM6AAAAAAVID74SM
.
You are receiving this because you commented.

—
Reply to this email directly, view it on GitHub
https://github.com/thedevdojo/wave/pull/89#issuecomment-1445461740, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AROANW57AE3G7WYSNVJLYL3WZO5VHANCNFSM6AAAAAAVID74SM
.
You are receiving this because you authored the thread.Message ID:
@.***>


Issue 42078: TSV export not resolving Lookup Columns by display column name

Rationale
Due to this PR, we are now passing through full column infos to ResultSetDataIterator results. This includes the DisplayColumnFactories. TSV export uses the DisplayColumnFactory to populate data for the export but cannot correctly load values with FK by the Lookup names (ex. JobRunId/JobRunId). Need to use NOLOOKUP display factory for TSV export.
Changes

Check for FK on the columns in TSVGridWriter.init and if it exists, use NOLOOKUP DisplayColumnFactory

I haven't tested this, but it looks like it would change all TSV exports so that they render the raw FK value instead of the display value from the target table.
If you do a TSV export from an issues grid (for example) do you get user names, or user IDs for columns like Assigned To and Created By?

I haven't tested this, but it looks like it would change all TSV exports so that they render the raw FK value instead of the display value from the target table.
If you do a TSV export from an issues grid (for example) do you get user names, or user IDs for columns like Assigned To and Created By?

Marty's change only affects the case where TSVGridWriter is handed a bare Results object (w/o explicit list of DisplayColumn objects).  You would expect the latter to be the common case e.g.
 Results results = rgn.getResults(view.getRenderContext());
 try (TSVGridWriter tsv = new TSVGridWriter(results, getExportColumns(rgn.getDisplayColumns())))
Still, I'm surprised how many usages there are of new TSVGridWriter(Results)

The bug report isn't very specific.  It this showing up as a general problem, or a specific code path that could possibly be fixed by calling tsvWriter.setApplyFormats(false);

The bug report isn't very specific. It this showing up as a general problem, or a specific code path that could possibly be fixed by calling tsvWriter.setApplyFormats(false);

The bug was found by this test failing test.  I can check out tsvWriter.setApplayFormats.  The issue is that the column name in RenderContext is not the same as the display value for these lookup columns, so when trying to retrieve the actual value for the TSV file, the names are not matching and the value is not found.  I can try out the setApplyFormats path but I believe it still ultimately calls DisplayColumn.getDisplayValue(RenderContext)

The bug report isn't very specific. It this showing up as a general problem, or a specific code path that could possibly be fixed by calling tsvWriter.setApplyFormats(false);

The bug was found by this test failing test. I can check out tsvWriter.setApplayFormats. The issue is that the column name in RenderContext is not the same as the display value for these lookup columns, so when trying to retrieve the actual value for the TSV file, the names are not matching and the value is not found. I can try out the setApplyFormats path but I believe it still ultimately calls DisplayColumn.getDisplayValue(RenderContext)

I did test this fix out on all the BVT, Dailys, CustomModules, NCI, Nab and DataIntegration tests.

I see so it looks like an ETL is running to generate a TSV that later code expects to be able to import.  The default mode of TSVGridWriter is not to generate round-trippable files.  It is to generate data that looks like the source 'dataregion' (assuming there is one).  Since this probably isn't the intention of most TSV generated by ETL, the fix is probably to default to TSVGridWriter.setApplyFormats(false) in TransformTask.appendToTargetFile().  This will give higher fidelity output (e.g. floating point and date precision).
It might make sense to be able to seperately configure use lookups and use formats in TSVGridWriter, but they are tied together now.

PS: I wasn't involved in the initial spec for TSV support in ETL.  I don't know if there is a need for formatted TSV output (doesn't seem too likely)

I see so it looks like an ETL is running to generate a TSV that later code expects to be able to import. The default mode of TSVGridWriter is not to generate round-trippable files. It is to generate data that looks like the source 'dataregion' (assuming there is one). Since this probably isn't the intention of most TSV generated by ETL, the fix is probably to default to TSVGridWriter.setApplyFormats(false) in TransformTask.appendToTargetFile(). This will give higher fidelity output (e.g. floating point and date precision).
It might make sense to be able to seperately configure use lookups and use formats in TSVGridWriter, but they are tied together now.

Indeed it looks like the setApplyFormats solution resolves the issue for this case.  I'll test it out on other suites.

Closed in lieu of this PR
https://github.com/LabKey/dataintegration/pull/69


Fix string checking bug and refreshLang param

The initLangSelect() method was treating the return value of
strstr() as an integer, which was resulting in a warning:
"A non-numeric value encountered at Intuition.php:1347"
This patch fixes this and makes it clearer what's happening.
It also fixes refreshLang(), which was previously not working.

:+1: I've observed the same warning

I guess that new lang code should be in a separate commit shouldn't it?

I've made #93 for that.

Any chance we could get a new minor release that includes this patch?

@MusikAnimal This is now done (v1.2.0).


Bump minor version

After #1900 we should, IMO, bump the minor version given that we did so in DPPL. Technically this should be non-breaking, but I'm personally worried that there will be some unforeseen consequences OR people are simply using some internal functionality from DPPL (which did have a breaking release).

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 81.241%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1152

Relevant Lines:
1418

💛  - Coveralls


Change how chain links are stored

Overview
When working towards #472, I realized that currently chain links are stored associated with a profile inside the Profile object itself. While this is very handy when querying them, the major downside is that when storing a chain link we need to update the whole profile. Since the gas usage is based on how much data is written during a transaction, this will cause later changes to the chain links slice to be extremely costly. Suppose we have a profile with already 10 links, if we add the 11th we need to write the whole slice again so we are writing 10 objects that we should not.
Changes proposal
For the above reason, I think what we can do is change how chain links are stored by using the same method we use with other repeated data (eg: DTag requests, blocks, etc):
ChainLinkPrefix + username + chain_name + chain_address -> ChainLink

This would allow us to check the existence of a link in O(1) time as well as to query for such link in the same time.
If this is implemented, the ProfileByChainLinkQuery needs to be replaced with a UserChainLinks paginated query.
Please @dadamu @bragaz let me know what you think about this change.

I highly agree with it. In my opinion, chain links should be isolated from profiles. It brings more flexibility to operate with chain link. And we can avoid the updating all chain links for profile when creating a new link as you said.

As we did for subspaces with admins and registered users this is the best way to go for this too. 💪

@dadamu Are you currently working on this? If not, I might be able to pick it up in the next days before starting to review all the tests

@RiccardoM Yes, I am working on it.


Need assembly resolution when loading custom bindings

For BYOB, none of the custom bindings are loading because the binding has a reference to Webjobs version X, and the script runtime refers to WebJobs version Y.  We need to resolve so they all unify on Y.
Else none of the attributes and types line up, and we fail type checks like this:
https://github.com/Azure/azure-webjobs-sdk-script/blob/a1360cb2a3314dea8ba806d71690d6e6c26fea72/src/WebJobs.Script/Host/ScriptHost.cs

This is related to https://github.com/Azure/azure-webjobs-sdk-script/issues/1397, but this bug is specifically validating the startup path  in ScriptHost.

With the tooling, BYOB and CLI, we have to ensure our redirects are appropriately setup, also covering higher versions of what the runtime references (for minor-safe version ranges), so we can have that unification happen.
We can also have some logic as part of the resolution process to make sure those assemblies are resolved as a fallback, but this should only be required if we don’t feel the redirects aren’t sufficient.

By default, script runtime’s assembly resolution should unify SDK & Json.Net. These are special assemblies. We could emit a warning if this downgrades the user version, or allow an opt-out if this is truly a problem.
Our default logic hurts us in VS tooling and also commonly breaks BYOB:

The default experience when a user adds a reference to JSON.Net, WebJobs, is to pull the latest.  (Even though most often, the user doesn’t care about the exact version and just wants any working version )
This commonly means they’ll pull a version greater than Script runtime’s referenced versions.
Our default behavior in that case is to then load  side-by-side (since we currently only do unification for lower versions), which will lead to failures since  these assemblies expect to be unified.

In other words, our default behavior practically guarantees an error  in the common customer case.

This would be a breaking change.
The unification may also be undesirable, and only applicable if those types are being used in parameter bindings, which is not always the case.
This would require an explicit user action if done, otherwise, existing customers would be impacted.

This can be done in a non-breaking way.  The presence of custom binding extensions provides that switch.
The current behavior is most likely not what the customer wants.
Trying to load multiple SDKs side-by-side (instead of unify) is absolutely incorrect and customers are not expecting that.

The presence of a custom binding extension alone is not enough eliminate the risk of a breaking change. We'd need to unify on the actual bound type

This is the desired behavior in many cases, we can't make this statement without actual data, but we do know that we have several scenarios where the current binding behavior is needed.

Not absolutely incorrect in the context of functions, though. We do provide isolation and if customers are binding to Foo 3.0, I would argue the expectation is that Foo 3.0 is what they'd bind to at runtime (which is the current behavior). The unexpected behavior would be to automatically redirect to a different version because of an implementation detail of the runtime (for that to be expected, we'd require them to understand that)

Something else worth noting is that our set of dependencies with the VS tooling is controlled by us. We can absolutely restrict the dependencies to the supported versions which would give your consistency between what you compile, test and get when running in our runtime.


Data Modelling - Migration

Drafting data model

I can start working on migration queries once we review and have a user friendly journey and data flow.


README file makes me nervous

awaiting evidence.

I compiled the code but can't SDK yet. Please advise.

Any updates.

Planning a rewrite to python

Python 2
...right?


The property 'CalcFormula' cannot be customized

I am using July update and converted CAL to AL.
I got below error while changing CalcFormula property of standard field.
Isn't it supported?
severity: 'Error' message: 'The property 'CalcFormula' cannot be customized'

No, calculation formulas cannot be customized. The conceptual problem here is that what if multiple extensions customize the CalcFormula on the same field - then there is no deterministic order to decide which customization is more important. Therefore the only properties that can currently be customized are the ones that have (let's call it) not so serious impact on the runtime.


Removes itertools dependency

the main purpose of this PR is to remove the dependency on more_itertools.

I'm not inclined to merge this one:

The code is more clear with more_itertools than without.
I use more_itertools functions very frequently, so I'll likely add the dependency back in the future.
I don't see why having more_itertools as a dependency is a problem.

I'm also not going to merge the changes to the comments: the trailing whitespace is how my editor determines which blocks of text should be line-wrapped.
I'd like to merge the fixes to the ConfigError lines and the unused imports, though.  Perhaps those should be their own PR.

1. The code is more clear with `more_itertools` than without.

i would argue that a design where the property exclude_section (sg.) is either a single item or an iterable.

2. I use `more_itertools` functions very frequently, so I'll likely add the dependency back in the future.

it's currently not frequently used in this project and a dependency can always be added if necessary. it would also be very simple to vendorize the generator function in question.

3. I don't see why having `more_itertools` as a dependency is a problem.

imho it's within an engineer's responsibility to reduce resource consumption. i'm assuming that this extension will gain popularity and then the network traffic to retrieve the more_itertools library scales with all these fully automated documentation builds that are nowadays common after each (often completely unrelated) code change.

I'm also not going to merge the changes to the comments: the trailing whitespace is how my editor determines which blocks of text should be line-wrapped.

well, i will not judge whether your or my editor is correct or not. after the great editor wars people luckily don't care about other people's choices and established peace-keeping solutions such as PEP-8 and black.

I'd like to merge the fixes to the ConfigError lines and the unused imports, though. Perhaps those should be their own PR.

you may cherry-pick or just reproduce these changes.


populate fields of direct abstract superclass when populating concret…

…e subclass (fixes #204)

Coverage remained the same at 92.36% when pulling 9b7cc49a733e7bc544f30be7131f0c21e7c9eed3 on PascalSchumacher:#204 into a84f2d08db9a15906f1335372020c911889234e0 on benas:master.

Great! thanks