Milestone 2: Login and registration page

In this pull request I have implemented the following:

Updated devise views for login and registration pages.

Approved ✔
Hi @MNisarAli ,
Great job, Your project is complete! There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉
(Highlights) Good Points: 👍
Your work is well documented. ✔
The correct workflow is used. ✔
All linters checks are ok. ✔
(Changes Required) Aspects to improve: ♻
N/A
[Optional] suggestions:
N/A


Cleanup files

As discussed we should remove when possible data / generated files from the repo.

    deleted:    knowledge_graph/Climate_Mind_DiGraph.gpickle
    deleted:    knowledge_graph/Climate_Mind_DiGraph.json
    deleted:    knowledge_graph/Climate_Mind_DiGraph.yaml
    deleted:    knowledge_graph/Climate_Mind_Digraph_Test_Ont.json
    deleted:    knowledge_graph/output.csv

I let Climate_Mind_DiGraph.gpickle as requested but we should come up with another solution.

Changed the make_network.py and make_graph.py imports to be relative. Those scripts should be called from the project root directory directly.
Also the generated files will not be in knowledge_graph but in the root also.

When we get to the point where we want to exclude data files from the repo, we should also add those extensions to the .gitignore file to simplify keeping them out after the tracked copies have been deleted (this will block them from being added to commits in the future).


ios 11.2 do not request again permissions

Expected Behaviour
If user request to use this feature permission should be requested again (even if disallowed earlier)
Actual Behaviour
Crash with message meaning permissions not granted
Reproduce Scenario (including but not limited to)
Steps to Reproduce
Create a simple app with this plugin (ie: ionic app)
Launch it on ios 11.2 (reproduced on 6s, 6s+, 7 and X)
Launch plugin
Give permission
Close app
Go to settings
Change app permission for camera
Reopen app
Launch plugin
Platform and Version (eg. Android 5.0 or iOS 9.2.1)
ios 11.2
Plugin 6.0.8
(Android) What device vendor (e.g. Samsung, HTC, Sony...)
N/A
Cordova CLI version and cordova platform version
@ionic/cli-utils  : 1.19.1
ionic (Ionic CLI) : 3.19.1

global packages:
cordova (Cordova CLI) : 7.0.1

local packages:
@ionic/app-scripts : 3.1.2
Cordova Platforms  : ios 4.5.1
Ionic Framework    : ionic-angular 3.9.2

System:
ios-deploy : 1.9.2
ios-sim    : 6.0.0
Node       : v6.11.2
npm        : 5.3.0
OS         : macOS High Sierra
Xcode      : Xcode 9.2 Build version 9C40b

Plugin version
6.0.8
Sample Code that illustrates the problem
N/A
Logs taken while reproducing problem
N/A

This is not possible, on iOS you can only ask once.
But keeping it open as it shouldn't crash if the permission was not granted

Anyway, I think this was fixed. Can you try with latest version (7.1.0)?

Ok It is not crashing anymore. I just get error about permission.
Why ios is so complicated compared to android 🗡


Transparent window

Could the window be made transparent? Show the desktop background image instead.
And have no window decorations?
Currently its - https://i.imgur.com/xSqDNxk.png

I do not know if this is possible with GTK, but I will look into it :)

Aw, back to Kitty it is.
Thank you!

I do not know if this is possible with GTK

https://docs.gtk.org/gtk4/method.Widget.set_opacity.html
Looks like we can! Will play around with it...

setting the background colour to complete transparency works for me on KDE

hi @Strykar , sorry for late reply, I wasn't watching the repo for a while.
The window of Cavalier is actually fully transparent (https://github.com/NickvisionApps/Cavalier/blob/main/NickvisionCavalier.GNOME/Resources/org.nickvision.cavalier.css#L2), it's just the default background color drawn by Cavalier is identical to the one from Adwaita theme, giving impression that the window itself is not transparent. But the background color can be changed in settings to any other, including fully transparent, and together with "borderless window" setting it's possible to make Cavalier only show foreground bars like on screenshot above.
But on your screenshot I see the problem. Lack of rounded corners and very thick window borders indicate that there's no compositing available for the app (= no transparency). It means that either there's something wrong with your Cavalier installation, or there's something wrong with your graphics drivers, or you use Xorg window manager that has compositing disabled or doesn't provide it at all. In Xfce and KDE it's possible to enable/disable compositing in settings. If you use window manager that doesn't provide compositing (for example, openbox), take a look at picom or  Xcompmgr.
Anyway, there's nothing to do on Cavalier side, so I'm closing the issue.

Thanks for the update, I am using Gnome on Wayland with Nvidia's binary drivers.
I assumed everything under the hood was was working as Kitty terminal can do transparency fine.

using Gnome on Wayland with Nvidia's binary drivers.

I once has the same issue in GNOME (not with Nvidia tho, Intel graphics) with some flatpak apps, caused by specific versions mismatch of Mesa libraries on the host and inside flatpak (as I understood, at least). But updating everything and reboot solved it, so that's not your case I guess.
The only thing I can suggest is to run the app in a terminal (flatpak run org.nickvision.cavalier for flatpak or snap run cavalier for snap) and look if there are some error messages related to graphics that will maybe help you search for hints or possible solution.
Hope you will find a fix :)


License checks still exists for Visual Studio 2022 extension

As per.: https://blog.ironmansoftware.com/powershell-pro-tools-end-of-life/
This will getting to be Open-Source - but when you install the extension for Visual Studio 2022 it still showing this:

This is installed from the Marketplace from the link over here: https://github.com/ironmansoftware/powershell-pro-tools
V. 2024.3.0

The Visual Studio extension open source release is still in progress: #45

Roger @adamdriscoll - looking forward to that 😃


[Accessibility - start] Update robolectric comment

@florina-muntenescu can you please take a quick look at this? This was based on your comment a while ago about upgrading Espresso


I have installed push.js but it still don't run on node.js backend

const express = require('express');
const app = express();
const Push = require('push.js')
app.use(express.json());
app.get('/', (req, res) => {
res.sendFile(__dirname + '/index.html');
});
app.post('/', async (req, res) => {
var f = 0 ;
// I get values here from the frontend's form and process them and do calculations to update f
if(f>10)
{
Push.create("Hello nice" );
}
else
{
Push.create("POOOOOOOOOOR man try again" );
}
});
app.listen(3000);

I installed push.js as a npm module but I don't understand after my server is started and rendered index.html, I see the following as an error:

Please try to understand why I want to do so, in my backend I fetch a value from the frontend's form and then process it and if it is in the range I need to send a push notification somehow to the frontend user which I am failing to do so because of the above error.
I am able to send a notification by making a notify button on the frontend and if the user press it, as I included the .js files in my HTML and things work fine, but I just don't understand what is the use of npm install push.js if a node.js backend is unable to send the notification to frontend when desired.

The error states: navigator is not defined, which makes sense as navigator is only available in browsers and not in node. I think this library is for browser only.

This is the npm library used in front-end web pages and cannot be used in nodejs


wrong unit at daswetter.0.NextDays.Location_1.Day_1.Maximale_Temperatur_value

I just fixed that typo here. You should delete that datapoint and it will created with correct unit next run time..


Followed the instruction in first_finetune_tutorial but cannot download the llama model

I was following the instruction in https://torchtune-preview.netlify.app/examples/first_finetune_tutorial.html. In the session of https://torchtune-preview.netlify.app/examples/first_finetune_tutorial.html#downloading-a-model, I went to https://huggingface.co/meta-llama as guided and went the llama website https://llama.meta.com/llama-downloads/ to request access to Llama. The email addressed used is the same as in my HF account. However I still got the same error,
(torchtune)  ~/src/torchtune (main)]$ tune download meta-llama/Llama-2-7b --output-dir /tmp/llama2 --hf-token hf_qff<rest of the token>
Ignoring files matching the following patterns: *.safetensors
usage: tune download <repo-id> [OPTIONS]
tune download: error: It looks like you are trying to access a gated repository. Please ensure you have access to the repository and have provided the proper Hugging Face API token using the option `--hf-token` or by running `huggingface-cli login`.You can find your token by visiting https://huggingface.co/settings/tokens

I'm using an internal devgpu server.
It would be great to have a clearer instruction as first_finetune_tutorial the first impression to users.

@iseeyuan thanks for filing this issue. Can you confirm that you're able to see the files here?
https://huggingface.co/meta-llama/Llama-2-7b-hf/tree/main
Access issues are hard since there's no way for us to verify this. Maybe we can make the error messgae more helpful (though I think it's pretty precise in this case).
cc: @joecummings in case you have any ideas

@kartikayk , that's a good point! I think the instruction is missing the link you just provided, https://huggingface.co/meta-llama/Llama-2-7b-hf/tree/main . When I get there I realized I need to sign the agreement. It's not mentioned in any instructions I followed, including the HF page, https://huggingface.co/meta-llama. It shows only when I click one link, and click files.
Now I have submitted the request for access from llama's HF page (not the llama's official page), and wait for the approval.
It would be great to add a couple of lines in the first_finetune_tutorial instruction, like "To check if you have access to the llama2 models in Hugging Face, click https://huggingface.co/meta-llama/Llama-2-7b-hf/tree/main. If you don't see the model files, instead some license agreement, make sure you have completed the agreement and submit the request to access from there."
I'm still waiting for the access, as "Your request to access this repo has been successfully submitted, and is pending a review from the repo's authors."

@iseeyuan Thanks for your detailed investigation. We'd be thrilled to accept a PR updating the tutorial with the new instructions- the source file can be found here.
Just curious - how long did you have to wait for access to the model weights after signing the agreement? And did you use your personal email or work email?

@joecummings https://github.com/pytorch/torchtune/pull/650.
Sorry I can't recall exactly how many minutes. I submitted the request, wait for a moment and signed off. It should be around 5-10 min.

Closing as completed by #650 ! Thanks for your contribution @iseeyuan


don't store data as state in DataMixin

In our app, we render DataTable immediately with no data, and then render it again when our data is loaded. Our data also continues to occasionally update in the background. DataTable does not currently update with the new data.
I spent some time looking at the code and this is happening because the initialData that is passed in is copied to data and stored as state. Since state persists across renders, it does not update (unless you happen to filter, which copies from initialData again, which does properly get updated).
I've forked and made a fix that is working for us, as this issue makes react-data-components unworkable for us, but we really like it otherwise.
My fix is essentially to not store data as state at all, and do all the sorting, filtering and pagination at the time buildPage is called. Although it is working for us, our app is currently new and small so I don't know whether this would have unexpected performance implications or other issues.
I was unable to get tests running -- from a commit back in March, it sounds like that might be a known issue.
If it makes sense to you, we would love to get this merged (or for the issue to be fixed another way) so that we can use your repo for future changes, etc.

Hey, thanks for your pull request! The problem I see here is that buildPage is called for every page change, and it's sorting and filtering when it's not needed. How about initializing the state for every prop change? You can do that using componentWillReceiveProps. Checkout the branch https://github.com/carlosrocha/react-data-components/tree/reinitialize-on-propchange and let me know if that works for you.

That makes complete sense.  I just tested your branch and it does work for us.  Will you be merging that change into master?
Thanks for the feedback and help!

I just pushed the changes to master and it's now on npm.


Support POSTing of InputStreams with custom contentType

The EncoderRegistry has a special treatment for byte arrays, so that they are handled as is and no .toString() is called upon them. The same handling needs to be done for InputStreams.
Fixes #1160

Thank you very much! Great find!


feat: rewrite operations

Description
This PR incorporates some of the learnings with regards to how datafusion "should" be used (or what I think I understood so far how it should be used) and how this applies to our operations module. It also embraces the IntoFuture trait stabilized in rust 1.64.
More specifically:

Model operations as builders that implement IntoFuture
While we figure out how to deal with state sharing - just consume the table as it needs to be updated anyhow (right?)
push datafusion dependencies into command implementations, so we can more easily extend to commands that do not require datafuison.
have command-spcecific errors that map to DeltaTableError (the top level error variants likely have to be refined, for now, many command errors map to a GenericError, which at least shows meaningful error messages.)
an updated PartitionWriter implementation that allows more fine graunlar control on how data is written

Some of choices or trials here mainly (hopefully) make sense when viewed as preparation for what's to come.

For the conflict resolution (#632), we want to leverage some information on especially the scanned files during an operation. The plan is to leverage the execution metrics from the datafusion plans for this. We already do this in some of the datafusion tests, to make sure we properly use the file metrics in scans.
The new partition writer implementation is kept separate from the existing one for now, to be able to more easily iterate.
I replicated a minimal implementation of the transactions, but the main update for this will follow with conflict resolution.

To keep it somewhat simpler to review I tried to keep the major changes contained in the operations module. If we adopt this the idea is to migrate all existing operations (create, vacuum, optimize) to the builder pattern and into the operations module, and have the methods on DeltaTable just return a pre-populated builder. I think this is where IntoFuture shines, as we can await them just like before.
Implementing this, one of the things I found most convenient, is that we now have the memory:// store available. Coupled with the sync_stores helper, it makes setting up and validating test cases that mutate an existing table very convenient - yay object_store 😆.
There are some things I want to clean up, but it would be great to get some feedback on if this is where we want to go - @houqp @wjones127 @fvaleye.
Related Issue(s)

Documentation

So, for example, I don't think the Create command and the Load/Write commands belong in the same module, since the first you pass in actions (low-level) while the others are more high-level and deal with data. I'll think about this some more though, since I'm not 100% sure this makes sense.

Okay I think I mis-read the purpose of Create: it's not a low-level API, it's just to create a table, so there's isn't any data writing interaction involved. So we should just think of operations module as the DataFusion-based high-level API. 👍

@wjones127 - sorry for letting this sit for so long. Did some minor tweaks, mainly related to so deprecations in latest chrono and resolved some conflicts with main.
could you re-approve? :)


Fix MSI path not being included on macOS builds

msi_linux.go would only be included on Linux machines, and not non-Windows machines as indicated by the build tag.

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Thanks for catching this and submitting a PR, it is much appreciated.


Add BoneAttachment3D::get_skeleton() method

This adds a get_skeleton() method to BoneAttachment3D to make the node consistent with SkeletonModifier3D.
Not sure what we want to do with get_external_skeleton() - it really should be get_external_skeleton_path() but at this point I guess we just leave it to avoid breaking changes.
I don't know C++ so hopefully this is all correct.
Closes https://github.com/godotengine/godot-proposals/issues/10454
Sample project with attached, external attached and unattached BoneAttachment3Ds. Hit play and the new get_skeleton() method will be called on all 3. boneattachment.zip

We tend not to expose both the get node pointer and the get path. What does @lyuma  @TokageItLab think?

If the ExternalSkeleton is not set, BoneAttachment cannot easily determine if it is under a parent skeleton. It is also difficult to determine if the ExternalSkeleton is getting it right. So I think adding this API makes sense.

Thanks!


Xamarin Auth Android manifest requires workaround

When Xamarin merges AndroidManifest.xml files together in its build step it does not correctly fold elements together when it should (https://github.com/xamarin/xamarin-android/issues/3428). This causes issues for the AppCenter Auth setup in the AndroidManifest.xml file as described in the AppCenter docs.
The docs tell us to add the following to the manifest:
<activity android:name="com.microsoft.identity.client.BrowserTabActivity">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />

        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />

        <data
            android:host="auth"
            android:scheme="msal{Your App Secret}" />
    </intent-filter>
</activity>

This should complement the generated activity from the BrowserTabActivity class that gets pulled in:
    <activity android:name="com.microsoft.identity.client.BrowserTabActivity" android:exported="true" />

However adding the first snippet to the manifest causes a build crash on Xamarin because the elements aren't properly merged:
[....]\Xamarin\Android\Xamarin.Android.Common.targets(2789,3): error : jav a.lang.IllegalArgumentException: already added :  Lcom/microsoft/identity/client/BrowserTabActivity

I don't think there's an easy workaround for this issue currently. Proper workarounds need to fix the manifest as part of the build process.

Hi @Jjagg, thanks for letting us know! We'll get back again about this.


protocol: send port as int for better handling

Having port as integer let us handle port related actions in a more safe
way.
Fixes #3

/cc @cihangir


No 'watch my sass'-button

Hello,
I tried installing the Live Sass Compiler 5.0.1 but there's no 'watch my sass'-button.
After "ctrl+shift+P : Live Sass: Watch Sass" I get the following message:

Uninstalling/disabling does nothing. Can you help me?

Don't know how but it suddenly works.


[stable/selenium] - Adding the option to set nodePort on the service

Signed-off-by: Elad Kirmayer<EMAIL_ADDRESS>What this PR does / why we need it:
This pull request is for allowing to select the nodePort on which the selenium-hub will be exposed with
This will make it simpler when deploying without the need to add queries to get the exposed port number. needed
Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

/assign @paulczar

/ok-to-test

Lgtm

lgtm

/lgtm

Thanks for your work on this @ekirmayer and @diemol and @flah00 for reviewing. After this is merged, you will be able to review/approve PRs for this chart.


Not able to achieve the live-Reload

I am using following main.go file:

import (
	"encoding/json"
	"github.com/gorilla/mux"
	"log"
	"net/http"
)

// Response is just a very basic example.
type Response struct {
	Status string `json:"status,omitempty"`
}

// GetStatus returns always the same response.
func GetStatus(w http.ResponseWriter, _ *http.Request) {
	b := Response{Status: "helo arshpreet singh khangra"}
	json.NewEncoder(w).Encode(b)
}

func main() {
	router := mux.NewRouter()
	router.HandleFunc("/status", GetStatus).Methods("GET")
	log.Fatal(http.ListenAndServe(":8123", router))
}

and I am running service like this:
docker run -it -u ${UID} -p 8123:812-v "$(pwd)/.cache/pkg:/go/pkg" -v "$(pwd):/go/src/app" zephinzer/golang-dev:latest start;
But each time I do: curl http://localhost:8123/status
I don't get live changes, instead I have to stop and re-run this "docker run -it -u ${UID} -p 8123:812-v "$(pwd)/.cache/pkg:/go/pkg" -v "$(pwd):/go/src/app" zephinzer/golang-dev:latest start;" in te same terminal.

Could it be because of "inotify" inside docker container?

@arshpreetsingh I'm also running into this problem, and I just tried downloading the latest version of the docker image that you pushed up a couple hours ago.
I am editing my files on my Mac, and when I exec into the container, I can see that the files have updated inside the container, but the live reload never occurs.

@duro I just did the latest Pull and and did  make build . again and Bingo!! I am able to achieve Hot Reloading!! @zephinzer Seems like time to close the I will also Test this on Mac Mozave Tomorrow and let you know!

@arshpreetsingh any updates? #15 fixes the live reload on windows, could you see if that works for you?

@zephinzer things are working fine for me now, on Ubuntu as well as on Mac. Please close the issue, Although I tried your Image inside docker-compose file where Reloading not happening yet.
Here is my Docker Compose file:
version: '3'
services:
  timescale:
    image: timescale/timescaledb
    environment:
      POSTGRES_DB: dev
      POSTGRES_USER: test
      POSTGRES_PASSWORD: password
      TIMESCALEDB_TELEMETRY: 'off'
    ports:
      - 5437:5432
  app:
    build: .
    command: start
    volumes:
      - .:/usr/local/go/src/app
    environment:
      - DB_CONNECTION=pgsql
      - DB_HOST=postgresql
      - DB_PORT=5432
      - DB_DATABASE=test
      - DB_USERNAME=test
    ports:
      - "80:8080"
    depends_on:
      - timescale
    links:
      - timescale

# docker run -d --name timescaledb -p 54320:5432 -e POSTGRES_PASSWORD=password timescale/timescaledb:latest-pg11

#postgresql://hola:hola@postgres/holadb

#postgresql://hola:hola@hola_postgres_1/holadb

Thanks @arshpreetsingh, I’ve released a binary version too, you can try that to see if it resolves the issue more gracefully-


admin: reimplement runtime and stats handlers without rapidjson

This patch reimplements runtime and stats (format=json) handler without rapidjson.
Risk Level: Low
Testing: unit test
Docs Changes: N/A
Release Notes: N/A
Signed-off-by: Dhi Aurrahman<EMAIL_ADDRESS>

/azp run envoy-macos

@envoyproxy/senior-maintainers

I think with the completion of this PR the only thing still using it is the Zipkin tracer - https://github.com/envoyproxy/envoy/search?q=rapidjson&unscoped_q=rapidjson

Yes. I have a PR in flight for that. Will clean it up soon.


Call RecordNotFound() when value isn't of right type

When I'm trying to getting by id like this:
db.First(&user, id).RecordNotFound()
and id isn't an integer and the record is not found, it doesn't call RecordNotFound().
I'd expect that RecordNotFound() was called since the record is not found. I think it's because of the value isn't of the right type.

Hello @milanvanschaik
Based on the implementation, it shouldn't works like this. it should works for all cases that can't find a struct.
Could you give me sample code that could explain your issue?
Thank you.
package main

import (
    _ "github.com/go-sql-driver/mysql"
    "github.com/jinzhu/gorm"
    _ "github.com/lib/pq"
    _ "github.com/mattn/go-sqlite3"
)

var db gorm.DB

func init() {
    var err error
    db, err = gorm.Open("sqlite3", "test.db")
    // db, err := gorm.Open("postgres", "user=username dbname=password sslmode=disable")
    // db, err := gorm.Open("mysql", "user:password@/dbname?charset=utf8&parseTime=True")
    if err != nil {
        panic(err)
    }
    db.LogMode(true)
}

func main() {
    // Your code
}

Hello @milanvanschaik
Does this issue still happen to you, if it does, feel free to reopen it
Thank you.


Remove Parameterless Constructors

@EliuX Out of curiosity, why do you have private constructors?
If they are required, the the compiler will create public parameterless constructors for you.
Please take a look at:

https://github.com/TwilioDevEd/task-router-servlets/blob/b5f9cc37e05ce95a1798c7ef49669f5154865f50/src/main/java/com/twilio/taskrouter/domain/model/MissedCall.java#L30-L31
https://github.com/TwilioDevEd/task-router-servlets/blob/master/src/main/java/com/twilio/taskrouter/domain/model/PhoneNumber.java#L21-L22

The default private constructor is because:

We need a default constructor for all JPA entities
We don't want the coder to create the JPA entity without specifying the required parameters. Therefore we need a second public constructor with all required params

Here is a good explanation about it.

Thanks @EliuX, this is a really good explanation about why we must have a parameterless (no-arg) constructor. The link you provided is really useful.
My original question was:

Out of curiosity, why do you have private constructors?

The private constructors are not used at all. Keep in mind the private constructor is not accessible outside the scope of the class.
MissedCall and PhoneNumber are working because if you don't define a explicitly a constructor for a class, a default public parameterless constructor is automatically created by the compiler. This constructor satisfies the requirement "The no-arg constructor must be public or protected".
Would you mind removing the unused code please? Unless you have a strong reason to keep it that way.

What i ment to say is that it needs a default constructor. If i have another one, the default one wont be implied, so it needs to be declared. After pairing a bit with @mcelicalderon we decided to make it public to be more JPA compliant, but its needed, i tried otherwise and didn't worked.

Yes, if you create a constructor with parameter you do need to create the default parameterless constructor. But it needs to be public or package-private (as protected), not just private as it was

Thanks guys!


[🐞] Using Material UI icons causes blank rendering in production

Which component is affected?
Qwik Rollup / Vite plugin
Describe the bug
We're in the process of testing Qwik end-to-end to start our migration from Next to Qwik.
Our next step is to deploy the project on our own servers (node deployment).
We followed the instructions from the docs for Express.
This is the picture we have for npm run dev:

But this is the picture we get when we deploy and run node server/entry.express.js:

Based on this message:

The JSX import source cannot be set without also enabling React's "automatic" JSX transform

that is related to the Icons.jsx file, it's related to the MUI icons.
Reproduction
https://github.com/Nefcanto/QwikBuildSuppressesSsr
Steps to reproduce

git clone https://github.com/Nefcanto/QwikBuildSuppressesSsr
cd QwikBuildSuppressesSsr
npm install
npm run dev
Project should work and show the whole page
npm run build
node server/entry.express.js
Project only shows a small header and the rest of the page is empty

System Info
System:
    OS: Linux 5.15 Debian GNU/Linux 11 (bullseye) 11 (bullseye)
    CPU: (4) x64 Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz
    Memory: 9.50 GB / 15.37 GB
    Container: Yes
    Shell: 5.1.4 - /bin/bash
  Binaries:
    Node: 18.12.1 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 9.2.0 - /usr/local/bin/npm
  npmPackages:
    @builder.io/partytown: ^0.7.0 => 0.7.3
    @builder.io/qwik: ^0.16.1 => 0.16.1
    @builder.io/qwik-city: ^0.0.128 => 0.0.128
    @builder.io/qwik-react: ^0.2.1 => 0.2.1
    vite: ^4.0.3 => 4.0.3

Additional Information
No response

Bump, getting the same problem when deploying to Netlify:

It is also coming from the /** @jsxImportSource react */

@Nefcanto is it still a valid issue?

@gioboa, we do not use Material UI icons anymore for this reason. We're using Google Symbols and import them as SVG. So, I have no idea if this is still the case or not. You can close it for now. Thank you.


(Strong) Dynamic-as-bottom + Map.fromIterable broken

This is now a warning in the latest dev released of the SDK:
class Foo {
  String bar;
}

void doThing(Iterable<Foo> foos) {
  new Map<Foo, String>.fromIterable(foos, value: (Foo foo) => foo.bar);
}

This is a hint, soon to be an error, because the definition dynamic -> String is expected.

My workaround is
value: (/* Dynamic as bottom */ foo) => (foo as Foo).bar

Duplicate of #26392.


Roadmap to a v3.0.0 of flow-typed

Roadmap to a v3.0.0 of flow-typed
I recently took the time to read through the opened issues and as others have already mentioned I also do think that there is room for improvement in how flow-typed works. A few opened issues already  address various topics which, in my eyes, would lead to breaking changes and therefore to a new major release (following the semantic release versioning) and currently hinder the flow community as a whole to progress to a matured state (in my eyes).
As far as I can see there are no specific plans, at least on GitHub issues, which are dedicated to a release plan or how flow-typed will progress in the longer run. This is why I created this issue.
I would like and could contribute a few weeks of my freelance time to this project in the upcoming three months, but before starting and risking to throw away time and code, it would make sense to agree on a certain set of problems that we want to solve and maybe even to agree on a schedule for this (major) release.
Serving type definitions via npm
While taking a look through the opened issues, I faced that most of them are in regards or at least related to the current implementation of having all definitions inside the repository of flow-typed itself, e.g.

Publish libraries as npm packages? #990
Committing libdef files to source control #413
[Discussion] What can we learn from DefinitelyTyped? #395
... and in-directly Dependencies between library definitions? #16

Both issues stopped at one certain problem, the version pinning between ...

... the type definition itself since it could contain bugfixes.
... the library of the type definition.
... the verion of flow that the type definition supports.

To solve this, I would propose to adapt the proposal of @EdwardDrapkin in his comment on #990.
How do we handle the versioning of the typing and the associated library?
First and foremost we should use existing functionalities as much as possible, e.g. the peerDependencies feature of npm/yarn. This way we can specify supported version(-range)s with almost no effort! Secondly I would propose that type definitions will follow a strict semver versioning out of the box.
Let's use an imaginary typing package, e.g. @flowtyped/axios, by the time of writing this the axios library is currently published as version 0.17.0. The first two numbers, namely the major and minor version, should always match the version of the targeted library version that the typing supports...
What about bug fixes to the typing?
... the patch version whatsoever can be used independently to release bugfixes of the typing itself, so a case such as the following will be completely valid since the API of axios is still the same and only a bugfix of the typing was published.

MAJOR
MINOR
PATCH

Version of the library
0
17
1

Version of the typing
0
17
12

Another beneficial result of this would be that users would get automatic updates/fixes in case they prepend the caret (^) to their typing versions within the package.json.
What about the supported flow version of the typing?
Again I would propose to use the peerDependency feature to specify a supported semver range of flow-bin.
But of course this would not allow serving types for multiple versions of flow in the same typing release. To allow this, I would follow @thejameskyle propose in #990 to introduce a mapping within the package.json to do this with a few adaptions, e.g.
{
    "name": "@flowtyped/axios",
    "flow-typed": {
        "types": {
            "byFlowVersion": {
                "v0.28.x-v0.30.x": "flow_v0.28.x-v0.30.x.js",
                "v0.30.x-v0.38.x": "flow_v0.30.x-v0.38.x.js",
                "latest": "flow_latest.js"
            }
        }
    }
}

You see that the property itself is named flow-typed and not flow, I think this is a bit safer since otherwise it could conflict in the future if flow itself would be configured in the package.json. I would also add a more generic latest key which should always be present, more on this later on.
What about packages that do not follow strict semver versioning?
Introducing a boolean property in the package.json configuration of the typing could solve this, e.g.
{
    "name": "@flowtyped/axios",
    "flow-typed": {
        "types": {
            "isIndependentlyVersioned": true,
            "byFlowVersion": {
                "v0.28.x-v0.30.x": "flow_v0.28.x-v0.30.x.js",
                "v0.30.x-v0.38.x": "flow_v0.30.x-v0.38.x.js",
                "latest": "flow_latest.js"
            }
        }
    }
}

Changes to the CLI
Installing new typings via flow-typed install
Since typings would be served via npm, the flow-typed install command would need to be reworked from the ground up. Step-by-step it would ...

... parse the projects package.json for dependencies as it does currently.
... filter out dependencies for which types where already installed.
... query the NPM registry via the HTTP API for matching types packages.
... prompt the developer if he would like to install the package into the devDependencies.
... execute a npm install or yarn add in the background. (This is also something that we would need to make configurable)

But how should flow resolve the types within node_modules automatically? I think there are two options, either each typing package has it's own postinstalland preuninstall script which would copy the files into the ${process.cwd()}/flow-typed/npm folder or we solve this issue in a central place with a new CLI command...
Symlinking/copying the installed types into flow-typed/npm with flow-typed create-symlinks
This command would ...

... do a grep through all package.json files in the node_modules folder of the project for package.json files with a "flow-typed" section defined.
... read the pkg["flow-typed"].types configuration.
... resolves the typing that matches the projects flow-bin version.
... if no match was found, it prompts the user to use the pkg["flow-typed"].types.latest version with a warning.
... if the user wants to use the latest, a flow-typed.lock file will be created with information for the next run (especially to avoid prompts on CI).
... and symlinks the file into the projects flow-typed/npm folder.

This way, the following issues would also be solved since the create-symlinks will also respect flow-typed configurations in library packages and not only typings in the @flowtype scope:

[Ecosystem] Vendoring in libraries? #286
What is the preferred way for a module to provide its own libdef? #1451

So you see the flow-typed install command would only be executed upon installing new packages and the flow-typed create-symlinks command would be run upon setting up a project or during CI / CD.

Migrating the old type definitions into separate repositories
Of course this would totally conflict with the current setup, hence a new major release would need to be published, but I think it's not a huge task to create a migration script which will automatically transform the existing type definitions into their own repositories while keeping their git histories using the git filter-branch command. Not huge because the existing definitions follow a strict convention in regards to their structure and tests.
The only question I have is, if the definitions should be moved into separate git repositories under the flow-typed organization or if we create a new mono-repository namely flow-typed-definitions in which all definitions could be placed.
I wouldn't like to keep the current structure where the CLI is in the same repository as the definitions since this causes way more noise and it makes separating CLI and definition pull requests harder, so I guess a separate mono-repository or even single repositories for each definition would make more sense.
Moving all definitions into a mono-repository

PRO: Easier to contribute new definitions to the @flowtyped npm scope and GitHub organization.
PRO: Easier to keep the tooling in sync

Moving definitions into single responsibility repositories

PRO: Easier to integrate automatic release management via semantic-release and commitizen
PRO: Easier to manage issues
PRO: Tests / CI would run extremely fast (Running def tests is unnecessarily slow #414)
PRO: Definition authors could be given PR merge rights on their definition repositories which would make review processes a bit faster
PRO: Additional tooling / tests could be added more easily [tests] Idea: Use a runtime test library for tests #100

IMO moving them into single responsibility repositories would be more beneficial, but I really don't know how new definitions would be handled, initially authors could just create their own definition repositories on their own and transfer them into the @flowtype after a review process or something along the lines, but that is definitely out of my scope.
The tooling won't be a problem as far as I can see since it could be abstracted into it's separate CLI, so up to our next point! :-)

Creating a flow-typed-definition CLI
So in the process of creating the migration script for definitions, most of the logic could be easily abstracted into a flow-typed-definition CLI, similar to create-react-app it could be a central point to create new definition repositories with ease and therefore solve [CONTRIB] Make it easier to work on libdefs #146.
This CLI could also hold commands for definition repository maintainers, e.g. the test script that we currently hold within flow-typed itself (run_def_tests.sh) and more...

Fin.
All of these proposals on how things could work should be seen as a basis for discussions, not as carved in stone and perfectly thought out.
I did not intend to undermine the already existing issues, but to have a central place for discussions and to take a look at them from a greater perspective. While I know that this is a pretty big proposal / change, I do think that the flow community would really appreciate it if we would solve these bigger pain-points/issues sooner than later, which of course should not mean that we should push everything out in a quick-shot move.
Let's take the time to discuss everything and try to find a format for a good flow-typed configuration within the project / within type packages that will be extendable in the longer run! :-) :heart:
/cc @DullReferenceException @TrySound @marudor @jeffmo @thejameskyle @EdwardDrapkin @bengotow @gtrufitt @lydell @samwgoldman @ryyppy @zertosh @callumlocke @GAntoine @doberkofler

Oh man, it's like you read my mind, I had just started writing up a list this weekend. I think you many of the current pain points that need to be addressed. There are a few more things I'd like to add as (stretch) goals to a 3.0 launch, so once I give this a  good read I'll edit this comment.
/cc @jedwards1211 @calebmer @A-Tokyo @pascalduez @mwalkerwells

To be honest, currently I lack the time to help a lot.
I'm mainly checking if I need to do a new release as I'm one of the few who can actually release a new version on NPM.
I trust @GAntoine to do reasonable decisions.

I think this https://github.com/flowtype/flow-typed/issues/1471 should be on 3.0

@sibelius question is how far we could automate this for existing type-defs.
I guess it is more of an manual task, but I guess we could prepare at least a markdown file automatically by parsing the type-def and prepare a common structured README.md?

It could be done after the release

@Inkdpixels you must not have seen my PR (#1435) to allow packages to optionally provide their own definitions for flow-typed, instead of storing them in this central repository, so that even private packages can have definitions for multiple versions of flow.  Check it out.

@jedwards1211 That's super cool! 🎉  And you are right, I haven't seen this PR until now!
And of course both self-provided and community-type-defs should be supported. Moving the existing community-type-defs of flow-typed into npm packages will not conflict with this at all - It just reduces the logic flow-typed would need to handle since we could just use existing solutions via npm/yarn that way. :-)
It's all about keeping things simple, otherwise we would end up handling two logical branches on how flow-typed install does it's thing, opting for the npm-only approach would simplify things for the user and for ourselves a lot IMO.

Npm only would simplify things for the user and you guys, but it would make things harder for package maintainers.  I can understand if some package maintainers don't want to spend time dealing with flow types, even if it just means accepting PRs for flow type updates.

I think flow should download typings for all project dependencies itself. Without flow-typed update/install or typings in package.json. I don't want save typings in package.json as in ts.

It is great to see some movement in this area. I really like using flow but the handling of type definitions is lagging quite a bit compared to the TypeScript type definitions.
On the long term I would love to see the management of the type definitions as part of flow itself as suggested by @XaveScor. From a "user perspective", the type definitions should just be part of the actual dependencies and in a perfect world, I would like to add a new dependency and automa(gi)cally also have the corresponding type definitions available in flow. Each npm package would contain it's versioned type definitions, they will be installed together with all other assets and flow just knows how to access and use them.
To get there, the proposal of @Inkdpixels would be a big step forward, using npm could simplify the CLI alot and having the definitions properly described in my package.json file would already be a great improvement.
I personally would probably move the definitions into separate single responsibility repositories.

Hey @jedwards1211,  thanks for your comment!

it would make things harder for package maintainers

I guess there is some misunderstanding going on, as stated, this proposal or having flow-typed type-defs in npm packages do not conflict with your comments at all! 😄
Let's again use the axios type-defs as an example, they are maintained by the community and are part of the flow-typed repository right now. What the proposal suggests is that this typing will be moved into a separate repository under the flow-typed GitHub organization as well as the NPM scope @flowtyped. It will still be maintained by the community and is still part of flow-typed, the package author of axios itself does not, as long as he wishes to do so, need to accept PR's to his repository.
Once the package author changes his mind, he can simply move the community type-defs into the library package and everything will be fine, as your referenced PR also does.
Maybe I am missing something, but as far as I can see, there are no drawbacks for anyone, neither us as the maintainers of flow-typed, authors of community type-defs or package maintainers itself. Would you agree or is there some drawback that I am currently missing?

What the proposal suggests is that this typing will be moved into a separate repository under the flow-typed GitHub organization as well as the NPM scope @flowtyped.

A key point here is that it does not technically need to be moved in its own repo; all definitions could live under the same project very easily, like DT does it.

@Inkdpixels oh I see.
Now that I read your proposal a bit more carefully, I think relying on the same major/minor version in the defs package is risky.  For instance, I'm working on type defs for sequelized right now, and since sequelized is very dynamic, there are multiple potential ways one could design the typedefs falling on a spectrum of tradeoffs between simplicity and precision (if you want concrete examples of what I mean I could PM you).  For a library like this, it's possible people would decide to completely redesign the type defs, causing a breaking change in the type defs themselves.
Considering that, I think it would be best to have folders inside @flowtyped/sequelize that mix and match versions of flow and sequelize (same folder structure that definitions/npm has in this repo) so that breaking changes to the types can be released.  Also there wouldn't need to be any special magic in the package.json.

@GAntoine Most definitely, both are options with benefits and drawbacks which we should outweigh against each other - I just tried to keep the comment simple, since both options (mono vs single-repos) where already outlined in my initial post :)
@jedwards1211 You are absolutely right, especially after me seeing your PR I do find "keeping the directory structure to resolve the type-defs" as the way to go. My initial thought with the configuration/file-path-pointers was to not restrict people to a certain directory structure, but I guess this is one of those cases where a restriction is better for everybody since it will be immediately clear where type-defs are located! 👍

Alright, I went ahead and created a github project for the V3 release. Issues and PRs which have the release tag or are located in the 3.0.0 Project should be discusses as to their inclusion in the next release. I'll list them out for ease of reading.
If you feel as if there are other issues which should be addresses for the V3 release, please comment below. There are a small number of proposed enhancements to the CLI which haven't been added, as it may drastically change with this release.

[ ] Serving type definitions via NPM (#990, #1494)
[ ] Migrating the old type definitions into separate repositories (#1494)
[ ] Install versioned definitions supplied by library authors (#1435, #1494)
[ ] Allowing for .md files in a definition's folder, which provides examples and usage information for that library's types (#1471)
[ ] Maintain a CHANGELOG.md file for the CLI (#1468)
[ ] Improve CONTRIBUTING.md, or better yet move it into the Wiki (#1458)
[ ] Fix prettier modifying typedefs and breaking tests after committing (#1187)
[ ] Merge and officialize the flow-typed browsers (#1122, #848)
[ ] Prepend // @flow to all definition and test files, for eslint compatibility (#929)

If you'd like to discuss any of the changes, including but not limited to purpose, proposed execution, work distribution/assignment or edge-cases, please comment directly on the related issue(s).

I think we also should support flow libdefs for non-npm packages, like @zertosh said in #16 (comment) and addresses things like discussed in facebook-atom/atom-ide-ui#95 🙂

@Inkdpixels @GAntoine I think we also should support flow libdefs for non-npm packages, like @zertosh said in #16 (comment) and addresses things like discussed in facebook-atom/atom-ide-ui#95 🙂

I like the direction v3 is headed.
+1 for a monorepo with lerna or yarn workspaces
I'm concerned though about keeping up the quality of libdefs (especially published via a possibly private npm package). Could we still run tests against different versions of flow?

Adding support for pre-releases, like discussed in #392 would also be something to consider for v3.0 I think?

If it's not too late, I want to make sure that being able for libdefs to declare dependencies on other libdefs isn't lost in the v3 work; we've got a bunch of express packages' libdefs that I can't PR because they require definitions like express$Request to be useful, and there's no way for me to make the tests pass as-is.  I'm working on getting as many of our Flow libdefs merged as possible, but I fear that if I PR a bunch of express middleware that's bailing on callback types, they'll be less than useful, let alone how useless a more tightly coupled ecosystem (feathers, specifically in my case) would be if expressed as Function and Object.

I have a similar issue with trying to type the various ProseMirror packages, as many of them depend on each other.

Has the idea been discussed of "simply" adding a types property to package.json that points to a directory containing types, and then having flowtype know to (recursively) look that up?

I don't know but I think flowTypes would be wiser, for the sake of avoiding conflicts (personally I think it's not very appropriate for tools to hijack package.json for configuration anyway),

While I agree the npm team seems fine with it, nyc and babel both use it.
On Dec 21, 2017 8:39 PM, "Andy Edwards"<EMAIL_ADDRESS>wrote:

I don't know but I think flowTypes would be wiser, for the sake of
avoiding conflicts (personally I think it's not very appropriate for tools
to hijack package.json for configuration anyway),
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/flowtype/flow-typed/issues/1494#issuecomment-353520446,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUb2XV6K5uJqxYgt7s5lBWphBWByOCnks5tCzJ6gaJpZM4QWGpL
.

Definitely true for nyc, though I don't think babel really encourages it over .babelrc.
And actually I think using the name of the package for configuration root is the most robust convention, so "flow-typed": {...} in the package.json for this package

I would definitely be into that. My follow up question is "Should
flow-typed also taken on the role of library type generation?" I know flow
cli has a tool for this but I had trouble getting it to work.
On Dec 22, 2017 8:06 AM, "Andy Edwards"<EMAIL_ADDRESS>wrote:

Definitely true for nyc, though I don't think babel really encourages it
over .babelrc.
And actually I think using the name of the package for configuration root
is the most robust convention, so "flow-typed": {...} in the package.json
for this package
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/flowtype/flow-typed/issues/1494#issuecomment-353627102,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUb2blWpqszNoBSSCvWkpbBYdjj4X9_ks5tC9NvgaJpZM4QWGpL
.

Good question, yeah I've had trouble with flow gen-flow-files or whatever it's called.
It wouldn't have to live in flow-typed itself, a tool to generate flow type defs could easily exist on its own.  It would probably make sense to have a babel-based tool to generate libdef files, rather than having flow do it itself.

I agree absolutely. If anyone wants to pair with me on that, HMU.

As of generation of flow definitions: there is also flowgen, which can convert from TypeScript to Flow. It is not ideal, but can serve as starting point. Join discussion in this issue https://github.com/joarwilk/flowgen/issues/29

@revyh you have a good point, I agree that flow itself should support this.
One of the things that came out of our earlier discussion is putting self-provided type defs in a flow-typed folder within a package is problematic, because during development that folder contains defs for a bunch of other packages installed by flow-typed.  So it needs to be a different folder name (which is why I chose flow-self-typed).

@jedwards1211 glad to hear, that you agree. And you right, I forgot that flow-typed is already reserved for another purpose. I just tried to find better name. However I'm ok with flow-self-typed. Anyway, it's bit early for naming now :smile:

@revyh I think the main reason I proposed supporting self-provided defs via flow-typed is I don't really want to spend the time learning enough OCaml to make a PR to flow itself...

I maintain a large ecosystem (130~) of libraries that all heavily rely on flow and other packages that have flow. I can't possibly manage pull requests for all of these over time.
Right now I'm basically flying blind: Everything is any'd.
Whatever it takes to make flow definition sharing easier I'm in, but I have to have this be easier.

@krainboltgreene I'm not following your complaint, please be more specific about what has to be easier.

I really like flow and therefore also very much depend on the quality of the flow-typed ecosystem.
When comparing with typescript the availability and quality of type definitions for flow is still quite limited and I’m currently evaluating a move to typescript just because of the type definitions.
Over time, I’ve contributed several type definitions and also made some improvements in the cli itself but the process of contributing is even more combersome then using them.
The proposals in this issue look quite promising but I was wondering, if there is any timetable or actual progress?

The CLI tool needs a complete rewrite pretty badly.  The code is, no offense to anyone, a complete disaster that's nearly impossible to decipher, particularly the runTests command which is full of 100+ line functions that stack await call after await call such that it's impossible to follow the execution context of the CLI utility.  There's probably been five/ten times I've wanted to change something in the CLI and just flat gave up because it's not worth the trouble to decipher god modules' god functions' just async-await stacks.  I actually have linked junior developers to runTests.js to demonstrate why async-await isn't the full solution to writing readable async code! This is so oblique that you're chasing contributors away.
Sorry for the rant, it's been building for months.  I'll volunteer 6-10 hours a week to a CLI rewrite if that's what it takes.

I think we need to add more contributors to make this repo move faster

@GAntoine I’m not sure if the CLI is the biggest problem and I’m also not sure that the result has to be “perfect” the first time. I really believe, that the availability and quality of the definitions is the key problem. A better CLI would definitively help, by improving the process of submitting PR’s for the definitions but from a client perspective I only really miss a proper “outdated” functionality.
At least me, it is quite unclear if I can “effort” to keep waiting for this project to mature and a roadmap with timings would really help.

@doberkofler 3 versions is super few. I have projects where we don't updated Flow 2-3 months. I think we need define outdated flow version. For example, flow versions over half a year is outdated. If we decide it we can drop support of 0.0.0-0.53.0 versions. Most of run-tests code if compatibility with <= 0.53.

@XaveScor

improving the process of submitting PR’s for the definitions but from a client perspective I only really miss a proper “outdated” functionality

The new/improved tool would allow for simpler library creation and submission. And by moving them to NPM packages, we get library deprecation basically for free.
@EdwardDrapkin
No need to apologize, we didn't write it. 😅 In fact, none of us who maintain it were part of the initial build of the CLI. And yeah, it is an absolute mess.

@doberkofler

At least for me the latest 3 versions would be all I really need and would support.

This is not realistic. We manage about 100+ packages at my work. It's super difficult to use and share typed source code across different versions of flow. Thus, when we upgrade...we have to upgrade everything. And since this is a huge task logistically and politically we're still on v0.53.1.
As I've mentioned in the past, the flow-typed CLI could help with this by providing someway to resolve different libdefs for different versions of flow for private packages.
In any case, private or not, expecting people to be to have an up-to-date flow version is just not reasonable.
That being said, I agree with @XaveScor that we could drop support for <0.53.x since there was such an overhaul.

@AndrewSouthpaw: I have 124 libraries that I maintain. They all have 100% type annotation. They are all intertwined (seriously the graph is wild). I want to use these libraries and have the type analysis.
As I understand it currently if I want flow-typed to "install" these type annotations I have to create a pull request that adds 124 libraries worth of type annotations that I have to write by hand. Then when any of those 124 type annotations changes I have to add between 1..124 new files via pull request. Lets ignore for a moment that my choices are either a single huge PR or 124 PRs and that I have to wait for someone to review that PR.
If I don't do any of this (the easiest path) flow-typed will just create stubs.

@krainboltgreene hard question. I think you can create index.flow.js in your packages. If you leave from your projects community can create package in flow-typed repo. I think official typings should store in source repo.

@krainboltgreene You could also just create your own type annotations locally, define the library in your .flowconfig, and maintain it locally. No need to go through flow-typed and deal with PRs. We don't get the benefit of your work, but that's your call of whether it's worth your time.
If your libraries have Flow annotations already, though, I would expect them to work as-is for type analysis. Do they not?

Not as I understand it. I welcome critique on my setup to fix this as I
want people who use my work to have type safety. See:
https://github.com/unctionjs
On Fri, May 25, 2018, 8:07 PM Andrew Smith<EMAIL_ADDRESS>wrote:

@krainboltgreene https://github.com/krainboltgreene You could also just
create your own type annotations locally, define the library in your
.flowconfig, and maintain it locally. No need to go through flow-typed
and deal with PRs. We don't get the benefit of your work, but that's your
call of whether it's worth your time.
If your libraries have Flow annotations already, though, I would expect
them to work as-is for type analysis. Do they not?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flowtype/flow-typed/issues/1494#issuecomment-392231511,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUb2QwUnuuw8ClhSnYk0u4fgkZjRoJnks5t2Mb7gaJpZM4QWGpL
.

Hm, bummer. Well, that's a limitation with flow, and not in our hands unfortunately.

@EdwardDrapkin I think your experience with async/await call stacks has been biased by running fully transpiled code (as the cli in this project does) rather than using babel-preset-env to employ native async/await in versions of node that support it and can give better stack traces than code using promises or whatever async control structures could ever hope to.  As this article explains V8 is able to pause the execution context of untranspiled async functions, keeping their stack around, hence it is actually able to build sane stack traces for them, whereas a function that sets up a promise or callback chain returns synchronously, so the execution context of that function disappears before any callback execution and can't become part of a stack trace.
I would recommend reconfiguring the development scripts in this project to run the CLI with babel-preset-env during development, and only fully transpile in the build for release, so that you get the full benefits of V8 support for async/await stack traces when doing development.  I think you'll be surprised how nice the development experience becomes.

The last comment here is May 2018, but now is March 2019. Is there any good news for serving types from npm? Looking forward to it so much.

@zhaoyao91 I gave up waiting and migrated to TypeScript. The quality and availability of the type definitions is just amazing.

Have to say we did the same thing here.  There's some headaches in the migrations, but the quality of tooling is definitely a huge leap forward.

Here is the current plan: https://github.com/flow-typed/flow-typed/issues/3083


scripts aren't working with $.gettext, only with the useGettext hook

Issue: after running vue-gettext-extract, the expected pot and po files are created, but they have not the translation strings when using $.gettext in templates. It works when using the useGettext hook tho.
This works:

<template>
  {{ $gettext('Some text...') }}
</template>

but this doesn't:
<template>
  {{ $.gettext('Some text...') }}
</template>

Details:
"vue": "3.2.33",
"vue3-gettext": "2.2.3"
App setup
import { createGettext } from 'vue3-gettext';
import translations from './i18n/translations.json';

const gettext = createGettext({
  availableLanguages: {
    en: 'English',
    es: 'Spanish',
  },
  defaultLanguage: 'en',
  translations: translations,
});

const app = createApp(App);
app.use(gettext);
app.mount('#app');

@nanoander I'm a bit confused, but here are some pointers:

You should be able to use {{ $gettext('text') }} in templates without any imports (use useGettext only if you need gettext in your script block). I'm not sure where you got $.gettext('text') from, that won't/shouldn't work.
the extraction only works for functions with the exact names $gettext etc. (see extraction script).

At some point I may make the extract script customizable so you can define your own function names/tokens, but I can't promise anything atm.


Spec files in subdirs included in AOT compilation

OS?
Windows 10
Versions.
angular-cli: 1.0.0-beta.24
node: 6.9.1
os: win32 x64
@angular/common: 2.4.3
@angular/compiler: 2.4.3
@angular/core: 2.4.3
@angular/forms: 2.4.3
@angular/http: 2.4.3
@angular/platform-browser: 2.4.3
@angular/platform-browser-dynamic: 2.4.3
@angular/router: 3.4.3
@angular/compiler-cli: 2.4.3
Repro steps.

ng init a new app.
Create a subdir under src/app and cd into it
ng g c test-comp
Edit the test-comp.component.spec.ts file to include import { BrowserDynamicTestingModule } from '@angular/platform-browser-dynamic/testing'; (This is somewhat arbitrary - I just know this particular module breaks AOT.)
run ng build -prod --aot

You'll get an error (see the log).
Note that if you do this directly under src/app you won't get an error, because the spec file is correctly excluded from the AOT build.
I believe the culprit is here: https://github.com/angular/angular-cli/blob/defc26935cad730dbdfb23c88ca229cba34f481d/packages/%40ngtools/webpack/src/plugin.ts#L124
The single-star replacement looks like it's clobbering the previous double-star replacement so you go from **/*\.spec\.ts after line 120 to  (?:.*)/*\.spec\.ts after line 122 to (?:.(?:[^/]*))/(?:[^/]*)\.spec\.ts after line 124, when you probably actually want (?:.*)/(?:[^/]*)\.spec\.ts.
The log given by the failure.
ERROR in Error encountered resolving symbol values statically. Calling function 'NoOpAnimationDriver', function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol AnimationDriver.NOOP in C:/wsecug<EMAIL_ADDRESS>resolving symbol BrowserTestingModule in<EMAIL_ADDRESS>resolving symbol BrowserTestingModule in C:/wsecugit/n<EMAIL_ADDRESS>

@mattdistefano can you try reproduce it on updated angular-cli? now it is 1.0.0-beta.25.5

Ah man you guys are killing me - just spent the afternoon upgrading from beta 23 to beta 24.
But yeah I'll check.

dup of #3928

@antonybudianto7 It looks similar but this issue is specifically re. spec files in subdirectories. Also the errors we're seeing look different.

@mattdistefano I used @angular/router/testing module, that's why it's different, but the fact is our spec file still get compiled :smile:

Can confirm this is present in beta 25.5 too:
angular-cli: 1.0.0-beta.25.5
node: 6.9.1
os: win32 x64
@angular/common: 2.4.3
@angular/compiler: 2.4.3
@angular/core: 2.4.3
@angular/forms: 2.4.3
@angular/http: 2.4.3
@angular/platform-browser: 2.4.3
@angular/platform-browser-dynamic: 2.4.3
@angular/router: 3.4.3
@angular/compiler-cli: 2.4.3

I think I was with the same issue, and after update to beta 25 it disappears.

This is fixed at the moment but I know some older versions of the CLI were more lenient with the dependency versions.
Make sure to follow the instructions in https://github.com/angular/angular-cli#updating-angular-cli, especially the bits where you delete your local node_modules.

@filipesilva Are you saying this is fixed in beta 26?

@mattdistefano probably even before that, but there might have been some old version of @ngtools/webpack sticking around.

Gotcha. Alright, I'll try again.

Hi, have got the same problem, i.e. one of my tests (.component.spec.ts) has an import to BrowserDynamicTestingModule in order to set the entryComponents property, and keeps failing with the error message mentioned above.
The problem is still there with the current version (angular-cli: 1.0.0-beta.26).
angular-cli: 1.0.0-beta.26 node: 7.1.0 os: win32 x64 @angular/common: 2.4.3 @angular/compiler: 2.4.3 @angular/core: 2.4.3 @angular/forms: 2.4.3 @angular/http: 2.4.3 @angular/platform-browser: 2.4.3 @angular/platform-browser-dynamic: 2.4.3 @angular/router: 3.4.3 @angular/compiler-cli: 2.4.3 @angular/platform-server: 2.4.3 @angular/tsc-wrapped: 0.5.1

@filipesilva I just confirmed this issue is still present in beta 26. See https://github.com/mattdistefano/ng-cli-beta26-spec-issue

I think I might be running into this too. Things were working fine in beta.22-1 but upgrading to beta.26 started producing the exact error. It's still present with beta.30 and I haven't been able to figure out why test files are being loaded. Node_modules folder has been removed when upgrading each time.

I have updated to cli 1.0.0-beta.32.3 and having the same issue too.

Will investigate.

Followed your repro and got this error:
ERROR in Error encountered resolving symbol values statically. Calling function 'NoOpAnimationDriver', function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol AnimationDriver.NOOP in<EMAIL_ADDRESS>resolving symbol BrowserTestingModule in<EMAIL_ADDRESS>resolving symbol BrowserTestingModule in<EMAIL_ADDRESS>


AMBARI-26004: Support Ambari agent test case execution on Python3 environment

What changes were proposed in this pull request?
Dummy PR to test that python3 CI changes does not impact branch-2 CI
How was this patch tested?
(Please explain how this patch was tested. Ex: unit tests, manual tests)
(If this patch involves UI changes, please attach a screen-shot; otherwise, remove this)
Please review Ambari Contributing Guide before opening a pull request.

There is no impact on branch-2.7 CI


EPERM error when installing from ZIP file on Windows

Installing from the ZIP file on Windows machine always fails with the EPERM rename error.
After some debugging, I have found that the error happens when the ResolveCache tries to rename/move temporary directory where ZIP was extracted to the cache directory.
Edit: See this comment for more details.
System info:
Bower version: 1.3.1
Node version: 0.10.26
OS: Windows_NT 6.2.9200 x64

I've added Windows CI support for bower. I encourage you all to create failing test, so we can fix it.

I have a basic setup that triggers the bug in a blank project, the setup is like this:
src/
    bower.json
    .bowerrc

bower.json's contents are:
{
  "name": "prueba",
  "version": "0.0.0",
  "homepage": "",
  "authors": [
    "presentes"
  ],
  "moduleType": [
    "amd"
  ],
  "license": "GPL",
  "dependencies": {
    "jquery": "*",
    "modernizr":"*"
  }
}

and I had to add the .bowerrc due to being behind a corporate proxy:
{
    "registry": "http://bower.herokuapp.com"
}

Nevertheless I'm worry that is an artifact of being behind a corporate proxy.
Please give me assistance on how to further provide information.

This should be fixed in bower 1.6.2 thanks to https://github.com/bower/bower/commit/0bb1536c9972e13f3be06bea9a8619632966c664


Color Choices

Attached are 3 color palette choices. Please let me know if you like any of the options.
Option A
Option B
Option C

A or C for me, although I'm not really in love with any of them.

That’s totally fine. We can stick with the default Bulma colors if you guys all prefer. After seeing them on what we have I’m not against it.

What about A, but darken the blue a little more?


added my name

I added my name to the list

Great joining on PR for biginners

@suleimanbashiru  thanks for making your first contribution, I will be merging your Pull Request, also look at the issues so that you can get a chance to win a limited community Swag from me.
If you like the project and Repo please give it a star and Follow me on Github (would be appreciated)

On my Hacktoberfest profile am informed that this project is not recognized by Hacktoberfest


Full vendor patient list

Code includes "filter vendor patients by measure feature" for full functionality of the vendor patient list as can be found in the bundle master patient list. But also:
-remove returned calculation results that have no IPOP value
-fix static code replacement issue with CRSF token
Pull requests into Cypress require the following. Submitter and reviewer should :white_check_mark: when done. For items that are not-applicable, note it's not-applicable ("N/A") and :white_check_mark:.
Submitter:

[x] This pull request describes why these changes were made.
[x] Internal ticket for this PR: https://jira.mitre.org/browse/CYPRESS-408
[x] Internal ticket links to this PR
[x] Code diff has been done and been reviewed
[x] Tests are included and test edge cases
[ ] Tests have been run locally and pass

Reviewer 1:
Name:

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code

Reviewer 2:
Name:

[ ] Code is maintainable and reusable, reuses existing code and infrastructure where appropriate, and accomplishes the task’s purpose
[ ] The tests appropriately test the new code, including edge cases
[ ] You have tried to break the code

I get this error when loading a bunch of files that return an error message.
I believe its related to assemble_alert


Can't change states after destroying secondary angularjs app

This is a (check one box):

[x] Bug Report
[ ] Feature Request
[ ] General Query

My version of UI-Router is: 1.0.12
My version of AngularJs is: 1.6.7, 1.5.8
Bug Report
Current Behavior:
I have a project that leverages two angular applications (created with angular.bootstrap()) on the same page. They both use ui-router and work fine while they are alive (state transitions and all).
However, if I destroy one angular app ($rootScope.$destroy()), the routing on the other app stops working.
Expected Behavior:
The routing should still work properly on the other angular app, even after one dies.
Note: This was working fine on ui-router 0.4.2
Link to Plunker or stackblitz that reproduces the issue:
I built it on jsbin because I am a pleb: https://jsbin.com/sufamusice/1/edit?html,js,output
Mostly minimal repro:

A first angular app is running on the page, with multiple states ("Home" and "State 2")
Note that navigation between these works fine
Click "Open Sub App" to bootstrap the 2nd angular application
Note that navigation between states on both applications work fine.
Click on "Close Sub App" to tear down the 2nd angular application
Note that navigation no longer works on the main application

Just tried to update to ui-router 1.0 again and I'm still hitting this issue.
this line is probably what's overriding the services now.


can not log in. need help

can not log in. here is the full log file:
`C:\Users\Minhajul Islam\Downloads\cr-dl>]cd-dl login [options]<EMAIL_ADDRESS>[rushhour2]
']cd-dl' is not recognized as an internal or external command,
operable program or batch file.
C:\Users\Minhajul Islam\Downloads\cr-dl>cd-dl login [options]<EMAIL_ADDRESS>[rushhour2]
'cd-dl' is not recognized as an internal or external command,
operable program or batch file.
C:\Users\Minhajul Islam\Downloads\cr-dl>
C:\Users\Minhajul Islam\Downloads\cr-dl>cr-dl login [options]<EMAIL_ADDRESS>[*****ur2]
CaptchaError: captcha
at validateResponse (C:\snapshot\CR-dl\node_modules\cloudscraper\index.js:273:11)
at onCloudflareResponse (C:\snapshot\CR-dl\node_modules\cloudscraper\index.js:222:5)
at onRequestResponse (C:\snapshot\CR-dl\node_modules\cloudscraper\index.js:205:5)
at Request. (C:\snapshot\CR-dl\node_modules\cloudscraper\index.js:149:7)
at Object.onceWrapper (events.js:418:26)
at Request.emit (events.js:311:20)
at Request. (C:\snapshot\CR-dl\node_modules\request\request.js:1154:10)
at Request.emit (events.js:311:20)
at Gunzip. (C:\snapshot\CR-dl\node_modules\request\request.js:1076:12)
at Object.onceWrapper (events.js:417:28)
at Gunzip.emit (events.js:323:22)
at endReadableNT (_stream_readable.js:1204:12)
at processTicksAndRejections (internal/process/task_queues.js:84:21) {
name: 'CaptchaError',
message: 'captcha'
}
C:\Users\Minhajul Islam\Downloads\cr-dl>`
when I try to use cookies. I got this error:
`C:\Users\Minhajul Islam\Downloads\cr-dl>cr-dl --cookies cookie.txt
error: unknown option '--cookies'
C:\Users\Minhajul Islam\Downloads\cr-dl>`

I'm having mostly the same problem.
Anyway, @MinhajBoss, you're using the --cookies parameter in the wrong way. You should use "login" before, like this:
cr-dl login --cookies cookies.txt
However, even with that, I had no luck with it. I'm still getting the "CaptchaError" despite I've used correctly the "cookies.txt" extension on Firefox and even using the absolute path to the file.
What am I doing wrong? 🤷♂


Update knative/pkg from 0.13 to master

Fixes #
Proposed Changes

Release Note

Is it safe to point at master instead of a particular release?

@Cynocracy We can pin to master before a certain release cut, in order to catch all the updates in dependency. When the package release 0.14 for example, we will pin to that release branch to prepare our 0.14 release.

Thanks, that makes sense!
/lgtm


pyodide: use toJs for PyProxy objects; otherwise throw a ConversionError

see #3
the toJs method on PyProxy objects can convert some things that otherwise couldn't be passed automatically through postMessage.
For types that really can't be passed back, such as functions, I think that we should catch the error on the receiving side and optionally silently ignore them.

Just to say, tried this and works well

Cool, I'll merge it then.


Players can get out of Drowning with Camera Mode.

Describe the bug
If a player is drowning in water, by using the /cs command and putting their character over the water they can refill their air bar.
General Info
Mod Version: 1.0.7
Minecraft Version: 1.18.1
To Reproduce

Start drowning in survival mode
Use /cs to switch to spectator
Fly above the water into air
Use /cs to be taken back to your original location with full air

Expected behavior
You shouldn't be able to /cs if drowning, or it should retain your air bar when taken back.

@LunchBox951 I've added a condition to the rule cameraModeSurvivalRestrictions which doesn't allow players to enter spectator mode if they are submerged in water. This should stop people from being able to get out of drowning. You can download the new jar here: https://github.com/Super-Santa/EssentialAddons/releases/tag/1.0.7


More than one speed reader opens

Hi. When I have more than one Chrome window (not tabs) open and chose read current page, speed reader opens as many speed-reading windows as I already have normal windows open.
If I select some text and right click and chose read selected text with, it works as expected, i.e. one speed-reader opens.

Hi there DrZingo!
Thanks for reaching out. That doesn't sound right, sorry about that. I'll be sure to take care of that in the next update.
Best regards,
Nick

Update:
This seems to been related to the browser. Last night I updated the browser and now speed reader behaves as expected, one window.
It is a bit strange though, that this extension is called 3 different names: Speed reader, Readio and Champ
/DrZingo

That's great to hear. Probably a bug in the chrome extensions API. Regarding the naming, I'll have that taken care of as well. Thanks for letting me know!


Installation

Installation as proposed in the readme
$ git clone git@github.com:jedireza/drywall.git && cd ./drywall
$ npm install

does not work and could put off newcomers.
Please replace with
$ git clone https://github.com/jedireza/drywall.git && cd ./drywall
$ npm install

Thank you!

You may want to take a look at https://help.github.com/articles/which-remote-url-should-i-use/

When you git fetch, git pull, or git push to the remote repository using HTTPS, you'll be asked for your GitHub username and password.

Which is why I like the ssh route. Thanks for creating an issue. I'll keep this in mind in the future.

Thank you for the link!
Sure, if you have your ssh route set up for github its easier and the experienced of us will do it in this way.
For newcomers however the https route is easier, because it does not require username and password.


createCookieMiddleware can't be called more than once with a prefix

createCookieMiddleware prepends prefix on every call so in tests where we build up stores more than once REDUX_COOKIES_GET ends up being ${prefix}${prefix}${prefix}...REDUX_COOKIES_GET.

@modosc Thanks, I see that behavior when I add another createCookieMiddleware in the test.  Currently I can only make it accept prefix once, and it will ignore all other prefix.
For example, if you do
createCookieMiddleware(__cookie, 'aaa_')   // it will set the namespace to aaa_

createCookieMiddleware(__cookie, 'bbb_')  // it will ignore the 2nd prefix

https://github.com/iroy2000/redux-cookie/pull/4
Does it cover your case?  Or do you have any better idea on that and a PR ?


fix: onboarding code snippet caused test to fail

External Contributor Checklist

🚨 Please review the guidelines for contributing to this repository.

[ ] Make sure that all commits follow the conventional commit specification for the Mender project.

The majority of our contributions are fixes, which means your commit should have
the form below:
fix: <SHORT DESCRIPTION OF FIX>

<OPTIONAL LONGER DESCRIPTION>

Changelog: <USER-FRIENDLY-CHANGE-DESCRIPTION> or <None>
Ticket: <TICKET NUMBER> or <None>

[ ] Make sure that all commits are signed with git --signoff. Also note that the signoff author must match the author of the commit.

Description
Please describe your pull request.
Thank you!

Already fixed, this PR is not needed anymore


Scrapping and universal state management

Scrapping text using axios and cheerio. The information taken from perseus is saved in state variable using recoil and displayed on top of the screen.

All good and working


Polygons missing on Silkscreen rendering

Subject says it all.
IMHO does not impede usability, but might be confusing.

This is fixed in KiCad upstream. You need to get a nightly build or if you are on windows get patched bindings.

Custom shape pads and copper zone drawings in footprints are supported but you need patched version of KiCad python bindings. My patch was integrated in KiCad dev branch, if you install a recent nightly build custom pads and copper/silkscreen graphics will be rendered.

You can also get prebuilt patched bindings for windows x64 KiCad 5.0 here.


Updated Emission Profile and Working Temperature Render

Made several changes to the layout and to a few of the equations in emission_profile, added the script temperature_render to test the function, which currently works. The code is currently formatted as wanted, but @kyle8mcknight will make a few changes to the units once the main branch is up to date, so that it doesn't get more confusing.

Once you've done that, you'll probably need to git push -f origin main to ensure your fork gets updated correctly (-f forces the push).

Can you also post images of the plots this generates, so we can track progress easily?


Update Dockerfile to go 1.18 syntax

Description
This PR updates Mailhog Dockerfile to use a golang image with a specific version (1.18-alpine) to help keep things from breaking unexpectedly in the future. It also removes the deprecated go get <package> and replaces it with the equivalent go install <package>@latest.
When using this Dockerfile today, I got an error that looked like this:
#53 0.833 go: go.mod file not found in current directory or any parent directory.
#53 0.833       'go get' is no longer supported outside a module.
#53 0.833       To build and install a command, use 'go install' with a version,
#53 0.833       like 'go install example.com/cmd@latest'
#53 0.833       For more information, see https://golang.org/doc/go-get-install-deprecation
#53 0.833       or run 'go help get' or 'go help install'.
------
failed to solve: executor failed running [/bin/sh -c apk --no-cache add --virtual build-dependencies     git   && mkdir -p /root/gocode   && export GOPATH=/root/gocode   && go get github.com/mailhog/MailHog]: exit code: 1
make: *** [build] Error 17

I believe this is because the golang:alpine Docker image was updated to 1.18 recently, since 1.18 was released a couple of days ago. As of 1.18, go get <package> no longer builds executables. go install <package> should be used to install an executable instead.
See the deprecation message for more information: https://go.dev/doc/go-get-install-deprecation
Testing plan

Make sure the image builds from this updated Dockerfile successfully
Make sure running the image works.

Confirmed as working for me

Confirmed working in https://github.com/CODESIGN2/mailhog-docker

I had the same issue and I can confirm that this resolved this for me as well.

I can also confirm that this worked. Was interested in building an arm64 image.


osx cocoa sys call alert

in github.com/achille-roussel/go-vu/driver/cocoa

# github.com/achille-roussel/go-vu/driver/cocoa
../driver/cocoa/cocoa.c:80:48: warning: 'kCTFontHorizontalOrientation' is deprecated: first deprecated in OS X 10.11 [-Wdeprecated-declarations]
/System/Library/Frameworks/CoreText.framework/Headers/CTFontDescriptor.h:186:5: note: 'kCTFontHorizontalOrientation' has been explicitly marked deprecated here
../driver/cocoa/cocoa.c:106:7: warning: 'kCTFontHorizontalOrientation' is deprecated: first deprecated in OS X 10.11 [-Wdeprecated-declarations]
/System/Library/Frameworks/CoreText.framework/Headers/CTFontDescriptor.h:186:5: note: 'kCTFontHorizontalOrientation' has been explicitly marked deprecated here
../driver/cocoa/cocoa.c:114:50: warning: 'kCTFontHorizontalOrientation' is deprecated: first deprecated in OS X 10.11 [-Wdeprecated-declarations]
/System/Library/Frameworks/CoreText.framework/Headers/CTFontDescriptor.h:186:5: note: 'kCTFontHorizontalOrientation' has been explicitly marked deprecated here
# github.com/achille-roussel/go-vu/driver/shiny
../driver/shiny/shiny.go:24: cannot use display literal (type display) as type "github.com/achille-roussel/go-vu/driver".Display in argument to f:
	display does not implement "github.com/achille-roussel/go-vu/driver".Display (missing NewClipboard method)
../driver/shiny/shiny.go:48: cannot use win (type window) as type "github.com/achille-roussel/go-vu/driver".Window in assignment:
	window does not implement "github.com/achille-roussel/go-vu/driver".Window (missing Display method)
../driver/shiny/shiny.go:115: unknown event.ChangeScreen field 'Density' in struct literal

```

Hi @joeblew99, thanks for reporting and sorry for the compile errors.
I'm seeing two different things in your trace, one is the use of a deprecated Cocoa symbol, the other is an attempt to use the shiny backend.
For the first error, I'll fix it tonight it shouldn't be hard. I was working on a OS X 10.10 until now which is why I didn't catch that warning.
For the second error, this is more of a known issue for now, I attempt to be able to use different rendering backends including gomobile and shiny but I haven't had enough time to keep them up to date with other developments so building the examples for gomobile and shiny is expected to break right now.
All other examples using the desktop backend should be working tho, please let me know if that's not the case for you.

I've fixed the deprecations warnings, I'll close this issue, please feel free to reopen if you're still seeing the problem.

Thanks. Really awesome project.
On Tue, 19 Apr 2016, 07:32 Achille<EMAIL_ADDRESS>wrote:

Closed #14 https://github.com/achille-roussel/go-vu/issues/14.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/achille-roussel/go-vu/issues/14#event-632375956


Infer literal/parameter's unicodeness from property

Part of #4686

LGTM, cc @ajcvickers for TypeMapper changes.

Providers beware?

@ErikEJ yes.

Are we setting the right unicodeness on parameters for updates and deletes statements for tables with non-Unicode string keys? I haven't tested it but I suspect performance of those could be affected by the same database limitation.

@divega - This PR does not make any modification to update pipeline. Is there any issue tracking it?

@smitpatel there isn't a separate issue for updates. I can create one if you just want to get this in faster.

This one is marked for RC2 milestone. Should get this in before the ask mode. :smile:

Updated with all feedback.

:shipit:


Can not open connection to Hive

Description
I trying to connect one HIveDB from DBeaver and i am getting the error as shown above . i can connect to the server using other tools like Putty, WinScp and Hive Shell. Any help regrading this is highly appreciated.
DBeaver Version
22.0.4
Operating System
Windows 10 Enterprise
Database and driver
1 . Database HIVE and Driver "org.apache.hive.jdbc.HiveDriver"
hive-jdbc-uber-<IP_ADDRESS>-292.jar
Steps to reproduce

I try to connect to the database using credentials
i get this error
Could not open client transport with JDBC Uri: jdbc:hive2://{HiveServer}:10001/{DB}: java.net.ConnectException: Connection refused: connect
java.net.ConnectException: Connection refused: connect
java.net.ConnectException: Connection refused: connect
Connection refused: connect
Connection refused: connect
I kept server name as hidden.

Additional context
No response

Hello @nsaolapu
Maybe this thread will be helpful for you: https://community.cloudera.com/t5/Support-Questions/Hive-JDBC-Could-not-open-client-transport-with-JDBC-Uri/td-p/101772

Did you use the URL connection type or host?

Hi ,
I did use host and specified the our server name there. .
On Thu, 5 Jan, 2023, 2:43 pm Anastasiya, @.***> wrote:

Did you use the URL connection type or host?
[image: 2023-01-05 12_12_38-Connect to a database]
https://user-images.githubusercontent.com/45152336/210743682-2e70f0c8-1cbf-4d55-b578-f710eee93b78.png
—
Reply to this email directly, view it on GitHub
https://github.com/dbeaver/dbeaver/issues/18663#issuecomment-1371960659,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A5CYTYKIQXAWIYLA7U7ACGTWQ2GFHANCNFSM6AAAAAATRQ2ZCY
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hello @nsaolapu,
I'm sorry for the late response. Are you using an SSH tunnel?

We arr not using SSH . its not required . i have specified the connection
that we are using in mail trail above
On Thu, 26 Jan, 2023, 7:22 pm ShadelessFox, @.***>
wrote:

Hello @nsaolapu https://github.com/nsaolapu,
I'm sorry for the late response. Are you using an SSH tunnel?
—
Reply to this email directly, view it on GitHub
https://github.com/dbeaver/dbeaver/issues/18663#issuecomment-1405035130,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A5CYTYOH5YTEXEU6LUU4ND3WUJ6QRANCNFSM6AAAAAATRQ2ZCY
.
You are receiving this because you were mentioned.Message ID:
@.***>

It looks like the supplied server URL/address is not accessible. Are you sure it's available through other tools without an SSH tunnel?

It's been a long time since no update here. If you encounter this issue again, please let me know and provide additional info.


Create .changes/unreleased folder if it doesn't exist

Is your feature request related to a problem? Please describe.
changie new fails without a .changes/unreleased folder. This explains why changie init creates a file .changes/unreleased/.gitkeep (since git doesn't retain empty folders).
Describe the solution you'd like
It would be nice if changie new simply created the folder if it doesn't exist, as happens when running changie init. This doesn't seem like a risky thing to do.
Describe alternatives you've considered
Checking the .gitkeep file into git is clearly the intended approach, but I question whether it's really necessary 🤷

haha yea, https://www.freecodecamp.org/news/what-is-gitkeep/
My idea was to create this folder, and the .gitkeep or it would be deleted, to sort of mark the folder "hey, this is where changie will put things, it is empty now, but just a heads up" sort of thing. Having new create the directory is fine and would also work, but I was thinking it would help to always have a directory around, even if empty and not have it pop in and out depending on if anything was unreleased.
I guess if init created it, but new would re-create it, then its up to you how you want to use it.

Perhaps it's a bug then? I didn't check mine in and I get this (replicated by deleting the unreleased folder in the changie repo)

I don't think people should be digging around in the .changes folder, so they shouldn't notice the unreleased folder popping in and out. Git diff only shows files added or removed not whether the folder sticks around 🙂

I don't think people should be digging around in the .changes folder, so they shouldn't notice the unreleased folder popping in and out. Git diff only shows files added or removed not whether the folder sticks around 🙂

yea, that error definitely looks like what I expect. I wouldn't call it a bug as the intended and supported use case is, you use init and then new, batch and merge as normal. If you do not use init, or you end up deleting the .gitkeep and unreleased directory it would fail.
But I would consider it a fair feature request to allow the option of keeping that directory around or having changie create it if you deleted it. However, changie will not delete the directory if it is empty. But I think git is fine with that. Not sure though.

Yes I don't think changie should delete the empty folder. But creating it if it's missing seems harmless?

Yea I think I would accept that

Thank you! I was considering trying to implement it myself but I would need to learn the code and wouldn't have time until next week 😅

Thank you! I was considering trying to implement it myself but I would need to learn the code and wouldn't have time until next week 😅

No worries, should be good to go now.


Improvements in the Bored API

[API Enhancement] : Bored API #147

Closes #147

🗒 Checklist:

[x] I have mentioned the issue number in my Pull Request.
[x]  I have gone through rules of when PR will get merged.
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have created a helpful and easy to understand README.md
[x] I have followed proper file structure.
[x] I have gone through CONTRIBUTING GUIDELINES.md.

After making the necessary enhancements:

It uses my custom hosted domain "https://suyash878.github.io/JSON_boredAPI_Activities/" for fetching Activities. Users can modify the Activities.json file by adding or removing more activities according to their needs.

Hey @Suyash878, Thank you for creating PR! We will review it super soon. 😇❣
As we continue to evolve and innovate, we encourage you to share your ideas, feedback, and code to help us push the boundaries of what's possible in the world of APIs🚀.
We hope you have followed CONTRIBUTING GUIDELINES.
Thank you for being an essential part of our community. Together, we'll keep building amazing things!
Don’t forget to ⭐ our repository!
Happy Coding!✨
Will See you soon❣

@Suyash878 We're thrilled to inform you that your pull request has been successfully merged into the APIverse🚀🎁
Your hard work, dedication, and expertise have made a significant impact on our project, and we couldn't be more grateful for your contributions.😇
Your code will now be a part of our growing ecosystem, helping developers worldwide to create exceptional APIs.❣🔥
Happy Coding! ✨
Will See you soon❣


New "range_adjust" param in an attack's .xml file.

There's a text file that explains stuff.

Range Adjust - Testing and Other Fun Information.txt


Adding the new requirements for licenses

This has been merged with the private repo. https://github.com/MicrosoftDocs/dynamics-365-customer-engagement-pr/pull/1366


[Feature]: Please add working example and some info to docs about how to use custom validation messages

Describe the feature
I am doing like this but didn't help! Can't find any source about how to handling custom error messages.
EDIT:
I cleared my code and provided free to write code. Because the error messages are being shown but what I am exactly talking about is the "Required" text.
<template>
  <Sheet v-model:open="onOpen">
    <SheetContent>
      <SheetHeader class="mt-4">
        <SheetTitle>Create a post</SheetTitle>
        <SheetDescription>
          Write anything in your mind if useful, otherwise remain silent.
        </SheetDescription>
      </SheetHeader>

      <form @submit="onSubmit" class="space-y-4 mt-6">
        <FormField v-slot="{ field, errorMessage }" name="title">
          <FormItem>
            <FormLabel>Title</FormLabel>
            <FormControl>
              <Input
                class="bg-secondary"
                type="text"
                placeholder="Type your title here"
                v-bind="field"
              />
            </FormControl>
            <FormDescription>This is your public title of your post.</FormDescription>
            <FormMessage :message="errorMessage" />
          </FormItem>
        </FormField>
        <FormField v-slot="{ field, errorMessage }" name="body">
          <FormItem>
            <FormLabel>Body</FormLabel>
            <FormControl>
              <Textarea
                class="bg-secondary"
                placeholder="Type your post message here."
                v-bind="field"
              />
            </FormControl>
            <FormDescription>This is your public text area of your cool post.</FormDescription>
            <FormMessage :message="errorMessage" />
          </FormItem>
        </FormField>
        <Button type="submit">Submit</Button>
      </form>
    </SheetContent>
  </Sheet>
</template>

<script setup lang="ts">
import { ref, watch } from 'vue'
import { useSheetStore } from '@/stores/sheetStore'

import {
  Sheet,
  SheetContent,
  SheetDescription,
  SheetHeader,
  SheetTitle
} from '@/components/ui/sheet'

const sheetStore = useSheetStore()

// Directly bind the sheet store state to onOpen
const onOpen = ref(sheetStore.isSheetOpen)

// Sync local state with the Pinia store
watch(onOpen, (newVal) => {
  sheetStore.isSheetOpen = newVal
})

// FORM VALIDATION
import { useForm, configure, ErrorMessage } from 'vee-validate'
import { toTypedSchema } from '@vee-validate/zod'
import * as z from 'zod'

import { Button } from '@/components/ui/button'

import {
  FormControl,
  FormDescription,
  FormField,
  FormItem,
  FormLabel,
  FormMessage
} from '@/components/ui/form'

import { Input } from '@/components/ui/input'
import { Textarea } from '@/components/ui/textarea'

configure({
  validateOnBlur: false, // controls if `blur` events should trigger validation with `handleChange` handler
  validateOnChange: false, // controls if `change` events should trigger validation with `handleChange` handler
  validateOnInput: false, // controls if `input` events should trigger validation with `handleChange` handler
  validateOnModelUpdate: true // controls if `update:modelValue` events should trigger validation with `handleChange` handler
})

const postSchema = toTypedSchema(
  z.object({
    title: z.string().min(5, { message: "Iltimos 5tadan ko'p belgi kiriting." }),
    body: z.string().min(15, { message: "Iltimos hech bo'lmasa 15ta belgi kiriting." })
  })
)

const form = useForm({
  validationSchema: postSchema
})

const onSubmit = form.handleSubmit((values) => {
  console.log('Form submitted!', values)
})
</script>

Additional information

[ ] I intend to submit a PR for this feature.
[ ] I have already implemented and/or tested this feature.

I was talking about something like this:  .string({required_error: 'Please select an email to display.',}). Closing this issue as of having the issue resolved.

But please, consider adding some examples to the docs. Because it is the most required feature 😃


P0.5 - elastic search alternative option (Azure search or DB search as switchable options)

rt

https://github.com/microsoft/pai/pull/4164


Added fonts option to Elements.svelte component

The @stripe/stripe-js package supports the option to define custom fonts in the Elements wrapper, which as far as I can see is the only way to get custom fonts working for individual Elements (CardNumber, CardCvc, etc.). This PR adds a fonts prop on the Elements.svelte component to give the option to pass in custom fonts.
Please let me know if any changes need to be made. Thanks!

Thanks @daniel-panhead! 🙌🏻


Multi lines in .goa

Treat as executable bash/sh or any script with a shebang line, or a Windows batch file.

This works now.  It gets exec'd as a shell of batch file.  But you can't put Python or something like that directly in the .goa file.  The .goa can point to a python script though, and will exec it if it has the appropriate shebang line in it.


autofocus attribute or focus api?

Hi. I'm using draft-js as textarea.
But, I couldn't find focus api...
How to focus the contenteditable element?

There is a focus method in the API.
See here:
https://facebook.github.io/draft-js/docs/api-reference-editor.html#focus

Thanks!!