Requests by external library from an iframe open new tabs/windows

Details

Are you nativefying a public website?: yes: https://www.freshworks.com/live-chat-software/ (issue is about any site that uses Freshchat widget)
Feature request? Nope
Full nativefier command used to build your app: nativefier "https://www.freshworks.com/live-chat-software/"
Version of Nativefier (run nativefier --version): v7.6.12
Version of node.js (run node --version): v10.15.3
OS: macOS Mojave

Explanation
First of all, I'm not 100 % sure of the exact issue here, but I have a straightforward replicable case. This ticket is not about Freshchat specifically, I think there's a more general root cause that could be addressed.
I have a web app that uses Freshchat, a support chat widget that can be embedded on web sites and apps. It works by loading a JS widget from their server. You can see details on their docs. As far as I can tell, this script loads an iframe and some more assets using multiple requests.
You can try it yourself with the following build:
npx nativefier "https://www.freshworks.com/live-chat-software/"

What happens is that the host website gets loaded (happens with any website with this library, this is just an example), but a new tab then opens in a browser with a blank page and the chat widget (I think this is the iframe content that would normally be injected into the page). The host page still has the iframe that the widget normally loads, but I think the requests that are in the iframe head open in a new tab. In the gif I also reload the page, and that opens another tab.
I tried adding freshchat.com to the internal-urls config param:
npx nativefier "https://www.freshworks.com/live-chat-software/" --internal-urls ".*(google|freshchat)\.com.*"

The result is the following:

So basically the same thing, but instead of opening a browser tab, a new window opens instead. This leads me to think that the internal-urls config is working (since it changes the behavior), but doesn't really achieve the goal here (which is that the iframe behavior should match freshworks.com, with no new windows opening).
Due to the way the library authors provide the library, it's not really easy to use this from NPM and only load it up conditionally, and I do want to use the widget on my product, so I'm looking for a solution that would make this work. A lot of web services work in a similar way so I wonder how often this happens with other external widgets.
I tried disabling the widget as a stopgap measure, since I have code where I can affect whether I initialise the widget or not, but the issue happens always if the script is even loaded, so I can't just leave the chat out based on a UA string: I would have to mess with loading the library conditionally just to disable the widget, so this issue can make it tricky to natify an app that uses widgets like this.
If anyone can point me in the right direction, would be happy to do more debugging, finding the solution and submitting a PR if needed.

Same issue, freshchat tries to open a new window with internal-urls. Now I no longer include it in the internal-urls and it opens a new tab in my default browser. Meaning that the chat-bubble is not shown in the application.

Has anybody found a workaround?

(I'll be happy to fund finding a workaround for Freshchat specifically, if it helps.)

Same issue here with Workast. They use the Freshchat widget which gets opened in a new tab or window depending on how you have --internal-urls set. Did a little digging by injecting a js file to log things. Freshchat is injected via a script which then inserts a div and iframe. Looks like the electron app treats the iframe as a second window. Since the injected js file isn't read until after the dom is completely loaded there's no opportunity to just remove the included script via something like:
document.querySelector("script[src*='freshchat']").remove()
If there was an option to inject a script that gets injected at the start of dom rendering that would be a workaround but ideally it would simply render iframes internally, not in a secondary window.


Closed Caption button does not appear in macOS.

The cc button (used to turn closed captions on/off) appears when running IPTVnator in Windows 10 and Linux, however it does not appear when running IPTVnator in macOS.

It does appear! It was user error. I forgot to select the "Show subtitles" option.


Webpack errors

Hello!
Having errors when trying to use npm package in Webpack build.
Module not found: Error: Can't resolve 'net' in '***/node_modules/forever-agent'
 @ ./~/forever-agent/index.js 6:10-24
 @ ./~/request/request.js
 @ ./~/request/index.js
 @ ./~/woocommerce-api/index.js
 @ ./assets/scripts/bootstrap.js
 @ ./assets/scripts/main.js
ERROR in ./~/forever-agent/index.js

Also Module not found and can't resolve 'tls' and 'fs'
There is something I've missed?

Maybe there is way to use WooCommerce with official WP API javascript client - models and collections?

yeah also having this issue with WC-API client and webpack.

@emilsgulbis fell free to submit a Pull Request.

Hi,
Has anyone made any progress on this issue?

+1 have this problem too ....

Here is how I solved it.
npm i --save request &&  npm i --save-dev json-loader

add below config to your webpack
  node: {
    console: true,
    fs: 'empty',
    net: 'empty',
    tls: 'empty',
  },

Ref
link

@ruucm
I had same issue - that helped me. Thanks!

It should be possible with https://github.com/woocommerce/woocommerce-rest-api-js-lib


fix for auto pause bug in tutorial

However is this fix required after Chris's fix

closed in favor of @PhilPJL broader fix.


Problems using both redux and react-router v4

I'm using both redux and react-router v4 and I've run into a problem: I get the redraw-on-change issue mentioned in the docs, and I can't add the data-transition-id property to the router setup:
            <Provider store={this.state.store}>
                <Router>
                    <PageTransition>
                        <Switch location={this.props.location}>
                            <Route exact path="/ukelonn/" component={Home} />
                            <Route path="/ukelonn/login" component={Login} />
                            <Route path="/ukelonn/user" component={User} />
                            <Route path="/ukelonn/performedjobs" component={PerformedJobs} />
                            <Route path="/ukelonn/performedpayments" component={PerformedPayments} />
                            <Route path="/ukelonn/admin" component={Admin} />
                        </Switch>
                    </PageTransition>
                </Router>
            </Provider>

I have tried the following, without success:

Adding 'data-transition-id': 'some-page' to the default props argument but got the syntax error "Invalid left-hand side in object destructuring pattern"
Adding data-transition-id="some-page" to the <Route> elements in <Switch>
Adding data-transition-id="some-page" to the top-most <div> of the component
Adding 'data-transition-id': 'some-page' to the defaultProps of the components

Hello, thank you for reporting this.
I am not sure if the lib can work with react-router 4 when combined with redux, but if you could create an example on https://codesandbox.io to reproduce the problem, I can take a look and see what when wrong.

This illustrates the problem: https://codesandbox.io/s/zlpm9wp874
Start typing in the username field of the Login window and the component starts redrawing.

I tried to run the example now to try to remember what this issues was about.  Unfortunately the Sandbox example won't run and the error message(s) don't make sense.
The example was working when I created it.
The error seems to be on the "." following ReactDOM in
ReactDOM.render(<App store={store} />, rootElement);

And the error messages are:
PageTransition.componentDidMount
https://zlpm9wp874.codesandbox.io/node_modules/react-router-page-transition/lib/PageTransition.js:85:15
commitLifeCycles
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:9784:26
commitAllLifeCycles
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:11455:9
HTMLUnknownElement.callCallback
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:100:14
Object.invokeGuardedCallbackDev
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:138:16
invokeGuardedCallback
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:187:29
commitRoot
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:11594:9
completeRoot
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:12502:36
performWorkOnRoot
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:12452:11
performWork
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:12370:9
performSyncWork
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:12347:5
requestWork
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:12247:7
scheduleWorkImpl
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:12122:13
scheduleWork
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:12082:12
scheduleRootUpdate
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:12710:5
updateContainerAtExpirationTime
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:12738:12
Object.updateContainer
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:12765:14
ReactRoot.render
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:16069:15
eval
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:16488:14
Object.unbatchedUpdates
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:12557:12
legacyRenderSubtreeIntoContainer
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:16484:17
Object.render
https://zlpm9wp874.codesandbox.io/node_modules/react-dom/cjs/react-dom.development.js:16543:12


Layouts

Feature description
On top of the current component API, a layout system should be implemented. This will be waiting on #12, #83, and #44.
Feature example API
from view import layout, page, h1, new_app

app = new_app()

@app.layout  # or @layout, which will be handled by the loader
async def lay(content: DOMNode | str):
    return page(content)

@app.get("/")
async def index():
    return h1("Hello, view.py!")

# OR

@index.layout
async def lay(content: DOMNode | str):
    return page(content)

app.run()

Anything else?
No response

This should also include some metadata utilities.


Added FT232R symbol and FT232RL device

This adds the FT232R symbol and the FT232RL device (with the SSOP28 package that it requires)

Thanks @MartijnBraam :smiley:
Here my comments after a quick review:

The new component category is very deep nested, I'd suggest to either move the new category one level up (as child of "Interface"), or use the "Drivers, Receivers, Transmitters" (without subcategory) instead. Or what do you think @dbrgn?
Symbol: Text elements for "{{NAME}}" and "{{VALUE}}" are missing. Name should be at the top left, and value at the bottom left of the symbol's outline.
Symbol: Generally for ICs we try to avoid placing pins at top and bottom of a symbol. We think schematics are more clean with pins only at left and right of IC symbols. Especially for GND it's often useful to place it 5.08mm below VCC because that way you can directly connect capacitors to them :)
Package: As it is a generic package, it would be good to move it into the base library. @dbrgn Could we generate that package with the parts generator?

@dbrgn Could we generate that package with the parts generator?

Yes, I can give it a try next week if I find time. We should be able to parametrize the SOIC generator for SSOP support. (I actually already started with generating TSSOP a while ago, but the branch is still sitting on my computer...)

I've updated the symbol so there's space for the caps and crystal you might need.

The previous symbol was made to closely match the symbol in the FTDI datasheet.

Thanks for the update!
Actually the new category should be moved to the LibrePCB Base library. Could you maybe open a pull request there? The category's directory can just be moved, no need for any adjustments.
Regarding the symbol:

Text elements should be left-aligned to the corners of the outline (corresponding library convention is work in progress, see draft here).
I would move the TEST pin 2.54mm to bottom, just because there is enough space available :)

Component and device look good so far :+1:

I've fixed the text elements and the test pin and moved the category.
Its probably a good idea to use a generated SSOP28 package instead of the one I've drawn since I'm not 100% sure everything aligns correctly and the silkscreen from the generated packages are nicer.

Assigning this to me, so I remember to finish the SOP generator :slightly_smiling_face:

TSSOP work ongoing at #28. Adding SSOP afterwards should be easy.

SSOP packages done: https://github.com/LibrePCB-Libraries/LibrePCB_Base.lplib/pull/35

Hi @MartijnBraam
SSOP footprints have finally(!) been added to the base library. We have re-used your UUIDs, so if you simply delete your own package and make sure to have a dependency on the base library, everything should work as intended.

I removed the SSOP28 package and added the base library as dependency, so we can merge this now.
Thanks again @MartijnBraam, and sorry for taking such a long time to get this merged :grin:


Add OPENMP package

Checklist

[X] Used a personal fork of the feedstock to propose changes
[X] Bumped the build number (if the version is unchanged)
[X] Reset the build number to 0 (if the version changed)
[X] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[X] Ensured the license file is being packaged.

Closes https://github.com/conda-forge/lammps-feedstock/issues/164

@conda-forge-admin, please rerender

While the openmp package was already included before, I guess it makes sense to be more explicit. In addition, this pull request rerenders the recipe which is always helpful to be compatible to other packages.

@conda-forge-admin, please rerender


Add ability to edit Front Door routing rules

It is currently possible to create and delete Front Door routing rules via the az cli.
The rationalization for this is that I am creating the Front Door routing rules using Terraform, which does not currently allow you to disable caching when you create them. To mitigate this, I was hoping to run the az cli after the fact to disable caching, but found that I cannot.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: bc41d7b5-ab21-fe9b-2f2e-93ac02e5af86
Version Independent ID: 67398425-8b96-f515-72af-22255ea1ae49
Content: az network front-door routing-rule
Content Source: latest/docs-ref-autogen/ext/front-door/network/front-door/routing-rule.yml
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

@bradcavanagh-ffs Hello. There is a argument --caching in the az network front-door routing-rule create command which you can set to Disabled. But we cannot update an existed command. You should delete the old one and create a new one.

@bradcavanagh-ffs There might be a tricky solution. 😄  You can try to create an existing routing rule. It should be able to update it.

@bradcavanagh-ffs Hello. Do you have more questions?

@bradcavanagh-ffs Hello. Do you have more questions?

Only an ETA for when I might be able to have an explicit 'edit' or 'modify' command. 'create' should really only be used to create a routing rule, in my opinion.


Fix order by multiple field with different orders and added Filter support.

This PR addresses the following:

Fixes an issue when ordering by multiple fields with different sort orders
Closes #293 with support for Filter.or and Filter.and

Wow thank you for tackling these big issues! It's a shame you didn't split it into two PRs. It'll take me quite a bit longer to review.

Yeah, I waited a week before adding the other. I needed them in my work so I had to merge them together.

I just published your code to https://pub.dev/packages/fake_cloud_firestore/changelog#310 and updated the README with the new features you implemented. Thanks again!

Thanks, I saw the changes you made and the published version.


Add Default Language Selection For Recorder

Describe the enhancement
OpenAI Whisper sometimes hallucinates on short audio clips and wrongly detects speaker's language. It's easy to add another setting to the Recorder tab where one can select or input the default language for speech recognition.

Great addition, I will be adding this - keeping this opened until it's implemented.

I think this is closely related to the enhancement request I made in issue #3 to have access to the Whisper prompt.
I don't know if the language setting is a different parameter but if we would be able to set the language and the Whisper prompt that would help us make full use of Whisper's capabilities via SS. Many thanks.

Hi @alexey-ezhikov, thanks for the suggestion! I’ve added the default language selection to the recorder settings, with English as the default option. This feature is available starting with the 0.7.0 update going live tonight. Additionally, there’s now more control over the transcription process, including fixing niche/personal vocabulary words, spellings, and post-processing. I’ll go ahead and close this issue. Let me know if you need anything else :)


No module named 'CycleGAN_TensorFlow

I install tensorflow
when I run command:python -m CycleGAN_TensorFlow.create_cyclegan_dataset --image_path_a=folder_a --image_path_b=folder_b --dataset_name="horse2zebra_train" --do_shuffle=0
error comes:
/usr/bin/python: Error while finding spec for 'CycleGAN_TensorFlow.create_cyclegan_dataset' (ImportError: No module named 'CycleGAN_TensorFlow')

Were you able to fix this? I have the same issue.

Fixed it. The solution was to rename the folder as CycleGAN_TensorFlow, as opposed to just cyclegan, which is the name of the repository upon cloning.

@devbhartra
I tried your solution I cloned then renamed the folder before launching the command but I have the same error 'no module named CycleGAN_TensorFlow'.


Issue with circular patterns showing up after orthographic projection

For a project I'm working on, I'm trying to project a GOES-16 image to an orthographic projection centred at the continental United States.  In a later stage,  I found these odd circular patterns appear in a result derived from an image I had reprojected to this orthographic projection. I have been able to trace this back to the projection, and can reproduce the patterns by computing the number of original GOES-16 pixels that are part of each pixel  in the final orthographic reproduction.
My question is as follows: Why is this? And if possible, how do I resolve it (besides choosing a different projection)?
I have included a (hopefully) working example below. Any help is much appreciated, and my apologies if this is not the correct place to ask questions like this.
import numpy as np
import cartopy.crs as ccrs
import pyproj
import pandas as pd
import matplotlib.pyplot as plt

# Extent in orthographic projection coordinates
EXTENT = [-2373970.2054802035, 3638399.906890716, -2388159.0372323524, 1620933.528091551]

# Orthographic projection
p_ortho = pyproj.Proj('+proj=ortho +ellps=GRS80 +lat_0=39.8283 +lon_0=-98.5795 +sweep=x +no_defs')

# GOES-16 nominal satellite height
h = 35786.0234375

# GOES-16 projection
proj_goes = pyproj.Proj(proj='geos', h=h*1000, lon_0=-75.2, sweep='x')

# GOES-16 scanning angles
x_goes = np.arange(-0.151844, 0.151844+5.5998564e-05, 5.5998564e-05)
y_goes = np.arange(0.151844, -0.151844-5.5998564e-05, -5.5998564e-05)

# Coordinates for lines of constant x and y scan angle
xx_goes, yy_goes = np.meshgrid(x_goes[::100], y_goes)
lon_x, lat_x = proj_goes(xx_goes*h*1000, yy_goes*h*1000, inverse=True)

xx_goes, yy_goes = np.meshgrid(x_goes, y_goes[::100])
lon_y, lat_y = proj_goes(xx_goes*h*1000, yy_goes*h*1000, inverse=True)

# Create x-y grid to reproject
xx_goes, yy_goes = np.meshgrid(x_goes, y_goes)

# Project scanning angles to corresponding longitude latitude
lon_goes, lat_goes = proj_goes(xx_goes*h*1000, yy_goes*h*1000, inverse=True)

# Filter for CONUS domain (roughly)
lon = lon_goes[(lon_goes > -136)*(lon_goes < -45)*(lat_goes>10)*(lat_goes <55)]
lat = lat_goes[(lon_goes > -136)*(lon_goes < -45)*(lat_goes>10)*(lat_goes <55)]

# Now project longitudes, latitudes to orthographic projection
xx_p, yy_p = p_ortho(lon, lat)

# Use dataframe for calculation
df = pd.DataFrame({'x': xx_p, 'y' : yy_p})

# Min and max coordinates in orthographic projection
[x_min, x_max, y_min, y_max] = EXTENT

# Number of bins
x_bins = 300
y_bins = 200

# Calculate bin size
x_size = (x_max-x_min)/x_bins
y_size = (y_max-y_min)/y_bins

# Calculate bin number for xx_p, yyp
df['x_bin'] = np.floor(((df['x'] - x_min)/x_size)).astype(int)
df['y_bin'] = np.floor(((df['y'] - y_min)/y_size)).astype(int)

# Filter because I was lazy in defining the CONUS domain (?)
df = df[(df.x_bin >= 0) & (df.x_bin <=x_bins-1) & (df.y_bin >= 0) & (df.y_bin <=y_bins-1)]

# Reshape results into 2D array for display
res = np.zeros((y_bins, x_bins))
grouped = df.groupby(['x_bin', 'y_bin']).count().reset_index()
res[y_bins-1-grouped.y_bin.values, grouped.x_bin.values] = grouped.x.values

# Show results
fig = plt.figure(figsize=(10, 5), dpi=300)
proj = ccrs.Orthographic(central_latitude=39.8283, central_longitude=-98.5795)
ax = fig.add_axes([0, 0, 1, 1], projection=proj)
ax.set_extent(EXTENT, proj)
ax.set_aspect('auto')
cf = ax.imshow(res, origin="upper", extent=EXTENT)

# Lines of constant scan angle
for i in range(lat_x.shape[1]):

    ax.plot(lon_x[:,i], lat_x[:,i], linewidth=0.25, c='w', transform=ccrs.PlateCarree())

    ax.plot(lon_y[i,:], lat_y[i,:], linewidth=0.25, c='w', transform=ccrs.PlateCarree())

ax.coastlines()
fig.colorbar(cf, label="Number of GOES-16 ABI pixels per 100 orthographic projection pixels")

Here is an issue comment that may be helpful: https://github.com/cf-convention/cf-conventions/issues/248#issuecomment-586350202
One thought I had was that using pyproj.Transformer might be helpful:

https://pyproj4.github.io/pyproj/stable/examples.html#transformations-from-crs-to-crs
https://pyproj4.github.io/pyproj/stable/gotchas.html#proj-not-a-generic-latitude-longitude-to-projection-converter

I would also recommend cross-posting this issue in a couple of places as there may be other insight to be gained:

https://gis.stackexchange.com/ (add pyproj & cartopy tags)
https://github.com/SciTools/cartopy (an issue and/or their gitter chat)
https://lists.osgeo.org/mailman/listinfo/proj/

Cross posted question for reference: https://gis.stackexchange.com/q/368351/144357


g.getmeta(...) seems to skip 15 minutes of the start

I'm not sure if this is intended behavior, but it seems g.getmeta(...) output in metashort skips the first 15 minutes of data.

EDIT at the end g.getmeta(...) are also seems to drop some samples at the end.

This is intentional to make aggregated data comparable in time between different recordings.
GGIR looks for the first integer of long windowsizes (second object windowsizes) in the hour and starts data aggregation at that time point.
For example, start recording A is at 10:01, and start recoridng B is at 10:09,
If long windowsize is 15 minutes the output for both will start at 10:15.
If long windowsize is 10 minutes the output for both will start at 10:10.
If long windowsize is 5 minutes the output for A will start at 10:05, while output for B will start at 10:10.
In this way it is also much easier to describe behaviour per day, because none of the epochs overlaps with midnight. This would be the case if you would simply start aggregating epochs relative to the start of the recording.


feat(Material Select): Support for readonly attribute in Material Select component

Feature Description
It should be possible to use a readonly property similar to have disabled is used with mat-select (Material Select component)
Use Case
When re-submitting a form where some select field should not be editable but resent. Property disabled will in this case simple remove selected value from form.
This is an example that show how it would be used and how it works now:
https://stackblitz.com/edit/angular-fj6kyz?file=src/app/select-overview-example.html

Duplicate of https://github.com/angular/components/issues/17743

I think that the title of #17743 is the same, but what it was actually asking for was inheriting the disabled state from the closest fieldset. I think that we can keep this open, but we'll have to do some investigation on whether we can make the accessibility work for this. We could use aria-readonly, but we'll have to check if it makes sense on a combobox.

This is still an issue today and i believe its very similar to how disable work the difference is essentially if the field is included in the this.form.getValue() which disabled i not but readonly should be.


Add align option for text inside buttons

Icons are cool but some of them may not be very obvious for some users.
I would like to add some text to remove the ambiguity of the buttons.
Sadly, if I add some text, the text is not centered on the buttons. Is there a way to align center the text inside the button?

Yes, you need to set canvas 'c.textAlign = "center" '
https://www.w3schools.com/tags/canvas_textalign.asp
Before the line which draws the text
Em sáb, 28 de ago de 2021 11:14, Patrice Robitaille <
@.***> escreveu:

Icons are cool but some of them may not be very obvious for some users.
I would like to add some text to remove the ambiguity of the buttons.
Sadly, if I add some text, the text is not centered on the buttons. Is
there a way to align center the text inside the button?
[image: image]
https://user-images.githubusercontent.com/2374739/131220753-32a030c0-21dd-4e6d-9d87-aecea4fe3a81.png
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/victorqribeiro/radialMenu/issues/7, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA5FEO7WJSS57S45TXCCMXTT7DVN5ANCNFSM5C7FHILQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Using logging.properties from classpath or from a file.

Signed-off-by: Tomas Langer<EMAIL_ADDRESS>Resolves #443

Rebased on latest master, as it fixes an intermittent issue that just happened.

@ljnelson could you please check if the latest changes are OK?


[WIP] NCBI Gene test

testing adding a link to https://www.ncbi.nlm.nih.gov/gene
Note: PR into #2.

Nice work @raynamharris! Only two small things needed to be done to get it to work - see #4.


Marketplace: Show what version of VS code an extension is for in the version history page

From @rchiodo
Our extension has this list currently:

Some of these work with insiders and some of these work with VS code. Users frequently try installing the latest version and don't realize why it doesn't work with their version of VS code.
Some indication of the version a vsix works with would be nice (or some way for us to put it into the version information).

is not that information readily available in extension manifest via engines: {"vscode": "..."} field, or can be easily extracted from "devDependencies": { "@types/vscode": "..." ...} that all extensions have. You just need to use that info and added to version history page.

The "Version History" at least needs the ability to select a code engine version. Jupyter version history is only listing versions for 1.58+, so trying to download a compatible version for 1.57.x for offline installation is impossible (linked to microsoft/vscode-jupyter#5582).

yeah, I agree that information is needed, especially for some of the "Preview" extensions that are published and work only with vscode insiders versions.

Also, the download API should be updated to accept code engine version. Is there an API which returns all the versions of a particular extension which support a particular vs code engine version?

This is especially important if for some reason I need to use an older version of vscode-jupyter.
I don't have the faintest about what version of VS Code older stable versions of vscode-jupyter is lock-stepped with.


Filter dashpages to show only available ones

Fixes #5295
The list of available dashpages in the Metrics UI is dynamic, depending on the selected resource.
A dashpage will only be shown if:

metrics are available for at least one chart, and
all required metrics are available
all required resources are available

Checklist

Is this feature complete?

[ ] Yes. Ready to ship.
[x] No. Follow-up changes expected. This is a feature branch.

Are you including unit tests for the changes and scenario tests if relevant?

[x] Yes
[ ] No

Did you add public API?

[ ] Yes

If yes, did you have an API Review for it?

[ ] Yes
[ ] No

Did you add <remarks /> and <code /> elements on your triple slash comments?

[ ] Yes
[ ] No

[x] No

Does the change make any security assumptions or guarantees?

[ ] Yes

If yes, have you done a threat model and had a security review?

[ ] Yes
[ ] No

[x] No

Does the change require an update in our Aspire docs?

[ ] Yes

Link to aspire-docs issue:

[x] No (though dashpages will be documented when the feature branch merges)

Microsoft Reviewers: Open in CodeFlow

/azp run

/azp run

/azp run

/azp run

/azp run


[MM-47931] a/b test for reduced onboarding task list item

Summary
This PR allows A/B testing for reducing onboarding task list item.
Ticket Link
https://mattermost.atlassian.net/browse/MM-47931
Related Pull Requests

Has server changes (https://github.com/mattermost/mattermost-server/pull/21571)

Screenshots

before/feature flag: off
after/feature flag: on

ADMIN USER

MEMBER

GUEST

Release Note
NONE

Due to a persistent error, spinwick would not take the latest master from the server. Created a new PR and will close this.


CVE5.0 it is bad pratice to hard code version numbers into tags...

CVSS record forat is:
        {
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ],
          "cvssV3_1": {
            "version": "3.1",
            "attackVector": "NETWORK",
            "attackComplexity": "LOW",
            "privilegesRequired": "LOW",
            "userInteraction": "NONE",
            "scope": "CHANGED",
            "confidentialityImpact": "LOW",
            "integrityImpact": "HIGH",
            "availabilityImpact": "NONE",
            "baseScore": 8.5,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:N"
          }
        },

This means that when the CVSS version changes to e.g. v3.2 the tag changes as well, meaning I have to update the code that renders CVEs records on https:csirt.divd.nl.
Having a version number as part of a tag is generally considered bad practice.
Is this is not the correct place to discuss this, should I discuss it elsewhere?

By "tags" if you meant the JSON key (eg. "cvssV3_1", "cvssV2_0", ..) I completely agree, and I argued against this format while JSON schema was being designed. IMHO it should be something "cvss" - thats it.
The version is anyway captured in the "version" field's value as "3.1", but I lost the argument.
IIRC mainly because when someone wants to provide both CVSS v2 and V3 scores at the same time, so the version numbers were hard coded in the field names.
If you think it is import to change this please raise this on the schema project https://github.com/CVEProject/cve-schema.

Rasied at: https://github.com/CVEProject/cve-schema/issues/163


QGIS User Group Wales

This is undoubtedly the wrong place, bu I have no idea of where to send new content.
Please can you promote the QGIS User Group – Wales on your ‘Upcoming user & development meetings’ section of the QGIS website?
The event will be held Cardiff Mercure Holland Hotel, on Tuesday 6th October. There are only 50 spaces available. More details can be found at qgis.eventbrite.co.uk.

@breconbeacons yes, will do it.
For later: either sent me or the community email list a message,
OR (depending how github savvy your are): clone QGIS-Website repository and edit this file:
https://github.com/qgis/QGIS-Website/blob/master/source/feeds/qugsnews.atom
and do a pull request

Thanks very much for updating the website and for the info.
Much appreciated.

done

Thank you ☺
Much appreciated.
From: Richard Duivenvoorde<EMAIL_ADDRESS>Sent: 15 June 2015 14:21
To: qgis/QGIS-Website
Cc: Shaun Lewis
Subject: Re: [QGIS-Website] QGIS User Group Wales (#262)
done
—
Reply to this email directly or view it on GitHubhttps://github.com/qgis/QGIS-Website/issues/262#issuecomment-112067261.
Peidiwch argraffu'r neges yma oni bai ei fod yn hollol angenrheidiol - ARBEDWCH YNNI a PHAPUR!/Please do not print this e-mail unless absolutely necessary - SAVE ENERGY and PAPER
Mae ganddom sawl ystafell i’w llogi ar gyfer cyfarfodydd, cynadleddau a hyfforddiant. Gallwn hefyd gynnig gweddarlledu cyfarfodydd, gwelwch http://www.beacons-npa.gov.uk/the-authority/hire-a-room am fanylion.
We have a range of rooms available to hire for meetings, conferences and training. We can also offer webcasting of meetings, see http://www.beacons-npa.gov.uk/the-authority/hire-a-room for details.
Croesewir gohebiaeth yn y Gymraeg a’r Saesneg/Correspondence welcomed in Welsh and English

Mae’r farn a fynegir gan anfonwr y neges hon yn un bersonol ac, heblaw a fynegir hynny yn hollol eglur, nid yw yn cynrhychioli barn Awdurdod Parc Cenedlaethol Bannau Brycheiniog. Bwriedir yr ebost yma a’i atodiadau ar gyfer y derbynnydd/derbynyddion yn unig ac all fod yn gyfrinachol. Os ydych wedi eu derbyn mewn camgymeriad peidiwch a chymeryd unrhyw weithred yn seiliedig arnynt na’i copïo na’u dangos i unrhyw un arall; rhowch wybod o’r camgymeriad i ni yn<EMAIL_ADDRESS>ac yna dilëwch bob copi.
Unless explicitly stated the views and opinions expressed by the sender of this message are those of the individual and do not represent the views and opinions of Brecon Beacons National Park Authority. This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please respond to<EMAIL_ADDRESS>to notify us of the error and delete all copies


Support for JupyterLab 4

I just upgraded my work server to JupyterLab 4 and saw that Codeium doesn't support it yet. It would be great to have this functionality.

Consolidating this into #9.


Make it easier to add banners when working on project pages

Maybe include banners as an inline option on project pages?

This is now done


[Spike] Azd and Starshot Integration

Spike to explore on the integration between Azd and Starshot.

I'm going to close this for now, until we have concrete asks to move forward with.


RFC: #[derive(SmartPointer)]

Use custom smart pointers with trait objects.
Rendered
Tracking issue: https://github.com/rust-lang/rust/issues/123430

Co-authored by @Darksonn and @Veykril
Thank you to @compiler-errors for the original idea

My main thought is that maybe this should just require repr(transparent), which simplifies a lot of the explanation of the requirements part.

My main thought is that maybe this should just require repr(transparent), which simplifies a lot of the explanation of the requirements part.

I don't think there should be a hard requirement that smart pointers be transparent. But since the requirements are very similar, it might make sense to incorporate the requirements by reference, for simplicity of documentation.

After doing a bit more research to get myself acquainted with the CoerceUnsized and DispatchFromDyn traits, I really don't think that it's a good idea to just bundle these both together as "smart pointer." Yes, all smart pointers will have these, but it's a false equivalence; having them does not make you a smart pointer.
What these traits really are about is ensuring proper variance, which is especially weird since variance is usually only exposed to programmers in Rust through weird mechanisms like PhantomData. Ultimately:

CoerceUnsized lets you declare a type as covariant, and varying the type this way makes it more general. For example, this lets you vary a mutable reference into an immutable reference or an array into a slice.
DispatchFromDyn lets you declare a type as contravariant, and varying the type this way makes it more specific. This would be the opposite, like varying a slice into an array or a trait object into a concrete type.

Smart pointers require both of these just by the nature of how references in Rust work in general: because autoderef lets us borrow things mostly automatically, we expect this automatic borrowing to happen even if a smart pointer is between us and our data. However, it's important to realise that this is just about variance and we only tie it specifically to smart pointers because unsized types in Rust today have to be used behind pointers.
If we allow unsized locals, whose RFC was accepted, now these types become even more just about variance. You should always be able to pass arrays into functions which accept unsized slices, return unsized trait objects by returning a concrete object, etc., etc.
Honestly, thinking of this more specifically as a way of managing variance, I do question whether the current method of manually implementing these traits is the right approach, and whether we should rely more on something like repr(transparent), as mentioned by @Lokathor. This falls closer to what currently is done for managing variance in other ways, via PhantomData.
Of course, we can't just use repr(transparent), for the following reasons:

Reference-counting necessitates adding extra stuff alongside your original data, and requiring repr(transparent) would forbid this.
The allocator API also requires extra stuff, assuming the allocator is nonempty, and that also messes with things.

Actually, the allocator API runs amok with this current proposal, too, since it would require that an allocator be zero-sized. If we reframe the proposal from the perspective of unsized types (treating smart pointers as implicitly always sized), this "single field" instead turns into "last field," like the current unsized requirements. I believe that zero-sized types are also not allowed to be after the unsized field of a struct, but we could probably amend this pretty easily.
Maybe we could have some kind of repr(variant) for smart pointers and repr(contravariant) for cells and those could be used instead, requiring that either:

The last field of these structs is something that is also repr(same-variant) in the same type parameter.
The last field of these structs is a value of that type parameter.

Basically ensuring that everything works as you'd expect.

A few footnotes:

I am aware that CoerceUnsized is specifically for references/pointers and that a pure impl<T: Unsize<U>> CoerceUnsized<U> for T does not exist, but I'm going to pretend that it does for the sake of simplicity here.
 I'm mostly operating on assumptions here.

@clarfonthey: A few things regarding your last comment--
It's not correct to call the relationship between [T; N] and [T] subtyping (which I know you're not doing explicitly, but you are kinda implicitly doing so by mentioning variance), and saying that CoerceUnsize and DispatchFromDyn are about variance is a bit misleading.
Their relationship is called unsizing in Rust, and is an explicit coercion operation inserted into the MIR and involves actually changing the type layout of pointer.
Also, Box<T> is covariant in its T parameter, but implements DispatchFromDyn, so I'm not certain what you mean by it enforcing contravariance in its argument.
DispatchFromDyn really is just a trait that instructs typecheck what's valid so that later codegen can peel off layers of a type to look for the "data" part to pass into the vtable method for, e.g., Rc<Self> or Box<Self>; it has slightly different requirements that try to (somewhat generally) capture what needs to happen when codegenning a dynamic call.[^1]

(disclaimer that i've been too busy to read the actual rfc yet, just wanted to clarify some stuff before people started also responding and a whole thread gets generated based off of false premises)

[^1]: the way that codegen actually works is why DispatchFromDyn for Box and Rc don't support custom allocators -- this could work, but it would need to piece back together the allocator on the receiver end.[^2]
[^2]: though, wow, the codegen for DispatchFromDyn is kind... interesting. I actually wonder why it doesn't just rip off the metadata from the ScalarPair and pass just the "sized" version of the data.... 🤔

The last-field limitation actually means nothing ABI-wise since the Rust layout allows reordering the fields

the Rust compiler is what chooses what order the fields are in, which also means the Rust compiler can always leave the unsizable field at the end, as I'm guessing it currently does. This means conversion from/to dyn Trait doesn't need to insert/remove the vtable in the middle and move everything after, and that conversion from dyn Trait back to the underlying type can just use a prefix of the struct, which in some cases may mean just changing pointer types.

@programmerjake

the Rust compiler is what chooses what order the fields are in, which also means the Rust compiler can always leave the unsizable field at the end, as I'm guessing it currently does.

My example code in https://github.com/rust-lang/rfcs/pull/3621#issuecomment-2092479531 already showed it does not. We are not talking about maybe-unsized struct tail here, but a pointer to a maybe-unsized type which can appear anywhere.
struct X<T: ?Sized> {
    extra: u16,
    tail: T,  // yes, this field is guaranteed to be at the end of X<T>
}

struct P<T: ?Sized> {
    extra: u16,
    ptr: *const T, // note that it is a pointer here, there is no guarantee about offset of `ptr` in P<T>
}

This means conversion from/to dyn Trait doesn't need to insert/remove the vtable in the middle and move everything after

Coercion from P<T> to P<dyn Trait> is already inserting a vtable in the middle of the struct (next to the ptr).

I don't think there should be a hard requirement that smart pointers be transparent.

We actually currently rely on them being the equivalent of transparent. The only reason DispatchFromDyn does not just check the repr is that we want it to be implemented on Box, and Box cannot be repr(transparent) because of the allocator -- but DispatchFromDyn is only implemented for Box<_, Global> which is effectively repr(transparent).
The way we call arbitrary-self receiver functions via vtables relies on repr(transparent) -- specifically, it relies on ABI compatibility. There's a subtle invariant here that all instances of repr(Rust) types that follow the repr(transparent) rules are indeed ABI-compatible to their one non-1-ZST field even if the repr(transparent) attribute is not present. I hope all our ABI adjustment logic ensures this invariant (and we have tests covering the basics), but this is easy to get wrong.

I don't think there should be a hard requirement that smart pointers be transparent.

We actually currently rely on them being the equivalent of transparent. The only reason DispatchFromDyn does not just check the repr is that we want it to be implemented on Box, and Box cannot be repr(transparent) because of the allocator -- but DispatchFromDyn is only implemented for Box<_, Global> which is effectively repr(transparent).
The way we call arbitrary-self receiver functions via vtables relies on repr(transparent) -- specifically, it relies on ABI compatibility. There's a subtle invariant here that all instances of repr(Rust) types that follow the repr(transparent) rules are indeed ABI-compatible to their one non-1-ZST field even if the repr(transparent) attribute is not present. I hope all our ABI adjustment logic ensures this invariant (and we have tests covering the basics), but this is easy to get wrong. This would be much easier if we could rely on repr(transparent)...

Is there any plan to make this work with allocators at all, or are we basically stuck with this design for the foreseeable future? Since as I mentioned, the current RFC proposal would also be unable to do anything with non-zero-sized allocators for reasons mentioned. I'd guess that kernel development would at best be dealing with ZSTs anyway since storing an extra pointer or something like it would be undesirable for performance reasons, but it's still a question that feels worth asking.
What I'd imagine would happen here is the fields for the allocator would always be after the pointee to ensure that you can still cast the pointer and have it Just Work, but that requires a bit of compiler help.

Extending DispatchFromDyn to be able to cover more cases (i.e., to handle types that are not just newtyped pointers) is a non-trivial topic on its own, I'd rather not derail this RFC by going there.

One question I have is about FFI smart pointers, which were one of the key use cases for arbitrary self types.
If I understand correctly, these smart pointers cannot easily be e.g. CppRef<dyn MyTrait> or Py<dyn MyTrait> because the pointee is always a thin pointer from FFI so there is no space for the dyn metadata.
It seems a little awkward to call this derive SmartPointer if an important category of smart pointers cannot implement it.
Is there perhaps a way where the FFI smart pointers could be made compatible with this? By having dyn metadata (manually?) placed in a second field, perhaps?

@davidhewitt You do have a point, but I also think you underestimate the extent to which something like CppRef could support this. I'm not so familiar with the CppRef type, but the kernel has an ARef<T> smart pointer where T is some C struct with refcounting built in.
pub struct ARef<T: AlwaysRefCounted> {
    ptr: NonNull<T>,
    _p: PhantomData<T>,
}

pub unsafe trait AlwaysRefCounted {
    fn inc_ref(&self);
    unsafe fn dec_ref(obj: NonNull<Self>);
}

Making this work with ARef<dyn MyTrait> probably requires MyTrait to be a sub-trait of AlwaysRefCounted, so AlwaysRefCounted must be object safe. It isn't right now because of the raw pointer argument, but it could be made object safe if we wrap NonNull in a #[derive(SmartPointer)] struct.
All that said, this isn't something the Linux Kernel needs right now. But I think it would work.

I see, I think you might also be able to do something like trait MyTraitRefCounted: MyTrait + AlwaysRefCounted when it's not possible to modify MyTrait directly.
For Py<T> in PyO3 we don't need a trait on T so we don't suffer the same problem. However the pointer we store is always NonNull<PyObject> hence my wondering about where to fit the metadata.

For Py<T> in PyO3 we don't need a trait on T so we don't suffer the same problem. However the pointer we store is always NonNull<PyObject> hence my wondering about where to fit the metadata.

I expect you can just store NonNull<T> but it's really always *mut PyObject in disguise, you'd always cast pointer types when creating or accessing the pointer.

I tried typing this up before on my phone but GitHub ate my message. -_-
Basically translating what I was proposing into a more concrete proposal. The tl;dr is that I think that instead of derive(SmartPointer), this should be repr(smart_pointer). The #[pointee] attribute remains the same. Going over a few of the details:

With repr, it's clearer that the layout of the type is constrained, whereas with a derive macro this could emit some weird errors. It also lets us rely a bit more heavily on repr(transparent) while technically not actually making the type repr(transparent), allowing for us to change the representation later.
If we go with repr, the situation on whether CoerceUnsized and DispatchFromDyn should be derived separately goes away. We just have a separate repr for each combination of the two, but for now, we don't need to offer the other two combinations (just CoerceUnsized or just DispatchFromDyn).
This also means that smart_pointer is a decent name for deriving both, since it seems pretty fair that only smart pointers would have both. It also avoids bikeshedding the name.

This also converts my nebulous and partially wrong analysis into an actionable proposal.

I went through the RFC and comments and I have a few thoughts.
On soundness with Pin
It seems to me that...

we should change the Pin requirements to be unsafe trait PinCoerceUnsized: CoerceUnsized -- based on prior thread discussion, I'm not sure if we know just what those constraints are, but it doesn't block this RFC
we can consider stabilizing derive(SmartPointer) without having resolved that, since you don't need it

...the only reason not to do this is if we want derive(SmartPointer) to require that you meet the pin contract -- i.e., we don't want to allow people in the future to have a "coercible pointer" that is not also pinnable. I generally think that we eventually want some simpler way to say "this is a true smart pointer" -- i.e., it is backed by a pointer, it is dynamic dispatch safe, supports pure deref, etc, all in one convenient package, but I think we don't know how to do that yet. So maybe it's fine to start with just the pieces and come back to it.
Zulip discussion here
On naming
On the topic of starting with just the pieces, I don't love the name derive(SmartPointer). It promises quite a lot but delivers quite a bit less. It seems to me that what this is really doing is saying "this is an unsizeable pointer". Perhaps a name like one of the following would be better

#[derive(std::ptr::UnsizeReferent)]
#[derive(std::ptr::UnsizePointee)]
#[derive(std::ptr::PointerUnsize)]
etc

...or perhaps in some module other than std::ptr (maybe even not from std, but just core? seems a bit weird, but it would let us keep this "quieter".)
Overall
But the above are really nits. The concept of "let's stabilize SOME way to get unsizing and work out the underlying traits later" I think is very solid. Therefore I am going to proposed FCP...
@rustbot fcp merge
...and get wider @rust-lang/lang attention!

I went through the RFC and comments and I have a few thoughts.
On soundness with Pin
It seems to me that...

we should change the Pin requirements to be unsafe trait PinCoerceUnsized: CoerceUnsized -- based on prior thread discussion, I'm not sure if we know just what those constraints are, but it doesn't block this RFC
we can consider stabilizing derive(SmartPointer) without having resolved that, since you don't need it

...the only reason not to do this is if we want derive(SmartPointer) to require that you meet the pin contract -- i.e., we don't want to allow people in the future to have a "coercible pointer" that is not also pinnable. I generally think that we eventually want some simpler way to say "this is a true smart pointer" -- i.e., it is backed by a pointer, it is dynamic dispatch safe, supports pure deref, etc, all in one convenient package, but I think we don't know how to do that yet. So maybe it's fine to start with just the pieces and come back to it.
Zulip discussion here
On naming
On the topic of starting with just the pieces, I don't love the name derive(SmartPointer). It promises quite a lot but delivers quite a bit less. It seems to me that what this is really doing is saying "this is an unsizeable pointer". Perhaps a name like one of the following would be better

#[derive(std::ptr::UnsizeReferent)]
#[derive(std::ptr::UnsizePointee)]
#[derive(std::ptr::PointerUnsize)]
etc

...or perhaps in some module other than std::ptr (maybe even not from std, but just core? seems a bit weird, but it would let us keep this "quieter".)
Overall
But the above are really nits. The concept of "let's stabilize SOME way to get unsizing and work out the underlying traits later" I think is very solid. Therefore I am going to proposed FCP...
@rfcbot fcp merge
...and get wider @rust-lang/lang attention!
PS, I posted this once before with the wrong bot name. =)

@rfc concern name
I propose we rename the derive to something like "unsize pointee". Not sure what. I think this concern can be resolved by just adding an "unresolved concern" to the RFC that says we'll settle on the ultimate name prior to stabilization.

@rfcbot concern name
I propose we rename the derive to something like "unsize pointee". Not sure what. I think this concern can be resolved by just adding an "unresolved concern" to the RFC that says we'll settle on the ultimate name prior to stabilization.

@rfcbot resolve name

i'm with scottmcm regarding repr(transparent).
The RFC itself says it is going to rely on "something similar to a transmute"; that, combined with the requirements that scottmcm already noted (the repr constraints and the single non-trivial field constraints) to me entails that this is already just as constraining as repr(transparent) would be.
If we find a reason later to generalize this construction to work in other contexts, then we can do that then. But right now, trying to avoid mention of repr(transparent) seems like trying to appear like this is a more general-purpose feature than it actually is.

I've posted my opinion regarding what I see as a slight hiccup between #[smart_pointer:...] and #[derive(SmartPointer)].
But I don't feel that opinion strongly enough to frame it as a formal concern.
@rfcbot reviewed

@scottmcm #[repr(transparent)] won't work for types which are allocator-aware such as Box<T, A> / Rc<T, A> / Arc<T, A> etc. Granted, Box<T, A> does not implement DispatchFromDyn (only Box<T, Global> does), plus allocator_api is still unstable, but you can't conditionally apply #[repr(transparent)] to A = Global or size_of::<A>() == 0 only either.
For this RFC, it means #[derive(SmartPointer)] and allocator support will become mutually exclusive, and unlike other derivable traits you can't manually impl DispatchFromDyn (The underlying traits used by its expansion will remain unstable for now.) so a custom smart pointer can never support allocators?? Removing #[repr(transparent)] is also considered breaking change btw.

You can't conditionally derive SmartPointer either though, so I don't think derive(SmartPointer) as proposed can handle Box<T, A>? Custom allocators and DispatchFromDyn are incompatible right now, that's just the reality. As you say, only Box<T, Global> is DispatchFromDyn.

The issue with forcing #[repr(transparent)] is that the type MyBox<T, A> can't exist at all, even if we only want impl<T> DispatchFromDyn for MyBox<T, Global>.
And if you don't #[repr(transparent)] then dispatching MyBox<dyn Trait, (Global)> to self: MyBox<T, (Global)> can't ever happen, as long as there is no plan to stabilize DispatchFromDyn and #[derive(SmartPointer)] being the only way to implement the trait.
I also think that if the door to impl<T, A> DispatchFromDyn for MyBox<T, A> is not entirely shut let's not jump ahead and enforce a stricter-than-necessary requirement.

This RFC already can't handle your MyBox. So no doors are being shut by requiring repr(transparent) in this first version of the derive. If later a new RFC is written that enables some form of conditional SmartPointer, or that allows DispatchFromDyn with non-default allocators, then the requirement can always be lifted.

Sure, but adding #[repr(transparent)] to an existing type, adding a defaulted trait parameter (A = Global), and implementing a trait (#[derive(SmartPointer)]) are all minor changes; removing #[repr(transparent)] after it is decided "the requirement can always be lifted" is a breaking change.

This RFC is clearly the result of a lot of thorough discussion and iteration. It anticipated many of my questions with better answers than I could come up with in an afternoon. Thank you for pushing it forward, @Darksonn, and to the many others who contributed.
After reading it I agree that SmartPointer is a name that promises too much for a type that isn't required to implement either Deref or Receiver.
On the #[repr(transparent)] question I'm not sure. I think we should either defer to the safety requirements of DispatchFromDyn or update those accordingly.
@rfcbot reviewed

I do not mind making it require repr(transparent) but the actual implementation of that is probably somewhat cumbersome. The existing requirements about repr aren't verified syntactically, but by the compiler in it's built in checks for implementations of DispatchFromDyn. However, we can't add the repr(transparent) check there because that wouldn't work for some standard library types, so we would probably need to add a new unstable AssertTransparent trait with a similar verification and emit an implementation of that.

Until now #[derive(Foo)] derived trait named Foo and only that. So this feature should not be named #[derive(SmartPointer)]. This will cause confusion. Users will expect that trait SmartPointer will be derived. So, please name language construct as #[smart_pointer] or something similar

I agree that the RFC should mention the point about the derive not matching any trait name (either as a drawback, or in the unresolved questions by expanding the name bikeshed to include the possibility of a regular attribute).
While this would be a first for the standard library, it matches the way user-defined derives work (matching the derive with a trait name is by convention only) and it's only meant to be used by advanced users. So I don't think we have to be too careful about violating their expectations.

That's already mentioned in the drawbacks section of the rfc.

@scottmcm and @pnkfelix please review the latest commit.

The current state of this RFC is a little confusing on the requirement of #[repr(transparent)].
The "Input Requirements" section lists that it must be transparent as a requirement, but non of the examples include a repr attribute on the structs. And that requirement isn't mentioned in the "Requirements for using the macro" section in the guide.
It also isn't very clear why the AssertReprTransparent trait is needed.

CustomPointer
I would recommend naming the derive CustomPointer instead of SmartPointer, since it seems it could be used with any custom pointers, not only smart pointers.
CustomPointer(T)
Mayhaps the syntax to specify the pointee type should be #[derive(CustomPointer(T))] or #[derive(CustomPointer = "T")] rather than requiring any extra attribute?
It would avoid collision with any other derive/macro.
Truly Custom Pointers
I apologize if I missed it in the RFC, is an inner pointer (somewhere) necessary for this trait to work?
It sometimes is useful to create "pointer-like" objects which internally use an offset, either for compression (u32) or to be able to shared them with other processes (shared memory, mapped files, etc...).
It's not essentially -- especially if we consider the trait a stop gap measure -- but may be worth mentioning.

I apologize if I missed it in the RFC, is an inner pointer (somewhere) necessary for this trait to work?

Yes, both CoerceUnsized and DispatchFromDyn directly modify the inner pointer without going through Deref. The former attaches metadata to a thin pointer, turning it into a fat pointer. The latter reads the metadata for a fat pointer to get the method to call and then strips the metadata to turn it back into a thin pointer.

Jumping onto the bikeshed train, I'd like to note that the spelling "ptr" is more prevalent in std than "pointer" by far. In particular, all items of the form "foo pointer" are named FooPtr.

@tmccombs Thanks. I removed the unnecessary details about how #[repr(transparent)] will be enforced.


Action methods ignored for index routes

What version of Remix are you using?
1.4.0
Steps to Reproduce

Create a bare remix project
Add test/index.tsx under routes and paste the following code:

import { redirect } from '@remix-run/node'

export const action = () => {
  return redirect("/");
};

Update index.tsx in routes with the following code:

import { Form } from "@remix-run/react";

export default function Index() {
  return (
    <Form method="post" action="/test">
      <button type="submit">Submit</button>
    </Form>
  );
}

Run the app and click on the "Submit" button on the root index page

Expected Behavior
Browser redirects back to the index page.
Actual Behavior
405 Method Not Allowed error is shown.

You need to target /test?index
#2808 will enhance the documentation for this behavior

Documentation updated, please refer to https://remix.run/docs/en/v1/guides/routing#what-is-the-index-query-param

Thanks!


Immutable record default values utilities

Resolves #129 AuditableDefaultValues / Factory for requiring properties to be set

defaultValuesFactory which essentially just provides typing to ensure consumer doesn't miss any properties of type T
auditableDefaultValuesFactory which does the same, but also provides defined properties for Auditables
ensureRecords which takes an array of objects and maps it through ensureRecord, which is common for view model constructors to do for navigation properties
Some additional cleanup, dependency bumps and removal of ported types

[x] Related GitHub issue(s) linked in PR description
[x] Destination branch merged, built and tested with your changes
[x] Code formatted and follows best practices and patterns
[x] Code builds cleanly (no additional warnings or errors)
[x] Manually tested
[x] Automated tests are passing
[x] No decreases in automated test coverage
[x] Documentation updated (readme, docs, comments, etc.)
[-] Localization: No hard-coded error messages in code files (minimally in string constants)

Love the ensureRecords addition. That will come in handy.

@all-contributors add @dylanjustice for review


Configuration enhancements

Took a look at Configuration topic remarks for default configuration (CreateDefaultBuilder) for app settings files after @nicksav left a remark at https://github.com/aspnet/AspNetCore.Docs/issues/11224#issuecomment-573399264. Not sure what you're asking for there, @nicksav, but I see a couple of items for improvement.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 0eb4d762-3910-2c57-8741-3306c15537b6
Version Independent ID: ba2254a0-ea8e-9b28-e94b-edd0fc58c043
Content: Configuration in ASP.NET Core
Content Source: aspnetcore/fundamentals/configuration/index.md
Product: aspnet-core
Technology: aspnetcore-fundamentals
GitHub Login: @guardrex
Microsoft Alias: riande

Hey Thank you for you reply.
I am struggling to get Windows Service to locate app.settings.json. This is what docs are saying:

Many examples for Web App, but none for console app (or Windows Service).

I haven't checked that exact scenario myself. Can you set the SetBasePath with an absolute path as we called out in the instruction and see if that works? Use the path right to the folder where the appsettings.json file is in the deployment.
var builder = new ConfigurationBuilder()
    .SetBasePath("c:\myapp")
    .AddJsonFile("appsetting.json");

I'm curious to know what it thinks the ContentRootPath is ... you might want to log that out and see what it thinks that is. The reason it probably isn't working is that ContentRootPath isn't the path to where the config file is ... guessing 🤔. Log that out ...
var logger = host.Services.GetRequiredService<ILogger<Program>>();
logger.LogInformation("ContentRootPath: {ContentRootPath}", env.ContentRootPath);

... you'll need the built host for that ... https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-3.1#create-logs-in-the-program-class

All parameters from env. are null. Setting absolute path will work, but I
am after a generic solution, as during instalation users might decide to
change the default instalation path.
On Mon, 13 Jan. 2020, 11:23 Luke Latham<EMAIL_ADDRESS>wrote:

I haven't checked that exact scenario myself. Can you set the SetBasePath
with an absolute path as we called out in the instruction and see if
that works? Use the path right to the folder where the appsettings.json
file is in the deployment.
var builder = new ConfigurationBuilder()
.SetBasePath("c:\myapp")

.AddJsonFile("appsetting.json");

I'm curious to know what it thinks the ContentRootPath is ... you might
want to log that out and see what it thinks that is. The reason it probably
isn't working is that ContentRootPath isn't the path to where the config
file is ... guessing 🤔. Log that out ...
var logger = host.Services.GetRequiredService<ILogger>();
logger.LogInformation("ContentRootPath: {ContentRootPath}", env.ContentRootPath);
... you'll need the built host for that ...
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-3.1#create-logs-in-the-program-class
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/AspNetCore.Docs/issues/16515?email_source=notifications&email_token=ACGWJPKPATD7B5TYY7PU7VDQ5O7ARA5CNFSM4KFX5ZDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXKCSQ#issuecomment-573481290,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACGWJPOBSPNVQOEOEPRCMSLQ5O7ARANCNFSM4KFX5ZDA
.

Ah ... yeah ... not populated until the HostBuilder is created. If you go this way ...
var host = CreateHostBuilder(args).Build();

// ... other code

host.Run();

... you should get it populated in there. Or, just create a new HostBuilder directly if you're trying to avoid the CreateHostBuilder method approach ... you can probably go the var host = new HostBuilder().Build(); route.

It's true ... we're rather web-ish and Kestrel/IIS-ish around here. As more feedback comes in, we address the rough spots with other scenarios. I might need to add something for this ... as you suggest an example for that section of the topic. I'll look closer on Monday.

Since CreateDefaultBuilder is probably going to return the system32 directory based on GetCurrentDirectory, the example we'd probably show is using CreateHostBuilder with Host.ConfigureAppConfiguration that sets the base path to the app's deployment folder (i.e., do what you did, but do it inside of Host.ConfigureAppConfiguration).
Yeah ... I'll take a look in the morning and add a bit for this scenario with example code. It probably won't be a console app example, but it will be better than what we have now ... which is nothing.

Ok, better will wait for sample.

Will probably go something like this ...
public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .UseWindowsService()
            .ConfigureAppConfiguration((hostingContext, config) =>
            {
                config.SetBasePath(hostingContext.HostingEnvironment.ContentRootPath);
                config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true);
            })
            .ConfigureServices((hostContext, services) =>
            {
                services.AddHostedService<Worker>();
            });
}

... if it will work. 🤞🍀
It assumes that we get a good ContentRootPath there ... not to system32.

Sorry to be a pain:) but what if we use old style Windows Service deployment?

Do you recon we better move to new Worker model?

The appsettings.json and appsettings.{Environment}.json files are properly consumed by CreateDefaultBuilder.

ContentRootPath is correct in ConfigureAppConfiguration. The call to SetBasePath is not required for any new app settings files. If there were some other settings file to consume, say anothersettingsfile.json, it can be consumed in ConfigureAppConfiguration.
public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .UseWindowsService()
            .ConfigureAppConfiguration((hostingContext, config) =>
            {
                config.AddJsonFile("anothersettingsfile.json");
            })
            .ConfigureServices((hostContext, services) =>
            {
                services.AddHostedService<Worker>();
            });
}

The pattern is the same as for non-service apps, so there's nothing special to document in the recommended scenario.
WRT the path information the topic, I'll take a further look at that shortly. We surely don't want that content to confuse anyone into thinking that they need to take special action in the most common use cases (i.e., an app based on the worker server or web app templates following the guidance in the WS and Configuration topics).
WRT your last remark, you can see how ServiceBase is used by the framework by searching the engineering repo for it: https://github.com/dotnet/aspnetcore/

Perfect!
Works fine now!


DRIVER.CAB is missing

Due to GitHub's size limitations, it couldn't be included.
There will be a link to the file and the path later.

I added it back in the ISO, hopefully it works.


store.get() and store.sparql() return different values for similar blank nodes

Hi,
I am quite new to the RDF world and I am currently testing node-quadstore as a solution to persist triples.
During my tests I found what seems to be a weird behavior, as the returned values for blank nodes differ when they are fetch using store.get() vs store.sparql().
Here is a script to reproduce this:
import {Quadstore} from "quadstore";
import {newEngine} from "quadstore-comunica";
const leveldown = require('leveldown')
const rdf = require('rdf-ext')

async function test() {
    const db = leveldown('test')
    const store = new Quadstore({
        backend: db,
        comunica: newEngine(),
        dataFactory: rdf
    });

    const intermediaryNode = rdf.blankNode()
    const quads = [
        rdf.quad(
            rdf.namedNode('http://example.org/from'),
            rdf.namedNode('http://example.org/link'),
            intermediaryNode
        ),
        rdf.quad(
            intermediaryNode,
            rdf.namedNode('http://example.org/link'),
            rdf.namedNode('http://example.org/to'),
        )
    ]

    await store.open()
    await store.multiPut(quads)

    const getResult = await store.get({})
    console.log(getResult.items)
    // [
    //     QuadExt {
    //         subject: BlankNodeExt { value: 'b1' },
    //         predicate: NamedNodeExt { value: 'http://example.org/link' },
    //         object: NamedNodeExt { value: 'http://example.org/to' },
    //         graph: DefaultGraphExt { value: '' }
    //     },
    //     QuadExt {
    //         subject: NamedNodeExt { value: 'http://example.org/from' },
    //         predicate: NamedNodeExt { value: 'http://example.org/link' },
    //         object: BlankNodeExt { value: 'b1' },
    //         graph: DefaultGraphExt { value: '' }
    //     }
    // ]

    const sparqlResult = await store.sparql(`SELECT * WHERE { ?s ?p ?o}`);
    console.log(sparqlResult.items)
    // [
    //     {
    //         '?s': BlankNode { termType: 'BlankNode', value: 'b11' },
    //         '?p': NamedNodeExt { value: 'http://example.org/link' },
    //         '?o': NamedNodeExt { value: 'http://example.org/to' }
    //     },
    //     {
    //         '?s': NamedNodeExt { value: 'http://example.org/from' },
    //         '?p': NamedNodeExt { value: 'http://example.org/link' },
    //         '?o': BlankNode { termType: 'BlankNode', value: 'b12' }
    //     }
    // ]

    await store.close()
}

test()

What bugs me here is that the blank node I created is returned as a single one (b1) when I use store.get(), but it is returned as two different ones (b11 and b12) when I use store.sparql().
Am I missing something about how this work, and should I change the way I create/store/fetch my data to prevent such a behavior?
Here are the versions I use:
    "leveldown": "^5.6.0",
    "quadstore": "^8.0.0",
    "quadstore-comunica": "^0.3.1",
    "rdf-ext": "^1.3.1"

Hello @ehupin! Thank you for that code snippet, I can confirm I am able to reproduce this. It's weird, the correct behavior is the one you're getting from store.get() and that is also the behavior I would have expected from store.sparql().
As a temporary workaround you can skolemise blank nodes into named nodes, which I would recommend anyway as blank nodes can be rather confusing.
@rubensworks is this expected behavior in Comunica? Quadstore returns blank nodes with the same labels they had when inserted, which leads me to think that something in Comunica's handling of blank nodes might be causing this.

The client shouldn't expect stable blank nodes though. That's what URIs are for :)

Just for clarify and set expectations: although blank node labels are not guaranteed to be stable, quads and the relationships between quads are. The issue, here, is not that the labels change between store.get() and store.sparql() but, rather, that the way they change when using the latter is breaking the relationship between those quads.

Thanks all for your answers!
First it gave me to better understanding the issue (as @jacoscaz mentioned returned blank nodes should have the same label) but moreover it helps me to better grasp how to use and what are the limitations of blank nodes. Skolemization is an interesting subject that I will definitely explore!

is this expected behavior in Comunica?

Yep, that's expected and intentional behaviour. We have to do this to ensure non-clashing bnodes when querying over multiple sources.
It's quite normal for RDF tools to modify bnode labels like this, as you can indeed never attach meaning to them when using them across different documents/contexts.

@rubensworks I've managed to reproduce the problem with N3.Store.
I've modified the script provided by @ehupin to be able to easily switch between quadstore and N3.Store. It still uses a bunch of utils and types from quadstore as I haven't had the time to make it fully agnostic but the main parts are now implementation-independent:

I'm using  RDF/JS interfaces to import quads (.import()) and read quads (.match());
I'm using the Comunica engine instance directly, passing the instantiated store to it.

Is there something in how I am packaging Comunica that might trigger this?
import {Quadstore} from "./lib/quadstore";
import {newEngine} from "quadstore-comunica";
import {BindingArrayResult, QuadArrayResult} from './lib/types';
import leveldown from 'leveldown';
import {DataFactory} from 'rdf-data-factory';
import { Store as N3Store } from 'n3';
// const rdf = require('rdf-ext')
import { ArrayIterator, wrap } from 'asynciterator';
import { streamToArray } from './lib/utils';
import {Algebra, translate} from 'sparqlalgebrajs';

async function test() {

  const rdf = new DataFactory();
  const engine = newEngine();

  const store = new N3Store();

  // const db = leveldown('test');
  // const store = new Quadstore({
  //   backend: db,
  //   comunica: newEngine(),
  //   dataFactory: rdf
  // });
  // await store.open();

  const intermediaryNode = rdf.blankNode();
  const quads = [
    rdf.quad(
      rdf.namedNode('http://example.org/from'),
      rdf.namedNode('http://example.org/link'),
      intermediaryNode
    ),
    rdf.quad(
      intermediaryNode,
      rdf.namedNode('http://example.org/link'),
      rdf.namedNode('http://example.org/to'),
    )
  ]

  await new Promise((resolve, reject) => {
    store.import(new ArrayIterator(quads))
      .on('end', resolve)
      .on('err', reject)
    ;
  });

  // @ts-ignore
  const storeQuads: Quad[] = await streamToArray(store.match());
  console.log(storeQuads);

  const sparqlQuery = 'SELECT * WHERE { ?s ?p ?o}';
  const sparqlOperation = translate(sparqlQuery, { quads: true, dataFactory: rdf });
  const sparqlResult = await engine.query(sparqlOperation, { source: store });
  // @ts-ignore
  const sparqlBindings = (await sparqlResult.bindings()).map(b => b.toObject());
  console.log(sparqlBindings);

}

test().catch((err) => {
  console.error(err);
  process.exit(1);
});

Hmm, that's not good.
Not sure what could cause this.
My first guess would be somewhere here https://github.com/comunica/comunica/blob/master/packages/actor-query-operation-quadpattern/lib/ActorQueryOperationQuadpattern.ts
Now that I think of it, this sounds similar to https://github.com/comunica/comunica/issues/773, which I initially thought to be a parsing issue, but may very well have the same cause as here.

@rubensworks I'll see whether I can replicate this in a new test within Comunica's test suite and open an issue over there if so.

Opened issue upstream: https://github.com/comunica/comunica/issues/795

For posterity: this has required some work in both Comunica and sparqlee, the latter being Comunica’s SPARQL expression evaluator. I think we’re relatively close to fixing this and the fix will surely be included in the next version of quadstore. Relevant issues and PRs:

https://github.com/comunica/comunica/issues/795 (upstream issue)
https://github.com/comunica/sparqlee/pull/80 (PR, closed)
https://github.com/comunica/sparqlee/pull/81 (PR, closed)
https://github.com/comunica/comunica/pull/803 (PR, open)

Released in<EMAIL_ADDRESS>


When using Script Setup syntactic sugar, importing a TS interface or type definition will result in a warning

Describe the bug
EN: When using Script Setup syntactic sugar, importing a TS interface or type definition will result in a warning
ZH: 当使用Script Setup语法糖时，导入一个TS接口或类型定义会报一个警告

EN: When I import a type that comes with Vue or an interface I wrote (not shown here, of course), I get a warning that my route matches the current component, but there's a problem with the import chain, so the page goes blank
ZH: 当我导入Vue自带的类型或者自己写的接口（当然这里没有展示）时，会报警告，我的路由匹配的就是当前这个组件，不过在导入链出现了问题，所以页面一片空白

EN: But I prepended the type marker and the error no longer exists.
ZH: 不过我在前面加上type标识，这个错误就不复存在。

EN: Also when I modify this part of the code by removing the type or adding the type logo, the following happens with hot substitution.
ZH: 另外我在修改这部分代码时，删除type或加上type标识，热替换（HMR）出现以下情况：

EN: So to narrow it down, my guess: it may be that when recognizing the imported packages, the components and types are not correctly distinguished, resulting in module parsing failure.
ZH: 所以范围缩小，我的猜测：可能是在识別导入的包的时候，没有正确区分出组件与类型，导致模块解析失败。
Reproduction
EN: I tried to reproduce it in codesandbox, but there is no such problem. It seems that this Bug exists by chance, maybe it is a problem of my project.
ZH: 我尝试在codesandbox复现它，但是却没有这个问题，貌似这个Bug存在偶然性，也许是我项目的问题。
System Info

required vite version: v1.0.0-rc.13
required Operating System: Windows 10 x64
required Node version: v15.2.0
Optional:

npm/yarn version: npm v7.0.8 / yarn v1.22.5
Installed vue version (from yarn.lock or package-lock.json): 3.0.4
Installed @vue/compiler-sfc version: 3.0.4

Logs (Optional if provided reproduction)

Run vite or vite build with the --debug flag.
Provide the error log here.

ImageLink: https://s3.ax1x.com/2020/12/28/rThbEd.png / https://imgchr.com/i/rThbEd

Duplicated of https://github.com/vitejs/vite/issues/731

Thanks


Generate a list of people by location

Generate a list of people by location.

This should wait until there is a longer list of people

I removed the city/country information.

I just got here and was about to raise an enhancement for exactly this! Being in Australia, most people will probably be outside of my timezone so a visual filter would be useful.

You are right, I put back the information in people.json and will work on something visual when I have the time.

To maintain privacy, perhaps keeping at the Country level would be sufficient?

Maybe, I'll think about that :)

For the sake of saving space in the README, I will probably display the country with flags. One of those projects should be useful:

https://github.com/lipis/flag-icons
https://github.com/hampusborgos/country-flags


Move package load/activation times into package metadata

This would be helpful for atom/settings-view#893.  Everything except loadTime and activationTime are available in the package's metadata, which is pretty much what the Settings View exclusively deals with.  This would prevent an extra call to atom.packages.getLoadedPackage(name) when we already have the rest of the package data available.  Unsure if this is a breaking change/if any packages are relying on this (why?).

Closing - turns out that this approach doesn't seem like it'll be worth it.


RFTools Crash

Currently crashing upon generating a new world or loading an existing one when RFTools is enabled. I'm not sure why, but I'm hoping you can help me so I can use your mod! I love this mod way more than Mystcraft and would much rather enjoy the tech-flavor of the dimension crafting. This is a custom pack I've made for private use on Curse, if a mod list would help i can put it together but I don't have it typed up at the moment.
Extra details that I don't know if matters:
Minecraft version 1.7.10
Forge <IP_ADDRESS>2
AFAIK I'm using the latest version of your mod. I'm not entirely sure because CurseForge seems to pick the version it thinks is best.
Crash report on pastebin:
http://pastebin.com/JStALfd3
I'm not near experienced enough to know why it's not working but it seems to be having a problem with NEI.
Here's another crash report that says something different and to quote one of the lines
"Caused by: java.lang.ClassNotFoundException: mcjty.rftools.dimension.world.types.ControllerType$BiomeFilter"  :/
2nd Crash report:
http://pastebin.com/jvrf3kAZ

This is weird. That class is certain present in RFTools. Can it be that your rftools download got corrupted or something?

I hoped so but I re-downloaded it from Curse again after deletion and it still was crashing. I made sure to test in between deleting and reinstalling the mod that minecraft successfully loaded into the world and was playable. Currenly im rebuilding the private modpack from scratch 4-5 mods at a time AND making a changelog after each try just so i can figure out where the incompatibilities are. Im using Infinity as a base modpack just to get started; so far RFTools is confirmed to work with all the mods in their most updated versions in the modpack. I'm almost positive its one of the obscure mods I've downloaded, but I couldn't narrow it down before. This time hopefully I can and will let you know if I find it : /

Sorry about posting some more but this is an update. After many versions and trial and error I finally finished the modpack I was making. I put together a changelog which could be useful in maybe determining the problem. At the beginning RFTools obviously worked well with the other mods, and about halfway through I tested it on the server and it was fine with about half the mods in the pack. My method was slow, but I only added in about 4 mods at a time and tested singleplayer creating a new world each time all the way until I am where I am now. My latest version on the changelog you'll see I finished my work and tested it solo style and it worked. HOWEVER, upon adding the last touches to the server and running it, while it starts the server just fine, players can't connect. Unfortunately it still points to RFTools, and I have no idea why : /
But then again, I know almost nothing about this kind of stuff so take that with a grain of salt and all.
Heres the Console's crash log:
http://pastebin.com/xeGKE3tx
Here is my personal changelog I've got going for every change I did start to finish on the modpack.
http://pastebin.com/F8JZsdHx
I really hope this all helps. Please let me know if you find anything and sorry for so much information.

Oh:
[15:56:07] [Client thread/ERROR]: ########## GL ERROR ##########
Seems you have bigger problems then RFTools. Also RFTools is crashing here but it is not the cause of the crash. It is crashing because the setup of something else went wrong. But not should give me the full log. That can contain more information.

Closing because most likely not an rftools issue. Reopen if you have evidence suggesting otherwise.


Update date_picker.blade.php

Add semicolons after variables declarations. Semicolons are optional but theirs lacks cause some errors if you are going to use Minify Response/HTML libraries.

Sure, merged! Thank you @mgralikowski .
Personally I prefer semicolons anyway, but fields have been created by quite a few people with different code styles. Apparently StyleCI doesn't check javascript - good to know.