text:
NaN if 0

Description
I often input entries manually after the work is done, so I just round the time, eg. 5 hours exactly.
Since I've updated to version 1.0.5, entries with 00 string either on the hours or the minutes of the human stat format show aN. I suppose this is because, somewhere, something is evaluating as NaN (not a number) and then is being trimmed to match the 2 chars length of the field.
Images

Thanks for letting me know. I just fixed it and will include the patch in the next release. So how it worked was it took a number and split it at the decimal point: 1.6 would become ["1", "6"] but 5.0 becomes only ["5"] which made the second value NaN hehe

repo: joshavanier/log


text:
Generating icons

If I change the profile image, how do I generate all the other icons and favicons?

That's not something that's usually built into Jekyll, from my understanding. You'll have to do it manually (or find a plugin, I guess), but there are plenty of sites that can automatically generate a full set of icons from a source image.

Thanks. What site did you use to do this?
I found this one.

I've used [this one] (http://www.favicomatic.com), but I couldn't say how complete or incomplete either option is. None of my sites are currently complete by either's standards (probably because my manifest is not quite accurate or up-to-date).

source: gharchive/issue

authors: RMBLRX adishavit

repo: joshgerdes/jekyll-uno

license: mit

license_type: permissive

license_source: bigquery


text:
Crash when opening edited progression GUI

After I had largely edited the progression config in-game, in singleplayer, after restarting the modpack and trying to open the GUI again it immediately closes down minecraft. Something that I also noticed is that it also leaves the process still running in the background.
I run with this modpack on the technic launcher: http://www.technicpack.net/modpack/mcdestiny-20.720894
I have tested putting it on a server, worked without a problem. Though as soon as a client tries to open the gui on the server, the client crashes.
I run Windows 10, with Java 8 and forge version 1448. I have a more than enough powerful computer to run things like this.
You can get the logs and criteria.json files from here.
If you could fix and/or tell me what is causing it to crash, it would be very much appreciated. But until then, I'm going to drop progression.

Yeah progression was very unstable in 1.7.10, for me it was a very experimental mod, I've learnt a few things from it, and am working on improving things in the 1.8.9 version.

repo: joshiejack/Progression


text:
CableReady detected an error in morph!

I managed to launch my StimulusReflex application on IE11, but I can’t start the component, I get the error: CableReady detected an error in morph! Failed to get the "nodeType" property of a link whose value is undefined or is NULL.
How can you fix this?

SR doesn't support IE11 as of yet, but this PR should be what you're looking for: https://github.com/hopsoft/stimulus_reflex/pull/345

authors: gordienko joshleblanc

license: MIT

license_source: github-api


text:
Sidebar reorder blocked by component overlay

Describe the bug

@AWolf81 identified an issue while working on #375 where the Infobar component is blocking the dragging of a sidebar project.
I think this is Windows-specific because I cannot reproduce in Mac (unsure about Linux).
To Reproduce

Be on Windows
Try to drag the project near top of the window
Infobar component is sitting on top, preventing the drag

Screenshots

Screenshot from PR (Windows):

My view (Mac):

I'm trying to reproduce this bug but I am not able to see it on Windows.
It's already fixed?

@Canopix This issue is still present. The component in question is Titlebar. You need at least two projects in Guppy and then reduce the screen height until the first item is close to the top edge of the window.
In the screenshot below I've added a border to the titlebar to make it visible:

Not sure why it is there & invisible. There is a comment in the component like following:

The title bar in this app is invisible, and yet it still needs to be defined,
as it constitutes the "draggable" area of the window.

But I don't know what draggable area means. Is this a Mac thing? On Window this is not needed or am I missing something? @joshwcomeau
The Titlebar component is used in App.js I've commented it and I haven't noticed any difference beside that the sidebar buttons are clickable.

Thanks, @AWolf81
I tried reducing the screen height from the top and from the bottom, and this is the result:

@Canopix Then scroll the sidebar (mousewheel or scrollbar) so that the icon is close to the top menubar - like in my screenshot.
After hovering you should notice that the mouse icon is not changing and dragging is not possible.

I think the titlebar should be only present on platforms without window chrome (i.e. only Mac)

@Haroenv thanks, I think now I understand why it is there. It is adding the three dots on Mac as window bar, right?
So adding a conditional render will fix this issue. By changing line App.js:l39 to {isMac && <Titlebar />} it should be fixed.
isMac can be imported from platform.service
@Canopix if you like you can add this and check if it's fixing the issue? Mac os testing will be done during PR.

the three dots are native I think, but the title bar component is there to make sure you can drag the window all along the top

@AWolf81 Issue fixed, I did that you mentioned about it.
There is a new PR now 😄

Closed in #383

authors: AWolf81 Canopix Haroenv melanieseltzer

repo: joshwcomeau/guppy

license: ISC


text:
Sensors introduces platform dependency

Sensors introduces platform dependency for android and iOS and does not include the mac/linux/windows platform. This is causing the package to lose pub points.
Find a way to support accelerometer functionality on mobile platforms (for GyroDough) while maintaining support for web/desktop platforms.
https://pub.dev/packages/dough/score

An alternative to this would be to have two packages

Platform independent library, Dough, which has all widgets and has not platform dependencies
Platform dependent library, Mobile Dough, which uses sensors

Or if your lazy and dont even need gyrodough https://pub.dev/packages/senseless_dough

New sensors package here: https://pub.dev/packages/dough_sensors

authors: HatFeather cyberpwnn josiahsrc

repo: josiahsrc/dough


text:
🛑 Sixth Sense HI is down

In ce16f80, Sixth Sense HI (https://sixthsensehi.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Sixth Sense HI is back up in a4ffbfc after 13 minutes.


text:
🛑 Doorworks Company is down

In 56036a2, Doorworks Company (https://doorworkscompany.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Doorworks Company is back up in 98d9571 after 1 hour, 23 minutes.


text:
Separate server and app initialization into two parts (optional)

Opening a new issue for this idea. This conversation originally started on #56. Relevant comment below.
@peterwillis

The way I have middleware setup also makes it difficult for the same reason. I totally understand why you have done it the way you have for the most convenient case. In the middleware chain I have, there is no good place where server and app are available together at a point where the routing can be changed. All the middleware for the app is setup in advance including the error handling and this is a separate module. This module is then required by the serving module, which decides whether it should start an HTTP or HTTPS server for the app. Is it possible to separate out where the route is added so that I can do it in two steps? So I would have to add code in two places for reload to work in this way:

during routing:
reload.configureRoute(app)

then another function that wouldn't need the app:
reload.websocketServer(server)

I think the module would need another way to instantiate so it wasn't always returning the single function. I can put together a PR if you think it is feasible to include it?

@peterwillis you mentioned in #56 that you would be interested in writing a PR for this. Are you still interested in writing a PR for this I think this would be a great idea?
Can we do?
For routing: reload.configureApp
And for the socket: reload.configureServer

Yes I think I can something submitted today or tomorrow

reload has a fork that middleware definition support. See for yourself : https://www.npmjs.com/package/ack-reload#middlware

If I needed it to work that way, I could just use the venerable webpack-dev-server. The way that fork works is hijacking the way static content is served which won't work for my middleware chain. Using this package means you can use the express static middleware.

I like sassy replies! Most all of mine are sassy too!!!
Here, it seems again I have to do the leg work to inspire the people using reload:
app.js
const express = require('express');
const reload = require('ack-reload');

const app = express();
// LOTS AND LOTS OF MIDDLEWARE HERE...
// server is not created since in this module.
app.use((err, req, res, next) => {
  // final error handler
});

app.use( reload.middleware(app, false) )

module.exports = app;

serve.js
const app = require('./app');
const http = require('http');
const reload = require('ack-reload');

// we actually have http and https switched on configuration, but this example is for brevity
const server = http.createServer(app);
// at this point we have server and app, but the middleware chain setup is completed so we can't add reload.

const pathToWwwFiles = require('path').join(__dirname,www)
reload.reloadSocketByHttp(pathToWwwFiles, http)

server.listen(8888, () => { console.log('started!') });

Let me know if this works for you. Otherwise make another sassy reply and I'll provide code for you to sit and spin on ;)

Hey, smart guy, my dumb ass came up with another simplified approach.
app.js (untouched - needs no changes)
const express = require('express');

const app = express();
// LOTS AND LOTS OF MIDDLEWARE HERE...
// server is not created since in this module.
app.use((err, req, res, next) => {
  // final error handler
});

module.exports = app;

serve.js
const app = require('./app');
const http = require('http');
const reload = require('ack-reload');
const pathToWwwFiles = require('path').join(__dirname,'www')
const midware = reload.middleware(pathToWwwFiles)

// we actually have http and https switched on configuration, but this example is for brevity
const server = http.createServer(function(req,res){
  midware(req, res, app)
});
// at this point we have server and app, but the middleware chain setup is completed so we can't add reload.

server.listen(8888, () => { console.log('started!') });

Sorry I wasn't intending to be smart or sassy - sorry if it came across that way. That doesn't solve the problem at all. You are still delegating the handling of static content to your middleware. If you want to have a conversation about it, perhaps do it on your repos issues not here?

Sass and read worthy is my intent. I like to create buzz to gain and keep interest. Just letting you know so nothing is taken to heart on either end... Hey good luck solving your issue. I created a new function of isRequestForReload that I think may hit the spot more for your needs. See below
const server = http.createServer(function(req,res){
  if( reload.isRequestForReload(req) ){
    midware(req, res)//request is html OR reload.js file
  }else{
    app(req, res)
  }
});

This new method ensures reload middleware only gets involved when it should and not delegate ALL request. Please review and reply as I think this is your fix.

It does not - I don't know how I can be clearer about this. Please use your own repository for issues about it.

Heard loud and extra clear. Intent is absolutely not to harass. Farewell

Resolved by c00ac1a4b00551885d4876c796a9f9cc8080b363 in pull request #71

Closes by #118

authors: AckerApple alallier peterwillis

repo: jprichardson/reload


text:
crypto_pwhash

Functions

[ ] crypto_pwhash
[ ] crypto_pwhash_str
[ ] crypto_pwhash_str_verify
[ ] crypto_pwhash_str_needs_rehash

Just leaving a quick note that pwhash was mentioned in #10

Just leaving a quick note that pwhash was mentioned in #10

repo: jprjr/luasodium


text:
Performance Graphs

Hi,
Is it possible to have a graph that shows the total aircraft seen during a 24 hour period. I guess this would be in the form of a graph that builds over the 24 hour period from midnight. The weekly/monthly/yearly graphs should show the rolling totals based on previous days...
Thanks
Jon

sounds like graphs.php to me, is there any easily accessible data which is not yet being graphed here?

I have been thinking of that too. There are ways to aggregate rrd data, yet my familiarity with that is with cacti and using a plugin. I'll take a look back at those instructions and see if I can't give this a whirl sometime next week if someone else hasn't by then.

I guess all of the data in the below RRD's is being used to build the current graphs; however getting the number of unique aircraft from dump1090 for any given interval may be non-trivial:
i# ls -lhgtr /var/lib/collectd/rrd/$1/localhost/dump1090-localhost/
total 3.0M
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_dbfs-signal.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_tracks-single_message.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_tracks-all.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_messages-strong_signals.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_messages-remote_accepted.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_messages-remote_accepted_1.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_messages-remote_accepted_0.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_messages-positions.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_messages-local_accepted.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_messages-local_accepted_1.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_messages-local_accepted_0.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_dbfs-peak_signal.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_dbfs-noise.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_cpu-reader.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_cpu-demod.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_cpu-background.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_range-max_range.rrd
-rw-r--r-- 1 root 152K Oct 27 17:38 dump1090_mlat-recent.rrd
-rw-r--r-- 1 root 301K Oct 27 17:38 dump1090_aircraft-recent.rrd

authors: JonFear Romeo-Golf jdwall

repo: jprochazka/adsb-receiver


text:
Add a components cache

Addresses #23. It works by storing in memory the components metadata (including the last-modified timestamp) and the result of Jinja's get_template(tmpl_name).
Because the template could have been updated after being cached, it tests if the file still exists and if its modified time is the same as the one stored. This check takes time and is not needed in production, so it can be avoided by setting the new catalog argument auto_reload to False.
The cache can be also deactivated by setting the new catalog argument use_cache to False.
This are the results of the benchmark:
Jinja: 0.000012999120s per render (13µs), 0.1_s total
FastApi: 0.000021882281s per render (22µs), 0.2s total

------------------------------------------------------------
NO CACHE: 10_000 renders of simple case...

JinjaX: 0.000115001536s per render (115µs), 1.2s total
8.8 times Jinja
5.3 times FastApi

------------------------------------------------------------
CACHE, AUTO-RELOAD: 10_000 renders of simple case...

JinjaX: 0.000024344903s per render (24µs), 0.2s total
1.9 times Jinja
1.1 times FastApi

------------------------------------------------------------
CACHE, NO AUTO-RELOAD: 10_000 renders of simple case...

JinjaX: 0.000017458029s per render (17µs), 0.2s total
1.3 times Jinja
0.8 times FastApi

------------------------------------------------------------
NO CACHE: 10_000 renders of realistic case...

JinjaX: 0.000631244620s per render (631µs), 6.3s total
48.6 times Jinja
28.8 times FastApi

------------------------------------------------------------
CACHE, AUTO-RELOAD: 10_000 renders of realistic case...

JinjaX: 0.000146022997s per render (146µs), 1.5s total
11.2 times Jinja
6.7 times FastApi

------------------------------------------------------------
CACHE, NO AUTO-RELOAD: 10_000 renders of realistic case...

JinjaX: 0.000110918753s per render (111µs), 1.1s total
8.5 times Jinja
5.1 times FastApi

As you can see, the difference is measured in millionths of one second. Even in the worst case scenario, the difference between JinjaX and Jinja is a little more than half  a milisecond per render, so I'm not sure if this was even worth it...
It's nice to have a benchmark tough.

That's very awesome ! Thanks a lot 👍

Hi, @jpsca!

As you can see, the difference is measured in millionths of one second. Even in the worst case scenario, the difference between JinjaX and Jinja is a little more than half a milisecond per render, so I'm not sure if this was even worth it...
It's nice to have a benchmark tough.

Just wanted to chime in here and share some quick, and frankly unscientific, benchmarking performed with our own codebase which heavily relies on JinjaX. We are seeing an almost 10x render speed improvement across the board :tada: We had one particularly gnarly list view with lots of JinjaX components, built on top of other components recursively, which now renders in ~0.5 seconds instead of 8 seconds.
So in our eyes, this is a huge win, and a great improvement for JinjaX overall :star_struck:

After having tested this out even more, I now think the main issue is the unpredictability of when you end up hitting cold caches. We have several web workers distributed across several Kubernetes pods, which all have their caches populated to a different degree. Clicking around in the interface is mostly fast and responsive, but every ~5 or so request is suddenly slow because there is a cache miss. Do you think JinjaX could offer a way to populate all the caches at startup, forcing all renders to be from a cached component, thus trading startup time for render time variability?

source: gharchive/pull-request

authors: JakobGM astariul jpsca

repo: jpsca/jinjax


text:
Develop

Status
READY/IN DEVELOPMENT/HOLD
Description
Impacted Areas in Library

Which issue(s) does this pull-request fix?

Any special notes for your reviewer?

Checklist

[ ] Automated tests exist
[ ] Updated Package Requirements (if required, and with maintainers' approval)
[ ] Local unit tests performed
[ ] Documentation exists link
[ ] Local pre-commit hooks performed
[ ] Desired commit message set as PR title and description set above
[ ] Link to relevant GitHub issue provided

Pull Request Test Coverage Report for Build 5356657689

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 94.172%

Totals

Change from base Build 5356595611:
0.0%

Covered Lines:
1018

Relevant Lines:
1081

💛  - Coveralls

authors: coveralls jpwsutton

repo: jpwsutton/ibm-generative-ai


text:
Start dragging and resizing in the DnD calendar immediately if the event is already selected

Do you want to request a feature or report a bug?
I guess a feature, I view this as a bug, but it's really anyone's guess.
What's the current behavior?
When using the DnD calendar, for an event to start being dragged or resized when the user drags it with the mouse or drags on its resize handles, the event has to be clicked first. So every time the user wants to drag or resize, they have to go: click, drag/resize, click, drag/resize. This is pretty bad in terms of UX as far as I am concerned, especially because the resize handles show up on hover, not on focus. I assumed the event will start being actioned immediately if it is selected, went to some lengths trying to preselect an event on hover in #538 only to find the event doesn't care at all if its selected or not, DnD will take two clicks no matter what.
What's the expected behavior?
I would like to suggest that a selected event starts being dragged/resized immediately and not after a focusing click.

I think @bs85 is the person to ping here as you seem to be the developer on the drag and drop addon.

Okay, this is hella confusing. On the demo page at http://intljusticemission.github.io/react-big-calendar/examples/index.html#dnd, and even locally when checking out the project and running npm run examples, the DnD demo does not need the click-then-action dance. No matter what item was last selected, you can just grab any item and drag it or resize it.
But when using RBC in my own project, even though the use is completely identical to the DnD demo code, I do have to first click and only then can I action a slot. I used to think I had to first click to select and then action unless previously selected, but turns out the behavior actually is it will immediately action on every other click.
I figured it may be that this was fixed, just not released, but I was not able to build the project. I am using Windows so I fixed a few things to work with it and I was able to run npm run build, but I am not sure how to get to a state where I can just npm install ../react-big-calendar in my other project to be able to run against my local fork. When I try to do that with successful npm run build, I am greeted with errors like Can't resolve BakcgroundWrapper.js in ../react-big-calendar/dist, which makes sense, because the files are in lib`.
I am not sure how to proceed from here, the problem is not present in this repository or on the demo site, but I can reliably reproduce it in any app which uses RBC at its latest version. I am hoping I could get some support on this issue as it makes the DnD experience significantly unpleasant.

This is my repro of the problem I describe above:
https://github.com/TomasHubelbauer/rbc-dnd-auto-select
Just npm install and npm start.

Not sure, but maybe it's same issue as I had in #1105

This issues does indeed sound very similar to #1105. I will wait until yours has been resolved and see if that fix makes my repro work as well, if yes, I will close my issue.

I'm running into the same issue, any updates on this?

I haven't tried this because in my project the drag requirement was dropped. I think this project has been abandoned so I think you're best off debugging this for yourself and PR-ing just in case, if this is a blocker for you and you're on a deadline.

Hey @TomasHubelbauer  thank you for the quick reply. I have no deadline pressure, it's just a side project, but I would really like to have this feature before I present it. I will tinker with it for a bit to see if I can fix it. I'm curious to know what you ended up implementing to change the event time range? Did you use a modal?

I am not sure actually, unfortunately. I did a handful of experiments with RBC:
https://github.com/TomasHubelbauer?utf8=✓&tab=repositories&q=rbc&type=&language=
I think either https://github.com/TomasHubelbauer/rbc-resizable-event-wrapper or https://github.com/TomasHubelbauer/rbc-dnd-auto-select may be of interest to you, but I am not sure if they contain a solution, it's been a while since I focused on RBC and I mostly worked around all its weirdness by wrapping it in my own React component and forgot the specifics :-/.

@TomasHubelbauer thank you for sharing! I'm looking at it rw. Love you sense of humor, lol

Hello, I want to know if the problem can be solved in any way

Not sure, but in my case this workaround with initial data (in initial view) helped me last time I was working with RBC.
https://github.com/jquense/react-big-calendar/issues/1105#issuecomment-459563886

Not sure, but in my case this workaround with initial data (in initial view) helped me last time I was working with RBC.
#1105 (comment)

that's the workaround that i implemented, but is weird that the in the DnD example page works very fine. Maybe the creators use the same   workaround in that example. I dont know. Thanks for the reply.

authors: FelipeGaraycochea TomasHubelbauer tuancaraballo xtursky

repo: jquense/react-big-calendar


text:
Add static Repeat method

https://docs.microsoft.com/en-us/dotnet/api/system.linq.enumerable.repeat?view=netcore-2.1

Dibs.

You got it man! Looking forward to your solution.

authors: jreina the-pat


text:
Style problem in Selectoze widget.

The problem appears when resizing the browser window. The size of the input window does not change as the window size changes
I fixed it in browser adding class to the div (div class="ts-control" style="width: 100%"). But as I understand this div was created with JS, so I can't correct it. Could you fix it?

The size of the input window does not change as the window size changes

well spotted. This is because django-formset pilfers the styles from the original <select>-element and applies them to the web component implementing the functionality. I will try to add an event listener and recompute the styles.
Thanks for reporting.

This should be fixed now in branch develop and releases/1.4.
Please test and confirm. I then will release version 1.4.1 and 1.3.11

authors: amikphoto jrief

repo: jrief/django-formset


text:
getBinding() results are not returned into wdi5 test

Describe the bug
We were calling getBinding() function of a control and results were the control itself and not the binding object which is returned as ui5 control getBinding() result.
It seems that in client-side-js/executeControlMethod.js file code is checking if method result is a primitive, an array or a control and if so - the forwards the results into wdi5 test, otherwise it doesn't (line 58).
We would like to call methods which return other objects and then check the results or query those objects deeper.
To Reproduce
Just get any control which has binding and try to retrieve it using getBinding('bindingName'). We used sap.ui.table.Table control and it's binding 'rows'.
Expected behavior
We should the the result object which was retrieved in UI5, currently we got the control object which method we called.
Runtime Env (please complete the following information):

wdi5/wdio-ui5-service-version: 0.9.0-rc3
UI5 version: 1.98.0
wdio-version (output of wdio --version):  7.19.3
node-version (output of node --version): v16.13.0
OS: macOS 12.3.1
Browser: chrome 100.0.4896.75

thanks for bringing attention to them non-primitives return values of a $control-API method 👍
My guess is that we could resolve this pretty quickly by serializing non-primitive values in the browser scope and passing that serialized value to the Node-scope as is - any caveats @dominikfeininger?

https://webdriver.io/docs/api/browser/executeAsync/

Arguments may be any JSON-primitive, array, or JSON object. JSON objects that define a WebElement reference will be converted to the corresponding DOM element. Likewise, any WebElements in the script result will be returned to the client as WebElement JSON objects.

Guess the also counts for the returned object. Serialization not necessary but we need to remove recursive structures etc..

Test:
    it.only("check binding info", async () => {         const title = await browser.asControl({ selector: { id: "container-Sample---Main--Title::NoAction.h1" } })         const bindingInfo = await title.getBinding("text")         expect(bindingInfo).not.toBeNull()     })
Result:

maybe use https://github.com/js-soft/wdi5/blob/204ce911b9ef2de295753fdc40ca5a6066add533/client-side-js/injectUI5.js#L243 to first pipe the object through before returning it?!

yep, already a todo in code ;)
https://github.com/js-soft/wdi5/blob/204ce911b9ef2de295753fdc40ca5a6066add533/client-side-js/executeControlMethod.js#L49

authors: dominikfeininger edvardas-kireilis vobu


text:
Open SCAD files

Expected Behavior
Try to open the SCAD file.
Actual Behavior
OpenJSCAD report an error that the file is an invalid JSCAD file while it's an SCAD, I suppose it does not even try to load it as an SCAD file. Here's the error I get:
Error: The JSCAD script must return one or more CSG or CAG solids.
    at /usr/local/lib/node_modules/@jscad/openjscad/src/core/rebuildSolid.js:39:17
    at process._tickCallback (internal/process/next_tick.js:109:7)
    at Module.runMain (module.js:606:11)
    at run (bootstrap_node.js:383:7)
    at startup (bootstrap_node.js:149:9)
    at bootstrap_node.js:496:3

Steps to Reproduce the Problem

Create a symlink to cli/cli.js named openjscad and a variable named SCAD_FILE pointing to an SCAD file. ... It might have been done by node?
On the command line run openjscad $SCAD_FILE -o /dev/null

Specifications

Version: 1.4.0  & Web
Platform: Bash (from Ubuntu 17.10) & Web
Environment: The commandline version is installed from (node.js@v6.11.4) & the I tested the web version (https://openjscad.org/) with chromium.

@kristianbenoit heres some information about using the CLI.
To use the CLI...
cd OpenJCAD.org/packages/cli
node ./cli.js example.js -of svg

This following design cannot be used as Node.js cannot look backwards from the current directory (for security reasons).
node ./cli.js ../examples/testV2.js -of svg
Please copy the designs to the current directory, or link designs to the current directory.
cp -R ../examples .
Or
ln -s ../examples ./examples


text:
🛑 Piwigo is down

In 057d881, Piwigo ($SERVER_BASE/piwigo/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Piwigo is back up in 2f26875 after 14 minutes.

repo: jscmidt/upptime


text:
🛑 Tandoor is down

In d56c82a, Tandoor ($SERVER_BASE/recipes/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Tandoor is back up in a505d98 after 1 hour, 10 minutes.


text:
🛑 API is down

In aef575d, API ($SERVER_BASE/api/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: API is back up in e42605c after 18 minutes.


text:
🛑 Lychee is down

In f6f96c0, Lychee ($SERVER_BASE/lychee/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Lychee is back up in 9cd61a3.


text:
ES6 export and classes

When a class is exported
export class MyClass {
   /**
    * @param {number} id
    */
   constructor(id) {
      super(id)
  }
}

The constructor will not be documented (the same for any other method defined by a class).  This happens in 3.4.2 as well as the 3.5.0-dev version.

With 3.4.2 module is not properly documented. (it display class methods)
/** @module Foobar */
import Something from 'some-thing'

/**
 * My foobar class description.
 */
export default class Foobar {
  /**
   * Create a foobar.
   */
  constructor() {
  }
}

Expected is in Foobar module page i should get Foobar Class listed only. (currently it list also foobar class methods, ...)
But if i do the following, it work as expected :
/** @module Foobar */
import Something from 'some-thing'

/**
 * My foobar class description.
 */
class Foobar {
  /**
   * Create a foobar.
   */
  constructor() {
  }
}

export default Foobar

I think I found a workaround for this
https://github.com/jsdoc3/jsdoc/issues/1293

@Native-Coder the workaround listed in #1293 does not work for me.
It still require to first write class Foobar {} then add a line export Foobar to be properly documented.
(it does the work so i am not complaining 😄 )
Tough, i think that it would be a nice enchancement to have the same behaviour if using a single line. i.e.: export default class Foobar {}.

It doesn't work as in it's not the way you want to do it, or it doesn't work as in you can't get it to work at all?

It doesn't work the way i expect. (the way i previously described, using single line declaration).

+1 :)

is there any news?

@kslimani 's workaround works for me. Another workaround is to insert the class doc between the export and class keywords:
export
/**
 * My foobar class description.
 */
class Foobar {
  /**
   * Create a foobar.
   */
  constructor() {
  }
}

Personal preference would to have jsdoc support using export and class a single line, but this at least saves the extra export default Foobar at the end.

Hello all,
For export default class Foo {} I found this module : jsdoc-export-default-interop.
Unfortunatly this does not work for export default function foo() {}.

The fix for #1293 has broken the original example in a new and interesting way. Investigating.

Okay, this is now fixed on master. The fix will be included in JSDoc 3.5.0.

@pixi/jsdoc-template has a fix for this. In your configuration:
plugins: [
  "@pixi/jsdoc-template/plugins/es6-fix"
]

authors: Native-Coder Oza94 SukantPal albertbuchard cgmartin coot hegemonic kslimani xwartz


text:
Allow input type override

In modern mobile web it is recommended to set input type to  or  for numeric input fields
mobileinputtypes.com

Thank you!

authors: jsillitoe sevos

repo: jsillitoe/react-currency-input


text:
Content-type clarification and preflight requests

You specify that the Content-type: application/vnd.api+json is REQUIRED in all requests, but then within your specification-page examples you don't include it -- instead you specify Accept header which I understand is OPTIONAL, e.g.
GET /articles HTTP/1.1
Accept: application/vnd.api+json

Also, is it really necessary to require Content-Type header? Doing that will effectively make even GET/POST requests issue preflight requests (for CORS), which will hurt page responsiveness (added latency). I think the Accept header alone would be fine, and it wouldn't produce preflights.

You specify that the Content-type: application/vnd.api+json is REQUIRED in all requests

No, only when there's "JSON API data", which is supposed to mean an HTTP message body. Thus, GET requests are exempt.
The spec should either formally define "JSON API data" or revert to the common HTTP terminology in the Content Negotiation section.

Makes sense. Yea the wording is a bit confusing but mistake is on my part.
The POST will still make a preflight, though. I agree including the Content-type is semantic and correct, but just a tad annoying (which for some remote users might add up to more than a tad).

I also think it should be mentioned that GET and DELETE requests should not send the Content-Type header and that the spec doesn't require them. When reading the spec, it's easy to miss that these requests do not contain JSON API data and therefore don't fall under this rule.

I think this has been clarified in upcoming v1.1 of the specification:

Clients and servers MUST send all JSON:API payloads using the JSON:API media type in the Content-Type header.

This clearly limits the Content-Type header to request and responses, which includes a JSON:API payload.
Do you see further need to clarify?

authors: bintoro dwelle jelhan mphasize

repo: json-api/json-api


text:
Categorising multiple relationships to a single resource type?

I'm wondering how best to represent this case, and not sure how best to structure the JSONAPI response.

A person has a contract object.
The contract object can have multiple supervisor (person) objects.
There are different kinds of supervision ('principal', 'alternate', 'co', 'external', 'joint') where there might be more than one of each kind, or none.

Within the contract, I could use;
	"relationships": {
		"supervisor": {
			"links": { "self": "/contract/123456/supervisor", "related": "/contract/123456" },
			"data": [
				{ "id":"654321", "type": "person"},
				{ "id":"543210", "type": "person"},
				{ "id":"432109", "type": "person"}
			]
		},
		...
	}

But then how to determine which is which?
I could place each in eg "supervisor_principal", "supervisor_alternate", etc sections, but then how does a consumer who just wants all supervisors know which keys to look at?
(and adding both options seems extremely verbose)
Alternately, is storing a map of (type) to (supervisor id) inside the attributes a 'jsonapi-compliant' way to go?

I believe this question was discussed here. Please take a look at that link. If it doesn't help, feel free to open a new thread on http://discuss.jsonapi.org/, our discussion forum! For now, I'm going to close this issue here, as we prefer to have these discussions on discuss.

Thank you @ethanresnick for clarifying. I'm afraid I take @hhware 's side in this too.
In the last API we designed foreign keys were just represented as attributes, lists of attributes or maps of attributes. (depending on multiplicity etc)
The first-class treatment that 'relationships' get is great, but one loses brevity and flexibility in doing so. (and I'm already struggling to deal with the signal-to-boilerplate ratio)
The suggested solution for promoting foreign keys to being their own object only sounds like a workaround for a technical limitation, not a solution.
Thank you for pointing me towards discuss.jsonapi.org - I hadn't seen links to it anywhere or had it show up in search results! (and IRC is so dead...)
Two suggestions while I've got your attention;

Giving the discuss greater weight and visibility on the main site?
The spec is great and detailed, but it doesn't negate the need for lots of examples. How about some recipes for common use cases? Cross-referencing with the spec, even.

I'm afraid I take @hhware 's side in this too.

That's fair. Hopefully the (forthcoming) extension system will address this for you! See #957 for the current version of that proposal.

Giving the discuss greater weight and visibility on the main site?
-The spec is great and detailed, but it doesn't negate the need for lots of examples. How about some recipes for common use cases? Cross-referencing with the spec, even.

I agree with both of those things. It's just been an issue of time & bandwidth. If you're able to submit PRs to address either of those, though, I'd happily accept them!

If you're able to submit PRs to address either of those, though,

Hah! A list of "what not to do", given my current level of expertise...

authors: MrTrick ethanresnick


text:
建议增加对static字段mock的相关配置项

在很多时候，我们不希望mock静态字段的值，因此，建议增加对static字段mock的相关配置项

当bean中有静态类时mock会出现问题
Caused by: java.lang.IllegalAccessException: Can not set static final long field com.xxx.serialVersionUID to java.lang.Long
at sun.reflect.UnsafeFieldAccessorImpl.throwFinalFieldIllegalAccessException(UnsafeFieldAccessorImpl.java:76)
at sun.reflect.UnsafeFieldAccessorImpl.throwFinalFieldIllegalAccessException(UnsafeFieldAccessorImpl.java:80)
at sun.reflect.UnsafeQualifiedStaticLongFieldAccessorImpl.set(UnsafeQualifiedStaticLongFieldAccessorImpl.java:77)
at java.lang.reflect.Field.set(Field.java:764)
at com.github.jsonzou.jmockdata.util.ReflectionUtils.setFieldValue(ReflectionUtils.java:42)
at com.github.jsonzou.jmockdata.mocker.BeanMocker.setFieldValueByFieldAccessible(BeanMocker.java:67)
at com.github.jsonzou.jmockdata.mocker.BeanMocker.mock(BeanMocker.java:41)
... 5 more

4.3已支持

authors: 6671246 CZ-chen jsonzoup

repo: jsonzou/jmockdata


text:
Can't build main-eisop

I'm getting a failure to build the main-eisop branch on a brand-new clone.
$ ls -a
total 8
4 ./  4 ../
$ git clone git@github.com:jspecify/jspecify-reference-checker.git
Cloning into 'jspecify-reference-checker'...
remote: Enumerating objects: 4032, done.
remote: Counting objects: 100% (660/660), done.
remote: Compressing objects: 100% (249/249), done.
remote: Total 4032 (delta 375), reused 520 (delta 291), pack-reused 3372 (from 1)
Receiving objects: 100% (4032/4032), 996.26 KiB | 29.30 MiB/s, done.
Resolving deltas: 100% (1426/1426), done.
$ cd jspecify-reference-checker/
$ git checkout main-eisop
branch 'main-eisop' set up to track 'origin/main-eisop'.
Switched to a new branch 'main-eisop'
$ ./gradlew build
git clone --depth 1 --single-branch https://github.com/jspecify/jdk.git ../jdk
Cloning into '../jdk'...
Updating files: 100% (69213/69213)
Updating files: 100% (69213/69213), done.

> Task :compileJava FAILED
/usr/local/google/home/dpb/dev/jspecify-eisop/jspecify-reference-checker/src/main/java/com/google/jspecify/nullness/NullSpecAnnotatedTypeFactory.java:110: error: cannot find symbol
import org.checkerframework.framework.util.NoContractsFromMethod;
                                          ^
  symbol:   class NoContractsFromMethod
  location: package org.checkerframework.framework.util
/usr/local/google/home/dpb/dev/jspecify-eisop/jspecify-reference-checker/src/main/java/com/google/jspecify/nullness/NullSpecAnnotatedTypeFactory.java:1038: error: cannot find symbol
    return new NoContractsFromMethod();
               ^
  symbol:   class NoContractsFromMethod
  location: class NullSpecAnnotatedTypeFactory
/usr/local/google/home/dpb/dev/jspecify-eisop/jspecify-reference-checker/src/main/java/com/google/jspecify/nullness/NullSpecChecker.java:72: error: method does not override or implement a method from a supertype
  @Override
  ^
3 errors

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':compileJava'.
> Compilation failed; see the compiler error output for details.

* Try:
> Run with --info option to get more log output.
> Run with --scan to get full insights.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/8.10/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.

BUILD FAILED in 32s
1 actionable task: 1 executed

You need to clone eisop/checker-framework and include that build, see https://github.com/jspecify/jspecify-reference-checker/blob/27d2334f1c94a223a70c0c98d11058dadce38d94/.github/workflows/build.yml#L35
I'll make an EISOP release next week, then the reference checker will work with that release.

I think I had mentioned my steps in https://github.com/jspecify/jspecify/pull/583#pullrequestreview-2228687118 elsewhere, so that's at least something that might still unblock your attempt until the normal instructions are fixed by a release or whatever turns out to be necessary.

authors: cpovirk netdpb wmdietl

repo: jspecify/jspecify-reference-checker


text:
WIP: Add internationalization (i.e. translations and more) support

This (currently WIP) PR adds support for internationalization i.e. translations and all other necessary features to make experiments available in different languages / locales.
Feedback and ideas are welcome.
(Non-Exhaustive) Todo List:

[x] Simple string based translations: turn Hello World! to Hallo Welt!
[ ] String interpolation: turn Hello {name}! to Hallo {name}!
[ ] Pluralization
[ ] Formatting of Dates, Numbers
[ ] Warnings for potential issues e.g. warn for certain locales when Keyboard keys are used that may be at a different location for that locale?

[ ] via translateKeyboard(['a']); KeyboardMap API

[ ] Styling that needs to be adjusted?

[ ] Right-aligned text
[ ] Forms

[ ] Check support for (automated) translation tools
[ ] Write docs page
[ ] Create a language selection plugin (maybe separate PR)

Hi @jansim,
thanks for the PR. I'm afraid what you suggest can already be done using i18next or similar libraries – taking care of all translation needs – so I'm a bit hesitant to build a translation framework from scratch into jsPsych, hence closing this PR. If you're interested in contributing a simple i18next example, that would be great.
Cheers!

Sorry, I seem to have missed that :see_no_evil:

Also, I think we're open to the possibility that another tool would be the better way to handle this.

To me, that sounds like the way to go – at least with an API like the one suggested in this PR, it looks straight-forward to use other tools instead. If i18next is too bloated, Polyglot.js might also be a very good option. If the API you envision can only be realized by extending jsPsych, maybe integrate another library, but if I may make a wish, please don't start a full-fledged translation framework here :face_in_clouds: We need to maintain this :smiling_face_with_tear:

Hmm, so I feel we have four options here in terms of whether/how we could use external libraries:

Use an external library altogether and we just write docs / a tutorial on "this is the recommended approach"
Use an external library as an optional dependency, but write a bit of glue code to make it integrate more nicely with jsPsych, passing the translation library instance in initJsPsych
Using an external library as an integrated dependency, so that users would never have to explicitly install / interact with the library unless they want to do special things. The most important bits would be handled by jsPsych.
Writing a full custom translation framework from scratch for jsPsych.

Do you have any clear feelings on which approach you would think is the most suitable here? I'm leaning a bit towards 2. or 3., as I don't want to create too much extra maintenance work.
My main reason for not being convinced by 1. is that IMO one quite valid use-case in jsPsych would be to create re-usable trials where you would want to have their translations side-by-side with the trial code itself. I think instance & translation management for this would be quite difficult in most / any existing i18n library as this is a sort of unusual use-case. I do believe we could fix this with some wrapper code, though, but that's option 2. then.

I do believe we could fix this with some wrapper code, though, but that's option 2. then.

Right, very valid point. When suggesting (1) above, I thought about adding translations separately next to each trial or in a trial callback, but that is definitely not as nice as a trial-level translations property. Now that I'm sold on (2), I'm comparing it to (3):
Pro (3):

Internationalization can be enabled by default for stock plugins without any additional setup required, with browser language detection included. This is all doable with (2) too but would require some boilerplate code.
Users don't need to load an i18n library separately and we decide which version is used

Pro (2):

Depending on the library in use, (2) might keep the jsPsych bundle (a lot?) smaller.

I think what's important if settling on (3) is that we expose the API of the underlying library as much as possible and are transparent about it in the docs to avoid reinventing the wheel documentation-wise and retain all of the original lib's flexibility. Which certainly would be easier to do with (2) :thinking: I'm on the fence.

Yep, agree 100%. I'm also usually very hesitant to introduce too much extra code to any sort of project as long as it could be avoided.
If we're all fine with deciding between (2) and (3), we could just make it dependent on the size of the final library we end up with. The benefit of these two options is also that they will most likely be very similar in how a lot of the code around them looks, so we could still pivot late in the process
.

My instinct here is that jsPsych bundle size is not a huge concern for most research projects. Jan's might be one of the few projects where bundle size is a relevant cost consideration given the huge volume of traffic and global reach. Obviously avoiding unnecessary bloat is good, but given a tradeoff between usability and bundle size I'd lean towards usability.

Haha, compared to the size of the MP3 files and stuff, we also don't pay too much attention to bundle size. It's more just some lean-solution-perfectionism coming through 😄
Let's just assume (3) then and we can still make the dependency optional if we size becomes an issue 👍

authors: bjoluc jansim jodeleeuw

repo: jspsych/jsPsych


text:
Is there protection against brute force attacks?

For example, a potential attacker could potentially keep on guessing a password many times via brute-force until the link unlocks.

Thanks for taking a look at the project! Theoretically, that is absolutely possible! Unfortunately, I am not aware of anything I can realistically do to protect against it. For example, given that all encryption and decryption is done client-side, I could not effectively perform rate-limiting.
Out of curiosity, I wrote a quick brute-force tool to try it out. While I know that nobody would actually ever brute-force anything too seriously in their browser, I coded up a web-based brute-forcer that will attempt to decrypt locked URLs by trying all combinations of characters in a user-submitted charset. I made a browser-based implementation simply because I could directly import the APIs I'd already written for the main project.
You can try my brute-forcer here. The code for it is here if you would like to modify it. In practice, using this very naive implementation of brute force, it turns out that even relatively short passwords with limited character sets take a very long time to crack!
In the meantime, I will leave this issue open in case others have ideas for how to protect against this.

In the spirit of openly discussing this issue, I have added the code to brute force locked links directly to the main repository. Users can attempt a brute force in their browser here:
https://jstrieb.github.io/link-lock/bruteforce/

A solution is to use scrypt or bcrypt instead of directly AES.
So you can provide complexity parameters that will make very hard for an attacker to brute force the password.

A solution is to use scrypt or bcrypt instead of directly AES.

Since a user with the password must be able to recover the original URL, I need the encryption to be symmetric, and cannot use a hashing algorithm for this. Thus, I wouldn't actually be able to replace AES with bcrypt or scrypt. I could potentially use those hash functions in place of SHA-256 for secure key derivation, but unfortunately neither algorithm seems to be available in the SubtleCrypto API.

As a fun project while learning Go, I wrote a cross-platform, command-line application to brute force Link Lock URLs. It parallelize on as many CPU cores as possible. Find it here:
https://github.com/jstrieb/bruteforce-link-lock
Interestingly, while profiling this code, I discovered that (perhaps unsurprisingly) the bottleneck for each attempt is the 100,000 iterations of SHA256 used for PBKDF2 key derivation. What did surprise me is that the Go code's rate of attempts per second per thread does not seem to be significantly better than the browser (both between 15 and 20 password attempts per second), so the only benefit of this new code over the browser-based brute force tool is parallelizing across CPU cores. Turns out the SubtleCrypto API is pretty fast!

Not seeing that work right the - I have roughly 52 threads and its only running on one.

hey @jstrieb i have a question about where the password is being stored in the client side?(is it inside the url itself)?

hey @jstrieb i have a question about where the password is being stored in the client side?(is it inside the url itself)?

Hi @cool-dev-guy! The password is not stored at all. Only encrypted data is stored. And all of the encrypted data is stored in the URL.
To give a concrete example, here is the structure extracted from one of the example URLs in the README.
jacob@jacob:~$ echo "https://jstrieb.github.io/link-lock/#eyJ2IjoiMC4wLjEiLCJlIjoiZEx3Yi9CNitlK0ZjM1B3ZURrbUY2NjdQWFlIV1dsS3dpclhvZmkvRXBFTXU0ZERlVkJuSmUrN1loS2JxQ3RrPSIsImgiOiIxICsgMSA9ID8iLCJpIjoiRDJYd1MyK1EzaHpuUDV1NyJ9" \
  | sed 's/.*#\(.*\)/\1/g' \
  | base64 -d - \
  | jq
{
  "v": "0.0.1",
  "e": "dLwb/B6+e+Fc3PweDkmF667PXYHWWlKwirXofi/EpEMu4dDeVBnJe+7YhKbqCtk=",
  "h": "1 + 1 = ?",
  "i": "D2XwS2+Q3hznP5u7"
}

Within this extracted JSON structure:

v is the API version
e is the base64-encoded, encrypted bytes
h is the (optional) password hint
i is the Initialization Vector (IV) for AES-GCM

The password itself is not stored in here, but all of the encrypted data is entirely in the URL. If we go one step further and try to inspect the encrypted data, we'll see that it doesn't have any structure itself, and is just gibberish bytes.
jacob@jacob:~$ echo "https://jstrieb.github.io/link-lock/#eyJ2IjoiMC4wLjEiLCJlIjoiZEx3Yi9CNitlK0ZjM1B3ZURrbUY2NjdQWFlIV1dsS3dpclhvZmkvRXBFTXU0ZERlVkJuSmUrN1loS2JxQ3RrPSIsImgiOiIxICsgMSA9ID8iLCJpIjoiRDJYd1MyK1EzaHpuUDV1NyJ9" \
  | sed 's/.*#\(.*\)/\1/g' \
  | base64 -d - \
  | jq --raw-output .e \
  | base64 -d - \
  | xxd -
00000000: 74bc 1bfc 1ebe 7be1 5cdc fc1e 0e49 85eb  t.....{.\....I..
00000010: aecf 5d81 d65a 52b0 8ab5 e87e 2fc4 a443  ..]..ZR....~/..C
00000020: 2ee1 d0de 5419 c97b eed8 84a6 ea0a d9    ....T..{.......

Hopefully this answers your question!

Thanks jstrieb for the answer,it really helped me.

hey @jstrieb ,i have a doubt about link-lock,is it possible to encrypt a string(length < 280chars) to an encrypted string of length<280 characters?

authors: PrinceOfParallax cktang88 cool-dev-guy jstrieb yogsototh

repo: jstrieb/link-lock


text:
[no-access-state-in-setstate] equivalent for useState

Hey guys!
I was wondering if there are any plans to do a similar rule to react/no-access-state-in-setstate but for useState?
I feel that there is still a lot of benefit of doing that to prevent previous state bugs and having react-hooks rules suggesting to put previous state on dependencies array (for useEffect, for instance).
Thank you for your time :)

Can you provide some code samples you'd want to warn?

Hi @ljharb
Absolutely!

function SquareRoom() {
  const [numRooms, setNumRooms] = useState(0)

  const increment = () => {
    // eslint should report here saying that we should use the setState callback to access the previous state when calculating a new one
    setNumRooms(numRooms + 1) // 👎

    setNumRooms(prev => prev + 1) // 👍
  }

  return ...
}

This isn't extremely necessary here but imagine we have logic within a useEffect or useCallback. We may have to add numRooms so that the closure is up to date, which is unfortunate. Having the callback would prevent the following headaches:

function SquareRoom() {
  const [numRooms, setNumRooms] = useState(0)

  useEffect(() => {
   const id = window.setInterval(() => {
     // we can also start having issues when having intervals involved
      setNumRooms(numRooms + 1)

    }, 2000)

    return () => {
      window.clearInterval(id)
    }
  }, []) // eslint[react-hooks/exhaustive-deps] will say we need to add numRooms to the dependencies array

const increment = useCallback(() => {
    setNumRooms(numRooms + 1)
  }, []) // eslint[react-hooks/exhaustive-deps] will say we need to add numRooms to the dependencies array

  return ...
}

SIDE NOTE:
To be fair,react-hooks/exhaustive-deps rule does warn the following:
React Hook useEffect has a missing dependency: 'numRooms'. Either include it or remove the dependency array. You can also do a functional update 'setNumRooms(n => ...)' if you only need 'numRooms' in the 'setNumRooms'
However, having the react team recommending this rule to be a warning and not an error, we don't have the strictest code. Inexperienced devs will still include numRooms on the dep array and waste time having to solve perf issues or bugs.
The functional form also encourages code reuse.
In short, this rule would kick in whenever the previous state is accessed to calculate the new one.
I'm not sure how complex it can be to implement this but if we keep the rule only for useState I think it can be somewhat doable. Even if it doesn't catch more complex use cases like:

const increment = () => {
    const finalRoomsValue = someOtherFunction(numRooms)
    setNumRooms(finalRoomsValue + 1)
  }

I still think it's a beneficial rule to have enabled.
What do you think?
Thank you once again for your time.

Regarding exhaustive deps, if the rule already exists, and you can choose to set it to an error (the react team unfortunately believes, incorrectly, that eslint rules set to "warn" still preserve their usefulness), I don't think it'd make sense to reimplement it here just so we could make a different severity recommendation.
I think that if a very thorough set of test cases was provided, and all of the warnings were legitimate, and the bad patterns that were not warned were exceedingly rare, then that might still be useful - but a rule that only catches a subset of a problematic pattern can often be worse than no rule at all, because it lulls people into a false sense of safety.

This would be great!

@ljharb, could you take a look at this code? Here useEffect is of no use, and this rule might save a lot of debug time
https://codesandbox.io/s/cocky-tristan-52dmpk?file=/src/App.js
I'm asking, because I might try to implement it in my free time, but would like to have your approval that you'll find this rule useful and might merge it

I’m confused; that code doesn’t have useEffect in it, but i agree that calling useState more than once without the function fork is problematic - but especially for a counter, nobody would ever do that. Do you have actual, not contrived, code that would benefit?

Thanks for such a quick answer
Above you've mentioned that useEffect and "react-hooks/exhaustive-deps" might catch these errors, and I just wanted to prove, that the rule still might be useful on its own.
As for code: I don't find it contrived.

nobody would ever do that

Well, some juniors definitely might. Replace "counter" with anything business related. Here is another example
https://codesandbox.io/s/zealous-http-xgwjlx?file=/src/App.js
Imagine that we count user likes, and if they are logged in - add it to their list. This rule might save from a bug here, right?
feel free to ask any additional questions or argue, why you find this rule unhelpful

@ljharb, did you find time to look at the provided code examples? What do you think? Should we add the rule, or maybe close the issue altogether?

This would actually be the hook version of https://github.com/jsx-eslint/eslint-plugin-react/blob/master/docs/rules/no-access-state-in-setstate.md which would be really helpful.

authors: Vladyslav-Soldatenko denyo eliw00d ljharb rodrigofariow

repo: jsx-eslint/eslint-plugin-react


text:
Allow nested destructuring with react/hook-use-state

State is not always flat and sometimes it can make sense to destructure it directly. Example:
const [{foo, bar, baz}, setFooBarBaz] = useState({foo: "omg", bar: "wtf", baz: "bbq"})
const [[index, value], setValueWithIndex] = useState([0, "hello"])

Note that in these cases the setter name can not be symmetrical to the destructured variables.
It would be nice if react/hook-use-state permitted this use case (maybe optional?).
Either way, thanks for the great work! :+1:

That definitely seems like a reasonable option to add ("allowDestructuredState"?)

authors: ljharb philer-jambit


text:
Not using the solidity.packageDefaultDependenciesDirectory correctly?

I have a project setup with Truffle (standard contracts, migrations, etc directories) and setup for NPM so I can do dependency handle (in particular grabbing Open Ethereum) I have my settings currently set to ...
"solidity.packageDefaultDependenciesDirectory" :  "node_modules",
"solidity.packageDefaultDependenciesContractsDirectory" : "contracts"

(which is the default)

… but for some reason I have to write my imports like this …
import 'node_modules/openzeppelin-solidity/contracts/ownership/Ownable.sol';

… to not have VS Code complain about my imports. If I override the settings to match the default, the error still exists. Checking online the indication seems to be that these settings should be set to ...
"solidity.packageDefaultDependenciesDirectory" :  "",
"solidity.packageDefaultDependenciesContractsDirectory" : ""

… to get around the issue (which I did in my user settings)… and it is true it does. Seems these settings aren't working as intended?

What is your directory structure? Have you got "node_modules" at root?

Yup, the "node_modules" directory is off the root of the project as are the other truffle created directories (e.g. "contracts", "build", "migrations"). Also in the root are the files "package-lock.json", "package.json", "truffle.js" and "truffle-config.js".

You need to take into account that path.

Not sure what that means?
If you mean that I need to put in 'node_modules' on the import statement, that is getting around something that solc is trying to make sure you don't need to do.
What I'm not understanding is how the 'solidity.packageDefaultDependenciesDirectory' is used since it defaults (and was set) to be 'node_modules' but didn't work when I thought it would have (but setting it to '' will properly not require 'node_modules').

what i mean the vscode compiler needs to know the full path (relative to your working folder) of the node_modules to find it.
this might be "node_modules" at root
or might be "solidity_libraries/node_modules"

that is your "solidity.packageDefaultDependenciesDirectory"

If you are setting up a standard truffle project via truffle init or truffle unbox, you can use the following settings:
  "solidity.packageDefaultDependenciesContractsDirectory": "",
  "solidity.packageDefaultDependenciesDirectory": "node_modules"

then import as usual like so
import "openzeppelin-solidity/contracts/token/ERC721/ERC721Token.sol";

This does not work even if I start from scratch.
solidity.packageDefaultDependenciesDirectory is not being picked up by the extension

It doesn't work for me either.

Neither does it work for me
    "solidity.packageDefaultDependenciesContractsDirectory": "",
    "solidity.packageDefaultDependenciesDirectory": "node_modules",

and my directory structure is as follows
`

root

contracts
node_modules
`

authors: Talvish hswopeams jbroudou juanfranblanco phillipgibb saurfang

repo: juanfranblanco/vscode-solidity


text:
Toggle from dark to light (and reverse) for plots

Dear @juba,
Thanks a lot for the great Quarto format! It’s just so much exactly what I needed!
I’m considering using bookup-html+dark which gives the ability to switch from dark to light.
Would it be possible to also switch between dark and light plots at the same time? Maybe using something like Mickaël Canouil is doing here: https://mickael.canouil.fr/posts/2023-05-30-quarto-light-dark/?
Or if it’s too complicated, would you have some recommendation about a ggplot theme that would fit for both light and dark mode? I see in your live example that the plots are light, but no so “aggressively” light in the dark rendered page. Did you use an existing theme or some custom one?
Thanks a lot for helping!

Hi,
I don't think there is anything special in my sample files, it is just the base ggplot2 theme.
Maybe a way to have both light and dark figures could be to generate them in SVG and then use CSS to style them, but I'm not sure it would work with ggplot2. Or you can try to implement the solution given by Mickaël Canouil directly in your document.

Hello,
Thanks a lot for your answer! I might try to implement the solution of Mickaël in the future.

authors: gabrielparriaux juba

repo: juba/bookup-html


text:
Fixed typo.

すみませんtypoがあったので修正しました。

It was merged!

authors: jugyo matsuu

repo: jugyo/earthquake


text:
Package JuiceFS for Linux package managers

It would be nice if JuiceFS could provide distribution-specific packages for Linux such as .deb and .rpm in addition to tarball releases. These could also be added to the quick start guide to simplify the installation process (instead of downloading & extracting the tarball then placing the binary correctly with a mount.juicefs symlink, just install a package through the package manager and everything is done).
For now, I have packaged JuiceFS for Arch Linux on AUR: https://aur.archlinux.org/packages/juicefs-oss/.

it will be perfect  that  systemd  file is included .

The juicefs v1.0.4 is added to Ubuntu PPA, see: https://juicefs.com/docs/community/installation/#ubuntu-ppa

The community Ubuntu PPA has packages for 1.04 and 1.1.0, but the 1.1.0 deb doesn't include the binary from juicefs_1.1.0.orig.tar.gz
http://ppa.launchpad.net/juicefs/ppa/ubuntu/pool/main/j/juicefs/

The community Ubuntu PPA has packages for 1.04 and 1.1.0, but the 1.1.0 deb doesn't include the binary from juicefs_1.1.0.orig.tar.gz
http://ppa.launchpad.net/juicefs/ppa/ubuntu/pool/main/j/juicefs/

Thank you for your feedback, we will take care of it.

The community Ubuntu PPA has packages for 1.04 and 1.1.0, but the 1.1.0 deb doesn't include the binary from juicefs_1.1.0.orig.tar.gz
http://ppa.launchpad.net/juicefs/ppa/ubuntu/pool/main/j/juicefs/

This issue has been resolved. Please try refreshing the source and updating the package.
sudo apt update
sudo apt upgrade

Thanks for the quick response - I can confirm the package works as expected on Jammy (which is all I need). The package isn't available for Focal, but I'm able to use the same package there without issue.
Thanks again!

authors: PeterCxy SandyXSD davejwatson jaywayjayway yuhr123

repo: juicedata/juicefs


text:
error after upgrade @nestcloud/config

TS2305: Module '"../../../../../node_modules/@nestcloud/config"' has no exported member 'ConsulConfig'.

@eduscrakozabrus the latest version of @nestcloud is broken and has a race issue

Between that is a nestcloud issue

authors: eduscrakozabrus juicycleff

repo: juicycleff/ultimate-backend


text:
Specifying resource revisions in config

Requirements
We currently do not have a way of specifying a resource revision for charms at deploy within a terraform configuration. Note that this is not about the charm revision, but about the resource revision.

e.g. `juju deploy juju-qa-test --resource foo-file=4`

resource "juju_application" "this" {
  name = "my-application"

  model = juju_model.development.name

  charm {
    name     = "juju-qa-test"
    channel  = "latest"
    revision = 21
    resource = 4 # <- this can be a file path, oci image url, or a revision number
  }
}

Urgency
Casually wishlisting
Notes & References
No response

+1

authors: cderici dparv

repo: juju/terraform-provider-juju


text:
[PROPOSAL] Add a security policy

Detailed description
For security reasons, when a vulnerability is found in the code, it should be reported to the maintainers/administrators rather than making an issue on GitHub; otherwise, everything could be exposed. It might be dangerous as well.
More information at https://docs.github.com/es/code-security/getting-started/adding-a-security-policy-to-your-repository
Context
In case a vulnerability in the code is found, the users can check the security policy to know how to report vulnerabilities properly.
This will also make it much easier for the maintainers as well for the users and the community using the code.
Possible implementation
No response
Additional information
If you need any help implementing this, let me know. 🙂

I'm opened a PR about this.
Please take a look, the fork will be joined if it is also convenient for you.

repo: julelang/jule


text:
Enhance GenLens to support select chains i.e. _.a.b.c

hi from @xdotai :)

@cvogt really nice, thank you.
Could you tell me what error message do you get if an accessor along the chain is not a case class accessor?

Well something like GenLens[A](_.b.c.d) is simply expanded into GenLens[A].b composeLens GenLens[B](_.c) composeLens GenLens[C](_.d) (assuming .b: B, .c:C). You tell me what Monocle does when you try to use GenLens on a non-case class field :). I didn't check.

authors: cvogt julien-truffaut

repo: julien-truffaut/Monocle


text:
Convert ezbake to use junction-api types.

Use junction-api types for xDS and kube conversions, which means that pushing dynamic config can now be done with junction-client dumping kube yaml.
This ezbake passes smoke tests, but definitely have problems with xDS resource names not being, since we don't take service ports into account. Since we're still passing smoke tests and this enables dynamic config, I'm going to push it.
After this comes a quick sequence of follow-up PRs to:

Add resource name mappings to junction-api and support for generating/parsing unique xdstp:// URLs for any Target.
Switch to using those names in ezbake, for both xDS on the wire and internal caching. No more collisions!
Switch junction-client to expecting and parsing xdstp:// URLs off the wire to figure out target data.

I bumped MSRV to 1.79 to match junction-client. We got a CI failure testing on 1.76 because junction-client takes advantage of some temporary lifetime extension stuff that got added in 1.79.

repo: junction-labs/ezbake


text:
[zsh] Re-initialize zle when widgets finish

zle automatically calls zle-line-init when it starts to read a new line. Many
Zsh setups use this hook to set the terminal into application mode, since this
will then allow defining keybinds based on the $terminfo variable (the escape
codes in said variable are only valid in application mode).
However, fzf resets the terminal into raw mode, rendering $terminfo values
invalid once the widget has finished. Accordingly, keyboard bindings defined
via $terminfo won’t work anymore.
This fixes the issue by calling zle-line-init when widgets finish. Care is taken
to not call this widget when it is undefined.
Fixes #279

Do we also need this in completion.zsh?

Good catch. I wasn’t even aware of completion.zsh, since the Archlinux package currently installs it into the wrong location (I’ve filed a bug for this). Since the keybinding there also launches fzf, we’ll need to fix up the terminal mode there, too. Hold on, I’ll amend this commit.

I could confirm that this fixes the issue with the config you provided. Merged, thanks!

authors: eigengrau junegunn

repo: junegunn/fzf