Ollama withdspy.ChainOfThought: slower after some initial runs?

I am running attached py as standalone which loads the attached data file. Execution should be very fast as there should be no training but isn't. An earlier version of the code runs without issues but the attached when processing the 5th case suddenly seems to switch to training. From what I see in the debugger this happens in the with-loop line 69 which calls dspy.ChainOfThought
PIA_test.txt
score.zip

Sorry I don’t understand. What model are you using? If you rerun again, does the issue to away? OpenAI has been slow and unstable today

Apologies for being imprecise. This is using phi-2/Ollama (line #4 model=phi)
No this is reproducible, changing the data file only changes when the bug hits.

Awesome! And the error is where? Feel free to post code here or stacktrace of ctrl-c
What do you mean by it switches to training. That seems unlikely to be something that happens

Full Code is in the zip-file I included in the first post. Fwiw line 69ff. is were the problem happens.
Processing time goes from 150it/s down to 30s/it on my machine... So it does not crash but runs very slowly.

What is num_threads? Maybe the servwr js overwhelmed
also when is it 150/s? At the start?

This is running on my local machine. No server involved.
Yes the first runs are at that speed (as per the Average Metric line) and then it falls off a cliff.

Yes ollama is the server and basically gets overwhelmed. What is your num_threads ?

Ah thanks for the clarification. num_threads = 1

Got it. It’s possible your laptop begins to overheat or just reduce power.
this doesn’t seem crazy — do you have another reason to believe there are issues? 30 iters per sec isn’t bad I think

It goes down to 30 and more seconds per it...

The laptop does throttle down under heavy load but not that much. Also, the error hits before the fan begins to spin up.

I have replaced phi with gemma:2b and am experiencing the same issue - right from the first run. The delay happens first in line #73 " detail = dspy.ChainOfThought(Assess)(context=context, assessed_question=detail, assessed_answer=predicted_answer)"
Attached is the update code which uses gemma:2b (and also the data file which get processed):
py file.zip
PIA_test.txt

closing this - might in related to (mis)using openai and not Ollamalocal

I'm doing something similar, using GPT-4, and using dspy vs "raw" call to OpenAi is extremely slow. With 10k points, I get a result with OpenAI in 30 minutes. With dspy, it's been 1 hour and it has processed only 1/5 of the data.
class Theme(dspy.Signature):
    """
    Classify user queries in following themes:
    [Restricted -- cannot share]
    """
    sentence = dspy.InputField()
    theme = dspy.OutputField(desc="THEME name only. No explanations.")

model = dspy.OpenAI(
        model=config.COMPLETION_CONFIG["model"],
        max_tokens=config.COMPLETION_CONFIG["max_tokens"],
    )
    dspy.settings.configure(
        lm=model, trace=[], temperature=config.COMPLETION_CONFIG["temperature"]
    )
    classify = dspy.ChainOfThought(Theme)

    df_out = df.copy()
    df_out["Theme"] = ""

    start_time = time.time()
    for i, row in tqdm(df.iterrows()):
        sentence = row["Prompt"]
        response = classify(sentence=sentence)
        extracted_theme = extract_theme(response.theme)
        logger.debug(extracted_theme)
        df_out.loc[i, "Theme"] = extracted_theme
    logger.info(f"Finished processing in {time.time() - start_time:.2f} secs")

Using the content of docstring with OpenAI directly is a lot faster. And I'm not even optimizing anything. Is there anything I can do to have more control? For instance, with OpenAI + standard python I use asyncio for threading.


SAMSUNG FRAME TV 2020 - APP CHANGE AND TTS NOT WORKING

The current app are correctly displayed.
Power on/off and volume control working correctly.
I can change from TV to HDMI, but not able to change between TV apps.
The TTS doesnt work for me ?

Exactly same problem here, with exactly same TV.

Same Issue here

I've got the same issue that starting apps described in app_list cannot be started.
But maybe some more insights:
I'm running a Samsung 75" QLED 4K Q90TC (2020). I've activated the API (Smartthings) so I'm able to switch to TV, HDMI1, etc, etc.
Furthermore I'm still able to use the channel-list.
Nonetheless apps stated in app_list are correctly shown. I mean when I start the netflix app on my TV, Homeassist tells me that the media_player is running org.tizen.netflix-app. After the following configuration it correctly displays "Netflix" with the logo in Home Assist:
media_player:
  - platform: samsungtv_tizen
    host: <IP_ADDRESS>
    mac: "zz:zz:zz:zz:zz"
    name: Fernseher
    api_key: "xxx-xxx-xxx"
    device_id: "yyy-yyy-yyy"
    source_list: '{"TV":"KEY_TV","Switch":"ST_HDMI1","Xbox":"ST_HDMI4"}'
    app_list: '{"Netflix": "11101200001/org.tizen.netflix-app", "Prime Video": "3201512006785/org.tizen.primevideo", "YouTube1": "111299001912/9Ur5lzDKqV.TizenYouTube", "YouTube2": "111299001912/9Ur5IzDKqV.TizenYouTube", "Disney+": "3201710015067/MCmYXNxgcu.DisneyPlus"}'
    channel_list: '{"KiKa":"4","MTV":"23"}'

Unfortunately its not possible to start the app herefrom. Thats the issue.
As of now the only viable option to start netflix is to keychain commands.

I have this problem!

Hi,
I found another issue for something like this on this repo, can;t find it anymore sorry.
It says that posting a request to the tv works so I ended up creating restful request in home assistant 👍
just past the following (and change the ip)  in your config.yaml and use the new actions as services in any scripts :)
the numbers at the end of the requests are the app id
rest_command:
  netflix:
    url: "http://[YOUR TV LOCAL IP]:8001/api/v2/applications/3201907018807"
    method: post
    content_type: "application/x-www-form-urlencoded"
  prime_video:
    url: "http://[YOUR TV LOCAL IP]:8001/api/v2/applications/3201910019365"
    method: post
    content_type: "application/x-www-form-urlencoded"
  youtube:
    url: "http://[YOUR TV LOCAL IP]:8001/api/v2/applications/111299001912"
    method: post
    content_type: "application/x-www-form-urlencoded"
  spotify:
    url: "http://[YOUR TV LOCAL IP]:8001/api/v2/applications/3201606009684"
    method: post
    content_type: "application/x-www-form-urlencoded"
  steam_link:
    url: "http://[YOUR TV LOCAL IP]:8001/api/v2/applications/3201702011851"
    method: post
    content_type: "application/x-www-form-urlencoded"

Hope it helps anyone in the meantime.

Hi, you may find a workaround in this issue
https://github.com/jaruba/ha-samsungtv-tizen/issues/124
Hop it helps in the meantime

Can have a nice result in the dashboard as well :

- type: grid
    cards:
      - type: picture
        image: /local/assets/netflix.png
        tap_action:
          action: call-service
          service: rest_command.netflix
          service_data: {}
          target: {}
        hold_action:
          action: none
      - type: picture
        image: /local/assets/prime_video.png
        tap_action:
          action: call-service
          service: rest_command.prime_video
          service_data: {}
          target: {}
        hold_action:
          action: none
      - type: picture
        image: /local/assets/youtube.png
        tap_action:
          action: call-service
          service: rest_command.youtube
          service_data: {}
          target: {}
        hold_action:
          action: none
      - type: picture
        image: /local/assets/spotify.png
        tap_action:
          action: call-service
          service: rest_command.spotify
          service_data: {}
          target: {}
        hold_action:
          action: none
      - type: picture
        image: /local/assets/steam_link.png
        tap_action:
          action: call-service
          service: rest_command.steam_link
          service_data: {}
          target: {}
        hold_action:
          action: none
    columns: 5
    square: false

Still have this error,
Anyone successfully solved it?


WHEN WILL THE NEXT UPDATE?

WHEN WILL THE NEXT UPDATE?

I'm not sure what you mean. Is there a particular feature you want in a future update?

Not sure what you mean. Is there a specific feature you want in a future update?

yes, edit 3d mesh import dump files, when i import in game it is invisible

I work with mods using this a
UABEA and I need it updated to edit urgent 3d mesh
this is my youtube channel where I share my work using UABE
https://www.youtube.com/channel/UCLKF6CG6MyMPDf5VTYhRwnA

Mesh discussion in #124.


Unable to run python training_ModelNet40.py with the following error message

Hi,
I'm trying to train the network for classification on ModelNet40 and downloaded the specified data. But when I run python training_ModelNet40.py command I get the error
tensorflow.python.framework.errors_impl.NotFoundError: tf_custom_ops/tf_neighbors.so: undefined symbol: _ZN10tensorflow8internal21CheckOpMessageBuilder9NewStringEv
although tf_neighbors.so is right there in tf_custom_ops folder
Regards

This is the fix.  Problem is with the version of gcc/g++. if g++/gcc version >= 5 you don't need to use -D_GLIBCXX_USE_CXX11_ABI=0 for compiling the custom operations.


Get-vhd on a live vhdx

If the vhd/vhdx is in use, then can only run get-vhd on the system that has the vhd loaded or is running the VM that is using the vhd.
All other systems eg other nodes of a cluster with vhd's on shared storage, will give "The operation cannot be performed while the object is in use"
[Enter feedback here]

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

ID: 7de2b1ce-c9e0-f7be-d8f1-9eb0ebd82677
Version Independent ID: 776cd256-d681-539c-999e-e281be147647
Content: Get-VHD (hyper-v)
Content Source: docset/windows/hyper-v/Get-VHD.md
Product: w10
Technology: powershell-windows
GitHub Login: @andreabarr
Microsoft Alias: v-anbarr

Same if the vhd/vhdx is on a fileshare and accessed over UNC. If in use only the system using it can successfully run get-vhd. All others get "The operation cannot be performed while the object is in use" as expected.

@stephc-msft Hello,
Thank you for your feedback.
Isn't this the desired behavior?
In my understanding the VHD file is locked by the VM that is using it to avoid corruption. I guess you want to still be able to get the VHD metadata?

Correct it is locked, but can be accessed via get-vhd from the system that is using it
This comment is to clarify that get-vhd from anywhere else will fail with object in use, as expected
Particularly when the vhd is on an smb share or a CSV
From: Borislav Velkov<EMAIL_ADDRESS>Sent: 15 November 2020 18:01
To: MicrosoftDocs/windows-powershell-docs<EMAIL_ADDRESS>Cc: Stephen Cole (ENGLAND<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [MicrosoftDocs/windows-powershell-docs] Get-vhd on a live vhdx (#2024)
@stephc-msfthttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fstephc-msft&data=04|01|stephc%40microsoft.com|d0486a27863540826be308d88990644e|72f988bf86f141af91ab2d7cd011db47|1|0|637410600533055735|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=vAlfOZSutR92Sd6oMabJ4KOTNinjG%2FKSXYFyS36zP5Y%3D&reserved=0 Hello,
Thank you for your feedback.
Isn't this the desired behavior?
In my understanding the VHD file is locked by the VM that is using it to avoid corruption. I guess you want to still be able to get the VHD metadata?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fwindows-powershell-docs%2Fissues%2F2024%23issuecomment-727610573&data=04|01|stephc%40microsoft.com|d0486a27863540826be308d88990644e|72f988bf86f141af91ab2d7cd011db47|1|0|637410600533055735|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=d5%2FwjanN91kKpTNKsHi9gQCdyUN7dUge8yB6DL7qOpI%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAGGHGBKSESNVKI42OGXMEZLSQAJNHANCNFSM4ODKMPLA&data=04|01|stephc%40microsoft.com|d0486a27863540826be308d88990644e|72f988bf86f141af91ab2d7cd011db47|1|0|637410600533065691|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=smWy5%2Fm%2B1Iu5X3gRl2WMhbaDSfr%2Ftssh9M1jQZWcG74%3D&reserved=0.

Thank you for the clarification. I will update the article with a note.


Multi-node receive [PoC]

This PR is an exploration of the design space for multi-node receive.
The idea is to run a standalone process (working title: invoice coordinator) that connects to a cluster of lnd nodes via the htlc interceptor API. The coordinator is backed by a replicated database that contains all invoices. It has its own node key and every invoice is generated by the coordinator. Invoices contain a hop hint for each node in the cluster with a dummy scid.
When an htlc comes in on one of the cluster nodes, it is intercepted by the coordinator. The coordinator matches the hash with the invoice database and if there is one, it signals the lnd node to settle the htlc.
This allows invoices to be paid through any of the cluster nodes. When one node goes down, senders will retry with one of the other nodes listed in the route hints. Also shards of a multi-part payment may use multiple nodes.
Current implementation is an adaptation to LND. It allows LND to be run in a mode where it acts as the coordinator. To do that, the gateway node needs to be specified (only one supported atm):
lnd --gateway.pubkey=0314aaf9b2547682b81977b3ac0c5585c3521a0a5430fb410cb572d5c72364edf3 --gateway.tls=~/.lnd/tls.cert --gateway.mac=~/.lnd-bob/data/chain/bitcoin/regtest/admin.macaroon --gateway.host=localhost:10002
What you can do with this is set up Alice and Bob with a channel between them and then connect the coordinator to Bob. This allows Alice to pay invoices created by the coordinator.
For production, it seems unlikely that we want to run a customized lnd as the coordinator. Instead the coordinator code can live in a fresh stand-alone repo. This also allows the database backend (channeldb/invoices.go) to be re-implemented using structured sql.
Dependencies:

https://github.com/lightningnetwork/lnd/issues/6161
https://github.com/lightningnetwork/lnd/issues/6040
https://github.com/lightningnetwork/lnd/pull/6177

Closing as this is now implemented externally in https://github.com/bottlepay/lnmux


[BUG] transformer multi-column pd.DataFrame output conversion fails

Describe the bug
It seem like series-to-series transformers cannot return multiple columns when passing a pd.Series as input.
To Reproduce
from sktime.transformations.base import BaseTransformer
import numpy as np
import pandas as pd

class MyTransformer(BaseTransformer):
    _tags = {
        "scitype:transform-input": "Series",
        "scitype:transform-output": "Series",
        "scitype:transform-labels": "None",
        "scitype:instancewise": True,
        "univariate-only": False,
        "handles-missing-data": True,
        "X_inner_mtype": "pd.DataFrame",
        "y_inner_mtype": "None",
        "X-y-must-have-same-index": True,
        "enforce_index_type": None,
        "fit-in-transform": False,
        "transform-returns-same-time-index": True,
        "skip-inverse-transform": True,
    }

    def _fit(self, X, y=None):
        return self

    def _transform(self, X, y=None):
        return pd.concat([X, X], axis=1)

transformer = MyTransformer()
transformer.fit_transform(pd.DataFrame(np.random.normal(size=(10,)))) # works
transformer.fit_transform(pd.Series(np.random.normal(size=(10,))))  # fails

ValueError: input must be univariate pd.DataFrame, with one column

Additional context
This is relevant for "featurizers" as in #1693.
Version
main at commit 8ca23bd85e60d

yes, I noticed that too when thinking about #1677.
I was wondering what the behaviour should be in that case. pd.DataFrame by default? Seems easiest.

@mloning, also wondering how to properly test this.
I have been thinking about a more comprehensive suite of transformers tests than we currently have. We need to cover cases like this, and then check inputs/outputs. A tag that indicates whether the number of variables might change (e.g., grow), or what it is, might help.


A date_range type field does not take values from the database

Hello everyone, why in the variable value = null? How to make sure that the date was extended from the database when editing
[
             'name' => 'interval_date_range', // a unique name for this field
             'start_name' => 'start_date', // the db column that holds the start_date
             'end_name' => 'end_date', // the db column that holds the end_date
             'label' => 'Date Range',
             'type' => 'date_range',
             // OPTIONALS
             'start_default' => \Carbon\Carbon::now()->format('Y-m-d'), // default value for start_date
             'end_default' => \Carbon\Carbon::now()->format('Y-m-d'), // default value for end_date
             'date_range_options' => [ // options sent to daterangepicker.js
                 'timePicker' => false,
                 'locale' => ['format' => 'YYYY-MM-DD'],
]

In the database there are values at the start _date and the end_date,
result in template
dd($fields['value']);
"value" => null

How to solve this problem with the assignment of dates from the database?

When you are editing, the date_range field_type have a bug #450 that may fix the problem that you've shared : Where the date_range field doesn't take the start_date and end_date value from your DB.
Anyhow, when you tried to access $fields["value"], it seem that the fields array is construct like "type"=>$field.
Hope it lights your problem.

@tabacitu, this doesn't seem to work for me either.
Tried it in the Backpack Demo with the dev version of backpack CRUD and the date range always shows defaults for both start and end dates.
I'll get working on a PR.

@tumf87 great, thank you. That you're working on a PR, not that it's not working. That's not great at all :-)

Fixed, merged and launched! Thanks guys!


Add CI

Add some basic tests to some of the functions in the package

I hear the bake Haskell library is a great place to start

Fixed by #8


added workflow to detect whitespaces

Simple workflow to detect whitespaces upon changes in application.properties files. This will ensure that application.properties files won't get merged in a format that may hinder their rendering as k8s resources.

@masayag


Leverage Stripe as admin panel

We are just two webhooks away from not needing to provision accounts manually via OPS script:

[ ] provision accounts using stripe (slug must be in metadata)
[ ] sync account name to stripe and back

This will be useful for building automation to provision all the early access signups in our queue. The process could be:

Qualify the early access request in HubSpot
Add automation to provision the customer from HubSpot to Stripe
Enjoy

Yeah, that was the reason why I want to do this - will allow us to automate the sales process. The only issue is the slug, would be pretty hard to get it all the way from HubSpot, so we might want to assign random and let customers manage their slug themselves.


error message on successful emit

Hi, I am working with a modified console example with SIO_TLS. The emit works and is received on the server side, but I am noticing a message every time I emit, I also get the console message;
ping exit,con is expired?0,ec:The I/O operation has been aborted because of either
a thread exit or an application request

The message comes from within client_impl::ping would this be related to ping interval or ping timeout setting? Thanks!

Hi, this is a normal case, the ping is for keeping the connection alive, the ping timer will be cancelled for a round when you're sending something, the canceling operation result in a aborted error code in timer callback.

Ok thanks!


Consider alternative frameworks

With https://astro.build/blog/astro-4140/, Astro is looking even better. The issues I ran into earlier might be easier to solve, if not the massively improved DX and features might make up for it. Worth a shot! Would close #88.

https://github.com/getzola/zola might also be worth a look. A lot simpler and may be less flexible however.


[Feature Request] Lexoffice Integration

Can you add a Fully Lexoffice integration for creating invoices directly on lexoffice and the customer can download the invoice via api from Lexoffice or the FossBilling Pannel via Lexoffice Sync (import the Lexoffice invoice to Fossbilling via pdf).
best regards

Well, I do think that there would be added value for the German market, as everyone is quickly using Lexoffice. In addition, the currently integrated invoice function is not GDPR-compliant and cannot be used in my company, for example.
I can offer to develop an extension and then offer it in my shop for a fee.

Go ahead we have limited resources and personally I we want to spend time to more GDPR approved it won't be moving to a paid invoicing system but keeping it internally.

I don't really even see how it's supposed to function.
Core functionality like renewals, payments, notifications, ect all depend on invoices being generated within FOSSBilling. Trying to separate invoice functionality from it would complicate all of that quite a lot


Update concepts.ngdoc

Replaced ng-repeats with ng-options as it is read in documentation to be better to use. Allowed my implementation of currency converter to work without any problems and not so much with ng-repeats.
AngularJS is in LTS mode
We are no longer accepting changes that are not critical bug fixes into this project.
See https://blog.angular.io/stable-angularjs-and-long-term-support-7e077635ee9c for more detail.

Does this PR fix a regression since 1.7.0, a security flaw, or a problem caused by a new browser version?

What is the current behavior? (You can also link to an open issue here)
What is the new behavior (if this is a feature change)?
Does this PR introduce a breaking change?
Please check if the PR fulfills these requirements

[ ] The commit message follows our guidelines
[ ] Fix/Feature: Docs have been added/updated
[ ] Fix/Feature: Tests have been added; existing tests pass

Other information:

@googlebot I signed it!

ng-repeat should work the same here. I am in fovor of keeping ng-repeat, because it is a more simple and low-level directive and I feel it is better suited for the concepts doc (which is a basic introduction).
Did the code not work for you with ng-repeat?

I was following along with the tutorial but for some reason it wasn't loading correctly in terms of the options, but later worked with ng-options. I totally understand with keeping ng-repeat to stay with the basics for the intro!

Could you share a reproduction of the issue (i.e. the code that was not working with ng-repeat)?
We certainly don't want to have code examples that don't work :smiley:

Ok, so oddly enough it worked this time for me when I used ng-repeat. Maybe there wasn't something right in my server/browser. Yesterday, the inCurr property wouldn't be shown as being set to EUR and the converted currency values would not print.
Thank you for your quick response!

Awesome, thx for getting back. I am going to close this issue then, since it is working for you now.


 And for the progress bar to work?
Use Case
This would make the user experience much better as it would eliminate steps and make the process faster and easier
Proposed Solution
Ideally clicking the generate on cloud button would result in identical behavior to clicking the regular generate button. I'm not sure how difficult this would be to implement but would be great if possible.
Other Information
No response
Solution version used
v1.3.2

Thanks for the feedback. We already support the auto refresh for inference result in dec branch and will official release to main branch in v1.0.1

https://github.com/omniinfer/sd-webui-cloud-inference
I have created a similar extensions inspired by aws extension to solve the problems, its ensuring compatibility with stable diffusion webui is main goal.

https://github.com/omniinfer/sd-webui-cloud-inference
I have created a similar extensions inspired by aws extension to solve the problems, its ensuring compatibility with stable diffusion webui is the main goal.

https://github.com/omniinfer/sd-webui-cloud-inference
I have created a similar extensions inspired by aws extension to solve the problems, its ensuring compatibility with stable diffusion webui is the main goal.

Looks good, I'll give a try. thx anyway.

@AGronowski feature resolved in new release v1.0.1, closed for now.


Slow resize + png for YCbCr images

I have an image (ycbcr.tif) that I want to resize and convert to PNG. Using resize and png the operation takes about 9 seconds.
// resize.js
require('sharp')(process.argv[2]).png().resize(100).toBuffer(() => {
  console.log('done processing', process.argv[2]);
});

$ time VIPS_WARNING=0 node resize.js ycbcr.tif
done processing ycbcr.tif

real    0m8.934s
user    0m8.298s
sys     0m0.601s

The same image using vipsthumbnail takes 75ms.
$ time VIPS_WARNING=0 vipsthumbnail --size=100 --format='%s.png' ycbcr.tif

real    0m0.075s
user    0m0.063s
sys     0m0.010s

Curiously, if I process ycbcr.tif with gdalwarp -dstalpha, and use the output (alpha.tif), sharp's operations become much faster.
$ gdalwarp ycbcr.tif alpha.tif -dstalpha
$ time VIPS_WARNING=0 node resize.js alpha.tif
done processing alpha.tif

real    0m0.202s
user    0m0.176s
sys     0m0.058s

(Note: I've described the images as YCbCr and alpha, but I don't know what differences exactly account for the processing time discrepancy. These are just the formats I happen to be using when I encountered the issue.)

Hello, a quick look at your input file suggests it contains 8 pages/images, which could explain some of the difference, although the default behaviour of both sharp and vips should be to use the first page/image only.
I wonder if this could also have something to do with colour space conversion. I'll do some code profiling and report back here - thanks for the report!

Adding sequentialRead() to the processing chain "fixes" this by preventing libtiff from decoding too far ahead. vipsthumbnail always uses the sequential approach.

@lovell Thanks. Yes, I'm also seeing that adding sequentialRead speeds up the operation.

Thanks for confirming.
If it's OK with you I'd like to leave this open until I've had a chance to inspect the libvips-libtiff-libjpeg bridge more closely. I spotted some possible efficiencies whilst profiling this code, e.g. the mostly-unnecessary "fancy upsampling" feature of libjpeg seemed to always be enabled.

Of course, let's leave it open. I'm interested in following along with the developments.

On closer inspection, it appears libtiff commit https://github.com/vadz/libtiff/commit/16eb07a48f2b4ca3e12f52a254a868c197e024da (unofficial mirror) fixes the do_fancy_upsampling related performance problem I was seeing.

@lovell This image has a transparency mask but with only three channels. Sharp doesn't seem to be use it to make transparent PNGs, or perhaps I'm missing an option. Could this be part of the issue? I can create another ticket if it's unrelated.

This image appears to be an 8 page TIFF, with the transparency on the second page, and then 6 more pages after that.
$ identify ycbcr.tif
ycbcr.tif[0] TIFF 1667x1674+0+0 DirectClass 8-bit 789.9K 0.000u 0:01
ycbcr.tif[1] TIFF 1667x1674+0+0 DirectClass 1-bit 789.9K 0.000u 0:01
ycbcr.tif[2] TIFF 834x837+0+0 DirectClass 8-bit 789.9K 0.000u 0:01
ycbcr.tif[3] TIFF 417x419+0+0 DirectClass 8-bit 789.9K 0.000u 0:01
ycbcr.tif[4] TIFF 209x210+0+0 DirectClass 8-bit 789.9K 0.000u 0:01
ycbcr.tif[5] TIFF 834x837+0+0 DirectClass 1-bit 789.9K 0.000u 0:01
ycbcr.tif[6] TIFF 417x419+0+0 DirectClass 1-bit 789.9K 0.000u 0:01
ycbcr.tif[7] TIFF 209x210+0+0 DirectClass 1-bit 789.9K 0.000u 0:01

Currently, sharp only uses the first page of a multi-page TIFF file.
If you need multi-page support please create a new issue, although this will only allow you to extract/process one numbered page at a time.
To then create an RGBA PNG, you'll have to write the logic to perform the joining of pages (there will soon be a joinChannel operation via #513 to help with this).


[connection] - Fix issue loading connection icon and status from connection definition

Notes for Reviewers
This PR fixes #

Connection kind name and component definition not same was reason for not load the image and also connection transition status. I'm handle those from ui

connection definition: meshery-core
connection - connection kind: meshery

Signed commits

[x] Yes, I signed my commits.

// @MUzairS15


Update 22.4.md

Regardless there is a back edge or not the DFS time complexity is bounded by O(V).

http://www.cs.jhu.edu/~xfliu/600.363_F03/hw_solution/midterm2_solution


ScoreboardStats not compatible with ASkyBlock

ASkyBlock: https://www.spigotmc.org/resources/askyblock.1220/
Error:
18.06 15:53:31 [Server] WARN [ASkyBlock] "ASkyBlock v<IP_ADDRESS>" has registered a listener for com.wasteofplastic.askyblock.events.IslandLevelEvent on method "public void com.github.games647.scoreboardstats.variables.defaults.ASkyBlockVariables.onLevelUp(com.wasteofplastic.askyblock.events.IslandLevelEvent)", but the event is Deprecated. "Server performance will be affected"; please notify the authors [Tastybento].
Auhor of ASkyBlock has informed you. But he says that there is as far no reaction from you.

You're using an outdated ScoreboardStats version. Please update https://github.com/games647/ScoreboardStats/releases


Reduce the number of tags with <space><space>

The extension currently tags every whitespace in the buffer when using <space><space>. This behaviour differs from the neovim version, which only tags empty lines. It would be interesting if double-space highlighted the newline character for every line, but I don't see the reason to highlight every whitespace.
Another consequence is that on my machine, it takes about 5 seconds to highlight the entire file when using double-space, defeating the purpose of fast jumping.

I totally agree. Perhaps I would change it so that only the first whitespace is highlighted in a chain. This would reduce the highlighting significantly, but you could still jump e.g. to the beginning of a line.
At the same time I would introduce a new setting, to give the user the option to only jump to the end of a line with .

That sounds good. The original leap.nvim lacks a good way to do line-wise navigation, but these options to do first whitespace and newline would achieve that nicely.


Autogenerated integrations

Greetings,
Out security policies dictates apps cannot fetch pull-secrets from k8s cluster. Is there any way to stop ACS from autogenerating integrations with docker registry?

@stackrox/scanner Could you please take a look?

@stackrox/core-workflows @stackrox/scanner
Does anyone know of a way to stop ACS from autogenerating integrations with docker registry?

The autogeneration can be disabled by setting ROX_DISABLE_AUTOGENERATED_REGISTRIES env var to false on the central deployment.

@KennyMacCormik It appears the env var ROX_DISABLE_AUTOGENERATED_REGISTRIES does not stop secret pulls but only prevents auto-generated registry integration creation in the central database.
The engineering team has opened a case for your use case and will review it in an upcoming roadmap planning.


v0.21.0 - Execution hangs on first command execution/jQuery not defined

What is the current behavior?
Page opens, but the Waiting for page to load message does not appear. Console hangs after printing the test title.
Solution
I downgraded to v0.19.2 (Not sure why, I have been struggling with this for the past 5 hours and tried everything) and it... works.
How I found out something was wrong
After a few tries, I opened the console and found out that the console show a few errors, in the likes of jQuery is not defined, $ is not defined, Cannot set property 'display' of undefined, etc.

Tested page URL: http://the-internet.herokuapp.com/abtest
Test code:
import { Selector } from 'testcafe';

fixture`AB TESTING`
  .page`the-internet.herokuapp.com/abtest`;

test('Print out header', async t => {
  const articleHeader = Selector('#main-form .main-content h1');
  await t
    .expect(articleHeader.innerText).eql('Thank you, Peter Parker!')
}); // I know it will fail, it is the idea.

operating system: Linux Mint 18.3 - Cinnamon desktop
testcafe version: 0.21.0 and 0.19.2
node.js version: 10.5.0
browsers: Chrome@latest and Firefox@latest

Hi @maeriens, I've reproduced the issue. Looks like a regression in the testcafe-hammerhead package.

@LavrovArtem, it can be reproduced with the latest master (55c3d75) in hammerhead's playground

Fixed in https://github.com/DevExpress/testcafe/pull/2743


iOS stacktraces are not symbolicate

Platform
Apple
Installed
Swift Package Manager
Version
0.2.1
Steps to Reproduce

Expected Result
I would like to see readable stacktrace
Actual Result

Hi!
maybe unrelated but I'm wondering why you can compile it with SPM without setting isStatic = truein the binary framework configuration.
Which Kotlin version are you using?
Also check out our KMP sample with SPM if you like.

You are right, I for mistake in deleting this before taking a screenshot. I've edited the post.
kotlin_version = 1.8.22
Yes, I've checked but without success

I see you're running self hosted, is the outcome the same on sentry.io?

Could you explain how can i check if the outcome is the same on sentry.io?

Check if your stacktrace is symbolicated on sentry.io not self hosted.
I currently cannot find any issues with your setup so that might be good to check.

Okay, so I've created my own project and migrated the iOS configuration to connect with my sentry and I've ended up with this.

This looks as expected with the SDKs current state, so I assume there's an issue with self hosted.
Might be worth checking if the same happens with Sentry Cocoa used directly in native iOS without KMP but I doubt it's different.

I've checked and is Not working.
Do you have any clue what can be wrong in self hosted?

@ynsok what's the version of self-hosted you're using?

Sentry 23.3.1

The fact that you have no "Debug File Candidates" might hint at a problem that Symbolicator is unable to query those from Sentry.
On the other hand though, the list should report those files as unused in that case.
Can you check the detailed logs of your self-hosted Symbolicator?


Support variables, such as $(Date:yyyyMMdd) and $(Rev:rr) in GitHub Release Title

Required Information
Question, Bug, or Feature?
Type: Feature
Enter Task Name: GitHubRelease
Environment
Azure Pipelines
Hosted VS 2017
Issue Description
The GitHubRelease task does not appear to support using variables to name the release on GitHub. For example, I'd like to name my release "Product Release 20190426.2" using the release title value "Product Release $(Date:yyyyMMdd)-$(Rev:r)"

I recently ran into this similar issue when creating a nightly build pipeline that publishes a release. I ended up settling on Nightly-$(Build.BuildId) but I'd of course prefer something a bit more meaningful.

To anyone who comes across this, I found a way to do it that worked for us.
In our release pipeline, under the general options area where it asks for "Release name format" I gave it the format with a date variable like so: Nightly-$(Date:yyyy-MM-dd)
Then, in the github release task when it asks for a tag, I gave it: $(Release.ReleaseName)
This will then publish a release with that tag and name over on Github. Not the most intuitive, but it seems to work.

To anyone who comes across this, I found a way to do it that worked for us.
In our release pipeline, under the general options area where it asks for "Release name format" I gave it the format with a date variable like so: Nightly-$(Date:yyyy-MM-dd)
Then, in the github release task when it asks for a tag, I gave it: $(Release.ReleaseName)
This will then publish a release with that tag and name over on Github. Not the most intuitive, but it seems to work.

Now that was epic! I've been trying to find a way through this the whole day. Couldn't figure out why "Tag" and "Release title" were not accepting the $(Rev:r). Thanks a lot for that!!!


RuntimeError: result type Long can't be cast to the desired output type Bool

Hi, guys：
First of all, thank you for your outstanding work, but when I was training the teacher network, I encountered such a problem.
python train_v2v.py mars --backbone resnet50 --num_train_images 8 --p 4 --k 4 --exp_name base_mars_resnet50 --first_milestone 100 --step_milestone 100
=> MARS loaded
Dataset statistics:
subset   | # ids | # tracklets | # images
train    |   625 |     8298 |   509914
query    |   626 |     1980 |   114493
gallery  |   622 |     9330 |   543216
total    |  1251 |    19608 |  1167623
number of images per tracklet: 2 ~ 920, average 59.5
EXP_NAME:  base_mars_resnet50
Traceback (most recent call last):
File "train_v2v.py", line 125, in
main()
File "train_v2v.py", line 96, in main
triplet_loss_batch = triplet_loss(embeddings, y)
File "/home/fei/code/VKD/model/loss.py", line 208, in call
return super(OnlineTripletLoss, self).call(*args, **kwargs)
File "/home/fei/anaconda3/envs/VKD/lib/python3.6/site-packages/torch/nn/modules/module.py", line 727, in _call_impl
result = self.forward(*input, **kwargs)
File "/home/fei/code/VKD/model/loss.py", line 146, in forward
negative_mask = same_id_mask ^ 1
RuntimeError: result type Long can't be cast to the desired output type Bool
How can I fix it ？

Besides, can you share the "test_track.txt" in VeRi776? This file was not included in their original dataset. Thanks a lot!

Besides, can you share the "test_track.txt" in VeRi776? This file was not included in their original dataset. Thanks a lot!

Hi,
The error is probably due to the new version of Pytorch; however, you can fix it by replacing the "1" with "True" (as suggested here).
Regarding VeRi776, you can download from here the file you are looking for.

Hi,
The error is probably due to the new version of Pytorch; however, you can fix it by replacing the "1" with "True" (as suggested here).
Regarding VeRi776, you can download from here the file you are looking for.


Telepot stopped after some time

Hi!
I've stuck with with issue, when telepot stopped receiving any updates after some time.
Script is running on my Raspberry Pi 3 model B. :
Raspbian GNU/Linux 9 (stretch)
Linux TopoR-Pi 4.9.59-v7+ #1047 SMP Sun Oct 29 12:19:23 GMT 2017 armv7l GNU/Linux

Scripts running by sh in rc.local:
setsid sh /home/pi/Documents/Scripts/launcher.sh &
And launcher.sh:
sudo pkill -f chkDir.py
sudo pkill -f tgmMain.py
sudo pkill -f chkDisc.py

cd /
cd home/pi/Documents/Scripts
setsid python -u chkDir.py >> chkDirStd.log &
setsid python -u tgmMain.py >> tgmStd.log &
setsid python chkDisc.py &
cd /

Almost entirely example script:
import time
import random
import datetime
import telepot
import os
import logging
from telepot.loop import MessageLoop

bot = telepot.Bot('XXX:YYY')
def handle(msg):
    chat_id = msg['chat']['id']
    command = msg['text']
    logging.info('Recieved command: %s' % command)

    if command == '/roll':
        bot.sendMessage(chat_id, random.randint(1,6))
        logging.info('Sended Roll')
    elif command == '/time':
        bot.sendMessage(chat_id, str(datetime.datetime.now()))
        logging.info('Sended time')
    elif command == '/test':
    	os.system('xclock &')

def sendMsg(text):
    bot.sendMessage('ZZZ', text)
    logging.info('Sended text: %s' % text)

logging.basicConfig(filename='tgmMain.log',format='%(asctime)s %(message)s',level=logging.DEBUG)
MessageLoop(bot, handle).run_as_thread()
logging.info('Telegram bot started!')
print('Telegram stdout log started.')
while 1:
	time.sleep(30)

Entire tgmStd.log:
Telegram stdout log started.
tgmMain.log (last update 9 hrs ago, script still running by system):
2018-02-09 13:14:09,894 Telegram bot started!
2018-02-09 13:14:09,900 Converted retries value: 3 -> Retry(total=3, connect=None, read=None, redirect=0, status=None)
2018-02-09 13:14:09,902 Starting new HTTPS connection (1): api.telegram.org
2018-02-09 13:14:30,287 https://api.telegram.org:443 "POST /botXXX:YYY/getUpdates HTTP/1.1" 200 23
2018-02-09 13:14:30,393 Converted retries value: 3 -> Retry(total=3, connect=None, read=None, redirect=0, status=None)
2018-02-09 13:14:37,487 https://api.telegram.org:443 "POST /botXXX:YYY/getUpdates HTTP/1.1" 200 553
2018-02-09 13:14:37,490 Recieved command: /time
2018-02-09 13:14:37,494 Converted retries value: 3 -> Retry(total=3, connect=None, read=None, redirect=0, status=None)
2018-02-09 13:14:37,593 Converted retries value: 3 -> Retry(total=3, connect=None, read=None, redirect=0, status=None)
2018-02-09 13:14:37,594 Starting new HTTPS connection (2): api.telegram.org
2018-02-09 13:14:37,598 https://api.telegram.org:443 "POST /botXXX:YYY/sendMessage HTTP/1.1" 200 357
2018-02-09 13:14:37,601 Sended time
...
2018-02-12 03:11:12,660 https://api.telegram.org:443 "POST /botXXX:YYY/getUpdates HTTP/1.1" 200 23
2018-02-12 03:11:12,765 Converted retries value: 3 -> Retry(total=3, connect=None, read=None, redirect=0, status=None)
2018-02-12 03:11:32,988 https://api.telegram.org:443 "POST /botXXX:YYY/getUpdates HTTP/1.1" 200 23
2018-02-12 03:11:33,094 Converted retries value: 3 -> Retry(total=3, connect=None, read=None, redirect=0, status=None)
2018-02-12 03:11:53,599 https://api.telegram.org:443 "POST /botXXX:YYY/getUpdates HTTP/1.1" 200 23
2018-02-12 03:11:53,704 Converted retries value: 3 -> Retry(total=3, connect=None, read=None, redirect=0, status=None)

Other scripts sending messages to the bot via telepot, but loop in the hadler just stopping at random times.

Reminiscent of #239 and #242. I am sorry I still haven't fixed those issues. Someone suggested some solutions there which may be helpful.

I have same problem. None of the workarounds has helped


Revert test skip for subscription readiness

This reverts commit 15d22560efc769fe272db010a4c5a07139cb2768.
Fixes #
Proposed Changes

undoing #573 since this should be better that #659 is in

Release Note

Docs

/test pull-knative-sandbox-eventing-kafka-integration-test-channel-consolidated-sasl

/test all

@lberk @devguyio even with the latest changes, we are not able to remove the skip of this one test :disappointed:

/close


Rebuild/Build View

Implement rebuild/build view on demand - target: for applying new views to documents.

Adding key-spaces can help with this (like buckets in boltdb).

A sequence (view) keeps track of updated keys and each view has some info on last timestamp it processed and some info on previous ones.
Needs more deeply investigation.

Since view func changed to receive the Go struct (instead of JSON) (and also I got super sh!tty feedback at this alpha stage of this project and also it works for my cases and I do not care beyond that anymore); currently the only way to rebuild indexes is to reinsert all entries.


Question: Read connection string from Azure KeyVault

All connections strings and keys are stored in AzureKeyVault and so I currently set the connection string via:
services.AddSignalR().AddAzureSignalR(options =>
{
.... read connection string from key vault
options.ConnectionString = connectionString;
});
My question is what is the recommended approach if the connection string can't be obtained, e.g. Key Vault is temporarily down?  Ideally I would like to be able to set the connection string when it is back up.  Of course, happy for SignalR to be disabled until that happens, i.e. degraded functionality.  Is this possible?
Only approach I see at the moment is to not use KeyVault for the connection string which would be a real shame as we store everything else there.
Appreciate any help.

Azure SignalR supports reading configuration from different configuration provider, including Key Vault, JSON file and so on. Maybe you can add Key Vault as a configuration provider and also have your backup way. Configuration providers that are added later override previous key settings. The configuration is hot reload. I hope that this can help you.

FYI: Azure Key Vault availability and redundancy

Thank you will take a look.
This question comes as recently our app service has been restarted overnight and the request to key vault has failed temporarily (other services show that this usually only lasts a few seconds or more).  As key vault isn't available the code currently throws an exception from AddAzureSignalR which means our app doesn't start up, hence we need to determine how we resolve this.
Hopefully hooking up the key vault as a configuration provider will work but this has to be resilient to key vault not being there, i.e. keep trying, if not we are no better off.

If I understand correctly, a retry logic for key vault client should help?

Please feel free to reopen it if you still have any concerns about it.

BTW, you can also use msi, if your hub server is running in azure app service.
Followings are the samples of connection string with msi:

System assigned:   Endpoint=<your endpoint>;AuthType=aad;Version=1.0
User assigned:  Endpoint=<your endpoint>;AuthType=aad;ClientId=<your client id>;Version=1.0


I can't connect to the db server

(I am really new at this :) )
I work in azure cloud shell. I am following the text to the letter - both parts running in azure cloud shell.
I stop at "python manage.py migrate". => server is or down or is not accwpting at 5432
I don't know how to proceed. Can you help? Tnxs. @RMC

Podrobnosti dokumenta
⚠ Ne uredite tega razdelka. Potreben je za povezovanje težav med storitvama docs.microsoft.com in GitHub.

ID: 791bd216-532f-7f28-fa51-d95798397310
Version Independent ID: 4f7ff676-e4a5-cc41-6a43-ecb8fa1095fb
Content: Build a Python web app with PostgreSQL on Linux - Azure App Service
Content Source: articles/app-service/containers/tutorial-python-postgresql-app.md
Service: app-service-web
GitHub Login: @cephalin
Microsoft Alias: beverst;cephalin

I have to add a few things probably :) :

server is created and should be ready ("available" as stated in Azur portal),
on the other hand when cheked with "/etc/init.d/postgresql status" I get "11/main (port 5432): down"

Hi @rmcjst, thanks for the feedback! We are currently investigating and will update you shortly.


Allow custom class support in router-link component

It'd be nice to allow custom classes to be passed through to a <router-link> component. I often have a set of button styles that I use, and it'd be awesome if I had a little more control over the styling of any internal links. These classes could then get merged with the active class when the current link was set to "active".

You can already do that:
<router-link class="btn btn-success" tag="button"></router-link>

As for the active class: http://router.vuejs.org/en/api/options.html#linkactiveclass

Ah, thanks. Is there any documentation for this? Couldn't seem to find it online. Happy to help write some if not.

Did you open a feature request issue without even trying if it was possible too?

I just didn't think to even try putting it directly on the component. I presumed (wrongly) that the documented props were the only ones supported.


OData 2.0 result set

Data returned from OData 2.0 is structured like:
{ d : { results : [{ ... }, { ... }] } }
As the ODataAngularResources expects an array, the following error message is thrown:
Expected response to contain an array but got an object
Changing code below is solving this issue for me:
var promise = $http(httpConfig).then(function(response) {
                var data = response.data,
                  promise = value.$promise;

To
var promise = $http(httpConfig).then(function(response) {
                var data = response.data.d.results,
                  promise = value.$promise;

Odd output.  But no problems.
Please see angular's documentation for $resource.
Specifically in the actions section there are two options available to assist you here.
You could probably overload the odata action and set this to false if you want automatic handling.

isArray – {boolean=} – If true then the returned object for this action is an array, see returns section.

Or preferably you could take over transforming the response yourself.

transformResponse – {function(data, headersGetter)|Array.<function(data, headersGetter)>} – transform function or an array of such functions. The transform function takes the http response body and headers and returns its transformed (typically deserialized) version. By default, transformResponse will contain one function that checks if the response looks like a JSON string and deserializes it using angular.fromJson. To prevent this behavior, set transformResponse to an empty array: transformResponse: []

var resource = $odataresource('/user/:userId',{userId:'@id'},{
  query: {
    transformResponse: function (response) {
      return angular.fromJson(response.data.d.results);
    }
  }
}, {});

var response = resource.odata().query(function(response) {
  console.info('Received Response.' response);
});

Thanks again for your help. Great angular module! Changing the code to the following solved the issue:
const resource = this.$odataresource(
        this.SERVICE.URL,
        {},
        {
          odata: {
            transformResponse: function (response) {
              return angular.fromJson(response).d.results;
            },
            isArray: false
          }
        },
        {}
      )

resource
        .odata()
        .select([
          this.SERVICE.COLUMNS.COL01,
          this.SERVICE.COLUMNS.COL02
        ])
        .format('json')
        .query(
          (data) => {
            deferred.resolve(data);
          },
          (error) => {
            deferred.reject(error);
          }
        );


distance difference between banglerun and gpsrec

Tried gpsrec and banglerun a few times, and noticed a significant difference in the distance between those two.
What could be the cause?
Example:

Start gpsrec on a new track, (recording every 10 second), go back.
Start banglerun
Run
Look at banglrun (recorded 10.35 km), then press button 3 to stop and go back to the main page
Stop gpsrec, look at the track and plot the distance (8.9km), within the same time.

As both claim to use the GPS, the difference cannot be explained by gpsrec starting the recording later.
Any hints, ideas?

That is an odd one - however while banglerun will record the data less often to flash, it will look at GPS coordinates to log the distance every second, so if there is any randomness to the value that it receives from the GPS, that will add up over time.
Imagine if you ran quickly in a zig-zag. Obviously in the case, if you work out distance from a fix once a second it records more than if you do it once every 10 seconds.
We did originally have a Kalman filter in Banglerun which made a nice job of this, but some changes broke it and I couldn't easily fix it so it got removed. I think it's something that longer-term I'd like to add inside Bangle.js to provide more nicely filtered GPS data

The difference seems to be too big (more than 10%) to account for cutting edges between 1 second and 10 second measuring interval, (because I did not run so many corners). However my next analysis steps:

Try to download, visualize and measure the gpsrec tracks in a GIS
Try with smaller measuring interval of gpsrec

Yes - you can also download the banglerun tracks too, but they should contain basically identical data

Used  https://f-droid.org/en/packages/mobi.maptrek/ to view a track that has been recorded by gpsrec and banglerun. For the mentioned track there was only a difference of 62 meters, which is fine with different recording intervall and potentially a few seconds difference in stopping both applications. gpsrec had 8.971 and banglerun had 9.033. But banglerun was showing ~10.35 on the display, so my guess is that something is off with the live updated summary of the track distance in banglerun.
(BTW: would be a cool debugging feature if gpsrec could also display the tracks of banglerun).

I think the issue is as I said above - I guess banglerun is recording every 3 seconds or something, gpsrec is recording every 10 and gets less distance.
However BangleRun's display is using the GPS data that occurs every second to work out a distance, which means it records an even higher distance.
The Kalman filter would be the solution here...

The distance as calculated by Trekarta (former MapTrek) for the track from banglerun was shown as 9.033km, but banglerun itself showed much more about 10.35km (this is from my memory as I when I stop banglerun, the display is gone of course, but I am sure.) The same track recorded with 10 seconds with gpsrec and shown and calculated by trekarta was 8.971km long, so within trekarta the difference between the two intervals is 62 meters. Therefor my conclusion that the problem for the live summary of banglerun must be a different one, it is not the interval difference.
Another experiment a few days ago, I've changed the interval on gpsrec to 1 second (because I've thought that would be what banglerun uses), again there is a large difference. However I could not compare this in trekarta yet, because downloading did not work #766 :) )

Therefor my conclusion that the problem for the live summary of banglerun must be a different one, it is not the interval difference.

I don't really understand what you mean here.
But I think that when you do get the 1 sample/second data off the Bangle, you'll find that if you sum the distances between fix points it will exactly match what BangleRun reported

when you do get the 1 sample/second data off the Bangle, you'll find that if you sum the distances between fix points it will exactly match what BangleRun reported

That is not what I am seeing.
I saw BangleRun reporting 10.35 (memory), and Trekarta 9.033 (via gpx download from banglerun) on the same track.
This would also explain the difference of BangleRun reporting to the gpsrec over the same session. gpsrec session displayed on the watch and on trekarta (gpx download) matches up.

But what data was Trekarta using? Wasn't it data only recorded every 10 sec or 3 sec, not every 1 second?

Let me call this one session where I took the watch to physically run roughly 9km session A.
In session A I have started both first gpsrec, then banglerun, using the default values. I've looked at banglerun, memoriesed the distance it displayed, stopped first banglerun, then gpsrec at the end of the session. A has been a few days ago. Later I've downloaded both recordings as gpx data files, both covering A.
Then I've displayed them both with Trekarta, I could see that banglerun used more datapoints. So the banglerun track has whatever banglerun uses as interval (given from what you have told me, probably 3 secs) and gpsrec had 10 secs.

Closing this now as we have the Run app and Recorder. There's some discussion on the forum but I think everyone seems happy with the distance calcs now: http://forum.espruino.com/conversations/371899

Closing this now as we have the Run app and Recorder.

Okay, if this is a no-fix because banglerun is outdated.
In my Run and Recorder apps, I've experienced the same defect of the Run calculation, just added this to the discussion you've mentioned. http://forum.espruino.com/comments/16382715/

Ok, lets discuss on there... I'm deprecating BangleRun and will probably get rid of it at some point soon, but if we can find the same issues with the Run app then obviously that's an issue


Try It Out Image Reset

Try out an image
Click "Test another image"

The Image and the results should be cleared and button should be disabled

validate on VS2019 and VS2019 preview


Build time regression in 2.10.1

Environment
StackBlitz
------------------------------
- Operating System: Linux
- Node Version:     v18.20.3
- Nitro Version:    2.9.7
- Package Manager<EMAIL_ADDRESS>------------------------------

vs
------------------------------
- Operating System: Linux
- Node Version:     v18.20.3
- Nitro Version:    2.10.3
- Package Manager<EMAIL_ADDRESS>------------------------------

Reproduction
- Go to https://stackblitz.com/edit/github-rppbve
- Run `npm run build`
- Note time it took to execute the command (5s here)

- Go to https://stackblitz.com/github/nitrojs/nitro/tree/main/examples/hello-world
- Run `npm run build`
- Note time it took to execute the command (8s here)

Describe the bug
The discrepancy, while small, is consistent with the minimal reproduction. In my project the total build time doubled from roughly 70-80 seconds to 140-160 seconds. Not sure what more of a reproduction exactly can I provide for this, luckily the change is noticeable even with minimal hello-world example straight from the home page.
One clue perhaps useful to the case, the nuxt prerender takes significantly longer; from ~10s to ~25s to do seemingly the same work; and it does not seem to be related to time spent on actual pages rendered:
ℹ Initializing prerenderer
ℹ Prerendering 1 routes
  ├─ /api/_content/cache.1730940049395.json (225ms)
ℹ Prerendered 1 routes in 10.558 seconds

[nitro] ℹ Initializing prerenderer
[nitro] ℹ Prerendering 1 routes
[nitro]   ├─ /api/_content/cache.1730933270977.json (98ms)
[nitro] ℹ Prerendered 1 routes in 25.281 seconds

Additional context
No response
Logs
No response

I'm facing the same issue here : the build step for Nitro is now taking 2 minutes instead of the previous 40s :(
Here is a CI job on the new Nitro version : https://github.com/antoinezanardi/werewolves-assistant-web-next/actions/runs/11699055175
Here is a CI job on the old Nitro version : https://github.com/antoinezanardi/werewolves-assistant-web-next/actions/runs/11529961414
You can check the build step to see the build time increase.

Investigating

The same problem. The Vercel build process increased to more than 6 minutes after the upgrade, from about 3:40 before.

(please use 👍🏼 if you have same issue. please share a runnable reporuction if you can)

Two observations inspecting werewolves-assistant-web-next (develop branch) (1)

Strangely there are 2 prerender builds (each take ~14s) and then actual build that takes ~170s.
The biggest step is for generate module graph stage (164s of total 170s in prod) and it is not from plugin hooks.

This is not an issue and if you have relatively smaller projects (Nuxt or Nitro both fine) that can make significant diff only by upgrading Nitro to 2.10 please share it would be super helpful 🙏🏼

 build 1 (before prerender)
BUILD (14.7s)

initialize (10.535ms)
  (unknown)                                6.212ms
  plugin 3 (unimport) - buildStart         3.519ms
  plugin 21 (commonjs) - buildStart        0.363ms
  plugin 20 (node-resolve) - buildStart    0.318ms
  plugin 18 (alias) - buildStart           0.108ms
  plugin 6 (replace) - buildStart          0.015ms

generate module graph (13.657s)
  (unknown)                                6.872s
  generate ast                             1.362s
  plugin 23 (inject) - transform           1.226s
  plugin 19 (node-externals) - resolveId   590.832ms
  plugin 2 (impound) - resolveId           442.001ms
  plugin 9 (virtual) - resolveId           274.211ms
  plugin 12 (virtual) - resolveId          242.525ms
  plugin 11 (virtual) - resolveId          238.853ms
  plugin 10 (virtual) - resolveId          234.539ms
  plugin 14 (virtual) - resolveId          225.318ms
  plugin 15 (virtual) - resolveId          224.386ms
  plugin 21 (commonjs) - transform         222.77ms
  plugin 16 (virtual) - resolveId          219.394ms
  plugin 13 (virtual) - resolveId          216.887ms
  plugin 17 (virtual) - resolveId          213.313ms
  plugin 18 (alias) - resolveId            203.258ms
  plugin 6 (replace) - transform           156.261ms
  plugin 20 (node-resolve) - resolveId     150.604ms
  plugin 1 (impound) - resolveId           103.337ms
  plugin 8 (dynamic-require) - resolveId   82.622ms
  plugin 4 (raw) - resolveId               62.809ms
  plugin 0 (commonjs--resolver) - resolveId 52.991ms
  plugin 16 (virtual) - load               15.528ms
  plugin 8 (dynamic-require) - transform   6.173ms
  plugin 9 (virtual) - load                3.054ms
  plugin 3 (unimport) - transform          1.83ms
  plugin 14 (virtual) - load               1.596ms
  plugin 7 (esbuild) - transform           1.377ms
  plugin 21 (commonjs) - load              1.344ms
  plugin 10 (virtual) - load               1.004ms
  plugin 22 (json) - transform             0.982ms
  plugin 4 (raw) - load                    0.974ms
  plugin 8 (dynamic-require) - load        0.857ms
  plugin 4 (raw) - transform               0.836ms
  plugin 20 (node-resolve) - load          0.826ms
  plugin 17 (virtual) - load               0.666ms
  plugin 15 (virtual) - load               0.586ms
  plugin 13 (virtual) - load               0.578ms
  plugin 11 (virtual) - load               0.578ms
  plugin 12 (virtual) - load               0.503ms

sort and bind modules (65.284ms)

mark included statements (966.814ms)
  treeshaking pass 15                      150.628ms
  treeshaking pass 9                       74.312ms
  treeshaking pass 10                      68.193ms
  treeshaking pass 14                      47.911ms
  treeshaking pass 11                      46.11ms
  treeshaking pass 17                      42.415ms
  treeshaking pass 16                      41.211ms
  treeshaking pass 12                      38.365ms
  treeshaking pass 23                      35.965ms
  treeshaking pass 13                      35.307ms
  treeshaking pass 24                      34.915ms
  treeshaking pass 20                      34.423ms
  treeshaking pass 22                      34.085ms
  treeshaking pass 18                      33.802ms
  treeshaking pass 26                      33.777ms
  treeshaking pass 19                      33.681ms
  treeshaking pass 27                      33.563ms
  treeshaking pass 21                      32.96ms
  treeshaking pass 25                      32.743ms
  treeshaking pass 4                       19.128ms
  treeshaking pass 6                       16.244ms
  treeshaking pass 2                       11.089ms
  treeshaking pass 5                       10.088ms
  treeshaking pass 3                       9.408ms
  treeshaking pass 8                       6.767ms
  treeshaking pass 7                       5.502ms
  treeshaking pass 1                       3.768ms
  plugin 19 (node-externals) - buildEnd    0.221ms
  (unknown)                                0.203ms
  plugin 21 (commonjs) - buildEnd          0.032ms

 build 2 (prerender)
ℹ Prerendering

BUILD (14.051s)

initialize (4.176ms)
  (unknown)                                2.043ms
  plugin 3 (unimport) - buildStart         1.814ms
  plugin 21 (commonjs) - buildStart        0.225ms
  plugin 20 (node-resolve) - buildStart    0.062ms
  plugin 18 (alias) - buildStart           0.018ms
  plugin 6 (replace) - buildStart          0.015ms

generate module graph (13.042s)
  (unknown)                                6.381s
  plugin 23 (inject) - transform           1.201s
  generate ast                             1.118s
  plugin 19 (node-externals) - resolveId   508.149ms
  plugin 2 (impound) - resolveId           415.814ms
  plugin 9 (virtual) - resolveId           316.706ms
  plugin 17 (virtual) - resolveId          271.009ms
  plugin 10 (virtual) - resolveId          270.71ms
  plugin 13 (virtual) - resolveId          268.529ms
  plugin 16 (virtual) - resolveId          263.826ms
  plugin 15 (virtual) - resolveId          262.893ms
  plugin 12 (virtual) - resolveId          261.458ms
  plugin 14 (virtual) - resolveId          256.908ms
  plugin 11 (virtual) - resolveId          249.994ms
  plugin 18 (alias) - resolveId            206.173ms
  plugin 21 (commonjs) - transform         205.266ms
  plugin 6 (replace) - transform           145.445ms
  plugin 20 (node-resolve) - resolveId     136.688ms
  plugin 1 (impound) - resolveId           87.584ms
  plugin 8 (dynamic-require) - resolveId   85.618ms
  plugin 4 (raw) - resolveId               57.635ms
  plugin 0 (commonjs--resolver) - resolveId 46.116ms
  plugin 16 (virtual) - load               11.752ms
  plugin 8 (dynamic-require) - transform   4.414ms
  plugin 3 (unimport) - transform          1.404ms
  plugin 7 (esbuild) - transform           0.971ms
  plugin 14 (virtual) - load               0.966ms
  plugin 21 (commonjs) - load              0.63ms
  plugin 22 (json) - transform             0.578ms
  plugin 10 (virtual) - load               0.576ms
  plugin 4 (raw) - load                    0.568ms
  plugin 4 (raw) - transform               0.548ms
  plugin 8 (dynamic-require) - load        0.465ms
  plugin 9 (virtual) - load                0.465ms
  plugin 17 (virtual) - load               0.458ms
  plugin 20 (node-resolve) - load          0.414ms
  plugin 12 (virtual) - load               0.41ms
  plugin 13 (virtual) - load               0.398ms
  plugin 15 (virtual) - load               0.36ms
  plugin 11 (virtual) - load               0.359ms

sort and bind modules (95.728ms)

mark included statements (908.775ms)
  treeshaking pass 15                      74.83ms
  treeshaking pass 10                      73.649ms
  treeshaking pass 9                       72.637ms
  treeshaking pass 14                      47.473ms
  treeshaking pass 11                      46.145ms
  treeshaking pass 16                      43.623ms
  treeshaking pass 26                      39.599ms
  treeshaking pass 19                      38.22ms
  treeshaking pass 12                      38.185ms
  treeshaking pass 13                      36.36ms
  treeshaking pass 23                      36.217ms
  treeshaking pass 20                      35.7ms
  treeshaking pass 21                      34.803ms
  treeshaking pass 17                      33.443ms
  treeshaking pass 27                      33.385ms
  treeshaking pass 18                      32.97ms
  treeshaking pass 25                      32.395ms
  treeshaking pass 22                      31.981ms
  treeshaking pass 24                      30.566ms
  treeshaking pass 4                       23.453ms
  treeshaking pass 2                       20.848ms
  treeshaking pass 5                       13.766ms
  treeshaking pass 6                       11.012ms
  treeshaking pass 3                       9.148ms
  treeshaking pass 7                       9.063ms
  treeshaking pass 8                       6.522ms
  treeshaking pass 1                       2.559ms
  (unknown)                                0.214ms
  plugin 19 (node-externals) - buildEnd    0.007ms
  plugin 21 (commonjs) - buildEnd          0.003ms

 build 3 (production)
BUILD (170.366s)

initialize (5.6ms)
  (unknown)                                3.134ms
  plugin 4 (unimport) - buildStart         2.416ms
  plugin 22 (commonjs) - buildStart        0.018ms
  plugin 21 (node-resolve) - buildStart    0.017ms
  plugin 19 (alias) - buildStart           0.011ms
  plugin 7 (replace) - buildStart          0.004ms

generate module graph (164.277s)
  (unknown)                                157.506s
  generate ast                             1.308s
  plugin 24 (inject) - transform           1.088s
  plugin 20 (node-externals) - resolveId   666.087ms
  plugin 2 (impound) - resolveId           438.972ms
  plugin 7 (replace) - transform           392.37ms
  plugin 10 (virtual) - resolveId          259.895ms
  plugin 18 (virtual) - resolveId          233.579ms
  plugin 12 (virtual) - resolveId          226.639ms
  plugin 13 (virtual) - resolveId          225.376ms
  plugin 22 (commonjs) - transform         219.203ms
  plugin 16 (virtual) - resolveId          219.011ms
  plugin 17 (virtual) - resolveId          216.902ms
  plugin 15 (virtual) - resolveId          216.348ms
  plugin 11 (virtual) - resolveId          209.446ms
  plugin 14 (virtual) - resolveId          207.443ms
  plugin 19 (alias) - resolveId            185.727ms
  plugin 21 (node-resolve) - resolveId     142.222ms
  plugin 1 (impound) - resolveId           91.907ms
  plugin 9 (dynamic-require) - resolveId   82.209ms
  plugin 5 (raw) - resolveId               58.254ms
  plugin 0 (commonjs--resolver) - resolveId 46.706ms
  plugin 17 (virtual) - load               15.369ms
  plugin 9 (dynamic-require) - transform   5.701ms
  plugin 3 (nuxt:sourcemap-import) - load  3.959ms
  plugin 4 (unimport) - transform          1.718ms
  plugin 15 (virtual) - load               1.361ms
  plugin 5 (raw) - transform               1.275ms
  plugin 8 (esbuild) - transform           1.001ms
  plugin 5 (raw) - load                    0.901ms
  plugin 11 (virtual) - load               0.842ms
  plugin 22 (commonjs) - load              0.788ms
  plugin 23 (json) - transform             0.775ms
  plugin 10 (virtual) - load               0.586ms
  plugin 9 (dynamic-require) - load        0.439ms
  plugin 21 (node-resolve) - load          0.407ms
  plugin 12 (virtual) - load               0.364ms
  plugin 14 (virtual) - load               0.34ms
  plugin 16 (virtual) - load               0.334ms
  plugin 13 (virtual) - load               0.333ms
  plugin 18 (virtual) - load               0.33ms

sort and bind modules (77.559ms)

mark included statements (1.197s)
  treeshaking pass 9                       235.437ms
  treeshaking pass 10                      144.71ms
  treeshaking pass 15                      80.844ms
  treeshaking pass 14                      50.142ms
  treeshaking pass 11                      49.04ms
  treeshaking pass 16                      44.522ms
  treeshaking pass 12                      40.975ms
  treeshaking pass 13                      38.836ms
  treeshaking pass 17                      38.834ms
  treeshaking pass 18                      37.385ms
  treeshaking pass 22                      37.247ms
  treeshaking pass 21                      37.035ms
  treeshaking pass 25                      36.88ms
  treeshaking pass 19                      36.79ms
  treeshaking pass 24                      36.346ms
  treeshaking pass 27                      35.832ms
  treeshaking pass 23                      35.812ms
  treeshaking pass 20                      35.666ms
  treeshaking pass 26                      34.922ms
  treeshaking pass 8                       21.98ms
  treeshaking pass 4                       21.761ms
  treeshaking pass 6                       16.077ms
  treeshaking pass 5                       14.657ms
  treeshaking pass 3                       14.002ms
  treeshaking pass 7                       10.403ms
  treeshaking pass 2                       7.655ms
  treeshaking pass 1                       3.054ms
  plugin 20 (node-externals) - buildEnd    1.057ms
  plugin 22 (commonjs) - buildEnd          0.043ms
  (unknown)                                -0.887ms

(1) I used rollup built-in perf flag. Doing is a little bit tricky you need to enable rollupConfig.perf and then access build result which is currently not exposed via Nitro hooks (need patching node_modules/nitropack/dist/core/index.mjs ~L1570). I made a custom reporter

Here are the results from the ~150s project I have described, this time running without docker for my convenience, it is still 2x slower than previously:

Nitro 2.10.3 - prerender phase of Nuxt
BUILD (30.418s)

initialize (1.93ms)
  plugin 3 (unimport) - buildStart         1.149ms
  (unknown)                                0.467ms
  plugin 21 (commonjs) - buildStart        0.19ms
  plugin 20 (node-resolve) - buildStart    0.071ms
  plugin 18 (alias) - buildStart           0.046ms
  plugin 6 (replace) - buildStart          0.007ms

generate module graph (29.451s)
  (unknown)                                21.075s
  plugin 19 (node-externals) - resolveId   846.776ms
  plugin 2 (impound) - resolveId           653.101ms
  plugin 9 (virtual) - resolveId           525.124ms
  generate ast                             519.381ms
  plugin 23 (inject) - transform           490.651ms
  plugin 10 (virtual) - resolveId          428.613ms
  plugin 15 (virtual) - resolveId          426.197ms
  plugin 14 (virtual) - resolveId          418.779ms
  plugin 11 (virtual) - resolveId          409.507ms
  plugin 18 (alias) - resolveId            409.047ms
  plugin 20 (node-resolve) - resolveId     406.746ms
  plugin 12 (virtual) - resolveId          402.607ms
  plugin 13 (virtual) - resolveId          399.312ms
  plugin 16 (virtual) - resolveId          398.959ms
  plugin 17 (virtual) - resolveId          395.99ms
  plugin 1 (impound) - resolveId           265.422ms
  plugin 8 (dynamic-require) - resolveId   255.055ms
  plugin 0 (commonjs--resolver) - resolveId 145.313ms
  plugin 4 (raw) - resolveId               144.982ms
  plugin 3 (unimport) - transform          112.483ms
  plugin 21 (commonjs) - transform         106.104ms
  plugin 6 (replace) - transform           70.833ms
  plugin 7 (esbuild) - transform           50.265ms
  plugin 16 (virtual) - load               16.03ms
  plugin 8 (dynamic-require) - transform   9.145ms
  plugin 4 (raw) - load                    6.667ms
  plugin 8 (dynamic-require) - load        5.76ms
  plugin 21 (commonjs) - load              5.491ms
  plugin 9 (virtual) - load                5.419ms
  plugin 4 (raw) - transform               5.259ms
  plugin 22 (json) - transform             5.124ms
  plugin 10 (virtual) - load               4.868ms
  plugin 13 (virtual) - load               4.801ms
  plugin 20 (node-resolve) - load          4.761ms
  plugin 14 (virtual) - load               4.712ms
  plugin 11 (virtual) - load               4.139ms
  plugin 17 (virtual) - load               4.112ms
  plugin 15 (virtual) - load               3.999ms
  plugin 12 (virtual) - load               3.977ms

sort and bind modules (67.586ms)

mark included statements (897.655ms)
  treeshaking pass 15                      78.47ms
  treeshaking pass 17                      57.893ms
  treeshaking pass 16                      56.716ms
  treeshaking pass 14                      46.081ms
  treeshaking pass 11                      43.971ms
  treeshaking pass 18                      43.191ms
  treeshaking pass 19                      42.203ms
  treeshaking pass 10                      41.009ms
  treeshaking pass 9                       40.126ms
  treeshaking pass 23                      38.158ms
  treeshaking pass 20                      37.71ms
  treeshaking pass 27                      37.549ms
  treeshaking pass 22                      36.849ms
  treeshaking pass 21                      36.25ms
  treeshaking pass 26                      35.409ms
  treeshaking pass 24                      35.104ms
  treeshaking pass 25                      34.878ms
  treeshaking pass 13                      34.847ms
  treeshaking pass 12                      34.102ms
  treeshaking pass 8                       32.011ms
  treeshaking pass 2                       15.497ms
  treeshaking pass 1                       8.314ms
  treeshaking pass 5                       7.84ms
  treeshaking pass 6                       7.252ms
  treeshaking pass 3                       5.785ms
  treeshaking pass 4                       5.606ms
  treeshaking pass 7                       4.105ms
  (unknown)                                0.467ms
  plugin 19 (node-externals) - buildEnd    0.225ms
  plugin 21 (commonjs) - buildEnd          0.039ms

Nitro 2.10.3 - build phase of Nuxt
BUILD (68.618s)

initialize (1.669ms)
  plugin 4 (unimport) - buildStart         1.181ms
  (unknown)                                0.376ms
  plugin 22 (commonjs) - buildStart        0.082ms
  plugin 21 (node-resolve) - buildStart    0.015ms
  plugin 19 (alias) - buildStart           0.008ms
  plugin 7 (replace) - buildStart          0.007ms

generate module graph (61.209s)
  (unknown)                                53.041s
  plugin 20 (node-externals) - resolveId   918.953ms
  generate ast                             575.389ms
  plugin 2 (impound) - resolveId           561.144ms
  plugin 24 (inject) - transform           511.948ms
  plugin 10 (virtual) - resolveId          500.074ms
  plugin 12 (virtual) - resolveId          405.605ms
  plugin 11 (virtual) - resolveId          398.7ms
  plugin 21 (node-resolve) - resolveId     395.101ms
  plugin 14 (virtual) - resolveId          394.732ms
  plugin 13 (virtual) - resolveId          386.407ms
  plugin 15 (virtual) - resolveId          384.763ms
  plugin 16 (virtual) - resolveId          381.358ms
  plugin 18 (virtual) - resolveId          378.179ms
  plugin 17 (virtual) - resolveId          374.841ms
  plugin 19 (alias) - resolveId            332.351ms
  plugin 1 (impound) - resolveId           231.6ms
  plugin 9 (dynamic-require) - resolveId   215.139ms
  plugin 0 (commonjs--resolver) - resolveId 144.869ms
  plugin 7 (replace) - transform           143.272ms
  plugin 5 (raw) - resolveId               131.352ms
  plugin 4 (unimport) - transform          119.995ms
  plugin 22 (commonjs) - transform         112.944ms
  plugin 8 (esbuild) - transform           49.349ms
  plugin 3 (nuxt:sourcemap-import) - load  47.978ms
  plugin 17 (virtual) - load               13.431ms
  plugin 9 (dynamic-require) - transform   10.104ms
  plugin 5 (raw) - transform               6.879ms
  plugin 23 (json) - transform             5.103ms
  plugin 5 (raw) - load                    4.349ms
  plugin 22 (commonjs) - load              3.78ms
  plugin 9 (dynamic-require) - load        3.103ms
  plugin 10 (virtual) - load               3.035ms
  plugin 16 (virtual) - load               2.967ms
  plugin 21 (node-resolve) - load          2.934ms
  plugin 15 (virtual) - load               2.863ms
  plugin 18 (virtual) - load               2.711ms
  plugin 11 (virtual) - load               2.583ms
  plugin 12 (virtual) - load               2.532ms
  plugin 14 (virtual) - load               2.51ms
  plugin 13 (virtual) - load               2.504ms

sort and bind modules (82.026ms)

mark included statements (1.043s)
  treeshaking pass 15                      85.777ms
  treeshaking pass 16                      61.491ms
  treeshaking pass 17                      60.172ms
  treeshaking pass 14                      50.754ms
  treeshaking pass 18                      50.705ms
  treeshaking pass 19                      49.333ms
  treeshaking pass 21                      49.032ms
  treeshaking pass 27                      46.113ms
  treeshaking pass 10                      45.988ms
  treeshaking pass 20                      44.998ms
  treeshaking pass 25                      44.96ms
  treeshaking pass 22                      44.935ms
  treeshaking pass 24                      44.6ms
  treeshaking pass 11                      44.53ms
  treeshaking pass 23                      44.11ms
  treeshaking pass 26                      43.265ms
  treeshaking pass 9                       40.654ms
  treeshaking pass 12                      40.092ms
  treeshaking pass 13                      37.01ms
  treeshaking pass 8                       33.574ms
  treeshaking pass 3                       18.966ms
  treeshaking pass 4                       15.601ms
  treeshaking pass 5                       12.715ms
  treeshaking pass 7                       11.45ms
  treeshaking pass 6                       11.022ms
  treeshaking pass 2                       6.323ms
  treeshaking pass 1                       3.896ms
  plugin 20 (node-externals) - buildEnd    1.19ms
  plugin 22 (commonjs) - buildEnd          0.006ms
  (unknown)                                -0.737ms

Nitro 2.9.7 - prerender phase of Nuxt
BUILD (11.264s)

initialize (1.663ms)
  plugin 2 (unimport) - buildStart         1.074ms
  (unknown)                                0.311ms
  plugin 19 (commonjs) - buildStart        0.155ms
  plugin 18 (node-resolve) - buildStart    0.071ms
  plugin 16 (alias) - buildStart           0.045ms
  plugin 5 (replace) - buildStart          0.007ms

generate module graph (10.354s)
  (unknown)                                7.361s
  generate ast                             507.734ms
  plugin 21 (inject) - transform           471.694ms
  plugin 17 (node-externals) - resolveId   214.144ms
  plugin 1 (impound) - resolveId           167.181ms
  plugin 18 (node-resolve) - resolveId     120.932ms
  plugin 2 (unimport) - transform          118.561ms
  plugin 8 (virtual) - resolveId           115.884ms
  plugin 10 (virtual) - resolveId          110.28ms
  plugin 19 (commonjs) - transform         107.624ms
  plugin 16 (alias) - resolveId            101.704ms
  plugin 11 (virtual) - resolveId          93.794ms
  plugin 14 (virtual) - resolveId          91.121ms
  plugin 9 (virtual) - resolveId           90.721ms
  plugin 12 (virtual) - resolveId          88.226ms
  plugin 15 (virtual) - resolveId          86.542ms
  plugin 13 (virtual) - resolveId          85.84ms
  plugin 0 (commonjs--resolver) - resolveId 79.13ms
  plugin 5 (replace) - transform           77.473ms
  plugin 3 (raw) - resolveId               64.405ms
  plugin 6 (esbuild) - transform           58.227ms
  plugin 7 (dynamic-require) - resolveId   54.722ms
  plugin 14 (virtual) - load               14.134ms
  plugin 7 (dynamic-require) - transform   9.614ms
  plugin 3 (raw) - load                    6.429ms
  plugin 7 (dynamic-require) - load        5.977ms
  plugin 3 (raw) - transform               5.351ms
  plugin 12 (virtual) - load               5.325ms
  plugin 8 (virtual) - load                4.9ms
  plugin 18 (node-resolve) - load          4.875ms
  plugin 19 (commonjs) - load              4.859ms
  plugin 20 (json) - transform             4.786ms
  plugin 9 (virtual) - load                4.627ms
  plugin 15 (virtual) - load               4.324ms
  plugin 10 (virtual) - load               4.279ms
  plugin 11 (virtual) - load               4.21ms
  plugin 13 (virtual) - load               4.066ms

sort and bind modules (60.764ms)

mark included statements (846.471ms)
  treeshaking pass 15                      74.098ms
  treeshaking pass 16                      65.922ms
  treeshaking pass 17                      58.385ms
  treeshaking pass 14                      48.512ms
  treeshaking pass 18                      46.639ms
  treeshaking pass 19                      41.827ms
  treeshaking pass 20                      40.254ms
  treeshaking pass 23                      37.109ms
  treeshaking pass 11                      36.863ms
  treeshaking pass 21                      36.124ms
  treeshaking pass 10                      36.085ms
  treeshaking pass 24                      35.729ms
  treeshaking pass 22                      35.669ms
  treeshaking pass 27                      35.032ms
  treeshaking pass 26                      34.713ms
  treeshaking pass 25                      34.683ms
  treeshaking pass 9                       33.206ms
  treeshaking pass 12                      31.391ms
  treeshaking pass 13                      29.01ms
  treeshaking pass 8                       27.994ms
  treeshaking pass 3                       6.823ms
  treeshaking pass 5                       5.646ms
  treeshaking pass 4                       4.784ms
  treeshaking pass 6                       4.758ms
  treeshaking pass 7                       3.67ms
  treeshaking pass 1                       0.645ms
  treeshaking pass 2                       0.442ms
  plugin 17 (node-externals) - buildEnd    0.349ms
  (unknown)                                0.072ms
  plugin 19 (commonjs) - buildEnd          0.039ms

Nitro 2.9.7 - build phase of Nuxt
BUILD (23.121s)

initialize (1.515ms)
  plugin 3 (unimport) - buildStart         1.108ms
  (unknown)                                0.361ms
  plugin 20 (commonjs) - buildStart        0.018ms
  plugin 19 (node-resolve) - buildStart    0.013ms
  plugin 17 (alias) - buildStart           0.007ms
  plugin 6 (replace) - buildStart          0.006ms

generate module graph (15.888s)
  (unknown)                                12.698s
  generate ast                             593.646ms
  plugin 22 (inject) - transform           540.958ms
  plugin 18 (node-externals) - resolveId   204.004ms
  plugin 1 (impound) - resolveId           162.51ms
  plugin 6 (replace) - transform           141.938ms
  plugin 9 (virtual) - resolveId           137.567ms
  plugin 19 (node-resolve) - resolveId     117.529ms
  plugin 3 (unimport) - transform          116.72ms
  plugin 20 (commonjs) - transform         116.587ms
  plugin 11 (virtual) - resolveId          94.886ms
  plugin 14 (virtual) - resolveId          94.776ms
  plugin 10 (virtual) - resolveId          94.041ms
  plugin 12 (virtual) - resolveId          90.69ms
  plugin 15 (virtual) - resolveId          89.04ms
  plugin 17 (alias) - resolveId            88.769ms
  plugin 13 (virtual) - resolveId          85.476ms
  plugin 16 (virtual) - resolveId          85.096ms
  plugin 0 (commonjs--resolver) - resolveId 67.555ms
  plugin 4 (raw) - resolveId               61.334ms
  plugin 8 (dynamic-require) - resolveId   48.196ms
  plugin 7 (esbuild) - transform           48.034ms
  plugin 2 (nuxt:sourcemap-import) - load  44.448ms
  plugin 15 (virtual) - load               13.276ms
  plugin 8 (dynamic-require) - transform   10.026ms
  plugin 4 (raw) - transform               5.872ms
  plugin 21 (json) - transform             5.15ms
  plugin 4 (raw) - load                    3.773ms
  plugin 20 (commonjs) - load              3.171ms
  plugin 9 (virtual) - load                3.057ms
  plugin 8 (dynamic-require) - load        3.02ms
  plugin 19 (node-resolve) - load          2.902ms
  plugin 13 (virtual) - load               2.704ms
  plugin 10 (virtual) - load               2.617ms
  plugin 16 (virtual) - load               2.582ms
  plugin 12 (virtual) - load               2.493ms
  plugin 14 (virtual) - load               2.46ms
  plugin 11 (virtual) - load               2.437ms

sort and bind modules (69.251ms)

mark included statements (907.038ms)
  treeshaking pass 15                      89.166ms
  treeshaking pass 16                      57.58ms
  treeshaking pass 17                      53.114ms
  treeshaking pass 14                      48.77ms
  treeshaking pass 18                      44.566ms
  treeshaking pass 19                      42.552ms
  treeshaking pass 23                      39.72ms
  treeshaking pass 20                      39.297ms
  treeshaking pass 21                      39.158ms
  treeshaking pass 24                      39.074ms
  treeshaking pass 27                      38.759ms
  treeshaking pass 22                      38.525ms
  treeshaking pass 25                      38.478ms
  treeshaking pass 26                      38.226ms
  treeshaking pass 10                      37.684ms
  treeshaking pass 11                      37.387ms
  treeshaking pass 9                       35.011ms
  treeshaking pass 12                      34.115ms
  treeshaking pass 13                      32.868ms
  treeshaking pass 8                       31.509ms
  treeshaking pass 5                       12.135ms
  treeshaking pass 4                       11.554ms
  treeshaking pass 7                       9.797ms
  treeshaking pass 6                       8.975ms
  treeshaking pass 3                       6.496ms
  treeshaking pass 2                       1.547ms
  plugin 18 (node-externals) - buildEnd    0.948ms
  treeshaking pass 1                       0.608ms
  plugin 20 (commonjs) - buildEnd          0.005ms
  (unknown)                                -0.588ms

Now, I could not replicate the fast results when downgrading. To my understanding, this means the reason lies within one of the dependencies, which a dependency which is present in both 2.9.3 and 2.10.3, and is semver compatible between both versions.
$ git reset --hard $HEAD
$ rm -rf node_modules pnpm-lock.yaml && pnpm add -D<EMAIL_ADDRESS>$ pnpm build # fast
$ rm -rf node_modules pnpm-lock.yaml && pnpm add -D<EMAIL_ADDRESS>$ pnpm build # slow
$ rm pnpm-lock.yaml && pnpm add -D<EMAIL_ADDRESS>$ pnpm build # slow, is it re-using some deps from node_modules?
$ rm -rf node_modules pnpm-lock.yaml && pnpm add -D<EMAIL_ADDRESS>$ pnpm build # fast again

Playing with a bit more, most of what I stated above is bullshit. Dependencies are hard. I was on this yesterday, yet somehow totally forgot by the morning. Turns out running actual debugger instead of guessing is very useful, too.
{ "pnpm": { "overrides": { "nitropack": "$VERSION" } }

3.9.7: 10s
2.10.0: 10s
2.10.1: 41s
2.10.2: 24s
2.10.3: 24s

Reproducible, to lesser degree but reproducible, on StackBlitz with hello-world. Probably degraded because of https://github.com/nitrojs/nitro/pull/2838 and then (probably, somehow, maybe) improved by https://github.com/nitrojs/nitro/pull/2842.
Precisely, the regression is caused by moving the check on !extensions.has(extname(resolvedId)) after await this.resolve(id, importer, resolveOpts). Adding back the early return fixes the regression:
    async resolveId(id, importer, resolveOpts) {
      if (id === HELPER_ID) {
        return id;
      }

      if (id[0] === "\0") {
        return;
      }

      const withRawSpecifier = id.startsWith("raw:");
      if (withRawSpecifier) {
        id = id.slice(4);
      }

+     if (!withRawSpecifier && !extensions.has(extname(id))) {
+      return;
+     }

      const resolvedId = (await this.resolve(id, importer, resolveOpts))?.id;

      if (!resolvedId || resolvedId.startsWith("\0")) {
        return resolvedId;
      }

      if (!withRawSpecifier && !extensions.has(extname(resolvedId))) {
        return;
      }

      return { id: "\0raw:" + resolvedId };
    },

Thanks for your investigation, dear @Aareksio. Early returning on nonresolved id essentially reverts the purpose of #2838 (id can be foo.sql while referencing to foo.sql.ts)
I'm sure we are going on the right path and it seems the addition of this.resolve is causing perf overhead somehow.

Nice find dear @lukaszflorczak. Any chance you could share your testing project btw? This amount of overhead for plugin resolution seems unusual. (your fix is good feel free to open a draft PR 🙏🏼 )

I am aware this is essentially reverting the PR and reinstalling the issue. However, resolving every single .js file with filesystem, precisely lstat, is going to cause overhead. For the project in question (which is small even for our small scale) there are over 22,000 additional resolutions. It is very abstract, but cost of time and resources wasted on build stack really strongly against convinience of .sql.ts.
Not sure how to solve the issue properly without introducing the overhead :(

Thanks for the investigation team. I will share the new build time when Nuxt will be updated with the new Nitro release. Stay tuned 😉


#134 - fix to breaking changes introduced in Obsidian 1.5.4 (they did an internal refactoring of File Explorer, the fix follows the refactoring accordingly)

I'm the author of the obsidian-custom-sort plugin which was also affected by the breaking changes in File Explorer introduced in Obsidian 1.5.4
I did a reverse engineering of Obsidian code to track back the relevant changes and then applied the fixes onto my plugin.
The fixes are simple and isolated, in this pull request I'm showing how to apply them onto the alx-folder-note plugin (which I love and use every day).

This seems to take care of #133 as well. Also, using this in my vault and can confirm it works flawlessly. Thanks for the good work!

Hi @pho3nixf1re
I'm unclear on the processes and rules around PR's and merging them in this github project.
While I've created this pull request, at the same time I don't have the write access required to do a merge.
Who can do the actual merge (or additional review, if the process requires that)?

@SebastianMC I'm using your fork directly until this is merged in. Thanks

FYI
I'm the author of this pull request.
Unfortunately, this plugin (alx-folder-note) stopped working for me with Obsidian 1.7.1: the folder notes are no longer hidden in their parent folders (mode: 'same name as parent folder'). Reinstalling didn't help, playing with settings, etc.  - no effect. I've been using this plugin from the very beginning with Obsidian. It seems to be abandoned now, based on the timestamps of recent commits and the long queue of unresolved issues.
In result I switched to a different folder notes plugin, actively maintained, with equivalent functionality.
As a side effect, I will no longer maintain the code in this pull request.

@SebastianMC May you tell us the name of the other folder notes plugin? ^^

@SebastianMC Thanks for letting us know.
Yes, please plug the alternate folder notes plugin please

Hi @desvaters, @huyz,
updated my previous comment with an inline link.
The plugin is Folder notes by Lost Paul
It is actively maintained. It has a long list of open issues, but if you take a closer look it turns out that the author doesn't close them for some reason, even if answered, clarified or fixed.