Support for filtering null columns

I'm trying to do a query that would result in SQL like this:
select * from emails where deleted_at IS NULL;
# or
select * from emails where deleted_at IS NOT NULL;

db(:emails)
|> filter(:deleted_at, "IS NULL")
|> all

Results in:
** (FunctionClauseError) no function clause matching in Postgrex.Extensions.Binary.encode_timestamp/1
    (postgrex) lib/postgrex/extensions/binary.ex:241: Postgrex.Extensions.Binary.encode_timestamp("IS NULL")
    (postgrex) lib/postgrex/protocol.ex:299: anonymous fn/2 in Postgrex.Protocol.encode_params/1
      (elixir) lib/enum.ex:1043: anonymous fn/3 in Enum.map/2
      (elixir) lib/enum.ex:1387: Enum."-reduce/3-lists^foldl/2-0-"/3
      (elixir) lib/enum.ex:1043: Enum.map/2
    (postgrex) lib/postgrex/protocol.ex:294: Postgrex.Protocol.encode_params/1
    (postgrex) lib/postgrex/protocol.ex:264: Postgrex.Protocol.send_params/2
    (postgrex) lib/postgrex/protocol.ex:136: Postgrex.Protocol.message/3

Probably the easiest way is to do this:
db(:emails)
|> filter("deleted_at IS NULL")
|> all

Although what you wrote above should work. I'm a bit puzzled because we had a filter method in there where you could:
db(:emails)
|> filter(:id, ">", 100)
|> all

... which should allow you to do this. Anyway the query here should work for you (for now) - I''ll leave this open to work on for 1.0.9. Cheers.

I get an unidentified func filter/4 for your 2nd example.
The first example works, but not when I pipe through filter() a second time:
iex(36)> db(:emails) |> filter(user_id: 16) |> count
919

iex(37)> db(:emails) |> filter(user_id: 16) |> filter("deleted_at IS NULL") |> count
36081

## what the queries look like:

iex(38)> db(:emails) |> filter(user_id: 16)
%Moebius.QueryCommand{columns: nil, error: nil, group_by: nil, join: [""],
 limit: "", offset: "", order: "", params: [16], pid: nil, sql: nil,
 table_name: "emails", type: :select, vals: nil, where: " where user_id = $1",
 where_columns: [:user_id]}

iex(39)> db(:emails) |> filter(user_id: 16) |> filter("deleted_at IS NULL")
%Moebius.QueryCommand{columns: nil, error: nil, group_by: nil, join: [""],
 limit: "", offset: "", order: "", params: [], pid: nil, sql: nil,
 table_name: "emails", type: :select, vals: nil,
 where: " where deleted_at IS NULL", where_columns: [:user_id]}

So it appears the 2nd pass through filter() is destructive.

You can't pass through to filters now. This is something that I wanted to look at. @taylorbrooks We are doing it but updating :where in the map
—
Thanks,
Johnny
On Thu, Nov 19, 2015 at 9:07 PM, Taylor Brooks<EMAIL_ADDRESS>wrote:

I get an unidentified func filter/4 for your 2nd example.
The first example works, but not when I pipe through filter() a second time:
iex(36)> db(:emails) |> filter(user_id: 16) |> count
919
iex(37)> db(:emails) |> filter(user_id: 16) |> filter("deleted_at IS NULL") |> count
36081
## what the queries look like:
iex(38)> db(:emails) |> filter(user_id: 16)
%Moebius.QueryCommand{columns: nil, error: nil, group_by: nil, join: [""],
 limit: "", offset: "", order: "", params: [16], pid: nil, sql: nil,
 table_name: "emails", type: :select, vals: nil, where: " where user_id = $1",
 where_columns: [:user_id]}
iex(39)> db(:emails) |> filter(user_id: 16) |> filter("deleted_at IS NULL")
%Moebius.QueryCommand{columns: nil, error: nil, group_by: nil, join: [""],
 limit: "", offset: "", order: "", params: [], pid: nil, sql: nil,
 table_name: "emails", type: :select, vals: nil,
 where: " where deleted_at IS NULL", where_columns: [:user_id]}

So it appears the 2nd pass through filter() is destructive.
Reply to this email directly or view it on GitHub:
https://github.com/robconery/moebius/issues/35#issuecomment-158258560

I guess I should look at this issue :)

The filter issue is fixed; null values (from OP) are handled with string pass. If I'm wrong on understanding this please reopen.


npm run lint throws error when spaces are in path on Windows

Node version:
5.1.11
npm version:
3.8.6
The output:
><EMAIL_ADDRESS>lint d:\Documents\Visual Studio 2015\Projects\NewsNotifier
> esw webpack.config.* src tools

'd:\Documents\Visual' is not recognized as an internal or external command,
operable program or batch file.

npm ERR! Windows_NT 10.0.10586
npm ERR! argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "lint"
npm ERR! node v5.11.1
npm ERR! npm  v3.8.6
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>lint: `esw webpack.config.* src tools`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>lint script 'esw webpack.config.* src tools'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the react-slingshot package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     esw webpack.config.* src tools
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs react-slingshot
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls react-slingshot
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     d:\Documents\Visual Studio 2015\Projects\NewsNotifier\npm-debug.log

Ah! It's because you have a space in your path. eslint-watch doesn't support running in a path with spaces. I'll open a ticket against them, but in the meantime I'd suggest moving your project to a folder that doesn't have spaces in the name.

Thanks for filing the issue.

Just an update - eslint-watch now has a branch with this issue fixed so can hopefully close this soon.

Just updated to the latest version of eslint-watch to resolve this.


[WIP] General updates to align with general release of Blockstack Connect

Resolve:

[x] #566
[x] #565
[x] #564
[x] #553
[ ] #560
[x] #552
[x] #561

FYI I've closed this PR out in favor of https://github.com/blockstack/docs.blockstack/pull/612 since I messed up the branch with a rebase 🤷


Distinguish windows-exporter-daemonset.yaml is for Windows Server 2019, not Windows Server 2022

The document says

Windows Server 2019 and Windows Server 2022 are supported.

but the support is not seamless and user needs to make certain decisions.
That is, to "Enable Windows metrics collection" user needs to use different manifests because the windows-exporter-daemonset.yaml mentioned in the article will pull mcr.microsoft.com/windows/nanoserver:1809 which will not work on Windows Server 2022 node.
Instead, user needs to use dedicated manifest windows-exporter-daemonset-ws2022.yaml.
The article needs to be updated to accommodate those differences.

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

ID: 58a1690b-c20f-b07e-29b9-1a8f98528114
Version Independent ID: c58b4d70-1b2f-166f-8a23-935410e23ca9
Content: Enable Azure Monitor managed service for Prometheus - Azure Monitor
Content Source: articles/azure-monitor/essentials/prometheus-metrics-enable.md
Service: azure-monitor
Sub-service: essentials
GitHub Login: @EdB-MSFT
Microsoft Alias: edbaynash

@mloskot
Thanks for bringing this to our attention. We will investigate it further and update you shortly.

@mloskot  Thanks for reporting this.

@bragi92

Hey @mloskot Can you try using the following YAML? https://github.com/Azure/prometheus-collector/blob/main/internal/windowsExporterInstaller/windows-exporter-daemonset.yaml
I have created the following PR to update the community image for the init container whcih is causing the issue : https://github.com/prometheus-community/windows_exporter/pull/1245
The updated one works on both windows server 2019 and windows server 2022 nodes.

@bragi92 I surely can, but I need to clarify a couple of things first:

On my WS 2022 -based AKS clusters, I had used windows-exporter-daemonset-ws2022.yaml. Why specifically you suggest to use windows-exporter-daemonset.yaml, how does it differ?

AFAICT, current version of windows-exporter-daemonset.yaml uses image: mcr.microsoft.com/powershell:lts-nanoserver-1809 which won't work on my clusters, will it? Unless, there is something that I don't know or understand.

``

@bragi92 I surely can, but I need to clarify a couple of things first:

On my WS 2022 -based AKS clusters, I had used windows-exporter-daemonset-ws2022.yaml. Why specifically you suggest to use windows-exporter-daemonset.yaml, how does it differ?
AFAICT, current version of windows-exporter-daemonset.yaml uses image: mcr.microsoft.com/powershell:lts-nanoserver-1809 which won't work on my clusters, will it? Unless, there is something that I don't know or understand.
Or, perhaps you mean that I should try the manifests from your PR fix: Update init container in windows exporter so that it works on both WS2019 and WS2022 prometheus-community/windows_exporter#1245 ?

The init container here is a mult-arch image so it works both on WS 2019 and WS 2022.

Yes, it should work on your cluster since its a multi-arch image. This way you won't have to deploy another daemonset in case you add WS 2019 nodes to your cluster.

The manifest in that PR is using the updated mcr.microsoft.com/powershell:lts-nanoserver-1809 which is a mult-arch image and yes, you can use the updated one too.

Please let me know if this doesn't fix your issue or if everything works for you after the deployment.

@bragi92  - Thank you for providing your insights.
@mloskot- I hope @bragi92 has answered your question.
At this moment, Since there is no doc update required, We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

@mloskot Where you able to resolve your issue with this?

@bragi92 Yes, I think so. The deployment using the latest internal/windowsExporterInstaller/windows-exporter-daemonset.yaml and the updated multi-arch image seems working.
There are some collector issues logged though, but nothing seems to be reported so far, so I will assume it's safe to ignore these:

Thanks!

@bragi92

Yes, it should work on your cluster since its a multi-arch image

Although this may be a bit off-topic here, this note of yours makes me wonder: how did you build those multi-arch/os images, so they are usable on hosts compatible with 1809 and ltsc2022 ?
The only official material I found is this at
https://learn.microsoft.com/en-us/azure/container-registry/push-multi-architecture-images#build-and-push-a-multi-arch-image
Is this how those images were built?

@mloskot  Yes, the link you mentioned is right. You build the two images seperately and then put them together in a single tag.
We do this for the prometheus collector image here: https://github.com/Azure/prometheus-collector/blob/main/.pipelines/azure-pipeline-build.yml#L370

Thank you @bragi92


add job scheduling section into guides

This PR add the tutorial of  job scheduling with kube-arbitrator and gang-scheduling into guides.
Fixed the issue: kubeflow/tf-operator#743

This change is

/assign @jlewi

@sarahmaddox
Thanks for your advices!
I have made some change, please have a look again, thanks!

/cc @k82cn @johnugeorge

LGTM

Thanks! I'll leave this to @jlewi to approve in case he has any comments.
/lgtm

/lgtm , thanks :)

/approve

the kube-arbitrator is renamed as kube-batch, should this document be updated as well ?
And looks like the document says using PodGroup object to achieve the scheduling, while this document says using PDB.  Is tf-opertor working with an old version ?
@ChanYiLin @k82cn

oh, saw https://github.com/kubeflow/tf-operator/issues/837 opened.
still the 2nd question

Hi, @jian-he
Previously, tf-operator create the pdb of the job while kube-batch schedule all the pods of the TFJob according to  that pdb.
Now, kube-batch changed to use podgroup which is also going to be the native resource type in Kubernetes in the near future to achieve gang-schedule. However, it keeps pdb available to have compatibility to other projects like tf-operator. See code
So we decide to keep using pdb in tf-operator until podgroup is merged into Kubernetes mainstream.
You can find the discussion here

I know tf-operator uses PDB for gang-scheduling, not sure about kube-batch, is it using PDB or PodGroup ?

Both are supported for now; PDB is only used for backward compatibility.
PodGroup will provide more features in near future, e.g. "transaction" for ResourceQuota (https://github.com/kubernetes-sigs/kube-batch/issues/401), lifecycle (https://github.com/kubernetes-sigs/kube-batch/issues/388) which are parts of discussion at Coscheduling/Gang-scheduling. PodGroup will be in https://github.com/kubernetes-sigs/kube-batch for a while.


Create covid and cousin solution.cpp

Solution to the problem covid and cousin

Please add DWOC and Level 1 labels to ths and assigne me this issue.
I checked leaderboard and this issue is not counted there.Please make the requested changes.
Thanks :-)

Please add DWOC and Level 1 labels to ths and assigne me this issue.
I checked leaderboard and this issue is not counted there.Please make the requested changes.
Thanks :-)


Overwrite .env file on compiled application

Is there is a way to point application to use another .env file instead of bundled one?

I don't quite understand what you are referring to. If you are talking about the configuration file of spc (such as config/ext.json, etc.), just overwrite it directly in the same directory as spc.

I mean after compiling code to the executable file, I want to be able to run it with an external .env file.

Sorry, I still don't understand what you mean by .env. static-php-cli is just a tool for statically compiling PHP. If you access it from other projects (such as FrankenPHP, Herd or NativePHP), .env may be related to these projects.
But according to your description, it may be the packaging source code function of FrankenPHP. You can submit an Issue or PR to the corresponding framework or project: fix the .env primary and secondary search directories in the packaging state. (Because the relative path and working directory in the packaging state may be different)


Backport PR #1339 on branch 0.10.x (Run CI on release branches)

Backport PR #1339: Run CI on release branches

Actually not sure if we need to merge this one... Adding a commit to the release branch to check

Doesn't seem to be running...


Support for model element string names

We should have them. need space in the input file somewhere, plus API to get/set them.

seems a good place for this in the inp file is as a "comment" on the same line as the element definition, preceded by a semicolon ;

What do you mean by name? Another string apart from the ID?

i think that's right. usually we are dealing with epanet inp files that have been exported from some master workflow and the "ID" field is actually some obfuscated GIS identifier. We also need a human-readable version.

@eladsal Yes. @samhatchett Ideally it should be more formal, though I recognize this could get into territory of non-backward-compatibility.  Need a place that is dedicated, I think.

I'm going to put this up on the forum, both because it has a strong 'user orientation' and also to add to the linkages between issues/forum posts.

The proper way is to add it as a property of the elements but then we have the backward-compatibility issue which we should discuss soon. There are ways to partially overcome this.
There are two "non-formal" ways to do this. One would be, as @samhatchett suggested, to put it after the semicolon. This string is read by the EPANET GUI and placed in the Description field. The second way is to put it in the Tags section of the INP file which is shown in the GUI too. Both strings are not currently read by the Toolkit since they are not used by the solver (but should be read when asked like the coordinates).

wow, i did not remember the [Tags] section! that seems like the better choice, since it's a separate section that is already recognized by the old GUI

Just remember that no spaces are allowed in the Tag field.

url encoding is an option...

yes

There is also [LABELS]. The format of that section could probably be adapted for backward compatibility so long as we only need node element labels. This section is:
X  Y  "string label"
Where the quotes are part of the format and node id is optional. So if there's only two fields it could be assumed to be the label and the node id.

That was supposed to be
X  Y  "label"

Crap! I guess when you use angle brackets that's interpreted as a type of markdown.

Some housekeeping...
@jamesuber would you like to close this issue and maybe open a new one for new APIs for the [TAGS] section? Or something else?

@eladsal I think I'd prefer to leave this as an open issue with the more generic understanding that model elements often have to use a GIS ID, but there are applications that want to refer to model elements by a meaningful name. Supporting this somehow within the next generation code base would then support those applications. But especially given the discussion I'm less inclined to specifically request that it be the [TAGS] section, or the comment string... but if the devcom wants to close this then that's Ok also. But then it could get lost.

how about we split into three issues:

short term: parse the comments on the same lines as the element definition, save as "description" field in network data
mid term: parse the [tags] section, store that data somewhere  (parity with the GUI)
longer term: general key-value capability for element relational data

Sure. I like that.

On Dec 1, 2015, at 5:03 PM, Sam Hatchett<EMAIL_ADDRESS>wrote:
how about we split into three issues:
short term: parse the comments on the same lines as the element definition, save as "description" field in network data
mid term: parse the [tags] section, store that data somewhere (parity with the GUI)
longer term: general key-value capability for element relational data
—
Reply to this email directly or view it on GitHub.

split to #47 #48 #49


Add logging backend integration

Which Issue(s) this Pull Request Resolves

Resolves #
Release Note

NONE

Notes for Reviewers

Still working on tests and also need to merge with the changes on #663 and #665.
Instead of adding the configmap read,as that is going to be added on #665 I tested my changes with
hardcoded values shown in api/main.go
There is a new dependency called ojg that stands for Optimized JSON for Golang for doing the JSON parsing for the Splunk retrieved data.
I only tried splunk and it returns a JSON per log line (it's not a whole json) so I am deserializing each line before applying the JSON path. The other option of joining all the lines in a whole JSON is still on the table but that will remove the possibility of streaming the logs (like Kubernetes API does [1]). Also, this could mean having a lot of memory consumed.
[1] Kubernetes API Implementation linked here uses http.ServeFile that ends up using copyBuffer function that streams the content from a reader to a writer on byte chunks

Kubernetes API Implementation linked here uses http.ServeFile that ends up using copyBuffer function that streams the content from a reader to a writer on byte chunks

Will streaming with with Elasticsearch, which I believe returns a JSON list of maps?

Kubernetes API Implementation linked here uses http.ServeFile that ends up using copyBuffer function that streams the content from a reader to a writer on byte chunks

Will streaming with with Elasticsearch, which I believe returns a JSON list of maps?

I've created a separate issue to address logging integration tests with elasticsearch. If we need to change the approach could be done when addressing that issue.


X-NUCLEO-IHM05A1

Hi Priscilla,
thanks for the PR. It is fine for me but could you splash the several commits in just one commit?
Thanks in advance and best regards.
Carlo

Merge done!
Thanks a lot Priscilla!


Turn off HHS warning banner for MyCarePlanner

Default to off.

Added an env variable name REACT_APP_HHS_BANNER in the .env file. Changing this value to true will enable the HHS warning banner on the app and changing it to false will disable the HHS warning banner.

just a quick comment on the HHS warning banner in version 2.2.0.  I set REACT_APP_HHS_BANNER="false" as an environment variable on the command line, but it appears that a value of false still means that the banner should show, as it's showing in that case:

also the progress bar is still displaying on top, as you can see in the screenshot.
Setting REACT_APP_HHS_BANNER="true" continues to disable the banner.
Not a blocker as we can still turn it off, I just wanted to bring this to your attention.  FYI


Png CSS

I exported an animation with png pictures.
Is it possible to sytle these pictures using CSS?

probably some filter effects can be applied to them. But not sure every browser supports them.


Item names bug

Here is an example: I setup a quest where the player has to bring a book to the npc. if i just bring a book it does not take it. Only if I rename it (using anvil) from the (German) Buch to BOOK it works. So there must be something wrong with the item names.

So you're adding the item from hand/your inventory? Is this issue similar: https://github.com/Blackvein/Quests/issues/42

@FlyingPikachu Loading item from hand doesnt work ;)

Thanks, I saw your ticket but I'd like to confirm that ScuroK is having the same issue first.

No he have a other problem and i know what he means

I confirm! load from hand does nothing.

Okay, try dev build #18 once it's available and let me know if that resolves the issue (no guarantee).
http://ci.ac3-servers.eu/job/Quests/

ok i test it now

Create quest set deliver item with Set name too: book
http://prntscr.com/63831q
http://prntscr.com/63835s
taking the quest:
http://prntscr.com/6383ef
Rightclicking the Npc with the Book doesnt work:
http://prntscr.com/6383t5
Rename the book with a Anvil to BOOK:
http://prntscr.com/638415
Works..:
http://prntscr.com/63846w

Is that on the dev build? And there any console errors?

It does still not work my friend. did you know that minecraft 1.8 chanced all the item ids? does this have something to do with this bug? and load item from hand does also still not work.

@FlyingPikachu no Errors.
If i rename my item: http://prntscr.com/63883s
exact like the plugin want it: http://prntscr.com/63887j
It works fine. You need to change the code that they took the item nameID and dont care about what names are the item has.
Sorry for my bad english

load from hand does nothing:
http://prntscr.com/63882n
Wants RAW_BEEF only....:
http://prntscr.com/6388jn

Zeile 514: [01:54:38] [Server thread/WARN]: [Quests] An error occurred inserting data into the snooper database!
Zeile 513: [01:54:38] [Server thread/WARN]: [Quests] An error occurred removing old data from the snooper database!

@ScuroK For the first picture: Remove youre configs and recreate then they show: Item loaded. But its not :D

However: the item-names system seems to be completely broken right?

Looks like

i am not a dev but i guess its because of the changes in the item id/names system in 1.8.

That's entirely possible. My current suspicion is it wants an ENUM value (thus the capital letters). Just need to find where.

good luck mate :)

Just good luck!

How is it going?

Pikachu I love you for updating and putting time into this
If I could help ironing out this issue I would love to, though I can't seem to figure it out.
On the other hand I might have a lead on something that could help.
The plugin Shopkeepers which is at 1.8 currently.
https://github.com/nisovin/Shopkeepers
It uses some system to identify and store item information, lore, tags and such.
While they use a interface I feel as though the system is very similar in the fact that it accepts and stores item details and can be specific on an item for accepting trades and rewarding trades.
Much like quests it doesn't have any dependencies and uses in game interface.
Just thought might help.

Fixed in Quests 2.1.6. Thanks!
@Leescar I appreciate that, however, while the plugin in your link and many others have similar interfaces, the code varies greatly. In the future, please consider making a pull request! (:

Seems to work now! Thank you!

Seems to work now! Thank you!


[terra-button] Hover highlight enabled after click on mobile devices

Bug Report
Description
After clicking a button, the button displays as though it is hovered on mobile devices.
Steps to Reproduce
This behavior is reproducible using the button"variant example on the documentation page on mobile.

Click on Button with "Neutral" text on it.
Button remains highlighted with hover effect.

Additional Context / Screenshots
Expected Behavior
If button is clicked on mobile device I would expect it to remove the hover effect after click.
Possible Solution
Environment

Component Name and Version: terra-button
Browser Name and Version:
Node/npm Version: [e.g. Node 8/npm 5]
Webpack Version:
Operating System and version (desktop or mobile): mobile

@ Mentions
@StephenEsser

I wonder if this could be resolved in a similar way as https://github.com/cerner/terra-core/pull/2332 - perhaps extended to any component with a hover style.

Before working on this wait for instructions from @neilpfeiffer


[corrade/magnum/-extras/-integration/-plugins] Update to 2018.10

Hi @ras0219-msft !
Magnum just tagged a new release! 🎉
I updated the magnum family of ports, @mosra will quickly go through these (straigh forward) changes and give his approval.
Thanks in advance,
Jonathan.

@Squareys  @mosra Thanks for the PR! LGTM pending CI :)


ninja: build stopped: subcommand failed?

`/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/utils/cpp_extension.py:118: UserWarning:
                           !! WARNING !!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Your compiler (c++) may be ABI-incompatible with PyTorch!
Please use a compiler that is ABI-compatible with GCC 4.9 and above.
See https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html.
See https://gist.github.com/goldsborough/d466f43e8ffc948ff92de7486c5216d6
for instructions on how to install GCC 4.9 or higher.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
                          !! WARNING !!

warnings.warn(ABI_INCOMPATIBILITY_WARNING.format(compiler))
CalledProcessError                        Traceback (most recent call last)
~/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/utils/cpp_extension.py in _build_extension_module(name, build_directory)
758         subprocess.check_output(
--> 759             ['ninja', '-v'], stderr=subprocess.STDOUT, cwd=build_directory)
760     except subprocess.CalledProcessError:
~/.conda/envs/pytorch0.41/lib/python3.6/subprocess.py in check_output(timeout, *popenargs, **kwargs)
335     return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
--> 336                **kwargs).stdout
337
~/.conda/envs/pytorch0.41/lib/python3.6/subprocess.py in run(input, timeout, check, *popenargs, **kwargs)
417             raise CalledProcessError(retcode, process.args,
--> 418                                      output=stdout, stderr=stderr)
419     return CompletedProcess(process.args, retcode, stdout, stderr)
CalledProcessError: Command '['ninja', '-v']' returned non-zero exit status 1.
During handling of the above exception, another exception occurred:
RuntimeError                              Traceback (most recent call last)
 in ()
----> 1 from modules import InPlaceABN, ASPPInPlaceABNBlock, InPlaceABNWrapper
2
3 import torch.nn as nn
4 import encoding
5 import torch
~/Desktop/RFMobileNetV2Plus/modules/init.py in ()
2 from .misc import ASPPBlock, SDASPPInPlaceABNBlock, ASPPInPlaceABNBlock, InvertedResidual
3 from .bn import ABN, InPlaceABN, InPlaceABNWrapper, InPlaceABNSync, InPlaceABNSyncWrapper
----> 4 from . context_encode import ContextEncodeInplaceABN, ContextEncodeDropInplaceABN
5 from .dualpath import DualPathInPlaceABNBlock
6 from .residual import IdentityResidualBlock
~/Desktop/RFMobileNetV2Plus/modules/context_encode.py in ()
2
3 import torch.nn as nn
----> 4 import encoding
5 import torch
6
~/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/init.py in ()
11 """An optimized PyTorch package with CUDA backend."""
12 from .version import version
---> 13 from . import nn, functions, dilated, parallel, utils, models, datasets
~/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/nn/init.py in ()
10
11 """Encoding NN Modules"""
---> 12 from .encoding import *
13 from .syncbn import *
14 from .customize import *
~/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/nn/encoding.py in ()
16 from torch.nn.modules.utils import _pair
17
---> 18 from ..functions import scaled_l2, aggregate, pairwise_cosine
19
20 all = ['Encoding', 'EncodingDrop', 'Inspiration', 'UpsampleConv2d']
~/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/functions/init.py in ()
1 """Encoding Autograd Fuctions"""
----> 2 from .encoding import *
3 from .syncbn import *
4 from .customize import *
~/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/functions/encoding.py in ()
12 from torch.autograd import Function, Variable
13 import torch.nn.functional as F
---> 14 from .. import lib
15
16 all = ['aggregate', 'scaled_l2', 'pairwise_cosine']
~/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/lib/init.py in ()
13         os.path.join(cpu_path, 'roi_align_cpu.cpp'),
14         os.path.join(cpu_path, 'nms_cpu.cpp'),
---> 15     ], build_directory=cpu_path, verbose=False)
16
17 if torch.cuda.is_available():
~/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/utils/cpp_extension.py in load(name, sources, extra_cflags, extra_cuda_cflags, extra_ldflags, extra_include_paths, build_directory, verbose, with_cuda)
512         build_directory or _get_build_directory(name, verbose),
513         verbose,
--> 514         with_cuda=with_cuda)
515
516
~/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/utils/cpp_extension.py in _jit_compile(name, sources, extra_cflags, extra_cuda_cflags, extra_ldflags, extra_include_paths, build_directory, verbose, with_cuda)
680             if verbose:
681                 print('Building extension module {}...'.format(name))
--> 682             _build_extension_module(name, build_directory)
683         finally:
684             baton.release()
~/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/utils/cpp_extension.py in _build_extension_module(name, build_directory)
763         # error.output contains the stdout and stderr of the build attempt.
764         raise RuntimeError("Error building extension '{}': {}".format(
--> 765             name, error.output.decode()))
766
767
RuntimeError: Error building extension 'enclib_cpu': [1/4] c++ -MMD -MF syncbn_cpu.o.d -DTORCH_EXTENSION_NAME=enclib_cpu -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include/TH -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include/THC -I/home/suyanzhou/.conda/envs/pytorch0.41/include/python3.6m -D_GLIBCXX_USE_CXX11_ABI=0 -fPIC -std=c++11 -c /home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/lib/cpu/syncbn_cpu.cpp -o syncbn_cpu.o
[2/4] c++ -MMD -MF roi_align_cpu.o.d -DTORCH_EXTENSION_NAME=enclib_cpu -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include/TH -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include/THC -I/home/suyanzhou/.conda/envs/pytorch0.41/include/python3.6m -D_GLIBCXX_USE_CXX11_ABI=0 -fPIC -std=c++11 -c /home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/lib/cpu/roi_align_cpu.cpp -o roi_align_cpu.o
[3/4] c++ -MMD -MF nms_cpu.o.d -DTORCH_EXTENSION_NAME=enclib_cpu -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include/TH -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include/THC -I/home/suyanzhou/.conda/envs/pytorch0.41/include/python3.6m -D_GLIBCXX_USE_CXX11_ABI=0 -fPIC -std=c++11 -c /home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/lib/cpu/nms_cpu.cpp -o nms_cpu.o
FAILED: c++ -MMD -MF syncbn_cpu.o.d -DTORCH_EXTENSION_NAME=enclib_cpu -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include/TH -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include/THC -I/home/suyanzhou/.conda/envs/pytorch0.41/include/python3.6m -D_GLIBCXX_USE_CXX11_ABI=0 -fPIC -std=c++11 -c /home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/lib/cpu/syncbn_cpu.cpp -o syncbn_cpu.o
/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/lib/cpu/syncbn_cpu.cpp:1:26: fatal error: torch/tensor.h: No such file or directory
compilation terminated.
FAILED: c++ -MMD -MF nms_cpu.o.d -DTORCH_EXTENSION_NAME=enclib_cpu -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include/TH -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include/THC -I/home/suyanzhou/.conda/envs/pytorch0.41/include/python3.6m -D_GLIBCXX_USE_CXX11_ABI=0 -fPIC -std=c++11 -c /home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/lib/cpu/nms_cpu.cpp -o nms_cpu.o
/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/lib/cpu/nms_cpu.cpp:1:26: fatal error: torch/tensor.h: No such file or directory
compilation terminated.
FAILED: c++ -MMD -MF roi_align_cpu.o.d -DTORCH_EXTENSION_NAME=enclib_cpu -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include/TH -I/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/torch/lib/include/THC -I/home/suyanzhou/.conda/envs/pytorch0.41/include/python3.6m -D_GLIBCXX_USE_CXX11_ABI=0 -fPIC -std=c++11 -c /home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/lib/cpu/roi_align_cpu.cpp -o roi_align_cpu.o
/home/suyanzhou/.conda/envs/pytorch0.41/lib/python3.6/site-packages/encoding/lib/cpu/roi_align_cpu.cpp:1:26: fatal error: torch/tensor.h: No such file or directory
compilation terminated.
ninja: build stopped: subcommand failed.`
My ubuntu: 16.04 LTS
GCC Version: 5.4
pytorch version: 0.41
how to slove it ?

It is clearly stated in the README that the code requires pytorch 0.4, I would start from there.

@suyanzhou626 the error seems to be generated from code that is not directly related to inplaceABN.


Compiled JSON templates are not included in the published folder

I'm testing example provided for NoTargets SDK and after running dotnet build compiled JSON template is indeed appears in the output directory, but after running dotnet publish resulting directory is empty.
I'm using version 0.12.40 of Azure.Bicep.* NuGet packages.

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

ID: 1f33c6e8-b158-b9c4-4118-5537f7227921
Version Independent ID: 5fb4c62f-e369-49bc-6103-10793f8bf25d
Content: Use MSBuild to convert Bicep to JSON - Azure Resource Manager
Content Source: articles/azure-resource-manager/bicep/msbuild-bicep-file.md
Service: azure-resource-manager
Sub-service: bicep
GitHub Login: @davidsmatlak
Microsoft Alias: davidsmatlak

#assign:davidsmatlak

@olegd-superoffice Thank you for the documentation feedback. The article's purpose is to describe how to use MSBuild to convert a Bicep file to JSON. The dotnet publish command is outside the scope of the article. But I'll do some research about your question.

@davidsmatlak Will there be separate article about using dotnet publish? IMO it is just a part of the same process and usually I use dotnet publish in Azure DevOps pipeline to produce zipped packages which then will be used deployed to deploy to Azure in different environments.

@olegd-superoffice I created an internal task to review the article and research how to include a step like dotnet publish to the existing article. The task to review and update the article will be prioritized and scheduled, so I'm closing the GitHub issue. I'll post a comment when the work begins.
Thanks for your feedback.

#please-close


[No QA] fix: non-unique key warning

Details

This PR tries to fix the non unique key warning when sending a message on group with same avatar url of at least two users.
Note: Sometime the avatar looks same, but the url is different. I have added some log to verify that the url is unique. That is local to my dev setup and is not pushed in the PR.
Fixed Issues

$ https://github.com/Expensify/App/issues/10847
Tests

Login on web dev
Create a new group with two users that have the same avatar url.
Send a message
Verify that there is no console warning

[x] Verify that no errors appear in the JS console

PR Review Checklist

Contributor (PR Author) Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] Any functional components have the displayName property
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist
The Contributor+ will copy/paste it into a new comment and complete it after the author checklist is completed

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] iOS / native
[ ] Android / native
[ ] iOS / Safari
[ ] Android / Chrome
[ ] MacOS / Chrome
[ ] MacOS / Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product was added in all src/languages/* files
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] Any functional components have the displayName property
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

QA Steps

[x] Verify that no errors appear in the JS console

Screenshots

Web

https://user-images.githubusercontent.com/77761491/193012650-d826de53-6b9a-4051-9195-621e4dff754e.mp4
https://user-images.githubusercontent.com/77761491/193012676-923227de-4301-45ef-bec2-595ce1b1f3b8.mov
Mobile Web - Chrome

https://user-images.githubusercontent.com/77761491/193013048-3cf5406e-d056-49f8-85c6-9000f27b37b8.mov
Mobile Web - Safari

https://user-images.githubusercontent.com/77761491/193013079-6db576ed-98cf-4aab-9e31-0aa423daccd1.mov
Desktop

https://user-images.githubusercontent.com/77761491/193013116-25b7c3a6-207c-40cf-8281-207991bc0389.mov
iOS

https://user-images.githubusercontent.com/77761491/193013157-e2bc11d1-c185-4944-bedf-95625f948f3e.mov
Android

https://user-images.githubusercontent.com/77761491/193013202-d3fcac9b-c97d-4b41-bab6-dc4961230982.mov

@mdneyazahmad I can see screencasts are missing. Can you please update them ?

Except mWeb maybe all ?

@mdneyazahmad do you have any questions here? Waiting for the other screencasts. And I can see we've only fixed on issue. We need to fix the other one too.

Thanks for the update @mdneyazahmad.  No worries

@mananjadhav updated

@srikarparsi Quick bump ^

discussing marc's pr https://github.com/Expensify/App/pull/11434 which solves the same issue and still figuring out if we can use the tooltip part of the solution. Regardless, we will compensate for the work put into this issue.

@srikarparsi yeah it seems to be changing the same line. But I feel we can take a pull and still merge this one. This addresses two issues. RoomHeaderAvatars is not fixed via the other PR.

you're right thanks @mananjadhav.
Lets disregard the changes in ReportWelcomeText.js as @marcaaron's pr already addressed it but keep the change in RoomHeaderAvatars. @mdneyazahmad could you make that change in your pr? Also, since indexes shouldn't generally be used as keys in react: https://reactjs.org/docs/lists-and-keys.html#:~:text=We don’t recommend,indexes as keys, maybe we could use the image source uri  or combine the image source uri with the index for RoomHeaderAvatars? The images aren't being reordered so it shouldn't affect performance but it may be good practice in case we update that code in the future.

Yeah just source uri won't help. We would need to combine source uri + index.

@mdneyazahmad did you get a chance to look at the above comments?

@mananjadhav I see that the the linked issue will be fixed in some other PR. I just want to say that the original issue of this PR is to fix the issue (now will be fixed in some other PR), and also the additional issue.
At this point the issue descriptions is something else, and the PR address some other issue. I will suggest to open a new issue for RoomHeaderAvatars and handle that as a separate issue, and also the solution may not be that trivial unless we go with index as a key.
What do you think?

@mdneyazahmad The reason I asked to still update the change was because we agreed to it. And the only change suggested was ${sourceuri}${index}. That means still use the index also have the source uri.
Let me know if you still want to create this as a separate issue.
What are your thoughts @srikarparsi ?

@mananjadhav I am sorry, I did not carefully read the previous suggestions, and misinterpreted that. I am going to update it as suggested. That's an easy fix. Thanks you.

Updated!

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by @srikarparsi in version: 1.2.13-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by @yuwenmemon in version: 1.2.13-5 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Cache the yii::$app->user->identity in yii2

How can i Cache the yii::$app->user->identity

@Quexer69

@faizanktk I dont know why thats a question for me but I can try to help if you could explain a bit more what exactly you want to achive by caching the user identity ;)
cheers


A Carousel in another Carousel?

Hi,
I have a simple question. Can I put a  in another  component? I made a test with a dummy  that I putted in a parent (and working) : the first (parent) carousel works as expected, not the second (child) one.
Should this be working?

Hi @enguerranws,
Well, the Carousel component is, ultimately, a ScrollView and as such it should be possible to nest multiple carousels. Unfortunately, there are currently countless React Native issues about nested ScrollView.
My recommendation would be to take a look at these issues and see if you can find something that looks like the one you're experiencing.
Do not hesitate to keep me posted; I'll gladly help if I can ;-)

@bd-arc Following your advice, I'll go for another solution: putting a carousel in a carousel doesn't make really sense (swipe gesture conflict, etc.). I'll use a solution based on https://github.com/archriss/react-native-image-gallery

Well, I'm not going to try and dissuade you from using another of our plugins :p

Well, I was using 2 of them, now 3. You've basically written 50% of my app.


Add section about upgrading

Since this site generator installs a copy of Antora when installed globally, we need to explain that upgrading Antora itself doesn't upgrade the copy of Antora used by this site generator.

Thanks Dan!
I caught a few typos but otherwise the instructions are clear. If that's OK with you I can commit my suggestion and merge?

Yes, plus apply your updates and merge.

Merged, thanks 🎉


Returns undefined

I tried this and got the following error:
Unhandled promise rejection: Error: undefined: [object Object]

Could you provide some more info? What function did you run? Can you show me the code you used? Could you stringify the result (JSON.stringify(result)) to give some more error information?

I run the following function:
`        const ah = new AH();
    const filter = {
        brand: "AH Glutenvrij",
        property: [ProductPropertyFilter.GlutenFree, ProductPropertyFilter.Vegan]
    };
    const products = await ah.product().getProductsFromName("Brood", {
        filter,
        sort: ProductSortOptions.PriceAsc
    });

    const res = products.products.map((product) => {
        return product.title;
    });
    console.log(res);`

I only use this in react native so don't know if that could be a problem haha

Running this code does not seem to give any errors by just running it in node (LTS 16.17.0) for me. Did you try to stringify the [object Object] and see what it says? It could be an issue with React native, though that would be strange.


@Setup

Hello,
I have a base component A(no template , only ts) , with @Setup for inject my composable .
I have another component B extends my base component A  (with template), the @ Setup not working.
If i move @ Setup in my my component B , it's works.
@ Setup works only with toNative ?

I just bumped into this. My workaround for now is to declare @Setup twice. Once as private field (with _ prefix for the field name), and second as usual.
@Component({})
class PageWithTour {
  @Setup(() => useOnboarding()) private _onboarding!: ReturnType<typeof useOnboarding>;
   // ... use this._onboarding
}

@Component({})
class OfficeConfiguration extends PageWithTour {
  @Setup(() => useOnboarding()) onboarding!: ReturnType<typeof useOnboarding>;
   // ... use this.onboarding

Works fine for sharing Pinia stores. Alternatively I could setup the store on the layout and @Provide it all the way down for any interested component.


Application components not rendering correctly

Logging this last thing on a Friday in case I forget. I just noticed that the components in finder-frontend don't appear to be rendering properly in the component guide (see below), although they seem to be okay in the rest of the application.
I've only been able to test this locally as the live finder-frontend component guide isn't online at the moment.
e.g. the expander component:

@MartinJJones is this possibly related to the recent application.scss compiling work that we talked about recently?

@andysellick yes, this PR will fix this issue as well - https://github.com/alphagov/govuk_publishing_components/pull/3347

@MartinJJones just tested and yep, all fixed, great stuff.
Don't worry about the styling - it shouldn't be styled, and the message I think is clear enough.


Update Windows-VisualStudio.md

Added the location of the Embedded and IoT development tools option as I couldn't find it and spent ages looking!  Hopefully this will save someone else some time in the future.

Thank you! You've saved some poor future soul those same ages.

Thank you! You've saved some poor future soul those same ages.


Fix client error modal not showing in dev (HMR)

We normal show a error modal when there's an error on the code. (Detected via webpack HMR)
But this didn't work with beta.37
So, this PR fixes that.
In order to prevent future issues like this, now we've a test case too.

Thanks @arunoda


About the result of PyramidNet-110 baseline in the paper

In the paper (table 6), PyramidNet-110 without cutmix is reported to achieve 19.85% top1 error on CIFAR100. Since in the paper of PyramidNet, the error rate with the same setting (except that lr equals 0.5) only achieves 23.12%, I wonder how the result of 19.85% is achieved? Could you provide any example training code to get this result?
Thanks a lot!

After some experiments, it is found out that this basline here should use bottleneck as the block type, so that the model can reach the result. Right?


⚠ Mobitopup has degraded performance

In e41b839, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 3199 ms

Resolved: Mobitopup performance has improved in 31349a1.


SubViewport: transparent BG with SSR enabled results in blank texture

Godot version
v4.1.3
System information
Ubuntu 22.04.3 LTS
Issue description
Setting SSR enabled in a viewport with transparent background results in a blank texture. If only one is enabled (SSR or transparent background) everything works fine.

Steps to reproduce
Please check the screenshots above, or the attached reproduction project.
Minimal reproduction project
reflections-test.zip

Can confirm, experiencing this as well.

Thanks for the report! Consolidating in https://github.com/godotengine/godot/issues/73817.


Add external doc attribute to rustc

This RFC proposes an addition to be able to pull in documentation for items from
an external source at compile time, rather than requiring them to be in the
source code itself.
Rendered

An alternate syntax, which fits in more with how #[doc] gets used, could be #[doc(include = "foo.md")]

A few times, I've tried to use #[doc = include_str!("foo.md")], so I think include_doc might be a better name (or the include = "foo" syntax as suggested by https://github.com/rust-lang/rfcs/pull/1990#issuecomment-299272567). external makes it look related to extern fn IMHO.
Also, using #![attr] is far superior to adding a "mod" parameter.

I've updated the syntax and clarified the section about the Rust book in how we teach this.

I'm a fan of this general concept. I dislike having pages and pages of stuff inline, if nothing else, but also agree that there can be a lot of duplication between README.md etc.

Conclusion from the language team: generally quite favorable, but this should fall entirely within the purview of the doc and/or dev-tools teams, rather than lang.

cc @rust-lang/docs

A possible extension to this is also allowing links into a section of a file. I imagine that some people might want to have all docs outside of the code file, and having a separate doc file for every function seems tedious. (Whether we want to encourage such a style is a valid question). I imagine we could allow something like include = "foo.md#section" where section is a markdown title in foo.md - I assume there is some markdown standard for doing this.

A mostly lurker here throwing my thoughts...
Instead of adding an attribute to every item whose documentation is in a separate file, which is also sort of tedious, it could be implicit (or have an implicit default).  So:
// module level
#![doc(external = "mymod.md")]

// no doc comment: rustdoc would look for a section "function_foo" or "fn.foo" or something like that
// in mymod.md
fn foo() -> usize { .. }

// This one specifies a different file.
#[doc(external = "mymod_bar.md")]
fn bar() { .. }

I'm not sure about the value of allowing item documentations both inline and separately for the same module, except perhaps when half way through converting from one format to the other.
I would definitely want the missing_docs lint to still work, and if the implicit link I suggest were done I'd also want a lint against documenting the same thing twice.

@nrc I think that would be a good idea since putting a separate file for each item seems excessive and it might be nicer on a per module basis. Usually in markdown a section is denoted with something like # or ## you could even use the --- notation to split things up per section. I think maybe something like # for types and then ## for sub-types like enums or fields in a struct might be a good way to split things up.

Love this proposal. I've read it over twice and haven't thought of any issues. I'm particularly looking forward to deduplicating text/code shared on the top-level docs and the README.

I imagine we could allow something like include = "foo.md#section" where section is a markdown title in foo.md - I assume there is some markdown standard for doing this.

This RFC is currently documentation format agnostic and has no knowledge or opinions about the underlying markdown syntax. Right now, there's nothing technically stopping someone from creating a rustdoc-like alternative that uses a different documentation format for all their doc comments and rendering it appropriately. Assuming this is a deliberate design decision (of keeping markdown as the docs format and the Rust language separate), seems like we can't add markdown-specific features (headings).

@frewsxcv If we want to keep it format agnostic would there be a syntax we should approach to denote what goes where if this is implemented?

I don't really understand your question @mgattozzi, can you rephrase it? The proposal as written is documentation format agnostic, which I think is a good thing.

Ah my bad @frewsxcv. I guess I should have said what should we do about having multiple items in a file? @jugglerchris brings up a good point about not wanting to have to annotate things multiple times or having lots of files. If we do have multiple items in a file we need a way to tell the compiler how to split up the documentation.

We should punt on multiple items being documented in a single file for another RFC. Get this change accepted first, as it's minimal and any sectional solution can base itself on this. Avoid unnecessary scope creep.

That's a good point. I'd be fine with opening another RFC to discuss all these extra expansions after this RFC gets accepted.

We talked about this in the docs team today, and everyone is pretty favorable for this. There's just one concern though, and that's about the "implementation section". Right now, /// is sugar for #[doc], so it seems strange that we'd have #[doc(include)] be sugar for /// which is sugar for #[doc]. That shouldn't actually affect the RFC though.

That makes me wonder if #[doc = include_str!("foo.rs")] will "happen" to work in the near future.
cc @jseyfried

Alternately, it may be prudent to rephrase what it actually wants to do. For me specifically, the phrase "expand out ... at compile time" was what threw me off. Currently, rustdoc doesn't even completely "compile" crates to generate their documentation. It gets as far as an AST, and for any given item it checks for any #[doc] attributes. (The /// sugar is processed before this.) With this implementation in mind, it's possible to say that that's "compile time", but that wasn't my first impression, and it would be worth elaborating what's intended there.
Moreover, there's currently plans to rewrite rustdoc to use rls-analysis and the save-analysis data emitted from the compiler. That makes it a little clearer, since we could make sure to state that the file substitution occurs when that analysis data is saved, but it's still different from my first impression when I see "expanded at compile time".
Something else I thought of while considering the #[doc = include_str!("foo.md")] rabbit-hole: Where are paths in doc(include) attributes based? include! and friends base their paths starting from the directory that the file is in, but the RFC acts like they're based on the current-working-directory based on the time of compilation, i.e. the docs folder is sitting alongside src, rather than inside it. This should be specified in the RFC, or at least codified for the implementation.

In all, I'm very much in favor of the idea, and the syntax, but that implementation note is what tripped me up. Though to be honest, in writing up those first two paragraphs, I cleared up my own misconceptions about it, so maybe it's not as bad as I originally thought. >_>

We discussed this today in the dev-tools meeting (https://github.com/nrc/dev-tools-team/blob/master/minutes/meeting notes 2017-06-05.md). We generally approve of the RFC. We thought it was important to address https://github.com/rust-lang/rfcs/pull/1990#issuecomment-305323449 - this might be a good alternative to this RFC.
I would also like to think about longer term plans. Do we want to be able to link a section of a file to become documentation (e.g., doc="foo.rs#bar"). If so, that would be a mark against using include_str!. This question (in my mind) comes down to 'do we want to encourage out-of-line documentation?', i.e., separating docs from code. I think we probably do not, since it makes source code less readable.
Further, do we want to just facilitate including README.md into the head of a crate, or is there a more general problem here? Could Rustdoc do a better job of documenting crates with a facility like this? I'd love to hear use cases beyond README.md, even if they'd need quite advanced machinery in Rustdoc. (I don't think we should necessarily have a more general or complex RFC, but I would like to be sure we are heading in the right direction and not just adding a bandaid that will become obsolete in the long term).

Another use case I have for this is including lots of examples into a custom Derive crate. I just noticed that using this at the same time as normal doc comments isn't something explicitly covered in the RFC, but I'd like to include the basic details inline in lib.rs then include a big examples file showing all the attributes for customising the Derive. Something like:
//! An awesome derive crate
//!
//! # Basic Example
//!
//! ```
//! #[derive(Awesome)] struct Foo {}
//! ```
#![doc(include = "advanced_examples.md")]

I won't be able to update this tool the week after next so if people hash out any ideas or things like that here I can update this at a later date

With regards to the suggestion of using include_str! in doc attributes, procedural macros are free to treat tokens which look like a macro invocation however they like. It seems reasonable that built-in attributes treat macro uses by expanding them, and thus include_str! should work as suggested in https://github.com/rust-lang/rfcs/pull/1990#issuecomment-305323449. It will require some implementation work, but I don't think it needs a new RFC.
I'd like to propose we pursue that direction. Thoughts?

Sounds good to me!
On Thu, Jun 15, 2017 at 3:02 AM, Nick Cameron<EMAIL_ADDRESS>wrote:

With regards to the suggestion of using include_str! in doc attributes,
procedural macros are free to treat tokens which look like a macro
invocation however they like. It seems reasonable that built-in attributes
treat macro uses by expanding them, and thus include_str! should work as
suggested in #1990 (comment)
https://github.com/rust-lang/rfcs/pull/1990#issuecomment-305323449. It
will require some implementation work, but I don't think it needs a new RFC.
I'd like to propose we pursue that direction. Thoughts?
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rfcs/pull/1990#issuecomment-308647163, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABsit6rd5qhlocKh02ofHd9CTI-jO-mks5sENchgaJpZM4NRDZV
.

I'm all for it, but would that obviate the need for the syntax that's already in the RFC? Would we propose/allow both? I think having both syntaxes, that reach the same result via different methods, invites too much confusion and opportunity for worthless diversions with style preferences for one or the other. If we allow include_str! in doc attributes, that should be the syntax we promote. If we keep the #[doc(include)] syntax, then even if we allow include_str!, we should teach and promote doc(include) and keep include_str! as a curiosity for the reference and for people to discover by accident.

but would that obviate the need for the syntax that's already in the RFC?

I think it would and I'm proposing it as an alternative to the RFC syntax.

My fear with having the doc attribute internally expand macros is that this will not interact well with procedural macros that use the value from doc attributes. By my understanding of how it would work the procedural macro would see the unexpanded macro call in the doc attribute and have to either fail because it has no way to expand it, or do the work to expand it itself (which as far as I know is impossible with the current proc-macro API, not sure if it would be possible in the future). In some cases just copying the unexpanded macro call to the output would work, but not in all cases.
Is it possible that expansion of macros inside attributes could be done by the compiler before running procedural macros/attributes? It appears that the current syntax does not allow macros inside attributes, so this should be a backwards compatible addition. It would also extend the solution to any other macros/attributes that this could be useful for (can't think of any off the top of my head, but they must exist).

or do the work to expand it itself

the plan is for this to be very easy - there should be some expand API to do exactly this.

In some cases just copying the unexpanded macro call to the output would work, but not in all cases.

I think this should work in all cases, except where the 'outer' proc macro arranges the output so that it doesn't. I.e., it is predictable.

Is it possible that expansion of macros inside attributes could be done by the compiler before running procedural macros/attributes?

Not really. Expansion order is pretty complicated, this kind of tweak would have all sorts of effects on hygiene, etc. as well as adding complexity.

not sure if [expanding with proc-macro API] would be possible in the future

We plan on this being possible.

Is it possible that expansion of macros inside attributes could be done by the compiler before running procedural macros/attributes?

It's possible, but we'd like to avoid this since we want to make as few assumptions as possible about the structure of proc-macro inputs. We'd like to be able to give proc-macros raw token streams and expose APIs to parse attributes (maybe third party) and expand macros (needs to be built-in).
Note that there is already a similar issue for e.g. include!(concat!("my_file", ".rs")) -- the concat! needs to get expanded "early" for the include! to find the file.

@nrc Reading your comment (I wrote mine before seeing yours), I don't think expanding macros inside attributes would cause problems with hygiene, and we'll need the complexity anyway with the expand API.
I think the main issue is that we don't know what is a macro invocation yet in general since it's the proc-macro's job to interpret the input tokens.

I'd expect the way this would go is an expression would be parsed, then forcefully expanded (without matching on the expression, just passing it to a function), and only then expecting a string literal - there are a few builtin macros which work like this already, e.g. format!(concat!("{", "}"), 0).

@mgattozzi do you have thoughts about the alternative proposal in https://github.com/rust-lang/rfcs/pull/1990#issuecomment-305323449 ?
I'm not sure if this needs an RFC at all - I kind of expect this to Just Work, and making it so is an implementation issue. OTOH, it might be useful to update this RFC so we don't forget to make it work?

I've been meaning to update this @nrc so thanks for pinging me.
While include_str!() would work and all, I just feel that it's not the same as using the include syntax. include_str!() feels like "Hey because this is a proc macro this technically works" while using the include syntax is very much "This has one specific goal in mind". I feel like that syntax is more clear as to what we're trying to do.
As for how this works and other things I'll need to update the RFC (hopefully this week, but most likely next due to personal reasons), but I'm more in favor of the proposed syntax then the "Technically this works syntax". That being said, if people are in favor of inlcude_str!() then I'll rewrite the RFC that way but personally I'd rather just address the other concerns and keep include as is and let the include_str!() work as just a quirk in the language of how proc macros work.

I keep flip-flopping on this. #[doc=include_str!("file.md")] is a combination of Little Details that aren't readily available (doc comment de-sugaring, and the presence of include_str!()). #[doc(include="file.md")] still wants you to know about doc comment de-sugaring, but also looks purpose-built for the task, rather than just being a combination of elements that were already there. The former is what people already try when they realize they can "connect the dots", and feels like a "clever" solution in that sense.
I personally like the look of doc(include), since you don't have to consider what this weird-looking macro is doing in your attribute. I would consider include_str!() acceptable, with the caveat i gave up here about not wanting to introduce two alternate forms to create style arguments with. It just kinda feels like a "happy accident" rather than something that was actually considered for the purpose. Maybe if we agree on include_str!() as the real mechanism and start referencing it in documentation, that feeling would ebb some.

To compare the two proposed syntaxes:
Original syntax:
#[doc(include = "docs/example.md")]
fn my_func() {
    ...
}

include_str syntax:
#[doc = include_str!("docs/example.md")]
fn my_func() {
    ...
}

And to be clear, the expectation is that if we adopt the orginally syntax, then we get both since the include_str syntax should work in any case.
IMO, the include_str syntax does not look any more ad hoc than the orginal.

I'd expect the include_str!() to work regardless because it's a macro. However, it seems more like "I can do this because rust lets me with macros" and not "This is a feature explicitly built into rust for this purpose"

I agree with @QuietMisdreavus on the stylistic point about #[doc(include="...")] looking more attribute-like. I'd also be concerned that people might look at #[doc=include_str!("...")] and infer that macros work in more attribute contexts, which would be incorrect.
Regardless of syntax, would pointing to a missing or empty file cause the missing_docs lint to fire, or would it be a compile error?

We discussed this again at this week's dev-tools meeting. I was pretty much alone in preferring the include_str! syntax. The feeling was that it was a bit hacky feeling and we'd prefer the nicer syntax (even if that was simply a sugar for include_str!).
So, with that in mind, I propose we enter FCP with intention to merge.
@rfcbot fcp merge

I'm in favor of #[doc(include="...")]. You can find the minutes from the dev tools team meeting here.
One thing to consider: When this feature is available, we should review our best practices for adding docs to crates. For example: Do we want to add a docs/ directory and include the files as module-level docs? (I'm not proposing that here; just want to note that we should talk about that.)
@rfcbot reviewed

I'm also in favor of #[doc(include="...")].
@rfcbot reviewed

I'll need to update the RFC then to fix the /// expanding in the text.

@rfcbot reviewed
Scrolling up a little, i don't think we addressed this comment directly:

Regardless of syntax, would pointing to a missing or empty file cause the missing_docs lint to fire, or would it be a compile error?

My assumption would be that it would be just like include_str! and friends: If the file doesn't exist, it's a compile error.

@QuietMisdreavus I would think so to, since this would mean the user intended to include a file, however, it wasn't there. A hard error would be better suited than a warning.

@rfcbot reviewed

@rfcbot reviewed

@rfcbot reviewed

One thing I didn't see mentioned: is there any functionality for file-relative includes? I could see some wanting to structure the extra documentation with the given file, rather than in a separate crate-root tree.
And since by default the path is really something absolute from the crate root, it might be much clearer to have some

(on mobile and hit enter accidentally)
.. have some prefix / something to convey the fact that the path is not currently file relative as I would first expect.
One big benefit of allowing current file relative paths is that you don't have to go in and change all of these paths during a refactor or code move, and makes files less coupled to the folder hierarchy, if wanted.

I'd made a comment about that early on, but it seems to have been passed up when the include_str!() suggestion came up. My assumption, since we're now thinking of #[doc(include)] in terms of #[doc = include_str!()], is that they would all be file-relative paths, since that's how include!() and friends work now. Since the crate uses a docs/ folder in its examples, it could be seen as making that folder in the crate root, but it could also work if it were relative to the file. Regardless, it would be prudent to make sure this is codified one way or another.

I would think relative to the crate root would be the best way to do it. That's what I had in mind when writing this (if not clearly spelt out). Would there be a reason to not make it relative to the crate root?

I'm fine with either file-relative or crate-relative being the default, but I think it would be good to at least have an option for file-relative. The benefits I see:

When you have a large source tree. Move refactors won't require mucking with documentation paths.
Avoiding tight coupling to the directory hierarchy.
More flexibility for file structures. File-relative paths are dependent on directory/file layout. Crate-relative paths are dependent on crate layout / compilation structure. The former can be more flexible/usable in a complex build system.

It might be as simple as using the dot notation for file relative:
crate root: "docs/foo.rs"
file relative: "./foo_docs.rs"
Or using a prefix for crate root:
crate root: "[crate]/docs/foo.rs"
file relative: "foo_docs.rs"

@rfcbot concern Where paths are based

I've been informed that registering concerns with rfcbot only works before the FCP. One concern that was brought up in today's dev-tools meeting was about what happens with crate-root-relative paths if someone's calling rustdoc directly without using Cargo. The concept of "the folder where the crate is based" is mainly a Cargo concept, and even then it's mainly in terms of "where Cargo.toml is". All rustdoc sees is the lib.rs (or whatever the file representing the crate root is named) file itself, so we'd have to either default to the directory where rustdoc is called, or the folder where the root file being handed to rustdoc is.

We should resolve the path base issue before merging.
It seems that a path relative to the 'crate root' is favoured, rather than relative to the file (the latter is used for include_str!, which is a mark in favour, but that seems mostly due to history and backwards compatibility - it doesn't seem a great choice (and is unhygienic with macros as well, which is just bad)).
The question then is what 'relative to crate root means'. As far as the compiler is concerned the crate root is where lib.rs is located (the src directory of a Cargo project). However, a use case mentioned here is referring to files in the docs directory, and some comments suggest being relative to the whole Cargo project.
So I see a few options:

relative to the src directory, referring to a doc would need ../docs/foo.md.
compiler takes a doc_root argument which when building using Cargo would point to the top of the workspace, so referring to a doc would be docs/foo.md
re-purpose some other argument to the compiler or env var
use src/.. as the root, i.e., the directory outside lib.rs (I do not like this, it would go wrong if compiling a Rust file in /, for example).

Preferences?

I prefer the doc_root option. I think that having to type .. in the common case is undesirable.

Would doc_root defaulting to docs as the default and having it be configurable as an option in Cargo.toml be an option?

If we go to the lengths to offer a doc_root flag, i vote we go one step further with Cargo and default it to docs/ to begin with. Cargo already uses specially-named subfolders of the project root for other purposes, so why not just add another? Make it a Cargo.toml option, too.
(Spent too long writing this, got sniped by @mgattozzi >_>)

If we default to the docs directory, including README.md in lib.rs will require going up a directory: #![doc(include = "../README.md")]

Could there maybe be a simple differentiation?
#![doc(include = "README.md")]
#![doc(include_sibling = "mod_tutorial.md")]

@phaylon something like include and include_relative where include defaults to doc and include_relative is relative to the crate root?

@mgattozzi I'd thought more like one that is relative to the current module, and one relative to the crate root. So you'd have one version for things that belong to a module (like a mymod_examples.md) and one for things belonging to the crate (README, "You shouldn't directly use this type"-kind templates and such).

The final comment period is now complete.

Going to try and resolve the doc root issue before merging.
I'd be wary of having multiple doc(include) variants - feels like unpleasant complexity.
I would also caution against file-relative paths since there are no good answers there with respect to macro hygiene.
Good options seem to me:

No doc_root argument, path is relative to the src directory (use ../README.md).
Rustdoc (clarification - rustdoc, not the compiler as I previously mentioned, correct?) takes a doc_root argument. If there is no doc_root:

use src as base
use docs as base (I worry that for non-Cargo users, this might cause issues)

I prefer the first option since it is the simplest and most conservative - we can always add doc_root later.
@mgattozzi @rust-lang/dev-tools @rust-lang/docs - thoughts?

@nrc I've honestly never seen someone put Markdown files in the src tree. They appear at the top level, or in documentation directories.

@joshtriplett I have done that for some crates. I find it useful as it maps well with the concept a rust module equals a directory where both its tests and its documentation lives.
You don't end up needing an external tool to do the mapping between the module and the doc for you.
Finding the doc of a module with src as base is dead simple. On github or similar it is even rendered for you.

Note that cargo-external-doc uses a doc/ directory at the top. I would personally rather see it be relative to the Cargo.toml (or maybe what cwd is for rustc).

There's also the include! macro which is relative to the current file's directory. That would also be consistent there (to me).

@Nemikolh If we're going to recommend that, then we'd need to document and talk about it more.

Firstly, does this compose? Can i write:
/// A brief description useful for someone browsing the code.
///
#[doc(include = "docs/a_long_winded_example.md")]
fn my_func() {
  // Hidden implementation
}

And how about:
#[doc(include = "docs/generic_boilerplate.md")]
#[doc(include = "docs/specific_details.md")]
fn my_func() {
  // Hidden implementation
}

?
Secondly, if this is something that only affects the documentation, it seems mildly weird to make it a language-level attribute. Wouldn't it make more sense to make includes something you do inside the documentation text? Like (pre-bikeshedding):
/// A brief description useful for someone browsing the code.
///
/// #include "docs/a_long_winded_example.md"
fn my_func() {
  // Hidden implementation
}

Thirdly, andt tangentially, is documentation always Markdown? Can (or could) it ever be AsciiDoc?

Firstly, does this compose? Can i write:

As far as I know, it should, given that this is already true with /// and #[doc] comments, thanks to the collapse-docs pass.

, if this is something that only affects the documentation, it seems mildly weird to make it a language-level attribute.

The doc comment itself is already a language-level attribute that affects docs, and has tons of options: https://doc.rust-lang.org/nightly/rustdoc/the-doc-attribute.html
Doc comments are even syntax in the language, that's more than just an attribute 😄

Thirdly, andt tangentially, is documentation always Markdown? Can (or could) it ever be AsciiDoc?

You could write something other than Markdown, but you'd need to use some other tool than Rustdoc to generate it. That is, the language treats doc comments as free-form text, but Rustdoc only supports Markdown.

Thanks, @steveklabnik. I suppose if the RFC for tool-specific attributes had gone through years ago, we would be writing #[rustdoc::doc] now, and this is just the best we could do at the time. And we'd have some sort of comment-ish syntax for cramming bulk text into arbitrary attributes ...
Shame about AsciiDoc. Markdown is the MySQL of lightweight markup languages!

Markdown is the MySQL of lightweight markup languages!

This is not particularly constructive.
We did have a very long, involved discussion about Markdown well before 1.0; there's a lot of tradeoffs here, and this is the way we chose.

I've honestly never seen someone put Markdown files in the src tree

@joshtriplett it is not uncommon to have README.md in nested directories - the compiler does this, for example, and GitHub encourages it by rendering the readme for the directory view.

We discussed this in the dev-tools meeting today. We decided it would probably be best to start with just a default path (no doc_root arg) and be relative to src.
@mgattozzi could you make that change (and any others needed from the comment thread) and then I can merge this and pretend we got in before the impl period deadline. Thanks!

@nrc I will make the change tonight and push the change and ping you when it's done.

@nrc I've made final updates to the RFC.
Changes include:

Relative path design
Proper expansion of include
Questions regarding best practices for docs as brought up by @killercup
Addressing the ability to expand paths to different types in future rfcs
What to do when paths or files are invalid

I think this should cover everything that was talked about and decided upon during FCP.

@QuietMisdreavus it was actually two words 😅

Small typo: the link in "Motivation" section under the first item ends with /issues.81 instead of /issues/81, resulting in a blank page. (Correct link)

Put in a fix thanks @behnam

Thanks for putting this together, @mgattozzi! It's a great move forward for crate docs!
One question about the language of the RFC: Under "Motivation", there's the third item talking about documentation localization and the need to be able to have multiple languages supported for the text side of documentations. But, there's no mention of this item in the rest of the RFC (or here on this thread) and I don't see how any decisions in the solution is based on the localization motivation.
Maybe there was some more features in earlier version of the RFC that has been dropped out since you wrote the motivation?

@behnam First off thank you! :D There wasn't anything you missed. I was using it as a motivator for as to why this feature would be justified, but using it for localization seemed outside the scope of the spec. You should be able to do this with cfg flags. For instance:
Let's say you had a file with a doc comment one in Japanese and one in English. You also have a config attribute you can use called lang.
The text of the English file in docs/struct-en.md is:
This is is a struct
and in the Japanese file under docs/struct-ja.md:
これはストルクトだ
(I took some liberties here with making struct a loan word in katakana so forgive me if this is incorrect)
Now let's say this is your code:
#[cfg(lang = "EN")]
#[doc(include = "../docs/struct-en.md")]
#[cfg(lang = "JA")]
#[doc(include = "../docs/struct-ja.md")]
pub struct ThisStruct;

Then it should compile with the correct comments depending on what lang is set too.
I didn't include all this because the RFC was about adding the include feature, not necessarily how it should be used. I gave it as possible reason as to why someone might want this, making it easier to have docs written separately but still included based off the language preference.
Does that answer you question at all @benham?

(psst, you would use #[cfg_attr(lang = "EN", doc(include = "../docs/struct-en.md"))] but yeah, basically that >_>)

@QuietMisdreavus I was unsure as I was just banging this out. Thanks for the clarification :D

Thanks, @mgattozzi. Yes, it's clear now. A couple of suggestions then:

Maybe you can put something along these lines in some informative sections of the RFC text itself, to keep it more self-sufficient?

Since one of the motivations of putting pieces of documents in external files is to be able to support multiple languages, I think it still remains an open question how to do so more efficiently, specially for internal documentations. In other words, something like the example below still needs some love to be practical, IMHO. Maybe you want to add something about this to the "Unresolved questions" section?

#[cfg_attr(lang = "en", doc("This is a struct to do blah blah blah."))]
#[cfg_attr(lang = "jp", doc("これはストルクトだ"))]
#[cfg_attr(lang = "fa", doc("این یک ساختار است برای فلان و بهمان."))]
pub struct ThisStruct;

By the way, is there any discussion for rustdoc's support for multiple languages?
The solution proposed here is kind of in contradiction with the solution suggested here, and may be a bit in conflict: https://internals.rust-lang.org/t/pre-rfc-localization-for-rustdoc/3190
There's also mentions of localization support for rustdoc here, with no details, though: https://github.com/rust-community/team/issues/178

@behnam now that the RFC is accepted I don't think it can be changed beyond little fixes for typos. I could be wrong but generally for history sake things shouldn't be changed as what was accepted was the text above.
There was talk about localizing error messages here but nothing definite. The pre-rfc you mentioned was from Feb of last year. This hadn't begun to be written until shortly after RustFest in Kiev after having discussed it with a few people after the conference. Looks like there was a pre-rfc over on the community repo from the localisation team, but nothing since Aug 16th. According to the this issue any kind of localisation for error messages would require an RFC. I haven't seen any yet, but now that this is accepted it could easily be used as the basis for another RFC focusing on that.
As for current rustdoc I don't see anything there. Nor on the new version that I'm helping work on during the impl period. Any major changes like this would require an RFC if it's to be used for current official Rust projects as these are pretty big changes the maintainer teams will be stuck with, including updating translations of docs.

Uh, I didn't notice that this PR is closed! The labels still say "final-comment-period" and "S-waiting-on-community-feedback". I suppose it's enough to have this conversation here for the record then. Thanks anyway! :smile:

(clarified in the rfc PR body, usually they link to the tracking issue iirc)

Hahaha okay this makes a bit more sense @behnam. I definitely would love to see a localisation PR at some point for sure. I think it would be an huge gain!

Is this actually working? Or not yet/only on @QuietMisdreavus's fork?

@chriskrycho As https://github.com/rust-lang/rust/pull/44781 is not yet merged, "official" rustdoc does not yet have this feature. If you'd like, you can check out my branch, build it, and try it out, but until that PR is merged that's the only way to try it out.

Will doctests within external files still work?

Yes, anything loaded in the external file is treated the same as if it were written inline.
(Please note that farther discussion of the feature - especially the implementation - should happen on the rust-lang/rust tracking issue. >_>)

Thanks! Sorry for asking in the wrong place!


[CLOSED] Publishing script republishes CMA cases correctly.

 Issue by kalleth
Tuesday 01 July 2014 at 10:09 GMT
Originally opened as https://github.com/alphagov/specialist-publisher/pull/151

To prepare for republishing multiple types of document (other than just
specialist documents) we needed to fix the republishing script to both
operate without errors and to correctly notify the right set of
observers.
The eventual aim is to provide a two-level array of repositories and
the listeners that should be notified which will then perform
republishing for all types of documents.

kalleth included the following code: https://github.com/alphagov/specialist-publisher/pull/151/commits

 Comment by bestie
Tuesday 01 July 2014 at 10:57 GMT

This is all good and I love that you've got rid of SpecialistDocument#published_version but there is a bit more code in the model and tests to delete to remove it cleanly.

 Comment by kalleth
Tuesday 01 July 2014 at 16:43 GMT

@evilstreak I've actioned your previous comments (which have disappeared as they were on the revision).
It'll now raise if there's more than one published edition -- with yesterdays preview dataset this doesn't result in any more documents failing to republish, but it's nice to have there as a guard for the data in future.
I've also swapped title for slug and swapped to using the bare document for logging purposes so we can bomb earlier and still have the information accessible to the logging method.

 Comment by bestie
Tuesday 01 July 2014 at 13:02 GMT

@evilstreak fixed now, must have committed a typo after I ran the tests.


If an imported file is not found request never ends

If an imported file doesn't exist the site is not able to load the stylesheet and stays waiting indefinitely.
There are no notifications in console.

When node-sass fails, success is not called, so this code is not executed and load never ends.
res.writeHead(200, {
	'Content-Type': 'text/css',
	'Cache-Control': 'max-age=0'
});
res.end(result.css);

Instead of that, node-sass calls error.
I'm thinking of supporting the node-sass error block and improve debug mode killing #22 in the way.

Great work @Bumxu. :+1:
Actually node-sass-middleware haven't been updated in a while to catchup with changes made in node-sass.
The generic syntax is in v2.0.1 is:
var options = {
  data: 's { a: ss }',
  file: 'path/to/my.scss',
  success: function(result) { },
  error: function(err) { }
};

require('node-sass').render(options);

Starting with v2.1, the above syntax will work but deprecated in favour of node style callbacks:
var options = {
  data: 's { a: ss }',
  file: 'path/to/my.scss'
};

require('node-sass').render(options, function(err, result) { });

Good approach!
So better wait for 2.1...
Thanks :)

this would be good to commit I have the same issue when I use @import

I would also like this

And.... node-sass v3 is here! :D
Can we already play with this?

Yup, but couple of major changes would need to be made (as v3 has most breaking changes made till date).
I will see if I get time to pull it off over the weekend. Otherwise, anyone can start a PR (/cc @iMoritz @jerone) and I will help knitting all pieces together. node-sass Readme and v3-alpha to v3-stable (https://github.com/sass/node-sass/releases/tag/v3.0.0) docs would most probably help in upgrade process. For reference, see the v2-v3 upgrade diff for grunt-sass: https://github.com/sindresorhus/grunt-sass/pull/200/files.
@iMoritz, would be a treat if we get #37 in middleware's vNext as well (before or after v3 changes, doesn't matter; as it will probably require equal amount of effort)

@am11 commented on 6 mei 2015 23:06 CEST:

[...] Otherwise, anyone can start a PR [...]

I'm sorry, I have moved on to other projects.

I just implemented node-sass v3 support in my fork: https://github.com/iMoritz/node-sass-middleware/commit/1ea16c12e75a3d85487ea12d2c10c6463425b6e5
@am11
Just waiting for #40 to get merged because my v3 support is built on top of it
I will go on #37 after node-sass v3 is implemented

A few remarks:

Option imagePath is no longer supported by node-sass and libsass.
Maybe error handling should use err.file when available (distinct of null or "stdin"), and format output expecting more than one line (backtrace).

See bumxu@ddd0ec1b83899c8d01c3938f14b7598549e7dcb1 for details.

@iMoritz, @bumxu, thank you guys for showing interest. Feel free to start a new PR. You guys can collaborate in a single PR (one of you will need to cherrypick other's commits).
@bumxu, this is true. There are couple of options obsoleted. This would require revamping most of the middleware code (both middleware.js and test/).

Maybe in case of compilation error, it would be more correct to call error function (that I deleted by mistake), and therefore to next(err) instead of end connection with 500.
What do you think? :confused:


Dry run fallback should return non-zero

If a user doesn't run the client with elevated permissions we fall back to dry run mode. In this case we should probably return a non-zero exit code.

Addressed via the hotfix #14


Samba icons missing

hi i have the taskbar folder located on samba server when i create shortcuts from samba server icons are always missing and there is no option to pin to taskbar , can anyone please help

Can you check the release here: https://github.com/PikeNote/taskbar-groups-pike-beta/releases?

Can you check the release here: https://github.com/PikeNote/taskbar-groups-pike-beta/releases? If the issue is not resolved, open an issue on that repo.

sir still no pin to taskbar option

Is that Windows 11? It may be because that option was moved. Can you still drag it into the taskbar as usual?


Getting same push notification multiple times at the same time (3)

After subscribing to folders,
I am getting multiple push notifications at the same time i.e., just the same notification is being pushed thrice why is this,
Or am I not returning status properly??

Please reactivate if you're still seeing this.


Add optional logging

This adds support for clients to pass in
a configured logger object to get warning
logs on retries, and debug logs in general
when downloading.
The default logger is a no-op logger, so
default behavior remains unchanged.

I don't have a container set up for CDSETool so I have not tested the regular cli or the NoopLogger, I would appreciate some help with testing that.
The library path with a logger passed in to download_feature has been tested by downloading ~1500 products without issues.

Thank you for yet another great contribution.
I will check out your branch and add some tests for NoopLogger :+1: