Browserify compile error.

I get a browserify error that says Angular and Hammer cannot be found. I import them right above the angular-hammer import. When I took a closer look, it was searching inside the wrong folders for them: (node_modules\angular-hammer\node_modules\hammerjs\hammer.js) something like that. So I went into angular-hammer's package.json and removed angular and hammerjs from the browser property and all got fixed... Is this really how it should be acting?

This is still an issue and I would love if someone could give me an answer.

No, it's not supposed to be like that. Commit https://github.com/RyanMullins/angular-hammer/commit/ff754eefb189c10b621465df03d0a6a5f423917f contains a fix for Browserify, but it doesn't seem to be included in the main package.

Just did, though I can't say I did much in the way of testing.
It's probably obvious by this point, but I haven't been using this library much recently and I don't see myself having time to get back to it frequently. I'm going to try and find a solution to long-term maintenance this month.


InvalidOperationException on reading diagnostics string representation

Describe the bug
In my service I see rare occasional System.InvalidOperationException thrown on reading diagnostics string.
To Reproduce
The issue is intermittent, therefore there's no reliable way to reproduce it. Here are examples of code that can lead to that exception:
// Example #1
ItemResponse<T> response = cosmosContainer
   .ReadItemAsync<T>(itemId, new PartitionKey(partitionKey), cancellationToken: cancellationToken)
   .ConfigureAwait(false);

response.Diagnostics.ToString();    // Could throw

// Example #2
FeedResponse<T> response = await cosmosContainer
   .GetChangeFeedIterator<T>(continuation, options)
   .ReadNextAsync(cancellationToken);

response.Diagnostics.ToString();    // Could throw

Stack trace for example №1:
System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
   at System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource)
   at System.Collections.Generic.List`1.Enumerator.MoveNextRare()
   at Microsoft.Azure.Cosmos.Diagnostics.CosmosDiagnosticsSerializerVisitor.Visit(CosmosDiagnosticsContext cosmosDiagnosticsContext)
   at Microsoft.Azure.Cosmos.Diagnostics.CosmosDiagnosticsInternal.ToString()

Expected behavior
Expected to receive diagnostic information string.
Actual behavior
Most of the time code returns diagnostic information string, but sometimes InvalidOperationException is thrown
Environment summary
SDK Version: 3.7.1-preview
OS Version (e.g. Windows, Linux, MacOSX): Microsoft Windows 10.0.17763 |.NET Framework 4.7.3610.0

Hi @maxvasil,
The only way this should be possible is if the response is still getting processed when calling the Diagnostics.ToString(). Any chance you can reproduce the error? Do you use any custom handlers?
For example 1 is the missing await just a copy paste mistake?

Hi @j82w, thanks for quick answer.
So far I didn't find the way to reproduce the issue.
Custom handlers are not used.

For example 1 is the missing await just a copy paste mistake?
Thanks for notice, that is copy-paste mistake. I've fixed it in the issue description.

@maxvasil I haven't had any luck with reproducing the issue. Is there any chance that you can catch the exception and try logging the diagnostics again so we can see what is being added to the diagnostics after the response has returned?

@j82w, sure, I'll try to do that. Is there a chance that 2nd attempt to get diagnostic string representation will be successful?


Sections with custom UIView won't scroll

Yo, Pete
Great parallax VC, and super easy to config with xib specially.
Right now it seems to be having this very problem that, if you call the api in UITableViewDelelgate
- (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section
   The custom section is initialized, but when scrolling the table, the section view stays still
   I have no idea if i'm doing sth wrong so as to cause the problem or other condition, lemme know

   Thanks in advance.

Hi
I already did solve this and will release an update :)
Temporary you can subclass the uitablevie as described in readme
On Thursday, February 5, 2015, tobatha<EMAIL_ADDRESS>wrote:

Yo, Pete
Great parallax VC, and super easy to config with xib specially.
Right now it seems to be having this very problem that, if you call the
api in UITableViewDelelgate

(UIView *)tableView:(UITableView *)tableView
viewForHeaderInSection:(NSInteger)section
The custom section is initialized, but when scrolling the table, the section view stays still
I have no idea if i'm doing sth wrong so as to cause the problem or other condition, lemme know
Thanks in advance.

—
Reply to this email directly or view it on GitHub
https://github.com/peterpaulis/M6UniversalParallaxViewController/issues/5
.

--
Prajem príjemný deň...
Mgr. Peter Paulis

Hi Pete,
i did subclass the tableview in storyboard to M6HeaderInsetTableView like in the demo project, but the custom section view will stay at the originated position and functions like normal table view does, as if the the table view's height is not growing when scrolling up

Hi, pls see the latest code just pushed https://github.com/peterpaulis/M6UniversalParallaxViewController


mfccInitFilterBanks() takes 2 positional arguments but 7 were give

anyone got this error?

You can remove the arguments (lowfreq, linsc, logsc, nlinfil, nlogfil) from the call in the stFeatureSpeed function


conda env installation error

I'm trying to create a conda environment with
conda create --yes --quiet -p conda-env python=2.7 openmmtools openmm matplotlib pymbar netcdf4 seaborn

but end up with this odd error:
Error: PREFIX too long: 142 characters, but only 128 allowed
Error: Error: post-link failed for: openssl-1.0.1k-1

This seems to be because I am in a subdirectory with a long absolute pathname.  When I create the environment in $HOME, things work fine.
Has anyone else encountered this?

Looks like this can be avoided by using -n env-name instead of -p path.


zh_cn translation for 3.0

I think everything is fine
After merge I'll only change serverReticleExtended translation 服务端瞄准环 -> 服务端瞄准环外观配置 because on the rest of the extended reticles that suffix was present
I hope that it has proper meaning; correct me if I am wrong, because I don't speak Chinese at all, it's my pure guess
Thanks for translations!
In some further updates I'll rethink if the extended reticles should instead be "extensions of standard reticles" rather than "independent reticles", because it sure can be confusing for users

Oh , yes your Chinese is good enough!  😄 .Great to have corrected that .


Decouple authentication information from business layer

Currently authentication information like the LDAP loginname is tightly coupled with the business layer code of Urlaubsverwaltung. Most prominentily (among other places) in the Person business object and corresponding services.
The only purpose of this information is authentication handling. It must not be coupled with the business code or it will be very difficult to change the authentication mechanism without changing the business behaviour.
This becomes apparent with the introduction of OIDC, where the provided authentication id is no longer a comprehensible name that can or should be used in any user-interaction.

All authentication information should be removed from the business logic and contained to authentication-related logic.
Probably a mapping from authentication-id to person is still needed by the authentication mechanism. This has to be evaluated and provided if necessary.

this one was done over the last year in several prs


ipodtouch0218: Watch bacuridigital.com

ipodtouch0218 requests the watch of the watch_keyword bacuridigital\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

From https://metasmoke.erwaysoftware.com/post/511074

Approved by Cow in Charcoal HQ


At Run examples from your IDE, the python example has 'python' written in the first line before the imports.

@diogobaltazar commented on Tue Mar 31 2020
[Tapez vos commentaires ici]

Détails du document
⚠ Ne pas modifier cette section. C’est obligatoire pour docs.microsoft.com ➟ Liaison des problèmes GitHub.

ID: 3642022f-a58f-6290-ecf1-3c551a9bfc96
Version Independent ID: cf117e4e-c261-858c-517e-04d67e44c35e
Content: Databricks Connect-Azure Databricks
Content Source: databricks/dev-tools/databricks-connect.md
Service: azure-databricks
GitHub Login: @mamccrea
Microsoft Alias: mamccrea

@srvbpigh commented on Tue Mar 31 2020
Hello, @diogobaltazar
Thank you for your feedback.
We are actively reviewing your comments and will get back to you soon.
Kind regards,
Microsoft DOCS International Team

Hi @diogobaltazar , Thanks for the feedback and bringing this to our notice. At this time we are reviewing the feedback and will update the document as appropriate.

@mamccrea Could you please update the doc as per the feedback from @diogobaltazar. Thanks!

Thank you for providing this feedback! I've updated the doc. Please allow a few days for the change to be published.
#please-close


Notification fails silently

I have successfully associated an account with pushbullet in nodeBB.
When I send a test notification, it does not display any errors but it does not send the notification either.
What can it be ?

I finally looked at the log and saw this when I press the button to test notification and nodeBB restarts

10 11:10 [11656] - error: TypeError: undefined is not a function
at /home/eng/NodeBB/src/posts.js:176:12
at try_callback (/home/eng/NodeBB/node_modules/redis/index.js:573:9)
at RedisClient.return_reply (/home/eng/NodeBB/node_modules/redis/index.js:661:13)
at ReplyParser. (/home/eng/NodeBB/node_modules/redis/index.js:309:14)
at ReplyParser.EventEmitter.emit (events.js:95:17)
at ReplyParser.send_reply (/home/eng/NodeBB/node_modules/redis/lib/parser/javascript.js:300:10)
at ReplyParser.execute (/home/eng/NodeBB/node_modules/redis/lib/parser/javascript.js:203:22)
at RedisClient.on_data (/home/eng/NodeBB/node_modules/redis/index.js:534:27)
at Socket. (/home/eng/NodeBB/node_modules/redis/index.js:91:14)
at Socket.EventEmitter.emit (events.js:95:17)
[cluster] Child Process (11656) has exited (code: 1, signal: null)
[cluster] Spinning up another process

@julianlam My notifications are also failing silently. I'm not getting any errors in the console, client side or server side (it looks like his error is completely unrelated). It just says "Test Notification sent" and nothing happens.

when i click test notification button, my nodebb just crashes


"Add new project" in a solution and chose "From Existing Python code" creates a new solution

I have an existing project and I want to add new project inside:

I pick "From existing Python code" and fill the correct location and name:

I hit OK and got a wizard. This is strange, since I already filled the folder, but let's continue:

I click on "finish" (I tried "next" too but does not change anything).
This closes my current solution and open a new one, this is not what I wanted:

Microsoft Visual Studio Enterprise 2017 Int Preview
Version 15.3.0 Preview 2.0 [26602.0.d15rel]
VisualStudio.15.IntPreview/15.3.0-pre.2.0+26602.0.d15rel
Microsoft .NET Framework
Version 4.7.02046
Installed Version: Enterprise
Python 3.0.17132.1
Provides IntelliSense, projects, templates, debugging, interactive windows, and other support for Python developers.

#13 is the same bug.


refactor(Toolbar): remove unused navigation input property

PR Checklist
Please check if your PR fulfills the following requirements:

[x] The commit message follows our guidelines: https://github.com/valentingavran/anglify/blob/master/CONTRIBUTING.md#commit
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[x] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Codecov Report

Merging #160 (3f089b6) into develop (6e17f21) will decrease coverage by 0.04%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           develop     #160      +/-   ##
===========================================
- Coverage    57.17%   57.12%   -0.05%
===========================================
  Files           49       49
  Lines          913      912       -1
  Branches       101      101
===========================================
- Hits           522      521       -1
  Misses         376      376
  Partials        15       15

Impacted Files
Coverage Δ

...lify/src/modules/toolbar/toolbar-settings.token.ts
100.00% <ø> (ø)

...s/anglify/src/modules/toolbar/toolbar.component.ts
100.00% <ø> (ø)

Continue to review full report at Codecov.

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

@Satellite37 please fix linter errors


Migrate from $.Deferred to Promises

Changes:

Remove jQuery from external modules
Switch getPixelData to just return the canvas imageData.data. The previous loop to set alpha channel to 255 is unnecessary since we can now just set image.rgba = false.
Set image.rgba to false by default. Users can change this to have the image rendered with the alpha channel intact.
Switch event triggering to use cornerstone.triggerEvent with only the lower case event name: 'cornerstoneimageloadprogress'

Coverage decreased (-1.6%) to 4.054% when pulling f622a4559ef68865134c1d26b1880248a6795604 on noDeferred into 935e6b92279dbe398bb9df7dbd33e95453c6d062 on master.


Check objects before removing them from containers

This is intended to prevent situations where, given an object with a matching container field and domain/range/workgroup field, if the domain/range/workgroup is removed from the container, a validation error will be raised so that an invalid object will not be left behind.
Resolves https://github.com/OSU-Net/cyder/issues/987

Seems okay to me.  Looks like you just edited a test though.. should I hold on merging?

No, it was just an assertion statement I forgot to delete. Didn't actually change anything.


source lmod profile checking if BASH_ENV is setup

Signed-off-by: Shahzeb Siddiqui<EMAIL_ADDRESS>

@shahzebsiddiqui I don't see where you are having issues on Travis?


Badge request: dotnet version

:clipboard: Description
I'd like to see a badge displaying the dotnet version the repository or nuget package is using.

:link: Data
The GitHub API does not give out this information, but nuget.org does, which means at least the second of the two example badges above should be possible.
In the API there is a dependency group for each target framework (which is what we are looking for; e.g. net5.0). If i understood the documentation from Microsoft correctly you'll probably end up here.
:microphone: Motivation
When developing dotnet libraries we can choose several versions to compile against. It would be nice to show off in our repositories, that we support the newest dotnet framework version (currently net5.0; soon to be net6.0).

Second one sounds feasible and reasonable to me, although might need to figure out how to display the multiple/all frameworks scenarios

Second one sounds feasible and reasonable to me

Yeah. First one was an idea I had, but disregarded because of the lack of API. I just wanted to mention it in case someone finds anything on that.

need to figure out how to display the multiple/all frameworks scenarios

I personally would just display the latest one if there is multiple, but give the user a dropdown menu to choose from (if possible). That way they can add them all if they want.

Hi, I would like to work on this issue! Can someone guide me how to get started🙂

I personally would just display the latest one if there is multiple, but give the user a dropdown menu to choose from (if possible). That way they can add them all if they want.

I don't follow, could you elaborate? Shields fetches data from some system of record (be it GitHub, nuget.org, Codecov, etc.) and then uses that data to determine the textual values to plug into the svg badges we return. Shields doesn't have any domain knowledge baked in (e.g Shields doesn't know/track the latest framework version at a point in time) nor do we natively support any kind if-then logic that users can control around our native badges.
If a dep group is applicable for all frameworks then Shields would see some kind of falsy value for targetFramework in the API response, and would need to have predetermined logic for specifying the badge message in that case.
The question for implementation would be what the value should be, all or something else. Any users that wanted to do custom messaging in that scenario, e.g. if targetFramework null then foo for message would be better suited to leveraging our Custom Endpoint badge, and anyone that just wanted a static enumeration of the frameworks should leverage our static badge, e.g.
https://img.shields.io/badge/dotnet version-net5.0,net6.0-blue

Hi, I would like to work on this issue! Can someone guide me how to get startedslightly_smiling_face

Thanks for volunteering! Assuming this is a standard nuget api not specific to nuget.org, would suggest starting in
https://github.com/badges/shields/blob/master/services/nuget/nuget-v3-service-family.js
so that'll cascade to all the nuget provider badges

Shields doesn't have any domain knowledge baked in (e.g Shields doesn't know/track the latest framework version at a point in time) nor do we natively support any kind if-then logic that users can control around our native badges.

I didn't know that. My bad.

I didn't know that. My bad.

No worries! The only other alternatives would be

let users controls this via something like a query param on the badge routes (e.g. ?all_frameworks=foo,bar)
fetch the current framework list from some other api endpoint

The first one wouldn't be good, both because it immediately introduces variability and inconsistency and also becomes something every individual user would have to update in all their respective badge urls.
The second one could be an option, but poses some additional challenges and considerations around implementation. It probably wouldn't make sense for Shields to try to fetch that data on every request like it would for the other data points from nuget, both because we typically need to avoid making sequential API calls to ensure the whole badge request/response flow completes quickly enough to actually be rendered on GitHub (a total ceiling of ~3-4 seconds), and because new versions aren't released that frequently.
The versions could be fetched up front, cached, and then used but there would be some things to be solved for there as well.
I don't know what the best answer/approach is for this scenario, but it is something that will need to be resolved before we could deploy the new badge

I think in general our platform support badges follow one of two patters.
Either the API returns a list of supported platforms/versions and we show a pipe-seperated list e.g:

 - https://img.shields.io/pypi/pyversions/wagtail
 - https://img.shields.io/powershellgallery/p/DNS.<IP_ADDRESS>

or the API returns a range/semver expression and we just display it. e.g:

 - https://img.shields.io/packagist/php-v/symfony/symfony
 - https://img.shields.io/node/v/request

Seems like this should fit into one of these boxes?

Seems like this should fit into one of these boxes?

That's not how I understand it. It's more that the value will either be explicitly bound to one specific framework version, or it'll be null/empty/undefined which implies "all" framework versions. However, the exact set of versions that are covered in "all" is where it's fuzzy. It would be more analogous to receiving a blank value in the api response from the npm registry for node, and that (as of today) signifying 12 | 14 | 16 | 17 | 18, but something different a few months down the road (e.g. when v12 and 17 go EOL).
I'm not sure what the exact set of values would map to in the nuget/.net space, but presumably also has a rolling aspect to it since I'd imagine something like .net framework 1.1 or 2.0 aren't implied with a blank value, but not sure which if any versions of framework/core/"new" .net would be included and how those values would change over time

I'm not sure what the exact set of values would map to in the nuget/.net space

Target frameworks are described over here. I'd assume (since I haven't tested the API), it returns any of the TFM values (since that is what you also configure in your projects .csproj file).

I'm not sure what the exact set of values would map to in the nuget/.net space

Target frameworks are described over here. I'd assume (since I haven't tested the API), it returns any of the TFM values (since that is what you also configure in your projects .csproj file).

Thanks, the full list is helpful. To be clear, the use case I am referring to is this:

If no targetFramework is specified, the dependency group applies to all target frameworks

Which unless I'm completely understanding means that an API response of "targetFramework": "" equals every single one of the frameworks listed here. That's an absolutely massive list that couldn't feasibly be enumerated as part of a badge message. Subset shown in below image:

That still leaves us with having to figure out how to transform that blank value into a reasonable badge message text e.g.

or something else

that couldn't feasibly be enumerated as part of a badge message

Challenge accepted!

:laughing: :trollface:

In my experience no one is crazy enough to explicitly put in every single on of them. The most I've ever seen was like 4 or 5 of them at the same time. If someone is crazy enough to specify all of them, I'd say they fully deserve that huge badge and they should be proud of themselves.
I like how you think @chris48s 😆

I think the question is really what value makes the most sense to show in the case where targetFramework is empty

I think the question is really what value makes the most sense to show in the case where targetFramework is empty

Precisely

how about this?

If you neither specify a target framework in your .csproj file, nor specify one during compilation (-f parameter for the dotnet cli) your project can't even be built. If someone manages that AND nuget servers accept a package without a target framework, we should be able to safely assume a major problem and just display an error.

@Abrynos - I was puzzled by your suggestion, but now realize I'm even more puzzled by the API documentation provided in the original description.
I've been operating under the assumption that the API you shared (https://docs.microsoft.com/en-us/nuget/api/registration-base-url-resource#package-dependency-group) is documenting the response and that would mean that when our Servers call that API in response to a bade request we'll see responses like this sometimes:
{
  "targetFramework": "net5.0,net6.0",
  "dependencyGroup": [...],
}

but in other cases we'll get a response like this which map to that "no targetFramework specified"
{
  "targetFramework": "",
  "dependencyGroup": [...],
}

Is that not the case? Is there a different API? If that's correct, then I'm back to being puzzled why we'd want to map that latter response to an error text given the context of the API documentation

ah wait. I misread that. Since the doc says

If no targetFramework is specified, the dependency group applies to all target frameworks.

I personally would probably go with this  or this  instead.


Expose docker connection pool size as agent argument

This PR makes it possible to set the Docker client connection pool size in a Helios Agent command line argument. The default value has been left unchanged.
We need this as we're running enough containers on each host to exhaust the default number (100).

Codecov Report

Merging #1088 into master will decrease coverage by 4.38%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #1088      +/-   ##
============================================
- Coverage     51.71%   47.32%   -4.39%
+ Complexity     1562      579     -983
============================================
  Files           270      107     -163
  Lines         12918     5111    -7807
  Branches       1480      769     -711
============================================
- Hits           6681     2419    -4262
+ Misses         5736     2473    -3263
+ Partials        501      219     -282

Continue to review full report at Codecov.

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

@mattnworb: Valid comments. I have pushed the requested changes.


"Better schemes - Coverage in Xcode" breaks my tests.

For some reason that commit results in a build that fails to find/run any of my tests. Commit right before works fine.
Did this cause anything to change as to how the tests need to be set up for them to be found?

I found the issue. It seems like the move away from Frameworks and toward Copy Files for gmock.framework and gtest.framework was causing this.
I had to remove the frameworks for this two in the list of linked libraries from my project's build phases.


Don't allocate in forward transforms.

@dwbuiten  this is the biggest memory usage improvement I've gotten so far

Coverage increased (+0.001%) to 83.27% when pulling 5d3e5ab6584d881bdaaccd1c35ea8803600b844e on tdaede:no_alloc_ftx into 63f13f7742703fd7589a4c438d5ad9a189926ff8 on xiph:master.

On my testcases it goes down from 47.6 M allocation to 14.2 M allocations, the cumulative memory allocation goes down from 11.2 GB to 6.2 GB.


add plot of confusion matrix

Summary

Plot confusion matrix after training.
Save confusion matrix

Implement Details

Convert computed confusion matrix to pandas.DataFrame and plot it
Save confusion matrix as .csv in zoutput/aggrsts
Use plot function from rich package to get better formatting in the terminal.

Example
Using the following code:
python -W ignore main_out.py --te_d=caltech --task=mini_vlcs --aname=diva --npath=examples/nets/resnet.py --npath_dom=examples/nets/resnet.py --gamma_y=7e5 --gamma_d=1e5 --epos=2

@smilesun As you can see from the above image, for each run, there will be one confusion matrix at the end.
In which way do you suggest saving the confusion matrix? Because for the other results (precision, recall, ... ), every time an extra line will be appended to the .csv file. But for confusion matrix, if is is saved in a .csv file, it is hard to to so.

@xinyuejohn , this is a feature proposed by @aliechoes , maybe he has some ideas on how the feature should be?

Thanks for asking. I would like to propose that we save the confusion matrix as a plot using sklearn.metrics.ConfusionMatrixDisplay

@smilesun Also, do you think it is necessary to add the additional dependency of rich package and its output effect?
If you like it and want to add it, could you please fix the CI test? Because it doesn't use the current .toml file to create the test environment.
@xinyuejohn
I hope my two commits will resolve this dependences, also I think what @aliechoes suggested is really good, it will be cool to save a pdf or svg to the zoutput folder after a run.

Codecov Report

Merging #89 (ead29e5) into master (007fa55) will decrease coverage by 0.08%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #89      +/-   ##
==========================================
- Coverage   93.94%   93.87%   -0.08%
==========================================
  Files         101      101
  Lines        3122     3135      +13
==========================================
+ Hits         2933     2943      +10
- Misses        189      192       +3

Flag
Coverage Δ

unittests
93.87% <100.00%> (-0.08%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

domainlab/compos/exp/exp_utils.py
98.90% <ø> (-0.02%)
:arrow_down:

domainlab/dsets/dset_subfolder.py
96.87% <100.00%> (+0.04%)
:arrow_up:

domainlab/models/a_model_classif.py
94.66% <100.00%> (+0.72%)
:arrow_up:

domainlab/utils/perf_metrics.py
98.11% <100.00%> (+0.15%)
:arrow_up:

domainlab/algos/msels/c_msel.py
85.00% <0.00%> (-15.00%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

i added some fixeme


Don't set draft to null in releaseAndInitialize

Draft's don't have a setter in WebSocketClient, so setting them to null in this method makes this method pretty much pointless.
I'm not sure if it's necessary to call this before connect after an error (say, in case the server restarts) but it seems like if the function is there and public it should not leave the client in a state where it's unusable.

releaseAndReinitialize

Reinitializes and prepares the class to be used for reconnect.

since 8d3909fae896444f565f486c0a68e174201f1124
but in 507e5ec9b3d8e0095576867c5e48ad920ad2df21 the type of draft changed...
To be able to reconnect properly the draft needs to be reset or recreated.
Currently there is no reset method in the class Draft.
A new setter would made the class more difficult to use but we could create a second close method which takes the same arguments like the constructor. That would ensure the object to never be in an invalid state.
And if we need releaseAndReinitialize any further it have to be protected or private.
Currently the usetage of releaseAndReinitialize is risky because it does not take care of anything. What e.g.  if the socket is still connected?

Creating a new WebSocket Client/Server instance it the way to go IMO, but I'm not totally sold on that.

I also can't think of a real benefit of creating a reusable socket.

I haven't seen a problem re-using the draft object across re-initializes, but I haven't done extensive testing.
I've just changed my code to re-create the websocket object rather than re-use the same object.  In that case, we should mark this method as deprecated/internal.


web.Release.config not merging into web.config on publish

Hey,
Trying to insert a rewrite rule into my web.config when the site is published in Release. So far no luck. Does RC2 support this in the publish process?
Thanks!
Files attached in next comment

web.configs.zip

web.config transforms like web.release.config is not supported.

@chassq You could provide that logic in a homebrew tool that would make modifications to the web.config in published output as a postpublish operation. For example, I do this to enable logging and change the log filepath. https://github.com/GuardRex/GuardRex.AspNetCore.Server.IISIntegration.Tools
It's based on cloning the bits in @moozzyk publish-iis tooling: https://github.com/aspnet/IISIntegration/tree/dev/src/Microsoft.AspNetCore.Server.IISIntegration.Tools

Much thanks! Will check it out.


[Azure Search] Implement SearchIndexClient factory to allow automatic secret rotation

Query (read-only) key was rotated at T-48H
Old query key was invalided at T-0H
Service started failing all requests.

This is due to how the Azure Search team recommends using it's SDK in a web app. In short, they recommend a long-lived singleton. This singleton, at activation time, holds the API key to access Azure Search. This means there is no way to change the API key in this instance after it is initialized.
See: https://stackoverflow.com/a/59690929

Implementing your own factory/pool for SearchIndexClient instances is the way to go. Unfortunately this kind of functionality isn't included in the SDK, so you'll have to roll your own.

For now, we just have to redeploy the app after rotating the secret in KeyVault.

This is no longer applicable. We have moved to managed identities.


librc-misc.c, rc.c, rc-status.c: fix memory leaks

Found by building with -Db_sanitize=address

superseded by #721


raft: make TestNodeTick reliable

TestNodeTick relies on a unreliable func waitForSchedule when running
with GOMAXPROCS > 1. This commit changes the test to make sure we stop
the node after it drains the tick chan. The test should be reliable now.
Fix #7374
/cc @fanminshi @heyitsanthony

lgtm


feat(cicd):[TRI-605] Add dash tool execution and result upload to CI workflows

https://jira.catena-x.net/browse/TRI-605

I moved the dash check to a dedicated action. This way we can still see, that there are license issues but the CI feature branch action won't get blocked.


Add support for pr review/review comment events

Add support for pr review/review comment events building on #352
There was one non-passive change with GHPullRequestReviewState the enum value did not match the value returned from the github API. I verified this on github.com and an enterprise instance.

@kohsuke Could I get a review on this?


Domo Blueprints: Upload, Download, Update

Added 3 new blueprints:

Upload a CSV to a Domo Dataset
Download a Domo Dataset as a CSV
Upate a Domo Dataset (that was created through the API)

Ready to go, added in folder name capability


feat: generalize response data injection

I have a leptos styled components library, which is using leptos_meta for SSR for a long time.
However, I had some problems with this flow, that are probably solvable by extension of leptos_meta public API, but I decided to generalize leptos_meta server integration instead, now any other library may hook into response data generation.
This PR only implements axum integration, because I'm not sure if there is a better way to implement this feature.

Can you say more about the problem you're trying to solve, here? There are some very significant drawbacks to making a breaking change to every application simply to add more verbosity for 99% of users, so I am wondering if there is another way to solve this than adding the generics you've added.

Basically, I want to inject a single

false sense that leptos_meta is not something tightly coupled with core, and something users can implement themselves.

The problem here is not that leptos_meta is tightly coupled to the core, and that users can't implement itself; the problem is that leptos_axum is designed as a convenient wrapper around the combination of leptos_router, leptos_meta, and leptos. It's just existed as a convenience for so long that it seems like a necessity; but it's really not.

It is also possible to push this breaking change with 0.7.0 major release

It's definitely possible. When I call it a "breaking change" I don't mean "it's a breaking change according to semver" I mean "it breaks users' applications" — see the fact that every example fails CI without modification. I do not plan to make this change, whether it is allowed by semver or not.

there is no way with the current ServerMetaContext api to be able to merge multiple added style tags into one.

Fair enough! Is there a way we can adjust the leptos_meta API to support it what you need? It might be useful to compare to the discussion in #2856, too, which I think had similar interests.
What additional functionality do you need to support what you're trying to do? Are there one or two functions that could be added to enable it?

It's just existed as a convenience for so long that it seems like a necessity; but it's really not.

The problem is, it is not easy to implement SSR without those helpers, => it is not easy to implement functionality like leptos_meta by yourself.

see the fact that every example fails CI without modification

I agree that the current approach is bad, but it might be improved.

Extension parameter may have a default type (Error-prone, as if user wants to specify it - it needs to be specified everywhere)
Extension might be made a value, instead of being purely type-based. This still require modifications to user code (It might be moved to LeptosOptions, made an optional provider function like additional_context, or redone in other, more convinient way), but also will allow users to provide some values from outside (generalized ResponseOptions?)
Server functions might be wrapped into a some struct. This way you can even get rid of many  generics everywhere (I.e server view definition can be done in a single place), but it requires users to update their codebases too.

What additional functionality do you need to support what you're trying to do? Are there one or two functions that could be added to enable it?

It might be solved by adding a couple of functions in public api, but there is no way to make this api look good, and be usable for everyone. My implementation only needs to

Create a style tag from inside of a hook. This is already possible by exposing register() function, sharing information about this style tag might be done by using user-provided context. Style tag needs not to be shared, as e.g my css modules implementation takes control of this tag during hydration
Append contents to this style tag. Current implementation needs to be extended to not only be able to send new tags to ServerMetaContextOutput, but also to be able to update (append-only?) already sent tags.
Have some way to provide information from use-hooks to hydration stage. An additional modifiable

@CertainLach I found a way to solve this problem without modifying leptos. Refer to the SSRMountStyleProvider component in https://github.com/thaw-ui/thaw/pull/335/commits/266dd6dd4a75484501cd8936429669221c1d4ee1.


Creates a Jenkinsfile for the new Jenkins

Added a Jenkinsfile for new Jenkins
This commit creates a Jenkinsfile which can be used for dev branches on
the new Jenkins which has dockerized ephemeral slaves.
Things to note:

A test had to be ignored to allow the test stage to proceed. This has
been captured in REG-1985
The Gatling tests are limited to Open profile only ('destructive' /
ever increasing load)
At the moment, both ScapeGoat and ScalaStyle analysis are being done
Corbertura is being used to generate test code coverage reports

Thanks @RichardSmithONS


Top-bar dropdown parent link duplicated on medium breakpoint

Confirmed in Chrome and Firefox http://codepen.io/rafibomb/pen/KwGYge
When in the medium breakpoint, the parent link of the dropdown is duplicated in the dropdown.
http://foundation.zurb.com/forum/posts/23372

Hi All, I am newly learning to make sites using Foundation and faced the same problem....
In Version 5.5.1 full download,
I changed line number: 4759 in file > foundation.min.js located in the js folder
changed:
mobile_show_parent_link : true,
to:
mobile_show_parent_link : false,
and the problem was gone... no more duplicate link showed anywhere (including mobile)
Thanks,
Prasadh

Hi
In v5.5.1 foundation.topbar.js Line 375, change the following from
class="parent-link hide-for-large-up"
to
class="parent-link hide-for-medium-up"       or class="parent-link show-for-small-only"
This cleared my problem
Derek

@prbfun I changed the line you point out in foundation.topbar.js on line 14. Works fine!

Fixed, thanks!


Automated cherry pick of #4683: hostman: distro name OpenWrt instead of OpenWRT

Cherry pick of #4683 on release/2.10.0.
#4683: hostman: distro name OpenWrt instead of OpenWRT

Codecov Report

:exclamation: No coverage uploaded for pull request base (release/2.10.0@2dbfd2b). Click here to learn what that means.
The diff coverage is 0%.

@@               Coverage Diff                @@
##             release/2.10.0   #4694   +/-   ##
================================================
  Coverage                  ?   7.46%
================================================
  Files                     ?     418
  Lines                     ?   66788
  Branches                  ?       0
================================================
  Hits                      ?    4984
  Misses                    ?   61378
  Partials                  ?     426

Flag
Coverage Δ

#aFlag
7.46% <0%> (?)

Impacted Files
Coverage Δ

pkg/hostman/guestfs/fsdriver/linux.go
0% <0%> (ø)

pkg/hostman/guestfs/fsdriver/base.go
13.08% <0%> (ø)

Continue to review full report at Codecov.

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

/lgtm

/approve


How do OpenSwiftUI and SwiftUIEmbedded work?

Hi,
How do OpenSwiftUI and SwiftUIEmbedded work and how they are structured?
It seems that you are creating a renderer:
https://github.com/Cosmo/Pixels
I'm creating this renderer:
https://github.com/swiftfn/SkiaSwift
Demo:
https://github.com/swiftfn/SkiaSwift/blob/master/Sources/Demo/main.swift
It's about 50% finished, I'm aiming to finish it soon.
I think it's very useful for your OpenSwiftUI project,
so that you can focus on porting SwiftUI,
instead of having to create your own renderer.

Hey @ngocdaothanh, thanks for reaching out!
OpenSwiftUI provides the infrastructure and SwiftUI DSL without any platform-specific code.
That means the actual rendering of a UI + Interaction and platform-specific elements is supposed to come from another project (like SwiftUIEmbedded for example).
This kind of separation will pave out the way for many different implementations of (Open)SwiftUI on various platforms without dictating how things should look and feel like.
I created SwiftUIEmbedded to show an extreme example of running SwiftUI outside of iOS, tvOS, watchOS or macOS on simple hardware.
This project depends on OpenSwiftUI and extends it with the actual rendering.
For 2D graphics I had these technologies / libraries in mind:

SVG
Desktop PostScript
Cairo (https://www.cairographics.org)
Cairo for Swift (https://github.com/PureSwift/Cairo)
Opal (https://github.com/gnustep/libs-opal)
Doggie (https://github.com/SusanDoggie/Doggie)
Skia (https://skia.org)
LittlevGL (https://littlevgl.com)
…

I was quite overwhelmed with the many possibilities and also didn't want to bother to think about compiling C or other languages, writing bridges, testing etc.
So I created Pixels to keep things simple for now without having any external dependencies.
What I know, is that Pixels was great to have at least something, but keeping it as part of the project makes no sense for the future.
In the following days I'll work on some code clean up tasks, updating the README and make the project more friendly towards potential contributors.
Any suggestions or pull requests are welcome of course!

Also pointing out to a cross-platform rendering API bgfx, it supports all popular backend including(metal, vulkan, directx12)
and another cross-platform swift UI framework already plan to moving its rendering backend to it

@ngocdaothanh are you still working on SkiaSwift?

I'm pausing SkiaSwift to work on a tool to automatically create Swift binding for Skia (SkiaSwift is manual work, so every time Skia changes, SkiaSwift needs to be manually updated):
https://github.com/swiftfn/Cpp4Susans

Oh, that's really cool!


REFPLTB-3054:Erouter0 is not getting IPv6 address.

Reason for change: To fix IPv6 address allocation issue for RPI platform.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.P Heam Kumar seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


process is only defined when referenced in _app getInitialProps

Bug report
Describe the bug
I'm setting env variables in next.config.js and destructing within _app.js to create an aws-amplify Auth (Cognito) instance. I found some strange behaviour, ultimately process is not defined in _app.js at all unless its referenced in getInitialProps. I understand that console.log is a blocking operation.
If this isn't actually a bug, any suggestions where to define the amplify configure so I can use it throughout the app? It's a serverless build so I'm not able to use the publicRuntimeConfig options
To Reproduce
I've put a repo together: https://github.com/omonk/nextjs-process

clone, npm i / yarn etc.
npm/yarn run start then open page and dev tools, you'll see process is not defined error with stack trace.
go to _app.js and uncomment line 15 console.log({ process });
refresh local running instance and error has disappeared.

Expected behavior
process to be defined without referencing it in getInitialProps.
System information

OS: macOS
Browser chrome
Version of Next.js: 8.0.4

The process is not defined error can also be resolved if just referencing process; within getInitialProps so it's not a matter of console.log blocking I don't think.

The problem is actually that you're trying to destructure values whereas environment variables are inline-replaced in the bundles using webpack DefinePlugin. Meaning you write the in full and they're replaced at build time. Eg process.env.ABC will become the literal value 'def' if you add env: {ABC: 'def'}.
So basically this won't work:
https://github.com/omonk/nextjs-process/blob/master/pages/_app.js#L4-L9

Riiiight ok that makes sense, thank you for your prompt response. I've made that update and it is indeed all working.
I'd like to make a PR into the docs to clarify this to anyone else who has the same issue

Although @timneutkens can you explain why referencing process in getInitialProps seems to work?

Depends on how it's called, on Node.js side of things (SSR) we call getInitialProps, meaning process is there from Node.js. Ideally we would just block people from using process but it might break a bunch of user's code so we haven't (yet). It would be undefined / polyfilled by webpack on the client routing.
I'd be happy to take in a PR explaining it :100:

@timneutkens https://github.com/zeit/next.js/pull/6889


Nested exceptions aren't reported out fully by default

Is there an existing issue for this?

[X] I have searched the existing issues

Describe the bug
When Hot Chocolate reports an exception that happens to nest another one, it only ever ends up returning the outermost one in the error response it generates by default.
Steps to reproduce

Throw an exception that has another one nested within it.

Product
Hot Chocolate
Version

Hm..
in what context?

Error Filter
Diagnostic Listener
Mutation Convention
GraphQL Errors for uncaught exceptions

GraphQL Errors for uncaught exceptions in this case.

@michaelstaib - I was thinking specifically for debugging purposes, if an exception has a nested error, if the default HotChocolate exception renderer could just also include the nested exception(s)...


VE-152 Added diable prop to the VehicleSelector component

Contributes VE-152
Changes

Added a prop disabled to the VehicleSelector Component default is set to false
Updated types, story
Added tests

Dependencies

UI/UX

Testing notes

When disabled is true all the autocomplete components should be diabled.

Author checklist
Before I request a review:

[x] I have reviewed my own code-diff.
[ ] I have tested the changes in Docker / a deploy-preview.
[ ] I have assigned the PR to myself or an appropriate delegate.
[x] I have added the relevant labels to the PR.
[x] I have included appropriate tests.
[x] I have checked that the Lint and Test workflows pass on Github.
[ ] I have populated the deploy-preview with relevant test data.
[ ] I have tagged a UI/UX designer for review if this PR includes UI/UX changes.

If we are explicitly setting this to disabled should the fields still be required? This is more of a question than it being incorrect. I'm not sure on the use case but it seems odd having the red required stars if they cannot be interacted with.

After Discussing with @Sowbhagya-ipg  changed * color to grey on disbaled fields


Update sbt-sonatype to 3.9.9

Updates org.xerial.sbt:sbt-sonatype from 3.9.7 to 3.9.9.
GitHub Release Notes - Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.xerial.sbt", artifactId = "sbt-sonatype" } ]

labels: sbt-plugin-update, semver-patch

Superseded by #32.


add webhook e2e test cases

/retest

/assign @pmorie

/assign @deads2k

/approve

This looks like a good start. Did I just miss the positive test (user with permission updates the hubAccepted)?  if not, can you make it a follow-on?
/lgtm

/retest

/retest

This looks like a good start. Did I just miss the positive test (user with permission updates the hubAccepted)? if not, can you make it a follow-on?

I think the loopback registration test already includes the positive test, we enabled the webhook with that test, in that test, the user who has the permission updates the hubAccepted to true

/retest

/retest

/lgtm


[DISCUSS] Any ideas about unified memory management for different native engines?

Hi OAP team, your job is wonderful and do you have some plans or designs about unified memory management for different native engines (e.g. velox)?

Do you mean to use Spark's memory management system? Then we need to define a set of APIs for native library where they can be implemented based on native implementation. when the library allocate memory it needs to notify spark's memory management system. This is really important part for spark. In Gazelle engine we spent quite much effort to implement this. We can port them to Gazelle-jni.
Thank you for your reminder, Let's add to readme.

Do you mean to use Spark's memory management system? Then we need to define a set of APIs for native library where they can be implemented based on native implementation. when the library allocate memory it needs to notify spark's memory management system. This is really important part for spark. In Gazelle engine we spent quite much effort to implement this. We can port them to Gazelle-jni.
Thank you for your reminder, Let's add to readme.

Hi @FelixYBW yep I think it's a critical part for this project. One more thing I have wondered is does this memory management is same in different engines. As you say, if users choose Gazelle engine, memory management will work well because you have defined-well API and spent much effort for it. But if users choose velox or another engine, since it may implement unified memory management by other ways instead of theses APIs your defined, does users have to do many works to unify memory management in this Spark-gazelleJni-mayAnotherEngine system?
In other words, my question is how to unify memory management API in different native engine?

It may depends on the native library. In theory we can implement a memory pool then every native engine use this pool to allocate large memory block. The pool register memory to Spark's memory management service. Currently Gazelle's one is enhanced from Arrow's. Let's see if it's possible to pull it out for general use.

Now we use [OPPRO-174] https://github.com/oap-project/gluten/pull/264 to unify the memory management

We already implemented the memory allocation interface. Every memory allocation needs to check if Spark has enough memory for this task thread. Now both Arrow and Velox memory are allocated using the interface. Clickhouse backend is still WIP.


explanation of @rend="siglum" and @rend="journal"

@ajaniak: Manu has closed #82, which was indeed getting excessively long and ciomplicated.
But it seems to me that we had not yet had the chance to discuss the attributes @rend="siglum" and @rend="journal" which were mentioned yesterday for the first time and don't yet figure in EGD.

Regarding @rend="siglum", can you explain where this will need to be used, for what purpose? I am not sure we ever need  the siglum, as defined in EGD 9.4.4, to appear other than in
 and at the end of a <bibl> entry that contains @n inside <listBibl>, but in those contexts we don't need @rend to make the siglum appear. Are you perhaps talking about a different kind of siglum?

Regarding @rend="journal", I am also not sure that I have understood the need to introduce this attribute. I believe the default bibliographic mode in display of our .xml files should be for journal titles to appear in abbreviated form. If that is the case (to be confirmed by others!), then perhaps we don't need such an attribute, or could work with an attribute only in the exceptional cases that the full journal title is desired?

I have suggestions about this and will psot them when time permits, hopefully this week ;-)

Shouldn't this discussion take place in #81 ? At any rate, my doubts concerning the topic (which I think may have prompted Arlo to open this thread) can be found at https://github.com/erc-dharma/project-documentation/issues/81#issuecomment-704338641.
Regarding Arlo's point 2 above, I would prefer to see full journal titles in the structured bibliography (primary and secondary), and journal abbreviations everywhere else. But if your preference is abbreviations in the structured bibliography too, then I have no objection to that.

I have given my view on full/abbreviated journal titles on #81. For the rest, I patiently await Manu's suggestions.

@rend="journal" issue is solved. Feedback on Axelle's implementation (see #81) is requested.
On @rend="siglum" see comment in EGD googledoc at 9.4.3.

@rend="journal" issue is solved. Feedback on Axelle's implementation (see #81) is requested.
On @rend="siglum" see comment in EGD googledoc at 9.4.3.

To answer Arlo's original question about where rend="siglum" might be used and to what purpose: Manu and I think it may be useful to use sigla to refer to previous editors of the text in some places outside the apparatus lemmas and readings, namely the commentary, notes in the apparatus, and notes in the translation. We might also want to permit this in the hand description (or in any part of the TEI header where free text is permitted).
In such cases, my practice so far (not very nice), has been simply to use the siglum as hard text, e.g. "PVPS connects the name Voṭṭi to Sāmanta Viṣṭi" and "VR's emendation", where PVPS is the siglum for an edition by P. V. Parabrahma Sastry and VR is another edition by V. Rangacharya.
The proposal that Manu endorses, if we understand each other right, is that instead of this barefoot method, we should from now on use <bibl rend="siglum"><ptr target="bib:Rangacharya1955-1956_01"/></bibl> instead of just VR. The precondition of this would, of course, be that the item referred to is present in the primary bibliography, and a siglum is assigned to it there (i.e. <bibl n="VR"><ptr target="bib:Rangacharya1955-1956_01"/></bibl>).
The above encoding would then be simply displayed as the siglum, with a tooltip showing the bibliographic details.
The advantage is easier legibility, when you repeatedly refer to the same edition and do not need a page number or any other details.
I would thus add that a citation with rend="siglum" must never contain any further details except the <ptr>; if details such as a page number are needed, then we should continue encoding a generic reference.
@arlogriffiths : do you like this?
@ajaniak : is this feasible to display and do you think it's acceptable encoding practice?
@manufrancis : is this in line with your thinking?
If the answer to all the above is yes, then we'll need Axelle to implement the code, and I'll add the appropriate instructions to EGD §10.4.5 (not §9.4.3). All of us who have been using some method to refer to editions by sigla will then have to change our provisional sigla to the above encoding.

To answer Arlo's original question about where rend="siglum" might be used and to what purpose: Manu and I think it may be useful to use sigla to refer to previous editors of the text in some places outside the apparatus lemmas and readings, namely the commentary, notes in the apparatus, and notes in the translation. We might also want to permit this in the hand description (or in any part of the TEI header where free text is permitted).
In such cases, my practice so far (not very nice), has been simply to use the siglum as hard text, e.g. "PVPS connects the name Voṭṭi to Sāmanta Viṣṭi" and "VR's emendation", where PVPS is the siglum for an edition by P. V. Parabrahma Sastry and VR is another edition by V. Rangacharya.
The proposal that Manu endorses, if we understand each other right, is that instead of this barefoot method, we should from now on use <bibl rend="siglum"><ptr target="bib:Rangacharya1955-1956_01"/></bibl> instead of just VR. The precondition of this would, of course, be that the item referred to is present in the primary bibliography, and a siglum is assigned to it there (i.e. <bibl n="VR"><ptr target="bib:Rangacharya1955-1956_01"/></bibl>).
The above encoding would then be simply displayed as the siglum, with a tooltip showing the bibliographic details.
The advantage is easier legibility, when you repeatedly refer to the same edition and do not need a page number or any other details.
I would thus add that a citation with rend="siglum" must never contain any further details except the <ptr>; if details such as a page number are needed, then we should continue encoding a generic reference.
@arlogriffiths : do you like this?
@ajaniak : is this feasible to display and do you think it's acceptable encoding practice?
@manufrancis : is this in line with your thinking?
If the answer to all the above is yes, then we'll need Axelle to implement the code, and I'll add the appropriate instructions to EGD §10.4.5 (not §9.4.3). All of us who have been using some method to refer to editions by sigla will then have to change our provisional sigla to the above encoding.

@danbalogh : yes, fully in line with my thinking.
One question: could not the item be also in the secondary bibliography?
The EGD currentlys says (9.4.3): "this applies regardless of whether the full citation is in your primary bibliography or the secondary one"

@danbalogh : yes, fully in line with my thinking.
One question: could not the item be also in the secondary bibliography?
The EGD currentlys says (9.4.3): "this applies regardless of whether the full citation is in your primary bibliography or the secondary one"

Indeed, Manu, thanks. I've now edited the above. The secondary bibliography can of course also include a siglum declaration.

Indeed, Manu, thanks. I've now edited the above. The secondary bibliography can of course also include a siglum declaration.

I have updated the code initially written for Manu and added the tooltip possibility. However, what do you expect exactly in the tooltip?

the full reference, such as Mahalingam, T. V. 1988. Inscriptions of the Pallavas. New Delhi; Delhi: Indian Council of Historical Research; Agam Prakashan
or the citation pattern, i.e. Mahalingam 1988.

I also need a clarification regarding the siglum spelling. Manu's has used IP_22 with an underscore in another issue but the EGD states that it should be written with a space IP 22. Can you confirm me you are keeping the second solution, so I know if I keep the replace pattern for underscore in the code?

I have updated the code initially written for Manu and added the tooltip possibility. However, what do you expect exactly in the tooltip?

the full reference, such as Mahalingam, T. V. 1988. Inscriptions of the Pallavas. New Delhi; Delhi: Indian Council of Historical Research; Agam Prakashan
or the citation pattern, i.e. Mahalingam 1988.

I also need a clarification regarding the siglum spelling. Manu's has used IP_22 with an underscore in another issue but the EGD states that it should be written with a space IP 22. Can you confirm me you are keeping the second solution, so I know if I keep the replace pattern for underscore in the code?

I expect in the tooltip the citation pattern, i.e. Mahalingam 1988.
As for the siglum spelling, I will change my sigla of the type "IP_22" and revert to "TVM".
I will also change my sigla of the type "ARIE 1904-1905" to just "ARIE". In that case, could the tooltip be "ARIE 1904-1905" (with space) based on the Zotero short title "ARIE1904-1905" (without space)?

I expect in the tooltip the citation pattern, i.e. Mahalingam 1988.
As for the siglum spelling, I will change my sigla of the type "IP_22" and revert to "TVM".
I will also change my sigla of the type "ARIE 1904-1905" to just "ARIE". In that case, could the tooltip be "ARIE 1904-1905" (with space) based on the Zotero short title "ARIE1904-1905" (without space)?

It is implemented. Can you check the result of the new code and let me know it if matches your expectations?

It is implemented. Can you check the result of the new code and let me know it if matches your expectations?

No objections from my side to any of the above.
I just wonder whether a less verbose manner of calling the siglum might be imaginable? In the EGC, we are offering a shortcut for calling manuscript sigla, for which in the case of critical editions xml:id's of course need to be defined in <listWit>. This allows us to use the following type of shortcut when witness "C1" needs to be mentioned in free prose:

It is fascinating that <ref target=”#C1”/> is written in red ink.

Is any such approach possible in the case at hand? I fear the answer is no, if we don't want to take recourse to using xml:id, but I ask nonetheless — also to request a reminder as to why we haven't decided to work with an authority file for sigla, in which case I suppose we could have done something like <ref target=”sigl:VR”/> to get the result aimed for in your example above.

No objections from my side to any of the above.
I just wonder whether a less verbose manner of calling the siglum might be imaginable? In the EGC, we are offering a shortcut for calling manuscript sigla, for which in the case of critical editions xml:id's of course need to be defined in <listWit>. This allows us to use the following type of shortcut when witness "C1" needs to be mentioned in free prose:

It is fascinating that <ref target=”#C1”/> is written in red ink.

Is any such approach possible in the case at hand? I fear the answer is no, if we don't want to take recourse to using xml:id, but I ask nonetheless — also to request a reminder as to why we haven't decided to work with an authority file for sigla, in which case I suppose we could have done something like <ref target=”sigl:VR”/> to get the result aimed for in your example above.

I agree that a less verbose method would be very welcome. @ajaniak : would it not be possible to change our siglum use method so that

instead of @n, we use @xml:id in the structured bibliography to assign a siglum to an entry (e.g. <bibl xml:id="EH">), and
then use that @xml:id to refer to publications that have a siglum (e.g. <ref target=”#EH”/>), and display those references as the siglum with a tooltip?

@arlogriffiths : as far as I can tell, the idea of using an authority file for sigla has never come up before. But I don't think it's a good idea, since the sigla would then have to be unique throughout the project. But with the above approach, sigla (i.e. @xml:id-s) would only need to be unique within each file, and there would be no problem with using the same siglum in different XML files for different publications of the same author.

I agree that a less verbose method would be very welcome. @ajaniak : would it not be possible to change our siglum use method so that

instead of @n, we use @xml:id in the structured bibliography to assign a siglum to an entry (e.g. <bibl xml:id="EH">), and
then use that @xml:id to refer to publications that have a siglum (e.g. <ref target=”#EH”/>), and display those references as the siglum with a tooltip?

@arlogriffiths : as far as I can tell, the idea of using an authority file for sigla has never come up before. But I don't think it's a good idea, since the sigla would then have to be unique throughout the project. But with the above approach, sigla (i.e. @xml:id-s) would only need to be unique within each file, and there would be no problem with using the same siglum in different XML files for different publications of the same author.

Dear all,
I understand the will in favor of a less verbose syntax, but in that case does it mean that encoding patterns for omitname and ibib that siglum was following should be change as well?
First, let's not use <ref> to do so. Indeed, if both <ref>and <ptr/> are used to link. <ref> should contains a textual content that will be hyperlinked, while <ptr/> is a self-closing element working to point or retrieve content from elsewhere. I wouldn't change the logic currently applied in the EGD regarding those 2 elements.
I am reluctant to add @xml:id inside our encoding. Strictly, the Zotero short title is already used as an ID, so adding another layer isn't a good practice and could be confusing for some members and reusers after the project. We could use the attribute @cRef if we considere those sigla as canonical references.
Wouldn't it be easier to just say that any  used on its own, so not used with <bibl> as parent element, would be renderer as a siglum. Such a solution would allow to keep the current logic of the EGD since <ptr target="bib:blabla"/> would be fetching the content of the @n attribute provided in the bibliography. I still wonder if it is clear enough though. In this case why not keep an attribute @rend="siglum" in the <ptr/>, so <ptr target="bib:blabla" @rend="siglum"/>.
So I guess I be in favor of <ptr target="bib:blabla"/> or <ptr target="bib:blabla" @rend="siglum"/>.

Dear all,
I understand the will in favor of a less verbose syntax, but in that case does it mean that encoding patterns for omitname and ibib that siglum was following should be change as well?
First, let's not use <ref> to do so. Indeed, if both <ref>and <ptr/> are used to link. <ref> should contains a textual content that will be hyperlinked, while <ptr/> is a self-closing element working to point or retrieve content from elsewhere. I wouldn't change the logic currently applied in the EGD regarding those 2 elements.
I am reluctant to add @xml:id inside our encoding. Strictly, the Zotero short title is already used as an ID, so adding another layer isn't a good practice and could be confusing for some members and reusers after the project. We could use the attribute @cRef if we considere those sigla as canonical references.
Wouldn't it be easier to just say that any  used on its own, so not used with <bibl> as parent element, would be renderer as a siglum. Such a solution would allow to keep the current logic of the EGD since <ptr target="bib:blabla"/> would be fetching the content of the @n attribute provided in the bibliography. I still wonder if it is clear enough though. In this case why not keep an attribute @rend="siglum" in the <ptr/>, so <ptr target="bib:blabla" @rend="siglum"/>.
So I guess I be in favor of <ptr target="bib:blabla"/> or <ptr target="bib:blabla" @rend="siglum"/>.

I think "omitname" and "ibid" should not be changed in any way, since most of the time these will be used in conjunction with <citedRange>.
Thanks for clarifying <ref> and <ptr/>; I was not conscious enough of this difference. Using <ptr/> would of course be perfectly fine. (And in this case, the same should, I guess, be done in the EGC for manuscript witnesses.)
I think this is a bit beyond me, but if I'm not mistaken, our sigla cannot be called canonical references, since their meaning changes from file to file. A siglum, e.g. JFF, may mean one publication (e.g. Fleet1865_01) in one XML file and a different publication (e.g. Fleet1888_13) in another XML file. But given 4 below, it seems we can safely forget about both @xml:id and @cRef.
It's never occurred to me that we could use a bibliographic pointer without an enclosing <bibl>. But if doing so is not frowned upon in TEI circles, then I'd be perfectly content with the method you suggest, i.e. <ptr target="bib:blabla"/> without @rend="siglum" (for simplicity's sake) if we can informally declare that this encoding is only used for sigla and let it go at that, but with @rend="siglum" if the former is bad practice.

Finally, one more point, concerning the contents of the tooltip. @manufrancis has said above that he wants the tooltip to show just the author-date citation. I'm OK with that if it's a definite preference, but would it not be better for the tooltip to show the full bibliographic details, just as the tooltip shown for a regular (non-siglum) bibliographic reference would?

I think "omitname" and "ibid" should not be changed in any way, since most of the time these will be used in conjunction with <citedRange>.
Thanks for clarifying <ref> and <ptr/>; I was not conscious enough of this difference. Using <ptr/> would of course be perfectly fine. (And in this case, the same should, I guess, be done in the EGC for manuscript witnesses.)
I think this is a bit beyond me, but if I'm not mistaken, our sigla cannot be called canonical references, since their meaning changes from file to file. A siglum, e.g. JFF, may mean one publication (e.g. Fleet1865_01) in one XML file and a different publication (e.g. Fleet1888_13) in another XML file. But given 4 below, it seems we can safely forget about both @xml:id and @cRef.
It's never occurred to me that we could use a bibliographic pointer without an enclosing <bibl>. But if doing so is not frowned upon in TEI circles, then I'd be perfectly content with the method you suggest, i.e. <ptr target="bib:blabla"/> without @rend="siglum" (for simplicity's sake) if we can informally declare that this encoding is only used for sigla and let it go at that, but with @rend="siglum" if the former is bad practice.

Finally, one more point, concerning the contents of the tooltip. @manufrancis has said above that he wants the tooltip to show just the author-date citation. I'm OK with that if it's a definite preference, but would it not be better for the tooltip to show the full bibliographic details, just as the tooltip shown for a regular (non-siglum) bibliographic reference would?

@danbalogh, to answer the 4. using <ptr/> on its own isn't frowned upon. It is not the most used feature of the TEI, but it is used when there is a bibliographic DB and no textual or encoding anchor already provided. If I am not mistaken, it is used by the Digital Latin Library.
If @manufrancis, @arlogriffiths and @AnneSchmiedchen feel confortable enough with <ptr target="bib:blabla"/>. I am also in favor of no @rend attribute.
Regarding the content of the tooltip, both are feasible technically. Not in the strict context of the html output since they don't have a backend codes to switch from one solution to the other, but we could provide the possibility to choose the content of the tooltip for the user. I honestly don't know if such a feature could be an expectation for the display.

@danbalogh, to answer the 4. using <ptr/> on its own isn't frowned upon. It is not the most used feature of the TEI, but it is used when there is a bibliographic DB and no textual or encoding anchor already provided. If I am not mistaken, it is used by the Digital Latin Library.
If @manufrancis, @arlogriffiths and @AnneSchmiedchen feel confortable enough with <ptr target="bib:blabla"/>. I am also in favor of no @rend attribute.
Regarding the content of the tooltip, both are feasible technically. Not in the strict context of the html output since they don't have a backend codes to switch from one solution to the other, but we could provide the possibility to choose the content of the tooltip for the user. I honestly don't know if such a feature could be an expectation for the display.

Thanks, all this sounds good to me. Enhancing the tooltips can be left for later.

Thanks, all this sounds good to me. Enhancing the tooltips can be left for later.

@ajaniak : Arlo, Manu and I have revised the siglum creation rules in the EGD (§9.4.3 at the moment, though I'll probably move these to a subsection of §10 when I write up the use of sigla in commentary and so on). I need your help in one point: should we restrict sigla to alphanumeric characters or is it OK to use some symbols in them? In particular, it would be good if we could use & in sigla of multi-author publications, but since this is a problematic character, I believe we could all agree on using + instead, provided that this is technically manageable. Also, while we are at it, should we avoid non-ASCII characters in sigla, or is it perfectly OK to use special accented characters such as Ś?

@ajaniak : Arlo, Manu and I have revised the siglum creation rules in the EGD (§9.4.3 at the moment, though I'll probably move these to a subsection of §10 when I write up the use of sigla in commentary and so on). I need your help in one point: should we restrict sigla to alphanumeric characters or is it OK to use some symbols in them? In particular, it would be good if we could use & in sigla of multi-author publications, but since this is a problematic character, I believe we could all agree on using + instead, provided that this is technically manageable. Also, while we are at it, should we avoid non-ASCII characters in sigla, or is it perfectly OK to use special accented characters such as Ś?

You don't have to restrict the sigla to alphanumeric characters. For now, I just retrieve the content, but I guess even if we need to add some work on the string itself it will be limited. And I will never use the sigla to retrieve data, or match data since I have the ZST. So I don't see technical reason to limit it.
So regarding non-ASCII characters in sigla, as long as people provide the utf-8 character when typing, it should be ok.
For some symbols will need to provide the html entity code rather than use the utf-8 encoding. Oxygen will identity as mistake those, since the list is the same or nearly the same, for XML and HTML. & is one of them. & should be & but its interpretation even in html will be &. So both + and & are good for me.
However, if some treatements of the string are expected, such as if underscore display a space instead. We will need to lead clear rules, because I will have a limited possibilities to codes rules in this case.
Please be aware also that I haven't implement the full code yet, so it is normal if it is not working yet!

You don't have to restrict the sigla to alphanumeric characters. For now, I just retrieve the content, but I guess even if we need to add some work on the string itself it will be limited. And I will never use the sigla to retrieve data, or match data since I have the ZST. So I don't see technical reason to limit it.
So regarding non-ASCII characters in sigla, as long as people provide the utf-8 character when typing, it should be ok.
For some symbols will need to provide the html entity code rather than use the utf-8 encoding. Oxygen will identity as mistake those, since the list is the same or nearly the same, for XML and HTML. & is one of them. & should be & but its interpretation even in html will be &. So both + and & are good for me.
However, if some treatements of the string are expected, such as if underscore display a space instead. We will need to lead clear rules, because I will have a limited possibilities to codes rules in this case.
Please be aware also that I haven't implement the full code yet, so it is normal if it is not working yet!

I concur with Dan's comments in 4 points above.
I am fine with <ptr target="bib:blabla"/>, without @rend.
As for the content of the tooltip display of "author-date citation" less cumbersome and concur again with Dan that this can be left for later.
@arlogriffiths and @AnneSchmiedchen Can we have your vote?
This will help Axelle finalizing the implementation of the DHARMA schema and also to close the issues related to @rend="siglum" and @rend="journal".

I concur with Dan's comments in 4 points above.
I am fine with <ptr target="bib:blabla"/>, without @rend.
As for the content of the tooltip display of "author-date citation" less cumbersome and concur again with Dan that this can be left for later.
@arlogriffiths and @AnneSchmiedchen Can we have your vote?
This will help Axelle finalizing the implementation of the DHARMA schema and also to close the issues related to @rend="siglum" and @rend="journal".

Thanks, Axelle. I don't think we'll want any manipulation of the sigla. I'll continue the discussion with Manu and Arlo in EGD comments so as not to hijack this thread.

Thanks, Axelle. I don't think we'll want any manipulation of the sigla. I'll continue the discussion with Manu and Arlo in EGD comments so as not to hijack this thread.

@ajaniak I'll ask encoders in the EG not to use & in sigla (because I'm afraid people will forget to use & and raise errors). We'll stick to + for multi-author sigle. But given the input from Manu and Arlo, it would be best if - in the long run - this could be replaced in display with an & character. This is the only transformation we'll want, but it would be nice to have this, so e.g. if the siglum is "S+G", then it is displayed as S&G. Does this sound feasible?

I have added a replace patter to transform + into & inside the new template for ptr.
The code requires bibliographic data, so it will be effective only transforming your file with start-edition-with-bibl.xsl.
I have kept start-edition.xsl running by not adding the specific template, since I know some members are still using this XSLT. But the downside of this is that <ptr> won't have any display, like the rest of the bibliographic data.

Thanks, this is great. I will make the necessary changes to the EGD.
I'm one of the people still using start-edition.xsl, but if we are ready to deprecate it, i.e. if the one with bibl works correctly in all details, then I don't mind changing over to with-bibl. Let me know whenever you want to take it out of circulation.

At some point, we will indeed need to deprecated it, because it limits transformation scenarios. But I would like to add a control of the Zotero ST in the Schematron to overcome the reason we had to have 2 lauching files first. So I hope in the following weeks, we should be ready to do it.


DO NOT MERGE Fix #2108: Defer identifier name mangling to the emitter.

Previously, we banished JavaScript keywords in the IR, in several places:

The name of local variables
The unprefixed name of fields
The name of methods (not including their encoded signature)

This commit allows all JavaScript keywords (and special reserved or meaningful identifiers such as arguments) in all these places. For fields and methods, it was irrelevant anyway, since they are always suffixed with something, and therefore the keyword is never actually a keyword.
For local variables, we defer their mangling until the emitter, in the pessimistic naming run (so we assume in the first run that no local variable uses a reserved word). The optimizer helps by eagerly renaming such variables on its own, to avoid the pessimistic run. It has to do renaming for inlined stuff anyway, so this is not more job for it. The pessimistic run is still necessary in exported methods (which are not optimized) and if the optimizer is disabled.
There is one place where the set of strict keywords must be avoided in the IR, per semantics: in JSGlobalRef. Therefore, JSGlobalRef does maintain a fixed set of illegal global variable names, which cannot be accessed. They trigger compile errors.
There is still one thing which must be eagerly mangled: identifiers starting with a digit (for fields, methods, and local variables). That's because scalac thinks they are valid, but they cannot be used at the start of an IdentifierName in JavaScript. We still do not allow them in the IR, because the IR can reasonably follow one of the two following rules:

Either it follows JavaScript's rules, hence IdentifierName
Or it follows the JVM rules, which allow virtually all Unicode characters (with a few exceptions such as . / < >).

Supporting the latter in the IR would mean much more preemptive mangling in the emitter, which would slow it down for almost no reason, since scalac uses none of those weird characters.
For that reason, the IR sticks to JavaScript IdentifierNames, and it is the scalac back-end's responsibility to encode leading digits away. We choose to prefix a leading digit with the character 〇 (Ideographic Number Zero, U+3007, category LETTER_NUMBER), which is a valid first character for an IdentifierName. This avoids cascading manglings. At the end of the day, that character will be Unicode-escaped as \u3007 by the pretty-printer to keep the character set of the emitted .js as ASCII (this was already implemented). If we had cascading manglings, it would be awkward to specify interoperability between different languages compiling to the IR.

Superseded by #3814 and #3823.


Toy example

How to reproduce the results in the paper and the video?

Hello, you can have a look at the robocar motion planner to see how the MPPI motion planner can be used. The usage in RoboCar is slightly different from the paper though.


added level order traversal of binary tree

Have you read the Contributing Guidelines on Pull Requests?
Yes
Description
->>Added C++ code for level order traversal of binary tree.
->>Constructed binary tree using stack and used queue for printing level order traversal of the binary tree.
->>algorithm works in 3 steps until queue is empty--
1. remove the node
2. save/print the value
3. add the children to the queue
Fixes#4591
Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[x] I've edited the README.md and link to my code.

Related Issues or Pull Requests
Fixed issue num #4591

Ok I will make all the requested changes.
Thank you


No Services

Hi,

I have rebuild the image countless times. It doesn't show services. I am on the latest version raspberry pi 3 as you can see. I don't know how to make this work.

I can't really tell from the screenshot, but I assume this device is part of the balena-sound application.
Do you get any errors when you push the application?
It might be worth doing a "Purge Data" (the pulldown beside the light bulb).

What do you mean by pushing the application?

Generally, you "push" an image to your balena fleet (formerly known as application), either at the CLI or using the one-click deploy.  Do you get any errors or messages when you do that?
How exactly are you building the image?  What steps have you taken so far?

I built the image for raspberry pi 3 and flashed those to sd cards. I did the same thing couple months back and it work flawlessly. Now I did the exact same thing I don't see any services on neither of the pi's.
I can't find "push" anywhere in the balena deploy thing. It's not like github, is it?

So after you build the image and boot from the cards, you have to deploy the application/fleet either using the one-click deploy or the balena CLI:
https://sound.balenalabs.io/docs/getting-started

All balena projects need to be deployed/pushed after you create the device image and fleet, so you may have used "one click deploy" in the past maybe?
Let us know how it works out.

Hey @Rickexe closing this due to inactivity, let us know if you need more help. Cheers!


jsconfig.json is overwritten at startup

VS Code: 1.15.1
OS: Windows 10
I always get the message that I should configure my jsconfig.json file to exclude large folders. Unfortunately this file is overwritten on each VS Code startup and I'm therefore not able to exclude any additional folder. How can I change my jsconfig file?

We should never overwrite your jsconfig file. Do you know how is it being overwritten? Does this issue reproduce if you disable extensions by starting code with the --disable-extensions command line flag?

You are right. One of my extensions creates the jsconfig.json file. Thanks for pointing me in the right direction.


Stress Test for summit prep on high traffic to test search perf

Purpose:
The idea is to perform Stress Test to simulate high traffic like for the upcoming summit, testing search performance, etc so we can leverage an additional node ahead.

Using Jmter for load test

I  tried the load test  with 500 users and  script executed without any error.


Major rework of the examples.

Main changes

Restructures the categories
Adds Basic Examples (durable execution, virtual objects, ...)
Add Durable Promises example
Reworks some examples to be simpler. Focus on the essentials, minimize noise around that (optional files, comments, etc.)
Adjusts all TypeScript example for release 0.8

Structure
The structure of the examples is as follows (copied from the README)
A collection of examples that illustrate how to use Restate to solve common application
challenges.

Basics: Small examples highlighting the basic building blocks, like
durable execution or virtual objects.

Use Cases and Patterns: Small specific use cases, like webhooks,
workflows, asynchronous task queuing.

End-to-End Applications: Runnable demo applications that consist
of many components, e.g., a fodo ordering app, or an e-commerce site.
Typically packaged as a docker compose setup.

Tutorials: A step-by-step guide that builds an application and introduces
the Restate concepts on the way.

Templates: Project templates for various languages and build systems.
Simple 'Hello World!' examples in a proper build setup that you can use if you want to start
a brand new project for a service or lambda that will be invoked through Restate.

Examples by Language
The majority of the examples currently exist as TypeScript versions, Java versions are catching up.
Here is a (incomplete) list of examples per language.
TypeScript

Type
Name / Link

Basics
Workflows, Durable Execution, Event-processing, Virtual Objects

Use Cases
Sagas

Use Cases
Durable Promises

Use Cases
State Machines

Use Cases
Payment Service

End-to-End
Food Ordering App

End-to-End
AI Image Processing Workflow

End-to-End
Online Shop

Tutorial
Tour of Restate

Templates
Restate Node/TS Template

Java

Type
Name / Link

Use Cases
Sagas

End-to-End
Food Ordering App

Tutorial
Tour of Restate

Templates
Restate Node/TS Template

Kotlin

Type
Name / Link

Templates
Restate Node/TS Template

Scala

Type
Name / Link

Templates
Restate Node/TS Template

Assumptions for reviewers to verify

I moves to the philosophy of having minimal files/noise in the example repos, so generally no .eslintrc, .gitignore, etc.
We don't need every example to be downloadable three ways, and don't need to spell that out in every example
Folks know how to work with zips. We put a link to the zip, but don't prepare the wget / unzip / cd / rm sequence for them.

I like the new layout a lot! Something missing that I think deserves its own top-level category is a "infrastructure and deployment automation" section to house things like Kubernetes and AWS/CDK recipes. Unlike the templates, we can go into more details and showcase available options there. I don't think we should use end-to-end applications to showcase the deployment aspects; they should be self-contained and easy to deploy/run, but we should be focused rather than comprehensive there.


electron_23: init at 23.0.0

Description of changes
Add Electron 23 and make it the default electron package.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Closing this one for newer version PR  https://github.com/NixOS/nixpkgs/pull/217868


which sass lib can use to implement renderSync function in moduleCache.sass

My project is a pure html project. I want to render vue sfc according data from api.
Insert sass.js by <script src="./libs/sass/sass.js"></script>;
First I use sass.js to compile in renderSync function like below:
var sass = new Sass();
const options = {
    moduleCache: {
            vue: Vue,
            sass: {
                renderSync(args) {
                    const { data, file, filename, outFile, sourceMap } = args;
                    return new Promise((reslove, reject) => {
                        sass.compile(data, function (result) {
                            reslove({
                                css: result.text,
                                stats: {}
                            });
                        });
                    });
                }
            }
        },
    },
    ...
};

Then if I try to return some test scss code, it works. like beow:
var sass = new Sass();
const options = {
    moduleCache: {
            vue: Vue,
            sass: {
                renderSync(args) {
                    return {
                        css: '.chart-con{background:#f00}',
                        stats: {}
                    }
                }
            }
        },
    },
    ...
};

This means that renderSync function must return sync。
So I then search if sass.js can compile sync, but it seems impossible.
Is there any other sass lib can do job like sass.js. The form is like this beolow:
// my expected form
let cssstr = sasslib.compile(sassstr);
...

I would be happy if anyone can provide some suggestions.

[solved]
I rebuild vue3-sfc-loader without compress. And modify call stack of renderSync function with async await


Timed out trying to set AX messaging timeout

New Issue Checklist

[X] Updated fastlane to the latest version
[X] I have read the Contribution Guidelines

Issue Description
When running scan on travis-ci.org my builds fail with a strange error (see below). This doesn't happen when  running locally (using Xcode 8 Beta 6).
Complete output when running fastlane, including the stack trace and command used
https://travis-ci.org/AlexChesters/schedule-ios/builds/156441330
Testing failed:
Test target scheduleUITests encountered an error (Timed out trying to set AX messaging timeout. If you believe this error represents a bug, please attach the log file at /Users/travis/Library/Developer/Xcode/DerivedData/schedule-bvgggwnybgkfjmbfdxscmrgvxdqf/Logs/Test/6CC6B04E-17A8-48AE-8CD2-3F5017C07E60/Session-scheduleUITests-2016-08-31_073846-ITuN7a.log)
** TEST FAILED **
[07:40:46]: Exit status: 65
[07:40:46]: Variable Dump:
[07:40:46]: {:DEFAULT_PLATFORM=>:ios, :PLATFORM_NAME=>:ios, :LANE_NAME=>"ios test", :SCAN_DERIVED_DATA_PATH=>"/Users/travis/Library/Developer/Xcode/DerivedData/schedule-bvgggwnybgkfjmbfdxscmrgvxdqf", :SCAN_GENERATED_PLIST_FILES=>["/Users/travis/Library/Developer/Xcode/DerivedData/schedule-bvgggwnybgkfjmbfdxscmrgvxdqf/Logs/Test/6CC6B04E-17A8-48AE-8CD2-3F5017C07E60_TestSummaries.plist"], :SCAN_GENERATED_PLIST_FILE=>"/Users/travis/Library/Developer/Xcode/DerivedData/schedule-bvgggwnybgkfjmbfdxscmrgvxdqf/Logs/Test/6CC6B04E-17A8-48AE-8CD2-3F5017C07E60_TestSummaries.plist"}

Configuration Files
Please copy the complete content of your Fastfile and any other configuration files you use below:
Fastfile:
default_platform :ios

platform :ios do
  before_all do
    fastlane_version "1.102.0"
  end

  desc "Runs all the tests"
  lane :test do
    scan(scheme: 'schedule')
  end
end

Environment
fastlane version (run fastlane -v):
1.102.0
Do you use bundler to execute fastlane (i.e. bundle exec fastlane)?
Yes
Do you use a Ruby environment manager (e.g. chruby, rbenv, rvm)?
Yes
This is the repo affected by the issue:
https://github.com/AlexChesters/schedule-ios

Hi @AlexChesters Thanks for reaching out. Are you able to build your test target successfully in Xcode? That'll help figure out what's going on here. Thanks!

Hi @TKBurner,
Yes. I can successfully build and run my UI tests in Xcode.

+1 I am facing the same issue. It only occurs when executing tests on travis-ci and my tests pass locally.

@esetnik @AlexChesters What version of Xcode is being used in Travis? I'm trying to figure out if this relates to Xcode 8 specifically. Thanks!

Xcode 8
Sent from my iPhone
On 6 Sep 2016, at 6:52 pm, Todd Burner <notifications<EMAIL_ADDRESS>wrote:
@esetnikhttps://github.com/esetnik @AlexChestershttps://github.com/AlexChesters What version of Xcode is being used in Travis? I'm trying to figure out if this relates to Xcode 8 specifically. Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/fastlane/fastlane/issues/5964#issuecomment-245032919, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKEdSFuvXzhuAZxx6M57_5YeGnziM14Lks5qnahDgaJpZM4JxU1F.

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Xcode 8

@AlexChesters  @esetnik Thanks! I've circled back with the core team and we'll update on this thread. 👍

@TKBurner cool, thanks! 👍

This seems to happen even without fastlane in the mix https://travis-ci.org/xmartlabs/Eureka/builds/151205338
I think this may be a Xcode8 + Travis thing for now.

@mfurtak Agreed. There's already an open issue with the travis-ci team, but I don't think they've followed up with a resolution or a workaround.
I was hoping it would just be resolved with the Xcode 8 GM build, but no such luck.

Thanks for linking to that context @downie! 👍

I am having this issue on XCode 8. I don't use Travis at all.

@xaphod Thanks for following up on this. Do you have any nsunmatablestrings in your tests? There is a bug with these hanging.

@TKBurner Rebooting fixed this for me. No idea why.

@xaphod Awesome! Really glad you got up and running.


Support SpringBoot nested jar file

When we use pkl config in Java SprintBoot application
We will get error
Caused by: org.pkl.core.PklException: –– Pkl Error ––
Refusing to load module `jar:nested:/app.jar/!BOOT-INF/classes/!/config/dev.pkl` because it does not match any entry in the module allowlist (`--allowed-modules`).

it's because jar:nested isn't include in allow-modules.
we could fix it by add it into allowModules and change defaultTrustLevel, but how about add jar:nested into java default configuration?

@semistone Are you using https://github.com/apple/pkl-spring or plain Pkl?

I used plain Pkl to load non spring configuration
and the application.jar is build by
./gradle assemble
that issue is because the pkl file is in
app.jar:!BOOT-INF/classes/
 jar tfv application.jar|grep pkl
...
  1429 Wed Oct 30 06:25:00 JST 2024 BOOT-INF/classes/application.pkl
   396 Wed Oct 30 06:25:00 JST 2024 BOOT-INF/classes/application-local.pkl


A request for looking up documentation

Is there a way to request documentation for something defined in Language Server Protocol? What I'm looking for is something like this.
def foo():
    # Imagine your cursor is on `bar` here,
    # and you can request documentation for it.
    bar()

I'd like to essentially send a request to look up documentation, and get the documentation text back in a response, such as a docstring for a Python function, or jsdoc text for TypeScript, etc. Currently you can make a "hover" request, but the "hover" request appears to be intended for returning only brief information for a given cursor position, such as short description of a function's signature and a brief summary. It would be nice to be able to separately request full documentation for anything at your cursor.
tsserver does appear to offer full documentation for in its quickinfo request, which is roughly equivalent to hover. https://github.com/Microsoft/TypeScript/blob/master/lib/protocol.d.ts#L1253

This is currently not possible.

I feel this will be difficult to provide in a language-agnostic kind of way due to the different ways a build path can be defined for a language. But perhaps I'm overthinking things here...

Currently you can make a "hover" request, but the "hover" request appears to be intended for returning only brief information for a given cursor position, such as short description of a function's signature and a brief summary. It would be nice to be able to separately request full documentation for anything at your cursor.

In JDT-LS (and Eclipse JDT in general), the hover shows the JavaDoc even if it's a long one, and this is still quite usable. What makes you say there is a restriction on the content that's returned by the hover request? Where in the spec is the part that makes hover not fit your use-case?

I think his point is that there is no guarantee that it is always complete.

I am not sure I understand your concerns. For hover the server already needs this information.

I wasn't sure what would be included in the request parameters as I had thought it wouldn't have enough context if you simply arbitrarily gave it a class name and its function (if there were two classes named Person and/or the namespace was ambiguous and so on). However, I realized I missed this bit...

It would be nice to be able to separately request full documentation for anything at your cursor.

So yes, it's basically the same as a hover. Don't mind me... :)

I think there's no guarantee that a language will support documentation requests. It might make sense to offer documentation requests as an optional feature, with flags for indicating if the server supports the feature, as LSP does already with other features.
I'm not entirely certain if the idea holds water myself. I just think it might be a good idea.