htmlpublisher plugin add olamy

Description

Submitter checklist for adding or changing permissions

Always

[ ] Add link to plugin/component Git repository in description above

For a newly hosted plugin only

[ ] Add link to resolved HOSTING issue in description above

For a new permissions file only

[ ] Make sure the file is created in permissions/ directory
[ ] artifactId (pom.xml) is used for name (permissions YAML file).
[ ] groupId / artifactId (pom.xml) are correctly represented in path (permissions YAML file)
[ ] Check that the file is named plugin-${artifactId}.yml for plugins

When adding new uploaders (this includes newly created permissions files)

[ ] Make sure to @mention an existing maintainer to confirm the permissions request, if applicable
[ ] Use the Jenkins community (LDAP) account name in the YAML file, not the GitHub account name
[ ] Make sure to @mention the users being added so their GitHub account names are known if they require GitHub merge access (see below).
[ ] All newly added users have logged in to Artifactory at least once

Reviewer checklist (not for requesters!)

[ ] Check this if newly added person also needs to be given merge permission to the GitHub repo (please @ the people/person with their GitHub username in this issue as well). If needed, it can be done using an IRC Bot command
[ ] Check that the $pluginId Developers team has Admin permissions while granting the access.
[ ] In the case of plugin adoption, ensure that the Jenkins Jira default assignee is either removed or changed to the new maintainer.
[ ] If security contacts are changed (this includes add/remove), ping the security officer (currently @daniel-beck) in this pull request. If an email contact is changed, wait for approval from the security officer.

There are IRC Bot commands for it

Approved from my end. @olamy will also need to be added to Github "htmlpublisher-plugin Developers" group.

htmlpublisher-plugin Developers

done and made you a maintainer of the team as well


Added a sports sub-directory

I have moved all of the current sports datasets to a new sub-directory in aorist. There will be more sports datasets added shortly.

These changes should not be merged.


SlideUp and SlideDown break when switching too fast

If you switch the animation prop between slideUp and slideDown too fast, the animation kinda breaks, as in, it becomes stuck in this in between state where it has almost no height.
It seems that this is caused by the fact that both of these animations take the current height as the starting height instead of the original height. This is causing problems if you switch between the animations in the middle of the animation, e.g. by clicking on a Read more/Read less button really fast.

This is likely a consequence of VelocityComponent using stop when switching animations. You could add a config property to change that to finish or allow it to queue, the way that the runAnimation method takes options.
See the demo for how these behaviors differ when calling runAnimation.

Ah I see how the demo does it. But this feels more like a workaround than the way it should be to be honest.. This forces me to directly use the Velocity API instead of using this wrapper in a nice way..

The same sort of configuration that is used in runAnimation could be
added to the props for VelocityComponent, if you're interested in sending
in a PR. It's all a workaround for slideUp/slideDown's implementation.
On Tue, Apr 18, 2017 at 9:35 AM, Robin<EMAIL_ADDRESS>wrote:

Ah I see how the demo does it. But this feels more like a workaround than
the way it should be to be honest.. This forces me to directly use the
Velocity API instead of using this wrapper in a nice way..
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/twitter-fabric/velocity-react/issues/185#issuecomment-294846161,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAP65Xqb1JCOAGk0UE_zFiDvMaLVfim-ks5rxLwrgaJpZM4NAEoA
.

@finneganh wouldn't it be better to add a prop to the velocity component? That way in componentWillUpdate we can check for that prop. If prop==='stop' then stopAnimation, otherwise finishAnimation.
What do you think?

Yep, I think we're on the same page.
On Tue, Apr 18, 2017 at 10:01 AM, Robin<EMAIL_ADDRESS>wrote:

@finneganh https://github.com/finneganh wouldn't it be better to add a
prop to the velocity component? That way in componentWillUpdate we can
check for that prop. If prop==='stop' then stopAnimation, otherwise
finishAnimation.
What do you think?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/twitter-fabric/velocity-react/issues/185#issuecomment-294853991,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAP65aPsI1m_ax7XF0Li_LQL9mgCs4AJks5rxMJLgaJpZM4NAEoA
.

I'll make a PR in that case.

Added the PR. Let me know if you agree or if you need changes.
P.S.: I also tried updating the demo, but in the demo the animation prop never changes so that wasn't possible with this new prop. It might be doable if you also check if the children prop changes in componentWillUpdate but I see that as a different issue.

I'm working on updating the demo to be hosted on Glitch. Will see if there's a good place to put it in then.

Cool, this is now live.

@finneganh I tried it out but it still doesn't seem to have the desired effect. I will check it out once more once I have some time.

I think I figured out why this is happening. Velocity is using Promises and returns a Promise for most functions. Yet in velocity-component.js you're calling the functions as if they are synchronous functions. I believe this might be causing issues with race conditions. I would suggest rewriting parts of the velocity component implementing promises to extend what Velocity is doing.. @finneganh

Interesting. I believe that the Promise bits have been added since velocity-react was written.
I can take a look. This will probably help if things like stop / finish are actually asynchronous, but not if the Promises are just an alternative to the complete callback for animations.

Hi,
I think I am facing a similar issue with the latest version of 'velocity-react'. I have something like this (where an element is added or removed from the transition group if active):
 <VelocityTransitionGroup enter={{animation: "transition.slideLeftIn", stagger: "200", duration: "400"}} leave={{animation: "transition.slideLeftOut", backwards: "150"}}>         {isActive && linksHTML} </VelocityTransitionGroup>
When i trigger the enter and leave animation really quickly, there are some really wierd visual sideffects happening where the animations are transitioning and canceling properly.
I decided to go back to an older version and realised that it worked fine in version 1.1.4 but any version after that it was a problem. One of the things I noticed was that a "|| ^15.0.0" was added to "react-addons-transition-group" in package.json in versions later than 1.1.4
As this package has moved to ''react-transition-group" I suspected it was a new version of that package that was a problem. So I built the latest version of 'velocity-react' but with older versions of "react-transition-group" and found that all versions before '1.2.0' worked fine in my application.
So I decided to look at the commits made in the 'react-transition-group' repo for the '1.2.0' tag and found this commit:
https://github.com/reactjs/react-transition-group/commit/b54588a81bef9cca981601d6b3227074510bc5cf
This looks like the most obvious offender out of all the pull requests merged in 1.2.0. I havn't looked into whats going on yet but thought I would share what I found.

@finneganh Any updates on that ? Having the same issue, but can't control anything if I use the VelocityTransitionGroup component 😢

I ran into this issue today, and had an idea.
Velocity accepts a begin option that runs when an animation is starting. Since the issue seemed to be that the partial height from a previous interruption gets "stuck" into the style and used as the new height, I figured I could use begin to reset the element's height to null before the animation begins.
And that works! slideDown no longer gets stuck at a previous interrupt point. But it's annoying to have to manually pass a begin option for every call to VelocityComponent, so I made a wrapper that automatically adds it for any slideDown animations.
class MyVelocity extends React.Component {
  constructor(props) {
    super(props);
    // https://reactjs.org/docs/handling-events.html
    this.begin = this.begin.bind(this);
  }

  begin(elements) {
    if ( 'slideDown' === this.props.animation ) {
      elements.forEach((el) => {
        if ( 'none' === el.style.display ) {
          el.style.height = null;
        }
      });
    }
  }

  render() {
    const props = Object.assign({}, {begin: this.begin}, this.props);
    return (
      <VelocityComponent {...props}>
        {this.props.children}
      </VelocityComponent>
    );
  }
}

Now you just use <MyVelocity /> the same way you'd use <VelocityComponent />, and it will keep your slideDown animations from getting stuck.
It's a bandaid, but for anyone tearing their hair out about this, I hope this helps.


Limit job listing to a much smaller subset of jobs

Currently the "all" query kills the DB, so we'll restrict the state list to active jobs (a much-smaller subset than all historical jobs") and we'll default it to show "scheduled" jobs. If we fix the performance problems, we can revert this back

Nice!


[elasticsearch][kibana] Add flexible ingress

[x] Chart version not bumped (the versions are all bumped and released at the same time)
[x] README.md updated with any new values or changes
[x] Updated template tests in ${CHART}/tests/*.py
[ ] Updated integration tests in ${CHART}/examples/*/test/goss.yaml

Fix #979

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

cla/check

jenkins test this please

jenkins test this please

jenkins test this please

LGTM but we need to keep backward compatibility

With no changes to our values, this change broke our Helm release. Is it the case that this chart does not follow semantic versioning? I would have expected a major version bump for this breaking change.

Hi @yurrriq,
This change has been updated to ensure backward compatibility.
It shouldn't have any impacts on existing release, that's why we removed the breaking change label.
If you had some issue with this change and your existing values, it's a bug.
Can you open a new ticket and provides all details required so we can investigate?

This change has been updated to ensure backward compatibility.

Unfortunately, that is not the case. The breaking change is here, where the schema for ingress.hosts was changed dramatically.

I have created https://github.com/elastic/helm-charts/issues/1090


fixed issues in component images

fixed spacing of px to rem indicator for style images
-updated some usage image bugs

do you want to remove the files with conflicts? not sure what happened here, possibly you were working off an out of date branch?

can we close this, or did you want to fix?

closing. feel free to reopen if needed


After entering game mode, the screen display is opposite to the direction of the controller

After entering the game mode, the displayed content is opposite to the direction of the controller, and it is impossible to rotate the screen in any way, resulting in the screen displaying exactly the opposite when correctly holding the controller.

The fixes for the Legion go are currently in the unstable branch, it looks like you're currently on the stable branch.
go to desktop mode, and run sudo frzr-deploy chimeraos/chimeraos:unstable in terminal, default pass is gamer

Hi Aarron,
Thanks for your quick reply.
I have already installed unstable version based on 8da6d18dc5d32d0e0b07857e10dc33b58b3e49c8 branch.
But I will try the command you suggested.
Thanks.

well that's odd.
okay, you can try this:
create a conf file at /home/gamer/.config/environment.d/01-my.conf
example: /home/gamer/.config/environment.d/01-my.conf
In the file, place the following:
export GAMESCOPECMD="/usr/bin/gamescope \
      -e \
      --xwayland-count 2 \
      -O *,eDP-1 \
      --default-touch-mode 4 \
      --hide-cursor-delay 3000 \
      --fade-out-duration 200 \
      --adaptive-sync \
      --force-orientation left "

You can change the --force-orientation left to whatever orientation you need.

Hi Aarron,
Thanks for your guide, but when I create the file and write the configure there, after rebooting system, it blocked here.

Too strange.

Hrm yeah, this is very strange.
Someone else recently was able to install unstable, and it worked on the Legion Go for them.
I guess we might need to wait for a ChimeraOS dev, and see if they have any ideas. Sorry that I couldn't be of any help.

Hrm yeah, this is very strange.
Someone else recently was able to install unstable, and it worked on the Legion Go for them.
I guess we might need to wait for a ChimeraOS dev, and see if they have any ideas. Sorry that I couldn't be of any help.

Thanks for your help, I'm trying to reinstall it and retry again, that's also confused me, two different operations, why. let me re-try it.
Thanks.

I just tried the unstable build and it fixed the orientation issue.
I noticed that you don't have button markings on your controller. Is this a pre-production unit? If so, that might explain why it's not working for you.


04875 bucket restructure hip

Description:
This PR adds the details of a Draft HIP for Bucket restructuring.
Related issue(s):
Fixes #4875
Notes for reviewer:
This is my fork and would like a way for the team to add their comments in here.
Checklist

[ ] Documented (Code comments, README, etc.)
[ ] Tested (unit, integration, etc.)

@steven-sheehy I have addressed all the comments I had answers to.

Since I don't have permission to resolve my own comments in this fork, I put a 🚀 at the end of each discussion item that I think can be resolved. That way you can resolve them on your side.


Error when destroying Swiper when clicking on a slide

This is a (multiple allowed):
[x] bug

Swiper Version: 4.0.3
Platform/Target and Browser Versions: Chrome/macOS

What you did
I use Swiper as icons for navigation in my app. I have click listener on my icon/slide that will do navigation and also destroy the Swiper (the react component is unmounted).
Expected Behavior
The Swiper disappears and leaves no trace. Did work fine in version 3.
Actual Behavior
There is a click event fired in Swiper after 300ms but at that time the Swiper is gone. Thus, an Error is thrown.
index.js:2177 TypeError: Cannot read property 'click' of undefined
    at swiper.js:1097
    at Array.forEach (<anonymous>)
    at Swiper.emit (swiper.js:1096)
    at swiper.js:2647

Have the same thing.


Spinner Font built-in not working in linux

Spinner is using built-in type fonts. These are not ttf file. so that i am unable to use it in Linux and other fonts ttf file not loaded symbol of increment and decrement. Please resolve it.
In src/elem folder xspinner.c file has acIncr for increment charactor but I am not getting how I can pass charactor in it

@abhishek1028 I documented this in my Builder FAQ
FAQ
Paul--

Where in code I call gslc_ElemXSpinnerSetChars() please send me link

Thanks for guidance

I have used faq instructions but not getting character for Inc and Dec of spinner using freemono font

I got it place of call function and fixed the issue thanks


[BUG] bias as nn.Parameter can't use GatheredParameters to get the model weight under the zero3 + offload

Describe the bug
Hi, everyone, I make a custom linear, when use zero3 + offload,  I can't get the bias weight from GatheredParameters.
this is my custom linear code:

this is log:
(Pdb) self.bias
Parameter containing:
tensor([], device='cuda:0', dtype=torch.bfloat16)
(Pdb) self.weight
Parameter containing:
tensor([[-0.0119, -0.0347, -0.0118,  ...,  0.0041, -0.0019,  0.0227],
[ 0.0146,  0.0229, -0.0015,  ...,  0.0476,  0.0503,  0.0718],
[-0.0049, -0.0217,  0.0173,  ..., -0.0132,  0.0173, -0.0189],
...,
[ 0.0493,  0.0075, -0.0229,  ..., -0.0231,  0.0152, -0.0267],
[-0.0166, -0.0092, -0.0053,  ...,  0.0124,  0.0337,  0.0062],
[-0.0349,  0.0121,  0.0126,  ...,  0.0101,  0.0049, -0.0153]],
device='cuda:0', dtype=torch.bfloat16)
How can I write code to obtain the weights of bias in ZeRO-3 mode?

sorry, I had solved it, close this issues


Financial Services

From Leo Donnachie,
For Financial Services Firm, the tool did not indicate which firms or sub-sectors are most exposed to carbon intensive sectors/industries. It could make use of various websites / reports that identify the bigger lenders to fossil fuel projects

Addressed


add pandas to requirements and update GitHub actions testing strategy

Codecov Report

Merging #962 (a6c9245) into master (1e2013b) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #962   +/-   ##
=======================================
  Coverage   71.43%   71.43%
=======================================
  Files          62       62
  Lines        9145     9145
=======================================
  Hits         6533     6533
  Misses       2612     2612

Continue to review full report at Codecov.

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


to_file and from_file are not implemented correctly: no compression

Json files are not compressed by monty when using to_file
See this MSONable2File class which uses json.dump instead of dumpfn
#in util.py
class MSONable2File:
    """
    Adds some very basic to_file and from_file methods common to
    all msonables in this package.
    """

    def to_file(self, filename):
        with open(filename, "w") as f:
            d = self.as_dict()
            json.dump(d, f)

        logger.info(
            f"Successfully wrote {self.__class__.__name__} " f"to file '{filename}'."
        )

    @classmethod
    def from_file(cls, filename):
        with open(filename) as f:
            d = json.load(f)
        return cls.from_dict(d)

Note probably most of the results.json.gz files need to be re-loaded and saved to disk!

I've created a pull request for resolving the above issue.


Graded games list should consider if you participated or not

The graded games list assumes you participated. The list should check if you're participating and give a special message for those not participating...

Sorry, I'm sure I understand this one (and it's from last year, oops). You should only be able rate games if you submitted something (with the exception of the "unfinished" constraint that was missing but should be in now).

The view where you see the games that you have graded so far in an event and what graded you have them along with nice graphs. That page doesn't check if you participated in the event or not according to me 5 months ago.

Looking around at the code, this isn't as straight forward as one could have hoped.
I can go about this way:
$Node.GetMy().then(r => $Node.Get(r.refs.games).then(r2 => r2.node.forEach(node => {if (node.parent.indexOf(featured.id) > -1) this.setState({'participating': true}));

Or similar.
I might be missing something, but I get the feeling the user object or the $Node.GetMy() should return event id:s participated in too...

You can check featured. There is some additional data in there (.what, .what_node, .focus) which tells you about your own participation. Probably best to wait until I get my "optimization-fixes" branch merged in though, as I did slightly change .what_node's format (batching improvements).

Alright, let me know when I can work on this then.


Symbols for stepping into testhost.exe source

Do you make symbols available anywhere with each release? If not, would you consider it?

@jnm2 There was an issue with publishing portable pdbs to the symbol server. It has been fixed (to publish the full pdbs) and you should be able to use it in a week's time when the archival requests are completed., @jayaranigarg fyi.

You sounds great! Just so I understand, this means I'll be able to step into the source of all the DLLs in https://www.nuget.org/packages/Microsoft.TestPlatform by including 'Microsoft Symbol Servers'?

This sounds great! Just so I understand, this means I'll be able to step into the source of all the DLLs in https://www.nuget.org/packages/Microsoft.TestPlatform by including 'Microsoft Symbol Servers'?


Feb 6th informal meetup with members and board

We get together on Monday, February 6 at 16.00 hrs at Tallinn University (convene in the lobby of Astra building at 15.55 or come directly to room 133- Mare from the sea-facing side).
The aim is to  get things moving and make an action plan for Open Knowledge Estonia.
Items to discuss:

short term business ( couple of months)

March 4th, International Open Data Day - what we want to see happen and organise ourselves?
other days, conferences, workshops - where we want to contribute? e.g. Tartu hackathon on post truth media sphere; e.g. Garage48 hackathon in May etc.
Digital Single Market conference in July and  MyData conference in August - how is OK-EE involved.

medium term business (2017)

collecting gaps and sorting out priorities  in  EST public data that should be opened
how to engage partners  ( in Estonia and internationally) and identify common aims and initiatives, e.g. need for Open Data Handbook translation and dissemination? or  how to build the  "business case" and bring out economic impact of OD?

I think there is a point in creating materials from OD community to community plus governement, businesses about how to use OD, what we expect etc. Currently there are only docs by government which are quite ok and cover much on OD handbook, but we probably need to split it into pieces and write materials oriented directly to different target groups. I think OD handbook itself is not relevant format for us though, this basic information is already in https://opendata.riik.ee/roheline-raamat and elsewhere.

On Monday, 6th February I have lectures and cannot participate. If there is anything where I can engage students then I can help more efficiently. Looks like IT College is organizing own hackathon.

collecting gaps and sorting out priorities in EST public data that should be opened

I'll  add here two resources:

Roof terms and principles from G8 Open Data Charter
https://www.gov.uk/government/publications/open-data-charter/g8-open-data-charter-and-technical-annex

Concrete valuation of a situation in Estonia. We could map first our situation for OpenData Index and then prioritize missing datasets, what could fill the gaps. This how we get initial demand list.
http://global.survey.okfn.org/

Extra input from the community.
Gather extra datasets what are not listed above and add to our demand list.

Memo Feb 6th meeting
People present:
Antti Poikola
Tanel Mällo
Märt Põder
Maarja-Leena Saar
Geoffroy  Berson
Adolfo Ruiz
Andres Kütt
Siim Tuisk
Events coming up
March 4th Open Data Day!
Tartu University  (Media department and computer studies) holds event son post truth in spring.
Märt will be involved to organize a pre-event on March 4.
Poliitika.guru blog and Tõnu Runnel? Data journalism actors? maybe Faktabaari share their method of checking media  articles?
NB! Good day to publish  the initial backlog : publish the site with initial input already gathered by that time.

which datasets are priority for users? how to get the seed going? take the categories and start digging out gaps. We will crowdsource  input and let gov  people cross-check if data is there and in good quality.
lets use the excel that was collected at Tartu hackathon
What to do with APIs that are not made public?: we gather information and publish!
categories might evolve into specific issues, each will  have a community of contributors

March 30,  Internet Day event:  Märt represents IOS and 5th freedom included in topics.
MyData Conference (Helsinki and Tallinn cross-border cooperation) in August

in Tallinn the day is more academic, questions of personal data

call for proposals for academic submissions will open soon.  Intl OK network involved (probably 10 - 15 persons, e.g Rufus Pollock)
should we organize OK community meetup separately?
regular weekly "talgud" meetups  (16.00 - 18.00 hrs on Thursdays in TLU) for volunteers/crowdsourced effort  in doing workbits for the conference.
Digital Single Market Conference
organized by gov, OK-EE members are in the content-formulating group. Rolls around ownership of data. Tanel will share regular updates on GitHub.

medium term activities

stakeholders mapping
a- contact  people by topic (especially those categories which do not have any input). e.g. Keegan - will provide his list) and Kalvet  and Krimmer from TTU
b-  Andres will bug gov info reps to join the issues and provide feedback. e.g. GeekOut data analysts who know which data is available

Communication channels and media plan is currently discussed under issue #4, please give your suggestions and arguments there!

All the topics have been moved further. Overview about activities made first year will be talked in General Meeting #22


python311Packages.queuelib: 1.6.2 -> 1.7.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python311Packages.queuelib is: A collection of persistent (disk-based) queues for Python
meta.homepage for python311Packages.queuelib is: https://github.com/scrapy/queuelib
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.7.0 with grep in /nix/store/ahbbf2pym3wxj2pbjnsxg5xwi9dfb3nb-python3.11-queuelib-1.7.0
found 1.7.0 in filename of file in /nix/store/ahbbf2pym3wxj2pbjnsxg5xwi9dfb3nb-python3.11-queuelib-1.7.0

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

11 total rebuild path(s)

11 package rebuild(s)

First fifty rebuilds by attrpath

python311Packages.queuelib
python311Packages.scrapy
python311Packages.scrapy-deltafetch
python311Packages.scrapy-fake-useragent
python311Packages.scrapy-splash
python312Packages.queuelib
python312Packages.scrapy
python312Packages.scrapy-deltafetch
python312Packages.scrapy-fake-useragent
python312Packages.scrapy-splash

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/ahbbf2pym3wxj2pbjnsxg5xwi9dfb3nb-python3.11-queuelib-1.7.0 \
  --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 python311Packages.queuelib https://github.com/r-ryantm/nixpkgs/archive/9993a754075fa6d81ba9b1449669b0d7dd0a3cbb.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/9993a754075fa6d81ba9b1449669b0d7dd0a3cbb#python311Packages.queuelib

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/ahbbf2pym3wxj2pbjnsxg5xwi9dfb3nb-python3.11-queuelib-1.7.0
ls -la /nix/store/ahbbf2pym3wxj2pbjnsxg5xwi9dfb3nb-python3.11-queuelib-1.7.0/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 --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

16 packages failed to build:

python311Packages.scrapy
python311Packages.scrapy-deltafetch
python311Packages.scrapy-deltafetch.dist
python311Packages.scrapy-fake-useragent
python311Packages.scrapy-fake-useragent.dist
python311Packages.scrapy-splash
python311Packages.scrapy-splash.dist
python311Packages.scrapy.dist
python312Packages.scrapy
python312Packages.scrapy-deltafetch
python312Packages.scrapy-deltafetch.dist
python312Packages.scrapy-fake-useragent
python312Packages.scrapy-fake-useragent.dist
python312Packages.scrapy-splash
python312Packages.scrapy-splash.dist
python312Packages.scrapy.dist

4 packages built:

python311Packages.queuelib
python311Packages.queuelib.dist
python312Packages.queuelib
python312Packages.queuelib.dist

Maintainer pings

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

20 packages built:

python311Packages.queuelib
python311Packages.queuelib.dist
python311Packages.scrapy
python311Packages.scrapy-deltafetch
python311Packages.scrapy-deltafetch.dist
python311Packages.scrapy-fake-useragent
python311Packages.scrapy-fake-useragent.dist
python311Packages.scrapy-splash
python311Packages.scrapy-splash.dist
python311Packages.scrapy.dist
python312Packages.queuelib
python312Packages.queuelib.dist
python312Packages.scrapy
python312Packages.scrapy-deltafetch
python312Packages.scrapy-deltafetch.dist
python312Packages.scrapy-fake-useragent
python312Packages.scrapy-fake-useragent.dist
python312Packages.scrapy-splash
python312Packages.scrapy-splash.dist
python312Packages.scrapy.dist


Format a Temporal object into a user-supplied string format

Similar to #2, but for string formatting instead of string parsing.
If #2 is adopted, an API using the same microformat could be proposed.
Advantages:
Sometimes it's necessary to obtain a string that fits a particular format that is neither ISO 8601 nor locale-sensitive. For these cases, third-party date libraries usually provide a formatting API.
Concerns:
In general, for human-readable strings, developers should not customize the format themselves, and use only the locale-specific formats provided by Intl.DateTimeFormat. While this functionality might be useful for formatting strings that must fit a certain format for machine-readability, providing such an API might result in worse user experiences because developers are tempted to use it for human-readable strings instead of Intl.DateTimeFormat.
Unlike parsing, this kind of functionality is easy to build in business logic.
Prior art:
TBD
Constraints / corner cases:
TBD

All I want is something like https://date-fns.org/v2.23.0/docs/format
eg. format(Date.now(), 'yyyy-MM-dd HH:mm:ss')
I have read the doc of DateTimeFormat and I don't think it can match my requirement.

I think strongly that Temporal should stick to the standards here.

I think strongly that Temporal should stick to the standards here.

It IS the standard: https://www.unicode.org/reports/tr35/tr35-dates.html#Date_Field_Symbol_Table
3rd-party libraries like moment, dayjs, date-fns are already very easy to use and their APIs are familiar. People choose to a new standard object that is not very stable, has learning costs and browser compatibility concerns mainly because it can reduce 3rd party library dependencies and publication code sizes.
If people still have to use 3rd-party libs for such a common use case formatting string, why do they have to learn something completely different?

@CarterLi I disagree. First of all, LDML is not a timestamp format standard, it is meant for localized formatting for i18n. We already allow localized formatting for Temporal objects via Intl.DateTimeFormat, so any such formatting can (and should) only be done using Intl.DateTimeFormat via Temporal.Foo#toLocaleString.
To a large extent, Intl.DateTimeFormat already allows customized formats like these, with the added benefit of making them locale-friendly.

I have a requirement to format some dates as either ‘8 Sep’ or ‘8 Sep 2020‘ (depending on whether the year is the current year or not).
toLocaleString('en') appears to insist that I want the month before the day, and the year separated by a comma – but I don't!
Is there a way to achieve those formats with the current APIs available?
If not, current APIs seem too rigid, and I would like to see custom formatting using tokens.
It has been an issue in the past that there have only been de-facto standards for such tokens, and it would be problematic to adopt any of these on a presumably arbitrary basis.
However, the Unicode Consortium is a standards body, and as part of the Locale Data Markup Language (LDML) have defined a standard set of pattern fields for date formatting (https://unicode-org.github.io/cldr/ldml/tr35-dates.html#Date_Format_Patterns).
As LDML is intended explicitly for locale-specific applications, and includes references to non-Gregorian calendars (such as the Chinese lunar calendar), it looks as if it would make a good fit for the Temporal proposal.
I hope I don‘t migrate to Temporal, and then still have to load the whole of a third-party module such as moment just to be able to generate custom formats.
Surely Unicode TR35 Part 4 (Dates) Section 8 (Date Format Patterns) would make a good basis  for Temporal custom formatting?

The discussion thread starting from https://github.com/tc39/ecma402/issues/554#issuecomment-796903218 might prove illuminating as to why there is caution about a formatter API.
I'm not sure whether your requirement

toLocaleString('en') appears to insist that I want the month before the day, and the year separated by a comma – but I don't!

means that you want to format dates with the day before the month and no comma, even in the en locale where that would be "incorrect" (at least, according to CLDR); or it means that you do actually want an internationalized date format but you are looking for the en-GB locale (or another en-?? locale, but I guessed GB based on the location in your GitHub profile).
In any case Temporal.Now.plainDateISO().toLocaleString('en-GB', { dateStyle: 'medium' }) seems to work for your purpose?

I hope I don‘t migrate to Temporal, and then still have to load the whole of a third-party module such as moment just to be able to generate custom formats.

It's more likely that a third-party module specifically for custom formatting would spring up, rather than loading Moment.

I can't believe this is even a debate. Formatting strings based on user-supplied specifiers is a standard across a wide range of languages and libraries. Sticking to only the "standards" is the kind of decision that gets made in ivory tower rooms of computer theory and completely ignores the needs of programmers dealing with the real, messy world that we have to code for.

I mean... this is a repo for incubating a proposal for the standard, and there are other programmers in this messy world that have needs that would conflict with just copying the API from date-fns ... so I guess I don't understand why it's so unbelievable that there is a discussion about this? In any case, it would be helpful if you could provide some details about your use case. The more we know about how people would use this API, the better.

Today, I wanted to get the following date/time format:
French: 2022-12-30 à 20 h 22 OR  2022-12-30 à 20:22
(20:22 isn't technically the format for use in sentences in French, but it's widely accepted as a more compact, more practical format to use for displaying times, compared to 20 h 22. Our design team isn't 100 % sure which format they want at this point.)
English: 2022-12-30 at 20:22
I couldn't find a way to do that with the current toLocaleString or DateTimeFormat options on offer.
Maybe there's an obscure locale that allows it, but the lack of a full documentation of all supported locales and the formats they provide anywhere that I could find isn't making the search easy.
Anyway, with this, I was able to get pretty close:
myDate.toLocaleString('fr-CA', {
  year: 'numeric',
  month: '2-digit',
  day: '2-digit',
  hour: 'numeric',
  minute: '2-digit',
})

// This is the same
myDate.toLocaleString('fr-CA', {
  dateStyle: 'short',
  timeStyle: 'short',
})

// Output: 2022-08-05 13 h 06

But the only way to get a separator in there that I found was:
const date =  new Date()
const formattedDate = new Date().toLocaleString('fr-CA', {
  dateStyle: 'short',
})
const formattedTime = new Date().toLocaleString('fr-CA', {
  timeStyle: 'short',
})
const formattedDateTime = `${ formattedDate } à ${ formattedTime }`

I do have a string translation library with variable insertion that allows me to do the English version of this pretty well, but isn't it unfortunate that I had to do that?
Basically, we have locales that define the "visuals" of the format. The order of the numbers. The separators between the numbers. The separators between hours and minutes. The separators between the date and time.
All of these factors can't be overridden. It's basically just magic that happens behind the scenes that we have no power over. I really, really wish I could pick fr-CA's defaults and work from there instead of having to either take all of its magic or none of it.
Additionally, I'm lucky; I'm from Canada, and the ISO-8601 representation of a date (just the 2022-12-30 part; not the whole machine-friendly string) is what JS understands as a short date for me. But what if someone wants that, but they're not aware of that? The built-in formatter is of no help to them.

Thanks for the detailed use cases! I agree, these would be good use cases for a string format minilanguage.
The point about starting from localized defaults and tweaking a few things is, I fear, difficult to write code for in a general case, so it's probably best to consider it for one or a few locales, like fr-CA and en-CA in your case.
You can pick fr-CA's defaults and work from there, using formatToParts(), which gives you the same localized string as toLocaleString() but broken up into segments that are tagged with the type of data that they represent. It probably gives you more information than you need and so your code using it would be on the verbose side, but could be encapsulated. For example, doing some of the stuff you mentioned:
function formatCustom(plainDateTime) {
  const formatter = new Intl.DateTimeFormat('fr-CA', {
    dateStyle: 'short',
    timeStyle: 'short'
  });

  const { year, month, day, hour, minute } = formatter
    .formatToParts(plainDateTime)
    .reduce((result, { type, value }) => {
      if (type !== 'literal') {
        result[type] = value;
      }
      return result;
    }, {});

  return `${year}-${month}-${day} à <strong>${hour}:${minute}</strong>`;
}

It would be easier to do things like this if formatToParts() gave more information about the purpose of each separator that it splits out, which is an issue that you could raise at https://github.com/tc39/ecma-402.
I do think that HTML and Markdown are out of scope for a facility that's part of the core JS language. Early JS included special HTML facilities like "my string".bold() that wrapped strings in HTML tags but those have been discouraged for a long time. In my opinion, a good formatting API should allow this but not give it special consideration.

What if we could do something like this?
const  localeDateFormatParams = Intl.getDateFormatParamsForLocale('fr-CA');
console.log(localeDateFormatParams);

// Would output something like:
const localeDateFormatParams = {
  separators: {
    afterDay: '-',
    afterMonth: '-',
    afterDate: ' à ',
  },
  // And much much more info about the minute details of how this locale works
}

And then use it like:
// An object for a locale would mean "I'm about to define to you the slightest details of a locale that may or may not exist"
const formatter = new Intl.DateTimeFormat(localeDateFormatParams, {
  dateStyle: 'short',
  timeStyle: 'short'
})

As for your code example, the existence of formatToParts is interesting and I didn't know about it, but wouldn't it be simpler to simply format the date and time separately in fr-CA or en-CA or a combination of both? Way fewer lines.

It would be fewer lines to use dateStyle and timeStyle separately if you only need to change the date/time separator string, but I intentionally did it the long way to illustrate what you might do to replace the h separator with a colon as well.
ECMA-402 have previously indicated that they are skeptical about such changes to Intl.DateTimeFormat: https://github.com/tc39/ecma402/issues/554#issuecomment-796903218 There is a data-driven API being discussed at https://github.com/tc39/ecma402/issues/210 that I think would address this.

Oh, I see! Thanks. :)
My sneaky way out of the colon issue was to use en-CA for the time no matter what language the page is being displayed in lol

I think the problem with string formatting is the concept and idioms themselves are very English-centric.
For example, most implementation assumes

MMMM to be January and MMM to be Jan
DDDD to be Monday and DDD to be Mon

However, this does not even translate to other Latin alphabet languages, for example in French, the equivalent of 3-letter month is 4 letters -- janv. for Jan and févr. for Feb. Does that mean we need to use MMMM for short month in French? And maybe MMMMM for long form? (Ref).
Also how does the string format apply to languages where people do not use space separators? (e.g. Asian languages) Does MMMM mean two 2-letter MM? (e.g. MM+MM) or does it mean 4-letter MMMM?

We just need to find the language with the most different ways to express, say, a month, and prepare a scale of complexity based on that. After that, it's probably relatively trivial to just simplify for the sooner languages. The concept of a short month doesn't exist in your language at all? Great! When you ask for a short month, you get the only month that exists.

OK, in that case, let's say the hypothetical "most different" language is some French dialect and their 4-letter word abbreviation for Month is represented by MMMM. The 1-3 letter spots (M, MM, MMM) are occupied by different numeric month representations.
Since as you say just simplify for simpler languages and English is simpler:

M, MM, MMM -- numeric month
MMMM -- Jan, Feb, Mar..
MMMMM -- January, February...

Would you be happy with that? I am pretty sure not.

I'd be satisfied with that. It may not be the ideal solution, but it'd be a workable solution.
A workable solution is much better than "let's not have a solution because there is no absolutely perfect one".
Though "MMMM" and such isn't the only model in existence. We could, for example, do templates with keywords that would be a bit more explicit than repeated letters.
This is just me improvising, but keywords like ${ monthTwoLetters } would be hard to misunderstand. Or maybe we could take a page out of PHP's book with percent signs and lowercase/uppercase letters. Not explicit and will require frequent referring to the docs, but short.
There are lots of possibilities. We should strive to choose the one(s) that will apply best to the most use cases. But even if there isn't a solution that will perfectly match every use case, I think it'll still be a significant win if we can cover most of them.

I think the problem with string formatting is the concept and idioms themselves are very English-centric.

This is however commonly accepted in programming and that's not going to be changed by one datetime library.
The primary use-case for strftime is not producing human-readable localized strings, but rather producing consistent machine-readable strings for things like log files, console output, model fields, filenames, URLs, DSLs, etc., where ISO-8601 is not suitable and the localization features of toLocaleString/DateTimeFormat actually hinder consistency.
As wonderful as they are, ISO-8601 and RFC 3339 do not suit all use-cases, there are reasons to need things like these:

date +"%Y-%m-%d_%H-%M-%S_%s" -> 2024-03-08_12-12-50_1709928770 (for filenames)
date '+%Y:%s%5N' -> 2024:170992885283002 for a year + unix timestamp with specific precision (e.g. for a yearly report file where a human needs to be able to see what year it applies to, but the exact time should be only machine-readable ts format to avoid implying it's a monthly/daily report to the human)
date +"%m/%d/%H/%M:%S" -> 03/08/12/17:09 for assembling a URL where only month, day, and hour are folders but the minute+second entries are a file
for preparing dates for DSLs (e.g. SQL, JQL, GQL, Excel formulas, config files like INI/YAML, etc. can all store and expect a wide variety of delimiters & formats in real world applications)
etc. just think of more constraints in real life around special characters, whitespace, implied precision, etc. and you can quickly find situations where machine readable timestamps are vastly easier to format in strftime-style than trying to shoehorn Intl.DateTimeFormat or manually slice and re-assemble ISO-8601.

It doesn't need to be the recommended or primary way of producing date strings, but because it's such an industry standard it would remove the need for external packages just to access this feature. As it stands now, strftime is one of the main reasons why people install external JS libraries like moment.js, date-fns, etc.
There's a reason strftime is so popular already, and we cannot honestly say that all of its existing use-cases are mis-uses (even if we're trying to push people towards localizing all datetimes by default). I think Python's datetime library strikes a great balance here as it provides both strftime and DateTimeFormat-style localization options.

Of course you can technically achieve these examples with some hand-written string slicing and assembling code right now: https://github.com/tc39/proposal-temporal/issues/2501#issuecomment-1986520974 but the whole point of strftime and yy:mm:dd equivalents are to remove these common, often-repeated, often subtly broken hand-written string formatting functions across the world's codebases and follow the principle of least surprise.

This is however commonly accepted in programming for developer-facing strings and that's not going to be changed by one datetime library.

String format syntaxes are divergent across languages / libraries even only counting English. Unless someone is willing to do the leg work to go to a standards body getting agreement by at least a dozen different countries or a few different industries, this would pretty much be xkcd on Standards

I've not found that to be the case, see the links I posted for the spec for each language above above. They almost all use a common set of strftime parameters or TR35, with only a few variations here and there (e.g. java's SimpleDateFormat uses u for Day number of week).
Since both strftime and TR35 are already well established, we definitely just use one or the other, not create a new standard.

Regardless of whether strftime/TF35 functionality is ultimately incorporated into Temporal and TC39, is there an existing proposal or candidate reference implementation polyfill elsewhere?
I do have an opinion, and I've already expressed it with emoji in this thread, above, but I also need an interim solution for dealing with a frustrating number of non-standard machine-readable formats when calling or linking to third-party services for reservations. I found a ton of modules, articles, blogs, and code snippets, but if one or more are on a future proposal track, that would be good to know here. I very much expect that many of the other folks coming here and reading this thread will be in the same situation and might be dealing with a bit of "analysis paralysis" trying to choose.

Nothing is on a proposal track at the time of writing. I'm not aware of any such libraries built on top of Temporal.
If I had time, I'd develop one or more lightweight libraries for formatting and parsing using various picture string formats (strftime, TR35, etc), to see what sticks in the ecosystem and to help with adoption of Temporal. But that's realistically not going to happen until Temporal v1 is stable.
So if you feel motivated to do it, go ahead!


I keep getting error message that software needs an update.

Hello there! First of all thank you for KCC! I’m only new to e-reading and I saw this. Unfortunately I can’t install it. I keep on getting this error message.

I downloaded both the latest for macos. I'm not sure if I'm doing it right. Just trying my luck. Thank you!

@nikitarthbn
You need to right click open to open unsigned apps.
KCC doesn't have an apple developer account.

@axu2 oh that's why 😹 thank you!


Does not support /url-path

Tried to run wstunnel behaind nginx on my site on /myprox url, and cannot connect to it from client
on client side i ran
wstunnel -v -D 1080 wss://myhost.domain.com:443/myprox
and got error
wstunnel: Invalid port number `443/myprox`
CallStack (from HasCallStack):
  error, called at app/Main.hs:115:31 in main:Main

It will be great to support urls

Hello,
You need to use the upgradePathPrefix option
                                                will show up in the http path
                                                in the upgrade request. Useful
                                                if you need to route requests
                                                server side but don't have
                                                vhosts


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-k8s-26-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 2725

Questions ?
Please refer to the Backport tool documentation


Standardize parameters and README for components (part 1)

The following parameters need be standardized as described https://github.com/epam/hub-kubeflow-components/issues/53 :

[x] argo
[x] cert-manager
[x] dex
[x] etcd
[x] external-dns
[x] istio-base
[x] istio-discovery
[x] istio-ingressgateway
[x] kfserving
[x] knative-eventing
[x] knative-serving
[x] knative
[x] kserve-model-ui
[x] kserve
[x] kubebench
[x] kubeflow-authn
[x] kubeflow-centraldashboard
[x] kubeflow-common

@NellyHargeliya  Quick feedback: helm.chart.version is incorrect. Proper name should be helm.version
@seseque probably related to your work as well

@NellyHargeliya  @seseque please let me know when the swill be merged and feature-branch will be deleted (54-standardize-parameters-and-readme-for-components-part-1)  foundation for rancher updated to feed components from this branch. See: epam/llmops-hub#5


Add Topic: Probability

Add the file Topics.Probability with some simple exercises about probability theory, independence of sets, definition of conditional probability and Bayes' theorem.

[ ] depends on: #12

You should also add the file to the list of topics files at the bottom of 03Forall.lean (in both exercises and solutions).

For future reference: the script mk_exercises.py generates the exercise files from the solution files (if the solution file is properly marked with -- sorry comments)

The new probability file should probably get -- sorry commands so that the script also works for it.

Thanks! Indeed it needs to be adapted to work with mk_exercises.

@LorenzoLuccioli You just need to commit the suggested changes and run:
python3 mk_exercises.py

Ok, now it looks good to me.
Thank you again @LorenzoLuccioli!


Lazily materialize the null buffer builder for all array builders.

Is your feature request related to a problem or challenge? Please describe what you are trying to do.
We have seen obvious performance improvement by lazily materializing the null buffer builder (please see the primitive builder or the boolean array builder). We want to use the optimization across all array builders.
Describe the solution you'd like
Instead of modifying each array builder one by one, I want to declare a new type: NullBufferBuilder
struct NullBufferBuilder {
    bitmap_builder: Option<BooleanBufferBuilder>,
    length: usize,
}

impl NullBufferBuilder {
    fn append {...}
    fn finish {...}
    ...
}

Then, let each array builder to use it.
Describe alternatives you've considered
We could not do this.
Additional context
Thank for the thought from @tustvold https://github.com/apache/arrow-rs/pull/2117#discussion_r926879313

I will work on this.


AttributeError: module 'openai' has no attribute 'ChatCompletion'

Traceback (most recent call last):
File "C:\Users\podpo.conda\envs\chatdev\lib\site-packages\tenacity_init_.py", line 382, in call
result = fn(*args, **kwargs)
File "C:\Users\podpo\Desktop\ChatDev-main\ChatDev\camel\utils.py", line 145, in wrapper
return func(self, *args, **kwargs)
File "C:\Users\podpo\Desktop\ChatDev-main\ChatDev\camel\agents\chat_agent.py", line 191, in step
response = self.model_backend.run(messages=openai_messages)
File "C:\Users\podpo\Desktop\ChatDev-main\ChatDev\camel\model_backend.py", line 70, in run
response = openai.ChatCompletion.create(*args, **kwargs,
AttributeError: module 'openai' has no attribute 'ChatCompletion'
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "C:\Users\podpo\Desktop\ChatDev-main\ChatDev\run.py", line 114, in
chat_chain.execute_chain()
File "C:\Users\podpo\Desktop\ChatDev-main\ChatDev\chatdev\chat_chain.py", line 163, in execute_chain
self.execute_step(phase_item)
File "C:\Users\podpo\Desktop\ChatDev-main\ChatDev\chatdev\chat_chain.py", line 133, in execute_step
self.chat_env = self.phases[phase].execute(self.chat_env,
File "C:\Users\podpo\Desktop\ChatDev-main\ChatDev\chatdev\phase.py", line 291, in execute
self.chatting(chat_env=chat_env,
File "C:\Users\podpo\Desktop\ChatDev-main\ChatDev\chatdev\utils.py", line 77, in wrapper
return func(*args, **kwargs)
File "C:\Users\podpo\Desktop\ChatDev-main\ChatDev\chatdev\phase.py", line 130, in chatting
assistant_response, user_response = role_play_session.step(input_user_msg, chat_turn_limit == 1)
File "C:\Users\podpo\Desktop\ChatDev-main\ChatDev\camel\agents\role_playing.py", line 242, in step
assistant_response = self.assistant_agent.step(user_msg_rst)
File "C:\Users\podpo.conda\envs\chatdev\lib\site-packages\tenacity_init_.py", line 289, in wrapped_f
return self(f, *args, **kw)
File "C:\Users\podpo.conda\envs\chatdev\lib\site-packages\tenacity_init_.py", line 379, in call
do = self.iter(retry_state=retry_state)
File "C:\Users\podpo.conda\envs\chatdev\lib\site-packages\tenacity_init_.py", line 326, in iter
raise retry_exc from fut.exception()
tenacity.RetryError: RetryError[<Future at 0x1e6f90f3dc0 state=finished raised AttributeError>]

It should be openai.completions.create. as per Openai API defintion.
(This one I recognize as a code suggestion flaw Openai often does ;-))

is your version of openai pinned at 0.28.x? (or at least below 1.0.0)
openai 1.0.0 brought a huge change to how the API works and this caught me out the first time - namely because I tend to install everything, then update everything, then run... which then made errors galore.

we have updated the openapi. please pull the latest code and try again.


ACM-14672: Set externallyProvisioned in IBI BMH template

Summary
This PR sets the externallyProvisioned: true BMH spec field for the IBI template.
Resolves: https://issues.redhat.com/browse/ACM-14672

/retest siteconfig-acm-212-on-pull-request


If there are multiple members for Airtable with the same email, the most recent should be used.

Is this logic available at the testing level? Via a package?

Duplicate


First commit of SageMaker file

I have done the following and successfully pushed my code from SageMaker to Github. Requesting your review of the same.
Initially I was facing some challenges in using the personal authentication token to push my changes to Github. I solved it later by pulling the latest copy of development branch.
The steps I followed are as follows:

Created Personal Authentication token for connecting my github account to Amazon SageMaker
Pulling the latest copy of development branch using "git pull"
Creating modifications to run the Clutering algorithm on SageMaker
Committing and pushing changes made back to a new branch "sage-maker-clustering"

Hey Eftu, this commit has 193 files in it.... I don't think that is what you want to commit for this issue.


VPE: "Open File" for custom component should display the definition or be disabled

Describe the issue

To Reproduce
Steps to reproduce the behavior:

Create RTS pipeline
Add a custom component to canvas
Open node's context and observe behavior after selecting "Open File"
See error

Screenshots or log output
If applicable, add screenshots or log output to help explain your problem.
Log Output

Paste the log output here.

Expected behavior
A clear and concise description of what you expected to happen.

Option is either disabled for custom component
Or launches a viewer for for component definition (YAML file or .py file for AA)

Deployment information
Describe what you've deployed and how:

Elyra version: 3.0/master

This appears to be a regression. See screen capture in https://github.com/elyra-ai/elyra/issues/1845, which rendered this as disabled

Still reproducible using 3.0/master pulled on 7/29.

Need to update pipeline-editor to v0.11.3

@lresende


caw download URL from a ChRIS different from the logged in one results in 401

Affected versions: 0.3.1
How to reproduce:

have two instances of ChRIS
caw --address https://chris-one.example.com/api/v1/
caw --address https://chris-other.example.com/api/v1/uploadedfiles/3/

Program tries to use a token for chris-one to authenticate with chris-other.

Fixed in https://github.com/FNNDSC/caw/commit/8fca7e3d7994e90926a7a08c0b577dfae5fc5dbd


Update links to point to GC

Updating built-in policy definition and policy initiatives links to point to guest configuration specifically

@michaeltlombardi

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


Support hiredis 0.6.0

It was recently released with no API changes as far as I can tell.
https://github.com/redis/hiredis-rb/compare/v0.5.2...v0.6.0

hiredis 0.6 has been around for quite some time, and now that ActionCable (from Rails) is depending on em-hiredis we have a dependency conflict.
Bundler could not find compatible versions for gem "hiredis":
  In Gemfile:
    hiredis (~> 0.6)

    rails (= 5.0.0.beta1) was resolved to 5.0.0.beta1, which depends on
      actioncable (= 5.0.0.beta1) was resolved to 5.0.0.beta1, which depends on
        em-hiredis (~> 0.3.0) was resolved to 0.3.0, which depends on
          hiredis (~> 0.5.0)

Now that Rails seems to use it and the new version (0.6.1) works without problems on Windows (pure-Ruby-fallback), it might be nice to upgrade em-hiredis as well.

Yes please upgrade to 0.6.1 ...

Merging #48 and cutting a release could fix this.

Ouch, it's still not actually fixed in released gems... Github might've interpreted "Fixes" as an auto-closing verb.  My bad.

Yes I noticed that. Will get round to releasing in the next day or so. Actually having merged I think it's better to leave the dependency as ~> 0.6.0 so I'll revert before releasing. I don't think there's any reason to prefer 0.6.1, so better to leave the dependency loose. Thanks for the prod!

Only 0.6.1 will install flawlessly on Windows

Just a note that this is still disrupting Rails. Can we cut a release soon?

I have just released 0.3.1 which requires ~> 0.6.0. Hope this helps.
@badboy thanks – however keeping the dependency loose shouldn't cause issues; anyone running a clean bundle install or bundle update will get 0.6.1 assuming they have no other hard dependencies on 0.6.0.

Woohoo.  Least surprise FTW.  Thanks.
On Wed, Jan 27, 2016 at 2:55 PM Martyn Loughran<EMAIL_ADDRESS>wrote:

Closed #39 https://github.com/mloughran/em-hiredis/issues/39.
—
Reply to this email directly or view it on GitHub
https://github.com/mloughran/em-hiredis/issues/39#event-528906181.


Replace parse calls

The parse calls create a JavaParser instance that uses a shared configuration  object.
While trying to fix the windows build this turned out to be problematic with the preserver formatting feature.
This PR replaces most of the JavaParser.parse* calls used to create AST nodes with manual creation.
Not all of them have been replaced yet, but with those changes the next steps should be easier.

Windows still breaks? Or is this PR a precondition for them to not break anymore?

Or is this PR a precondition for them to not break anymore?

Its a precondition and it might need another one. I wanted to keep the PRs small and comprehensible.


Add an option to show sizes of used types using -Zprint-type-sizes

Compiling with cargo +nightly rustc -- -Zprint-type-sizes provides a nice type size printout that would be nice to have on the playground. Example from https://nnethercote.github.io/perf-book/type-sizes.html:
print-type-size type: `E`: 32 bytes, alignment: 8 bytes
print-type-size     discriminant: 1 bytes
print-type-size     variant `D`: 31 bytes
print-type-size         padding: 7 bytes
print-type-size         field `.0`: 24 bytes, alignment: 8 bytes
print-type-size     variant `C`: 23 bytes
...

It would be very handy to be able to quickly see this output in the playground, to help validate layout concerns. All that is needed is an extra button that directly displays the compiler output, or optionally strips the leading print-type-size  first.

Relevant: https://github.com/rust-lang/rust/issues/69852


Frontend - Centering Columns in Repo Groups

Currently the Repo Groups table has column headers slightly to the left of the content beneath them, we will adjust these headers to be centered along with the content they are above.

We decided to add new pages for our frontend instead of modifying existing ones.


chore(deps): update common-dev-assets digest to 9ec1a51

This PR contains the following updates:

Package
Update
Change

common-dev-assets
digest
6131edf -> 9ec1a51

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 2.1.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[AutoPR sql/resource-manager] typo: sql/resource-manager/Microsoft.Sql

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/4783

(message created by the CI based on PR content)

Codecov Report

Merging #4004 into restapi_auto_sql/resource-manager will increase coverage by 0.12%.
The diff coverage is n/a.

@@                          Coverage Diff                          @@
##           restapi_auto_sql/resource-manager    #4004      +/-   ##
=====================================================================
+ Coverage                              55.93%   56.06%   +0.12%
=====================================================================
  Files                                   9420     9376      -44
  Lines                                 189773   188300    -1473
=====================================================================
- Hits                                  106159   105569     -590
+ Misses                                 83614    82731     -883

Impacted Files
Coverage Δ

...operations/recommended_elastic_pools_operations.py
24% <ø> (ø)
:arrow_up:

...gmt-sql/azure/mgmt/sql/models/metric_definition.py
45.45% <ø> (ø)
:arrow_up:

...re/mgmt/sql/models/recommended_elastic_pool_py3.py
29.41% <ø> (ø)
:arrow_up:

...mgmt-sql/azure/mgmt/sql/models/job_schedule_py3.py
40% <ø> (ø)
:arrow_up:

...sql/azure/mgmt/sql/models/metric_definition_py3.py
45.45% <ø> (ø)
:arrow_up:

...e/mgmt/sql/operations/job_executions_operations.py
15.64% <ø> (ø)
:arrow_up:

.../azure/mgmt/sql/models/recommended_elastic_pool.py
29.41% <ø> (ø)
:arrow_up:

...ure-mgmt-sql/azure/mgmt/sql/models/job_schedule.py
40% <ø> (ø)
:arrow_up:

..._07_01/models/role_assignment_create_parameters.py
66.66% <0%> (-3.34%)
:arrow_down:

...01/models/role_assignment_create_parameters_py3.py
66.66% <0%> (-3.34%)
:arrow_down:

... and 67 more

Continue to review full report at Codecov.

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

This PR has been merged into https://github.com/Azure/azure-sdk-for-python/pull/3769


Add support for "docker compose" in mage

docker-compose has now been replaced with docker compose. See https://stackoverflow.com/a/66516826 for a brief explanation.
On newer system, the existing mage commands dont work out of the box.
This PR updates the mage system to support either based on an environment flag.
Sample invocations on my system (only has docker compose, no docker-compose):
$ GRAFADRUID_USE_DOCKER_COMPOSE_V2=0 /home/azureuser/go/bin/mage env:restart
Error: failed to run "docker-compose down: exec: "docker-compose": executable file not found in $PATH"

$ GRAFADRUID_USE_DOCKER_COMPOSE_V2=1 /home/azureuser/go/bin/mage env:restart
[+] Running 10/10
 ⠿ Container druidgrafana-historical-1     Removed                                                                                0.6s
 ⠿ Container druidgrafana-router-1         Removed                                                                                0.7s
 ⠿ Container druidgrafana-grafana-1        Removed                                                                                0.4s
 ⠿ Container druidgrafana-toolbox-1        Removed                                                                                10.3s
 ⠿ Container druidgrafana-middlemanager-1  Removed                                                                                0.7s
 ⠿ Container druidgrafana-broker-1         Removed                                                                                0.5s
 ⠿ Container druidgrafana-coordinator-1    Removed                                                                                0.4s
 ⠿ Container druidgrafana-zookeeper-1      Removed                                                                                0.6s
 ⠿ Container druidgrafana-postgres-1       Removed                                                                                0.3s
 ⠿ Network druidgrafana_default            Removed                                                                                0.1s
WARN[0000] mount of type `volume` should not define `bind` option
[+] Running 1/3
 ⠿ Network druidgrafana_default        Created                                                                                0.1s
[+] Running 3/3uidgrafana-zookeeper-1  Creating                                                                                0.1s
 ⠿ Network druidgrafana_default          Created                                                                                0.1s
 ⠿ Container druidgrafana-zookeeper-1    Created                                                                                0.2s
 ⠿ Container druidgrafana-postgres-1     Created                                                                                0.1s
 ⠋ Container druidgrafana-coordinator-1  Creating                                                                                0.1s
WARN[0000] mount of type `volume` should not define `bind` option
[+] Running 10/10of type `volume` should not define `bind` option
 ⠿ Network druidgrafana_default            Created                                                                                0.1s
 ⠿ Container druidgrafana-zookeeper-1      Started                                                                                1.1s
 ⠿ Container druidgrafana-postgres-1       Started                                                                                1.1s
 ⠿ Container druidgrafana-coordinator-1    Started                                                                                1.4s
 ⠿ Container druidgrafana-router-1         Started                                                                                2.5s
 ⠿ Container druidgrafana-toolbox-1        Started                                                                                2.3s
 ⠿ Container druidgrafana-historical-1     Started                                                                                2.3s
 ⠿ Container druidgrafana-middlemanager-1  Started                                                                                2.7s
 ⠿ Container druidgrafana-broker-1         Started                                                                                2.6s
 ⠿ Container druidgrafana-grafana-1        Started                                                                                3.1s

Ingesting example data into Druid
Beginning indexing data for wikipedia
Waiting for broker to become available...
Waiting for broker to become available...
Waiting for broker to become available...
Datasource wikipedia already present - skipping (use -F/--force to ingest anyway)

Druid: http://localhost:8888
Grafana: http://localhost:3000 (use druid/druid to login)

I like this change, thanks for your contribution!

Thank you @ApoorvGuptaAi !!! LGTM :)


Layout improvement

Problem

What's the story exposing the problem the users are facing

The previous top bar disappears as it was useless (it only had the Studio logo and some links to stuff not related to Studio). Instead, it's now holding the name of the service (AsyncAPI file) we're developing and a few buttons to customize the layout. These are just the buttons that used to be on the sidebar, i.e., toggle Navigation, Docs, Diagnostics, etc.
But probably, the biggest change here is the introduction of this new sidebar on the left. It contains a bunch of buttons and also the avatar of the user. This new sidebar is meant to be the navigation for the whole application, meaning it's not just for the code editor as it was before. The purpose of this sidebar is to navigate to other parts of the application like Services, Governance, Settings, and more.
In general, now the layout is accommodated to start growing the application in a friendly and sane way.
Solution

Proposed solution with mockups, views ...

Link to Figma: https://www.figma.com/proto/bPMB3lkMTOOMuKk0oGLuNm/Studio?type=design&node-id=144-4141&scaling=contain&page-id=0%3A1&starting-point-node-id=2%3A2
Rabbit holes

Potential technical, design ... challenges

To incorporate this change, we plan to leverage the new design system (refer to issue #636) as our foundation. Before adding the components into studio, it's crucial to ensure they are first integrated into the design system, in case they are not already included.

Scope

Describe a list of tasks or issues that needs to be done ( you don't need to have an exhaustive list of all the tasks in the beginning)

[ ] SideBar
[ ] TopBar

Out of bounds

What won't be part of the scope

Success criteria

How do we know we made a good bet

Hey @Amzani Let me know if you require assistance in solving this issue. I can pick it up if the issue is unblocked. I'll go through the issue and clarify any requirements once I get the go-ahead from your end.

Hi @divyammadhok This work will start after cycle 1 is done: https://shapeit.app/projects/org/asyncapi/16/cycles/e4232524
I'll ping you here so you can contribute once we start the cycle 2.

Thanks @Amzani Sounds good!

Do we want to wait until the next architecture https://github.com/asyncapi/studio/issues/725 is completed before integrating the components ?
Any thoughts ? @Shurtu-gal @fmvilas @KhudaDad414

Yeah we wouldn't want to increase the task of migration by adding components before everything is decided.

@Amzani Can you share the access to this channel

@divyammadhok sorry for the silence. There have been summer holidays recently and @Amzani probably missed your message. You can sign in to our Slack here: https://asyncapi.com/slack-invite. After that, you'll be able to see the content of this link. Hope that helps.

Hey @fmvilas Got through your message now, and I believe that the link is not valid anymore. Can you please ping this to me again? I'll make a note of joining it on time.

Hii @Shurtu-gal  @Amzani @KhudaDad414

Is there been any plan on how to show the user avatar dynamically?

We don't need to add the avatar as we don't support users (signin/signup) in studio @utnim2

We don't need to add the avatar as we don't support users (signin/signup) in studio @utnim2

@Amzani many parts of the studio are not completed yet that us there in the figma file
should i proceed with the part that is present ?
Thanks

Best to coordinate with @Shurtu-gal as he is working on the NextJS migration, I suggest to add this enhancement as part of the new app in apps/studio-next

@utnim2 @Shurtu-gal is working on https://github.com/asyncapi/studio/pull/997 (still under review), you will need this.

i am working on sidebar and the topbar

We need to add the topbar and the sidebar as the design provide right?
cc @Amzani @Shurtu-gal
i am taking this, if no one is working in it


Suggestion: custom loaders for webpack integration.

Please see my prior issue. (https://github.com/Microsoft/TypeScript/issues/11975)
Scenario
I have a pretty normal looking react project layout.
project/
├── node_modules
├── src
│   ├── modules
│   └── components
├── webpack.config.js
└── tsconfig.json

I have the following goals.

Import commonjs modules from /node_modules.
Don't import modules from $HOME/node_modules.
Import es6 modules from /src by name (not by relative path)
Import css modules and generate default typescript export on the fly.
Import react components with inline HTML in JSX syntax.
Import typings from /typings.
Import typings from /node_modules/@types.
Build project with webpack.

It's unclear how to accomplish my entire list. Webpack works great for JavaScript, but the issue is TypeScript can never find anything. I want static typing but it's too difficult to figure out. Instead, I end up with a hybrid code base.
Solution
See Jest transform for inspiration.
It would be nice if TypeScript allowed user defined resolution and file reading functions. I'd imagine the types could look like this:
resolveModule(absolutePath: string, moduleName: string): Promise<FileDescriptor>
readFile(absolutePath: string): Promise<NodeBuffer, SourceMap?>

I could provide nodejs modules that adhere to the interface.
{
    compilerOptions: {
        resolveModule: "./config/typescript/resolve.js",
        readFile: "./config/typescript/read.js",
    },
}

It would open up a world of possibilities for developers without needing constant changes to TypeScript core. The most popular strategies (like commonjs and typescript) could be bundled as a string constant instead of a path to code.
// tsconfig.json

{
    compilerOptions: {
        resolveModule: "commonjs",
        readFile: "typescript",
    },
}

If I want to do unusual things, like import image files as type string or parse CSS files for safe css module access, I should be allowed. The concept is similar to webpack loaders.
It's simple and configurable. It doesn't lock developers into using specific file extensions, or module resolution strategies, or frameworks, or build systems. TypeScript should just check types, and let developers provide modules and definitions as needed.

The only thing that I believe is currently problematic is

Don't import modules from $HOME/node_modules

I often get get types from parent directories that are incidentally on disk.
For the remaining items this does the trick:
tsconfig.json
{
    "compilerOptions": {
        "moduleResolution": "node",
        "target": "es2015",
        "module": "es2015",
        "jsx": "react",
        "allowSyntheticDefaultImports": true,
        "baseUrl": "src",
        "paths": {
            "*":[
                "modules/*"
            ]
        }
    }
}

globals.d.ts
declare module '*.css' {
    const css: React.CSSProperties;
    export default css;
}

src/main.tsx
import $ from 'jquery'; // typings/globals/jquery/index.d.ts
import * as React from 'react'; //<EMAIL_ADDRESS>import {render} from 'react-dom'; //<EMAIL_ADDRESS>import square from 'square'; // src/modules/square.ts
import style from 'main.css'; // anywhere.css

export default () => render(
    <div style={style}>
        {square(4)}
    </div>,
    $('#app')[0]
);

Sorry I think I misunderstood the issue. Are you asking for the language service to parse the CSS files?
I think
resolveModule: "./config/typescript/resolve.js",

would be immensely valuable but that
readFile: "typescript",

is not a good idea.

Thanks for the tsconfig.json example. I updated mine to what you suggested. I had it working except for importing folders using index.ts or index.tsx which is now fixed.
With respect to this issue, I guess it's two separate parts.

Complete control of mapping module name to absolute path. It could "include batteries" for normal setups.

Some way to preprocess non-typescript imports to either lookup or generate .d.ts. It's a general solution for typings vs @types and would allow cool stuff like importing assets safely in webpack, or even loading file formats that don't exist yet. I realize that could be a bit out of scope.

I hope this makes sense.

It makes sense but I'm not sure if there is any reason to couple the two things because given the first capability, the second is just a matter of generating declaration files to describe the shape of these files.
The first definitely seems in scope but the second is not currently a TypeScript concern and does not need to be for this to work. Ultimately, it is some other tool, e.g. a Webpack plugin that would actually provide the runtime values for these assets. That is perfect, the TypeScript compiler doesn't care about that - all it needs is a type declaration.

Ultimately, it is some other tool, e.g. a Webpack plugin that would actually provide the runtime values for these assets. That is perfect, the TypeScript compiler doesn't care about that - all it needs is a type declaration.

I think we're in agreement.
For sure, TypeScript does not need to know css. It just needs to allow configurable function to map a non-TypeScript import to a real or virtual .d.ts file. Webpack will actually load the css, but TypeScript needs to know the definition of the import so it can find errors in the .tsx code.
I'm ignorant in TypeScript compiler internals, but in theory it works the same way as a JavaScript file import, where you need to map a non-TypeScript (in this case JavaScript) file to the corresponding definition file. It's just a bit more general.

Technically this is not quite right since TypeScript handles JavaScript code just fine and infers tons of information from and can also transpile it directly. I think they key point is pluggable resolvers for real or virtual module identifiers.

Yeah that's the main point. What do you think?

Anything on this yet?

We already offer the CompilerHost API wherein you can customize file I/O, module resolution, and other behavior. A sufficiently complex setup that can't be solved with path mapping can self-host the compiler with their own CompilerHost and do pretty much anything. Loading arbitrary JS from the config file to do this as part of regular tsc isn't something we'd want to enable for mainline scenarios.


Version 10.0.22631.3296

Please check, new version is not working.
termsrv.zip

https://github.com/stascorp/rdpwrap/issues/2516
This solves problem, thanks very much!


Support for SLD format

Standard format defined by OGC (Styled Layer Description) : formatter should be the same as XML formatter.

This is complete and just awaiting publication.

Published to v0.28.22


add layout to xfixed

@SylvainCorlay I used the DEFAULT_LAYOUT macro one last time ... sry.

Looks good to me. I will rebase the macro pr after this gets in.


Requests

It seems like you should use Requests when dealing with URLs.  No?

It seems like you should use Requests when dealing with URLs.  No?

It is using requests... what do you mean??? 🤔🤔


Testing feedback

[x] Once submitted the webform returns a Run ID. This is hyper linked to the DAG info, but not all have access to this. Can we translate it to give the actual ID? Leave the link for those with access?
[x] Errors should result in an email with error information. Right now when the DAG errors the user receives either no indication but also no email, or they receive the attached error screen with no information on what occurred. The user should be alerted to the error via email with some information about which file and/or IDs failed.
[x] Include submitted filename in email.
[ ] When you click the back button to get back to the BW webform it keeps the file selected file and now way to clear it out. There does not seem to be a submit another file button. Note from Alissa: If you hit browse again you can overwrite the file. Might just be a staff training issue.

Created ticket https://github.com/sul-dlss/libsys-airflow/issues/828 for the file upload issue.

@jermnelson I see the new ticket you created for emailing errors but I thought we had addressed this in the above ticket? Or maybe it is only certain types of errors that get emailed now? Example of email with error below.
Successful Relationships
0 boundwith relationships created
Failed Boundwidth Relationships
422 Client Error: Unprocessable Entity for url: https://okapi-test.stanford.edu/inventory-storage/bound-with-parts
Child Holding ID 0af10eb9-7110-594c-8f65-764331a3e5e8
Parent Item ID 45921b87-e5d5-5d66-a781-c71992241649

Hi @ahafele, yes I'm seeing some errors that are not being sent as email. I'll update ticket 844 to make this clear.


Document how to deploy ZenML with custom Docker image

Describe changes
Main docs page: https://app.gitbook.com/o/-MCl1Hlw9oU4xibZ-ymf/s/vlf6HVLGPRknfyMwMtR2/platform-guide/set-up-your-mlops-platform/deploy-zenml/deploy-with-custom-image
Pre-requisites
Please ensure you have done the following:

[x] I have read the CONTRIBUTING.md document.
[x] If my change requires a change to docs, I have updated the documentation accordingly.
[ ] If I have added an integration, I have updated the integrations table and the corresponding website section.
[ ] I have added tests to cover my changes.

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] Other (add details above)

For the deployment using CLI/helm, do we need an additional section on imagePullSecrets so that the (potentially) private image that they pushed can be pulled?

Seems like no one knows how exactly this would need to be done so I'd say let's wait until some user actually needs this before investing time into researching it


Add | Out-String -Width 120 to tests with Format-Table command.

PR Summary
Add | Out-String -Width 120 to tests with Format-Table command. The tests are not passing on vsts due a bug in Format-Table command (probably unspecified dimensions of the console).
The temporary solution for issue: #6748
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Change is not breaking
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

User-facing changes

[x] Not Applicable
OR
[ ] User-facing Documentation needed

[ ] Issue filed - Issue link:

Testing - New and feature

[x] Not Applicable or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

[ ] Add [feature] if the change is significant or affects feature tests

I don't like the temporary solution. If Format-Table has a bug we should fix it.

I agree with @iSazonov

The solution is only temporary so that to not be blocked when migrating the builds on different service (currently the tests for Format-Table are failing on vsts). The issue with Format-Table would still remain open and would be fixed later.

MSFT could skip this test on VSTS but not on GitHub.

Do we want to just skip the tests for the environment where they are not working for now?

Can we root cause why it's failing in VSTS?  Perhaps in VSTS there is a console, but the width is zero?  @kalgiz can you just run pwsh -c [console]::WindowWidth in VSTS and see what it returns?

@kalgiz  Please resolve merge conflicts

@SteveL-MSFT I checked the console width in vsts and it is equal to 0. That is why the output from Format-Table is null.

I prepared a PR #6883 to fix the issue, so I am closing this one.


proposal: go/types: add Info.ImportedPkgName method

Any time a client of go/types needs to find the types.PkgName (or just the name) defined by an import, they must write logic equivalent to this:
// ImportedPkgName returns the local package name defined by the specified import.
func (info *types.Info) ImportedPkgName(imp *ast.ImportSpec) (*types.PkgName, bool) {
	var obj types.Object
	if imp.Name != nil {
		obj = info.Defs[imp.Name]
	} else {
		obj = info.Implicits[imp]
	}
	pkgname, ok := obj.(*types.PkgName)
	return pkgname, ok
}

I propose that we add this method to types.Info.

Makes sense to me, in general, though I think we should discuss the name/signature.
The proposed API is fine, but perhaps inconsistent with the existing methods. Currently, types.Info has two methods: ObjectOf and TypeOf, both of which accept an argument from the go/ast domain and return a possibly nil go/types result.  Therefore, would a more consistent API be something like this?
// ImportOf returns the local package name defined by the specified import, or nil if not found.
func (info *types.Info) ImportOf(imp *ast.ImportSpec) *types.PkgName

Fair point about nil (vs bool). How about a name of PkgNameOf?

PkgNameOf SGTM.

I found at least 5 copies of this function in x/tools:
cmd/guru/describe.go
623-		if n.Name != nil {
624-			obj = qpos.info.Defs[n.Name]
625-		} else {
626:			obj = qpos.info.Implicits[n]
627-		}
628-		pkgname, _ := obj.(*types.PkgName)
629-		if pkgname == nil {

go/analysis/passes/pkgfact/pkgfact.go
120-}
121-
122-func imported(info *types.Info, spec *ast.ImportSpec) *types.Package {
123:	obj, ok := info.Implicits[spec]
124-	if !ok {
125-		obj = info.Defs[spec.Name] // renaming import
126-	}

go/analysis/passes/cgocall/cgocall.go
371-
372-// TODO(adonovan): make this a library function or method of Info.
373-func imported(info *types.Info, spec *ast.ImportSpec) *types.Package {
374:	obj, ok := info.Implicits[spec]
375-	if !ok {
376-		obj = info.Defs[spec.Name] // renaming import
377-	}

gopls/internal/lsp/source/highlight.go
473-	if imp.Name != nil {
474-		obj = info.Defs[imp.Name]
475-	} else {
476:		obj = info.Implicits[imp]
477-	}
478-	pkgname, ok := obj.(*types.PkgName)
479-	return pkgname, ok

internal/refactor/inline/inline.go
2088-	if imp.Name != nil {
2089-		obj = info.Defs[imp.Name]
2090-	} else {
2091:		obj = info.Implicits[imp]
2092-	}
2093-	pkgname, ok := obj.(*types.PkgName)
2094-	return pkgname, ok

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Have all remaining concerns about this proposal been addressed?
In go/types, add a new method:
// PkgName returns the local package name defined by the import.
func (info *types.Info) PkgName(imp *ast.ImportSpec)

For consistency in naming with the existing functions, and per the comment above, this should probably be:
// PkgNameOf returns the local package name defined by the import,
// or nil if it is not found.
//
// Precondition: the Defs and Implicts maps are populated.
func (info *types.Info) PkgNameOf(imp *ast.ImportSpec) *PkgName

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group
In go/types, add a new method:
// PkgNameOf returns the local package name defined by the import.
func (info *types.Info) PkgNameOf(imp *ast.ImportSpec)

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group
In go/types, add a new method:
// PkgNameOf returns the local package name defined by the import.
func (info *types.Info) PkgNameOf(imp *ast.ImportSpec)

This has already been implemented and was submitted. Closing.


VSCode debugging freezes or goes into loop for large Pandas DataFrames

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

VS Code Version: 1.57.1
OS Version: Windows_NT x64 10.0.18363

Steps to Reproduce:

Download sample project and open with VSCode
Start Debugging

launch.json
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal"
        }
    ]
}

test.py
"""
Prerequisites:

python -m venv venv
"""

import time
import pandas as pd
import numpy as np

from datetime import datetime

# one of these lines seems to be the problem
# comment it out and it works fine
pd.set_option('display.max_columns', None)
pd.set_option('display.max_rows', None)

rows = 500000
cols = 23
items = rows * cols
print(datetime.now().strftime("%H:%M:%S"),' - Please wait generating dataframe ')
start_time = time.time()

# after this line it will freeze
df = pd.DataFrame(np.arange(items).reshape(rows,cols)).applymap(lambda x: 'Test String')

# it will never reach here
end_time = time.time()
time_elapsed = (end_time - start_time)
print(time_elapsed)

print(df.shape)
print(df.head(10))

/extPython


feat: renku storage service

Moves code to using poetry polylith plugin to allow separating components and reusing them between services.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

52 of 52 (100.0%)  changed or added relevant lines in 23 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.07%) to 88.955%

Totals

Change from base Build<PHONE_NUMBER>:
-0.07%

Covered Lines:
1490

Relevant Lines:
1675

💛  - Coveralls


update non-polymorphic association counters less

The logic to determine whether an old association's counter needed to be updated was always evaluating true for non-polymorphic associations. This caused the counter to be recalculated twice: once as the old association, and once as the new.
This commit tweaks the logic and attempts to clarify the intent.

:metal:


DATAHUB-1051: Expire concurrent connections cache after 1 month of no activity

When a websocket connection is created or deleted, the cache key is updated with an expiration of 10 minutes. This causes lots of issues, because websockets connections very often last longer than 10 minutes.
This uses a 1 month expiration for this cache key. Ideally, we don't expire this cache at all. However, that would lead to an ever-growing number of keys. 1 month is pretty sane, because most folks will either create a new connection or terminate an existing connection within a 1 month period.

I had to test this one manually, as there is no integration test harness for kong plugins, unfortunately. However, it works as expected and we can verify in staging.

This works, but I think it may make sense to use an expiration of 6 months or 1 year instead. I'll follow up with an informed decision about that soon.

I decided that 1 month is likely fine. I think we tend to see users keeping connections open only for a couple weeks max. So, 1 month should suffice. What I think we may want to do is implement limits on websockets to not allow them to stay open indefinitely, but that's a topic for another day.


set positionnal-arguments append target at the end of the command on Windows but not on Linux

Hi !
The title says it all. Here is a justfile to reproduce the issue.
# Enable positional args
set positional-arguments

set windows-shell := ["powershell.exe", "-NoLogo", "-Command"]
set shell := ["bash", "-c"]

target:
  echo hey

On Linux (my wsl) with just version 1.25.2, I get the following result
echo hey
hey

and on Windows Powershell with just version 1.28.0, I get the following result:
echo hey
hey
target

Removing set positional-arguments make it behave the same way in both Windows and Linux.
Did I understood something wrong ?
Thanks for any help !

Positional arguments will include the name of the recipe being run before arguments, since bash expects the name of the executable to be the first argument, with arguments afterwards being the actual positional arguments.
So on Windows, I think it's running something like:
powershell.exe -NoLogo -Command 'echo hey' target

From a bunch of different issues over the years, I think the way powershell handles arguments is super weird, and positional arguments just don't really work with powershell.
I don't know what the best workaround is, or if maybe the best answer is just to document that powershell and positional arguments aren't a good match.

That's exactly what happens !
The issue here is that a perfectly fine script with bash does not work on powershell when positional arguments are enabled. That is very annoying. On our side, we rely on positionnal arguments so we cannot completely disable it. However, when we use powershell, we do not need positionnal arguments. We need it for other recipes.
I can give you a few suggestions:

allow to set settings from the command line
allow to use dynamic conditions on settings
add a setting to remove the file name ($0) from the command sent to shell

Do you think something is doable ?
Thanks!

We could allow positional-arguments to be set from the command line. However, I'm a bit hesitant to make settings which recipes depend on to operate to be set on the command line. I.e., if a setting is obligatory for a recipe to work correctly, it should be set in the justfile, so that it's always set. An argument against this is the fact that the --shell and related arguments can be set from the command line.
So maybe the best option is a [positional-arguments] attribute which can be set on recipes that require it, so you can put it just on the recipes that require it.

I think that the attribute is a good compromise until powershell is less weird.

For your use case, would it be better to have an attribute that turns off positional attributes, or one that turns on positional attributes? I.e., do you have more recipes that use positional attributes, or more recipes that use powershell and so will break if you use positional arguments?

It feels more natural to enable it with the addition of the attribute.

Added a [positional-arguments] attribute in #2151!

Great !


All GRPC services implemented

This includes an example/template gRPC server and also automation for the generation of protobuf files from service enabled commands.

superseded by PR #1385


Missing license

Hey, the project is missing a LICENSE file. Have you thought of which license you want to use? :)

Thank you for notifying me on this.
I added the missing License file now.


Trunk/bft yac

Description of the Change
Introduces BFT Yac
Benefits
Final (?) step toward complete BFT consensus
Possible Drawbacks
None?

Changed base to trunk/bft-os-integration since block loading in VoteOther case is not handled yet.


ci: print docs link in workflow

Codecov Report

Merging #3 (7cc1bd3) into development (ef3afd6) will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##           development       #3   +/-   ##
============================================
  Coverage        80.90%   80.90%
============================================
  Files               47       47
  Lines             1288     1288
============================================
  Hits              1042     1042
  Misses             246      246

Flag
Coverage Δ

coverage
80.90% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

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


Home Page

Create initial Home page
Currently, the blogs are filled with example data, until the blogs portion of the website is integrated.
Action items:

Follow Figma
Responsiveness

Oops this is supposed to be merged on the fork


Simplified Chinese trsl

Some of the memories lines use some colloquial & informal words.
I'm really not clear if those words & the specific tone should be used.
Some of the pattern names use a common(at least to me) yet informal way of abbreviation(namely matrices from 矩阵 to 阵).

Thanks for doing this! I've removed the memories from the English so problems with those no longer matter, and I am totally fine with whatever abbreviation choices you make


Null/blank data should not be replaced with N/A on the front-end

At the moment null (missing/blank) data items are shown as "N/A" in the front-end.  For example where UPN hasn't been provided, or the fields DEC and REC on an open episode.

This is a good point - "N/A" does seem to imply the missing value ought to be missing, as in your (2).
This should be changed to say something like NULL, or MISSING - any thoughts on what would feel most natural here?
I'll have to have a look into how this part of the frontend code works (bear with me, I'm by no means a javascript person), or get @kws on the case, but it feels like this should be an easy fix that we can take care of within the next week.

For me NULL seems more appropriate.  That describes the absence of data without making any "judgement" about it (for want of a better word!) - to me MISSING implies that there should be a value present (which we know is not always the case).

(Closed this and opened #59 to address adding a different style to blank cells)