Does not work on Safari

Thanks for forking and giving sticky-sidebar some needed love!
It works great for me on Firefox and Chrome, but doesn't work on Safari.
On the desktop version of Safari on a Mac it doesn't work at all.
On the mobile version of Safari on an iPad it works to a point, but then the sidebar content starts scrolling up and down incessantly.

There were two issues:

The sticky-sidebar was not working on Safari.

This was due to Safari rendering my page differently than Firefox and Chrome. It perceived the content size as being half of what it was, so the sticky-sidebar never was activated. I resolved this by modifying my CSS.

When the page reached the bottom, the sidebar content would continuously flicker, jumping up and down by a few pixels.

This was resolved by @dryymoon's pull request. We can close this issue as soon as that PR is integrated.
FYI, for anyone implementing a Phoenix LiveView app, this is what my JavaScript hook looks like:
Hooks.StickySidebar = {
  mounted() {
    this.stickySidebar = new StickySidebar('#sidebar', {
      topSpacing: 18,
      bottomSpacing: 16,
      containerSelector: '#main-content',
      innerWrapperSelector: '.sidebar__inner',
    })
    var _this = this
    window.addEventListener('load', event => {
      _this.stickySidebar.updateSticky()
    })
    setTimeout(function () {
      _this.stickySidebar.updateSticky()
    }, 500)
  },
  updated() {
    this.stickySidebar.updateSticky()
  },
  destroyed() {
    this.stickySidebar.destroy()
  },
}

@pthompson Hey, thanks a lot for submitting an issue! :) I'm glad an existing PR fixes the problem, but the PR in question is not completely straight forward to merge. Would you care to have a look at my latest comment there?

@pthompson Hey, thanks a lot for submitting an issue! :) I'm glad an existing PR fixes the problem, but the PR in question is not completely straight forward to merge. Would you care to have a look at my latest comment there?

Closing this issue as https://github.com/blixhavn/sticky-sidebar-v2/pull/9 is now merged


[IOTDB-3250] Reactor UDF related services for mpp cluster

Coverage increased (+0.02%) to 45.525% when pulling ac6d90e0357da6d86e062cd40395a57537d9034a on iotdb-3250 into 8f81a4334d91734996e995a76c745e6be38458ca on master.


Change FileSystemVectorStore FilePath Parameter

The FileSystemVectorStore __construct method takes a $filepath parameter.
But this parameter is a lie! Or, as they say in France: Sàcèblö it's lè falsè.
It acutally adds the path. Also it should use the DIRECTORY_SEPERATOR seperator instead of / to be windows compatible, or as they say in Germany: Damit man durchlüften kann.
$this->filePath = getcwd().'/'.$filepath;
This is unnecacary and a random behavior it should just take a path, maybe make the default "null" and if null take getcwd() or something.

@MaximeThoonsen I have had to fight with the Linter but I have sucseeded.


Multiple Calendar in single Page not working

Schedule-X version [v1.59.0]

Describe the bug

When we have configure Schedule-X in VUE 3 custom component. And try to render same component multiple time in single page it's creating issue to switch views.

To Reproduce
Steps to reproduce the behavior:

Step 1 - Render  custom component with schedule-X multiple time in single page.
Step 2 - Try to switch views in any one of calendar.
Step 3 - It will change the view but it will wipe out other calendar and there is no console errors.

Expected behavior

If we change anything in one calendar, It should not affect other calendar component.

Screenshots

If applicable, add screenshots to help explain your problem.
Things that could speed up the process

[ ] I can picture implementing at least parts of this fix
[ ] I believe I know how to do this, and am willing to implement the whole thing.
[x] I have a Schedule-X premium license

Can you include the code you use for setting up the calendar?
Do you import viewMonthGrid or createViewMonthGrid from '@schedule-x/calendar'? If the former, that would be the error

`feature.config = SXCalendar.createCalendar({
selectedDate: localYYYYMMDDHmm(new Date()),
views: [SXCalendar.viewDay, SXCalendar.viewWeek, SXCalendar.viewMonthGrid, SXCalendar.viewMonthAgenda],
defaultView: SXCalendar.viewWeek.name,
//initialView: 'timeGridWeek',
events: feature.events,
plugins: [ SXResize.createResizePlugin(), SXScrollController.createScrollControllerPlugin({ initialScroll: '07:50' }),
eventsService, SXEventModal.createEventModalPlugin(), interactiveEventModal, sidebar],
//plugins: [ScheduleX.createDragAndDropPlugin(), ScheduleX.createResizePlugin(), ScheduleX.createScrollControllerPlugin(), ScheduleX.createEventsServicePlugin(), ScheduleX.createEventModalPlugin()],
      callbacks: {
        /** * Is called when: * 1. Selecting a date in the date picker * 2. Selecting a new view * */
        onRangeUpdate(range) {
          console.log('new calendar range start date', range.start)
          console.log('new calendar range end date', range.end)
        },
        /** * Is called when an event is updated through drag and drop * */
        onEventUpdate(updatedEvent) {
          console.log('onEventClick', calendarEvent)
        },
        /** * Is called when an event is clicked * */
        onEventClick(calendarEvent) {
          console.log('onEventClick', calendarEvent)
        },
        /** * Is called when clicking a date in the month grid * */
        onClickDate(date) {
          console.log('onClickDate', date) // e.g. 2024-01-01
        },
        /** * Is called when clicking somewhere in the time grid of a week or day view * */
        onClickDateTime(dateTime) {
          console.log('onClickDateTime', dateTime)
        },
        /** * Is called when clicking the "+ N events" button of a month grid-day * */
        onClickPlusEvents(date) {
          console.log('onClickPlusEvents', date) // e.g. 2024-01-01
        },
        /** * Is called when the selected date is updated * */
        onSelectedDateUpdate(date) {
          console.log('onSelectedDateUpdate', date)
        }
      },
      calendars: feature.calendars || {},
      guid: feature.guid
    });

    setTimeout(() => { feature.config.render(document.querySelector('.a' + feature.guid + ' #schedule-calendar')); }, 100);`

You need to use the factory functions for creating the view, like createViewMonth, or createViewWeek if you use multiple calendars.
And I need to update the docs for using CDN I see now 😊

I tried with only Day and Week with below code still getting same issue.. can we connect on Discord? I sent you request.

ok got working with factory functions thanks.


altcoins.wownero: <IP_ADDRESS> -> <IP_ADDRESS>

Motivation for this change
Version bump
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Assured whether relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg build altcoins.wownero

@GrahamcOfBorg build altcoins.wownero

@fuwa0529 If you'd like to trigger GrahamcOfBorg builds, you need to add yourself to the known users https://github.com/NixOS/ofborg/#trusted-users-vs-known-users

@ryantm Thanks


SSL Error when connecting to client cert authenticated kafka

If this is a bug report, please fill out the following:

Version of Ruby: 2.5.1 (should be any)
Version of Kafka: ii confluent-platform-oss-2.11            4.1.2-1
Version of ruby-kafka: 0.6.7 (and master)

Please verify that the problem you're seeing hasn't been fixed by the current master of ruby-kafka.
Steps to reproduce
The server needs to be configured to trust the organization's Root CA for client certificate authentication. The client cert needs to be generated by the Intermediate CA, the int_ca isn't part of the truststore on the server, only the root_ca.
client_key = IO.read('/path/to/client_key.pem')
client_cert = IO.read('/path/to/client_cert.pem')
ca_cert = IO.read('/path/to/ca.pem')
kafka = Kafka.new(ssl_client_cert: client_cert, ssl_client_cert_key: client_key, ssl_ca_cert: ca_cert)

kafka.topics

Expected outcome
I expect the topics to be listed. (This applies to any kafka operation)
Actual outcome
OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=unknown state: unexpected message)
I, [2018-08-20T14:18:45.070086 #95763]  INFO -- : Fetching cluster metadata from kafka://broker0.kafka-sbx.venuenext.net:9092
D, [2018-08-20T14:18:45.070688 #95763] DEBUG -- : Opening connection to broker0.kafka-sbx.venuenext.net:9092 with client id portico-rb-eventa...
D, [2018-08-20T14:18:45.321117 #95763] DEBUG -- : Closing socket to broker0.kafka-sbx.venuenext.net:9092
Traceback (most recent call last):
       16: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/client.rb:587:in `topics'
       15: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/cluster.rb:347:in `list_topics'
       14: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/cluster.rb:417:in `random_broker'
       13: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/cluster.rb:367:in `cluster_info'
       12: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/cluster.rb:387:in `fetch_cluster_info'
       11: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/cluster.rb:387:in `each'
       10: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/cluster.rb:392:in `block in fetch_cluster_info'
        9: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/broker.rb:44:in `fetch_metadata'
        8: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/broker.rb:170:in `send_request'
        7: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/connection.rb:96:in `send_request'
        6: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/instrumenter.rb:23:in `instrument'
        5: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/connection.rb:97:in `block in send_request'
        4: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/connection.rb:124:in `open'
        3: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/connection.rb:124:in `new'
        2: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/ssl_socket_with_timeout.rb:68:in `initialize'
        1: from /Users/redbeard/dev/venuenext/ruby-kafka/lib/kafka/ssl_socket_with_timeout.rb:68:in `connect_nonblock'
OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=unknown state: unexpected message)

I started working on a fix to the issue. The SSL Context needs to have an array of certificates provided to the extra_chain_cert property so the rest of the certificate chain can be sent to the server.
Here is my branch that I started working on the fix with: https://github.com/venuenext/ruby-kafka/tree/client_certs_intermediate_ca
I'll start a PR when I get some tests figured out.

:+1: thanks!


TypeScript Support rebass v4?

@types/rebass is supported rebass v3.
Are there any plans to update the type definition to support v4?

In the meantime, you can use this workaround
create rebass.d.ts with this content:
declare module 'rebass/styled-components' {
    import * as r from 'rebass';
    import { CSSObject } from 'styled-components';
    export interface BaseProps {
        sx?: CSSObject;
    }
    export = r;
}

@martasko it does not work with new props like maxWidth, overflow and others.

I've created a PR a few seconds ago in DefinitelyTyped, please take a look and see if I missed anything 🙏

I've created a PR a few seconds ago in DefinitelyTyped, please take a look and see if I missed anything 🙏
DefinitelyTyped/DefinitelyTyped#37709

Is there support for theme config variables checking? I don't see it...
For example:
export const Header = ({ transparent }: { transparent?: boolean }) => (
  <Box bg={['secondary', 'secondary', transparent ? 'transparent' : 'primary']} />
)

No validation of enum secondary and primary of theme.colors

No, I've only adapted the existing typings to work with v4, didn't add any features.

I understand, but it's not usable in production because there are no checking of theme.

It's merged! 🍾

Closing this since it sounds like the type definitions have been updated


Ignore flag not working correctly

This is very annoying. My IDE puts a .idea file in the project, which is in my gitignore. micro-dev does not seem to respect the --ignore flag. I have tried:
--ignore=.idea/
--ignore=.idea/*
--ignore=**/*.xml
--ignore=*.xml
And all other kinds of patterns. Unfortunately combined with https://github.com/zeit/micro-dev/issues/55 it makes micro-dev pretty unusable right now :'(

Can you try cloning https://github.com/zeit/micro-dev/pull/54? Maybe it solves your issue? If so, we can release it 😊

Yes, this fixes my issue! 👍

Fixed in https://github.com/zeit/micro-dev/pull/54

Thank you for the fast turn-around @leo 👍

Released! 😊


Do you have a beta version compiled ?

Hi,
Do you have a beta version compiled ?
Regards ! :octocat:

:)
https://youtu.be/2x_AfmCvfu4
These builds are for internal testing only. Buttons don't work. And don't support the English language despite the translation exists inside the code.
https://github.com/SophiaUI/SophiApp/releases

Wait until the summer. :)


Update README.md

The basics

[ ] I validated my changes

The details
Resolves

Fixes
Proposed Changes

Reason for Changes

Test Coverage

Documentation

Additional Information

@depedabot rebase

@dependabot rebase

https://github.com/dependabot rebase

@dependabot rebase

@dependabot rebase


Correction: More than four types are available

The list has grown beyond four, and may keep growing in the future

/lgtm
Good catch! If there are any other stale things, or any other cleanup up, that you can see in this file, it would be great to take care of that while touching the file. But looks good - thanks!

/approve


Circular dependant security groups

I am not sure if this is solvable however I am interested in any views on how this could work or if the module can be extended to support this.
I would like to setup two security groups, one for my puppetmasters and one for puppet clients (example puppet manifest below).
Most guides seem to suggest creating empty security groups where you have circular dependencies and than update them both with the rules in a second run.  With the way the module is currently setup you cannot re-declare the security group with the rules you would like to apply.
One option (not ideal) is when creating the security group it checks to see if the dependent group is already created and if it is not created create an empty shell, later the empty shell will will be updated with the in and out rules.
Thoughts?
ec2_securitygroup { 'puppetmaster-sg':
   ensure             => present,
   region             => hiera('aws_region'),
   description        => 'Testing security master',
   ingress            => [{
     protocol            => 'tcp',
     port                  => 443,
     security_group => 'puppetagent-sg',
   },{
     protocol            => 'tcp',
     port                  => 8140,
     security_group => 'puppetagent-sg',
   },{
     protocol            => 'tcp',
     port                  => 61613,
     security_group => 'puppetagent-sg',
   },{
     protocol            => 'tcp',
     port                  => 61613,
     security_group => 'bastion-host-sg',
   },{
     protocol            => 'tcp',
     port                  => 61613,
     security_group => 'puppetagent-sg',
   },{
     protocol            => 'tcp',
     port                  => 22,
     security_group => 'bastion-host-sg',
   }
}
ec2_securitygroup { 'puppetagent-sg':
   ensure             => present,
   region              => hiera('aws_region'),
   description      => 'Testing security master',
   ingress            => [{
     protocol            => 'tcp',
     port                  => 22,
     security_group => 'bastion-host-sg',
   },{
     protocol            => 'tcp',
     port                  => 61613,
     security_group => 'puppetmaster-sg',
}

Apologies for taking an age to get to these issues, I've been busy with other work.
This is definitely an issue and I don't have a definite answer at the moment unfortunately. I will try and make some time to have a think.

I think this can be solved by moving ingress rules into own resource or adding extra resource just for this edge case. Something like:
ec2_securitygroup { 'puppetmaster-sg':
ensure             => present,
region             => hiera('aws_region'),
description        => 'Testing security master'
}
ec2_securitygroup { 'puppetagent-sg':
ensure             => present,
region              => hiera('aws_region'),
description      => 'Testing security master'
}
ec2_securitygroup_ingres { 'puppetmaster-sg-rules':
security_group => 'puppetmaster-sg',
require => [ Ec2_securitygroup[ 'puppetmaster-sg'], Ec2_securitygroup['puppetagent-sg']],
ingress            => [{
protocol            => 'tcp',
port                  => 443,
security_group => 'puppetagent-sg',
},{
protocol            => 'tcp',
port                  => 8140,
security_group => 'puppetagent-sg',
},{
protocol            => 'tcp',
port                  => 61613,
security_group => 'puppetagent-sg',
},{
protocol            => 'tcp',
port                  => 61613,
security_group => 'bastion-host-sg',
},{
protocol            => 'tcp',
port                  => 61613,
security_group => 'puppetagent-sg',
},{
protocol            => 'tcp',
port                  => 22,
security_group => 'bastion-host-sg',
} ]
}
ec2_securitygroup_ingres { 'puppetagent-sg-rules':
security_group => 'puppetagent-sg',
require => [ Ec2_securitygroup[ 'puppetmaster-sg'], Ec2_securitygroup['puppetagent-sg']],
ingress            => [{
protocol            => 'tcp',
port                  => 22,
security_group => 'bastion-host-sg',
},{
protocol            => 'tcp',
port                  => 61613,
security_group => 'puppetmaster-sg',
}]
}

@garethr , I tried a few things with this module, however I also ran into the DAG issues.  I'm trying to setup a daily audit with a manifest generated from "puppet apply ec2_securitygoups" However I have about 50 Groups, and several interdependencies. I'll have to make it work by splitting the SG's in to separate manifests, and doing some shell routines.  Any thoughts on how one could overcome this issue?

I just ran into this issue as well.

Is this something that can be fixed within this module, or an issue that is inherently within puppet? I'm having a rough time convincing my company to use puppet to manage SG's because of this issue.


Allow USE_MY_METRICS when dx is negligible, matching ufo2ft

Fixes #1078
ufo2ft determines this metric after most of glyf is already compiled, which means that component positions will already have been rounded, with negligible offsets discarded. We can match this behaviour by rounding the x-offset before comparing to the identity transform.
After this change, fontc matches fontmake's behaviour for Moirai, in which /Ugrave's /U component has a 0.004 x-offset that is rounded away during compilation.
Note: this is a personal contribution independent of my employer, and so I've submitted from a fork under my personal profile and email to make this distinction

Passing to @anthrotype to confirm, looks good at a glance. Could we impose on you to sign the CLA?

Yes no problem :) Just signed under this email

All done!


Figure out what to do about installers that can only be built in specific containers

There are some assets (deb and rpm bits) that are built in specific containers. Up till this point, the plan has been to divide up the verticals based on the existing runtime legs, and invoke a build command for each one. This should then produce all outputs required to ship .NET. How do we handle deb and rpm packages in this case? The runtime build usually invokes builds of those packages in separate containers. This is less desirable as it uses AzDO tasks to accomplish this, meaning you'd have to exit the build and re-enter.
What should be done here?

If we do the following items, we can remove the requirement for separate containers to build Linux packages.

[ ] https://github.com/dotnet/sdk/issues/43688

[ ] https://github.com/dotnet/aspnetcore/issues/58073

[ ] https://github.com/dotnet/arcade/issues/15143

[ ] Move SDK to new RPM tooling

[ ] Move aspnetcore to new RPM tooling

All repos have been moved to the new tooling, so we don't depend on separate docker images any more


Added resources about WebRTC

The PR introduces a thorough expansion to our WebRTC documentation. The update includes detailed explanations of core concepts like the signaling server, ICE candidates, STUN and TURN servers, and the nuances of establishing connections and streaming in WebRTC. Additionally, it explores alternative architectures such as SFU and MCU, addressing their scalability and applicability in different scenarios.
Key Additions:

Introduction to WebRTC: Clarifies the functionality and significance of WebRTC in modern web applications.
In-depth Analysis of Signaling Servers: Explains their role and functionality in WebRTC architecture.
Detailed Explanation of ICE Candidates and Their Types: Offers insights into the technicalities of WebRTC connections.
Roles of STUN and TURN Servers: Discusses their importance in overcoming networking challenges.
Streaming Process: Details the steps involved in streaming audio and video between peers.
Alternative Architectures (SFU and MCU): Provides an analysis of these architectures, highlighting their scalability and use cases.

Purpose:

To enhance the depth and breadth of our WebRTC documentation, providing a valuable resource for developers.
To clarify complex concepts and streamline the learning process for those new to WebRTC.
To offer insights into choosing the right architecture for specific WebRTC use cases.

This is looking really good David. A few comments:

The explanations are super clear and easy to follow, making it a breeze for anyone diving into WebRTC.

Love how you've divided things up into sections; makes it all super digestible.

How about hinting at what's to come with WebRTC? Just a quick snapshot to get readers excited about what they're diving into.

Adding a simple diagram to explain ICE candidates could be a game-changer. Visuals can make this tech stuff a lot friendlier.

Expanding more on SFU and MCU would be nice. Let's talk about their unique perks and limitations to give readers a fuller picture.

This is looking really good David. A few comments:

The explanations are super clear and easy to follow, making it a breeze for anyone diving into WebRTC.
Love how you've divided things up into sections; makes it all super digestible.
How about hinting at what's to come with WebRTC? Just a quick snapshot to get readers excited about what they're diving into.
Adding a simple diagram to explain ICE candidates could be a game-changer. Visuals can make this tech stuff a lot friendlier.
Expanding more on SFU and MCU would be nice. Let's talk about their unique perks and limitations to give readers a fuller picture.

Thanks Kai for the feedback and suggestions. Adding a diagram for ICE candidates is a great idea for better clarity and I'll expand on the SFU and MCU sections to detail their unique advantages and limitations. I'll update the PR soon with these enhancements.

Great Work David, I think you have done a great job at explaining concepts like signalling server and ICE candidates, as well as the importance of STUN and TURN servers in ICE.

The introduction provides a clear and concise overview of WebRTC, making it accessible to readers who may be unfamiliar with the topic. The use of a rhetorical question engages the reader.

The explanation of the signaling server is informative, and the provided code example enhances understanding. The example signal structure is clear and adds practical value.

I like how you mentioned the option of hosting your own TURN server, as this adds a practical aspect to your explanations.

I agree with Kai that a simple diagram to explain ICE candidates would be extremely helpful, and if you have time I believe that adding quick code comments to critical parts of the code would benefit some readers, especially those who are new to coding and WebRTC as a whole! Keep up the great work!!

I think the documentation on the perks and limitations of SFU and MCU is sufficient in the article. This article mainly focuses on establishing a peer-to-peer models and more details on SFU and MCU is also referenced at the end if the reader wants to learn more about different architectures.


Install alias /item/:id route for catalog#show

UMedia will want /item/p16022coll282:9999 for compatibility, which can at least double up /catalog/p16022coll282:9999 per CatalogController's default behavior.

Merging this for now, but we might also reconsider using /catalog in the application. We could move to /search and probably view search result hits at /item everywhere, which would be more aligned with UMedia.


[ISSUE #4734] Use the static final modifier to decorate Logger

Fixes #4734
Motivation
In Java, it is a best practice to declare a logger static final.
private - so that no other class can hijack your logger
static - so there is only one logger instance per class, also avoiding attempts to serialize loggers
final - no need to change the logger over the lifetime of the class
Modifications
For all private final Logger declarations a static modifier has been added and the UPPER_CASE has been applied.
Logger names has been substituted with constants from org.apache.eventmesh.runtime.constants.EventMeshConstants, in particular 3 new constants have been added to it.
Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)
If a feature is not applicable for documentation, explain why? (minor refactoring)
If a feature is not documented yet in this PR, please create a followup issue for adding the documentation

Please fix checkstyle warnings in CI.


data_augmentation

In data_aug.py, for rotation and scaling:
    angle = np.random.uniform(-np.pi / 4, np.pi / 4)
    lidar[:, 0:3] = point_transform(lidar[:, 0:3], 0, 0, 0, rz=angle)
    gt_box3d = box_transform(gt_box3d, 0, 0, 0, -angle, 'camera')
    newtag = 'aug_{}_2_{:.4f}'.format(tag, angle).replace('.', '_')

Above is the code for rotation:
It calls box_transform to rotational transform the gt_box3d.
At this step, gt_box3d is in 'camera' coordinate.
In box_transform function, it calculates boxes_corner using center_to_corner_box3d function.
And the elements in boxes_corner are still 'camera' coordinate.
However, since the point_transform function is written under assumption that the origin of coordinate is the location of Lidar, no matter it rotates around rz or ry, at this step boxes_corner should be in 'Lidar' coordinate.
I think you considered this already in the first option of data augmentation. It first transform to lidar based box and calculated everything needed for transforming and then finally it converts back to 'camera' coordinate using lidar_to_camera_box.
But for the second and the third option of data augmentation, you didn't consider location of the origin of 'camera' coordinate and 'Lidar' coordinate.
So I suggest you to update the code for the second data augmentation, rotation as:

angle = np.random.uniform(-np.pi / 4, np.pi / 4)
lidar[:, 0:3] = point_transform(lidar[:, 0:3], tx=0, ty=0, tz=0, rx=0, ry=0, rz=angle)
lidar_center_gt_box3d = camera_to_lidar_box(gt_box3d)
lidar_center_gt_box3d = box_transform(lidar_center_gt_box3d, tx=0, ty=0, tz=0, r=angle, coordinate='lidar')
gt_box3d = lidar_to_camera_box(lidar_center_gt_box3d)
and for the global scaling:
factor = np.random.uniform(0.95, 1.05)
lidar[:, 0:3] = lidar[:, 0:3] * factor
lidar_center_gt_box3d = camera_to_lidar_box(gt_box3d)
lidar_center_gt_box3d[:, 0:6] = lidar_center_gt_box3d[:, 0:6] * factor
gt_box3d = lidar_to_camera_box(lidar_center_gt_box3d)


Generated project for Talon project type has error

The project that is generated for the Talon project type has an error in Robot.java.  robotInit() creates local leftMaster and rightMaster objects instead of using the global variables with the same name, which causes a NullPointerException in autonomousPeriodic().

This was fixed shortly after the switch to frc-characterization from robotpy-characterization.  Make sure you're using the recent version.


Azure App Service Deploy - ETIMEDOUT

Environment
TFS on-premises, version: 16.122.27102.1
##Agent
Private, Windows
Issue Description
We experience issues while uploading files to the slot of an App Service. We are using the Azure App Service Deploy task. We have approximately 10 of these task within our deployment process.
Sometimes the tasks succeed, sometimes they fail. We do not see any algorithm in this behaviour.
Error logs
With system,debug on true we notice the following ERROR output:
2018-04-26T01:36:31.4127340Z ##[debug]Performing the deployment of webapp.
2018-04-26T01:36:31.4128146Z ##[debug]Finding files matching input: E:\1\r2\a\Develop\drop-deployment\licenses
2018-04-26T01:36:31.4550578Z ##[debug]Azure web app in wrong state, status code : 403
2018-04-26T01:36:31.4567285Z ##[debug]Failed to check availability of azure web app, error : undefined
2018-04-26T01:36:31.4573006Z ##[debug]Requesting for Auth Token: https://login.windows.net/********/oauth2/token/
2018-04-26T01:36:52.4791662Z ##[debug]task result: Failed
2018-04-26T01:36:52.4847017Z ##[error]Error: connect ETIMEDOUT <IP_ADDRESS>:443
2018-04-26T01:36:52.4857393Z ##[debug]Processed: ##vso[task.issue type=error;]Error: connect ETIMEDOUT <IP_ADDRESS>:443
2018-04-26T01:36:52.4858837Z ##[debug]Processed: ##vso[task.complete result=Failed;]Error: connect ETIMEDOUT <IP_ADDRESS>:443
2018-04-26T01:36:52.4860351Z ##[debug]Web App Publish Kudu URL: OURCUSTOMER-staging.scm.azurewebsites.net:443

@bstoop-github This issue was fixed with the task version 3.3.36.
Here is the PR: https://github.com/Microsoft/vsts-tasks/pull/6182/files
This fix should be available to you in TFS 2018 U2 RC2.

Thanks for your answer!

Van: Krishna Aditya<EMAIL_ADDRESS>Verzonden: donderdag 26 april 2018 12:37
Aan: Microsoft/vsts-tasks
CC: bstoop-github; Mention
Onderwerp: Re: [Microsoft/vsts-tasks] Azure App Service Deploy - ETIMEDOUT (#7078)
@bstoop-githubhttps://github.com/bstoop-github This issue was fixed with the task version 3.3.36.
Here is the PR: https://github.com/Microsoft/vsts-tasks/pull/6182/files
This fix should be available to you in TFS 2018 U2 RC2.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/vsts-tasks/issues/7078#issuecomment-384593499, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AO4sdry8S-bM8K6182aX2cVbbgKLrSVgks5tsaNagaJpZM4TkphD.


Use navbar html that's local

We should probably use the navbar html that's in the action repository:
  navbar-url:
    description: 'URL of the navbar HTML to be inserted.'
    required: false
    default: ${{ github.action_path }}/scripts/TuringNavbar.html

The insert_navbar.sh script will have to be modified for this though because it uses curl right now (whereas if it's local we probably just want to use cat).

The insert_navbar.sh script will have to be modified for this though because it uses curl right now (whereas if it's local we probably just want to use cat).

I will update this!


Add support for Elixir 1.7

For example, we have this warning with Elixir 1.7:
warning: not passing the :switches or :strict option to OptionParser is deprecated

@jpagex I can't actually see this warning myself. Can you confirm if you're on version 4.3.0 of whitebread as this is when 1.7 support was added.

Closing this now but let's re-open or create specific bugs when they come up 👍

Maybe I was not on the version 4.3.0. I'll let you know if I encounter other warnings.


Generated models can be difficult to use due to unnecessary pointer types

The generated models can be difficult to use with primitive types like string, int and bool because they are consumed as pointers and can make the code more verbose.
For example, in order to use this struct with hard-coded values, I need to write my code like so:
abbreviation := "..."
description := "..."
version := 1

// note the use of variables. in Go, you cannot de-reference a constant!
project := core.ProjectInfo{
	Abbreviation: &abbreviation
	Description: &description
	Version: &version
        ...
}

Without pointers, it can be simplified to this:
project := core.ProjectInfo{
	Abbreviation: "..."
	Description: "..."
	Version: 1
        ...
}

Note: the current strategy probably lowers the runtime memory footprint of an application for larger types like strings, structs, maps, etc... but the efficiency gain is lost for int and bool (i believe).

Thanks for the feedback.  A lot of thought was given in to how to handle the generated models, although that doesn't mean I got it right.  I agree that the verbosity of creating a new struct with hard coded values is not great.
Let me walk through the thinking behind the current approach.  The service is written in c#, so we need to be able to represent all the data in Go that can be represented in c#.   Since structs in Go can not be null, we are forced to use a pointer for struct fields, so that the nil pointer can represent that null state.
string is a similar case.  In c# the empty string and a null string have two different meanings.  For example, if I make a patch request with a description field set to the empty string, this will update the resource's description to an empty string, while making that same patch request with the description field set to null (or not supplied), will leave the description unchanged.  In Go the only way to represent a null string, is to have a nil string pointer.  Therefore it was necessary to make string fields pointers also, so we can cover that null case.
Simple types like int and bool are handled similarly in both languages, and therefore we could get away with making these non pointer fields in Go.  What you will find throughout our c# models is that for many of the cases the nullable types int? and bool? are used rather than simply int or bool.  Patch requests are probably the biggest reason for this.  For int? and bool? we will still have to use pointers to be able to represent the null state.  For our c# controller methods, all new parameters that are added have to be optional for compatibility reasons, so simple types that are query parameters are usually nullable also.  This means that our parameter structs in Go will also require the pointers for most cases of the simple types.
This leaves us with the decision on how to handle the simple types that are not nullable:
Option 1: Keep all simple type fields as pointers.  This has the drawback of extra verbosity.  The benefits are in the consistency.  The consumer does not have to be confused at why some int fields are pointers and others are not.  They know ahead of time that the field is a pointer because every field is a pointer.
Option 2: Do not use pointers for simple types that are not nullable.  This removes a small amount of the verbosity, making it very easy to set values on those fields. The drawback is that this only helps in a subset of fields, and introduces the inconsistency mentioned above.
What are your thoughts?  Of the two options, which would have been better for your project?

@nmiodice , have you had a chance to review my response above?  Do you have any feedback regarding the response?

I am in agreement with @nmiodice that the current approach, while true to the service, is less than ideal from developer perspective. There are some definite drawbacks to the approach I am about to outline, but I think the benefit outweighs the cost. Have you considered something like this to make the API a bit more idiomatic?
Getting data from the REST API
Even though it would represent some loss of data, I expect the API to return the zero value for a field that is either 1) explicitly set to the zero value or 2) a null/omitted value. As that's how encoding/json works out of the box, we don't need any special handling to get data from the API.
Sending data to the REST API
We have to be able to send both a zero and null (unset) value to the API.
The omitempty json tag in use on all generated models already handles sending a null/unset value in an idiomatic way. If I don't want a field to be included in the request to the REST API, I simply set it to its zero value (or more precisely, don't set it) and everything works as expected. This is the more common use case by a significant margin in my experience (compared to needing to explicitly send the REST API a zero value), so this is the path I feel we should optimize.
That leaves how to explicitly include a zero value. I propose the creation of exported variables to represent that the zero value should be sent to the API, and then use custom MarshalJSON() implementations to control this logic. These custom marshalling functions may be a bit messy, but they should be able to be auto generated and significantly improve the user experience in consuming this API. This is a rarer use case, but one that must be accounted for. I've outlined an example implementation in this playground.
The obvious negative to this approach is that the end user must remember that setting Description = "" will not actually be sent to the API unless you include Description = EmptyString. Otherwise, the code is signficantly simpler from a consumption perspective.
Thoughts?

I'm glad to see a complete Azure Devops library for go coming to fruition, thanks for your effort!
I've been following the current go-github approaches, which is to use pointers for all struct members, along with generated accessors and helper functions like https://github.com/google/go-github/blob/master/github/github.go#L1042-L1056.  They discussed this topic in several issues over the years.  There are some interesting comments about taking a different approach if they started over, like https://github.com/google/go-github/issues/537#issuecomment-284486137, but they stuck with pointers for consistency.
From a consumer and new amateur Go user standpoint, I don't mind the extra verbosity too much.  I appreciate the readability and don't mind checking for nil all over the place.

Thanks for the info/feedback @mcdafydd.  Based on the information you provided, I think it makes the most sense to keep things as they are.  I am closing this issue for now, and we can reopen if a compelling alternative pops up.


as an admin I do not want the clusternator server running as root

use an unprivileged user in the clusternator docker.

This task is almost finished.  I need to redeploy the clusternator server validate it, but I do not have an opportunity to reboot right now.


restore numpy 2.0 constraints

References and relevant issues
closes #6871
Description
Restore NumPy 2.0 constraints as it crashed our pre tests because vispy incompatibility. It also crashes napari-plugin-manager tests (see https://github.com/napari/napari-plugin-manager/pull/55).
I think that we should not remove it until tests on separate branches pass.

I think @brisvag is working on a np2-compatible vispy release right now... Can we wait a bit to see if that fixes it? (And @brisvag can you confirm this? 🙏)

We may merge this, and relax constraint in one or two days when vispy is released. Then we could test if any other package creates a problem

Ok. It's certainly annoying to have all the CI failing. 😅

I'll merge this quickly so we can get on with other PRs. It's easy to revert if needed.


[Snyk] Security upgrade ubuntu from 18.04 to 24.10

Snyk has created this PR to fix 5 vulnerabilities in the dockerfile dependencies of this project.
Keeping your Docker base image up-to-date means you’ll benefit from security fixes in the latest version of your chosen image.
Snyk changed the following file(s):

Dockerfile

We recommend upgrading to ubuntu:24.10, as this image has only 7 known vulnerabilities. To do this, merge this pull request, then verify your application still works as expected.
Vulnerabilities that will be fixed with an upgrade:

Issue
Score

CVE-2024-2961 SNYK-UBUNTU1804-GLIBC-6663166
  514

CVE-2024-33600 SNYK-UBUNTU1804-GLIBC-6674192
  514

CVE-2024-33599 SNYK-UBUNTU1804-GLIBC-6674207
  514

CVE-2024-33601 SNYK-UBUNTU1804-GLIBC-6674216
  514

CVE-2024-33602 SNYK-UBUNTU1804-GLIBC-6674225
  514

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

:tada: Snyk checks have passed. No issues have been found so far.
:white_check_mark: security/snyk check is complete. No issues have been found. (View Details)


Client autocompletion for include is suboptimal

A sad Prisma Client (TS) autocompletion story in VSCode (see screenshots below):

Writing code very confident
Using autocompletion because Prisma is amazing!
Uh.... what!?
Uh, no useful auto completion any more?
Good I read the docs before and just know that : true is the answer here.

Related to https://github.com/prisma/prisma/issues/12843


NotV1SupportedException while creating a folder

Hi
Getting  NotV1SupportedException when creating a folder.
Here's the stack trace:
Microsoft.Win32.TaskScheduler.NotV1SupportedException: MyClass.createTask is not supported on Task Scheduler 1.0
at Microsoft.Win32.TaskScheduler.TaskFolder.CreateFolder(String subFolderName, String sddlForm, Boolean exceptionOnExists)
Code:
           td.Actions.Add(new ExecAction(scheduleExePath, scheduleId));

            TaskFolder tf = ts.RootFolder;
            TaskFolder testFolder = null;
            foreach (TaskFolder taskFolder in tf.SubFolders)
            {
                if (taskFolder.Name.Equals("ReportSchedule", StringComparison.OrdinalIgnoreCase))
                {
                    testFolder = taskFolder;
                }
            }
            if (testFolder == null)
                testFolder = tf.CreateFolder("MyFolder");

Environment:
OS: Windows 10 / Windows 2012
Visual Studio 2013
.NET Framework 4.5.1
Task Scheduler Version: Release 2.5.21
Kindly advice, is there anything I am doing wrong?
Thanks
Mani
Originally posted: 2017-02-03T00:17:36

This one is easy and is a problem with your code. You have created the TaskService instance and have set the 'forceV1' parameter to 'true'. This forces the library to revert to the version created for Windows XP that does not support subfolders. You simply need to set that parameter to false and your code should work. Please note that you should protect against trying to create folders on any system older than Windows Vista. Also, you can use the tf.SubFolders.Exists method to see if the "ReportSchedule" subfolder has been created instead of the loop. It is much more efficient. I would do something like:
TaskFolder tf = ts.RootFolder;
TaskFolder testFolder = tf;
if (System.Environment.OSVersion.Version.Major >= 6)
{
   if (!tf.SubFolders.Exists("ReportSchedule"))
      testFolder = tf.CreateFolder("MyFolder");
   else
      testFolder = tf.SubFolders["ReportSchedule"];
}

Originally posted: 2017-02-03T12:09:45

Hi dahall,
Thanks a lot for the resolution.
Though, I haven't explicitly set forceV1 to true, it was in the initialization line.
TaskService ts = new TaskService(server, userName, domain, Password, true)
Thanks
Mani
Originally posted: 2017-02-04T05:42:29

Originally posted: 2017-02-03T12:10:39


Cms management uninstall plugins command fails

eg.
manage.py cms uninstall plugins PicturePlugin
django.db.utils.IntegrityError: update or delete on table "cms_cmsplugin" violates foreign key constraint "cmsplugin_picture_cmsplugin_fkey_ptr"
DETAIL:  Key (id)=(15) is still referenced from table "cmsplugin_picture".
So fails if plugin instances are left in the inherited model.

Test cannot be written for sqlite since it does not hav refs.
Fix not possible without a on delete cascade. Temporary solution: drop the child pluginmodels table and rerun management command.


page 357, Section 10.5.1

"If we set $\sigma^2 = \infty$, we force the MAP estimate to be $w = 0$"
It looks like cases $\sigma^2 = \infty$ and $\sigma^2 = 0$ are reversed in this paragraph. $\sigma^2 = \infty$ is uninformative prior, so this setting should turn MAP into MLE.

this seems to be fixed already in the latest version


Corrected grammar in readme

Corrected usage of set up and shut down

Wow, hacktoberfest came early!
Don't waste our time.


't' key in ikhal does not focus on today if not in same year

With ikhal, the 't' key moves the cursor on today.day+today.month of displayed year, regardless of today.year

the date in the right column will not change whenever you press t, but
yes, this looks like a bug
Quoting Markus Unterwaditzer (2014-11-27 17:17:34)

This doesn't actually seem exactly true, it seems to move the cursor itself correctly, but the year in the right column is wrong. Moving the cursor away will switch that column also to the current year.

Reply to this email directly or view it on GitHub:
https://github.com/geier/khal/issues/130#issuecomment-64808807


Typos

Mark,
I noticed two typos while reviewing the site.
On the About page, in The arguments, in the Dig row, in the Against column, there's an instance of "disrutive" that should probably read "disruptive."
On the Contact page, there's an instance of "wwant" that should probably be "want."
Cool site; this is a classic Mark Headd project.  I'm looking forward to seeing more work from the Upstate Data Project.
Dan

Thanks for catching these, @DJViau!


[ZEPPELIN-6094] Fixed broken impersonation

What is this PR for?
A few sentences describing the overall goals of the pull request's commits.
The issue stems from the way the interpreter.sh script handles the ZEPPELIN_IMPERSONATE_CMD and constructs the command to be executed. Specifically, the command string passed to bash -c is not being properly formed as a single string, causing exec to fail when it tries to execute the impersonation command.

Command Construction: When ZEPPELIN_IMPERSONATE_CMD is set, the script attempts to build an array INTERPRETER_RUN_COMMAND that includes this command. However, if ZEPPELIN_IMPERSONATE_CMD is a string, it gets added as a single element to the array, leading to incorrect command parsing.
bash -c Behavior: The -c option in bash expects a single string argument that contains the command to execute. If this command is split into multiple array elements, bash misinterprets it, causing failures when it encounters shell built-ins like source.
exec Execution: The exec command replaces the shell with the specified command. If the command is not correctly formatted, exec cannot find it, resulting in errors like exec: sudo -H -u rfialkovskii bash -c: not found.

To fix the issue needs to adjust how the command is constructed in interpreter.sh when ZEPPELIN_IMPERSONATE_CMD is used. Specifically, the command string passed to bash -c is a single, properly formatted string.
Needs:
Define ZEPPELIN_IMPERSONATE_CMD as an Array.
Modify interpreter.sh to Build a Single Command String:
What type of PR is it?
Bug Fix
What is the Jira issue?
[* Open an issue on Jira https://issues.apache.org/jira/browse/ZEPPELIN/
(https://issues.apache.org/jira/browse/ZEPPELIN-6094)
How should this be tested?
Enable shiro auth, configure impersonation and try to run any interpreter under impersonated user
Screenshots (if appropriate)

Questions:

Does the license files need to update?
No

Is there breaking changes for older versions?
Yes, needs to change env from:
export ZEPPELIN_IMPERSONATE_CMD='sudo -H -u "${ZEPPELIN_IMPERSONATE_USER}" bash -c'
to:
export ZEPPELIN_IMPERSONATE_CMD=(sudo -H -u "${ZEPPELIN_IMPERSONATE_USER}" bash -c)

Does this needs documentation?
Yes

will it create subprocesses when impersonation is enabled? if yes, what's the hierarchy?

@pan3793 Yes, when impersonation is enabled in Apache Zeppelin, it creates subprocesses to execute the interpreter under the impersonated user’s identity.
Zeppelin Server Process (Parent)
└── interpreter.sh (Interpreter Launch Script)
└── sudo (or ssh) as ZEPPELIN_IMPERSONATE_CMD (Switches User Context)
└── Interpreter Process (e.g., Spark, Flink, etc.)
└── [Optional] Interpreter Subprocesses (e.g., Spark driver, executors)
Nothing new, this is a fix for what worked before.
It doesn't interfere into process work, it just fixed the command format.

I think ZEPPELIN-5070 changed the process's hierarchy, at least for impersonation-disabled cases.

Also, this fix enables impersonation permanently if ZEPPELIN_IMPERSONATE_CMD exists in env file. I appreciate to point on the clue on how to enable it only if the option "Set impersonation" is active.

@ruslanfialkovskii I tend to accept this change as it recovers a broken feature, but the differences in the process's hierarchy between impersonate enabled and disabled might break some assumptions.

cc @Reamer, you may have the context to evaluate the impact of different process's hierarchy

In general, I am not a friend of user impersonation. In my opinion, both the attempt with sudo and ssh are hacked solutions.
In general, there are such approaches that the running program changes the user. This can be seen, for example, with the Apache web server, which changes from root to www-data. As far as I know, this is done because Apache opens privileged ports (<1024). In the case of Apache, this is usually 80 or 443.
Zeppelin is already running on a high port e.g. 8080, so it is not necessary to change the user here, but you can start directly with an unprivileged user.
Both ssh and sudo may have problems passing signals to the JVM. This can lead to the Zeppelin interpreter not shutting down properly.
I had the signal problem in K8s, which is why I switched to exec.

If the user impersonation works again with these corrections, that's fine by me.

If I understand correctly, after ZEPPELIN-5070, with impersonation disabled, the process's hierarchy looks like below?
Zeppelin Server Process (Parent)
    └── Interpreter Process (e.g., Spark, Flink, etc.)
        └── [Optional] Interpreter Subprocesses (e.g., Spark driver, executors)

Hi @Reamer, the point of using impersonation is running interpreters under specific authenticated users (in my case by ldap)
It is a security team request. Zeppelin server of course is already running under Zeppelin system user (zeppelin) but I need to configure it to run a specific interpreter under a specific user in a separate isolated process.

because running interpreter under system user gives too wide permissions in my case.

Hmm... I believe I understand why gosu present and is adopted widely now, maybe we can explore leverage it to avoid creating subporcess, though this might be out of the scope of this PR.

@Reamer yes, I set up  a user for each LDAP user on the system, which is then addressed via sudo.

@ruslanfialkovskii thanks, merged to master for 0.12. Given it involves a breaking change - user should update the default value, I only merge this to the master for the next feature version


Investigate possible paths for Helium configuration.

If having a completely new gateway the Helium part would need configuration. However, our configuration is already a superset of this (wifi and position) is ist possible to do this as one application?
Investigate Nebras configurator.

The helium wallet app simply uses a number of characteristics for connecting to the hotspot. To be compatible we can just fulfill these
https://docs.helium.com/hotspot-makers/become-a-maker/hotspot-ble-services/
I'm not sure what everything is here and possibly the wallet connection is not there? Maybe that is handled in som other way in Helium?
There seems to be an erlang implementation here: https://github.com/helium/gateway-config


ResponseTimer callstack exceeded

closes INS-698

@develohpanda great find on the discrepancy between timers.  Looks like the rabbit hole goes a bit further down.  cool!
And I really liked where you were headed with the useTimer implementation.  We're really gonna need something like that in the future, but I think it is a little too much for what I want to accomplish with this PR, which is just to fix the callstack-exceeded bug.
We need to discuss more (and, haha, pun intended, take our time in doing so), have tests, etc. for a useTimer implementation that works for us because we do similar things to this with timers all over the app and I think we'll need something like it.  And once we have something we have tested and works well we can contribute it to react-use.  I removed this stuff for now but I'm excited to carry forward where we got with this PR.


Duplicated type leads TSC to pick the wrong one in the *.d.ts file (for implicit return type)

TypeScript Version:  ^2.9.2 (also tested with @next with no difference)
Search Terms:
duplicated type, implicit return, type definition file
Code
// component-a/component-a.tsx
export type ComponentAPosition = 'top' | 'bottom' | 'left' | 'right';

export class ComponentA {
  doAThing(value: ComponentAPosition) {}
}

// component-b/component-b.tsx
export type ComponentBPosition = 'top' | 'right' | 'bottom' | 'left';

export class ComponentB {
  doSomething(values: ComponentBPosition) {
    return values;
  }
}

Expected behavior:
// component-b.d.ts
export declare type ComponentBPosition = 'top' | 'right' | 'bottom' | 'left';
export declare class ComponentB {
    doSomething(values: ComponentBPosition): ComponentBPosition;
}

Actual behavior:
// component-b.d.ts
export declare type ComponentBPosition = 'top' | 'right' | 'bottom' | 'left';
export declare class ComponentB {
    doSomething(values: ComponentBPosition): import("../component-a/component-a").ComponentAPosition;
}

Playground Link: Not a playground, but a repo (run npm i && tsc, although the output is in the repo anyway under the build/ directory): https://github.com/lorem--ipsum/tsc-test
Related Issues: -
Thoughts:
The file that gets its type definition is component-b.tsx. It needs to be compiled after component)-a.tsx (I assume the order is alphabetical). The bug does happen when running tsc --watch, but only on the first run, not when component-b.tsx is changed. The returned type is correct when stated explicitly in the source file. It doesn't occur either when the two types (ComponentAPosition and ComponentBPosition aren't strictly similar).

Type aliases are just that, aliases. the compiler inlines the type alias value for every use of the alias. for visualization purposes (e.g. hover in an IDE, error messages, and declaration file emit), the compiler tries to find a "name" for a union type, and for that it uses the first type alias declaration it saw for this union type. in this case, it is ComponentAPosition. Since the two types are equivalent, there should not be any functional impact to the compiler picking one or the other.
A workaround to avoid this is to give explict type annotations to your functions. e.g.":
export class ComponentB {
    doSomething(values: ComponentBPosition): ComponentBPosition {
        return values;
    }
}

Good bot.


Fix Kusama block building

The consensus digest isn't exactly right.
The 2nd new block building for some reason takes forever. It is iterating all the offensive.reports and some other big storage maps and takes very long time to down all of those storages one by one.

conensus digest fixed
the block building time is due to session change from time wrap. this is a performance issue


New problems appears after solving the old one

When I solve a problem, a new list of problems appear. It would be good if the list of problems shown once persists till we need a new list of problems.

I will add an option to this soon. Thank you for notifying me.


Potential race condition in scheduler?

I noticed a few instances in manager/scheduler/scheduler.go where some checks seem suspect. In particular, we're doing something like
// Ignore all tasks that have not reached PENDING
		// state and tasks that no longer consume resources.
		if t.Status.State < api.TaskStatePending || t.Status.State > api.TaskStateRunning {
			continue
		}

in three places:

https://github.com/docker/swarmkit/blob/master/manager/scheduler/scheduler.go#L71

https://github.com/docker/swarmkit/blob/master/manager/scheduler/scheduler.go#L206

https://github.com/docker/swarmkit/blob/master/manager/scheduler/scheduler.go#L243

From the comment, it seems like we're assuming that tasks with current state > RUNNING do not consume resources, which is no longer true with https://github.com/docker/swarmkit/pull/2461. For the brief period where the task reaper hasn't deleted some tasks, I'm trying to figure out if the task reaper could race with the scheduler here.

I'm seeing something that might be related to this. A service was removed, but the task was orphaned, and is lingering in the task list. Is that expected behavior?
For example:
[ec2-user@manager1 ~]$ sudo docker node ps uyqwvctka5ow3c3ay1boztslh | grep w8cqmb3ng
w8cqmb3ngslj        qphwmhh7brgph9msda2r3c7ev.1                                                             manager1:9874/anaconda-0201-1517522214-runscript:latest                      worker1.us-west-2.compute.internal   Running             Failed 3 hours ago           "task: non-zero exit (1)"
[ec2-user@manager1 ~]$ sudo docker service ps qphwmhh7brgph9msda2r3c7ev
no such service: qphwmhh7brgph9msda2r3c7ev

This state persists despite removing the container on the node this task was running on.


@conda-forge-admin, please add user @dianaclarke

@conda-forge-admin, please add user @dianaclarke

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added user @dianaclarke in conda-forge/conbench-feedstock#2.


Feature request: Include Let's encrypt

It would be nice if EE would have the ability to setup https/tls using Le's Encrypt when creating (or modifying) a host.

Duplicate.
https://github.com/rtCamp/easyengine/issues/376
https://github.com/rtCamp/easyengine/issues/559

Duplicate of #376
letsencrypt.org - already on roadmap.


Bug 1838122: add admission webhooks to must-gather for kas-o

We need this information to understand certain bootstrapping loops caused by overly broad admission webhook configuration that prevent restarts.

/lgtm

/cherrypick release-4.4
@deads2k we want in ^ right?

/bugzilla refresh


Bugfix: Title change recommendations on the projector

Fixes the problemes when showing title change recommendations on the projector

@normanjaeckel Please review later

Ok.


Add solder jumper package and device

I'm still not sure about the polarized silkscreen, it looks a bit strange on a jumper. But let's merge it for now!

Well if you break it up and want to measure, it is helpful to know which pin is which.

Btw, it was not that easy to solder. Adding a dab of solder paste across it before reflowing didn't work, the pads were not connected after reflowing. With a soldering iron it worked out after adding a lot of solder, but you could see the surface tension trying to pull the bridge apart.

Btw, it was not that easy to solder. Adding a dab of solder paste across it before reflowing didn't work, the pads were not connected after reflowing. With a soldering iron it worked out after adding a lot of solder, but you could see the surface tension trying to pull the bridge apart.

Yes, I was thinking that it may be to far apart, but others convinced me that less space between the pads would be too hard to break up the connection :wink:. For reflow we'd probably need to add a 0-ohm resistor.


[Part 1] Part  xc7k160tfbg484-2, chapter 2 needed to complete linked tutorial

I think (and I could have been confused about this because it was the beginning of the assignment) that the installation instructions should have us install an additional part in order to follow the recommended tutorial (chapters 6 and 7 of the Xilinx guide).
When attempting to play along with chapters 6 or 7, the project won't run. The error messages that come up reference something about a "part" not being set, which is confusing when you're just starting out. When you google for the error message, it's a bunch of forum posts with people telling people to run commands in a "tcl console," which is also confusing (if you're in the GUI and don't know what "tcl" is).
What I ended up realizing is that when you open up the tutorial files, you need to specify which part (which also I think is called an "IP" = "intellectual property" ... and I just think of as "FPGA board") you're going to use as a target to build the code. (I guess it's analogous to picking your compiler target between x86 and ARM when compiling "normal" code.)
This is covered in the Xilinx guide in chapter 2 (specifically, page 15).
However, the part they end up picking ( xc7k160tfbg484-2) isn't one that we have installed (I think). So, instead, I picked a part that seemed to be very similar to the one they recommend. However, it's different enough that when you run through chapters 6 and 7, all of the numbers and diagrams are off from what they show in the guide. This makes following through and doing the analysis a bit tricky (especially if everything is totally foreign and you're still trying to get a bearing of what the heck is going on).
So, if installing that part for free is possible, it might be good for future iterations of the lab to have that part installed and point them to chapter 2 to get it setup.
(Apologies if I'm crazy here / feel free to shame me in the comments.)

One more tiny note about the tutorials: they take (or at least took me) waaaay longer than 30 mins. I would estimate 2hrs as a good ballpark median to provide on the assignment page. (Part of this could be someone used to writing high-level software repeatedly overcoming the shock that yes, you are analyzing and optimizing the clock ticks and hardware implementations of individual C++ instructions .)


Support package.json exports outside of Node

package.json exports are only supported in --moduleResolution node16 and --moduleResolution nodenext. This is expected behavior, but we are working on expanding it. A few points of common confusion:

If you’re using Node 12 or 14, you should use --moduleResolution node16. The features added to 16 have fully or mostly been backported to 12 and 14.
--moduleResolution node is for Node 11 and older. Its name is currently bad. We plan to rename it accordingly.
If you are using a bundler or a non-Node runtime, we do not currently have a mode for you. node16 and nodenext are only for Node.*

This has been thoroughly discussed elsewhere, so I won’t go into much  more detail—I’m creating this just to have an issue to track and point to, since #33079 is closed, but people continue to show up thinking it’s incomplete due to lack of support outside of Node. If you want to participate in discussion about current or future support for package.json exports or module resolution outside of Node more generally, it is critical to read #50152 first. Please do not comment here without reading that context.
* It’s worth noting that the (intentional) lack of support for package.json exports in the node (to be renamed node11 soon) mode can be, and has been, worked around for bundler users by many libraries in one of two ways:

Arranging index files and subdirectory package.json files of the library such that Node 11 (non-exports-respecting) and Node 12+ (exports-respecting) reach the same result
Setting a typesVersions that mirrors the structure of exports such that TypeScript’s --moduleResolution node will reach the same result as TypeScript’s --moduleResolution nodenext. Note that in this scenario, other resolvers that don’t respect exports, like Node 11, Parcel, and Browserify, will be broken. The syntax for typesVersions is very similar, but not identical, to that of exports. If you are a library author who intends to support Webpack, esbuild, Vite, Node 12+, etc., but not Parcel, Browserify, or Node 11, and you need help figuring out how to set up typesVersions as an interim workaround, feel free to ask here and I’ll assist.

Incorrect. As I have explained in https://github.com/microsoft/TypeScript/issues/33079 (multiple times, with at least 2 attempts of linking a repo, both of which were ignored) package.json exports fields are fully supported by moduleResolution node, they are just broken out of the box.
To reiterate the issue: As a library author you want your library to work for as many users as possible. This means it NEEDS to work with ANY resolution mode. Currently resolution mode "node" (the default!) requires the files linked in the exports[].types key to be in the root of the package
"exports": {
  "./": {
    "types": "./index.d.ts", // works fine, even if it re-exports types!
    "import": "./dist/index.js",
    "require": "./dist/index.cjs"
  },
  "./some-module": {
    "types": "./dist/types/some-module.d.ts", // does not work but should
    "import": "./dist/some-module.js",
    "require": "./dist/some-module.cjs"
  }
}

The resolution mode "node" should be fixed and not renamed. The other two options ("node16" and "nodenext") have actual breaking changes and are not even known to exist to 90% of users.
If you are renaming anything, then you should rename "node16" as that is a terrible name that will eventually be outdated and changing it then will cause even more confusion than renaming it to "node-lts" now.
Add a "node-legacy" option for people not concerned with security who are sticking with node11 or earlier - the default option should work as a default for 90% of users.

Incorrect.... package.json exports fields are fully supported by moduleResolution node, they are just broken out of the box

It’s a weird situation to have to assert my credentials on an issue that I authored in a project that it is my full-time job to work on, but here we are? I’ve worked on the TypeScript for the last 3.5 years and have spent nearly every working hour of the last 3 months or so on module resolution. I assure you, there are at most 2–3 people who know as much or more than me about TypeScript’s module resolution as it stands today, and they all have the “Member” badge on this GitHub repo. I’m not willing to debate the validity of the broad claims I’ve made in this issue. Secondly, this issue is about bundlers and non-Node runtimes, so while I appreciate that you were directly responding to my comments about Node, I don’t want to further discuss existing functionality (or naming conventions) intended for Node here. As I said in #33079, if you think you have a bug, please open a new issue. Thank you for understanding.

I’m not willing to debate the validity of the broad claims I’ve made in this issue. Secondly, this issue is about bundlers and non-Node runtimes, so while I appreciate that you were directly responding to my comments about Node, I don’t want to further discuss existing functionality (or naming conventions) intended for Node here.

Bundlers are exactly the place where the bug I am trying to bring to attention is of concern. Projects that don't use a bundler can simply refactor to node16 resolution, while bundlers often require the "node" module resolution mode and will throw errors when given import paths with file extension, which is what both "node16" and "nodenext" require.

Right, this issue will be resolved by a new module resolution mode for bundlers, which will include package.json exports support but will not require file extensions. Reminder:

If you want to participate in discussion about current or future support for package.json exports or module resolution outside of Node more generally, it is critical to read https://github.com/microsoft/TypeScript/issues/50152 first. Please do not comment here without reading that context.

Brief off-topic:

I’m not willing to debate the validity of the broad claims I’ve made in this issue.

FWIW, I really dislike how this came off. There has been so much confusion around topics of module resolution, so I wanted the information in this issue to be clear, concise, and authoritative, and to be immediately challenged on the fundamental facts underlying it would seem to undermine that goal. I wanted anyone else trying to follow along to rest assured that what I said in the issue body is correct and settled. Working on TypeScript certainly doesn’t make me an authority on everything about it and in most contexts I’m happy to talk through disagreement. The reason I don’t want to debate it here is just that this issue is intended to clarify, and I worked hard to ensure that the narrow set of information I presented is accurate. Attempting to prove my statements would just muddy the waters and be a nuisance for future readers—anyone really interested can validate them by reading moduleNameResolver.ts, but hopefully most folks can just trust me on this. At any rate, I apologize for the arrogant tone.

If you are a library author who intends to support Webpack, esbuild, Vite, Node 12+, etc., but not Parcel, Browserify, or Node 11, and you need help figuring out ...

I'd like to get some help figuring out how to make a library which will work for as many users as possible, that is:

users who have "type": "commonjs" in package.json, and use "moduleResolution": "node" - that's what everyone was doing a while ago

users who have "type": "module" in package.json, and use "moduleResolution": "nodenext" - that's what everyone is supposed to do in the future

users who have "type": "module" in package.json, but use "moduleResolution": "node" - such packages do exist

users who have "type": "commonjs" in package.json, but use "moduleResolution": "nodenext" - such packages also do exist

As far as runtime is concerned, there are only two variants of consumers, and the solution is not complicated: just transpile or bundle your code to produce commonjs variant, and use "main" for old node and "exports" for the modern node, which is also supported by modern bundlers:
{
    "exports": {
        ".": {
            "import": "./dist/index.mjs",
            "require": "./dist/index.cjs"
        }
    },
    "main": "dist/index.cjs",
}

What I'd like to know is how to produce type declarations that will be usable by all 4 variants of the consumers?

Spoiler alert: here's one way to do it, but I'd love to know if there's something better

Have type declaration generated in a separate folder under dist, for example dist/types  (use declarationDir option in tsconfig for that), and add nested package.json there with just one line:
{"type": "commonjs"}

Then, in your regular package.json, add types where appropriate:
    "exports": {
        ".": {
            "types": "./dist/types/index.d.ts",
            "import": "./dist/index.mjs",
            "require": "./dist/index.cjs"
        }
    },
    "main": "dist/index.cjs",
    "types": "dist/types/index.d.ts",

and add nested package.json there with just one line

Why is this nested package.json necessary in your example?
Definitely the easiest way to have subpath exports that “work” even in module resolvers that don’t support them is to do away with having a dist folder in your npm output and put your type definitions in the same directory as your JS files. So you might have something like
"type": "commonjs",
"exports": {
  "./subpath": {
    "import": "./subpath/index.mjs",
    "default": "./subpath/index.js"
  },
  // ...
}

subpath/
├─ index.mjs
├─ index.js
├─ index.d.mts
├─ index.d.ts

(Notice that I don’t even have to specify exports["./subpath"]["types"] because each JS file has a definition file sibling that matches its extension.) When any module resolver that supports exports tries to resolve an import path of "your-library/subpath", it will follow the package.json. When any module resolver that doesn’t support exports resolves the same path, it will just use the directory structure and find subpath/index.js / subpath/index.d.ts under the normal index-file lookup rules.
If you must have a dist folder, and/or must put your type definitions in a separate directory, this gets more complicated. The first way is to use directories with package.json files to redirect non-exports-supporting resolvers:
// @Filename: package.json
"type": "commonjs",
"exports": {
  "./subpath": {
    "types": "./types/subpath/index.d.ts",
    "import": "./esm/subpath/index.mjs",
    "default": "./cjs/subpath/index.js"
  },
  // ...
}

// @Filename: subpath/package.json
{
  "main": "../cjs/subpath/index.js",
  "types": "../types/subpath/index.d.ts"
}

(🚨 Warning: I’m showing a types/import/default trio here because it’s very common, but this can be a hazard in itself. It’s generally a better idea to have separate types for your ESM and CJS files and let them be matched up by file extension, as in my earlier example. If you use any default exports in ESM-format files, you must have separate types for the ESM and CJS variants. See #50690.)
Again, resolvers that support exports will be immediately directed into the right output folder by the root package.json, while resolvers that don’t will hit the subpath/package.json stub and be redirected from there. (That stub is only concerned with CJS variants, because resolver support for ESM and exports is pretty much 1:1 AFAIK.)
The other way to do this, which only changes the way TypeScript resolves and not any other runtimes or resolvers, is to set up a typesVersions that mirrors the exports:
"type": "commonjs",
"exports": {
  "./subpath": {
    "types": "./types/subpath/index.d.ts",
    "import": "./esm/subpath/index.mjs",
    "default": "./cjs/subpath/index.js"
  },
},
"typesVersions": {
  "*": { // all versions of TypeScript should respect this map
    "subpath": ["./types/subpath/index.d.ts"] // syntax is an array
  }
}

While this approach does not help support Node 11, Parcel, Browserify, etc., one advantage is it supports wildcards. All together:
"type": "commonjs",
"exports": {
  ".": {
    "types": "./types/index.d.ts",
    "import": "./esm/index.mjs",
    "default": "./cjs/index.js"
  },
  "./subpath": {
    "types": "./types/subpath/index.d.ts",
    "import": "./esm/subpath/index.mjs",
    "default": "./cjs/subpath/index.js"
  },
  "./*": {
    "types": "./types/*.d.ts",
    "import": "./esm/*.mjs",
    "default": "./cjs/*.js"
  }
},
"typesVersions": {
  "*": {
    "subpath": ["./types/subpath/index.d.ts"],
    "*": ["./types/*.d.ts"]
  }
},
"types": "index",
"main": "cjs/index.js"

Notice here that the top-level "types" itself actually feeds through the pattern provided in "typesVersions", so "index" gets resolved to "./types/index.d.ts". Having a wildcard that unconditionally maps TypeScript into the types folder in a directory structure like this is good, because it prevents imports like "your-library/types/subpath" from resolving, which would be a problem at runtime since there’s no JS in the types folder.
This complexity is why I’m not a fan of declarationDir and think the happiest path is if you can avoid publishing a dist folder in your npm structure altogether, but hopefully this gives you some strategies you can employ in different situations.
In every example I gave here, the library being imported is "type": "commonjs". All this controls is the implied format of .js and .d.ts files—the package can still be just as much ESM by shipping .mjs and .d.mts files, whose extension makes them explicitly ESM. I think this approach works better than flipping it to "type": "module", letting .js files be ESM, and needing .cjs/.d.cts extensions to force a file to be interpreted as CommonJS, because those files are not eligible for extensionless or index-file lookups, which was a technique I relied on in my first example. If you don’t rely on that technique, you can probably use "type": "module" if you must and arrange everything else to work, but if your goal is maximum compatibility, a better way to set yourself up for success is to use a format where every resolver, old and new, agrees that .js and .d.ts files are CJS, then put ESM on top of that where supported.
I gave these examples from memory, so while I’m quite sure the overall ideas are sound, beware that there may still be typos or small errors. I’ll try to port this to a working repo today or tomorrow and fix any errors that turn up in the process.

Definitely the easiest way to have subpath exports that “work” even in module resolvers that don’t support them is to do away with having a dist folder in your npm output and put your type definitions in the same directory as your JS files. So you might have something like

Forgive my ignorance: does this example imply that the project source code has both index.mts and index.ts files? If so, what happens if the source code is only written in one format (let's say esm in a .ts file), would the compiled output for esm and cjs and their corresponding declaration files conflict (in other words, would both compilations output a index.d.ts file?).
Hopefully this question makes sense. Sorry if it doesn't.

In talking about the published package contents, I wasn’t necessarily making any assumptions about how it was generated. tsc isn’t designed to help you generate dual ESM and CJS packages from a single source; while it might be possible to do that in some circumstances, it would be really easy to mess it up. tsc will always output a declaration file with an extension that matches the input file, so if a .ts is interpreted as ESM during the compilation, but later you flip the package.json "type" to "commonjs", the .d.ts file that got emitted might be problematic. Given that generating dual-mode packages is not a goal of tsc, I would recommend folks use an external tool that is designed to do that, but I don’t have personal experience with any so can’t make a recommendation. It’s something I hope to investigate later.

First, thanks for the detailed explanations!

Why is this nested package.json necessary in your example?

Because the package itself can then be "type": "module" - javascript tooling is already mostly ESM, and having config .js files which are actually ESM is becoming the norm.

If you use any default exports in ESM-format files, you must have separate types for the ESM and CJS variants. See https://github.com/microsoft/TypeScript/issues/50690.)

Thanks for the heads up, that's one more argument against default exports I guess.

In every example I gave here, the library being imported is "type": "commonjs". All this controls is the implied format of .js and .d.ts files—the package can still be just as much ESM by shipping .mjs and .d.mts files, whose extension makes them explicitly ESM.

If all d.ts are commonjs in a published library, and if the library consumer uses "moduleResolution": "nodenext", then the library can only use dependencies which also have only commonjs type declarations. Attempt to import a ESM module gives an error
error TS1479: The current file is a CommonJS module whose imports will produce 'require' calls; however, the referenced file is an ECMAScript module and cannot be imported with 'require'. Consider writing a dynamic 'import("dual-lib")' call instead.

On the flip side, due to the same error, as soon as you start shipping  ESM types, the library becomes unusable by consumers who are commonjs and use  "moduleResolution": "nodenext".
I don't know any way around this, it looks like keeping the types commonjs is the only option for the time being, can't wait until TypeScript ships the promised new module resolution mode for bundlers.

Given that generating dual-mode packages is not a goal of tsc, I would recommend folks use an external tool that is designed to do that, but I don’t have personal experience with any

From my limited experience with rollup, it looks like rollup-plugin-typescript could do the job if you run rollup twice with different configs. There's also transform which could be plugged into rollup-plugin-typescript to add .js extensions to relative imports in ESM output, but I haven't tried it myself yet.

If all d.ts are commonjs in a published library, and if the library consumer uses "moduleResolution": "nodenext", then the library can only use dependencies which also have only commonjs type declarations. Attempt to import a ESM module gives an error

Yeah, good point. But this is an issue whether the library is using TypeScript / shipping types or not. I would rephrase your sentence to:

If all .js are CommonJS-format in a published library, and if the library consumer uses any ESM-format files in Node, then the library can only (synchronously) use dependencies which are also CommonJS-format.

This is the core problem library authors are facing with Node. However they choose to solve or work around it, the TypeScript types just follow the implementation.

I’ll try to port this to a working repo today or tomorrow

As promised: https://github.com/andrewbranch/example-subpath-exports-ts-compat

and fix any errors that turn up in the process

I didn’t notice any issues with the examples I posted, but the ones in the repo are programmatically validated, more complete, and discussed in more detail.

In that repo, only the extensionless library supports dual ESM/commonjs type declarations. Not sure if it's important enough to be mentioned in the Pros/Cons sections and in the table, but I made the PR anyway. The big "Con" is that it's not clear what (and if) tooling can be used to generate dual type declarations from the single source, but it's a topic for separate discussion maybe.

Is there any eta for this? would be great if the following case with module/nodenext:
...
"./some-module": {
    "types": "./dist/types/some-module.d.ts", // does not work but should
    "import": "./dist/some-module.js",
    "require": "./dist/some-module.cjs"
  }
...

... would work..

@nivida that already works in --module nodenext; you can see an example here

As someone who's in the apparently unusual camp of having a project with type:module and moduleResolution:node I wanted to point out that at least for my case, 'upgrading to nodenext' was a breaking change that I had to reverse, since nodenext caused compilation to resolve to the types entry of exports over and above the source files in my monorepo.
So I'd be concerned if broadening the application of node16 and nodenext (and maybe retiring/deprecating node) meant I ended up with no modes that allowed me to guide tsc to resolve packages to actual Typescript source locally.
Let me know if this is the wrong issue to document this problem and there's a better place for it.
With moduleResolution:node
This was my proven, reference config. I double-checked via tsc --traceResolution that packages internal to the monorepo (like @starter/sum referenced by @starter/multiply)  were correctly fulfilled directly by their source files, and without pointing to build artefacts and .d.ts by mistake (which would make local dev error prone). Here's the proof...
[packages/multiply]$ npx tsc --traceResolution | grep @starter/sum | more
======== Resolving module '@starter/sum' from '/home/cefn/Documents/github/starter/packages/multiply/src/index.ts'. ========
======== Module name '@starter/sum' was successfully resolved to '/home/cefn/Documents/github/starter/packages/sum/src/index.ts'. ========

With moduleResolution:node16 or moduleResolution:nodenext
This effectively introduces a regression to my tooling, by looking at exports, then ignoring the order of default vs types, and settling on the types in second position, rather than the .ts sibling of the default .js target in first position. Here's the proof...
[packages/multiply]$ npx tsc --traceResolution | grep @starter/sum | more
======== Resolving module '@starter/sum' from '/home/cefn/Documents/github/starter/packages/multiply/src/index.ts'. ========
======== Module name '@starter/sum' was successfully resolved to '/home/cefn/Documents/github/starter/packages/sum/dist/esm/index.d.ts' with Package ID '@starter/sum/dist/esm/ind
<EMAIL_ADDRESS>========

You can see the reference repo at https://github.com/cefn/starter/tree/export-typescript-source which is only there to explore this kind of thing, so I'm happy to try workarounds.

nodenext doesn't seem to honour exports field when utilising subpath-patterns. Are there workarounds for this? Or plans to implement support for it? I generally want to do something like this in my package instead of introducing package.json bloat and possible maintenance  issues.
"files": [
  "/dist"
],
"exports": {
  "./*": "./dist/*.js",
  "./dist/internals/*": null
},


Postcondition number different from contract call

What version of Stacks.js are you using?
"@stacks/connect": "^7.2.1",
"@stacks/transactions": "^6.11.0",

Describe the bug
When creating post condition with a very big number, the amount will turn into a random number
How to reproduce
const stxAddress = userData!.profile.stxAddress.mainnet;
const amount =<PHONE_NUMBER>00000000000n
await openContractCall({
  anchorMode: AnchorMode.Any,
  contractAddress: 'SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9',
  contractName: 'age000-governance-token',
  functionName: 'transfer-fixed',
  functionArgs: [uintCV(amount), principalCV(stxAddress), principalCV('SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9'), optionalCVOf(undefined)],
  postConditions: [createFungiblePostCondition(stxAddress, FungibleConditionCode.Equal, amount, 'SP3K8BC0PPEVCV7NZ6QSRWPQ2JE9E5B6N3PA0KBR9.age000-governance-token::alex')]
});
}}

Expected behavior

Reproduce repo:
https://github.com/alexgo-io/post-condition-example

Post-conditions can only handle amounts up to 8-byte length. I'm adding a check to serialization that will throw if the amount is larger.

Added a check here: https://github.com/hirosystems/stacks.js/pull/1612/files
It depends on your use-case, but it should be possible to check for the byte-length of the amount users want to send. According to SIP-005 in Stacks we can only post-condition for amounts up to 8-bytes integer length.

Also Stacks transfers can only send amounts up to 8-bytes in length.

Also Stacks transfers can only send amounts up to 8-bytes in length.

Hi @janniks so you mean if post-condition fails due to 8-bytes length, then the underlying transfer should also fail?

Stacks transfer transactions (STX or other fungible tokens) are encoded to only have 8-bytes of "amount" information in the wireformat (the same goes for post-conditions). This is a part of SIP-005.
So we can't encode more than 8-bytes for the amount value, trying to would cut off the amount in serialization/deserialization code.


[Issue] Should not Open Jenkins Port [8888] in Release Product

In GitLab by @Robin-Mao on Sep 19, 2017, 17:56

In GitLab by @yhua123 on Nov 8, 2019, 07:37
#343

In GitLab by @yhua123 on Nov 8, 2019, 07:37
LGTM

In GitLab by @sokril on Nov 8, 2019, 08:10
closed

In GitLab by @sokril on Nov 8, 2019, 08:10
assigned to @yhua123


It will be good to have a custom element support

I'm a little bit frustrated, because it seems that we dont have a way to add a custom element, in the CMS. Thinking in user exp, i want to add custom classes to a <p> or any heading tag, and the user dont need to know what will be added. Because in front-end i want to have a bunch classes that will be used.... The CMS will be managed by people that dont know much html, and in thoses cases.. when more abstraction, i think will be better.... Aside, good repo and stuff. <3
Describe the solution you'd like
Could be possible to use this feature of custom elements.
Ref

I'm not sure what you mean, via the editorConfig options your able to add somewhat custom styles and elements. Here, I'm adding custom header elements that mostly output Tailwind classes.
/* CKEditor configuration */
configs: {
  custom: {
    editorConfig:{
      heading: {
        options: [
          { model: 'heading1', view: 'h1', title: 'Heading 1', class: 'ds--h1' },
          { model: 'heading2', view: 'h2', title: 'Heading 2', class: 'ds--h2' },
          { model: 'heading3', view: 'h1', title: 'Display 1', class: 'ds--d1' },
          { model: 'heading4', view: 'h2', title: 'Display 2', class: 'ds--d2' },
          { model: 'heading5', view: 'p', title: 'Body', class: 'ds--d2' },
          { model: 'heading6', view: 'p', title: 'Body - Medium', class: 'ds--d2 ds--medium' },
          { model: 'heading7', view: 'p', title: 'Body Alt', class: 'ds--d2' },
        ]
      }
    }
  }
}


Arabic language

Would it be possible to have Arabic text fields from RTL when Arabic is added to languages :
languages:
ar: Arabic
Maybe implement something that loops though the bind attr's which contains _ar and set it to RTL ?

@pauloamgomes this seems to be a simple but effective idea 🤔 need to hink about it. thanks for the suggestion 👍


test_import_export: Don't hard-code ZULIP_VERSION in fixtures.

Fix-up to #31681
Otherwise, these tests fail if ZULIP_VERSION is different locally from what's hard-coded. Use a placeholder instead and replace dynamically in a helper function.

Merged, thanks @mateuszmandera!

This is no longer a backport candidate given we're not backporting #31681.


Add pretty markers

Add a marker symbol for query points.
Visually pick up markers to clarify which textbox changes which marker

Added draggable markers with 8cb250f79bf850a29903b04e81849d9e642001ea Keep this issue open for now, since we don't have via markers yet.
Also visually connecting search text boxes with markers is not ytet done

Text boxes have a colored dot next to them. The via points would need numbers since they all have the same color.

Closing this for now, postponing the number stuff until later


Cannot load models

rasa NLU version : 0.8.0a10
Used backend / pipeline: "spacy_sklearn"
Operating system (windows, osx, ...): tried in Windows 8.1 and mac OS X
Issue:
I was using the latest version of Rasa NLU and was able to train a model using the configuration and example data given by the docs. However, when I tried to run the trained model using this command
python -m rasa_nlu.server -c config_spacy.json --server_model_dirs=./model_YYYYMMDD-HHMMSS
it gave out this error message, though the server still ran with the default output ('greet' with confidence 1):
ERROR:root:Failed to load model './model_20170418-162706'. Error: 'actions'
Traceback (most recent call last):

  File "C:\Users\ASUS\AppData\Local\Programs\Python\Python35\lib\site-packages\rasa_nlu\data_router.py", line 84, in __create_model_store
    interpreter = Interpreter.load(metadata, self.config, self.component_builder)

  File "C:\Users\ASUS\AppData\Local\Programs\Python\Python35\lib\site-packages\rasa_nlu\model.py", line 249, in load
    component = component_builder.load_component(component_name, context, model_config, meta)

  File "C:\Users\ASUS\AppData\Local\Programs\Python\Python35\lib\site-packages\rasa_nlu\components.py", line 234, in load_component
    component = registry.load_component_by_name(component_name, context, model_config)

  File "C:\Users\ASUS\AppData\Local\Programs\Python\Python35\lib\site-packages\rasa_nlu\registry.py", line 89, in load_component_by_name
    return load_component(component_clz, context, config)

  File "C:\Users\ASUS\AppData\Local\Programs\Python\Python35\lib\site-packages\rasa_nlu\components.py", line 27, in load_component
    return component_clz.load(*load_args)

  File "C:\Users\ASUS\AppData\Local\Programs\Python\Python35\lib\site-packages\rasa_nlu\extractors\spacy_entity_extractor.py", line 103, in load
    ner = EntityRecognizer.load(pathlib.Path(ner_dir), spacy_nlp.vocab)

  File "spacy/syntax/parser.pyx", line 149, in spacy.syntax.parser.Parser.load (spacy/syntax/parser.cpp:6845)

KeyError: 'actions'
INFO:root:Started http server on port 5000

Which version of spacy are you using?

@tmbo I'm using spacy 1.8.0

We haven't ported / tested 1.8 yet. Might be an issue with the move from 1.7 to 1.8. I'll create a separate issue for that. In the meantime you could try installing 1.7.x

Ok, I verified it is an issue with the update to spacy 1.8.0. I'll have a look at it, but in the meantime you can downgrade to 1.7 using pip install -U spacy==1.7.5

This is an issue on the spacy part and I haven't found a way to get around this yet. https://github.com/explosion/spaCy/issues/999

I'll close this in favor of #284. In the meantime, don't use spacy 1.8


autoload octokit as it won't be used unless project is remote repo

Which will never be the case for some deployments. Fixes #268
Seems to work, see below. I'm not of a good way to write a test since whether it is loaded would depend on whether any test accessing a remote repo had been run.
$ irb
irb(main):001:0> require 'licensee'
=> true
irb(main):002:0> defined?(Octokit)
=> nil
irb(main):003:0> Licensee.project('.')
=> #<Licensee::Projects::GitProject:0x00007fea220e5c90 @repository=#<Rugged::Repository:70321785220620 {path: "/Users/mlinksva/G/licensee/.git/"}>, @revision=nil, @detect_packages=false, @detect_readme=false>
irb(main):004:0> defined?(Octokit)
=> nil
irb(main):005:0> Licensee.project('https://github.com/benbalter/licensee')
=> #<Licensee::Projects::GitHubProject:0x00007fea2240e7a0 @repo="benbalter/licensee", @detect_packages=false, @detect_readme=false>
irb(main):006:0> defined?(Octokit)
=> "constant"

Huh. I had no idea you could do that.

You must have had the idea and forgotten because https://github.com/benbalter/licensee/commit/c98761e2e74d0787114391e0f57ce926d40422b5 😄  which I suppose must've reduced memory upon requiring licensee a bit (none of licensee's own components being autoloaded there are large).
I'm not sure the module scoping of autoloads seen in commit above -- and seems to be a common pattern -- accomplishes, couldn't find an explanation with quick web search.

I knew you could use it for subclasses/modules, but didn't realize you could use it for external Gems. It's in the loadpath, and seems to work, so 👍


Upload private corpus to the database

AS Data Management Interface user
I WANT TO upload my own new private NER corpus from the database
IN ORDER TO train a new model and teach new entities to the model.
Acceptance Criteria:

[ ] Get the corpus from the user via uploading module
[ ] Format and upload private corpus to Postgres database via Ruuter POST /corpora and ReSQL POST /insert_corpora_task/batch

Additional
We’re getting the corpus through Ruuter.
IMPORTANT
Ruuter does not handle file uploads at the moment, so we should solve this by mocking the upload itself. Request comes in, nothing is actually uploaded, and the process uses a specific demo file already existing on disk. This is a Ruuter limitation that will be solved in the future, but is not solved yet.
Uploading corpus schema

@alimuhammadahmer @kunnark

This issue is marked as "In progress" but should be groomed first;
ACs must contain all REST endpoints used to get the result.

Ruuter Endpoint:
POST /corpora
Resql Endpoint:
POST /insert_corpora_task/batch

@turnerrainer

This issue is marked as "In progress" but should be groomed first;
ACs must contain all REST endpoints used to get the result.

Status changed to 'Backlog'
AC's added endpoints, bpmn-schema added.


🌐 Add Portuguese translation for docs/pt/docs/tutorial/static-files.md

Added translation for pt to docs/pt/docs/tutorial/static-files.md.

Thank you @batlopes! :cake:
And thanks for the reviews @LorhanSohaky, @cassiobotaro, and @handreassa :bow: :coffee:
I'll accept this as it is right now, and maybe another iteration with @LorhanSohaky's suggestions could be made on top, with extra reviews, to keep the conversation about those changes apart but take this as it is for now.


Currency Unit

The 'Currency Unit' class has this rdfs:comment "A unit of money. Note: this is the only unit whose conversion factors include time (i.e., the conversion rates change on a daily basis)."
I can't see where time is a factor in the axioms on this class - there's no 'Time Instant' axiom.
Cheers, Dougal

Thank you for your comment.  This is a note to the reader about how currency is different from other units.   In the event that someone wanted to track conversions over time, they would have to extend the ontology.
Its always a judgment call how much of what is in fact true is worth including in gist. If we put everything in, it would have a lot of bloat that which was of interest to relatively few.

Thanks for your reply. I appreciate this perspective, it's a fine line to walk. This seems to work ok if I extend Currency with a restriction e.g. a data property to capture datetime data on the Currency class.
<!-- https://ontologies.semanticarts.com/gist/CurrencyUnit -->

<rdf:Description rdf:about="https://ontologies.semanticarts.com/gist/CurrencyUnit">
    <rdfs:subClassOf>
        <owl:Restriction>
            <owl:onProperty rdf:resource="https://ontologies.semanticarts.com/gist/localDate"/>
            <owl:someValuesFrom rdf:resource="http://www.w3.org/2001/XMLSchema#date"/>
        </owl:Restriction>
    </rdfs:subClassOf>
</rdf:Description>

</rdf:RDF>
However I can't make any modification to the underlying GIST definition or Protege will force-reload the GIST import. It does seem to sometimes display odd behaviour anyway: see https://github.com/protegeproject/protege/issues/722

WON'T FIX: This is an important point that will not be handled in gist at this time.


Plot histograms only when visible (ReactVisibilitySensor)

A possible solution to #201 that doesn't involve a "show more" button: only renders the plot if the element is visible. Uses package react-visibility-sensor.
One note, I had to hard-code a height=200px div in the case of not visible in order for this to work. I'm sure there's a better workaround.

This leads to some jittering during scrolling for me, as the top row of histograms will un-render and cause you to scroll back up briefly.
We're using the "show more" pattern in the draws table, I think it makes sense to do the same here.

#205