Pattern matching on lists

Pattern matching on lists fails with "never" exception.
I have the following code to get the second <iframe> element on the page
open FunScript
open FunScript.TypeScript

let toNodesList (nodes:NodeList) =
    let rec getNodesRec i =
        match int nodes.length with
        | x when x > 0 && x > i -> nodes.Item(x) :: getNodesRec (i + 1)
        | _ -> []
    getNodesRec 0

let querySelectorAll (document:Document) selector =
    document.querySelectorAll(selector) |> toNodesList

let querySelector (document:Document) selector =
    let nodes = querySelectorAll document selector
    match nodes with
    | x :: _ -> Some (x :?> HTMLElement)
    | _ -> None

let secondFrame =
    let nodes = querySelectorAll Globals.document "iframe"
    match nodes with
    | first :: second :: _ -> second :?> HTMLFrameElement
    | _ -> failwith "Frame not found"

let main () =
    Globals.console.log secondFrame

It successfully gets the nodes but it fails on pattern matching. Is it not supported yet or I'm doing anything wrong?

If you get the "never" exception, probably it's because the F# compiler is trying to evaluate a function that's only supposed to execute in JS. The culprit may be secondFrame as the F# compiler will try to evaluate it eagerly before Funscript comes into play. Can you please try changing it to let secondFrame()? (The last line should then become something like Globals.console.log <| secondFrame().)

Yes, it works after changing value to function. Is it temporary constraint of the library or it can't be implemented otherwise?

Well, you could prevent the eager evaluation by compiling the project as a library and then using an external script to generate the JS code from the dll but it may be not worth the effort depending on your workflow. I'm actually working in a new version that will use the F# Compiler Services to generate the AST directly from the source files without compiling them first, which would solve this problem among other things, but I still need to put more work on it :/ I'll try to release at least an alpha version this month. You can follow issue #171 if you're interested.

Ok, thank you!


Click doesn't work (dom.GetBoxModel().WithNodeID)

dom.GetBoxModel().WithNodeID don't return correct values
Click() -> MouseClickNode() -> dom.GetBoxModel().WithNodeID

This lacks information. Please provide a short Go program that shows the buggy behavior.

Closing for now. Feel free to reopen if you can provide detailed information.


Add utility function for converting point coordinates between magnifications

@slee172, @cdeepakroy What would the preferred API for this look like?  For instance,
point = (x, y)
scaledPoint = tilesource.getPointAtAnotherScale(point, sourceScale, sourceUnits, targetScale, targetUnits)

where sourceScale, targetScale, and targetUnits are identical to the parameters that can get passed to convertRegionScale.
As an example, if you have coordinates at magnification 5 and want them in the base units coordinates, this would be
scaledPoint = tilesource.getPointAtAnotherScale(point, sourceScale={'magnification': 5}, sourceUnits='mag_pixels', targetUnits='base_pixels')

This looks good to me.

Added in PR #230.


Feature: Form.props.onChange

What
Maybe there is a use case to have a general onChange handler assigned to the Form, which fires each time any field inside changes.
onChange handler is different from onDirty because onChange fires each time any field is changed within the form, while onDirty fires only once, when the first change happens.
How
Need to proof this feature is really useful and has a reason.

What would be the handler value? Props of changed field? I tried, but I cant think of a single reasonable use case...

@Vidlec I think the interface can be like follows:
onChange = ({ nextValue, prevValue, fieldProps, fields, form }) => {}

So, it's completely the same as Field.onChange handler/callback.
The use cases for this feature may be as follows:

Developer wants to keep the form values in some sort of state (i.e. Redux store). Instead of hooking each onChange handler individually, it can hook once into Form.onChange handler.
Developer wants to flush the values of the fields into localStorage, or any other storage, upon any change. Again, just a shortcut which ensures no matter what fields are in the form, their change will always trigger Form.onChange handler.

There were another cases, but I can't recall them right now. I will update them here if I remember.
That's a good catch, thanks. We do need to prove its useful/useless.

Since this is a rather minor change to the code base, I have moved it to 1.x milestone.

After giving this proposal another thought, I think it would be a good example of over-engineering.

Having explicit onChange on field components is clear and easily maintainable
There is no scenarios that explicit onChange handlers on fields cannot handle

Closing this.


Add misc functionality

Coverage decreased (-0.2%) to 99.81% when pulling 6121618c900da44406138b38e0bf7bd5910d23bf on add-misc-functionality into d1b03f96f3cdea93c9e5cede69dde786e1fd7222 on master.

Coverage remained the same at 100.0% when pulling bf41e622986be8ec47b5d6a28ed814853ccee1f2 on add-misc-functionality into d1b03f96f3cdea93c9e5cede69dde786e1fd7222 on master.

params party
🎉 🎈 🎂

Coverage remained the same at 100.0% when pulling 88f52434f894f4d9da15905f6ab458a253ec43ac on add-misc-functionality into d1b03f96f3cdea93c9e5cede69dde786e1fd7222 on master.


Add Event Publisher in Incoming Document - OnBeforeCreateSalesHeaderFromIncomingDoc()

Hi there,
we need a new Event Publisher OnBeforeCreateSalesHeaderFromIncomingDoc() in Incoming Document:
        end;
        OnBeforeCreateSalesHeaderFromIncomingDoc(SalesHeader); // NEW
        SalesHeader.Insert(true);
        OnAfterCreateSalesHeaderFromIncomingDoc(SalesHeader);

    [IntegrationEvent(TRUE, false)]
    local procedure OnBeforeCreateSalesHeaderFromIncomingDoc(var SalesHeader: Record "Sales Header")
    begin
    end;

Thanks,
Carsten

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Demo site for ezPlus broken

Hi, your demo site at https://igorlino.github.io/elevatezoom-plus/examples.htm seems to be broken. For mit in FF dev.ed. and in Chrome.

@ParkerD13 thanks for informing , the linking of the libraries had to be changed from http to https. Now its all loading properly.
Press CTRL+F5 to reload the page while cleaning the cache.


remove bottom navigation bar from when it isn't map, rank-board, or camera

you're referring to android UI, not our own bottom nav correct?

If you saw the video I had shared, when you're in Settings, Player Profile--the bottom navigation is still there but I think in the UI Mock Ups, the bottom navigation is only on the Camera, Map, and Rank Board fragments


[Update] Domain status enum

updated domain status enum to only include active and disabled

@cschreep Hola! This should be ready for your review, though I do have one question for you--
Technically, it looks like the API code updates only get rid of setting the edit_mode status on the API and doesn't have any bearing on whether a domain with status of edit_mode could be read from the API, if that were to exist. Would you prefer it if we set edit_mode to read-only instead of getting rid of it? Or, because we're looking to phase it out in general, should we just stick to getting rid of it entirely?

@nmelehan the request for this change suggests that we don't want it at all anymore, so we should stick with getting rid of it entirely


Update CHANGELOG.md

Fix Dry.Struct constructor example

no, it's fine, both ::Struct( and .Struct( work


Use pants managed venv in Makefile

I don't intend to merge this. I want to use this to find any issues with the requirements pants is using and limit them appropriately. So, the changes to the Makefile are quite hacky.

The pants-managed venv does not have PyOpenSSL.

Apparently that was pulled in by requests[security] which was disabled in:

request 2.24 (https://github.com/psf/requests/pull/5443):

eww. I didn't realize that the urllib3 module was getting monkey patched with pyopenssl.

request 2.25 (https://github.com/psf/requests/pull/5867)

I don't know if that's related to the timeouts in the integration tests or not.


Only pass in inputs on first half of clock cycle

This is a pretty significant change. Conceptually, I realized this is "more correct" while implementing #358.
Why is this more correct? Well, let's talk about the times when what we currently have is incorrect: It's incorrect for one-cycle synthesis. Currently, if we're synthesizing a one-cycle operation, then we eval with inputs=inputs and clk=0, and we eval with inputs=inputs and clk=1, and then we use that last eval to formulate our synthesis query. But because inputs=inputs and not inputs=0 on the second eval, then the combinational paths will have inputs and not 0. So this means that the synthesis can choose to use the combinational paths, effectively bypassing the need to use the registers in the one-cycle case!
(note that we don't actually use 0 but symbolic values/havoc in the synthesis query and random values in the simulator)
This shouldn't be a problem for combinational cases or for >1 cycle cases.
Why is it correct to pass in the inputs only when clk=0, though? This is because the semantics of registers say that, when a register is at clk=1 and was previously at clk=0, they latch in the value from the previous timestep when clk=0. So effectively, the value at the current timestep does not matter. Thus, we never needed to be passing inputs at the clk=1 timestep!

See https://github.com/uwsampl/2024-asplos-lakeroad/issues/45 for the corresponding paper change that's needed..


[DNM:untested] update moby

Signed-off-by: Akihiro Suda<EMAIL_ADDRESS>

CI failure is due to https://github.com/rootless-containers/usernetes/issues/39


Guard against erroneously sized malloc/cu_malloc calls with sizeof(*name) where name is whatever you're calling the struct

In every new method (and cu_dev_new method) we do an allocation with malloc (and cu_malloc in cu_dev_new) which looks something like
name_of_struct *up = gkyl_malloc(sizeof(name_of_struct));
where name_of_struct is whatever that updaters struct is. For example,
gkyl_proj_maxwellian_on_basis *up = gkyl_malloc(sizeof(gkyl_proj_maxwellian_on_basis));
gkyl_hyper_dg *up = gkyl_malloc(sizeof(gkyl_hyper_dg));

etc., etc.
While this is not impacting anyone @ammarhakim pointed out to me recently there is a safer allocation call which is used in a number of places that looks like:
name_of_struct *up = gkyl_malloc(sizeof(*up));
This call is guaranteed to allocate a struct of size up and avoids potential size issues if for whatever reason a developer accidentally passes the wrong sized struct to the sizeof call (potentially possible depending on what headers are included and how close two different structs names are). If the developer makes a mistake in what type *up is, that will be caught at compile time because of things like the return in the new method, or trying to fill *up with something that is undefined for that struct.
Examples where we currently utilize this are:
gkyl_wave_prop *up = gkyl_malloc(sizeof(*up));
Along with this type of large-scale naming change, I think it would be worth standardizing the object in the new and cu_dev_new methods can be called up (or up_cu) to impose a consistent naming standard on new developers coming in and adding new objects. Advance methods can still take some variant of the name of the struct for clarity if we so choose, but within new methods I think it's reasonable (and it's also the current overwhelming standard) that new methods fill a struct of some type named "up"

The other reason to use this is that is avoids cut-paste errors. If you cut-paste and then change the struct on the left of the expression, but forget to do the same in the malloc, then you will end up with a serious memory problem. We should use this going forward unless there is a good reason not to. (There often are). But retrofitting old code will be very tedious and we do not need to do this.


jrnl: 2.7.1 -> 2.8

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for jrnl is: "A simple command line journal application that stores your journal in a plain text file"
meta.homepage for jrnl is: "http://maebert.github.io/jrnl/"
meta.changelog for jrnl is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/qm5ccg4ibij3gysxdfd3smvmnpb1xjpa-jrnl-2.8/bin/jrnl passed the binary check.

/nix/store/qm5ccg4ibij3gysxdfd3smvmnpb1xjpa-jrnl-2.8/bin/.jrnl-wrapped passed the binary check.

2 of 2 passed binary check by having a zero exit code.

2 of 2 passed binary check by having the new version present in output.

found 2.8 with grep in /nix/store/qm5ccg4ibij3gysxdfd3smvmnpb1xjpa-jrnl-2.8

found 2.8 in filename of file in /nix/store/qm5ccg4ibij3gysxdfd3smvmnpb1xjpa-jrnl-2.8

directory tree listing: https://gist.github.com/ac87a9f9442fb84bf59a952e1eb30072

du listing: https://gist.github.com/0889fc05342789a593aeeb755b0b39f7

Rebuild report (if merged into master) (click to expand)

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
jrnl

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/qm5ccg4ibij3gysxdfd3smvmnpb1xjpa-jrnl-2.8 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A jrnl https://github.com/r-ryantm/nixpkgs/archive/befed014cd58b854b618ef081a4db6aabcbe2e92.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/qm5ccg4ibij3gysxdfd3smvmnpb1xjpa-jrnl-2.8
ls -la /nix/store/qm5ccg4ibij3gysxdfd3smvmnpb1xjpa-jrnl-2.8/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

jrnl

Maintainer pings
cc @umazalakain for testing.

Result of nixpkgs-review pr 117994 run on x86_64-linux 1

1 package built:

jrnl


Honey bottle

Can't be done honey bottle.
There is a task for which you need: honey bottle.
But you can't make a bottle.
You need sand(glass) to make a bottle.
Sand you can get only through chrushing wheel.
To do chrushing wheel necessary: mechanical creafter.
To do mechanical creafter necessary: electron tube
To do electron tube necessary: polished roza quartz
To do polished roza quartz necessary: sand paper
Which is crafted from sand
Offers

Add craft sand through milstone or
Break gravel with a shovel + shift

Also
Add the relevant achievement (For the extraction of glass (+ signature: "sand can be extracted..."))
(written with the help of a translator, the translation may not be correct)

Fish a water bottle.

I also just added a tip in the advancements (will be included in the next release).

I also just added a tip in the advancements (will be included in the next release).

Thank you, sorry for the wasted time.

It wasn't completely wasted. You just brought me to call this in the advancements. The two "wasted time" issues shouldn't make you stop asking questions either. After all, I know where there are problems of understanding.
PS: I actually pondered for a long time when creating the modpack how to do this with the glass bottles without making a lot of resources useless. (Sand washing -> clay balls -> copper; Red Sand washing -> gold.) The fact that you can also simply fish for the bottles made things a lot easier for me.


Add remote repository branch protection

Prior to merging #13, we should consider adding a protected branch to main to avoid accidental commits.

Depending on our development workflow, it might be best keep dev for project testing and feature additions.

Resolved!


[REG master] Issue14817 std.algorithm.copy/std.file.copy conflict

Reboot of #3509 now with a unittest.

Auto-merge toggled on

Auto-merge toggled off

LGTM

Merge anyone?

Auto-merge toggled on


Added the needed cmd to run the app at localhost:3000

The npm run dev cmd is not enough to run the dev server

Thanks for this PR! remix dev is enough if you use the Remix App Server as instructed in tutorial. If you pick anything else you need to check the README :)


Composed build seems to be stuck

The following job has been running for 50mins now on the DTK and it looks like it'll time out: https://gitlab.com/finestructure/swiftpackageindex-builder/-/jobs/680473477
Running it locally with the same parameters (but on intel), shows the following:
❯ ./builder checkout -c https://github.com/thread/Composed.git -r 1.0.33 -f
Clone URL: https://github.com/thread/Composed.git
Reference: 1.0.33
Cloned https://github.com/thread/Composed.git into ./checkout
~/P/ssas/Projects/spi-builder on  main took 3s ▹ fish
❯ ./builder build -p checkout/ --platform macos-xcodebuild --swift-version 5.3
Selected platform:         macosXcodebuild
Swift version:             v5_3
Building package at path:  checkout/
Running build ...
env DEVELOPER_DIR="/Applications/Xcode_12_beta_4.app" xcrun xcodebuild -IDEClonedSourcePackagesDirPathOverride="$PWD/.dependencies" -derivedDataPath "$PWD/.derivedData" build -scheme "Composed" -destination "generic/platform=macos"
Error: ShellOut encountered an error
Status code: 65
Message: "** BUILD FAILED **
"
Output: "Command line invocation:
    /Applications/Xcode_12_beta_4.app/Contents/Developer/usr/bin/xcodebuild -IDEClonedSourcePackagesDirPathOverride=/Users/sas/Projects/spi-builder/checkout/.dependencies -derivedDataPath /Users/sas/Projects/spi-builder/checkout/.derivedData build -scheme Composed -destination generic/platform=macos

User defaults from command line:
    IDEClonedSourcePackagesDirPathOverride = /Users/sas/Projects/spi-builder/checkout/.dependencies
    IDEDerivedDataPathOverride = /Users/sas/Projects/spi-builder/checkout/.derivedData

note: Using new build system
note: Building targets in parallel
note: Planning build
note: Constructing build description
error: No signing certificate "Mac Development" found: No "Mac Development" signing certificate matching team ID "XD2B49EJ3F" with a private key was found. (in target 'Composed' from project 'Composed')
"

I looks like this is a genuine failure case but one that we're not capturing.
Also, this is a case where it would help if we streamed the logs.

I've checked that the DTK isn't stuck on some popup prompt or alert. There is nothing.

We're actually correctly reporting this up in general: https://swiftpackageindex.com/builds/173C14FC-483A-4B48-9834-0B3EBB99EB2B

I think it's just that particular job that got stuck. I should get cleared and retried automatically.

Just noticed that we were down to 6 runners and the problem was an ARM backlog.
Looking at the jobs I noticed another one that seems to be stuck: https://gitlab.com/finestructure/swiftpackageindex-builder/-/jobs/682294428
It's hard to tell what it's doing without log streaming but I don't want to interrupt it. However, the problem with only 2 concurrency was that we seem to have gotten stuck on a couple of these hour long jobs that time out. While they were sitting there, we build up a huge ARM backlog which lead to the regular jobs running down their queues.
Not a huge problem, just a little lost capacity.
Will need to check what's going on with this.
I've bumped concurrency on the DTK to 4 to see if that helps with the backlog. We seem to be doing ok cpu wise:

(Does iStat Menus run on ARM?)

More timeouts (I've reduced it to 30mins to shorten the time the queue is blocked):

https://gitlab.com/finestructure/swiftpackageindex-builder/-/jobs/682964837
https://gitlab.com/finestructure/swiftpackageindex-builder/-/jobs/682964851
https://gitlab.com/finestructure/swiftpackageindex-builder/-/jobs/682982700

The load on the DTK is fine and these are different packages. Are they really all taking this long or is something up with ARM builds?
I did notice that on my intel MBP sometimes builds with 12b3 takes very long when run via our build mechanism. I wonder if there's something specific to 12b4 that's causing builds to stall.
Need to do some testing on this.

(Does iStat Menus run on ARM?)

I spoke to Marc about this and they don't have an ARM build ready, but he said the regular Intel build works fine. 👍

I've reduced job timeout even further (10m for ARM atm, 30m for Linux) to ensure the main platform builds aren't held up by ARM and/or potentially Linux queues.
The purpose here is to make jobs that will time out anyway timeout faster. There may be legitimate build times of 15m or longer but we can get to these later by lifting the limit after we're done with the backlog. The problem isn't the long build times per se, it's just that they lead to a backlog in a particular queue that then runs up against the 300 job limit, with all 300 jobs arm jobs serviced by a frequently stalling worker. The same can happen for Linux, or just a combination of the two to pile up to 300.
I've also considered shortening the garbage collection time for pending queues but realised that this will do no good unless we also cancel those jobs. Best leave this be for now so we don't change too many things at a time and/or introduce more churn as we enqueue and delete jobs.

I'm going to go ahead and close this one. We've seen similar hangs across all builders now and it doesn't seem particular to ARM. In any case, the particular builds weren't the issue. They've finished at other times and so it's not a reproducible error. I don't think there's anything in particular we can do here at this time.


Font-Family: Arial is causing a white border-bottom on Outlook 2016

To help us help you, provide as much information as you can. You'll find below a template you can use to submit your issue, but feel free to remove any part that wouldn't be relevant here.
[Short description of problem here]
I have created a basic email in MJML which is using font-family=" 'Century Gothic', CenturyGothic, AppleGothic, Helvetica " for everything in my email from the  to  and  and it looks absolutely wonderful. I was asked by my Account Manager to change the font to Arial for everything in the email (which I did very carefully and simply) and all of a sudden there is a thin while line appearing at the bottom of my  in the header  of my email. The original font-family=" 'Century Gothic', CenturyGothic, AppleGothic, Helvetica " does not cause this problem as soon as I go back to using this. The issue only occurs when changing to font-family="Arial". I have looked at the HTML of both versions and they appear to be exactly the same the besides the font-family attribute change. I am using Pardot to send out these emails to the Outlook 16 client.
Reproduction Steps:

[First Step]
Change:
body {
font-family: 'Century Gothic', CenturyGothic, AppleGothic, Helvetica;
}

to
body {
font-family: Arial;
}

[Second Step]
Change:

to

[Other Steps...]
Change for both  elements:

to

Expected behavior:
[Describe expected behavior here]
The expected behavior should match the screenshot here: https://ibb.co/edoOwJ
Observed behavior:
[Describe observed behavior here]
The observed behavior is showing a thin white line under my  in the header  here: https://ibb.co/mw5giy
Screenshots and GIFs

Here is the live MJML editor with the correct behavior on Outlook 16 and font-family="'Century Gothic', CenturyGothic, AppleGothic, Helvetica": https://mjml.io/try-it-live/SkDwTff0z
Here is the live MJML editor with the incorrect behavior on Outlook 16 and font-family="Arial": https://mjml.io/try-it-live/rJGXZmf0G
MJML version:
[Enter MJML version here]
Using "MJML App v2.8.0" which is using "MJML v^4.0.3" https://ibb.co/dEHK3y
Email clients the bug is seen on:
[Enter email clients names and versions here]
The bug is being seen on Desktop Outlook 16 using a Windows 10 machine.
I am using Pardot to send out these emails to the Outlook 16 client.

@qunvar-arora Hi, outlook has some issues with calculating heights, this kind of white lines can have multiple causes.
The color of the line only depends on the  background, so it can't be fixed by wrapping your element inside of another element with the desired color as background.
I found a few workarounds that solve your problem, but you'll need to edit the html output :

If you manually set the height of the mj-column's   that is in the outlook conditional, it renders fine
On the  containing "Digital Health" that has font-size:26px, if you add mso-ansi-font-size: 27px; to the inline-style, it renders fine
If you don't set vertical-align: bottom on the column, you don't get the white line.

Unfortunately all this values are situation-specific (i.e. here if you set font-size to 27px, then it renders fine without mso-ansi-font-size, and adding mso-ansi-font-size: 28px will bring back the white line...). Therefore these workarounds can't be adapted into a generic fix in mjml, so i'll close this one for now.


numberOfAttempts should be on state not options

From @Stevenic
I just noticed that we added a numberOfAttempts property to the PromptOptions structure. This shouldn’t be on the PromptOptions structure. This should have been added to the prompt state, not the options. In general the incoming options for a prompt should be immutable.
/**

Basic configuration options supported by all prompts.
/
export interface PromptOptions {
/*

(Optional) Initial prompt to send the user.
*/
prompt?: string | Partial;

/**

(Optional) Retry prompt to send the user.
*/
retryPrompt?: string | Partial;

/**

(Optional) List of choices associated with the prompt.
*/
choices?: (string | Choice)[];

/**

(Optional) Property that can be used to override or set the value of ChoicePrompt.Style
when the prompt is executed using DialogContext.prompt.
*/
style?: ListStyle

/**

(Optional) Additional validation rules to pass the prompts validator routine.
*/
validations?: object;

/

(Optional) Count of the number of times the prompt has retried.
/
numberOfAttempts?: number;*
}

This is a new feature and we should get it right. Making this P0 for 4.4.


README: Update compiler version

Since CI uses g++ version 7.4.0, that's the only version we can guarantee the code compiles with --- we should update the requirements listed in the README accordingly.
In particular, it turns out the -Wshadow=local flag that I added to .bazelrc is only available starting in GCC 7.
Unfortunately, Cilk support is also deprecated in GCC 7, and is removed entirely in Cilk GCC 8. An alternative path forward would be to just remove -Wshadow=local (ideally we would replace it with the much older flag -Wshadow, but our codebase contains too many instances of shadowing right now) and force Travis to use whatever g++ version is ideal for us.

Long term we should deprecate the dependence on GCC for cilk and switch to using the llvm-based cilk provided from http://cilk.mit.edu/). We should coordinate with TB and others, since a good outcome of that work would be to have our benchmarks used as part of the Tapir/Cilk benchmarks for their performance profiling and testing.


Allow disabling the nRF5340 network CPU by protocol drivers

Changes introduced in https://github.com/zephyrproject-rtos/zephyr/pull/71337 caused radio protocol drivers to be unable to turn off the network CPU in longer periods of inactivity. This PR attempts to fix that while keeping the sharing mechanism in place and functional.

Just curious, why is there separate code for each board instead of having this shared in SoC under a Kconfig?

@masz no idea, I agree it would be cleaner to avoid all this duplication. I don't want to rework it in this PR though to keep its scope small and get it merged faster.


Show test errors in full.

It would be cool to see the first error in full. This helps fixing the first bug faster.
Before

After

Scene
(not sure this one helps)

Hi @clemens-tolboom thanks for supporting the project ;)
Please always create a bug/improvement suggestion first and then link it to the pull request.
This will help me to organize the task, and keep track of it.
Thanks a lot


bm25_refresh fails

Hey, thanks for creating this extension!
I am currently in the process of setting this up for BM25, and ran into this issue when trying to execute bm25_refresh:
devdb: public, bm_catalog> SELECT bm25_refresh('publication_abstract_bm25')
[2024-06-29 14:20:33] [42P01] ERROR: relation "bm_catalog.bm25" does not exist
[2024-06-29 14:20:33] Where: PL/pgSQL function bm25_refresh(regclass) line 9 at SQL statement
I believe bm_catalog.bm25 in the following line should be bm_catalog.pg_bm25 instead.
https://github.com/tensorchord/pg_bestmatch.rs/blob/419aadf10bc54c59d5712e96de0f9d987b410f5b/src/sql/finalize.sql#L76

Thanks for catching the bug! Would you like to submit a PR for this?


Issue #207 - network rm (via API & UI) must fail for reserved networks

-Fail network deletes for bridge, none and host.
-Gist w/ CLI validation: https://gist.github.com/f2667c3bd8a0392b447e
Signed-off-by: Brent Salisbury<EMAIL_ADDRESS>

@nerdalert can you please rework the code as per the comments?

Closing this in favor of : https://github.com/docker/libnetwork/pull/252


Update README.md

Could you read through the README.md and correct any mistakes?

@dzx11 would you like to pick this up?


Investigate use of map:put($namespace) in init-intance

@kcoleman-marklogic has noticed that namespace information is added to an instance in two places, both in es:init-instance and in extract-instance-X.
The first place gets namespace information from scraping the source document.
In the second its asserted from the model.  The first situation seems wrong to me -- without namespaces information in the model, canonical instances should be written to no namespace regardless of the input XPath and namespaces.

I investigated the two places where namespace information is added.
The use of namespaces in init-instance is currently required for resolving references.  But my hunch remains -- this does not look like the right source for namespace information, but rather might point to having fixed the 'issue' in the wrong place.

I now consider this a more serious issue, which would be great to get fixed.  It's an edge case, but if I address it then the 9.0-3 support for namespaces will be better.  I'm closing in on a good fix but it's a slight API change, so I need to make sure that we're OK with it all around.
The issue is that the method for getting namespace info in init-instance is faulty.  It works for the happy-path extraction. but in some circumstances will result in buggy canonical forms.  I'll include more information in this bug later this evening.
The fix is to have generated code functions pass namespace information to es:init-instance, and to remove the map:with functions from extraction functions.  That solution will make extraction functions cleaner with regard to namespaces, but is a change to the public API at a late point.
Setting to fix.  I'll be aspirational and hope we can get it in.

OK, I've got a fix.  It doesn't look as disruptive as I expected.  I think it's important to go in and I'll circulate for review.

In PR, assigning to you @bsrikan .

Functional tests have been updated thanks to @grechaw, to reflect latest code change for use of namespaces in init-instance. All green. OK to ship.


[Bug] The new version 0.1.32 try find a non-existing file by running the resolve the pdf.js

Describe the bug
That happens after upgrading to 0.1.32, it seems there are some incapable issues for node 20
It seems the package is trying to find a non-existing file by running the resolve the pdf.js
node_modules\pdfjs-dist\legacy\build\pdf doesn't exist
node_modules\pdfjs-dist\legacy\build\pdf.js doesn't exist
node_modules\pdfjs-dist\legacy\build\pdf.ts doesn't exist

To Reproduce
Steps to reproduce the behavior:

Go to terminal
Run the npm build with the package update to 0.1.32
Invoke error and build fail
See error

Expected behavior
Build without any error
Screenshots

Desktop (please complete the following information):

OS: Windows
Browser VSCode
Node Version v20.16.0
Package Version 0.1.32

Please try this with v0.2.0 of this package, which removes the dependency on node-specific libs, including path.

What's a great news!

@whats2000 please close this issue if this has been resolved for you


Private type on public interface makes it hard to mock out the response

The following List endpoint returns a type that is not made public making it difficult to make an interface for this method.
https://github.com/Metronome-Industries/metronome-go/blob/70b3a862ea59fd36d768932f55b33c7befeebbcc/customerinvoice.go#L59

Hi @aliotta,
Could you clarify what type is causing issues for you? Both pagination.CursorPage and Invoice seem to be public as far as I can tell.

Ah, you're perfectly right, pagination is under internal. That's definitely problematic. Thank you for the report, we are looking into it.


YAML files not verified?

I'm validating SPDX files produced by Black Duck, which are JSON and (allegedly) SPDX 2.2. When I upload said files to the online validator as JSON file, I get various warnings (the warnings depend on the file contents). If, however, YAML is selected as the upload format, the file supposedly validates okay - even though it's a JSON file, not a YAML file.

@stephenkilbaneadi This is due to the JSON format has an associated schema file which can provide additional validation which is likely where the warnings are coming from.

BTW - there is validation for SPDX elements for YAML but this is done after the YAML file is parsed - kind of a logical model validation vs. a file syntax and structure validation that occurs with the schema validation.

I'm not following. If I say I'm uploading a YAML file, but upload a JSON file instead, are you saying it manages to detect that it's a JSON file anyway and parses it okay, but doesn't retrieve the associated schema file, hence no warnings? Whereas if I upload the sam JSON file, but say it's JSON rather than YAML, then the associated schema file is used, hence warnings?
Honestly, I'd just expect an error like "This doesn't look like a YAML file"...

@stephenkilbaneadi Ahh - Yes - this would be an issue with the tools - I guess I didn't read your description very carefully this morning.
I'll take a look and see if I can find a fix.

I found the source of the issue, but this may be a challenge to fix.
The JSON schema is validated based on the serialization format specified on the verification command: https://github.com/spdx/tools-java/blob/b949e88a2fb900b120f1f915d839dd022c134072/src/main/java/org/spdx/tools/Verify.java#L142
It looks like you can pass a JSON stream to the  Jackson YAML factory and it will process it as JSON.
I could not find a way to tell if the YAML factory found a JSON file.
I'm actually quite surprised the parsing succeeded since it is not a valid YAML stream.
To fix this, we could inspect the file to see if it is JSON even though YAML was input as the format.
@stephenkilbaneadi Do you think this would be a common issue?

Or, to put it another way: I opened a bug with Synopsys because their SPDX output was producing warnings when validated; they've argued that this is a problem with the validator because "look no problems if you select YAML as input type..." I believe I should be going back to Synopsys and saying "Yes, there's a problem with the validator, but the problematic case is when the warnings aren't emitted, and there are generation issues that Synopsys still need to address."

I'm still unclear whether the validation is actually happening, in this case and, if so, whether it's correct that no warnings are emitted, despite such warnings being emitted when the type is correctly identified as JSON. It does seem to be an edge case that provides a rich vein of confusion. :-(

There are 2 types of validations that occur:

Full model validation
Schema validate

The full model validation (1) is accomplished by examining every property in the SPDX document and checking it against the rules in the spec (e.g. cardinality, format, exclusions).  This is done for all file types.  So, for YAML - yes, it is validated.
The schema validation is only done when the format supports a schema.  JSON supports a schema file whereas YAML does not.  So, YAML does not do any schema validation.  Although schema validation isn't as complete as the full model validation, it does find issue in the specific serialized file that may not show up in the model validation due to the parsers masking the issues.
All of the tools are open source, so if you need more information I can point you to the specific code that does the validation.
The short answer is - yes - validation does work with YAML files.

Is it possible to simply check the MIME type of the submitted file against the declared file type, or does the serialisation make that problematic?

Typically the MIME type is determined by the file extension.  We could check for file type .json but we would want to somehow cover for the possibility the file really is YAML as the user specified.
One approach I thought about was to read the first couple of lines and see if it "looks like" YAML or JSON.  I though that approach was a bit kludgy and may make the code a bit harder to maintain.  But if we think this is a significant issue, it may be worth the trouble.

I opened a bug with Synopsys because their SPDX output was producing warnings when validated; they've argued that this is a problem with the validator because "look no problems if you select YAML as input type..." I believe I should be going back to Synopsys and saying "Yes, there's a problem with the validator, but the problematic case is when the warnings aren't emitted, and there are generation issues that Synopsys still need to address."

@stephenkilbaneadi I agree with your point of view on this.
You can point the Synopsys team to the JSON schema in the spec.  You can run an online schema validator (e.g. the Newtonsoft validator) to see if there are errors in the generated file.  This is a validation completely independent of the online tools.
Note - it is possible that there is an issue with the schema, but I would suggest the Synopsys team evaluate the errors and if they believe the schema is in error they should open up an issue against the spec.
Hope that helps.

@goneall I have validated a number of SPDX SBOMs in Json format, produced by Black Duck in Newtonsoft validator, using the exact  JSON schema in the spec you've referenced, and they all were validated successfully. So it does not look like the Json schema produced by BlackDuck is corrupt

@strashila Thanks for doing the research on this.  If you could attach an SBOM that shows the validation error, I can look into it a bit further.

@goneall I'm attaching a few test SBOMs, which all validate against the schema. That said, the SBOMs also now validate against the tool https://tools.spdx.org/app/validate/ , which was not the case before. I was able to recreate the issue with BlackDuck SBOM not validating successfully with the tool when File Type is JSON a week ago, but can't do it now for some reason, and now the validation seems to be working.
strashila_python_cicd_tests-buildless-1.16_SPDX_22_2022-11-21_085803.zip
alex-mvn-tests-3.0_SPDX_22_2022-11-21_090417.zip

That said, the SBOMs also now validate against the tool https://tools.spdx.org/app/validate/ , which was not the case before.

@strashila The online tools were recently updated, so the previous validation errors may have been an issue with the online tools which has been fixed.

@goneall thank you for checking. @stephenkilbaneadi this issue may have been resolved, I successfully verified a number of BlackDuck SPDX json files as JSON File Type with the online tool

@strashila @stephenkilbaneadi - shall we close this issue?

@goneall Ok with me

Closing per the above comments


Support client-rendered pages

It'd be cool if new-work supported sites rendered on the client-side. I tried to add Dan Holdsworth's site to my list, but since it's rendered on the client with Angular, newwork can't detect any changes.
Some ideas on ways to handle this:

Execute the client scripts before fetching the URL (I imagine this could get pretty messy)
Allow defining a "source" URL that's different from the site URL. His site uses a JSON API to fetch the content (this won't work for every client-rendered site)

Yep, this is definitely on the list. As you say, the easiest way to do this would be to allow an alternate source URL (overlap with #2 actually). Alternatively, I've been trying to wait for headless Chrome libraries to mature a bit so that we can scrape HTML after waiting for the page to render clientside (however, this will slow down scraping significantly).


df_parser parent_env unit tests

unit tests for #584

Coverage increased (+0.02%) to 89.968% when pulling 84f0808f1f4fbab3a142d82efc461f33666b8b08 on rcerven:correct_parents_inherited_label into d0116e57b0fbc733b69db30423d5966cf7ba790e on projectatomic:master.

Coverage increased (+0.1%) to 90.09% when pulling 6859e81a3858de38f49043a54c49588440cf2ddd on rcerven:correct_parents_inherited_label into d0116e57b0fbc733b69db30423d5966cf7ba790e on projectatomic:master.

Coverage increased (+0.2%) to 90.139% when pulling bf4c7980a8e7bf9d2298bee9374af84d6ea8b160 on rcerven:correct_parents_inherited_label into d0116e57b0fbc733b69db30423d5966cf7ba790e on projectatomic:master.

Coverage increased (+0.3%) to 90.142% when pulling 8f6001a58e6789e2d4e9e87cd952cb1903e041e7 on rcerven:correct_parents_inherited_label into cb2eb3f15305ca7d28110a7aceee3fe5f2b9be05 on projectatomic:master.

Code added in https://github.com/projectatomic/atomic-reactor/pull/586

Coverage increased (+0.3%) to 90.064% when pulling 6ce1acf63202f777209d639d87ae8149066b8816 on rcerven:correct_parents_inherited_label into 97928c9b0b4c899229431317a6686ef6ad2830cb on projectatomic:master.

Coverage increased (+0.3%) to 90.064% when pulling 6ce1acf63202f777209d639d87ae8149066b8816 on rcerven:correct_parents_inherited_label into 97928c9b0b4c899229431317a6686ef6ad2830cb on projectatomic:master.


Azbot bot show command with --msbot fails

Tool
Name: AZ BOT
Version: AZ CLI: 2.0.46; botservice: 0.4.1
OS: os version
Describe the bug
AZ bot show command optionally accepts a --msbot argument that can spit out the ABS configuration in a format that can be consumed by msbot.
az bot show --msbot fails ..
> az bot show -n cafebottest -g testCafeBot --msbot
The behavior of this command has been altered by the following extension: botservice
list index out of range
Traceback (most recent call last):
  File "C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\Lib\site-packages\knack\cli.py", line 197, in invoke
    cmd_result = self.invocation.execute(args)
  File "C:\Users\trdai\AppData\Local\Temp\pip-install-6nyhv9qe\azure-cli-core\azure\cli\core\commands\__init__.py", line 369, in execute
  File "C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\Lib\site-packages\six.py", line 693, in reraise
    raise value
  File "C:\Users\trdai\AppData\Local\Temp\pip-install-6nyhv9qe\azure-cli-core\azure\cli\core\commands\__init__.py", line 343, in execute
  File "C:\Users\trdai\AppData\Local\Temp\pip-install-6nyhv9qe\azure-cli-core\azure\cli\core\commands\__init__.py", line 182, in __call__
  File "C:\Users\trdai\AppData\Local\Temp\pip-install-6nyhv9qe\azure-cli-core\azure\cli\core\__init__.py", line 436, in default_command_handler
  File "C:\Users\vkannan\.azure\cliextensions\botservice\azext_bot\custom.py", line 225, in get_bot
    return create_bot_json(cmd, client, resource_group_name, resource_name, raw_bot_properties=raw_bot_properties)
  File "C:\Users\vkannan\.azure\cliextensions\botservice\azext_bot\custom.py", line 115, in create_bot_json
    app_password = [item['value'] for item in app_settings if item['name'] == 'MicrosoftAppPassword'][0]
IndexError: list index out of range

To Reproduce
Steps to reproduce the behavior:

Install the latest AZ CLI and botservice extension
az login
try az bot show with --msbot option for one of your bots

Expected behavior
AZ bot show works with --msbot option.
[bug]

We are targeting this one for a fix on 11/26 to be released 12/4

@vishwacsena, @carlosscastro, is this supposed to retrieve the MSA App password as well? Or is it expected that the user will go to apps.dev.microsoft.com to get/generate a password?
The bug here stems from that create_bot_json() does not receive the app_password arg so it attempts to retrieve it from the Web App's settings. This raises a problem for v4 bots (haven't tested yet with v3, but it should work just fine) because the password doesn't exist there, it now exists in the .bot file.
If  az bot show --msbot true should get the password as well, then there we can code for several cases:

There exists a bot file with the same name as the bot
A singular bot file exists, the name does not match the bot
Multiple bot files exist, the name does not match the bot

We need to read the appsettings for bot file path, use the botFileSecret to decrypt it (if encrypted) using the bot Framework configuration library and pick the app Secret from that bot file.

Observing this, it seems like the most correct thing to do would be to implement the botframework-config library in Python.
@carlosscastro, I know you're busy but we should discuss this item tonight/tomorrow.

@vishwacsena is there an "easy and viable" path for using az bot show --msbot true on a registration bot?
Otherwise we have a couple of paths to evaluate:

Have them do the OAuth path for https://apps.dev.microsoft.com and then attempt to create a new password for them on their behalf

IIRC, a MSA App can only have two AppPws, if attempting to create a third AppPw this will fail

Fail fast and have them manually go to https://apps.dev.microsoft.com to get their MSA AppId and a new AppPw

In this case we could output a partial IEndpointService entry for their .bot file.

We could do the partial IEndpointService entry for the first path as well in the case of failure.

@stevengum the original bug from Vishwac was not implemented in az, we added this method last week and it seemed to work well.
The password part is a new requirement and I think we are a bit late, let's discuss today.

In registration bots we retrieve the password at creation time. In all cases including registration, we could get the password from the web app settings which we can query from az. Tom queries web app settings during msbot clone as well.

Moved to 4.3 per conversation with Scott.

Closed via Azure/Azure-cli#8035.


Fix parser regression for bad related diagnostic on missing matching brackets

The parser expects the keywords if, do,  while, and with to be followed by pairs of braces({, }) or parentheses ((,)).
It was also attempting to unconditionally add a related diagnostic for missing closing brackets to the diagnostics for missing opening brackets. When the opening bracket did not exist, this typically meant that diagnostic span was being added beyond the EOF.
Here we avoid associating the missing closing bracket diagnostic with the opening bracket diagnostic if we fail to parse the former. The errors resulting from the regression broke smart indentation on the keywords, thus the indentation tests in this change. We don't have the same concern about parseExpectedMatchingBrackets with array and object literals since their parsings are triggered by their opening braces.
Regressed by #40884

I'll admit up front that I don't fully understand the chain of events that led from the parser error to smart indentation breaking. While debugging I was seeing Debug.assert(!incrementalSourceFile.hasBeenIncrementallyParsed); in parser.ts throw when the getIndentation command ran derailing it along with a handful of other language service command my editor was firing at the time. I assume that the bad diagnostic dirtied up something somewhere else in the parser and getting us into a bad state .-.

While debugging I was seeing Debug.assert(!incrementalSourceFile.hasBeenIncrementallyParsed); in parser.ts throw when the getIndentation command ran, derailing it along with a handful of other language service command my editor was firing at the time. I assume that the bad diagnostic dirtied up something somewhere else in the parser and getting us into a bad state .-.

!!!
I would strongly urge a revert on the commit for 4.3.


Syntax error when running elasticdump

When I try to run elasticdump --help, I'm getting the following syntax error:

elasticdump --help

Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.
elasticdump.js(16, 30) Microsoft JScript compilation error: Syntax error

ElasticDump version - 3.3.14
ElasticSearch version - 5.6.3
Node.js version - 10.3.0

You need an actual shell 🐚, to run elasticdump on Windows. Git for Windows is packaged with bash, but cmd isn’t supported.


Sublime Text 4 palette

Haxe commands in Sublime Text 4 palette are missing, look up this forum discussion
https://forum.sublimetext.com/t/upgrade-st4-from-st3-missing-palette-options/57901/8?u=lbones

Ok :shrug:


Fix Hash index split slot ID when reserving a number of slots which are a power of two

E.g.
When reserving 64 slots, numSlotsOfCurrentLevel will be 32 instead of 64, and the nextSplitSlotId will be 32, instead of 0.
This shouldn't cause any issues, but the behaviour wasn't what I was expecting and it does some unnecessary work.

Since the levelHashMask is 31, all slots calculated using it will be less than the nextSplitSlotId (in getPrimarySlotIdForHash) and use the higherLevelHashMask (which is the same if we had instead increased the level by one and reset nextSplitSlotId to 0).
The first time splitSlot is called it will split slot 32, but entries used the higherLevelHashMask when inserting into it originally,  so all the entries get hashed back into the same slot, and then the level will be incremented and nextSplitSlotId will be reset to 0.

(Also added a missing include that's necessary with newer versions of gcc because <string> no longer implicitly includes it)

Nice catch on this!


fix: issue form error

Describe the bug

Under GSSoC'23.

I will further improve things as per standard conventions.
Expected behaviour

It will be shown while creating a new issue.

Screenshots
No response
Additional context
No response
Code of Conduct

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

assigning this to you


MSYS/Cygwin paths are not supported as terminal links

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.90.0
OS Version: Windows 10

Steps to Reproduce:
When I compile with MSYS on the terminal, paths in warnings/errors are shown in MSYS/Cygwin style: [/cygdrive]/d/Projects/test/foo.cpp:123. Ctrl-clicking it opens the Quick open edit with the path, then I have to edit it, remove the leading slash, add a colon after the drive letter and press Enter.
Created PR #214435 to handle that, but it was rejected because the change was in a central component (path.ts), and was too risky.

/cygdrive/ is not a stable prefix. It could be anything, down to bare /.
If you want a stable prefix, there's /proc/cygdrive/, but it's nearly useless for the intended purpose of parsing terminal links. You would simply never encounter this form in the wild.

Yes, I know, but it's the default mount for cygwin, so most users just have it as it is. For MSYS it's /, and my plan is to support both / and /cygdrive/. It can be extended in the future to discover the mount and translate accordingly, but that's really niche.

"Most users" !== "usable default".
You have to, either, make it configurable (a can of worms in itself), or run each path through cygpath (super slow), or, being a good guest, produce file: links relative to the project root. VS Code will pick them up, no issue.

(Also, if I would be coding such a translator, I would not check for just /cygdrive/, but for /<prefix/>[a..z]/.)

run each path through cygpath (super slow)

If you only have to resolve the path when clicked, there's no performance issue.
The difficulty seems to be to find out which cygpath program to run, if the user had multiple cygwin/msys/git-bash installations.

If the user has multiple installations, it's up to the user to provide a path to the correct executable.


Revocation of the invite link

Kukks pointed out that when a user is invited, there may be a situation where store owner would want to revoke their access (eg, invited by mistake).
Open questions:

User can just be removed from the store (mentioned by @dennisreimann )
Don't we have expiration time for invite links?

conceptual ACK

If the invite code has been used, but then revoked, we'd just remove the user and log them out on state refresh?
I'd think a 24hour to 72hour (for the weekend, employee invited on a friday, working on monday?) expiration for an invite link would work?

If the invite code has been used, but then revoked, we'd just remove the user and log them out on state refresh?

Nope, once the invitation is accepted it's done and at that point and the user would have to get removed the regular way — same as without any invite.

I'd think a 24hour to 72hour (for the weekend, employee invited on a friday, working on monday?) expiration for an invite link would work?

We';ve settled on an expiry of seven days and I think that's fine to handle these cases.

Ahh I see, it's not a persistent invite, but a one-and-done.
All sounds good, just making sure I understand the mechanics for testing!

Agreed.
Side thought - would it make sense to simply call the CTA Cancel in the Pending Invite case? Does the same thing (removal), but different CTA label?

There is no canceling of the invitation at that point, because that would basically mean to remove the user as well (they could not register or sign in, so it doesn't make much sense to keep the user record).


Add system-monitoring-center

https://github.com/hakandundar34coding/system-monitoring-center/

Duplicate of #67


Links to summon is broken in README

Summon is now hosted at

https://cyberark.github.io/summon (docs)
https://github.com/cyberark/summon (repo)

@dustinmm80 this will be fixed in: https://github.com/lookout/summon-cerberus/pull/8/files

Thanks very much!

@rohitasva can you close this issue?


Add PartialEq and PartialOrd unit tests to Literal

https://github.com/gluesql/gluesql/blob/23e0e875f307cf5d8187e70eac1a3765d6a3ea5e/src/data/literal.rs#L68-L103
There is no unit test for PartialEq and PartialOrd impl in Literal.
Let's add it :)

ref. https://github.com/gluesql/gluesql/pull/332


Add CC specific utility functions

Adds utility functions to get ccSpecific enums

I can't increase test coverage without creating fake values. All the code paths that aren't tested are related to error handling. Practically speaking we should never reach them

I was able to test one of the failure scenarios since we have the fixture data, but can't get any further than that.

@MartinHjelmare what more do we need to do on this PR to get it closed? I'd like to get this merged so I can release a new version and prepare core for the update, and then also spend more time working on the entity description PR since it's a better implementation vs our current approach

Update: decided it was OK to create fake values with known bad meterType and scale values. Even if it's not a real life scenario, it validates that we will raise an exception if such an issue occurs


Add ability to hide keys from inline fields on rendering.

Hello.
It would be neat to add a syntax to hide the keys form inline fields on rendering.
Desired rendering:

Ideas of source:
The cat ({scientific_name::[[Felis catus]]}) is a domestic species of small {order::[[Carnivora|carnivorous]]} {class::[[Mammalia|mammal]]}.

or
The cat (%%scientific_name::%%[[Felis catus]]) is a domestic species of small %%order::%%[[Carnivora|carnivorous]] %%class::%%[[Mammalia|mammal]].

(The second example is already rendered as desired, but the inline fields do nothing).

In Obs 0.14.5 with DV 0.5.4:

I've tried to do this with a little html and CSS, but the fields don't work when wrapped in html tags. For example:
<span class="hide-dv-field">Summary:: </span>
.hide-dv-field {display:none;}
I'd love to hid the field on my page, but still have it available for queries.

One of the two styles () vs [] hide the keys iirc. Can you try and let us know?

(Summary::) test ( ) hides the field name in "reading" view but the field does not work for dataview queries.
I'm looking for a way to hide the field in the "live-preview" mode, but still have it work for queries. Is it possible for dataview to look for inline fields within html?

I added a new feature request #1451   to hide (key:: value) syntax in live-preview, too. If you feel it's something that would help you, give it a thumbs-up :)

Oh so if I understand what you're saying, (summary:: test)'s key hiding feature is broken in live preview? Am I understanding correctly? Is this what #1451 also talks about?


Unable to create a source for reading table

when i use the cdc connector in flink1.13 and try to create the cdc table，i am using pyflink and flink sql. then i got this error：
py4j.protocol.Py4JJavaError: An error occurred while calling o7.executeSql.
: org.apache.flink.table.api.ValidationException: Unable to create a source for reading table 'default_catalog.default_database.test_lecture'.
Table options are:
'connector'='mysql-cdc'
'database-name'='xxxx'
'hostname'='xxxxx'
'password'='xxxx'
'port'='3306'
'table-name'='xxxx'
'username'='xxxx'
.....
Caused by: java.lang.NoSuchMethodError: org.apache.flink.table.factories.DynamicTableFactory$Context.getCatalogTable()Lorg/apache/flink/table/catalog/CatalogT
able;
i've tried to run the same code in flink 1.12 in the same way, it works,
so can anyone help me with this problem? thx

i've build the latest version of the connector and put it into my program, then it works!

@Owenmessizz hello, I have encountered the same problem as you. Have you resolved it? my flink version is 1.15.2,flink-sql-connector-oracle-cdc-2.4.1,the connector is the latest version, but it do not work


Quesiton about training and (possibly) finetuning the model

Hi, thanks for your impressive work on image generation!
I anticipate using it as a generative backbone of my future work, so I am a bit curious about how many GPU resources are needed to train the model from scratch. More importantly, is it possible to finetune the model (like we commonly did on diffusion-based models like SD) using fewer GPU resources? Could you please provide some information? Thanks very much!

Training from scratch is very expensive especially for the 1024x1024 resolution. We highly recommand you finetune Infinity. According to our full-params fine-tuning test, a iteration takes around 6s for one GPU, where bs=4, resolution=1024x1024.

hi, I would like to know how many computing resources are required to train the 125M model from scratch and how many are required to finetune？

@wxxhaoshuai
Apart from the model size, computing resources also depend on the data size and the targe resolution. I think 16 gpu cards (A100 or H100) are enough for training 125M model from scratch under 256x256 resolution.

Will you release the smaller checkpoint？such as 125M or 1B.

@wxxhaoshuai These small models are trained with a small subset of the whole dataset and used for demonstrating the scaling capability of Infinity. They are not full trained with abundant data, resolutions , iterations. Therefore, we have no plan to release samller models for Infinity😭. We plan to release Infinity-20B.


[Refactoring] Tools for automatic dependency usage check

Tool to support post 1 of #35

Maybe https://maven.apache.org/plugins/maven-dependency-plugin/ could be useful here. Not sure if there are other tools that are better suited


Updated breadcrumb UI to new design

Pull Request Description
Implements ##7199

Important Notes

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[x] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.
[x] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

The attached screenshot does not match the design:  I see that gaps between elements are different, and not only a gap before the read icon, but also gaps between entry and separator seems a little off to me (I didn't measure though)

I've updated the distances to better match the reference (see the new screenshot).

QA: :green_circle:


Stabilize workspace/symbol

Problem
The workspace/symbol request is "sent from the client to the server to list project-wide symbols matching the query string." It includes location information for each symbol, so the user can navigate to them, along with a symbol type that influences the icon used to display the result in-editor.
The query string is just a string with no special formatting or query. It can be fuzzily matched or exact matched; whatever seems to work best.
You can search for symbols in VS Code with ⌘T, which opens up the search box with #. VS Code will send workspace/symbol requests as you type. e.g. searching for #foo will send three separate workspace/symbol requests with query strings "f", "fo", and "foo" to the language server. (It probably cancels intermediate requests that haven't yet been processed; Sorbet's language server correctly supports cancelation.)
Proposed solution
We have a straightforward implementation of workspace/symbol:
https://github.com/sorbet/sorbet/blob/master/main/lsp/requests/workspace_symbols.cc#L29
However, it has a few problems:

It doesn't "appear" to work in Stripe's large Ruby codebase, but one look at the log suggests that it might be because it sends back way too many symbols.

VS Code doesn't appear to be hung, so I suspect but did not confirm that VS Code refuses to display results until the query is specific enough to return a manageable set of symbols.

It is effectively untested.*
Search results aren't ranked in any particular order.
Some internal Sorbet names (e.g. <root>) appear in the description of search results:

This is from a small test workspace.
We should:

Determine what 'good' sorting and fuzzy matching behavior should be.

For sorting, I've used Levenshtein distance before, but it might be worth seeing what TypeScript does.

Add testing support to test_corpus.
Write tests that search for many symbol types and that expose existing bugs (e.g., showing <root>, not ranking things, etc).
Fix the code so it passes those tests.

The tests for workspace/symbol can likely cargo-cult part of the design from @jez's autocomplete tests. I'm thinking something like:
# symbolSearch: foo  result1, result2, result3, ...

* There's a "recorded test", but it should be deleted once we have proper test_corpus tests.

If it's not fast, we could memoize the results of last few searches and filter those if a new query is a superset of an old query, e.g. f => fo => foo).

Update: It looks like we're not fuzzy matching anymore, we're exact matching.

I benchmarked workspace/symbol on Stripe's large codebase; it takes only 80 milliseconds to iterate through the symbol table looking for exact string matches. I think we can make this run quickly without an index!

Awesome!


Can not load "webpack" on<EMAIL_ADDRESS>

Hi Guys, I'am using the<EMAIL_ADDRESS>with<EMAIL_ADDRESS>currently I updating my webpack from 2.1.0-beta.25 to 2.1.0-beta.26, when I running npm test I encountered the following error, does anyone has the same issue?
Here's the error message :

By the way here is my repo

The problem has been solved due to new webpack external settings rule

I have the same issue. What did you do, to fix it?
I found your externals settings here https://github.com/wellyshen/react-cool-starter/blob/master/tools/webpack/config.test.babel.js#L40-L45
You have some »react« stuff there. I tried this in my config, but it doesn’t change anything.

https://github.com/webpack-contrib/karma-webpack/releases/tag/v2.0.0

?
If you tried to tell my that i should remove the entry: {} from my webpack config: I have no entry: {} in my webpack config.


An option to disable adding the @live directive

Is your feature request related to a problem? Please describe.
I'm trying to use the graphql-mesh package with Apollo Federation. And I have the following error:
GraphQLSchemaValidationError: [@live] -> Custom directives must be implemented in every service.

I don't see an option to disable adding the @live directive to the generated schema.
Describe the solution you'd like
It would be great to have an option to disable adding the @live directive
Describe alternatives you've considered
I think I may try to use the @graphql-tools/wrap package and remove the @live directive after the schema is generated

<EMAIL_ADDRESS>will be available without @live directive in a few minutes.

@ardatan I'm very grateful, you are really quick! But I don't use @graphql-mesh/cli, I use @graphql-mesh/runtime instead

So it is available with the latest version for<EMAIL_ADDRESS>

thank you, I really appreciate this!


Problem building and running featuretoools-docker

Hi there,
i ran into an issue when trying to build this Dockerfile:
mkdir: cannot create directory ‘/home/jovyan/.jupyter’: File exists
The command '/bin/sh -c mkdir /home/$NB_USER/.jupyter' returned a non-zero code: 1

(Full build error below)
This appears to be caused by the last line in the Dockerfile, since the upstream jupyter/base-notebook image already creates it:
RUN mkdir /home/$NB_USER/.jupyter
Commenting the line out allows the build to complete, but running the docker run -it -p 8888:8888 <IMAGE_NAME> command generates the following error:
OSError: [Errno 99] Cannot assign requested address

(Full run error below)
I decided to slap together my own Dockerfile to get started:
Dockerfile:
FROM jupyter/minimal-notebook
COPY requirements.txt /tmp
RUN pip install -r /tmp/requirements.txt

requirements.txt:
featuretools==0.6.1

To run it,
docker run -it -p 8888:8888 -v <full host directory path for my own Jupyter notebooks>:/home/jovyan/work <IMAGE_NAME>

Full build error
pato@u16:/mnt/4TB-ext4/tmp/featuretools-docker$ docker build -t ftdocker .
Sending build context to Docker daemon   72.7kB
Step 1/9 : FROM jupyter/minimal-notebook
 ---> bb9925358374
Step 2/9 : RUN conda create --quiet --yes -p $CONDA_DIR/envs/python2 python=2.7 ipykernel kernda &&     conda clean -tipsy
 ---> Running in c2478bda4165
Collecting package metadata: ...working... done
Solving environment: ...working... done

## Package Plan ##

  environment location: /opt/conda/envs/python2

  added / updated specs:
    - ipykernel
    - kernda
    - python=2.7

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    backports-1.0              |             py_2           4 KB  conda-forge
    backports.shutil_get_terminal_size-1.0.0|             py_3           7 KB  conda-forge
    backports_abc-0.5          |             py_1           5 KB  conda-forge
    certifi-2019.3.9           |           py27_0         149 KB  conda-forge
    decorator-4.4.0            |             py_0          11 KB  conda-forge
    enum34-1.1.6               |        py27_1001          56 KB  conda-forge
    futures-3.2.0              |        py27_1000          24 KB  conda-forge
    ipykernel-4.10.0           |           py27_1         144 KB  conda-forge
    ipython-5.8.0              |           py27_0         1.0 MB  conda-forge
    kernda-0.3.0               |             py_1           7 KB  conda-forge
    libffi-3.2.1               |    he1b5a44_1006          46 KB  conda-forge
    pathlib2-2.3.3             |        py27_1000          31 KB  conda-forge
    pexpect-4.6.0              |        py27_1000          73 KB  conda-forge
    pickleshare-0.7.5          |        py27_1000          11 KB  conda-forge
    pip-19.0.3                 |           py27_0         1.8 MB  conda-forge
    prompt_toolkit-1.0.15      |             py_1         154 KB  conda-forge
    ptyprocess-0.6.0           |        py27_1000          22 KB  conda-forge
    python-2.7.15              |    h721da81_1008        12.8 MB  conda-forge
    pyzmq-18.0.1               |   py27h0e1adb2_0         474 KB  conda-forge
    scandir-1.10.0             |   py27h14c3975_0          28 KB  conda-forge
    setuptools-40.8.0          |           py27_0         630 KB  conda-forge
    simplegeneric-0.8.1        |             py_1           7 KB  conda-forge
    singledispatch-<IP_ADDRESS>     |        py27_1000          15 KB  conda-forge
    six-1.12.0                 |        py27_1000          21 KB  conda-forge
    tornado-5.1.1              |py27h14c3975_1000         642 KB  conda-forge
    traitlets-4.3.2            |        py27_1000         125 KB  conda-forge
    wheel-0.33.1               |           py27_0          34 KB  conda-forge
    ------------------------------------------------------------
                                           Total:        18.2 MB

The following NEW packages will be INSTALLED:

  backports          conda-forge/noarch::backports-1.0-py_2
  backports.shutil_~ conda-forge/noarch::backports.shutil_get_terminal_size-1.0.0-py_3
  backports_abc      conda-forge/noarch::backports_abc-0.5-py_1
  ca-certificates    conda-forge/linux-64::ca-certificates-2019.3.9-hecc5488_0
  certifi            conda-forge/linux-64::certifi-2019.3.9-py27_0
  decorator          conda-forge/noarch::decorator-4.4.0-py_0
  enum34             conda-forge/linux-64::enum34-1.1.6-py27_1001
  futures            conda-forge/linux-64::futures-3.2.0-py27_1000
  ipykernel          conda-forge/linux-64::ipykernel-4.10.0-py27_1
  ipython            conda-forge/linux-64::ipython-5.8.0-py27_0
  ipython_genutils   conda-forge/noarch::ipython_genutils-0.2.0-py_1
  jupyter_client     conda-forge/noarch::jupyter_client-5.2.4-py_3
  jupyter_core       conda-forge/noarch::jupyter_core-4.4.0-py_0
  kernda             conda-forge/noarch::kernda-0.3.0-py_1
  libffi             conda-forge/linux-64::libffi-3.2.1-he1b5a44_1006
  libgcc-ng          conda-forge/linux-64::libgcc-ng-7.3.0-hdf63c60_0
  libsodium          conda-forge/linux-64::libsodium-1.0.16-h14c3975_1001
  libstdcxx-ng       conda-forge/linux-64::libstdcxx-ng-7.3.0-hdf63c60_0
  ncurses            conda-forge/linux-64::ncurses-6.1-hf484d3e_1002
  openssl            conda-forge/linux-64::openssl-1.1.1b-h14c3975_1
  pathlib2           conda-forge/linux-64::pathlib2-2.3.3-py27_1000
  pexpect            conda-forge/linux-64::pexpect-4.6.0-py27_1000
  pickleshare        conda-forge/linux-64::pickleshare-0.7.5-py27_1000
  pip                conda-forge/linux-64::pip-19.0.3-py27_0
  prompt_toolkit     conda-forge/noarch::prompt_toolkit-1.0.15-py_1
  ptyprocess         conda-forge/linux-64::ptyprocess-0.6.0-py27_1000
  pygments           conda-forge/noarch::pygments-2.3.1-py_0
  python             conda-forge/linux-64::python-2.7.15-h721da81_1008
  python-dateutil    conda-forge/noarch::python-dateutil-2.8.0-py_0
  pyzmq              conda-forge/linux-64::pyzmq-18.0.1-py27h0e1adb2_0
  readline           conda-forge/linux-64::readline-7.0-hf8c457e_1001
  scandir            conda-forge/linux-64::scandir-1.10.0-py27h14c3975_0
  setuptools         conda-forge/linux-64::setuptools-40.8.0-py27_0
  simplegeneric      conda-forge/noarch::simplegeneric-0.8.1-py_1
  singledispatch     conda-forge/linux-64::singledispatch-<IP_ADDRESS>-py27_1000
  six                conda-forge/linux-64::six-1.12.0-py27_1000
  sqlite             conda-forge/linux-64::sqlite-3.26.0-h67949de_1001
  tk                 conda-forge/linux-64::tk-8.6.9-h84994c4_1000
  tornado            conda-forge/linux-64::tornado-5.1.1-py27h14c3975_1000
  traitlets          conda-forge/linux-64::traitlets-4.3.2-py27_1000
  wcwidth            conda-forge/noarch::wcwidth-0.1.7-py_1
  wheel              conda-forge/linux-64::wheel-0.33.1-py27_0
  zeromq             conda-forge/linux-64::zeromq-4.2.5-hf484d3e_1006
  zlib               conda-forge/linux-64::zlib-1.2.11-h14c3975_1004

Preparing transaction: ...working... done
Verifying transaction: ...working... done
Executing transaction: ...working... done
Cache location: /opt/conda/pkgs
Will remove the following tarballs:

/opt/conda/pkgs
---------------
pickleshare-0.7.5-py27_1000.tar.bz2           11 KB
traitlets-4.3.2-py27_1000.tar.bz2            125 KB
decorator-4.4.0-py_0.tar.bz2                  11 KB
backports_abc-0.5-py_1.tar.bz2                 5 KB
backports-1.0-py_2.tar.bz2                     4 KB
pip-19.0.3-py27_0.tar.bz2                    1.8 MB
tornado-5.1.1-py27h14c3975_1000.tar.bz2      642 KB
backports.shutil_get_terminal_size-1.0.0-py_3.tar.bz2       7 KB
pathlib2-2.3.3-py27_1000.tar.bz2              31 KB
kernda-0.3.0-py_1.tar.bz2                      7 KB
scandir-1.10.0-py27h14c3975_0.tar.bz2         28 KB
simplegeneric-0.8.1-py_1.tar.bz2               7 KB
ipython-5.8.0-py27_0.tar.bz2                 1.0 MB
ptyprocess-0.6.0-py27_1000.tar.bz2            22 KB
python-2.7.15-h721da81_1008.tar.bz2         12.8 MB
ipykernel-4.10.0-py27_1.tar.bz2              144 KB
futures-3.2.0-py27_1000.tar.bz2               24 KB
setuptools-40.8.0-py27_0.tar.bz2             630 KB
pexpect-4.6.0-py27_1000.tar.bz2               73 KB
certifi-2019.3.9-py27_0.tar.bz2              149 KB
enum34-1.1.6-py27_1001.tar.bz2                56 KB
six-1.12.0-py27_1000.tar.bz2                  21 KB
libffi-3.2.1-he1b5a44_1006.tar.bz2            46 KB
singledispatch-<IP_ADDRESS>-py27_1000.tar.bz2      15 KB
prompt_toolkit-1.0.15-py_1.tar.bz2           154 KB
wheel-0.33.1-py27_0.tar.bz2                   34 KB
pyzmq-18.0.1-py27h0e1adb2_0.tar.bz2          474 KB

---------------------------------------------------
Total:                                      18.2 MB

Removed pickleshare-0.7.5-py27_1000.tar.bz2
Removed traitlets-4.3.2-py27_1000.tar.bz2
Removed decorator-4.4.0-py_0.tar.bz2
Removed backports_abc-0.5-py_1.tar.bz2
Removed backports-1.0-py_2.tar.bz2
Removed pip-19.0.3-py27_0.tar.bz2
Removed tornado-5.1.1-py27h14c3975_1000.tar.bz2
Removed backports.shutil_get_terminal_size-1.0.0-py_3.tar.bz2
Removed pathlib2-2.3.3-py27_1000.tar.bz2
Removed kernda-0.3.0-py_1.tar.bz2
Removed scandir-1.10.0-py27h14c3975_0.tar.bz2
Removed simplegeneric-0.8.1-py_1.tar.bz2
Removed ipython-5.8.0-py27_0.tar.bz2
Removed ptyprocess-0.6.0-py27_1000.tar.bz2
Removed python-2.7.15-h721da81_1008.tar.bz2
Removed ipykernel-4.10.0-py27_1.tar.bz2
Removed futures-3.2.0-py27_1000.tar.bz2
Removed setuptools-40.8.0-py27_0.tar.bz2
Removed pexpect-4.6.0-py27_1000.tar.bz2
Removed certifi-2019.3.9-py27_0.tar.bz2
Removed enum34-1.1.6-py27_1001.tar.bz2
Removed six-1.12.0-py27_1000.tar.bz2
Removed libffi-3.2.1-he1b5a44_1006.tar.bz2
Removed singledispatch-<IP_ADDRESS>-py27_1000.tar.bz2
Removed prompt_toolkit-1.0.15-py_1.tar.bz2
Removed wheel-0.33.1-py27_0.tar.bz2
Removed pyzmq-18.0.1-py27h0e1adb2_0.tar.bz2
Cache location: /opt/conda/pkgs
Will remove the following packages:
/opt/conda/pkgs
---------------

jupyterhub-0.9.4-py37_1000                   6.4 MB
nodejs-11.11.0-hf484d3e_0                   60.7 MB
tornado-6.0.1-py37h14c3975_0                 2.8 MB
jinja2-2.10-py_1                             450 KB
krb5-1.16.3-h05b26f9_1001                    5.0 MB
python-editor-1.0.4-py_0                      26 KB
backcall-0.1.0-py_0                           64 KB
nbformat-4.4.0-py_1                          384 KB
pandocfilters-1.4.2-py_1                      26 KB
terminado-0.8.1-py37_1001                     71 KB
defusedxml-0.5.0-py_1                         81 KB
libcurl-7.64.0-h541490c_2                    2.1 MB
send2trash-1.5.0-py_0                         51 KB
pickleshare-0.7.5-py37_1000                   32 KB
testpath-0.4.2-py37_1000                     192 KB
nbconvert-5.4.1-py_2                         1.1 MB
ptyprocess-0.6.0-py37_1000                    72 KB
pycurl-<IP_ADDRESS>-py37h1ba5d50_0               762 KB
prompt_toolkit-2.0.9-py_0                    1.2 MB
alembic-1.0.8-py_0                           614 KB
parso-0.3.4-py_0                             316 KB
traitlets-4.3.2-py37_1000                    624 KB
libssh2-1.8.0-h90d6eec_1004                  1.0 MB
notebook-5.7.5-py37_0                       31.0 MB
bleach-3.1.0-py_0                            623 KB
jsonschema-3.0.1-py37_0                      418 KB
entrypoints-0.3-py37_1000                     29 KB
decorator-4.3.2-py_0                          33 KB
ipython-7.3.0-py37h24bf2e0_0                 4.2 MB
pyzmq-18.0.1-py37h0e1adb2_0                  2.1 MB
markupsafe-1.1.1-py37h14c3975_0               81 KB
webencodings-0.5.1-py_1                       45 KB
jupyterlab-0.35.4-py37_0                    48.7 MB
async_generator-1.10-py_0                     72 KB
ipykernel-5.1.0-py37h24bf2e0_1002            640 KB
prometheus_client-0.6.0-py_0                 151 KB
python-oauth2-1.1.0-py37h28b3542_1           526 KB
mistune-0.8.4-py37h14c3975_1000              211 KB
mako-1.0.7-py_1                              285 KB
pyrsistent-0.14.11-py37h14c3975_0            372 KB
jedi-0.13.3-py37_0                          1013 KB
pexpect-4.6.0-py37_1000                      326 KB
attrs-19.1.0-py_0                            133 KB
pandoc-2.6-1                               125.8 MB
jupyterlab_server-0.2.0-py_0                  94 KB
pamela-1.0.0-py_0                             26 KB
configurable-http-proxy-1.3.0-0              758 KB
sqlalchemy-1.3.1-py37h14c3975_0              8.2 MB
tini-0.18.0-h14c3975_1001                     36 KB
python-3.7.1-h381d211_1003                  83.9 MB
yaml-0.1.7-h14c3975_1001                     333 KB
bzip2-1.0.6-h14c3975_1002                    1.5 MB
six-1.12.0-py37_1000                          71 KB
pyopenssl-19.0.0-py37_0                      399 KB
cryptography-2.6.1-py37h9d9f1b6_0            3.3 MB
cffi-1.12.2-py37hf0e25f4_1                   822 KB
asn1crypto-0.24.0-py37_1003                  870 KB
pycparser-2.19-py37_1                        947 KB
urllib3-1.24.1-py37_1000                     642 KB
chardet-3.0.4-py37_1003                      822 KB
pysocks-1.6.8-py37_1002                       73 KB
libffi-3.2.1-hf484d3e_1005                   160 KB
wheel-0.33.1-py37_0                          108 KB
conda-4.6.8-py37_0                           3.3 MB
pycosat-0.6.3-py37h14c3975_1001              415 KB
ruamel_yaml-0.15.71-py37h14c3975_1000        1.0 MB
requests-2.21.0-py37_1000                    335 KB
certifi-2019.3.9-py37_0                      293 KB
setuptools-40.8.0-py37_0                     2.7 MB
pip-19.0.3-py37_0                            7.1 MB
libedit-3.1.20170329-hf8c457e_1001           718 KB
xz-5.2.4-h14c3975_1001                       1.2 MB
idna-2.8-py37_1000                           486 KB

---------------------------------------------------
Total:                                     421.2 MB

removing jupyterhub-0.9.4-py37_1000
removing nodejs-11.11.0-hf484d3e_0
removing tornado-6.0.1-py37h14c3975_0
removing jinja2-2.10-py_1
removing krb5-1.16.3-h05b26f9_1001
removing python-editor-1.0.4-py_0
removing backcall-0.1.0-py_0
removing nbformat-4.4.0-py_1
removing pandocfilters-1.4.2-py_1
removing terminado-0.8.1-py37_1001
removing defusedxml-0.5.0-py_1
removing libcurl-7.64.0-h541490c_2
removing send2trash-1.5.0-py_0
removing pickleshare-0.7.5-py37_1000
removing testpath-0.4.2-py37_1000
removing nbconvert-5.4.1-py_2
removing ptyprocess-0.6.0-py37_1000
removing pycurl-<IP_ADDRESS>-py37h1ba5d50_0
removing prompt_toolkit-2.0.9-py_0
removing alembic-1.0.8-py_0
removing parso-0.3.4-py_0
removing traitlets-4.3.2-py37_1000
removing libssh2-1.8.0-h90d6eec_1004
removing notebook-5.7.5-py37_0
removing bleach-3.1.0-py_0
removing jsonschema-3.0.1-py37_0
removing entrypoints-0.3-py37_1000
removing decorator-4.3.2-py_0
removing ipython-7.3.0-py37h24bf2e0_0
removing pyzmq-18.0.1-py37h0e1adb2_0
removing markupsafe-1.1.1-py37h14c3975_0
removing webencodings-0.5.1-py_1
removing jupyterlab-0.35.4-py37_0
removing async_generator-1.10-py_0
removing ipykernel-5.1.0-py37h24bf2e0_1002
removing prometheus_client-0.6.0-py_0
removing python-oauth2-1.1.0-py37h28b3542_1
removing mistune-0.8.4-py37h14c3975_1000
removing mako-1.0.7-py_1
removing pyrsistent-0.14.11-py37h14c3975_0
removing jedi-0.13.3-py37_0
removing pexpect-4.6.0-py37_1000
removing attrs-19.1.0-py_0WARNING: 'conda clean --source-cache' is deprecated.
     Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
Collecting featuretools
  Downloading https://files.pythonhosted.org/packages/60/91/b868d0426b06be0e1b2eaead4784c7b060bc2833a32cbe9c4087731b50a7/featuretools-0.6.1.tar.gz (159kB)
Collecting boto3>=1.9.51 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/0a/44/96075812bcd1666e339107db0e7ef8ba610270d8039ca81e3cd5bc2de206/boto3-1.9.117-py2.py3-none-any.whl (128kB)
Collecting botocore>=1.12.51 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/5d/34/1f9422dba5bc9cc5304ee4f075855fad989e4b9d80d0e48016f3e3981ea5/botocore-1.12.117-py2.py3-none-any.whl (5.3MB)
Collecting numpy>=1.13.3 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/c4/33/8ec8dcdb4ede5d453047bbdbd01916dbaccdb63e98bba60989718f5f0876/numpy-1.16.2-cp27-cp27mu-manylinux1_x86_64.whl (17.0MB)
Collecting pandas>=0.23.0 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/db/83/7d4008ffc2988066ff37f6a0bb6d7b60822367dcb36ba5e39aa7801fda54/pandas-0.24.2-cp27-cp27mu-manylinux1_x86_64.whl (10.1MB)
Collecting tqdm>=4.19.2 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/6c/4b/c38b5144cf167c4f52288517436ccafefe9dc01b8d1c190e18a6b154cd4a/tqdm-4.31.1-py2.py3-none-any.whl (48kB)
Collecting toolz>=0.8.2 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/14/d0/a73c15bbeda3d2e7b381a36afb0d9cd770a9f4adc5d1532691013ba881db/toolz-0.9.0.tar.gz (45kB)
Collecting pyyaml>=3.12 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/9f/2c/9417b5c774792634834e730932745bc09a7d36754ca00acf1ccd1ac2594d/PyYAML-5.1.tar.gz (274kB)
Collecting cloudpickle>=0.4.0 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/47/d5/efa7cacef5d3bdcd71d7053a698fb9b64a20fff5cb3c592efefa53ea5578/cloudpickle-0.8.0-py2.py3-none-any.whl
Collecting future>=0.16.0 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/90/52/e20466b85000a181e1e144fd8305caf2cf475e2f9674e797b222f8105f5f/future-0.17.1.tar.gz (829kB)
Collecting dask>=1.1.0 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/b9/bc/0d747625c18397ed548c7890bf984a40d931b9ebac236c570a07565b0cc8/dask-1.1.4-py2.py3-none-any.whl (704kB)
Collecting distributed>=1.24.2 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/e7/52/08ead8f0968d42510630f307100307b481298696cb7de81d58f0cdf7f320/distributed-1.26.0-py2.py3-none-any.whl (506kB)
Collecting psutil>=5.4.8 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/2f/b8/11ec5006d2ec2998cb68349b8d1317c24c284cf918ecd6729739388e4c56/psutil-5.6.1.tar.gz (427kB)
Collecting click>=7.0.0 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/fa/37/45185cb5abbc30d7257104c434fe0b07e5a195a6847506c074527aa599ec/Click-7.0-py2.py3-none-any.whl (81kB)
Collecting smart_open>=1.7.1 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/ff/c8/de7dcf34d4b5f2ae94fe1055e0d6418fb97a63c9dc3428edd264704983a2/smart_open-1.8.0.tar.gz (40kB)
Collecting scikit-learn>=0.20.0 (from featuretools)
  Downloading https://files.pythonhosted.org/packages/f7/bb/52a01390c1dbb2c65d3072bc687271aa9ddf6964141ce7e03304820138f4/scikit_learn-0.20.3-cp27-cp27mu-manylinux1_x86_64.whl (5.5MB)
Collecting jmespath<1.0.0,>=0.7.1 (from boto3>=1.9.51->featuretools)
  Downloading https://files.pythonhosted.org/packages/83/94/7179c3832a6d45b266ddb2aac329e101367fbdb11f425f13771d27f225bb/jmespath-0.9.4-py2.py3-none-any.whl
Collecting s3transfer<0.3.0,>=0.2.0 (from boto3>=1.9.51->featuretools)
  Downloading https://files.pythonhosted.org/packages/d7/de/5737f602e22073ecbded7a0c590707085e154e32b68d86545dcc31004c02/s3transfer-0.2.0-py2.py3-none-any.whl (69kB)
Collecting docutils>=0.10 (from botocore>=1.12.51->featuretools)
  Downloading https://files.pythonhosted.org/packages/50/09/c53398e0005b11f7ffb27b7aa720c617aba53be4fb4f4f3f06b9b5c60f28/docutils-0.14-py2-none-any.whl (543kB)
Requirement already satisfied: python-dateutil<3.0.0,>=2.1; python_version >= "2.7" in /opt/conda/envs/python2/lib/python2.7/site-packages (from botocore>=1.12.51->featuretools) (2.8.0)
Collecting urllib3<1.25,>=1.20; python_version == "2.7" (from botocore>=1.12.51->featuretools)
  Downloading https://files.pythonhosted.org/packages/62/00/ee1d7de624db8ba7090d1226aebefab96a2c71cd5cfa7629d6ad3f61b79e/urllib3-1.24.1-py2.py3-none-any.whl (118kB)
Collecting pytz>=2011k (from pandas>=0.23.0->featuretools)
  Downloading https://files.pythonhosted.org/packages/61/28/1d3920e4d1d50b19bc5d24398a7cd85cc7b9a75a490570d5a30c57622d34/pytz-2018.9-py2.py3-none-any.whl (510kB)
Collecting msgpack (from distributed>=1.24.2->featuretools)
  Downloading https://files.pythonhosted.org/packages/6f/74/06f950e5a4c1fb94b676640b8fea839b80bffdc247144bd054dd5eed250e/msgpack-0.6.1-cp27-cp27mu-manylinux1_x86_64.whl (231kB)
Collecting sortedcontainers!=2.0.0,!=2.0.1 (from distributed>=1.24.2->featuretools)
  Downloading https://files.pythonhosted.org/packages/13/f3/cf85f7c3a2dbd1a515d51e1f1676d971abe41bba6f4ab5443240d9a78e5b/sortedcontainers-2.1.0-py2.py3-none-any.whl
Requirement already satisfied: singledispatch; python_version < "3.4" in /opt/conda/envs/python2/lib/python2.7/site-packages (from distributed>=1.24.2->featuretools) (<IP_ADDRESS>)
Requirement already satisfied: six in /opt/conda/envs/python2/lib/python2.7/site-packages (from distributed>=1.24.2->featuretools) (1.12.0)
Requirement already satisfied: tornado>=5 in /opt/conda/envs/python2/lib/python2.7/site-packages (from distributed>=1.24.2->featuretools) (5.1.1)
Requirement already satisfied: futures; python_version < "3.0" in /opt/conda/envs/python2/lib/python2.7/site-packages (from distributed>=1.24.2->featuretools) (3.2.0)
Collecting zict>=0.1.3 (from distributed>=1.24.2->featuretools)
  Downloading https://files.pythonhosted.org/packages/bd/45/a2e6f95a850cd407d785f2f8624b02e72baf6ab910aea4bdcac7e18b4871/zict-0.1.4-py2.py3-none-any.whl
Collecting tblib (from distributed>=1.24.2->featuretools)
  Downloading https://files.pythonhosted.org/packages/4a/82/1b9fba6e93629a8557f9784cd8f1ae063c8762c26446367a6764edd328ce/tblib-1.3.2-py2.py3-none-any.whl
Collecting boto>=2.32 (from smart_open>=1.7.1->featuretools)
  Downloading https://files.pythonhosted.org/packages/23/10/c0b78c27298029e4454a472a1919bde20cb182dab1662cec7f2ca1dcc523/boto-2.49.0-py2.py3-none-any.whl (1.4MB)
Collecting bz2file (from smart_open>=1.7.1->featuretools)
  Downloading https://files.pythonhosted.org/packages/61/39/122222b5e85cd41c391b68a99ee296584b2a2d1d233e7ee32b4532384f2d/bz2file-0.98.tar.gz
Collecting requests (from smart_open>=1.7.1->featuretools)
  Downloading https://files.pythonhosted.org/packages/7d/e3/20f3d364d6c8e5d2353c72a67778eb189176f08e873c9900e10c0287b84b/requests-2.21.0-py2.py3-none-any.whl (57kB)
Collecting scipy>=0.13.3 (from scikit-learn>=0.20.0->featuretools)
  Downloading https://files.pythonhosted.org/packages/81/39/f1457091d0a45a84a2bd7815e2cf6bd45d4fe240728e9ed567cbb17c8abe/scipy-1.2.1-cp27-cp27mu-manylinux1_x86_64.whl (24.8MB)
Requirement already satisfied: backports_abc>=0.4 in /opt/conda/envs/python2/lib/python2.7/site-packages (from tornado>=5->distributed>=1.24.2->featuretools) (0.5)
Collecting heapdict (from zict>=0.1.3->distributed>=1.24.2->featuretools)
  Downloading https://files.pythonhosted.org/packages/e2/ca/f5feba2f939c97629dbce52a17acc95a0d10256ef620334795379dda8ce6/HeapDict-1.0.0.tar.gz
Collecting chardet<3.1.0,>=3.0.2 (from requests->smart_open>=1.7.1->featuretools)
  Downloading https://files.pythonhosted.org/packages/bc/a9/01ffebfb562e4274b6487b4bb1ddec7ca55ec7510b22e4c51f14098443b8/chardet-3.0.4-py2.py3-none-any.whl (133kB)
Collecting idna<2.9,>=2.5 (from requests->smart_open>=1.7.1->featuretools)
  Downloading https://files.pythonhosted.org/packages/14/2c/cd551d81dbe15200be1cf41cd03869a46fe7226e7450af7a6545bfc474c9/idna-2.8-py2.py3-none-any.whl (58kB)
Requirement already satisfied: certifi>=2017.4.17 in /opt/conda/envs/python2/lib/python2.7/site-packages (from requests->smart_open>=1.7.1->featuretools) (2019.3.9)
Building wheels for collected packages: featuretools, toolz, pyyaml, future, psutil, smart-open, bz2file, heapdict
  Building wheel for featuretools (setup.py): started
  Building wheel for featuretools (setup.py): finished with status 'done'
  Stored in directory: /home/jovyan/.cache/pip/wheels/cb/87/34/21b0ef1eeceb492f7885799c2f923254e5983832f2c43111e0
  Building wheel for toolz (setup.py): started
  Building wheel for toolz (setup.py): finished with status 'done'
  Stored in directory: /home/jovyan/.cache/pip/wheels/f4/0c/f6/ce6b2d1aa459ee97cc3c0f82236302bd62d89c86c700219463
  Building wheel for pyyaml (setup.py): started
  Building wheel for pyyaml (setup.py): finished with status 'done'
  Stored in directory: /home/jovyan/.cache/pip/wheels/ad/56/bc/1522f864feb2a358ea6f1a92b4798d69ac783a28e80567a18b
  Building wheel for future (setup.py): started
  Building wheel for future (setup.py): finished with status 'done'
  Stored in directory: /home/jovyan/.cache/pip/wheels/0c/61/d2/d6b7317325828fbb39ee6ad559dbe4664d0896da4721bf379e
  Building wheel for psutil (setup.py): started
  Building wheel for psutil (setup.py): finished with status 'done'
  Stored in directory: /home/jovyan/.cache/pip/wheels/86/36/f4/e1fc49f198c623b8dc2156e80011a52f19a959d538f6b1a5db
  Building wheel for smart-open (setup.py): started
  Building wheel for smart-open (setup.py): finished with status 'done'
  Stored in directory: /home/jovyan/.cache/pip/wheels/f7/a6/ff/9ab5842c14e50e95a06a4675b0b4a689c9cab6064dac2b01d0
  Building wheel for bz2file (setup.py): started
  Building wheel for bz2file (setup.py): finished with status 'done'
  Stored in directory: /home/jovyan/.cache/pip/wheels/81/75/d6/e1317bf09bf1af5a30befc2a007869fa6e1f516b8f7c591cb9
  Building wheel for heapdict (setup.py): started
  Building wheel for heapdict (setup.py): finished with status 'done'
  Stored in directory: /home/jovyan/.cache/pip/wheels/40/b9/42/344857b482c954f48bcff6db72d388e30bf2bee4ed14706faa
Successfully built featuretools toolz pyyaml future psutil smart-open bz2file heapdict
Installing collected packages: jmespath, docutils, urllib3, botocore, s3transfer, boto3, numpy, pytz, pandas, tqdm, toolz, pyyaml, cloudpickle, future, dask, msgpack, sortedcontainers, click, psutil, heapdict, zict, tblib, distributed, boto, bz2file, chardet, idna, requests, smart-open, scipy, scikit-learn, featuretools
Successfully installed boto-2.49.0 boto3-1.9.117 botocore-1.12.117 bz2file-0.98 chardet-3.0.4 click-7.0 cloudpickle-0.8.0 dask-1.1.4 distributed-1.26.0 docutils-0.14 featuretools-0.6.1 future-0.17.1 heapdict-1.0.0 idna-2.8 jmespath-0.9.4 msgpack-0.6.1 numpy-1.16.2 pandas-0.24.2 psutil-5.6.1 pytz-2018.9 pyyaml-5.1 requests-2.21.0 s3transfer-0.2.0 scikit-learn-0.20.3 scipy-1.2.1 smart-open-1.8.0 sortedcontainers-2.1.0 tblib-1.3.2 toolz-0.9.0 tqdm-4.31.1 urllib3-1.24.1 zict-0.1.4
Removing intermediate container 229ce6c00d0e
 ---> 4b4a0a19b41b
Step 4/9 : USER root
 ---> Running in 694865c83e34
Removing intermediate container 694865c83e34
 ---> 9aad3db6af58
Step 5/9 : RUN $CONDA_DIR/envs/python2/bin/python -m ipykernel install &&     $CONDA_DIR/envs/python2/bin/kernda -o -y /usr/local/share/jupyter/kernels/python2/kernel.json
 ---> Running in 12631dba4c03
Installed kernelspec python2 in /usr/local/share/jupyter/kernels/python2
Wrote to /usr/local/share/jupyter/kernels/python2/kernel.json
{
  "display_name": "Python 2",
  "argv": [
    "bash",
    "-c",
    "source \"/opt/conda/bin/activate\" \"/opt/conda/envs/python2\" && exec /opt/conda/envs/python2/bin/python -m ipykernel_launcher -f '{connection_file}' "
  ],
  "language": "python"
}
Removing intermediate container 12631dba4c03
 ---> 6b81fbd5852c
Step 6/9 : RUN echo "c.KernelSpecManager.whitelist = set(['python2'])" >> /etc/jupyter/jupyter_notebook_config.py
 ---> Running in f73416e55eba
Removing intermediate container f73416e55eba
 ---> 460d57d78cb7
Step 7/9 : COPY start-notebook.sh /usr/local/bin/start-notebook.sh
 ---> 4c6666f5e869
Step 8/9 : USER $NB_USER
 ---> Running in 7d7a12217c28
Removing intermediate container 7d7a12217c28
 ---> 5721974b366f
Step 9/9 : RUN mkdir /home/$NB_USER/.jupyter
 ---> Running in 67e2dc816b7e
mkdir: cannot create directory ‘/home/jovyan/.jupyter’: File exists
The command '/bin/sh -c mkdir /home/$NB_USER/.jupyter' returned a non-zero code: 1

Full run error
docker run -it -p 8888:8888 ftdocker
Executing the command: jupyter notebook
[E 17:50:01.396 NotebookApp] Exception while loading config file /etc/jupyter/jupyter_notebook_config.py
    Traceback (most recent call last):
      File "/opt/conda/lib/python3.7/site-packages/traitlets/config/application.py", line 562, in _load_config_files
        config = loader.load_config()
      File "/opt/conda/lib/python3.7/site-packages/traitlets/config/loader.py", line 457, in load_config
        self._read_file_as_dict()
      File "/opt/conda/lib/python3.7/site-packages/traitlets/config/loader.py", line 489, in _read_file_as_dict
        py3compat.execfile(conf_filename, namespace)
      File "/opt/conda/lib/python3.7/site-packages/ipython_genutils/py3compat.py", line 198, in execfile
        exec(compiler(f.read(), fname, 'exec'), glob, loc)
      File "/etc/jupyter/jupyter_notebook_config.py", line 55
        os.umask(int(os.environ['NB_UMASK'], 8))c.KernelSpecManager.whitelist = set(['python2'])
                                                ^
    SyntaxError: invalid syntax
[I 17:50:01.450 NotebookApp] Writing notebook server cookie secret to /home/jovyan/.local/share/jupyter/runtime/notebook_cookie_secret
Traceback (most recent call last):
  File "/opt/conda/bin/jupyter-notebook", line 11, in <module>
    sys.exit(main())
  File "/opt/conda/lib/python3.7/site-packages/jupyter_core/application.py", line 266, in launch_instance
    return super(JupyterApp, cls).launch_instance(argv=argv, **kwargs)
  File "/opt/conda/lib/python3.7/site-packages/traitlets/config/application.py", line 657, in launch_instance
    app.initialize(argv)
  File "</opt/conda/lib/python3.7/site-packages/decorator.py:decorator-gen-7>", line 2, in initialize
  File "/opt/conda/lib/python3.7/site-packages/traitlets/config/application.py", line 87, in catch_config_error
    return method(app, *args, **kwargs)
  File "/opt/conda/lib/python3.7/site-packages/notebook/notebookapp.py", line 1628, in initialize
    self.init_webapp()
  File "/opt/conda/lib/python3.7/site-packages/notebook/notebookapp.py", line 1407, in init_webapp
    self.http_server.listen(port, self.ip)
  File "/opt/conda/lib/python3.7/site-packages/tornado/tcpserver.py", line 151, in listen
    sockets = bind_sockets(port, address=address)
  File "/opt/conda/lib/python3.7/site-packages/tornado/netutil.py", line 174, in bind_sockets
    sock.bind(sockaddr)
OSError: [Errno 99] Cannot assign requested address

Of course, running export NB_USER=$USER will resolve the build issue, but the run error still occurs.

@patrickmpoon, thanks for raising this issue.  Most of the code in this Dockerfile is used for setting up python 2 notebooks.  We'll switch to python 3 notebooks and end up with something similar to the Dockerfile you've suggested.


add integration test for / autocomplete list can scroll - #12599

Summary
Pull Request adds a new cypress test that tests that when entering the slash command an autocomplete list shows and is abled to scroll through to the bottom.
Ticket Link
Fixes https://github.com/mattermost/mattermost-server/issues/12599
Related Pull Requests
No Related PRs

Has server changes: None
Has redux changes: None
Has mobile changes: None

Thanks @asbillings07 for the pull request!
Per the CONTRIBUTING.md file displayed when you created this pull request, we need to add you to the list of approved contributors for the Mattermost project.
Please help complete the Mattermost contribution license agreement?
This is a standard procedure for many open source projects. Your form should be processed within 24 hours and reviewers for your pull request will be able to proceed.
Please let us know if you have any questions.
We are very happy to have you join our growing community! If you're not yet a member, please consider joining our Contributors community channel to meet other contributors and discuss new opportunities with the core team.

Hello @asbillings07, I'm very sorry but upon rechecking, I realized that we have already specific test for this.
It's my fault. Sorry for wasting your time and effort.  I'd appreciate if you look for another help-wanted tickets - https://github.com/mattermost/mattermost-server/labels/Area%2FE2E Tests.
Please close if it's fine with you.  Thanks.


Add dependabot

https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/

At this moment we use NPM packages for TailwindCSS and postcss only. And go packages are updated during build. Therefore, Adding dependabot will only update the few NPM packages.