CI: job to check PR issue association should allow relates to association that is non-closing

https://github.com/orgs/community/discussions/66741
We should update our GHA to allow PR issue relation without closing association via fixes/closes/resolves to promote small, tracked PRs with a passing CI pipeline.

A preliminary regex to use instead using the github api to check if an issue is linked. Use GHA context to dynamically replace the org and repo name in the regex.
^((relates to)|(fixes)|(resolves)|(closes)):?(\s+)?https:\/\/github\.com\/opentdf\/platform\/issues\/\d+$

Test cases:
// PASS: no colon
fixes https://github.com/opentdf/platform/issues/1332
// PASS: one whitespace char
resolves: https://github.com/opentdf/platform/issues/1335
// PASS: multiple whitespace chars
relates to:  https://github.com/opentdf/platform/issues/1335
// PASS: no space
relates to:https://github.com/opentdf/platform/issues/1335
// FAIL: no https, no issues plural
http://github.com/opentdf/platform/issue/1332


Update Android registration code snipped

See: AGPUSH-1360

@matzew @sebastienblanc @secondsun Could you give it a spin?

@danielpassos @sebastienblanc should it say, somewhere, somehow which version of the API it is? 2.x for instance?

Yes, why not?!

@danielpassos ok, let's do it! @sebastienblanc any comments?

Let's put the version in a code comment at the beginning of the snippet , wdyt ?

ok
On Tue, Apr 14, 2015 at 11:05 AM, Sebastien Blanc<EMAIL_ADDRESS>wrote:

Let's put the version in a code comment at the beginning of the snippet ,
wdyt ?
—
Reply to this email directly or view it on GitHub
https://github.com/aerogear/aerogear-unifiedpush-server/pull/524#issuecomment-92707588
.

--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

AeroGear Android >=2.0 code to register Android device in UPS wdyt?

@danielpassos If you put it in the javadoc for the snippit why not @link it to aerogear-android-push?

merged...


[Feature/versions] Surface Versions on files [OSF-6026]

Purpose
The changes introduced a feature that would let users see what version of the file they were looking at on the files page. In addition when they clicked that version they would be taken to the files-view page on the Revisions tab, and be able to see what version of the file they would be looking at. Clicking the "Version #" at the top of the page would take them to the Revisions tab and further clicking of it would keep them on that page.
Changes
I made changes to a lot of files, on the front end I made a versions column on the files tab and in the files view page the version number is displayed alongside the name of the file.
I was not able to check for dropbox or any other addons, however the workings should be similar. A problem with my machine prevented local testing of those functions.
All of the features are purely front end changes so it would be hard to implement unit test for them.
Images
Before

After

Side effects
If the fangorn files are used as a template in any other places the the default columns could be initialized as Name and Version. This behavior might be  undesirable.
Editied a few inhouse functions that are used in other places. Mainly -fangornTitleColumn to be host to a helper function. This should still work in the way the previous one did in all other places in the code that it is used.
Ticket
https://openscience.atlassian.net/browse/OSF-6026

Okay, a couple of places where there are better tools that you could be using, and one place where I'm not sure if you're handling the templating portion right or not. Pass done. 🐧 Once you've finished with these changes and get it working again, please schedule a product demo with Nici and/or Sara before putting it back into code review so they can approve your implementation.

Pass done. 🐧

[ ] Verify you're not breaking anything by not having a version serialized for
[ ] Fix your setup to use the .jshintrc
[ ] Fix spaces

Fantastic. Could you add Before and After screenshots to the Changes section so QA knows what to look for? Then this should be good to go. 🎉 🐧 🎉

Pass finished.

Looks like there are merge conflicts and a request, "From the Product Consults flow: the link should toggle the revisions view, i.e. clicking alternately shows and hides the revisions view. Shaquille Johnson Can you please update your PR with this behavior?"

@SSJohns This is not working after the latest updates. When I click the "Version: " link, a JS error occurs.

and the Revisions tab does not get displayed.

I'll continue my CR when this is in a working state.

Pinging @pattisdr to make her aware of this feature, since she is working on porting the file detail page.

@SSJohns this adds a column to the files view. Did you check if the mobile view is still working well with the columns? Maybe put a screenshot. Also the project summary files widget screen shot would also be useful.

Hello, and yeah other changes in develop have added columns as well. It may be getting slightly cramped in the view though, but I don't think a column based webpage is really meant to be viewed in mobile.

If I'm not mistaken around 6-8% of our users do use their mobile phones. Whether we think a column based web page is meant to be used in mobile or not we do need to provide a working version to the users who are accessing their files from their phones. Cramped view may itself not be a problem, but we do need to address how the view is. Can you please add the screenshots?
@sloria

Oh sorry, I didn't mean to make it sound like I wasn't adding the screenshot, I added the screen shot right before I posted my comment. I just meant to point out that other people have been adding to the file view and I was not sure how I would address this because it is very out of line with my ticket and PR.

@SSJohns That's fair, and why it's all the more important to highlight this point. The sizing looks fine for the moment, but we will keep an eye on what else is being added. We will probably look into how to make the column names clear when truncated, but that's not necessarily part of this PR, probably another ticket would need to be made. I'll look into that. Thanks!


Provider a better completion navigation/details interaction

Completion items (e.g. as produced by a language server) can provide 'big' documentation strings. It would be nice to display these big strings in a popup side-panel in a manner similar to how Eclipse does this.
It's actually one of the few ways in which Eclipse ui is 'better' than many other an IDE. Seeing the full doc for the method or type you are completing on easily accessible right next to the completions menu is, in my opinion, really convenient.
vscode right now shows a kind of 'shortened' version of the documentation (which can look really uggly, depending on whether the original source looks good when you just strip out newlines to attempt to display it on a single line). vscode also provides a little 'info' button you can click which opens the 'detailed' view of the docs. This is not very convenient because the extra clicks and context switch between completions view and 'details view' makes it rather hard to navigate quickly between completions and see their respective docs before making a choice on which completion you really wanted to pick.
Note: somewhat related. It would be nice if the 'side view' was capable of rendering markdown properly. But perhaps that is really a separate issue. And maybe it is covered already by this issue ticket:
https://github.com/Microsoft/language-server-protocol/issues/137

The current design was an explicit decision: we want less popups in our source code.

That sounds good and I appreciate the 'limit the popups rule'.
So, I agree with your rephrasing. However, please don't rule out using a well-placed popup, just because its a popup when you consider how to actually implement it.
Popups can be annoying sure. But I don't think they are annoying by definition. A popup which shows some interesting information without being annoying/intrusive is actually a good popup.
The documentation side view 'popup' as I'm used to it from Eclipse, i.m.o is actually a pretty good design because:
a)  it doesn't reduce the vertical scroll area available for showing the completion items themselves
b)  it gives a fair amount of space to displaying big docs without feeling intrusive or annoying
c)  it doesn't make the completion items 'jump around' vertically to insert the extra details / docs inline into the completions list

BTW: Eclipse's 'side-view popup' is position and sized so that it aligns nicely with the completions menu. Perhaps this is a big part of why it 'feels good'. The alignment makes it feel and look more like the side-view and completions menu are a 'single popup' rather than two separate popups. So I could also imagine a single-popup design which has some extra-space to the side to show details. From user point of view that would be functionally equivalent (and doesn't violate your 'only one simultaeous popup' rule).


feat(env): remove FSXA_HOST and FSXA_PORT

Added init of api singleton implemented in https://github.com/e-Spirit/fsxa-pattern-library/pull/40


GitHub API request failed: Maximum number of login attempts exceeded. Please try again later.

Seems like we can't build in Travis anymore.
https://travis-ci.org/danielgindi/Charts
It's been a few days already that it is failing.
Is it my fault or Facebook's? Or maybe Travis'?

Any news on this? I apologize but we kind of rely on this :-)

I haven't figured this out yet, it was happening before 2.1.0 as well so I am not sure what is going on.

Maybe try to invalidate the authorization token of Travis on Github, and issue a new one?

Have you checked out https://github.com/Carthage/Carthage/issues/1236?


Does not fire tracking callback when using api_transport: 'sendBeacon'

When using `api_transport: 'sendBeacon' the tracking callback isn't called. If that is by design, then I think it should be explicitly mentioned in the documentation, since that is definitely not what I expect.
I think that it should be very easy to fix this, basically just call the callback from the block in the if statement here:
https://github.com/mixpanel/mixpanel-js/blob/master/src/mixpanel-core.js#L397-L402
Since the sendBeacon api doesn't really have a response object, then maybe it should mock one, similar to how the error branch of the XHR transport branch does it (https://github.com/mixpanel/mixpanel-js/blob/master/src/mixpanel-core.js#L441). So maybe, something like this:
        try {
            if (sendBeacon(url, body_data)) {
                callback({ status: 200 });
            } else {
                callback({ status: 0, error: 'sendBeacon failed to track' });
            }
        } catch (e) {
            console.error(e);
            callback({ status: 0, error: `error calling sendBeacon: ${e}` });
        }

Sorry, I thought we'd covered this in the docs but in retrospect this could be talking about the web api too: "the sendBeacon API does not support callbacks or any way to know the result of the request."
In principle the tracking callback is supposed to report whether the event was successfully queued up by Mixpanel's API servers, not the fact that a request was made (for which you don't need a callback at all; you'll know from the return value of mixpanel.track() whether the network call was attempted or not). You're right though that we currently don't take the return value of navigator.sendBeacon() into account. Would you be ok with mixpanel.track() returning a falsey value when sendBeacon does? This would be in line with the existing convention, where track() doesn't call the callback if it never makes the request.

Sure, this would be a good solution. Although, maybe it should be documented that the mixpanel.track() function has a return value and that it can be used like this?
The current documentation doesn't seem to mention that at all: https://developer.mixpanel.com/docs/javascript-full-api-reference#section-mixpanel-track

OK, as of https://github.com/mixpanel/mixpanel-js/releases/tag/v2.35.0 the track() method should be returning false when the return value of sendBeacon is falsey (i.e. the request wasn't successfully enqueued).
The documentation has also been updated to include the return value: https://developer.mixpanel.com/docs/javascript-full-api-reference#section-mixpanel-track
Thanks for the report!


Extend VDB Point conversion to support Vec3f as well as Vec3d

There was some ambiguity in the function signatures that was causing the CI to fail. I found a slightly improved way to do this that doesn't require deprecations or changing the API. In this implementation, the type it uses is PointWrapperT::value_type unless this has not been defined in which case it falls back to Vec3R. This should mean that all existing code continues to work and it just requires a using value_type = Vec3f in the wrapper to be able to change the value type.


Long term storage for Bakery BuildLogs

In the long run, we really need to think about the right architecture here... Should the bakeries have their own REST endpoint? Sqlite database? Log to a central service?
Originally posted by @rabernat in https://github.com/pangeo-forge/pangeo-forge-orchestrator/pull/1#discussion_r741084344

This issue is resolved by the new API development work.


Add indent property to question

The default indent property value is 0. The available values are: {0, 1, 2, 3}. The default offset, margin-left, for 1 is 20px, 40px for 2 and 60px for 3. To change it, use survey.css.question.indent, default value is 20.

Committed the implementation.

Is there a way to use margin instead of padding for indenting?

@Aymsu, hello! Why do you need it? Please describe your use case.

@dmitrykobets
I use a custom css class :   question: { mainRoot: 'survey-question-blue' }    resulting in the following :

when answered yes another question is displayed with indentation :

But I'm trying to achieve the following which works with margin:

@Aymsu, hello! Sorry for the late response. I've created an example for you based on cssClasses. Could you please check it? https://plnkr.co/edit/tvR2MXqB7cUlCWE3jUIa?p=preview

Works like a charm ! Thanks a lot


DSD response with UNSD agency

Hello dr-leo,
I am trying to harvest some data from national accounts from the UNSD agency.
I tried the following code:
from pandasdmx import model, Request
unsd = Request('UNSD')
cat_response = unsd.categoryscheme()
print(cat_response.write().categoryscheme)
dsd_id = unsd.categoryscheme().dataflow.NA_MAIN.structure.id
dsd_response = unsd.datastructure(resource_id = dsd_id)

and I get the following error:
Python\Anaconda3\lib\site-packages\requests\models.py", line 928, in raise_for_status     raise HTTPError(http_error_msg, response=self) requests.exceptions.HTTPError: 404 Client Error: Not Found for url: http://data.un.org/WS/rest/datastructure/UNSD/NA_MAIN/latest/?references=all
Is there anything I am doing wrong?
Best,
Charlescad
`

Hi, I am currently off-line and cannot reproduce the error. My best guess is that the structure reference specifies a different agency ID look at the attributes of these trucks are reference to verify this. I would recommend not to request the data structure in the first place, Rhonda, my advice would be to request the data flow specifying the data flow ID. You should then receive a response containing the data structure, “lists etc. This does not work for all agencies though, as you can see from the example on the index page of the documentation. Let me know if this works for you. Regards, leo

Am 03.07.2018 um 16:54 schrieb Charlescad<EMAIL_ADDRESS>Hello dr-leo,
I am trying to harvest some data from national accounts from the UNSD agency.
I tried the following code:
from pandasdmx import model, Request
unsd = Request('UNSD')
cat_response = unsd.categoryscheme()
print(cat_response.write().categoryscheme)
dsd_id = unsd.categoryscheme().dataflow.NA_MAIN.structure.id
dsd_response = unsd.datastructure(resource_id = dsd_id)
and I get the following error:
Python\Anaconda3\lib\site-packages\requests\models.py", line 928, in raise_for_status raise HTTPError(http_error_msg, response=self) requests.exceptions.HTTPError: 404 Client Error: Not Found for url: http://data.un.org/WS/rest/datastructure/UNSD/NA_MAIN/latest/?references=all
Is there anything I am doing wrong?
Best,
Charlescad
`
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I've doublechecked this and found that UNSD does not provide a dataflow with the ID you're looking for. Don't know why it Shows up in the categorizations.

flows=un.dataflow()

Shows the dataflows that UNSD actually provides.
I recommend to use data from another agency such as IMF or OECD to retrieve data on national accounts.

Hi,
Sorry for the last answer. Here is my code:
from pandasdmx import model, Request
List of agencies
print(Request.list_agencies())
UNSD Agency
unsd = Request('UNSD')
cat_response = unsd.categoryscheme()
print(cat_response.write().dataflow) # dataflows into category schemes
I see that there is a NA_MAIN into the category scheme NATIONAL_ACCOUNTS
and i try to get data from there:
This one works:
print('Number of series:', unsd.preview_data('NA_MAIN', count = True, total
= True))
series_keys = unsd.series_keys('NA_MAIN',cache = True)
print(list(series_keys))
From there, I suspect that there is a DataStructure NA_MAIN  and I want to
explore this. For that, I want to use dsd.
Series keys on NA_MAIN
dsd_id = unsd.categoryscheme().dataflow.NA_MAIN.structure.id
print(dsd_id)
refs = dict(references = 'all')
print(unsd.categoryscheme().url) # URL category schemes
dsd_response = unsd.datastructure(resource_id = dsd_id, params = refs)
While it works on another dataset that I can see not through the
categoryscheme but in dataflows:
print(unsd.dataflow().write()) # dataflows not necessarly into category
schemes
Series keys on another dataset
dsd_id = unsd.categoryscheme().dataflow['DF_UNDATA_COUNTRYDATA'].
structure.id
print(dsd_id)
refs = dict(references = 'all')
dsd_response = unsd.datastructure(resource_id = dsd_id, params = refs)
print(dsd_response.write())
Is that right? Sorry I am a new python user as well as a new pandaSDMX
user.
Thank you very much,
Charles.
On Thu, Jul 5, 2018 at 2:36 PM, dr-leo<EMAIL_ADDRESS>wrote:

Closed #66 https://github.com/dr-leo/pandaSDMX/issues/66.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dr-leo/pandaSDMX/issues/66#event-1717966264, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFb6NlQwe2I9zqJzHR93qXDEjfLGldi9ks5uDgg8gaJpZM4VBG5M
.

Thanks. I will try to reproduce this. But it may take some time (I
have day-job and Kids).
Note that the preview_data method does not download the DSD, but
attempts to download an empty dataset with all valid series keys. You
can see tzis by inspecting the Cache or memcache dict attached to the
Request instance. Perhaps this already answers your question. - It
would be an error if an agency offered a dataflow with no DSD. But do
a dir() on the .structure reference attached to the dataflow. And you
can see the agency_ID of the agency providing that DSD. In v0.8.2 some
of the Ref Attributes were Buggy. This is fixed in the dev branch on
github.
On a General note, it would be extremely helpful if you could send
Code examples with Outputs. This would save me (or any other reader) a
lot of time. To do this, you may wish to use the excellent and very
popular browser-based Jupyter Notebook or the IPython console if you
prefer. As a Python novice you may want to consider using Jupyter
anyway. It may Change your life.
On 05/07/2018, Charlescad<EMAIL_ADDRESS>wrote:

Hi,
Sorry for the last answer. Here is my code:
from pandasdmx import model, Request
List of agencies
print(Request.list_agencies())
UNSD Agency
unsd = Request('UNSD')
cat_response = unsd.categoryscheme()
print(cat_response.write().dataflow) # dataflows into category schemes
I see that there is a NA_MAIN into the category scheme NATIONAL_ACCOUNTS
and i try to get data from there:
This one works:
print('Number of series:', unsd.preview_data('NA_MAIN', count = True, total
= True))
series_keys = unsd.series_keys('NA_MAIN',cache = True)
print(list(series_keys))
From there, I suspect that there is a DataStructure NA_MAIN  and I want to
explore this. For that, I want to use dsd.
Series keys on NA_MAIN
dsd_id = unsd.categoryscheme().dataflow.NA_MAIN.structure.id
print(dsd_id)
refs = dict(references = 'all')
print(unsd.categoryscheme().url) # URL category schemes
dsd_response = unsd.datastructure(resource_id = dsd_id, params = refs)
While it works on another dataset that I can see not through the
categoryscheme but in dataflows:
print(unsd.dataflow().write()) # dataflows not necessarly into category
schemes
Series keys on another dataset
dsd_id = unsd.categoryscheme().dataflow['DF_UNDATA_COUNTRYDATA'].
structure.id
print(dsd_id)
refs = dict(references = 'all')
dsd_response = unsd.datastructure(resource_id = dsd_id, params = refs)
print(dsd_response.write())
Is that right? Sorry I am a new python user as well as a new pandaSDMX
user.
Thank you very much,
Charles.
On Thu, Jul 5, 2018 at 2:36 PM, dr-leo<EMAIL_ADDRESS>wrote:

Closed #66 https://github.com/dr-leo/pandaSDMX/issues/66.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dr-leo/pandaSDMX/issues/66#event-1717966264, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFb6NlQwe2I9zqJzHR93qXDEjfLGldi9ks5uDgg8gaJpZM4VBG5M
.

--
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub:
https://github.com/dr-leo/pandaSDMX/issues/66#issuecomment-402718805

Hi again,
Thank you so much this is already super nice to verify that!
Here are the results in a more readable fashion created via Jupyter
Notebook.
In the meantime, I checked dir() on the structure and the agency_id: this
is ESTAT providing this dataset!
At this step, I think that we can say you have resolved my issue,
Thank you so much,
Best,
Charles.
On Thu, Jul 5, 2018 at 4:18 PM, dr-leo<EMAIL_ADDRESS>wrote:

Thanks. I will try to reproduce this. But it may take some time (I
have day-job and Kids).
Note that the preview_data method does not download the DSD, but
attempts to download an empty dataset with all valid series keys. You
can see tzis by inspecting the Cache or memcache dict attached to the
Request instance. Perhaps this already answers your question. - It
would be an error if an agency offered a dataflow with no DSD. But do
a dir() on the .structure reference attached to the dataflow. And you
can see the agency_ID of the agency providing that DSD. In v0.8.2 some
of the Ref Attributes were Buggy. This is fixed in the dev branch on
github.
On a General note, it would be extremely helpful if you could send
Code examples with Outputs. This would save me (or any other reader) a
lot of time. To do this, you may wish to use the excellent and very
popular browser-based Jupyter Notebook or the IPython console if you
prefer. As a Python novice you may want to consider using Jupyter
anyway. It may Change your life.
On 05/07/2018, Charlescad<EMAIL_ADDRESS>wrote:

Hi,
Sorry for the last answer. Here is my code:
from pandasdmx import model, Request
List of agencies
print(Request.list_agencies())
UNSD Agency
unsd = Request('UNSD')
cat_response = unsd.categoryscheme()
print(cat_response.write().dataflow) # dataflows into category schemes
I see that there is a NA_MAIN into the category scheme NATIONAL_ACCOUNTS
and i try to get data from there:
This one works:
print('Number of series:', unsd.preview_data('NA_MAIN', count = True,
total
= True))
series_keys = unsd.series_keys('NA_MAIN',cache = True)
print(list(series_keys))
From there, I suspect that there is a DataStructure NA_MAIN and I want to
explore this. For that, I want to use dsd.
Series keys on NA_MAIN
dsd_id = unsd.categoryscheme().dataflow.NA_MAIN.structure.id
print(dsd_id)
refs = dict(references = 'all')
print(unsd.categoryscheme().url) # URL category schemes
dsd_response = unsd.datastructure(resource_id = dsd_id, params = refs)
While it works on another dataset that I can see not through the
categoryscheme but in dataflows:
print(unsd.dataflow().write()) # dataflows not necessarly into category
schemes
Series keys on another dataset
dsd_id = unsd.categoryscheme().dataflow['DF_UNDATA_COUNTRYDATA'].
structure.id
print(dsd_id)
refs = dict(references = 'all')
dsd_response = unsd.datastructure(resource_id = dsd_id, params = refs)
print(dsd_response.write())
Is that right? Sorry I am a new python user as well as a new pandaSDMX
user.
Thank you very much,
Charles.
On Thu, Jul 5, 2018 at 2:36 PM, dr-leo<EMAIL_ADDRESS>wrote:

Closed #66 https://github.com/dr-leo/pandaSDMX/issues/66.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dr-leo/pandaSDMX/issues/66#event-1717966264, or
mute
the thread
<https://github.com/notifications/unsubscribe-auth/
AFb6NlQwe2I9zqJzHR93qXDEjfLGldi9ks5uDgg8gaJpZM4VBG5M>
.

--
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub:
https://github.com/dr-leo/pandaSDMX/issues/66#issuecomment-402718805

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dr-leo/pandaSDMX/issues/66#issuecomment-402737472,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFb6NmOzFkHU74LrSrpFi_VB7EQMoAtfks5uDiAagaJpZM4VBG5M
.


[Swift 4] Update Shell Sort

Checklist

[x ] I've looked at the contribution guidelines.
[ x] This pull request is complete and ready for review.

Description

Cheers @carlosaking. Thanks for making the changes to the readme!


Discussion: Display names of reacting users when hovering a reaction

Checklist
General

[x] I tested all changes and their related features with all corresponding user types on a test server.
[ ] This is a small issue that I tested locally and was confirmed by another developer on a test server.
[x] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
[x] I chose a title conforming to the naming conventions for pull requests.

Client

[x] I followed the coding and design guidelines.
[x] I added multiple integration tests (Jest) related to the features (with a high test coverage), while following the test guidelines.
[x] I added authorities to all new routes and checked the course groups for displaying navigation elements (links, buttons).
[x] I documented the TypeScript code using JSDoc style.
[x] I added multiple screenshots/screencasts of my UI changes.
[x] I translated all newly inserted strings into English and German.

Motivation and Context

Proposed by a user requesting the feature in #4306.
The PR also fixes a bug described in #4323.
It fixes the window title for the course discussion page that got lost when restructuring module loading to reduce the bundle size (see pictures)

Description

For the features that shown the names of reacting users, we make use of the existing functionality in buildReactionMetaDataMap that collects reacting users for a each reaction on a postings and determines if the logged in user is among them (in this case the emoji is highlighted). We transform this information with a newly introduced pipe reactingUsersOnPosting that takes the array of reacting users and outputs a suitable string taking into account several aspects:

if only the currently logged in student reacted -> "you"
if there are only two users reacting their names are joined with "and" (or "und") -> "x and y reacted."
if there are more than two users reacting their names are joined with ", " but the last name is appended with "and" -> (x, y and z reacted"
if the logged in user reacted, he/she is included in the list of reacting users by having "You" (or "Du") in the beginning of the string -> "you, x, y and z reacted".
if there are more than 10 (e.g. 12)  people reacting, the list is trimmed -> "a, b, c, d, e, f, g, h, i, j and 2 other users reacted."

Steps for Testing

Prerequisites:

1 User
1 Course with postings enabled

Log in to Artemis
Navigate to course discussion overview -> name in tab should be Discussion or Diskussion
Hover over reactions -> check that the showed tooltips on reacting users follows the rules introduced in the description above
Change the language -> check if the tooltip language automatically changed accordingly, without reloading the page
Add a reaction -> check that the tooltip on reacting users is updated correctly
Remove a reaction -> check that the tooltip on reacting users is updated correctly
For reactions with more than 10 users, check that the tooltip on reacting users is trimmed correctly (you can use this posting to test, it already has 11 reacting users: https://artemistest.ase.in.tum.de/courses/477/lectures/184?postId=1798)
As windows user confirm that when hovering the button to add a reaction the scrollbar of the window does not flicker anymore and you can click the button without any disturbances.

Review Progress

Code Review

[ ] Review 1
[ ] Review 2

Manual Tests

[ ] Test 1
[ ] Test 2

Test Coverage

reacting-users-on-posting.pipe.ts: 100%
posting-reaction-bar.component.ts: 85,7%
post-reaction-bar.compnent.ts: 100%
answer-post-reaction-bar.component.ts: 95,1%
Screenshots

1. Hovering over reactions to see user names:
https://user-images.githubusercontent.com/41366522/144046717-fa8714fe-f6aa-4023-afa1-cd1d23561c7a.mov
2. Changed tooltip for choosing a reaction -> hint is now encapsulated in a button "title" which looks a bit different than the tooltips but this prevents the scrollbar from flickering in windows (#4323) which prevents the button from being usable.
Before:

After:

3. Fixed window title for course discussion page (before: red, after: green):

@JohannesStoehr and @willergeorg as you both reported the issue with the scrollbar and reaction tooltip to me, please checkout this PR. I aimed to resolve this! Please, let me know if the behavior of the "add-reaction"-button is ok now.

@JohannesStoehr thanks for the hint, I adapted it in 9a06cce.


fsharpi fails with error FS0193 on mono 5.0

Since I updated to mono 5.0 I've got this weird issue when using fsharpi:
error FS0193: Specified method is not supported
It only happens when I try to run stuff from fsharpi, not when I compile and run.
I managed to create an absurdly small example that triggers the error for me:
// in problem.fsx
let f a =
    match a with
    | [] ->
        true
    | _ ->
        true

then:
↪ fsharpi problem.fsx

error FS0193: Specified method is not supported.

Related information
F# version:
F# Interactive for F# 4.1
My mono version:
↪ mono --version
Mono JIT compiler version 5.0.0 (Stable <IP_ADDRESS>/9667aa6 Fri May 12 07:20:13 UTC 2017)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           __thread
	SIGSEGV:       altstack
	Notifications: epoll
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug
	LLVM:          supported, not enabled.
	GC:            sgen (concurrent by default)

OS:
Arch Linux
Kernel:
x86_64 Linux 4.10.13-1-ARCH

I just managed a much smaller example:
F# Interactive for F# 4.1
Freely distributed under the Apache 2.0 Open Source License

For help type #help;;

> [1; 2];;
val it : int list = [1; 2]
> [1];;
val it : int list = [1]
> [];;

error FS0193: Specified method is not supported.

So to me it seems like the empty list is triggering this error.
Also, it might be related to #739, since it's the same error code.

Update:
Downgrading to mono 4.8.0 solved the issue for me, so only version 5.0.0 is causing problems with fsharpi.

@nosami could you take a look?
@Zinggi Have you tried compiling from master?

@dsyme no, I haven't tried with the master branch yet.
I'm using what's included in my distro, that is version <IP_ADDRESS>-1 (https://www.archlinux.org/packages/extra/any/fsharp/)
If I find the time I can try compiling the master branch

13:00 $ fsharpi

F# Interactive for F# 4.1
Freely distributed under the Apache 2.0 Open Source License

For help type #help;;

> let f a =
-   match a with
-   | [] ->
-     true
-   | _ ->
-     true;;
val f : a:'a list -> bool

> [];;
val it : 'a list

>

Working for me on OSX with Mono <IP_ADDRESS>. I think the fsharp package needs to be upgraded in Archlinux

I can confirm that the error vanishes with fsharp 4.1.18-1.
The official arch package is still not updated, but this version can already be found in testing.

I can find this bug when using stock versions of mono(<IP_ADDRESS>+dfsg3-1ubuntu1) and fsharp(<IP_ADDRESS>+dfsg2-2) included by default in Ubuntu 19.04 previews.
@directhex do you mind confirming if you see the same thing in the version of Debian that already includes Mono 5.16.x please?

@RAOF hey Christopher, by any chance a F#4.1 version can still be uploaded in time for Ubuntu 19.04? otherwise fsx scripts will not be able to run in this version of Ubuntu.

@knocte confirmed.


pb/rename

Rename all project metadata
Strip leading namespace

Yeah, I might adopt this "namespace-less library" design for CLI projects like this in the future, just to be more flexible to this sort of thing.


Can not see other maps in the cluster

all three maps are the same config minus their map name and ports here is the island, server runs, you can play but when you go to an obelisk and try to go to another map there are none in the list
arkserverroot="/home/steam/ARK"
arkbackupdir="/home/steam/ARK-Backups/theisland"
serverMap="TheIsland"
ark_RCONEnabled="True"
ark_RCONPort="32330"
ark_SessionName="MuddyARK-TheIsland"
ark_Port="7778"
ark_QueryPort="27015"
ark_AltSaveDirectoryName="Saved-TheIsland"
arkflag_AllowCaveBuildingPVE=true
ark cluster settings
arkflag_NoTransferFromFiltering=""
arkopt_clusterid=muddycluster
#ark_PreventDownloadSurvivors=False
#ark_PreventDownloadItems=False
#ark_PreventDownloadDinos=False
#ark_PreventUploadSurvivors=False
#ark_PreventUploadItems=False
#ark_PreventUploadDinos=False
#ark_noTributeDownloads=false
arkopt_ClusterDirOverride=/home/steam/ark-clusterdata

Try changing your first line you listed to
arkflag_NoTransferFromFiltering=true  (not "")
Everything else looks correct, I just setup the same thing myself and it works fine.
I assume you are running all instances on the same Linux server? If not, then you need to ensure that /home/steam/ark-clusterdata is a shared NFS mount for all servers.


Extract into individual files

Fixes #63

Thanks for the great work, this looks absolutely fantastic!
I am however encounter some issues:

I'm getting a type issue with importing (d).ts files (e.g. for obsidian/Vault.d.ts. I've tried changing the tsconfig.json, but haven't found the correct set of configurations to fix that.
TS language server seems to not be able to pick up the typings anymore. (Which is probably related to the previous problem)

I don't know if you are facing these issues, it might also be a configuration problem with the repository I use for testing the typings.

@Fevol I made it fully working on my test repository.
Can you please share the tes repository where you encounter misbehavior?

@Fevol let me clarify
Are you trying to
import "obsidian/Vault.d.ts";

?
If so, I didn't consider this scenario. You want to be able to augment only individual interfaces without modifying others?

Can you please share the test repository where you encounter misbehavior?

Sadly not easily, I did try to replace the obsidian-ex.d.ts with the lib directory for another repository (e.g. used as a NPM package in node_modules), and that worked without issue. So it definitely has something to do with how I configured my test repository.

Are you trying to (...)

No, in this case, the problem is just having the typings be registered to the language server (i.e. App not being extended). I am using a slightly orthodox set-up with symlinks, so I am wondering whether that has something to do with it:
├─ \source_code\ (Source code for reverse-engineering)
├─ \obsidian-typings\ (Git repo for developing the typings, SYMSOURCE)
└─ \plugin_test\ (Sample plugin)
      └─ \node_modules\
             └─ \@types\
                    └─ \obsidian-typings\ (SYMLINKED)

I'll try to see if I can find the issue ASAP.

@Fevol your test environment looks similar to mine
Try the following
cd /path/to/obsidian-typings
npm link

cd /path/to/plugin_test
npm link obsidian-typings

And try again

@Fevol I am currently doing some final changes, and updating the docs to provide examples

Alright, I finally managed to resolve the issue. The LSP was using the typescript package from v4.7.5, when I installed typescript for the obsidian-typings repository and changed the LSP to that typescript install, it worked again.
So after updating typescript for plugin_test from v4.7.5 to v5.4.5, the issue went away and the typings got picked up again. I'm guessing some particular config was changed between those two versions that caused the issue (or perhaps something with ESNext? Haven't investigated it yet.

@Fevol ready to test

Apologies for the wait, I spent a while reworking the custom tsmorph formatter to the new directory structure and the formatter you are using -- I hope it is alright that I've added those to this PR too.
Further, I'm sorry that I won't be able to merge the PR immediately. I spent the past two hours trying to figure out why the typings aren't getting picked up again for both my sample and 'real' plugins. I only managed to get a working configuration for a single minute, which broke not much later.
I did eventually manage to get things working, some takeaways from my experience:
The next version should definitely be a 2.0.0 version, as there are quite a lot of breaking changes:
- From 5a835238 onwards, there is also an issue where the definition file for obsidian-typings cannot be found (TS2688), I haven't investigated this yet, but I did notice that some imports were erroneously renamed to XXXX.d.ts, so it might have something to do with that.
- Some interfaces/classes obviously need to be imported from obsidian-typings instead of obsidian itself (I realized this far too late, because dozens of different errors got spat out 😅)
- Plugin's tsconfig.json now requires you to add allowImportingTsExtensions: true (Would it be possible to avoid having this requirement? The errors can be very vague when users update without knowing what changed.)
- Importing from obsidian-typings doesn't give autocompletions for the classes, only for the plugin values (InternalPluginName).
- Extending types further (e.g. in a extensions.d.ts file within the plugin repo) does not seem to work anymore; the typings there take precendence over the types defined in obsidian-typings.  Specific example:
// extensions.d.ts
declare module "obsidian" {
	interface Plugins {
		plugins: {
			"commentator": CommentatorPlugin;
		};
	}
}

// main.ts
this.remove_monkeys.push(around(this.app.plugins, {
	// ERROR: Plugins does not have a method `uninstallPlugin`
	uninstallPlugin: (oldMethod) => {
		return async (id: string) => {
			oldMethod && await oldMethod.apply(this.app.plugins, [id]);
			if (id === "commentator")
				await this.database.dropDatabase();
		};
	},
}));

As it is already quite late now, I will try look at the issues in more detail tomorrow. It is very likely that I made some stupid mistake somewhere along the line; so I'll need to look at it with a fresh mind.
If at all possible, I would like to make the migration for dependants of this package smooth enough that it doesn't require more than five minutes of work. The main problem will be communication of the changes, I'll probably make a Discord post and a pinned issue on this repo so as many people will see it as possible.
I want to note though: I am really happy with these changes! I'll admit - at first I was doubtful, but having each interface separated really does make navigation and browsing much easier. Thank you very much for all your fantastic work, and sorry for all the hold-ups!

@Fevol thanks for the feedback

I hope it is alright that I've added those to this PR too.

That's great, so you can force the code style before accepting PRs.

I spent the past two hours trying to figure out why the typings aren't getting picked up again for both my sample and 'real' plugins

It also took me way more hours to understand how to get it fully working. Now I know about typescript compilation, type resolutions etc, way more than I ever wanted to.

The next version should definitely be a 2.0.0 version

Agree

as there are quite a lot of breaking changes:

that's hopefully a misunderstanding

From https://github.com/Fevol/obsidian-typings/commit/5a8352385712f32ee232eb129682c749829e8fad onwards, there is also an issue where the definition file for obsidian-typings cannot be found (TS2688)

I will try to replicate this issue from the new project, as my current ones works perfectly

some imports were erroneously renamed to XXXX.d.ts

Why do you think it is an error? It is actually a very deliberate choice

Some interfaces/classes obviously need to be imported from obsidian-typings instead of obsidian itself

Yes, this is indeed a breaking change, but I think it totally worth it. In my opinion previous model is extremely confusing and misleading.

Plugin's tsconfig.json now requires you to add allowImportingTsExtensions: true (Would it be possible to avoid having this requirement? The errors can be very vague when users update without knowing what changed.)

this setting is only required for the project itself, and should not be forced to the client projects
I honestly think that without this setting the code looks horrible.
It forces to write
import { InternalPlugins} from "../types.js";

while there is no types.js file. I think it is extremely misleading and unfriendly.
There is one place in lib/types.d.ts where I couldn't avoid making reference to non-existing files. I made me upset, but it is what it is. I put a comment there.

Importing from obsidian-typings doesn't give autocompletions for the classes, only for the plugin values (InternalPluginName).

That's very strange, because in my latest fix, I clearly separated types vs implementations, see README

Extending types further (e.g. in a extensions.d.ts file within the plugin repo) does not seem to work anymore; the typings there take precendence over the types defined in obsidian-typings. Specific example:

Thanks, I will test your example shortly

As it is already quite late now, I will try look at the issues in more detail tomorrow. It is very likely that I made some stupid mistake somewhere along the line; so I'll need to look at it with a fresh mind.

I will try to help you to get this tested ASAP. Don't hesitate to ask. I am in the UTC-6 timezone

If at all possible, I would like to make the migration for dependants of this package smooth enough that it doesn't require more than five minutes of work. The main problem will be communication of the changes, I'll probably make a Discord post and a pinned issue on this repo so as many people will see it as possible.

I would create a MIGRATION.md document or similar describing how to do the migration, step-by-step, but, honestly, I don't think there should be many.

I want to note though: I am really happy with these changes! I'll admit - at first I was doubtful, but having each interface separated really does make navigation and browsing much easier. Thank you very much for all your fantastic work, and sorry for all the hold-ups!

I am a big fan of your project and would be very proud if you can take advantage of my efforts!

@Fevol I can confirm I am having similar issues to the ones you described, when I tried to use the new version in my other project. I will troubleshoot and find the solution

@Fevol it took me awhile but I figured it out
Troubleshooting
The most difficult part was to understand why the typings are not picked up while compilation works.
So the trick is to set "skipLibCheck": false in the test project, and run tsc --build --force and it will help to catch the issue instantly.
Incompatible obsidian package
My test project had old version of obsidian installed which is not compatible with the latest one used by obsidian-typings. We set it a peerDependency but it seems to be not good enough
So please ensure your obsidian package is updated.
"moduleResolution": "NodeNext"
Please ensure your tsconfig.json has the following setting. As of now, obsidian-typings is built for this mode, and in case we want to support other older systems, we can build sources into the format expected by older systems.
I am more than welcome to help you with this, but I think first we need to ensure it works at least for you, before we move any on :)

Why do you think it is an error? It is actually a very deliberate choice
I was thinking that because I saw a package.json being renamed to package.d.tson in one of the scripts (https://github.com/Fevol/obsidian-typings/commit/5a8352385712f32ee232eb129682c749829e8fad#diff-d7c10983349f520dd101e4bcb29702f993cf43b625cc0128be48eb8f80282957L31-R32), but I am guessing it's just an isolated problem

Yes, this is indeed a breaking change, but I think it totally worth it. In my opinion previous model is extremely confusing and misleading.
Absolutely, this is definitely necessary, I'll just need to communicate it well so people won't get confused!

I applied all of the fixes but I am still hitting some roadblocks:

Extending from tsconfig.jsons provided by packages is an issue (example: Svelte requires you to extend its tsconfig if you want to have TS typings for svelte files)
Even after removing the extend, the tsc --build --force still returns Cannot find type definition file for 'obsidian-typings'. without any other indications of what the issue is.

@Fevol I created a new repo where we can test the build
https://github.com/mnaoumov/obsidian-typings-build-test
I gave you the write permissions, so we can work on this problem more efficiently

Any progress on this?

@Fevol Please see my replies inline

@mnaoumov, @4Source Apologies for the delay. I have some final notes on this PR, then it is good to merge for me:
Questions

While everything now functions properly on my set-up with moduleResolution: bundler, I have not been able to get moduleResolution: NodeNext to work at all. Does this work on your end, or is this option not necessary?

Please loot at my comment https://github.com/Fevol/obsidian-typings/pull/65#issuecomment-2147877581
I created a repo for you and me to identify all the migration pains.
Please create there an example where "moduleResolution": "bundler" is working and "moduleResolution": "NodeNext" doesn't. I will be more than happy to get it fixed.

Similarly, does the configuration with "moduleResolution": "bundler" or types: ... work in your IDE's/set-ups?

I never tested "moduleResolution": "bundler" setting and I think that supporting "moduleResolution": "NodeNext" is better because it is stricter.

Potential Changes
Allowing legacy types importing
Instead of exclusively using exports in package.json to expose the types in the library:
{
    "name": "obsidian-typings",
    "exports": {
        ".": "./lib/types.d.ts",
        "./implementations.js": "./lib/implementations.ts"
    },
}

It might be interesting to also include a types field to allow for people with a TypeScript version lower than 5 to still use the library, as this is still the default in the sample plugin:
{
    "...": "...",
    "types": "./lib/types.d.ts",
}

This also makes the migration completely painless (save for having to change a few imports).

Sure, let's add types as well.

However, while it does seem to compile without issue, my IDE's language server seems to only sporadically be able to provide type hints for the added typings.

This could require you to restart TypeScript server, but this usually happens only one time.

Removing .js extension from imports
In my set-up, at least, having the .js extension included for the imports within the library itself, does not seem to make any difference. I did read somewhere that they are necessary when using NodeNext resolution, so if it is not possible to remove then, that's completely fine.

Having extensions is mandatory for NodeNext module resolution (to be precise, starting from Node16), so I strongly recommend we keep it that way for future compatibility. I already gave on the idea to keep .ts extensions and have to switch to the non-existing .js ones, but unfortunately we have to do it to support more client configurations.

Migration Guide
For me, it is important that the upgrade to the new version is as smooth as possible. I tried noting down the most important pitfalls below, is there anything I'm missing or anything that should be changed?
Minimal changes
Migrating to the new version (v2.0.0) will require at minimum the following changes (if types: ... is not specified):

We don't have reasons not to specify types.

typescript needs to be updated to 5.0.0 or higher, the sample plugin currently only specifies 4.7.4, so it is highely likely that you need to upgrade (this can be easily done by running npm install typescript@latest)

I will investigate if this is indeed required.

tsconfig.json needs to be updated to have moduleResolution: bundler instead of moduleResolution: node, this is now required in order to properly resolve the library.

I will investigate if this is indeed required.

Importing undocumented methods now requires you to import from obsidian-typings, and not just obsidian. This is done in order to make it more apparent that you are making use of undocumented and possibly volatile API. See below for the full list of interfaces that should be imported as import { X } from "obsidian-typings instead of import { X } from "obsidian".

Full list of classes that need to be imported from obsidian-typings
AbstractSearchComponent
Account
AppMenuBarManager
AppVaultConfig
BaseEditor
CanvasConnection
CanvasLeaf
CanvasNode
CanvasView
ClipBoardManager
Commands
ConfigItem
CustomArrayDict
CustomCSS
DragManager
EditorSearchComponent
EditorSuggests
EmbedContext
EmbeddableConstructor
EmbeddedEditorView
EmbedRegistry
FileCacheEntry
FileEntry
FileExplorerLeaf
FileExplorerView
FileSuggest
FileSuggestManager
FileTreeItem
FoldInfo
FoldManager
FootnoteCache
GlobalSearchLeaf
HotkeyManager
HotkeysSettingTab
HoverLinkEvent
IFramedMarkdownEditor
ImportedAttachments
InfinityScroll
InternalPlugin
KeyScope
LeafEntry
LinkUpdate
LoadProgress
MarkdownBaseView
MarkdownScrollableEditView
MetadataEditor
MetadataEditorProperty
MetadataTypeManager
MetadataWidget
MobileNavbar
MobileToolbar
ObsidianDOM
ObsidianTouchEvent
Plugins
PluginUpdateManifest
PositionedReference
PropertyEntryData
PropertyInfo
PropertyRenderContext
PropertyWidget
PropertyWidgetType
ReadViewRenderer
RecentFileTracker
RendererSection
Runnable
SearchCursor
SerializedWorkspace
StateHistory
SuggestionContainer
TableCell
TableCellEditor
TableEditor
ThemeManifest
Token
Tree
TreeItem
TreeNode
ViewRegistry
WeakMapWrapper
WidgetEditorView
WindowSelection

Extending Plugins interface with your own plugin
If you used to have the code below for registering your plugin to the app.plugins object:
import { Plugin } from "obsidian";
declare module "obsidian" {
	interface Plugins {
		plugins: Record<string, Plugin> & {
			"your-plugin": YourPlugin;
		};
	}
}

You should instead use:
import { Plugins as PluginsInterface } from "obsidian-typings";
declare module "obsidian" {
	export interface Plugins extends PluginsInterface {
		plugins: PluginsInterface["plugins"] & {
			"your-plugin": YourPlugin;
		};
	}
}

I disagree with your suggestion either. I think this is the way to go: https://github.com/mnaoumov/obsidian-typings-build-test/blob/master/project1/extensions.d.ts

Importing from /implementations
If you want to import from implementations (which contain methods such as createTFile, createTFolder, CustomArrayDict and InternalPluginName):
Method 1. If obsidian-typings was installed using an alias (i.e. package is installed in @types/obsidian-typings), you must alias the implementations separately within your tsconfig.json (baseUrl should also be set):

Actually baseUrl SHOULD NOT be set, it is a bad confusing thing, because it breaks the relative paths and auto-complete. I would strongly advise to remove it instead.

{
  "compilerOptions": {
    "baseUrl": ".",

Remove it

"paths": {
  "obsidian-typings/implementations": [
    "../node_modules/@types/obsidian-typings/lib/implementations"

Remove leading dots: node_modules/@types/obsidian-typings/lib/implementations

  ]

}
}

Then the methods can be imported as:

```ts
import { InternalPluginName } from "obsidian-typings/implementations";

console.log(InternalPluginName.FileExplorer);

Method 2. (NOTE: I have not been able to get this to work myself) You can also import directly from the module using:
import { InternalPluginName } from<EMAIL_ADDRESS>

That's unlikely going to work with NodeNext (Node16+). We should respect the encapsulation of the package

console.log(InternalPluginName.FileExplorer);

Thanks for the quick response and many great pointers!

Please loot at my comment https://github.com/Fevol/obsidian-typings/pull/65#issuecomment-2147877581

I created a repo for you and me to identify all the migration pains.

Please create there an example where "moduleResolution": "bundler" is working and "moduleResolution": "NodeNext" doesn't. I will be more than happy to get it fixed.

Apologies, I should have clarified a bit more: it is not that NodeNext does not work for me, but that it requires an unnecessary amount of rewrites (imports breaking, having to add the extension everywhere for relative imports, etc.), that I gave up after trying for a hour. NodeNext did work for me in the test repository, but I got confused with something else probably.

This could require you to restart TypeScript server, but this usually happens only one time.

Yeah, that probably was the reason why it suddenly worked.

Having extensions is mandatory for NodeNext module resolution (to be precise, starting from Node16), so I strongly recommend we keep it that way for future compatibility. I already gave on the idea to keep .ts extensions and have to switch to the non-existing .js ones, but unfortunately we have to do it to support more client configurations.

That's absolutely fine for me then, making it as compatible as possible is the ideal situation, of course. I mainly suggested it because I didn't know that there are actually plugins that make use of NodeNext, I thought most were on ESNext or node. Thanks for pointing this out to me!

I will investigate if this is indeed required.

Since the types field is added, no changes should have to be made to already existing repositories. Specifying bundler and upgrading to TS5 is only necessary if you want to have /implementations import, AFAICS.

I disagree with your suggestion either. I think this is the way to go: https://github.com/mnaoumov/obsidian-typings-build-test/blob/master/project1/extensions.d.ts

I did try this, but sadly it did not work for me. I think either the declaration should be in its own file, or it is an issue with Esbuild, I haven't been able to confirm either way. The snippet above is the only one that worked for me.

Actually baseUrl SHOULD NOT be set, it is a bad confusing thing, because it breaks the relative paths and auto-complete. I would strongly advise to remove it instead.

You are right, my bad! I have the baseUrl specified for my commentator plugin, and I haphazardly copied it over. The path should be "./node_modules/@types/obsidian-typings/lib/implementations" however, otherwise you would get errors about: Non-relative paths are not allowed when 'baseUrl' is not set. Did you forget a leading './'?.

Thanks for the quick response and many great pointers!

Please loot at my comment #65 (comment)

I created a repo for you and me to identify all the migration pains.

Please create there an example where "moduleResolution": "bundler" is working and "moduleResolution": "NodeNext" doesn't. I will be more than happy to get it fixed.

Apologies, I should have clarified a bit more: it is not that NodeNext does not work for me, but that it requires an unnecessary amount of rewrites (imports breaking, having to add the extension everywhere for relative imports, etc.), that I gave up after trying for a hour. NodeNext did work for me in the test repository, but I got confused with something else probably.

In my opinion, rewriting to NodeNext is not unnecessary, it is getting rid of legacy code to make it more portable and future-proof.
But I realize we need to support all possible client configurations. So making sure it works in node and in bundler mode is the must. I am working on it.

This could require you to restart TypeScript server, but this usually happens only one time.

Yeah, that probably was the reason why it suddenly worked.

Having extensions is mandatory for NodeNext module resolution (to be precise, starting from Node16), so I strongly recommend we keep it that way for future compatibility. I already gave on the idea to keep .ts extensions and have to switch to the non-existing .js ones, but unfortunately we have to do it to support more client configurations.

That's absolutely fine for me then, making it as compatible as possible is the ideal situation, of course. I mainly suggested it because I didn't know that there are actually plugins that make use of NodeNext, I thought most were on ESNext or node. Thanks for pointing this out to me!

Well, at least all my plugins are on NodeNext. I didn't do the research to get the stats :)

I will investigate if this is indeed required.

Since the types field is added, no changes should have to be made to already existing repositories. Specifying bundler and upgrading to TS5 is only necessary if you want to have /implementations import, AFAICS.

Testing this theory now.

I disagree with your suggestion either. I think this is the way to go: https://github.com/mnaoumov/obsidian-typings-build-test/blob/master/project1/extensions.d.ts

I did try this, but sadly it did not work for me. I think either the declaration should be in its own file, or it is an issue with Esbuild, I haven't been able to confirm either way. The snippet above is the only one that worked for me.

Yes, the declaration has to be in its own .d.ts file. But please use our testing repository to provide an example that didn't work for you.

Actually baseUrl SHOULD NOT be set, it is a bad confusing thing, because it breaks the relative paths and auto-complete. I would strongly advise to remove it instead.

You are right, my bad! I have the baseUrl specified for my commentator plugin, and I haphazardly copied it over. The path should be "./node_modules/@types/obsidian-typings/lib/implementations" however, otherwise you would get errors about: Non-relative paths are not allowed when 'baseUrl' is not set. Did you forget a leading './'?.

Here is my bad, actually, I am the one who forgot the leading ./?

Yes, the declaration has to be in its own .d.ts file. But please use our testing repository to provide an example that didn't work for you.

I pushed an example (copy of project1) where I showcase the issue. I misread the error in my original repository, it is not that the declaration file wasn't working properly, but it's the type of the plugin being wrong. My method (method 2) does work for this purpose.
(See: https://github.com/mnaoumov/obsidian-typings-build-test/tree/master/extension-test)

@Fevol I have to apologize. My method was faulty and I didn't do the enough testing
It's always a good idea to ad "skipLibCheck": false to actually test faulty .d.ts files
I did that in my repository and discovered the issue.
While technically your solution works, it adds the undesired confusion, because you declare the interface in obsidian module where it doesn't belong.
declare module "obsidian" {
  interface Plugins {
    plugins: Record<string, Plugin> & {
      commentator: CommentatorPlugin;
    }
  }
}

Unfortunately, we cannot just move the declaration to obsidian-typings module, because we will get a compile error.
Subsequent property declarations must have the same type.  Property 'plugins' must be of type 'Record<string, Plugin>', but here has type 'Record<string, Plugin> & { commentator: CommentatorPlugin; }'.ts(2717)

I came up with another more robust solution, which I am going to push in a bit

@Fevol I came up with the following solution: https://github.com/mnaoumov/obsidian-typings-build-test/blob/master/extension-test/extensions.d.ts
import CommentatorPlugin from "./main.ts";

declare module "obsidian-typings" {
  interface PluginsPluginsRecord {
    commentator: CommentatorPlugin
  }
}

Here the intent is clear, we put it into obsidian-typings module and don't pollute into the obsidian module.
Unfortunately we couldn't just augment Record<string, Plugin> due to TS2717 compilation error.
So I came up with the solution where we replace Record<K,V> types with corresponding interfaces that we can now augment.
I extracted all record types from all places for consistency purposes, knowing that the most likely the most of them will never be augmented, but the consistency comes with its trade-offs.

@Fevol I wrote build scripts to bundle typings and implementations into CommonJS format, so more clients can just use it.
Also added MIGRATION.md describing different gotchas.

This is fantastic work, thank you so much! Tested this out on a new project, almost everything works out of the box.
I only noticed one regression, aliasing /implementations does not seem to work anymore with the cjs format - or I am doing something completely wrong.
Other than that, this PR (and all the others) are ready to merge for me.

@Fevol did you read the README.md? There I show how to get implementations working for legacy scenario which is the case of obsidian-sample-plugin

Yeah, I did try the methods listed in the README, neither worked with the bundler/legacy TS set-up.

Tested everything again from scratch with the sample plugin, still a module resolution error for obsidian/implementations. Does the process work on your end, or do you notice a mistake below?

Specifically I did:

Clone sample plugin
Copy build of obsidian-typings containing only dist and package.json to @types/obsidian-typings
Update tsconfig.json with:

{
	"compilerOptions": {
		"types": [
			"obsidian-typings"
		],
		"paths": {
			"obsidian-typings/implementations": [
<EMAIL_ADDRESS>			]
		}
        }
}

Add test lines for implementations import in main.ts

import { InternalPluginName } from "obsidian-typings/implementations";

console.log(InternalPluginName.FileExplorer)

Alright, I did manage to solve it by tweaking the ESBuild configuration, but I am not sure whether I like it.
// esbuild.config.mjs
const context = await esbuild.context({
	// ...
	alias: {
		"obsidian-typings/implementations"<EMAIL_ADDRESS>	},
	// ...
});

What do you think? Since implementations is not an essential part of the obsidian-typings package, I am fine with an admittedly ugly solution like this, otherwise I feel like we'd be stuck for a while trying to find another way to solve this.

@Fevol
I made the following end-to-end scenario working
cd path/to/new/dir
git clone https://github.com/obsidianmd/obsidian-sample-plugin
cd obsidian-sample-plugin
npm install @types/obsidian-typings@path/to/obsidian-typings/root/with/compiled/dist --save-dev
# modify tsconfig.json
# modify main.ts
npm install
npm run build

tsconfig.json changes (I will update README.md for the changes required)
{
  "compilerOptions": {
    ...
    "paths": {
      "obsidian-typings/implementations": [
<EMAIL_ADDRESS><EMAIL_ADDRESS>      ]
  }
}

main.ts changes:
import { InternalPluginName } from "obsidian-typings/implementations";
console.log(InternalPluginName.FileExplorer)

Oh that is much better, this works for me without issue. I really should've realized that the only difference with the previous version is that the .ts was compiled into two separate files, so obviously only aliasing one of them wouldn't work. 😅
Alright, I'll merge the PR's now (unless you still have something to add?). Then I'll update the README with this new correct version.

@Fevol hold with merges. I want to try a better idea to solve the style-mod nightmare

@Fevol honestly I don't know why are you still into @types/obsidian-typings approach. I removed the recommended label from this case in README.md (and put to the one that actually should be recommended)

The main reason is that I use the set-up in my other plugins, so I know for sure that the new changes will also work on my (and other people's) repositories. Plus, I didn't know that installing under @types/ isn't necessary (anymore?) (#10, #13).
Either way, if it really has no use anymore, then I am fine with the approach being entirely removed.

@Fevol I made a final fix for style-mod nightmare which doesn't require anything from the library users. Now you can merge the PR. I will also go through all other PRs to ensure there are no merge conflicts

Great! Thank you again for all your work on this massive PR.


Added An Interactive React Playground

Co-authored by: Eric Hellman<EMAIL_ADDRESS>What does this PR do?
Add resource(s)
For resources
Description
Added An Interactive Playground for React
Why is this valuable (or not)?
Yes
How do we know it's really free?
Doesn't charge subscription
For book lists, is it a book? For course lists, is it a course? etc.
It is a playground
Checklist:

[x] Read our contributing guidelines.
[x] Search for duplicates.
[x] Include author(s) and platform where appropriate.
[x] Put lists in alphabetical order, correct spacing.
[x] Add needed indications (PDF, access notes, under construction).
[x] Used an informative name for this pull request.

Follow-up

Check the status of GitHub Actions and resolve any reported warnings!

duplicate

@eshellman This is not a duplicate PR this PR has an Interactive playground for react on CodePen the other one was of PlayCode Kindly check that out.


Development setup issue

Hi! I have been trying to set up this project locally, however I'm not sure how to download the notebooks. I have added github API key in config/dev.secret.exs file but now sure what to do next?
Any help is appreciated. Thanks!

Hi Aayush!
Do you mean to download notebooks from GitHub? If so, have a look at
RecentNotebooksWorker.
Yet, to run most of the application locally you can use a the seed file.
When you run “mix ecto.setup” it also loads some example notebooks in your
database.
Does this answer your question?
On Mon, 10 Jul 2023 at 08:38, Aayush Sahu @.***> wrote:

Hi! I have been trying to set up this project locally, however I'm not
sure how to download the notebooks. I have added github API key in
config/dev.secret.exs file but now sure what to do next?
Any help is appreciated. Thanks!
—
Reply to this email directly, view it on GitHub
https://github.com/notesclub/notesclub/issues/165, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAACJISFKEF4SKQ7BRBICILXPOPOFANCNFSM6AAAAAA2ECGXXQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Yet, to run most of the application locally you can use a the seed file.
When you run “mix ecto.setup” it also loads some example notebooks in your
database.

Tried this however I'm not seeing any entry on the homepage. It shows there are 7 notebooks though.

I just fixed the seed files.
Please do a git pull from master and run mix ecto.drop and mix ecto.setup and it should work now.
Btw, your PR was great and it is in production now, thanks!! 🚀

@aayushmau5 I just fixed the seed files.
Please do a git pull from master and run mix ecto.drop and mix ecto.setup and it should work now.
Btw, your PR was great and it is in production now, thanks!! 🚀

Just tried it. It's working as intended. Thanks for the quick fix!


[Bug - Partner Center] "Customer contact website" not accepting subdomains

Describe the bug
When entering a URL which has a subdomain, it is rejected in the partner center dashboard.
To Reproduce
Steps to reproduce the behavior:

Go to https://partner.microsoft.com/en-us/dashboard/account/v3/organization/legalinfo
Click on Contact Info
Edit Contact Info
Enter a URL with a subdomain
See error

Expected behavior
The validator should accept the URL. Seems the https: detection validator has some issues.
Screenshots

Desktop (please complete the following information):
n/a

@ManikanthMSFT Let me know if you need any more info. Seems in general the whole form seems broken in Firefox as well.

It now states the employer verification failed without specifying why and how to fix this.


Remove inline git revert confirmation alert (Issue #43625)

Remove inline git revert confirmation alert (Issue #43625)

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: NahomAgidew sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


spring-cloud-dataflow vs spring cloud-function

Is the only difference the granularity (microservice >data flow > task>function) of the deployment unit/ business logic boxed?
Please help to find out what will stick together, what may be dropped in favour or just melts together of this two projects where i see so much coverage in patterns an functionality,
> https://github.com/spring-cloud/spring-cloud-function  <>  https://github.com/spring-cloud/spring-cloud-dataflow
> spring cloud-function-task  <> spring-cloud-task
> spring cloud-function-web   <>  spring-cloud-web
> spring-cloud-function-stream   <> spring-cloud-stream
> spring-cloud-function-deployer <> Spring Cloud Skipper -> Spring-cloud-deployer(cloudfoundry,kuberntes, yarn,mesos)
> spring-cloud-function-registry-service <> spring-cloud-dataflow-registry
> @FunctionScan <> @EnableTask
> @FunctionEntry <>

While dataflow already has support for Kubernetes to scale out running processes i don't undertstand how spring-cloud-function-deployer will solve that stateful process managment of function instances at high scale and on which provided XaaS.
Tx for clarifying differences, commonalities and common roadmap of this two projects.

SpringCloudFunction itself does not offer features  to compose data flow streams, but Spring cloud data flow  does.
Having the SPCF adapter for calling in SpringCloud DataFlow's allows me to deploy and excute SPCFunctions controll from DaFlowServer.
Currently DataFlowServer  allows me to deploy on Kuberntes, Cloudfoundry & Openshift
Iss there also an approach to deploy on SpringCloudFunctions Adapatered FaaS platforms like IBM OpenWhisk, Google, Azure, AWS Lambda ans the use this in a composed data flow ?
If functions in all this FaaS will published via OpenServiceBroker as catalogue, i could register them automatically in SpringClouddataFlow and use the functions in my data flow stream compositions.

Additional I would like to know what riff integration is planned or how spring cloud data flow relates to Pivotals FaaS Plattform Riff

In short Data Flow orchestrates Spring Cloud Stream applications over messaging middleware of your choice (Rabbit, Kafka etc). As of now Spring Cloud Stream is fully integrated with Spring Cloud Function by providing an alternative programming model. So, to compose data flow from individual functions is no different then compose data flow from any other spring cloud stream app.

Registration in  DataFlowServer of  producer/consumer as stream app (spring cloud stream) and function (spring cloud function) is needed, so this apps can be downloaded, used for stream/pipe/dataflow layouts and afterwards to be shipped/deployed on Kubernetes or PCF (or local for developing).
What dataflow server does not support is to register Azure/AWS or Google Functions which are already deployed on their clouds plattform and to use them as producer/consumer in your dataflow stream.
Besides a FaaS platform like project Eirini (proceeded from RIF) besides native Kubernetes as deployment target would be a cloud native option.

I am going to close this as stale and if anything the discussion is more about data-flow hence out of scope of SCF. If you have more specific suggestion/request, please open a new issue.


Shader fails to initialize uniform variable on linux

Specifically Ubuntu (unknown version), Firefox, GTX 980.
Details here: https://github.com/iTwin/viewer/issues/172

Duplicate of #3737


Output to stdout, and pipe, rather than overwrite

npx syzer -o > package.json

This makes it easy to edit programmatically with jq, or manually.
npx syzer, without -u, is not easy for grepping
PNPM does support package.yaml and package.json5

Also, piping in would also be beneficial, because of jq as well.
cat package.json | jq '.dependencies' | npx syzer

@patarapolw Agreed! Initially when I first created this tool, I did not have much knowledge on how things work in nodejs but still I didn't the like the exisiting tools that does this job so just tried to build this quick module that does the job for me personally. Now looking back at the project I see that the peoject can be improved in various ways. I tried to write code for every little thing when there are many utlily modules that can be used here.
I didn't thought anyone would actually use it so was not planning to update it , now I see that it would be good time to update the project.
In the meantime, PRs are welcome for this issue

I implemented my thought (for another cli app) here. It will took a while to port to syzer.


Type 'UnEnumerate' does not satisfy the constraint 'object'.

Bug description
When trying to compile my typescript I get these errors:
node_modules/.prisma/client/index.d.ts:276:64 - error TS2344: Type 'UnEnumerate<TK>' does not satisfy the constraint 'object'.
  Type 'unknown' is not assignable to type 'object'.

276       ? GetHavingFields<UnEnumerate<TK> extends object ? Merge<UnEnumerate<TK>> : never>
                                                                   ~~~~~~~~~~~~~~~

node_modules/.prisma/client/index.d.ts:785:66 - error TS2344: Type 'UnEnumerate<TK>' does not satisfy the constraint 'object'.
  Type 'unknown' is not assignable to type 'object'.

785         ? GetHavingFields<UnEnumerate<TK> extends object ? Merge<UnEnumerate<TK>> : never>
                                                                     ~~~~~~~~~~~~~~~

Found 2 errors.

How to reproduce

Compile app with tsc

Expected behavior
It should compile the app
Prisma information
@prisma/client 2.14.0
Environment & setup

OS: MacOS Big Sur
Database: Postgres
Node.js version: 14.1.0
Prisma version: 2.14.0

Don't know what happened but my code is now working...closing.

Don't know what happened but my code is now working...closing.

Just encountered the same issue in the Prisma Public Slack and the problem was that the global typescript dependency was too old.
Check the output of tsc -v for the version.
Update your local or / and global typescript version to >4.1 or latest.
Because 2.14 requires typescript >4.1
https://github.com/prisma/prisma/releases/tag/2.14.0

Just encountered the same issue in the Prisma Public Slack and the problem was that the global typescript dependency was too old.
Check the output of tsc -v for the version.
Update your local or / and global typescript version to >4.1 or latest.
Because 2.14 requires typescript >4.1
https://github.com/prisma/prisma/releases/tag/2.14.0

@Jolg42 Thanks for the tip!

@Jolg42 Thanks for the tip!

Note: This is where we keep the requirements up-to-date https://www.prisma.io/docs/reference/system-requirements/


Twitter Automation script.

I want to contribute by adding Twitter automation python script. Kindly assign this issue to me. Thankyou.

Added. Thanks


SystemJS and Angular modules - Looking for the right design pattern

Edgar
This is the same pattern I found everywhere.
edgarSucre/ifrit/blob/master/app/main/main-module.ts#L2
But I want to load app first, then app.controllers, etc... with angular.module. What SystemJS does is to load async all imports then it continues executing app.js and so on.
What I did in molekilla/rutha-2016 was to add the canonical name (eg app.controllers.serviceName) as module name
https://github.com/molekilla/rutha-2016/blob/angular-training-promises/src/app/common/services/UserService.ts#L61-L62
I found some people avoiding SystemJS and others use some kind of Promise chain to load app module first then internal modules but really lost until further sample code from Angular.io, which I'm using as guide for Angular 1 + Typescript in rutha-2016
References
1 - http://blog.rangle.io/unittests/
2 - http://stackoverflow.com/questions/31081300/how-to-use-systemjs-to-bundle-angular-typescript-with-internal-modules
3 - Promise chain example http://stackoverflow.com/questions/32623175/lazy-loading-angular-module-with-es6-and-systemjs-import
4 - Lookfirst is using OCLazyLoad https://egghead.io/lessons/angularjs-simple-lazy-loaded-angular-module-syntax-with-oclazyload

So, you want to declare module dependencies in the component rather than the module, that way you don't need to import the file to the module, and imported just when needed?
That should work, I'll try that approach, and get back to you.

We need to discuss this further. I'd like to see a working example trying to load modules only when needed. With the classic approach all files are loaded because of the module dependency chain.

It means then lazy load is the way to use it (as found in the lookfirst
seed)
On Mon, 25 Jan 2016 at 08:41 Edgar<EMAIL_ADDRESS>wrote:

We need to discuss this further. I'd like to see a working example trying
to load modules only when needed. With the classic approach all files are
loaded because of the module dependency chain.
—
Reply to this email directly or view it on GitHub
https://github.com/edgarSucre/ifrit/issues/1#issuecomment-174512555.

I found this video for Ionic and Typescript: http://blog.ionic.io/ionic-and-typescript-part-3/
I liked how you could have a "module table" like the routes table you do for each section.
You could have
/app
/services
MyServiceA.ts
MyServiceB.ts
ServiceModule.ts
import {MyServiceA} from './MyServiceA'
angular.module('app.services', [])
.service('MyServiceA', MyServiceA)
// ...