Fast USB DFU workflow

Is your enhancement proposal related to a problem? Please describe.
The current of implementation USB DFU for Zephyr is not very streamlined. This makes it unusable for our product. See Additional context.
The current workflow (as far as I understand) is as follows:

Download new binary to slot 1 using dfu-util
Reset the device

There seems to be no solid way to do this automatically from the host. It could be done via the shell, but that adds two large dependencies. Also sometimes the CDC ACM endpoint seems to have trouble coming back up after the download.

Bootloader swaps the slots
Confirm the image

Again there seems to be no way to do this nicely without the shell.
It is possible to download an image that is already confirmed. This however has the disadvantage that it will increase the image size to the max possible value, since the swap status is stored at the end of the image. This is quite significant on nRF52480 since it has lots of flash.

I am mainly opening this issue to see if there is interest from the community to fix this. Since we need this anyway for our company we are interested to know if something like this would be merged.
Describe the solution you'd like
The most ideal (and fasted) workflow for us would be if developers could just run west flash --runner dfu, and have the same experience as with a debugger(minus actual debugging of course).
Keep in mind this flow is most suited to developers. For customer facing updates this may not be ideal.
Here are the steps that need to happen under the hood:

dfu-util sends the DFU_DETACH followed by a USB reset, as per the USB DFU standard. This causes the MCU to reset into the bootloader, where the actual download is preformed.

The application will somehow have to let the bootloader know it should go into DFU mode instead of booting the application. Nrf52 has some registers that are retained over a software reset, those could be used for that. I'm not sure if something similar exists on other platforms.
For testing at our company we currently have a shell command set up that sets the GPREGRET registers and resets the MCU. This works fine, but needs the shell enabled.

Mcuboot enables USB and USB DFU

This is similar to the USB DFU recovery mode already present in Mcuboots Zephyr code. Only an additional check is needed to see if it should stay in DFU mode.

dfu-util downloads the binary directly to slot 0

Because the binary is written from the bootloader, it is possible to write into slot 0. This eliminates both the swap and confirm operations. Saving time and complexity.
This of course isn't as safe as using the complete test-confirm cycle, but if the upload fails the device can always be debricked with the DFU recovery mode.

The bootloader directly boots the uploaded image!

I have some proof of concept code for enabling step 3. The current USB DFU implementation (correctly) forbids writing to slot 0. I only need to add some KConfig options so these checks can be en/disabled depending if it is used from the bootloader or application. I should be able to have a PR up by next week.
I suspect step 1 would be a bit more work. I guess usb_dfu.c would need to be split up somehow. One for the 'reset to bootloader' part, and another to do the actual download.
Describe alternatives you've considered
Going the USB DFU route seems the nicest for our use case, since it seems to be the fasted in terms of upload speed (given CONFIG_USB_REQUEST_BUFFER_SIZE is set to a high enough value).
We also experimented with the Mcumgr over USB, but that seems pretty slow with all the overhead involved. It also didn't seem to be very reliable.
Additional context
Our product (based on a nRF52840) has a closed housing with only a USB port exposed. For development we currently have to partly disassemble the product and hook up a debugger.
This works of course, but it is not very convenient for several reasons:

Quickly testing a change requires disassembly and lots of desk space.
Our product consists of several (up to 24) identical units that communicate to each other. Flashing them one by one via a debugger is tedious...
We have some developers that only work on the higher level side of the code. They don't need the debugging functionality anyway.

This is very specific to our product of course. But we figured improving this might be useful for more people.
Reference
https://usb.org/sites/default/files/DFU_1.1.pdf

Hi @hackwerken, it seems like you are willing to give up all nice mcuboot properties (downgrade protection, encrypted software, ...) to simplify the development proces. This seems like the wrong approach. Are you sure that your final product do without these properties?
It is not because mcuboot is said to be a secure bootloader that you can't disable all the security.

Hi @Laczen, thanks for your response.
We indeed do not use the features you mentioned for various reasons. Image signing is the most important for us, which is still intact with the proposed changes. We are also not sure yet if we want to ship a bootloader containing this behavior to end customers.
In any case, it would be nice to be able to optionally enable writing to slot 0 from the bootloader. We could then flash our development units with a special version of the bootloader.
Do you know what the original use case for the USB DFU feature was? Since some peaces seem to be missing.

The current of implementation USB DFU for Zephyr is not very streamlined. This makes it unusable for our product. See Additional context.
The current workflow (as far as I understand) is as follows:
1. Download new binary to slot 1 using dfu-util

2. Reset the device

   * There seems to be no solid way to do this automatically from the host. It could be done via the shell, but that adds two large dependencies. Also sometimes the CDC ACM endpoint seems to have trouble coming back up after the download.

3. Bootloader swaps the slots

4. Confirm the image

   * Again there seems to be no way to do this nicely without the shell.
   * It is possible to download an image that is already confirmed. This however has the disadvantage that it will increase the image size to the max possible value, since the swap status is stored at the end of the image. This is quite significant on nRF52480 since it has lots of flash.

What you describe is how samples/subsys/usb/dfu works, your application does not have to be like that, you can also use USB DFU class from/with bootloader only (what is obvious). IRRC there is example code in MCUboot (where MCUboot is just a Zephyr OS application) itself how to trigger update, e.g. using button or just timeout.
Is not CONFIG_SINGLE_APPLICATION_SLOT what you are looking for?

Hi @jfischer-no, thank you for your suggestions.
You are right, the Zephyr Mcuboot port has a recovery option using USB DFU. As you mentioned this requires a button or some kind of other trigger to stay in the bootloader. This works great on the NRF52480 DK. But, apart from requiring extra user input, this also requires a spare button. Unfortunately our product only has one button to turn it on/off. The most ideal workflow would be to only have to run west flash --runner dfu and have the application running some seconds afterwards. Kind of the Arduino experience, so to say.
CONFIG_SINGLE_APPLICATION_SLOT is and interesting option I didn't conciser yet. It would simplify some things as it does not require the patches to usb_dfu.c I mentioned. It does however remove the possibility to update via BLE. So then we would have to flash some units for USB and others for BLE.
Also, I realize I'm talking a lot in terms of 'we' and 'our product'. However, my goal for this issue is to find out if there is some common ground with other Zephyr users. If that is the case we are willing to put in the effort to implement it in such a way that it can be upstreamed.

@hackwerken, it would be good if there would be a zephyr application that fully supports usb-dfu. As far as I understand usb-dfu this application should:
a. Allow moving from usb-run to usb-dfu,
b. Remain in usb-dfu during the upload,
c. Reboot and upgrade (if using image0 and image1 solution),
d. After the upgrade restart in usb-dfu to allow the manifestation (that should include image validation),
e. Switch to usb-run,
Step d. could use the state of the validation to decide if an image should start in usb-run or usb-dfu. If the image upgrade fails for whatever reason the image would be the old image and this would not start the usb-dfu which could be used by the uploader to error out.

@Laczen right!
With D, do you mean to 'confirm' the image (in mcuboot terms)?
That is a good point. Because C and D seem to be the missing pieces of the puzzle.
I'll look more into the manifestation phase next week.

@Laczen right!
With D, do you mean to 'confirm' the image (in mcuboot terms)?
That is a good point. Because C and D seem to be the missing pieces of the puzzle.
I'll look more into the manifestation phase next week.

Yes, by D I mean the image confirmation. You could however also not do the confirmation in the manifestation but to assign a special dfu location where you would write "OK" to in order to validate the image. The running image could be asked to go to dfu mode, allow only upgrades if the image is confirmed, and allow writing to the special "OK" location.

You are right, the Zephyr Mcuboot port has a recovery option using USB DFU. As you mentioned this requires a button or some kind of other trigger to stay in the bootloader. This works great on the NRF52480 DK. But, apart from requiring extra user input, this also requires a spare button. Unfortunately our product only has one button to turn it on/off. The most ideal workflow would be to only have to run west flash --runner dfu and have the application running some seconds afterwards. Kind of the Arduino experience, so to say.

IIRC there is also timeout option, but it would not make it faster. There is no way without disadvantages, either USB DFU in bootloader and user interaction, or issues/limitations in USB communication in application mode, since USB DFU + other classes usually does not work, on Windows OS anyway.

CONFIG_SINGLE_APPLICATION_SLOT is and interesting option I didn't conciser yet. It would simplify some things as it does not require the patches to usb_dfu.c I mentioned. It does however remove the possibility to update via BLE. So then we would have to flash some units for USB and others for BLE.

What kind of product is it that is updated with west flash --runner dfu or via BLE, does it happen in the field?
Have you considered to use mcumgr and DFU over CDC ACM UART?

@Laczen

You could however also not do the confirmation in the manifestation but to assign a special dfu location where you would write "OK" to in order to validate the image.

I'm not sure what you mean by this? Such location already exists in the image trailer. Since the trailer is at the end of an image partition a 'preconfirmed' image is very large (as large as i can be).
Meanwhile I dived a bit deeper into the USB DFU specification. I might be mistaken, but as far as I can tell the manifestation phase works different from what you describe. Because in this case the device can not communicate during manifestation (ie the swap), it has to set bitManifestationTolerant=0 and bitWillDetach=1. After the update is complete the new image is booted in dfu app mode.
I made this diagram to show how that could work for Zephyr/Mcuboot.

This only leaves image confirmation. I see a few points where this could happen:

Uploading a precomfirmed image

Makes the image size very large
Requires extra scripts to generate the image via the sign tool

Confirm from the application before swapping (at 6 in the diagram)
Confirm on boot of the newly flashed image

How does the app know it was updated successfully and not reverted?
How does the app know it was updated via USB DFU and not some other way (ie BLE)?
Does not protect against uploading an image without USB DFU...
Could use something like GPREGRET on nRF52, but that would not be platform agnostic.

??

To me 2 seems best to start with. All three bypass the test-confirm mechanism, but manual recovery could be enabled via the bootloader.

@jfischer-no

IIRC there is also timeout option, but it would not make it faster. There is no way without disadvantages, either USB DFU in bootloader and user interaction, or issues/limitations in USB communication in application mode, since USB DFU + other classes usually does not work, on Windows OS anyway.

Entering the bootloader without user interaction is possible. We currently have a proof of concept shell command that does this. But as I wrote in the original issue, this uses the nRF52 GPREGRET register. That could be a drawback if nothing similar is available on other platforms.
For completeness I also made a diagram for the 'DFU in bootloader' solution:

This has the same issues with confirmation as the 'DFU in app' solution. It seems like USB DFU isn't really intended for such mechanism. But when updating from the bootloader this isn't a big deal, since manual recovery is always possible.

What kind of product is it that is updated with west flash --runner dfu or via BLE, does it happen in the field?

We make an interactive toy to encourage kids to play outside. There are already thousands being used in the field (hopefully many more will follow :)). Our customers use BLE to update their devices.
Since this product requires many devices to run the same firmware, it would be nice to have an update mechanism that is faster then BLE. This won't (yet) be used by customers, but it will be invaluable for development and user tests. So to answer your question more directly: it would be nice if it could happen in the field :). Having to keep different sets around that can ether be update via BLE of USB would be a pain. Also since our previous generation (not based on Zephyr) could do this.

Have you considered to use mcumgr and DFU over CDC ACM UART?

Yes, I have tried that before. It works, but it is really slow. I flashed the SMP example to my NRF DK this morning, and got around 3KiB/s. That would be more then 10 minutes for a 1MiB image... This is probably because the data is packetized before being send over ACM CDC.
From past experience it also seems to be unreliable when it has to share the ACM CDC pipe with logging.

@Laczen

You could however also not do the confirmation in the manifestation but to assign a special dfu location where you would write "OK" to in order to validate the image.

I'm not sure what you mean by this? Such location already exists in the image trailer. Since the trailer is at the end of an image partition a 'preconfirmed' image is very large (as large as i can be).
Meanwhile I dived a bit deeper into the USB DFU specification. I might be mistaken, but as far as I can tell the manifestation phase works different from what you describe. Because in this case the device can not communicate during manifestation (ie the swap), it has to set bitManifestationTolerant=0 and bitWillDetach=1. After the update is complete the new image is booted in dfu app mode.
I made this diagram to show how that could work for Zephyr/Mcuboot.
This only leaves image confirmation. I see a few points where this could happen:

Uploading a precomfirmed image

Makes the image size very large
Requires extra scripts to generate the image via the sign tool

Confirm from the application before swapping (at 6 in the diagram)

Confirm on boot of the newly flashed image

How does the app know it was updated successfully and not reverted?
How does the app know it was updated via USB DFU and not some other way (ie BLE)?
Does not protect against uploading an image without USB DFU...
Could use something like GPREGRET on nRF52, but that would not be platform agnostic.

??

To me 2 seems best to start with. All three bypass the test-confirm mechanism, but manual recovery could be enabled via the bootloader.

@hackwerken, nice diagrams. One small remark regarding this diagram, the manifestation phase could be after the upgrade (and I think usb-dfu intends it to be after the upgrade). If the upgrade fails the manifestation phase would never be reached and dfu-util would time-out. To start the manifestation at first boot you could detect the image verification state (but this would probably ruin support for preconfirmed images). If the image is not confirmed the application boots into dfu-mode and in the manifestation state.
Regarding the image confirmation, in dfu-util you are passing the location where to write and the data to write. You could define a "fake" location (e.g. location 0x0) and use this to pass the confimation message (e.g. a message containing "OK"). The dfu-util would then be called twice, once for the update and once for the confirmation. The application catches this second "upgrade" using the fake location and instead of writing an image it does the image confirm.

@hackwerken (goedemorgen Martijn), the above comments are two separate solutions, the first one to confirm during manifestation, the second one to use dfu-util to confirm the image. The last solution would be the simplest and most versatile.

@Laczen (goedemiddag :))
As far as I understand the manifestation phase is meant to do things like the swap. In fact, it can't happen after the swap/update, because resetting to the bootloader causes a detach event on the bus. At least in the case of the 'DFU via app' approach.
Taken from the USB Device Firmware Upgrade Specification, Revision 1.1, page 26:

After the zero length DFU_DNLOAD request terminates the Transfer phase, the device is ready to
manifest the new firmware. As described previously, some devices may accumulate the firmware image
and perform the entire reprogramming operation at one time. Others may have only a small amount
remaining to be reprogrammed, and still others may have none. Regardless, the device enters the
dfuMANIFEST-SYNC state and awaits the solicitation of the status report by the host. Upon receipt of
the anticipated DFU_GETSTATUS, the device enters the dfuMANIFEST state, where it completes its
reprogramming operations.
Following a successful reprogramming, the device enters one of two states: dfuMANIFEST-SYNC or
dfuMANIFEST-WAIT-RESET, depending on whether or not it is still capable of communicating via
USB. The host is aware of which state the device will enter by virtue of the bmAttributes bit
bitManifestationTolerant. If the device enters dfuMANIFEST-SYNC (bitMainfestationTolerant = 1),
then the host issues the DFU_GETSTATUS request, and the device enters the dfuIDLE state. At that
point, the host can perform another download, solicit an upload, or issue a USB reset to return the
device to application run-time mode. If, however, the device enters the dfuMANIFEST-WAIT-RESET
state (bitManifestationTolerant = 0), then if bitWillDetach = 1 the device generates a detach-attach
sequence on the bus, otherwise (bitWillDetach = 0) the host must issue a USB reset to the device.
After the bus reset the device will evaluate the firmware status and enter the appropriate mode.

When the appropriate bits are set (bitManifestationTolerant = 0 and bitWillDetach = 1) dfu-util shouldn't error out.
If upgrading/swapping failed, according to the spec (page 37) the firmware should remain in DFU mode after reset. This does not seem to be possible for us tho, since the application has no way of knowing if the swap was successful. Not really a big deal I think.
Or am I missing something?
I understand your idea for confirming via the 'fake location'. It wouldn't be strictly USB DFU compliant, but it could work I guess.
Anyway, for now I want to start implementing the 'DFU via app' approach, and confirm from the application after the upload completes. This would be the simplest to implement. More advanced/robust approaches could be added later.
I still think the 'DFU via bootloader' is the best approach in terms of functionality (option to upload directly to slot0, good error reporting in the manifestation phase, good recovery mode). But it is also the most difficult to implement correctly (especially the 'enter bootloader' bit). So that's why I'll start work on the other approach.

The 'DFU via bootloader' might be a closer match for usb, not for ble. As you add more and more communication methods to the bootloader it's size and complexity increases. I prefer a bootloader that does almost nothing, but does this good.


Fix issues for OCP4 migraiton

SecureImage 1.0.5
Build 21

Update UI to have a light appearance;
Update SSO to new prod URL;
Update API to new;
Add text to email indication album link expiration;
Update build and version umbers.

Fixed #11

@jleach changes reviewed without testing as my environment not yet set and need your help as discussed before

@jleach changes reviewed without testing as my environment not yet set and need your help as discussed before


Fix long name ui issues and label ui issue

This PR fixes some ui problems as mentioned in the two issues below.

Long file path has no word break

Before

After

on mobile

Texts in labels

Before

After

with two labels

In explore and star pages

Long name repository on creating new fork page

Before

After

Closes #23535
Closes #23534

should we backport to 1.19?

:trumpet: :robot:


[BUG] Any test should be skipped if the dependency tools for that test are not installed

Describe the bug
Any test should be skipped if the dependency tools for that test are not installed
To Reproduce
Steps to reproduce the behavior:
Install a CNF with dependencies
Run test: e.g. reasonable_image_size
If the dependency is not installed and cannot be installed then the test fails.
Expected behavior
The test should be ignored if the dependency is not installed.

@wavell @HashNuke @agentpoyo Is this issue still relevant?


Delegate reimbursement import to Celery

This is a work in progress, I just created it earlier to have feedbacks. The aim, when complete, is to address part of #217.
What is the purpose of this Pull Request?
The purpose of this PR is make the process of importing reimbursement quicker and without manual steps as described in #217.
What was done to achieve this purpose?
I introduced Celery to perform some task asynchronously: that way the heavy work of the import is handled in the background.
How to test if it really works?

Install RabbitMQ if not using Docker — brew install rabbitmq or apt-get install rabbitmq-server should do the job for macOS and any Debian based Linux such as Ubuntu (Docker environment is ready, no need to worry about it)
Install new packages: $ python -m pip install -U -r requirements.txt
Run tests $ python manage.py test
Get Celery started: $ celery worker --app jarbas
Run reimbursement import: $ python manage.py reimbursements <path to reimbursements.xz>

Who can help reviewing it?
@jtemporal @lipemorais @davinirjr @augustogoulart @adrianomargarin
What is out of scope
In #217 I mentioned creating a API endpoint so Rosie can send POSTs with reimbursement data. I think this is an issue for a new PR when this one is finished, reviewed, stable an merged.
Next steps in this PR

[x] Find out why the iteration is taking so long for each CSV (.xz) line (either I screwed up when wiring up Celery, or the serialize step is another bottleneck; if so, a callback in Celery should be able to handle serializing and then the create/update step)
[x] Improve documentation on the RabbitMQ and Celery parts (I added bit on the environment variable, but instructions to run Celery still missing as well as pointing RabbitMQ as a requirement)

Next steps

Bring back Docker Hub images to docker-compose.yml after this PR is merged

Testing with sample data seems Ok. Ready to Merge.

Testing with sample data seems Ok. Ready to Merge.

In PVT @decko told me that actually it wasn't working with the Celery (worker) running in a container. So we still need to fix that before considering merging it. Is that right?

Ok… I'm back to this PR.
I merged the novelties from master branch and studied this PR a bit more to advance it further.
The master branch imported the sample in 34s (counting the time to start Docker containers) and this branch did it in 24s (idem). We were saving 30% of the time, which is great.
Then I moved the serialize part to the async task (42e512a). The importing command took 15s — we're saving more than 50% of time now, yay!
From that I think the Celery part is indeed working and this PR is good for code review and, if that's the case, merging… cc @anaschwendler

Hello @cuducos and @decko!
I'll start testing this PR little by little and how (so it will be edited along the way):

Clone the repository:

$ git clone git@github.com:datasciencebr/jarbas.git

Open the repo folder:

$ cd jarbas

Checkout to @cuducos branch:

$ git checkout -b cuducos-celery origin/cuducos-celery

Update the branch:

$ git merge master

I'll try to run with Docker, even if its showed without, I'll try :)

Nice! Good work, people, congrats!


isTaskReadyFunction failing randomly

Which package is this bug report for? If unsure which one to select, leave blank
@crawlee/core
Issue description
How to reproduce:

Running the code with gc exposed. (it is the same without gc exposed)
It appears randomly, sometimes after the first request, sometimes after 20+k requests, but I could never pass 50-55k requests.

Here is the error:
ERROR CheerioCrawler:AutoscaledPool: isTaskReadyFunction failed
  SyntaxError: Unexpected end of JSON input
      at JSON.parse (<anonymous>)
      at RequestQueueFileSystemEntry.get (/Users/user/project/node_modules/@crawlee/memory-storage/fs/request-queue/fs.js:19:21)
      at async RequestQueueClient.listHead (/Users/user/project/node_modules/@crawlee/memory-storage/resource-clients/request-queue.js:147:29)
      at async RequestQueue._ensureHeadIsNonEmpty (/Users/user/project/node_modules/@crawlee/core/storages/request_queue.js:610:101)
      at async RequestQueue.isEmpty (/Users/user/project/node_modules/@crawlee/core/storages/request_queue.js:526:9)
      at async CheerioCrawler._isTaskReadyFunction (/Users/user/project/node_modules/@crawlee/basic/internals/basic-crawler.js:710:38)
      at async AutoscaledPool._maybeRunTask (/Users/user/project/node_modules/@crawlee/core/autoscaling/autoscaled_pool.js:481:27)

I don't know if there is any method of handling this error so it doesn't kill my script completely.
Code sample
Here is my main.js:
// For more information, see https://crawlee.dev/
import { CheerioCrawler, createCheerioRouter, purgeDefaultStorages, log, LogLevel, KeyValueStore } from 'crawlee';
import { router } from './routes.js';
log.setLevel(LogLevel.DEBUG);
console.log('Purging local storage')
await purgeDefaultStorages();

const crawler = new CheerioCrawler({
    requestHandler: router,
    minConcurrency: 10,
    maxConcurrency: 50,
    maxRequestRetries: 20,
    useSessionPool: false,
    failedRequestHandler({ request }) {
        log.debug(`Request ${request.url} failed 20 times.`);
    },
});
await crawler.run(['https://www.somewebsite.com']);

Here is my routes.js :
 { Dataset, createCheerioRouter, EnqueueStrategy } from 'crawlee';

export const router = createCheerioRouter();
global.productsCount = 0
router.addDefaultHandler(async ({ enqueueLinks, log, request }) => {
    log.info(`Navigating to ${request.loadedUrl}`);
    await enqueueLinks({
        globs: ['**/i/**'],
        label: 'product',
        strategy: EnqueueStrategy.SameHostname,
    });
    await enqueueLinks({
        globs: ['**/c/**'],
        strategy: EnqueueStrategy.SameHostname,
    });
    global.gc();
});

router.addHandler('product', async ({ request, log, session, body, $ }) => {
    log.debug(`${$('title').toString()} || scraped`)
    await Dataset.pushData({
        url: request.url,
        html: body,
    });
    global.productsCount ++
    log.info(`${global.productsCount} products scraped`)
    $ = null;
    body = null;
    global.gc();

});```

Package version
<EMAIL_ADDRESS>Node.js version
v19.6.0
Operating system
MacOS Ventura 13.1
Apify platform

[ ] Tick me if you encountered this issue on the Apify platform

I have tested this on the next release
No response
Other context
No response

Moved my testing to a different machine.
Pop!Os 22.04 LTS ( Intel Xeon E5-2696 v4 (44) @ 3.700GHz , 32GB RAM )
issue occured much later, searched manually in the request_queues for an empty json, deleted it and I could resume my job.
I was thinking maybe we can somehow handle this situation, for example if an empty json is detected just delete it and restart the process !

@vladfrangu this is an old bug that we fixed by introducing SQLite. Without it, it was almost impossible to ensure that there won't be file system race conditions. I would see if request queue v2 helps with it thanks to locking. Still, I thought that with memory storage now, all operations happen in memory only, so this should never happen. That files are written (for backup), but not read during run time.
@dragospopa420 You can use https://github.com/apify/apify-storage-local-js as your storage client to fix this (I hope) and then inject it with configuration.
import { Configuration } from 'crawlee';
import { ApifyStorageLocal } from '@apify/storage-local'

const storageClient = new ApifyStorageLocal();

Configuration.set('storageClient', storageClient);

Please try above, but I can't guarantee it will work, because I haven't tested it in months.

@mnmkng yeah, I've noticed that.. that said, I have an idea of how to try to tackle this issue (but I feel like it'll cause slowdowns for those using persistStorage, but its a small perf penalty for fixing this race condition)

In relation to that above, one solution is setting persistStorage to false (see https://crawlee.dev/docs/guides/configuration for how to do that).

@vladfrangu this is an old bug that we fixed by introducing SQLite. Without it, it was almost impossible to ensure that there won't be file system race conditions. I would see if request queue v2 helps with it thanks to locking. Still, I thought that with memory storage now, all operations happen in memory only, so this should never happen. That files are written (for backup), but not read during run time.
@dragospopa420 You can use https://github.com/apify/apify-storage-local-js as your storage client to fix this (I hope) and then inject it with configuration.
import { Configuration } from 'crawlee';
import { ApifyStorageLocal } from '@apify/storage-local'

const storageClient = new ApifyStorageLocal();

Configuration.set('storageClient', storageClient);

Please try above, but I can't guarantee it will work, because I haven't tested it in months.

Will try it on new jobs later tonight, the jobs that were running when I first encountered this issue are still runing.
One offtopic question, with this storage client can I also store somewhere else ? Like an S3 or something similar ?
I couldn't find anything in the docs.

One offtopic question, with this storage client can I also store somewhere else ? Like an S3 or something similar ?

Not with this one particularly, but you can create your own plugin while respecting the StorageClient interface.
@B4nan how difficult would it be to support not only a StorageClient plugin but also the lower level ones like DatasetClient. Because now adding a custom plugin is quite difficult because you need to override everything, but it would be nice if we could override just Dataset where .pushData() would then push to S3 or something like that, without touching the other storages.

I think you could extend the storage and only reimplement e.g. the dataset client. This is one of the things I'd like to improve in v4, simplify interfaces and extension in general, and provide other storage clients (e.g. postgres). This abstraction should be ideally much less tied to the apify platform.


[Enhancement](jdbc catalog) Change Jdbc connection pool to hikari

Proposed changes
Issue Number: close #xxx
pick #34045
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


Error when starting storybook

Working commit - 876797fc5af410d386cba2dab4ab2889

rm -rf node_modules
yarn
yarn storybook

This is working

Identified commit where error introduced - b497fb6580db0c4edad249000f6ab00640b6e425

rm -rf node_modules
yarn
yarn storybook


Update config.yml

Description
This PR fixes #193
Notes for Reviewers
Updated Layer5 to Meshery Community!!
Signed commits

[ ] Yes, I signed my commits.

@ShivangShandilya Could you please add the following line too after the  tag?
  	   	   	   	 [Join the community](http://slack.layer5.io), if you haven't yet and please leave a :star: [star on the project](../stargazers). :smile:

@ShivangShandilya Could you please add the following line too after the tag?
  	   	   	   	 [Join the community](http://slack.layer5.io), if you haven't yet and please leave a :star: [star on the project](../stargazers). :smile:

(Just copy paste the exact same format, with   etc..)

Done


chore: remove usage of std::mem::forget

It's not clear to me on why we "forget" the CRS, PK, constraint systems and witness. I remember that previously Barretenberg would have some singleton instance of the proving key, etc. which would make some sense. We don't do this anymore and in any case, we pass in new values for each of these on every call so I don't see any reason to not to free these resources.

Well this was good timing :sweat_smile:


Update to Godot 4.2

Godot 4.2 changes up the Graph Editor system that Quest Manager node relies on to work. Working on updating it to 4.2

Main Branch now updated for Godot 4.2


Columns to be included in the prevalence data table

•Jahr
•Mikroorganismus
•Probenursprung (Tier/Lebensmittel/Futtermittel)
•Probenahmestelle
•Matrix
•and all numeric columns

We currently have a mix of lanuguages. I am not sure whether this is a possibility at the moment to have just one language on display?


Concurrent queries

Very nice concept, was wondering if you've considered keeping the db connection open and implementing a connection pool to allow multiple queries to run at the same time?

The use case I have in mind currently is a lightweight reverse ETL to make aggregated data available to internal tools used by multiple users at once.

We can implement the same method we had in chdb where providing auth produces a semi-persistent query session allowing multiple interactions as opposed to running individual queries. Will add to the roadmap.

@loicalleyne this is now partially supported through authenticated sessions which use filesystem storage (WIP) so it should be fine for reading in parallel (not writing yet)


fix: landing page header bug fixed

Description

Fixes width bug on landing page phone view

Issue(s)
Fixes #
How to test

Go to https://deploy-preview-1904--oak-web-application.netlify.thenational.academy
Click on _______
You should see _______

Screenshots
How it used to look (delete if n/a):

How it should now look:

Checklist

[ ] Added or updated tests where appropriate
[ ] Manually tested across browsers / devices
[ ] Considered impact on accessibility
[ ] Design sign-off
[ ] Approved by product owner

:tada: This PR is included in version 1.240.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


docs: create Lumberjack documentation website

The Problem
Lumberjack doesn't have a proper documentation website.
The Goal
Create a Lumberjack documentation website like the spectacular one.
Tasks

[ ]  Create and configure Docusaurus documentation website
[ ] Deploy to Github Pages
[ ] Configure CI/CD
[ ] Write proper documentation using the tools format

See spectacular-docs.


adding decorators plugin

Hi @joshbolduc 😀
sometimes we declare auxiliary components directly in stories
for example, when we want to write a history for a directive
@Component({
    template: '<div my-directive></div>',
})
class MockComponent {
}

export default {
    title: 'Components/Menu/IframeMock',
    component: MockComponent ,
} as Meta

export const Default: Story<MockComponent > = () => ({})

I found that the extension does not find such stories.
I debugged the code and realized that it is necessary to add decorators support for parsing
after that change, all my stories are displayed in STORY EXPLORER

This is great, thanks for the contribution!


Update Waukesha County, Wisconsin City and Unit

# us-wi-waukesha-1544625287195.geojson.gz
ok - 206394/206875 (99.7%) valid addresses
ok - 0 outside of boundary (dropped)
ok - 339 have an unsupported number format
ok - 1 are missing street names
ok - 0 could not be parsed
ok - 141 suffered misc failures


Generate new demo certs with IPv6 loopback added to SAN in node certificate

Description
This PR solves bug where backwards compatibility tests would fail for IPv6 loopback address (::1) with:
No subject alternative names matching IP address ::1 found

Category: Maintenance

Exit criteria:

[x] BWC tests should no longer fail with the above error.

Issues Resolved

Resolves: https://github.com/opensearch-project/security/issues/3174

Testing
Manual testing
Check List
~- [ ] New functionality includes testing~
~- [ ] New functionality has been documented~

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Looking into plugin-install failures now. Seems like we need to generate a new JKS file for sanity tests since the certificates were updated.

We should not ship ChecksumCalcuator as part of the plugin distribution, its purpose is to automate making changes in the java code, not something a consumer of the plugin would need.

Agreed. I have added a section in Developer guide on steps to refresh demo certs.

@DarshitChanpura Is there any way to 'diff' the certs?
i.e. I'd like to verify that the only differences are:

Issue date
Expiry date
the SAN in the updated certs is mostly the same, but in the new certs it contains the IPv6 loopback address (::1)

@cwperks What do you think is missing?  By virtue of BWC tests passing, and Plugin Install passing - I am assuming they work.

@peternied Just trying to cover all the bases. This PR looks good to me.

Unfortunately this has generated an already expired root CA certificate : valid from 29/08/2023 to 28/09/2023


fix exception when messageset is too large for decode buffer

new exception does not inherit from ProtocolClientError, removing ambiguity about whether this error originated at the broker or the client
fixes #697

Codecov Report

Merging #713 into master will decrease coverage by 0.07%.
The diff coverage is 75%.

@@            Coverage Diff             @@
##           master     #713      +/-   ##
==========================================
- Coverage    84.1%   84.02%   -0.08%
==========================================
  Files          26       26
  Lines        3373     3375       +2
  Branches      539      539
==========================================
- Hits         2837     2836       -1
- Misses        393      397       +4
+ Partials      143      142       -1

Impacted Files
Coverage Δ

pykafka/exceptions.py
100% <100%> (ø)
:arrow_up:

pykafka/protocol.py
96.66% <50%> (ø)
:arrow_up:

pykafka/connection.py
77.65% <0%> (-2.13%)
:arrow_down:

pykafka/simpleconsumer.py
82.1% <0%> (-1.23%)
:arrow_down:

pykafka/balancedconsumer.py
90.26% <0%> (+0.29%)
:arrow_up:

pykafka/rdkafka/producer.py
88.17% <0%> (+0.31%)
:arrow_up:

pykafka/cluster.py
71.73% <0%> (+0.43%)
:arrow_up:

pykafka/managedbalancedconsumer.py
80.55% <0%> (+0.69%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 878b1ff...92b75f3. Read the comment docs.


Texture mode issues

Thanks for putting out this code.
I was able to get the MappingMode = VERTEX to texture OK, but TEXTURE mode produces very messy textures with lots of occlusions and missing & mixed up parts ( see images ) It seems no part of the image is being correctly projected into the texture. ( see attached ) I've tried various permutations of the parameters like photoconsistency, ca_mode, etc with no luck. Was there some particular setting regime where you had success with this code? I think square images also might be required.
I might start digging in further but curious if you had any tips.
Thanks
TEXTURE MappingMode

VERTEX MappingMode

INPUT

The output customized texture （fileNameTexOut） is a no-color picture, and the textured model is without any color. I got similar results with you, and I do not know why. Hope Rafael Pages can help me.


test

Describe the bug
test
Link to the blitz that caused the error
https://stackblitz.com/edit/node-bvbnbr?file=index.js
Steps to reproduce
ttt
Expected behavior
ttt
Parity with Local

[X] I have run the project in my local machine and I could not reproduce the issue.

Screenshots
ttt
Platform
Browser name  = Chrome
Full version  = 102.0.5005.63
Major version = 102
navigator.appName = Netscape
navigator.userAgent = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.5005.63 Safari/537.36
performance.memory = {
  "totalJSHeapSize": 54783829,
  "usedJSHeapSize": 49235421,
  "jsHeapSizeLimit":<PHONE_NUMBER>
}
Hash = ad37e903755d89e0f5d9999e69be73a0c6cb6bcc

Additional context
ttt

Closing this issue as it's unclear what goes wrong and none of the required details are filled in. Feel free to open a new issue and fill in all the necessary details so we have enough information to have a look ourselves. The more information we have, the better we can help you 🙏 .


Acces to the full ajax response from the onEnd callback

I found myself in need to access the full ajax response within the onEnd callback so i added it as an extra parameter. If you run the smootstate on the body container and want to copy the new body classes from the ajax response (for css styling to stay intact) then this looks like a logical way to achive this. Well at least for me. This might even have other use cases. For example hooking into changes in het html header.

+1 This is excellent @jorisvm — thanks brother! Can we get a merge on this?

+1, this is an excellent addition to the plugin. I hope it is merged soon!

@jorisvm thanks for this, merged!

Excellent!!!

Great!

It looks like the onEnd callback has been removed, and the onReady callback does not contain the full HTML response. Any way to get this back?

@daltonrooney see my answer to this here; https://github.com/miguel-perez/smoothState.js/issues/103#issuecomment-160401967

Why was this removed?


iFrameDialog with /Lists/../NewForm.aspx?env=WebView is not closing when hit Save/Cancel

Category
[X ] Bug
[X ] Question
Expected / Desired Behavior / Question
When loading the url /Lists/../NewForm.aspx?IsDlg=1 (showing the classic form definition), hitting save/cancel will close the dialog due to these additional functions. https://github.com/pnp/sp-dev-fx-controls-react/blob/66d8dbed9b61cb51e294b52c90e690c5620665d7/src/controls/iFrameDialog/IFrameDialogContent.tsx#L41
When using the new url /Lists/../NewForm.aspx?env=WebView (for modern forms) these methods are not called anymore.
ps. Modern forms can only be used for newly created lists, lists created in the past (not sure what timeframe) only have the classic form definition.

Im in need of this too. Looking for a way to handle modern form submit/close events

Hi @mdissel & @Vertamin,
I'm not sure that modern list forms provide such param / info to be displayed as a pop-up, since it's not an option anymore in this context.
@AJIXuMuK maybe you have info regarding this?


Get-HotFixList misses updates

I ran the script on a Server 2022 system with KB5033118 installed. Since this update apparently doesn't create a registry key in the expected format Get-HotFixList misses this update.
As far as I can tell parsing update information from the registry is an unsupported hack, so I think it would make sense in the long term if the script parsed both the registry and Get-HotFix, and warn the user if Get-Hotfix shows an update not collected from the registry.

You are making a good point. I already noticed this discrepancy between the official Get-HotFix and the data present in the registry.
Your proposition makes sense, but I might also just get rid of the custom registry parsing altogether.
Thanks for taking the time to report the issue. I'll see what I can do.

Should be fixed with commit 373014d6a7fb8a90e4599fab196366e3d8563539.


Update Readme

The readme should talk about the website and podcast, not the Jekyll theme.

This is done.


Allow inject connector from ElasticSearch till Connection

Related with this PR1[1], it enables inject from the upper layer the adhoc Connection class
[1] https://github.com/aio-libs/aioes/pull/137

Codecov Report

Merging #138 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #138      +/-   ##
==========================================
+ Coverage   81.09%   81.09%   +<.01%
==========================================
  Files          23       23
  Lines        3533     3534       +1
  Branches      725      725
==========================================
+ Hits         2865     2866       +1
  Misses        389      389
  Partials      279      279

Impacted Files
Coverage Δ

aioes/transport.py
83.33% <100%> (+0.09%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a9e2e6a...0bb6dd4. Read the comment docs.

@popravich can you take a look to this MR?
Also, I would like to ask you for a favor. could you publish a new release with the last two changes?
We are having a lot of issues with the default aiohttp Connector, that uses the default DNS resolver and a forerver cache table. We have implemented our TCPConnector - I expect that this finally will be also merged in the 2.X series of aiohttp, but due to the current architecture of aioes we can not inject our own implementation.
In any case, thanks in advance!

Please add test also.

@popravich done.

Thanks

you welcome, any chance to get a 0.7.1 release? otherwise, any ETA?

Ok, I will do a release in a several hours


Helm upgrade points to old service account and fails with missing token

Output of helm version: version.BuildInfo{Version:"v3.9.4", GitCommit:"dbc6d8e20fe1d58d50e6ed30f09a04a77e4c68db", GitTreeState:"clean", GoVersion:"go1.17.13"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.2", GitCommit:"5835544ca568b757a8ecae5c153f317e5736700e", GitTreeState:"clean", BuildDate:"2022-09-21T14:33:49Z", GoVersion:"go1.19.1", Compiler:"gc", Platform:"windows/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.12", GitCommit:"2cb4598553d0a2ca5f3eb7980c99cd8236cc5011", GitTreeState:"clean", BuildDate:"2021-06-16T12:52:44Z", GoVersion:"go1.15.13", Compiler:"gc", Platform:"linux/amd64"}
We have a application that generates a service account using the following yaml file:
{{- if not (lookup "v1" "ServiceAccount" .Release.Namespace (.Values.serviceAccountName | default "service-account")) }} apiVersion: v1 kind: ServiceAccount metadata:   labels:     app.kubernetes.io/instance: instancename   name: {{ .Values.serviceAccountName | default "service-account" }}   namespace: {{ .Release.Namespace }} {{- end }}
When we do helm install the first time it works without any issues. But when we try to do helm upgrade, it gets stuck in the containercreating stage with the following message
 Warning  FailedMount  5s (x5 over 13s)  kubelet            MountVolume.SetUp failed fo │ │ r volume "service-account-token-xxxxx" : secret "service-account-token-xxxxx" not found
The old pod keeps running without any problem. This only happens with helm upgrade, running helm uninstall and helm install fixes the issue. I would appreciate any help or suggestions. Please feel free to ask for any more information you might need.

Thank you, we have figured out the solution thanks to your reply.

yes,  very simplified , but you can imagine that install/upgrade is helm template then  kubectl apply the generated yaml

Thank you


added to_string_hex functions to UInt modules

Please review. I have not extensively tested this.

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

Hi Karthik. After #1850 our machine integers are now all coming from stdint, so this patch fails since it requires using OCaml's int type.
I can export Stdint's to_string_hex very easily, but the behaviour is slightly different. For instance, for 15 it would print 0xf instead of 0f (it has a leading 0x, and does not group by octets).
Would that work? Otherwise we can roll our own hex-printing function, because it doesn't seem stdint exports one similar to the your printf implementation.
Also, Stdint can work for negative numbers. Printing (-1) gives -0x1.

Generally it is preferable to print “0f” so that we can easily print a sequence of integers in hex.
But 0x0f may be ok too, so that we can easily get rid of the 0x outside if need be.
0xf is quite the worst.

On 16 Mar 2020, at 15:25, Guido Martínez<EMAIL_ADDRESS>wrote:
Hi Karthik. After #1850 https://github.com/FStarLang/FStar/pull/1850 our machine integers are now all coming from stdint, so this patch fails since it requires using OCaml's int type.
I can export Stdint's to_string_hex very easily, but the behaviour is slightly different. For instance, for 15 it would print 0xf instead of 0f (it has a leading 0x, and does not group by octets).
Would that work? Otherwise we can roll our own hex-printing function, because it doesn't seem stdint exports one similar to the your printf implementation.
Also, Stdint can work for negative numbers. Printing (-1) gives -0x1.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/FStarLang/FStar/pull/1917#issuecomment-599565196, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFUVSZK3KVKD2TMDTPKOGLRHYZHPANCNFSM4KSMZ4GQ.

Yes, good points. Just wrote a fixed-width variant of to_string_hex without the leading 0x. Here's the generic implementation where n is the bitwidth of the integers.
let to_string_hex i =
    let s0 = M.to_string_hex i in
    let len = (String.length s0 - 2) in
    let s1 = String.sub s0 2 len in (* Remove leading "0x" *)
    let zeroes = String.make ((Z.to_int n / 4) - len) '0' in
    zeroes ^ s1

This should work as you intended. Pushing to master soon and closing this PR.
Note that your original patch was not fixed-width afaict, printing "10" on 64 bit integers (or any width) would have printed "0a". You will now get "000000000000000a" for 64 bits. Let me know if this is not what you meant.


added Yandex Data Streams support

Hello. This changes are need too if PR will merged.

Welcome @preved911! It looks like this is your first PR to falcosecurity/charts 🎉

Superseeded by #378

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten


✨ Toggle preview visibility in Quick Open overlay

Is your feature request related to a problem? Please describe.
Users should have the ability to hide overlay previews if preferred.
Describe the solution you'd like
There should be a toggle to turn on and off the preview at the top right of the quick open overlay.

Clicking this toggle, changes the symbols appearance and hides the preview as shown below.

Additional context
Xcode does this here:

When toggled off...

@austincondiff I'm pretty sure this is fixed, but this does bring up a new bug where the preview/text view turns blank when it is toggled.
https://github.com/CodeEditApp/CodeEdit/assets/128280019/1fad3b18-54da-4309-b9ca-5fb8d162a422

Closing as this is complete.


[Feature] Implement a new travel plan persistence index

Description
Clearly describe changes in your PR, new feature or bug fixes.
Solution

Design Doc

Testing

[x] Integration testing on Heroku staging
[x] Added new unit tests

Checks

[x] Have you removed commented code?
[x] Have you used gofmt to format your code?

LGTM


install does not abort when there is no npm

I am trying to get koel ready on my raspberry pi and found something intresting.
I didnt have npm yet on it and I got this in the shell:
my1@my1-pi:~/koel $ php artisan koel:init
Attempting to install or upgrade Koel.
Remember, you can always install/upgrade manually following the guide here:
📙  https://github.com/phanan/koel/wiki

App key exists -- skipping
JWT secret exists -- skipping
Migrating database
Seeding initial data
Executing npm install, gulp and whatnot
sh: 1: npm: not found

🎆  Success! You can now run Koel from localhost with `php artisan serve`.
Again, for more configuration guidance, refer to
📙  https://github.com/phanan/koel/wiki.
WIKI ROCKS WIKI RULES.
KTHXBYE.

the intresting part is that if npm is needed then usually it would have to abort, but well... it didnt.

npm is required obviously. From wiki:

Since Koel is written in Vue and Laravel, it is assumed that your server has npm and composer installed.

Yes, in an ideal world, Koel should check for each and every prerequisite. Our world is far from ideal, though ;)

"Since Koel is written in Vue and Laravel" well before seeing koel I never even have heard of one of those 2.
also when setting up a new system you might just have forgotten it.
by the way, is it normal that the init takes half an eternity (at least a night and it still isnt over) or is a raspi 1b just too weak?
it would be nice to have hardware requirements somewhere.

Please see the wiki: https://github.com/phanan/koel/wiki.

by the way, is it normal that the init takes half an eternity (at least a night and it still isnt over) or is a raspi 1b just too weak?

Something must have gone wrong then. init doesn't do anything time-consuming.

the wiki doesnt say anything specific about heardware requirements. just "a capable web server" but well what is "capable"?
well most of the time it's busy with the npm phase.

init runs npm install which is time consuming.


refactor(dsync): use object destructuring for request body

This PR addresses a code style issue in the index.ts file. Previously, we were accessing the body property from the req object directly. However, using object destructuring can make the code cleaner and easier to understand.
To improve readability, we've updated the code to use object destructuring when accessing the body property from the req object.
Changes include:

Updating the index.ts file to use object destructuring for the req object.

This change should make the code in index.ts easier to read and maintain.

I Run npm run format as per request.


chore: add Python 3.9 and 3.10 to Trove classifiers

updated classifiers
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

[ ] Make sure to open an issue as a bug/issue before writing your code!  That way we can discuss the change, evaluate designs, and agree on the general idea
[ ] Ensure the tests and linter pass
[x] Code coverage does not decrease (if any source code was changed)
[ ] Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> 🦕

@anukaal Thank you for the patch!


Introduce typescript types (possibly via conversion to typescript)

The original repository had types through DefinitelyTyped here.
Forking means the types won't have come through. We could:

Copy the definitely-typed types to this repo
Upload a copy to definitely-typed/commit-and-tag-version
Convert this repo to typescript

I think the smallest effort would be option 1. Long term, conversion to typescript would be ideal, because then we'd be able to merge #21, #19, #18 and #16, all of which require ESM.

Quick note (as you are probably aware): the types from DefinitelyTyped are pretty out of date (they are for v7.0.0)

Hi @TimothyJones ,
any updates about this?

I haven't had the chance to look at this one in detail, sorry. I think it needs some close attention. I would happily accept a PR if you have some spare capacity.
If not, even just looking at the definitely-typed types to see what needs updating would be helpful.

It's late here, so I'll be brief, but since you're actively working on this, I wanted to reply quickly.

I've started some work on option 3.

Firstly: <3 Thank you! This is amazing. If you have it on a branch somewhere, I could lend a hand / take a look etc - if you want.
In general I was hoping to do this without breaking changes - as in, changing the external behaviour or API.
I have a general philosophy of doing one thing at once, so as to keep the risk (and workload) down. However, if you think it's not possible to avoid bringing in several changes, then feel free to use your judgement.
(Aside: the original author for this project was also the author of yargs (at least, I think I have that right), so I would imagine it was chosen due to familiarity and preference)
It would be good to redo the way that options are handled, as at the moment there isn't consistency in the options available via CLI or config file. There's some context here and on the linked issues from there. I don't mind replacing yargs, but it would be great to use whatever is best for supporting fixes for those issues.
My gut feel is that it might be more practical and safer to force the typings for yargs with as, any etc (as long as we can keep that constrained to one or two files) in order to get Typescript going, and then do the refactor to commander (or whatever) after.

or general guidelines for other dependency updates I might encounter?

I have two main concerns - firstly, I'd like to prioritise maintainability - part of the reason that I'd like to bring typescript in is to reduce the risk of small changes introducing big mistakes (since this project is pretty stable, it's likely to receive more small changes than big, in general - the safer we can make those, the better).
Secondly, a big refactor to typescript is going to touch both the tests and the implementation - and changing both together is pretty risky. I think it would be best to avoid changing too much of the implementation at the same time as we touch the tests.
It would be great to have a point in the repo where we can say "here's a working version where we brought in typescript" and then one where we can say "and here's where we swapped to better dependencies for typescript" - even if there's no release between the two. I like this as the path-of-least risk, but of course there may be some reason it's not practical to do it that way.
Update: I was not brief 😂

Haha! Thanks for the quick and thoughtful response, though!
Breaking Changes
I think you're right about trying to isolate changes to the type layer. Ultimately, may be impossible to fully type everything without run-time changes, so on the first pass I'll probably have to use some anys where there's ambiguity that a type-cast can't solve.
My approach will be to get to 100% type coverage without touching any test files, ensuring run-time semantics are consistent. I'll file issues (or a super-issue?) to track any unsafe type compromises that must be made.
Options
As for https://github.com/absolute-version/commit-and-tag-version/issues/31, that will necessarily involve breaking changes. I realized this as my initial optimism about switching to commander without breaking changes began to fade when I got to types option, which is an array of objects.
Commander doesn't account for object-typed values at all, but objects can be worked around with dot notation. Unfortunately, an array of objects is off the table without some pretty funky CLI syntax.
That said, I've already done a little playing around with the swap... would it be a good idea to close https://github.com/absolute-version/commit-and-tag-version/issues/31 with a breaking change before the TS refactor?
Roadmap
It seems to me that introducing TS to popular JS libs increases their popularity. Closing https://github.com/absolute-version/commit-and-tag-version/issues/31 means a major API change for both the CLI and the JSON config. It would make commit-and-tag-version no longer backward-compatible with scripts and config files for standard-version or any version of commit-and-tag-version prior to the breaking change.
If that's on the roadmap, I would argue that making such a change now would have less downstream impact than doing so after this fork sees wider adoption.

I'll file issues (or a super-issue?) to track any unsafe type compromises that must be made.

Please feel free to do so!

Commander doesn't account for object-typed values at all,

For some things, it's hard to do via a CLI without resorting to json (which is pretty unpleasant in a CLI). I don't mind if those need to be specified by config - if it's going to be clumsy to specify via CLI, then a hybrid approach would be the most ergonomic for users. One drawback of the current implementation is that it doesn't always support combining options in config and CLI (see #28)

That said, I've already done a little playing around with the swap... would it be a good idea to close https://github.com/absolute-version/commit-and-tag-version/issues/31 with a breaking change before the TS refactor?

Yes, I think this makes a great deal of sense.

It seems to me that introducing TS to popular JS libs increases their popularity.

This is another good reason :) As far as I can see from searching npm, this is the most popular fork.

Closing https://github.com/absolute-version/commit-and-tag-version/issues/31 means a major API change for both the CLI and the JSON config.

Perhaps I'm missing something, but why would it be a breaking change for the JSON config?

a transform on JSON options to normalize them to the types received by CLI args

Ah! So, I had assumed that whatever format the CLI library outputs would be irrelevant from the perspective of the rest of the code. As in, we would bring options in from (potentially) a few different sources, and populate a config object. This object would probably the same as the format for the JSON config (so there isn't need for another mental model).
This approach would also mean that only one file would have to change if we ever wanted to replace the CLI args library again - and it would keep the reading of the package.json and any version.rc files / future alternative config sources independent.
It would look something like:
// Assuming combineConfig(newConfig, currentConfig) => Config

const config = combineConfig(
  readCliConfig(),
  combineConfig(readPackageConfig(), defaultConfig)
);

It would make commit-and-tag-version no longer backward-compatible with scripts and config files for standard-version or any version of commit-and-tag-version prior to the breaking change.

I don't mind making breaking changes if there's a clear reason to do so. And, we might be able to get pretty close for most common options.
I prefer releasing minor well-documented breaking changes, over bending the API out of shape to avoid making them. I've already released breaking changes since forking, and according to the npm stats, the current major release is the most popular, so people are comfortable migrating.

Edit: Maybe I can fix [...]
Edit edit: Nah, not that easy.

This is very relateable 😎

I am a huge fan of Typescript and would love to see this get converted.  Has there been any progress made?  I would love to help.

I believe we came to the conclusion that we would consider #31 to be a blocker to this (see also: #28 for context). I spun up a codespace that has some playground work, but I was hoping for a bit more feedback before just going cowboy with the API 😆

I don't see #31 as a blocker.  It's a little more complex, but definitely possible.  I'll look into it and see what I can figure out.

Just throwing around this but I'm working on a future pr over a fork, its pretty early but anyone interested to throw suggestions that can benefit the "refactor" watch this

I've got a start on this here #68, and I've taken fewer liberties with the project config than @D4RKAR117.
@D4RKAR117 Can I recommend trying to keep commits focused around a very specific goal? It's really hard to tell what changes you've made that actually relate directly to TypeScript conversion. It looks like a lot of project-config changes that haven't been discussed by anyone so far.

I've got a start on this here #68, and I've taken fewer liberties with the project config than @D4RKAR117.
@D4RKAR117 Can I recommend trying to keep commits focused around a very specific goal? It's really hard to tell what changes you've made that actually relate directly to TypeScript conversion. It looks like a lot of project-config changes that haven't been discussed by anyone so far.

Oh, I didn't see #68 before. You have advanced much
I'm trying to focus to move the entire lib to esm and typescript in all front including testing suite, but without directly modifying the internal logic  (dome times it's needed to, but the result is the same (I hope)), so when everything is typescript compliant can we reuse test to check if the migration its successful

@D4RKAR117 I don't disagree with your goal - I just think that what constitutes a 'modern compliant typescript library' might differ from one person to the next, so it's best to stick to what is obvious.

@D4RKAR117 I don't disagree with your goal - I just think that what constitutes a 'modern compliant typescript library' might differ from one person to the next, so it's best to stick to what is obvious.
edit: updated the name for the branch, new draft PR is #69

Yeah absolutely, it's kinda a subjective topic to discuss, but it's always refreshing to have different approaches

Thanks for the link @D4RKAR117. I took a look, and from a quick read it looks like good work. I appreciate you taking the time.
I'm a little confused about a new branch being started when there's quite a bit of discussion about the work already in progress already, both above and on the linked issues - but perhaps you didn't see it beforehand or something.
I don't want to discourage new contributions or contributors, but also having two people work on separate branches to do the same thing runs the risk of both becoming demoralised and not finishing either. For this reason (and given the extensive discussion we've had already), I'm inclined to prefer the branch that @helmturner is working on already.
However, I also see that this is your second public fork - I don't know if you're new to open source or not, and I don't want you to feel that your efforts are lost or aren't appreciated. If you would be interested, I could review your branch as if I were considering it for merge. This way you would still get the feedback that you would normally get.

Yeah, i didn't see the branch of @helmturner before starting mine, i just use this lib extensively on my projects and saw this issue, and yeah kinda new to open source collaboration.
So due to that branch, it's fixing more problems than mine (like console args parsing). i will close mine and focus the effort to help on other approaches.
Keep the good work

Thanks for being so understanding!

@D4RKAR117 I noticed that you dropped a vitest config file in there - did you ever get testing with vitest working? Currently we're hitting a build error when running the tests because it's trying to test not-yet-transpiled .ts files. Switching to vitest would be a big help, but I figured it would take a complete rewrite of the testing suite. Is there anything you found out in your refactor? If you have vitest working as a replacement for mocha, that would certainly be worth a PR!

Since we have (at least) three people working on typescript conversion, would it be simpler to have a branch created on this repository that we all can submit pull requests too?
I think that will help keep the number of conflicts low.  Once we have it finished, we can merge into master.

@SharpSeeEr Due to the highly integrated nature of the conversion, I think it's best to coordinate our efforts as tightly as possible. I would recommend keeping a separate fork or branch that we can compare across so that we can sound the bells if one of us starts doing conflicting or duplicate work. We should check in and review often, and merge changes from each other's branches frequently. I think broken code should only be allowed on WIP branches with a single author.

Yes, definitely work in separate forks and branches, but if we open a PR to merge our changes into the cli-update-and-typescript-conversion-wip branch in this repo, that will actually help keep us from stepping on each others toes without having to manually do comparisons.  Keep the PR's small, like converting one file, and it should work fairly smoothly.
In the end, I know you guys are the project maintainers and I am a new contributor, and I will follow your lead on how we handle all this.

Lol, I'm a new contributor as well! 😌 Teamwork!

@D4RKAR117 I noticed that you dropped a vitest config file in there - did you ever get testing with vitest working? Currently we're hitting a build error when running the tests because it's trying to test not-yet-transpiled .ts files. Switching to vitest would be a big help, but I figured it would take a complete rewrite of the testing suite. Is there anything you found out in your refactor? If you have vitest working as a replacement for mocha, that would certainly be worth a PR!
Edit: To be fair to @D4RKAR117, I don't think I had submitted the draft PR when he started, so they would have had to find the branch on my fork (which would not be likely stumbled upon).

Yeah i achieved many times migration from mocha to vitest due it helps to no transpile test and even test type assertions, but that requires at least top level modules/exports to be changed to esm. the problem here is that a lot of code, (i.e: updaters) code its tightly coupled to some old ways to resume modules like dynamic requires and many of the code i reviewed can be async tho. so for the test must taken in consideration tho

Just opened a PR for this.  It's pretty much a full conversion at this point.  Took me all day today, but I got there.  Needs some review for some parts I didn't know what to do with.

Sorry for falling off the cliff here... life got a bit crazy for me. Still is TBH but I'm starting to feel guilty for letting this hang so long 😅
Fortunately, however, I've learned a lot since then. This YouTube short is a gem - everyone in this thread should invest the 40s to watch it.
Beyond that, however, I've identified the biggest problem we face here (and a practical solution).

The Problem
The technical debt on this code-base is real. Most of the issues we have faced (and will continue to face) stem from this being written pre-ESM and before TS became a best practice. It's pretty hard to do anything incrementally because of cascading issues that arise throughout the rafactor.
The solution
It recently dawned on me that the best way to convert any codebase to TS is to start by.... not using TS. I think JSDoc types are the way to go here (at least at first):

You can write them in JS files
They give the same auto-complete and tooltips
Errors can be highlighted without enforcement (Just set noEmit and add tsc to the test flow - no build step needed)
ChatGPT can translate TS types to JSDoc for any authors unfamiliar with it
Converting to actual TS is as easy as changing the file extension and using VSCode to auto-annotate from the JSDocs

Bonus: Comments are encouraged, and they show up in the tooltips.

I've submitted a draft PR where I've done more than half of the work on a minimal 'migration'. The commits are split such that all of the "free lunch" types are in one commit, and the types that weren't so straightforward are separate. I'll continue poking at the errors and see how far I can get, but despite the type errors it still passes tests, and it should build no problem.

Lol @TimothyJones... couldn't help but notice you started contributing to release-please not long after your last commit-and-tag-version release. Assuming you've been using it, do you see any real advantage to CATV over Release Pleases?


Question: error flag in rmqamqp::TopologyTransformer::processReplyMessage

Here the code just returns false without setting the error flag d_error:
https://github.com/bloomberg/rmqcpp/blob/becec1737669dbebb0a108e9dd0244b294951633/src/rmq/rmqamqp/rmqamqp_topologytransformer.cpp#L114-L116
In other places in this procedure the error flag is set to true when some problem occurs, for example:
https://github.com/bloomberg/rmqcpp/blob/becec1737669dbebb0a108e9dd0244b294951633/src/rmq/rmqamqp/rmqamqp_topologytransformer.cpp#L118-L123
Is it intended behaviour in the first code example? So, basically, returning with false there is not an error situation?

Good catch, I think initially there was no such variable and this method would return whether there was an error or not, so it wasn't required, but later added for performing updates, it should be safe to set it here.


uninitialized constant ActionView::FileSystemResolver (NameError) in rails 4.1.0

Hi,
I've upgraded my application to rails 4.1 and I'm getting the following error:
/Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/haml_coffee_assets-1.16.0/lib/haml_coffee_assets/action_view/resolver.rb:9:in `<module:ActionView>': uninitialized constant ActionView::FileSystemResolver (NameError)
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/haml_coffee_assets-1.16.0/lib/haml_coffee_assets/action_view/resolver.rb:4:in `<module:HamlCoffeeAssets>'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/haml_coffee_assets-1.16.0/lib/haml_coffee_assets/action_view/resolver.rb:3:in `<top (required)>'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/haml_coffee_assets-1.16.0/lib/haml_coffee_assets/rails/engine.rb:3:in `require'
source 'https://rubygems.org'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/haml_coffee_assets-1.16.0/lib/haml_coffee_assets/rails/engine.rb:3:in `<top (required)>'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/haml_coffee_assets-1.16.0/lib/haml_coffee_assets.rb:18:in `require'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/haml_coffee_assets-1.16.0/lib/haml_coffee_assets.rb:18:in `<top (required)>'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.6.1/lib/bundler/runtime.rb:76:in `require'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.6.1/lib/bundler/runtime.rb:76:in `block (2 levels) in require'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.6.1/lib/bundler/runtime.rb:72:in `each'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.6.1/lib/bundler/runtime.rb:72:in `block in require'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.6.1/lib/bundler/runtime.rb:61:in `each'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.6.1/lib/bundler/runtime.rb:61:in `require'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/bundler-1.6.1/lib/bundler.rb:132:in `require'
	from /Users/ifeins/Development/lunchtime/config/application.rb:7:in `<top (required)>'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/railties-4.1.0/lib/rails/commands/commands_tasks.rb:79:in `require'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/railties-4.1.0/lib/rails/commands/commands_tasks.rb:79:in `block in server'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/railties-4.1.0/lib/rails/commands/commands_tasks.rb:76:in `tap'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/railties-4.1.0/lib/rails/commands/commands_tasks.rb:76:in `server'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/railties-4.1.0/lib/rails/commands/commands_tasks.rb:40:in `run_command!'
	from /Users/ifeins/.rbenv/versions/2.1.1/lib/ruby/gems/2.1.0/gems/railties-4.1.0/lib/rails/commands.rb:17:in `<top (required)>'
	from script/rails:6:in `require'
	from script/rails:6:in `<main>'

I see that you solve this in master, and indeed when I changed my Gemfile to
gem 'haml_coffee_assets', git: "https://github.com/netzpirat/haml_coffee_assets"

it solved the issue.
Can you push the latest revision to rubygems?

RIP

If anyone else ends up here chasing this error message, you can fix it in your application by making sure that some specific files get required - I added these two lines to the top of my application.rb:
require "action_view"
require "action_view/template/resolver"

Thanks @nevinera , this worked for me.

I have come here following an urgent issue related to the rails security patch for <IP_ADDRESS>
I am sorry to hear about @netzpirat (Mr. Michael Kessler of Switzerland)
The issue is fixed on my fork here https://github.com/mackweldon/haml_coffee_assets, although I realize with an inactive github account there will be noone to merge the PR in. I believe Github has an official repo abandonment process, I'm not sure if it covers the actual death of the account holder. I will email them to follow up

It looks like @thedeeno, @fixme, and @zhrivodkin have all merged PRs. Do any of you have access to do that still?
I think the critical issue isn't GitHub but rubygems. Of course someone who wants to take over the gem can fork and rename it.


[CCXDEV-11713] Added ability to publish compressed messages to topic

Description
Added ability to publish compressed (gzip) messages by adding compression: gzip to configuration file under publisher.
Fixes # (issue)
https://issues.redhat.com/browse/CCXDEV-11713
Type of change
Please delete options that are not relevant.

New feature (non-breaking change which adds functionality)

Testing steps
Tested locally
Checklist

[ ] make before_commit passes
[ ] updated documentation wherever necessary
[ ] added or modified tests if necessary
[ ] updated schemas and validators in insights-data-schemas in case of input/output change

Codecov Report
Patch coverage is 71.42% of modified lines.

Files Changed
Coverage

ccx_messaging/publishers/kafka_publisher.py
71.42%

:loudspeaker: Thoughts on this report? Let us know!.


Privacy Statement page issues

There are 2 issues with the "Privacy Statement" page -

The button at the bottom reads "Back" even in the French version. It should instead be in French when on the French version.
The footer of the page should be the same as the "About Us" page saying - "Copyright 2024 - All Rights Reserved"

example to address issue n.1: 1)Add blue arrow on top-left that is symmetrical to  Feedback/Votre Avis link on the top-right. 2) Need to delete Feedback in bold
https://www.figma.com/file/zNLXI1il5R1IHJ9FliPlUe/Untitled?type=design&node-id=74%3A2&mode=design&t=bUe80lN45b5bBKb4-1


ModalSheetPage with DraggableNavigationSheetPage/ScrollableNavigationSheetPage Pop animation

I have implemented bottom sheet navigation similar to the one used in the AI Playlist Generator. I have a ShellRoute that returns a ModalSheetPage within the ShellRoute.pageBuilder method. The routes in the Shell are either DraggableNavigationSheetPage or ScrollableNavigationSheetPage.
The navigation works well, and I can have nicely animated transitions when opening Sheet-A and then pushing Sheet-B. Popping Sheet-B also transitions smoothly back. However, if I add a close button on Sheet-A to pop Sheet-A, both the transition animation and the ModalSheetPage animation play, resulting in a strange closing animation.
On the other hand, if I tap the barrier, only the animation of the ModalSheetPage plays, and Sheet-A remains visible.
Is there a way to ensure that the transition animation is not used when popping the last sheet in a ShellRoute so that only the "slide-down" animation of the modal sheet is used?
Here is an example of recoding. Due to the platform, it uses the "Slide" transition, which looks weird when closing the sheet:
https://github.com/user-attachments/assets/068048fe-f16d-4000-b3f8-5dc81c29d36c

As I am using GoRouter with Shell routes I realized there I can just use GoRouter.of rather than Navigator.of which just shows the modal close animation


⚠ Bofrost.be has degraded performance

In d070664, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2102 ms

Resolved: Bofrost.be performance has improved in 7dc522a after 13 minutes.


Codebuild plugin sets currentBuild.result = "FAILURE"

Whenever there is a failure in Codebuild, the plugin fails the parent Jenkins build in an unrecoverable manner. My Jenkins pipeline allows specific parts of the pipeline that are flakey builds to be rerun and then pass without rerunning the entire build.
However once currentBuild.result has been set to "failure" already, the whole build can never be set to pass again. Could you send failure status to Jenkins by throwing a exception instead of explicitly setting the build as failure?
This was implemented before here but reverted again here
Thanks

Thanks for your feedback. Since we've received requests for both behaviors, I'll add a flag to specify the pipeline failure mode.

+1 to this. In my usecase I'm planning to have a job that puts tests that need to run in a SQS queue, kicks off 30-50 codebuild builds in parallel, and let each of them chomp at the queue. So if some of them fail during setup, but all the tests run on other workers, the parent job should pass. Since each of these workers take about 30min to finish, it's quite costly to have the parent job falsely fail and then need to rerun all of them.

Implemented in f597598303e2cfef97dabd83e57f61aae6969ff0. When the new exceptionFailureMode is enabled, you can catch exceptions from awsCodeBuild steps like so
try {
  awsCodeBuild ...
} catch (hudson.AbortException ae) {

}

This will be released in version 0.38 later today.

omg thank you so much! you're a life saver!

hey sorry, one more question:
it looks like when the plugin sets the whole build result as FAILURE, it also returns a CodeBuildException which has some useful information about the build. When exceptionFailureMode is enabled though since it's just an AbortException this info is lost. Is it possible to keep these Exceptions consistent with build info?

Yeah, it makes sense to keep the pipeline failure behavior in sync and only throw CodeBuildExceptions in that flow. I've updated the logic in 281ca95340cbcee969a8d3bd3e2f0121b71dd74f. I'll release this in version 0.39 sometime this week.


detailed execution output does not show published vars for action-chain workflows

Given this action-chain:
chain
  -
    name: 'test_publish'
    ref: 'core.noop'
    publish:
      something: 'register this'

st2 execution get -d <workflow id> doesn't show the published vars. A mistral workflow shows 'published' entry for each task that publishes something. It would be nice if action-chains did the same.

You can turn displaying of published variables on by setting display_published action chain runner parameter to True. It defaults to False.
If Mistral defaults to true, it would perhaps also make sense for action-chain to default to true for consistency reasons.

See #3519 for proposed default behavior change.

Good to know! Thanks!


changing the style of pet me it is not aligned properly

What Docs changes are you proposing?
Provide a clear description of the changes you're proposing for the documentation. Are you suggesting corrections, clarifications, additions, or updates?
Why do the Docs need this improvement? What is the motivation for this change? How will this change benefit the community?
Explain the motivation behind the proposed changes and how they will benefit the community or users of the documentation.
Describe the solution you'd like
Provide a clear and concise description of the changes you'd like to see implemented in the documentation.
Describe alternatives you've considered
If you've thought about alternative approaches or solutions, briefly describe them here.
Additional context
Add any additional context, examples, or screenshots related to the proposed documentation changes.

Adopt.html "Meet pet" is not aligned properly and color combination of become volunteer is not matching i propose to chnage that


Wiki contains wrong password

https://github.com/getumbrel/umbrel-os/wiki/Box-System-Defaults still contains the old password

Thanks good catch!

fixed


[feat] store the estimated stats

Right now we are storing stats just for the AI request that ended, but when the request is interrupted, we simply lose usage for this one. Maybe we should store it before the request is being executed or maybe Sztor estimated versus real usage that way we won't lose anything.

We can add a stats record save it's id and when passed with the next request simply replace the estimate with the real usage

The other option which is probably better bc it's not exposing any delete operations is to store the estimated values in additional columns


Port to NeoForge

Initial port to NeoForge. There are a couple of TODOs left and it could use some general review and testing. But has been tested to get into world with commands working on the dedicated and integrated server.

Hey @jpenilla - thank you for this!
I have thought a bit more, I think we should keep supporting regular Forge for the time being in addition to NeoForge. If it becomes too much of a burden, Forge will be removed.
Would you be able to re-instate the Forge module please? :)

@lucko I've added back the forge module.
Do you have any thoughts on requiring an IModInfo or ModContainer for event registration?
https://github.com/LuckPerms/LuckPerms/pull/3950/files#diff-ebe2107a53d10525584eceb9c3d0ecac119f690a38351288dd255307f6088b1aR41

I'm unsure - are there any places in NeoForge where you have to pass either of these? It should be a class similar to Bukkit's Plugin interface.
Another way to look at it - which is easier to get hold of if you're writing a mod?

Looks like ModContainer is used much more often.
Mod authors can get their ModContainer by declaring it as a parameter of their @Mod class constructor:
https://github.com/LuckPerms/LuckPerms/pull/3950/files#diff-8f07a3e4f1d64aac49ffd7402fba4eb0e5028ee62fedc1f5bfd5f91101caf111R52
The ModContainer seems to be more analogous to a Plugin as well, with IModInfo being more like the plugin description. Extension points, configs, etc are registered through it.

Thanks very much for this :)


Add swift-stm32c011-examples to Community Examples section

I created some examples for the STM32C0116-DK:
https://github.com/xtremekforever/swift-stm32c011-examples
Can these be added as to the Community Examples section of the README as well?

Please open a PR with this link :)

#81


Adding Kubekey

Pre-submission checklist:
Please check each of these after submitting your pull request:

[ ] Are you only including a repo_url if your project is 100% open source? If so, you need to pick the single best GitHub repository for your project, not a GitHub organization.
[ ] Is your project closed source or, if it is open source, does your project have at least 300 GitHub stars?
[ ] Have you picked the single best (existing) category for your project?
[ ] Does it follow the other guidelines from the new entries section?
[ ] Have you included a URL for your SVG or added it to hosted_logos and referenced it there?
[ ] Does your logo clearly state the name of the project/product and follow the other logo guidelines?
[ ] Does your project/product name match the text on the logo?
[ ] Have you verified that the Crunchbase data for your organization is correct (including headquarters and LinkedIn)?
[ ] ~15 minutes after opening the pull request, the CNCF-Bot will post the URL for your staging server. Have you confirmed that it looks good to you and then added a comment to the PR saying "LGTM"?

Deploy preview for landscape ready!
Built with commit 9bfb2deef224839e0941e49b383d78e62ec6cee4
https://deploy-preview-2058--landscape.netlify.app

LGTM

almost there, kubesphere needs a valid crunchbase entry


fix:Gensvc templateFile file pointing error

Thanks for your contribution. First of all, I don't understand the problem that this PR needs to solve. Please describe the specific problem in short words. Secondly, the svcTemplateFile in this PR is not really related to the specific template file.


pull request for e2e test at 12/31/2016 01:56:10

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


BUG - ALL Annotations

Describe what were you doing and what caused the bug.
When checking the annotations on a specific post, we are seeing all the annotaions that are recorded.  We require specif annotation for specific post.
What do you think needs to be changed?
HTML and .JS shall be changed.
You can upload screen shot if needed.

2d0b6bb1a109a3d9debe8819ff6738ddfbaf8758


[Monolog] Console handler don't bubble anymore

Q
A

Bug fix?
no

New feature?
no

BC breaks?
no

Deprecations?
no

Tests pass?
yes

Fixed tickets
-

License
MIT

Doc PR
-

see https://github.com/symfony/symfony-standard/pull/557#discussion_r52014052 for more information

Thank you @lyrixx.


Javascript module plans

Note These are plans about this project todo but not found enough time to make it happen yet.

[ ] Remove godot form global scope, make it as an esmodule.
import { Vector2, Node, clamp } from 'godot';

[ ] Improved TypeScript support

[ ] Better signal/slot support

[ ] Remove extral signal value bindings, implements in TS declerations
[ ] Type checking and code completion for signals, callbacks and paramters

[ ] Add godot importer to compile TypeScript files with tsc/esbuild

[ ] We want writing TypeScript files and attach them to nodes in editor

[ ] Improved debugger for QuickJS

[ ] Standard ESModule/CommonJS implementation

[x] Rename jsx to mjs for esmodule
[ ] Add interface to native API for module code loading so that would be possible to

Load script from remote like deno
Load TypeScript and run it (after custom compile process)
Script content encryption

[ ] Add operators as methods like op_add op_divide to builtin math types for compatibility with more backends

[ ] Samples for complicated projects

[ ] Out of box configuration of webpack/esbuild etc
[ ] Out of box remote debugger/profiler configurations for VSCode to make it easier for mobile game development
[ ] Hot reload implementation for faster development
[ ] Remote update version without ship new version on App Store/Google Play/Steam

[ ] Port to godot 4.x

[ ] Port QuickJS binding to godot 4.0
[ ] Add GDExtension support to make everyone can just download and using it

[ ] Some demo projects

[ ] For performance tests
[ ] For best practics
[ ] For make good use of TypeScript/JavaScript/NPM

Documentations

[ ] I can writing documentations in Chinese
[ ] It world be great if anyone can help translate them

About backends and improvements to current workflow

[ ] Add V8 backend

[ ] Professional debugger/inspector/profiler/memory tools support
[ ] Enable JIT as default and using jitless mode on iOS

[ ] Add NodeJS backend (Editor/PC Only)

[ ] Using full NodeJS API (and millions of libraries) to extend editor or make games on PC

Also, there are some errors in the godot.d.ts (lines 4686 and 47134, I think), it would be nice to fix them, along with #126.

Also, there are some errors in the godot.d.ts (lines 4686 and 47134, I think), it would be nice to fix them, along with #126.

I've fixed the first issue with #135. @Geequlim could you take a look?

Can you estimate the effort to add wasm support?

Can you estimate the effort to add wasm support? Or describe how you would do it?

WASM is supported by V8 directly.
For QuickJS backen we can using wasm3

For note
Latest stable V8 static libraries build is ready at https://github.com/Geequlim/v8-builder
Puerts seems integrated nodejs for unity and unreal engine on both desktop and mobile platforms with https://github.com/puerts/backend-nodejs

Do you prefer v8 or quickjs + wasm3?

For different usage choose different backend.
QuickJS is smaller so it is suitable for most game projects.
v8 is large but fast with jit and much more stable with better toolchains including debugger/profiler etc.
We'd better develop games with v8 and publish with your choice.
The principle of the backend to choose is based on your project.
If performance more important using V8 or if size is more important choose QuickJS.
Note:

V8 is not supported on Web and quickjs is better for better load time.
On iOS jit is not allowed so performance of V8 is not that obviously so maybe QuickJS is better choice.
For editor and developers tools    we'd better choose nodejs so we can benefit from the npm ecosystem  to make life easier.

Heya, @vignetteapp would love to help you out with the GDExtensions work item and (potentially) the CommonJS/ESM implementation, is there any progress in the 4.1 branch so far?

The master branch has had active work by @nmerget

I created a roadmap to track progress


command :pwd does not print the working directory

When I enable this plugin and call :pwd, it does not print the working directory but print the current file name.
On the other hand, when I disable this plugin, this issue goes away. So I think this plugin may cause this issue.

Try with some minimal config, as it works as expected for me, so perhaps something else in your configuration interacts.