NSNib issues

I have some issues with the NSNib interface. My preferred solution would be API-breaking, which may be OK because the project is still pre-v1:

NSNib_Init - This uses a specific init method, so IMO it should be named something like NSNib_InitWithName
I'd like to add a wrapper for init from NSData, e.g. NSNib_InitWithData
InstantiateWithOwner discards the return value. instantiateNibWithOwner:topLevelObjects: can return false - that should be passed to the caller as a boolean.
instantiateNibWithOwner:topLevelObjects: is deprecated in favor of instantiateWithOwner:topLevelObjects:. The difference is that the latter requires the caller to retain any objects they are interested in. If I understand correctly, retaining a reference to the nib, the array, or a given object is sufficient to keep the object from being deallocated.

I'm happy to open a PR with these changes.
The readme says "1:1 mapping of API names with Objective-C APIs", and it sounds like the eventual goal is to use a generator. In that case, shouldn't the Go function names match the Objective-C method names?

yea in some cases there is just a bare *_Init() from trying out conventions that might work for code generation, but in this case it might not map to anything real or useful or conventional. I don't think any of your suggestion is API breaking? PR away, just document any new kinds of translations to Go in the API so we can be sure to work them into generation.

Renaming NSNib_Init to NSNib_InitWithName would be a backwards-incompatible change, as would be adding a return value to (*NSNib).InstantiateWithOwner, as it changes the method signature.

PR away, just document any new kinds of translations to Go in the API so we can be sure to work them into generation.

I'm not sure what you mean. I was planning on making changes in cocoa/NSNib.go.

My first thought if you wanted to not make breaking changes would be not to change NSNib_Init but just add NSNib_InitWithName, so I assumed you could just do that. Regardless, not concerned about making breaking changes right now. There are versioned releases and it's pre-1.0. Especially if it's making it more in line with the actual Cocoa APIs.
Re documenting, all I'm saying is if you end up changing the API to be more helpful in Go, to point that out and discuss. Like for example at some point we decided to try to return strings instead of NSString pointers. That way we can work those conventions into the code generation. Tell me if I can be more clear.


Create 1512-Number-Of-Good-Pairs.cpp

File(s) Modified: 1512-Number-Of-Good-Pairs
Language(s) Used: C++
Submission URL: _https://leetcode.com/submissions/detail/770493888/_

Thanks, @Vitali-Matteo!


Scale stack divider

Overview

Adds a simple chart.js plugin that draws a divider between scales
Adds a custom "medication" scale type that adds a bit of extra padding at the top. This was needed to prevent label from getting covered by the divider. I wish there was a simpler solution for this.

How it was tested

Ran showcase app and added multiple layers with both observations and medications in different combinations.
Tested with medications at both top and bottom of the chart.
Tested different browser window sizes.

Checklist

[x] The title contains a short meaningful summary
[ ] I have added a link to this PR in the Jira issue
[x] I have described how this was tested
[ ] I have included screen shots for changes that affect the user interface
[ ] I have updated unit tests
[ ] I have run unit tests locally
[ ] I have updated documentation (including README)


message_list_tooltips: Convert module to TypeScript.

There are 3 instances where the upstream tippyjs type has conflicted with local function parameter type. I have type-assert ed those variables/parameters but am looking for some advice if we can handle it differently.

@LaPulgaaa can you post an update on this? I think some of the comments above may not require action, but at least
https://github.com/zulip/zulip/pull/29335#discussion_r1529522986 seems to suggest you intend to make a change. Would be nice to integrate this.

Apologies for any delay. I have added a prep commit and dropped a comment addressing #29335(comment)

The test failure is an operational issue: https://chat.zulip.org/#narrow/stream/43-automated-testing/topic/debian.2012.20gpg.20failures/near/1764206
Merged, after squashing the linter-fixup commit and the small tweak noted above, thanks @LaPulgaaa!


do not use master for github actions

Codecov Report

Merging #1101 (7cc4717) into master (7f7908c) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files
@@            Coverage Diff            @@
##            master     #1101   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           36        36
  Lines         2450      2450
=========================================
  Hits          2450      2450


Camel 4.5 - Trace config

Describe the feature here
The backlog tracer has its configuration moved into its own group like the debug already have
https://issues.apache.org/jira/browse/CAMEL-20472
Its probably easier to see what we did for CSB to learn what may need to be done in CEQ
https://github.com/apache/camel-spring-boot/commit/3e8de47443debcf6c1372f53312961fbd6e0be37
There is a DebugConfig.java in CEQ today, so maybe a TraceConfig.java needs to be created. As trace is very similar to how debug config is.

@davsclaus please take a look at the PR and I wonder if there is any way to test with these trace configuration?

use null instead of empty string. For testing them I am afraid you can only test like its tested in the core project. But generally its not really needed as core tests the tracing functionality, and CEQ is just a facade on setting the options.


Splitted the patch for merging RTCSEL in an individual file

See Missing patch for stm32f446 (#17).
I think this is correct but I can't get to generate the rs files : make svd2rust -j8; ls stm32f4/src outputs :
.rw-rw-r--  1,4k 24 mai   14:11 lib.rs
.rw-rw-r--     0  24 mai   14:17 stm32f401.rs
.rw-rw-r--     0  24 mai   14:17 stm32f405.rs
.rw-rw-r--     0  24 mai   14:17 stm32f407.rs
.rw-rw-r--     0  24 mai   14:17 stm32f410.rs
.rw-rw-r--     0  24 mai   14:17 stm32f411.rs
.rw-rw-r--     0  24 mai   14:17 stm32f412.rs
.rw-rw-r--     0  24 mai   14:17 stm32f413.rs
.rw-rw-r--     0  24 mai   14:17 stm32f427.rs
.rw-rw-r--     0  24 mai   14:17 stm32f429.rs
.rw-rw-r--     0  24 mai   14:17 stm32f446.rs
.rw-rw-r--     0  24 mai   14:17 stm32f469.rs

Can you take a look at this please :smile:
I have a few projects downstream that need this PR to be merged :smile:

Ah yep sorry, I missed this the first time. I'll check it out this evening.

Can you update the stm32f4 crate on crates.io, please ?
I can't find a way to use git to access the latest modifications...

Yep, I was about to do that now!
For reference you should be able to use the dependency from git like:
[dependencies.stm32f4]
git = "https://github.com/adamgreig/stm32-rs"

but, it looks like that errors out on the build script now, so I'll try to fix that and then release a new version to crates.io.

(also please note that the new version being released will be using the latest svd2rust 0.13.1 which is a breaking change for downstream crates)

Done, 0.2.0 is now on https://crates.io/crates/stm32f4.


Mezzanine template tag "translate_url"

Hello,
When I try on homepage to choose a language,i get in end of url double slashes. So, original example.com/en and then example.com/fr///
I use templatetag "translate_url" to choose another language.
How can i fix it?
Thanks.

That happens only  when I use HOMEPAGE AS AN EDITABLE PAGE IN THE PAGE TREE.
Bug???

With this solution I can not switch language on my homepage!


⚠ SpeakUpConference.com has degraded performance

In 948e2f0, SpeakUpConference.com (https://www.speakupconference.com) experienced degraded performance:

HTTP code: 200
Response time: 12585 ms

Resolved: SpeakUpConference.com performance has improved in 169acb2 after 11 minutes.


Adding bot to active directory

To achieve proactive messaging (starting conversation) on teams in a single tenancy without having user first message the bot are there any work arounds? Is it possible to add bot to active directory and for all intents and purpose be a user and can be messaged and message others?
Is the unique user id generated by the Bot Adapter or is it generated by Teams as part of the message post to the bot. If its the former would it be possible to pass on a request  to a single bot to other adapters to get the unique user id for other bots, achieving ability to create conversations proactively for all bots within a tenancy by first messaging one bot?

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

ID: ba8d3979-14f5-3105-ad89-ce6f98d11df1
Version Independent ID: e53a7d1e-0e70-ca30-9809-fda7ebe5f4da
Content: Proactive messages - Teams
Content Source: msteams-platform/concepts/bots/bot-conversations/bots-conv-proactive.md
Product: msteams
GitHub Login: @o365devx
Microsoft Alias: o365devx

Currently, only workaround is to create a Team with all users.
User's uniqueId differs from Bot to Bot. You can not use same id to send proactive message from another bot.

@Wajeed-msft  I understand number 2. Let me rephrase the question, how is that uniqueId generated? If my organization has multiple bots could I design a middleware that passes the message activity to the other bots to get the user ids effectively "registering" a  userid with all the bots once it any single bot is messaged for the first time

Exactly! Good Question is, how to create, wich is the algoritm to create those TeamsUsersId isolated.

The algorithm is a one-way hash for privacy reasons, so we have no plans to expose it.


Implement requirejs path * configuration

I am using the require.config.path list to map module names to filenames. When the project uses module names as well as file names madge cant find circular dependencies very well.
This change rewrites all found module names in the tree to the filename. Currently it is doing that for map["*"]
example:
require.config({
    baseUrl : 'js',
    map:{
         "*":{
            "moduleName":"util/blah/moduleName"
        }
    }
});

Thanks for your contribution but I'm closing this since the RequireJS related features has been rewritten from scratch in the upcoming 1.0 release of Madge.

Btw, that rewrite includes this feature and will ship with madge 1.0


SD/TF Card Filesystem

What Filesystem should be used?
I'm using a 2GB SD-Card and I tried a few different ones, but i couldn't get it to work.
I always get an error from the fs demo:

...
Get FS T Flash device info fail!
T Flash used:0 Bytes, total size:0 Bytes(0.000 MB)
...
Start Fs  TF card read write test!
Open file failed:-1

Standard FAT32 should be fine. There are power issues driving the SDCard as the board powers up GRPS though: https://github.com/Ai-Thinker-Open/GPRS_C_SDK/issues/421 so if you're getting  intermittent errors try 1. making sure to have enough good power and/or 2. power cycling the board (not just resetting it).

Hi, thanks so much for the help so far!
I looked at #421 (and #457 ), but I don't have the problem that it "sometimes" doesn't mount, it never works/worked ;(
I always power cycle it between tests.
I supply the pudding board with my bench PSU (has a 5A current capability) at the VBAT-Pins.
(I also looked if I have some fitting caps, but no luck so far, i may need to order some LOW ESR ones tomorrow)
I tried FAT32 with allocation unit sizes of 4096 or 512 bytes, both not working (i formated the sd-card via windows).
On another note: does someone know why the altitude is 0.00000 in the GPS example?

Hi all,
I have same problem. The SD card is not mounted at all even I tried as many as possible FAT versions. Can someone help here?
Thank you

Same problem. tried different cards


Unnamed bit-fields and alignment

r? @pepyakin or @emilio

Looks great!
@bors-servo r+

:pushpin: Commit e17bd8d has been approved by pepyakin

:hourglass: Testing commit e17bd8df3fbd686fa0857b2e09d6e38c9fb6262c with merge ddb680b27db6581070b7b4fb03ea1119167a0bd3...

:sunny: Test successful - status-travis
Approved by: pepyakin
Pushing ddb680b27db6581070b7b4fb03ea1119167a0bd3 to master...

Thanks for review :)


Unable to see the details on the BTC transfer summary screen

v6.20.0
The stars are manually added using chrome devTools to hide the address
https://github.com/leather-wallet/extension/assets/22010816/5a936241-d848-4c72-ac15-0f5a200e6399

I think this has been solved in https://github.com/leather-io/extension/pull/5778
https://github.com/user-attachments/assets/49427174-aa60-4429-9d34-89e93becfea7
It's unclear if this is a re-sized large window or else a popup window but I think it's solved


upgrade maven wrapper to latest version

What is the purpose of the change
Upgrade maven wrapper version to latest version 3.5.2
Brief changelog
Modify wrapper configuration file to use new version

Thanks for your contribution. But we have decided to remove maven wrapper from dubbo.


Sequentialrecsys

Description

We provide 4 sequential models in this update for deeprec, namely ASVD (non-sequential, just to compare with), GRU4Rec (RNN based sequential model), Caser (CNN based sequential model), and SLi-Rec (time-aware RNN base sequential model, published in IJCAI'19 by MSRA).
We provide a jupyter notebook in quick_start.
We use a public dataset, Amazon review dataset, for demonstration. In the quick start notebook, the script will automatically download the dataset, so there is no need for us to host the dataset.
We provide unit test and smoke test for sequential models.

Sequential recommenders is a type of recommender models with increasing importance.  In this update, we aim to enable the repo with sequential recommender models.
Related Issues

Checklist:

[x] I have followed the contribution guidelines and code style for this project.
[x] I have added tests covering my contributions.
 After this is merged, I'll start working on the 4 deep dives https://github.com/microsoft/recommenders/issues/1013

@Leavingseason, feel free to merge when you think it is finished. After this is merged, I'll start working on the 4 deep dives #1013

Unfortunately I an not authorized to merge this pull request...  @yueguoguo @anargyri @gramhagen  do you have any comments?


scale penalty with samples

This is a first attempt at #108.
There are quite a few docstrings that still need to be adjusted.
@tlienart can you have a look at the RidgeRegression docstring for an example how I intended to adjust them?

Apologies for the late reply, with family duties around the holidays I didn't have much time to look into this.
This looks great, thank you very much. One small note is that we could add a function get_penalty_scale(glr, n) which would return glr.penalty * ifelse(glr.scale_penalty_with_samples, float(n), 1.0), that might be a bit less clunky in the code but it's essentially aesthetics. I can do that later.
I'm otherwise happy with this as it is, thanks!

Codecov Report

Merging #109 (a81bb81) into dev (add2984) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

:exclamation: Current head a81bb81 differs from pull request most recent head ab6a5d1. Consider uploading reports for the commit ab6a5d1 to get more accurate results

@@            Coverage Diff             @@
##              dev     #109      +/-   ##
==========================================
- Coverage   94.83%   94.82%   -0.02%
==========================================
  Files          20       20
  Lines         852      850       -2
==========================================
- Hits          808      806       -2
  Misses         44       44

Impacted Files
Coverage Δ

src/fit/iwls.jl
100.00% <ø> (ø)

src/glr/constructors.jl
100.00% <ø> (ø)

src/mlj/classifiers.jl
50.00% <ø> (ø)

src/mlj/regressors.jl
6.66% <ø> (ø)

src/fit/analytical.jl
100.00% <100.00%> (ø)

src/glr/d_l2loss.jl
100.00% <100.00%> (ø)

src/glr/d_logistic.jl
100.00% <100.00%> (ø)

src/glr/d_robust.jl
100.00% <100.00%> (ø)

src/glr/utils.jl
90.90% <100.00%> (-0.76%)
:arrow_down:

Continue to review full report at Codecov.

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

Thanks for the feedback! I use a get_penalty_scale function now and fixed the docstrings.
By the way, when I started working on this PR I considered for a moment an alternative implementation with a wrapper
struct AverageLoss{L} <: Loss
    loss::L
end

(al::AverageLoss)(x::AVR, y::AVR) = al.loss(x, y)/length(y)

I found this pretty neat, but it would have required some major refactoring, mostly because of the parametric dispatch on glr for _solver, _fit etc. Are all these type restrictions really needed? Or could one get rid of them, maybe with a few traits?
But I am also fine with the current implementation. Please feel free to merge whenever you feel this PR is ready.

I think the CI failure with Julia1 is due to MLJBase changes. The easiest is probably to just put the minimum Julia version for MLJLinearModels 0.6 to 1.5.

Thanks a lot @jbrea for this!
With respect to AverageLoss, this sounds great and happy to help you with the refactoring if you need any help there.


Next.config.js resolve.modules not working to resolve module

I'm looking for a simple way to link up a few directories that are in the root of my project to use as paths for webpack to resolve modules. That is, import Button from 'components/Button' without all of the ../.. directory hops. I believe that either of these would do that...
module.exports = config => {
  config.resolve.modules = [
    __dirname,
    'node_modules'
  ]
  return config
}

or with alias...
module.exports = config => {
  config.resolve.alias = {
    components: path.resolve(__dirname, 'components')
  }
  return config
}

Neither of those seem to work. Am I missing something? Is __dirname not giving me my project root?

My apologies. I set up that import incorrectly. It does work on the client when I use the webpack key but not on the server. I guess that's because we don't have webpack on the server. Any other ideas?

I got it working with a Babel plugin instead. https://github.com/tleunen/babel-plugin-module-resolver
It does make me wonder the examples that alias react with Inferno for example, is that using React or Inferno on the server since the alias is just in webpack?

@abstracthat inferno example doesn't use React on the server.
See fjx: https://github.com/zeit/next.js/pull/767
Using https://github.com/tleunen/babel-plugin-module-resolver is the current solution.

Does anybody have any examples of a next.js app working with the babel-plugin-module-resolver?  I've been trying for a couple of days to get it to resolve my components using this plugin, but I must be doing something wrong and I haven't seen any examples online.

@msell I was able to get it working pretty easily with this .babelrc:
{
  "presets": [
    "next/babel"
  ],
  "plugins": [
    ["module-resolver", {
      "root": ["./"]
    }]
  ]
}

you can try running it yourself and see an example at https://github.com/timberio/next-go

There's an example for doing this now https://github.com/zeit/next.js/tree/master/examples/with-absolute-imports


chore(main): release 1.7.0

:robot: I have created a release beep boop
1.7.0 (2024-02-29)
Features

add env support and update design (2950808)
add env support and update design (1e80650)
update install (cb6c545)
新增scan扫描功能 (d892f93)

Docs

make doc better (5f3c570)
make doc better (c7962d2)
make doc better (a788376)
make doc better (93ac252)
make doc better (ced9668)
make doc better (0a8d6db)
make doc better (f3d0318)
make doc better (e9d4ba2)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/WGrape/posture/releases/tag/v1.7.0 :sunflower:


Don't pass empty or undefined tools body param

Don't allow tools to be passed unless there are tools available

Fixes https://github.com/continuedev/continue/issues/3403


[2.x] Error when starting websocket with custom handler.

Hello.
I'm trying to create a custom handler, my laravel-websocket current version is 2.0.0-beta.33.
app\MyCustomWebSocketHandler.php
namespace App;

use BeyondCode\LaravelWebSockets\Server\WebSocketHandler;
use Exception;
use Illuminate\Support\Facades\Log;
use Ratchet\ConnectionInterface;
use Ratchet\RFC6455\Messaging\MessageInterface;
use Ratchet\WebSocket\MessageComponentInterface;

class MyCustomWebSocketHandler extends WebSocketHandler
{
    public function onOpen(ConnectionInterface $connection)
    {
        Log::info($connection->httpRequest);
    }
}

In my routes/web.php I added the following
use App\MyCustomWebSocketHandler;
use BeyondCode\LaravelWebSockets\Facades\WebSocketRouter;

WebSocketRouter::get('/test', MyCustomWebSocketHandler::class);

But when I try to restart the websocket server, I get the following error:

Searching in the error in the issues page I found the #531, however it says that was fixed at beta.21, So I'd like to know if there is another workaround, or there is a step that I missed.
I even changed the WebSocketRouter::get('/test', MyCustomWebSocketHandler::class); to boot() in AppServiceProvider.php, but to no avail.

Hi, try this:
WebSocketsRouter::webSocket('/app/{appKey}', \App\Websocket\MyCustomWebsocketHandler::class);

After the mentioned PR is merged, there will be one way to register the routes that's strict for 2.x:
WebSocketsRouter::addCustomRoute('GET', '/my-websocket', \App\MyCustomWebSocketHandler::class);


Issue with reexport syntax

In my existing project Esprima complains about export { default } from 'ember-ckeditor/components/ember-ckeditor';
When I hack the following into the addon, this works fine:
import X from 'ember-ckeditor/components/ember-ckeditor';
export default X;

I've update to the latest ember-cli and I don't have too many exotic modules. Not exactly an issue related to this addon, but others might be hit as well.
@ebryn do you have a suggestion where to look / what to update to get the addon working?

Tracked down to having an issue with ember-browserify 1.0.0, updating it to 1.0.1 solved the problem. Closing.


Publish 03/28/2022 3:30 PM PT

Docs Build status updates of commit dd8bb51:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/docs-conceptual/connect-to-exchange-online-powershell.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/New-SafeLinksPolicy.md
:white_check_mark:Succeeded
View (exchange-ps)

exchange/exchange-ps/exchange/Set-SafeLinksPolicy.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Display several turn icons for one lane overlapped

This PR proposes displaying all available lane icons (excluding undelivered by backend itself) overlapped each other for the same lane and with graying out inappropriate icons for a current route step direction.
Lane indication icons were created from scratch to be mono-width and centered but to be quite close by color and style to base step maneuver icons.
Now the lane icons (missing in source issue #281) look like:

Other samples:

Wow, nice work!

Guys working on Project-OSRM/osrm-backend#2935 could be interested by this.

in the image "Other samples:", one of the steps "turn left onto" tells you to turn left, and all 3 lane arrows are blue, even though the rightmost show only going straight?

This is the sample how currently backed works with lanes :wink: If there is only one icon per lane (this case), its valid flag (produced by backend) is not being changed.

@yuryleb: what misses for this to be merged?

Good will of maintainers I think :wink:

Sigh, sorry @yuryleb , too many things to track.  Thanks for the PR!

For my information, when is this supposed to appear on the demo website map.project-osrm.org?

The last step - rebuild bundle.js, bundle.js.map and bundle.raw.js. Actually anyone could prepare this PR :wink:

Gah, I forgot about that step.  I've just re-built and pushed a commit directly, I don't think this requires a PR.

@yuryleb I got an email from GitHub Pages saying that the Jekyll build timed out.  I've pushed an empty commit to re-trigger whatever magic it is that GitHub Pages does in the background, and hopefully this time it'll work.


Unable to set the request Host header

Hi,
In our setup the keycloak proxy's upstream-url is set to the internal URL of a web application that is not accessible from the internet (e.g. http://webapp.internal:6543/).
We use an Amazon Load Balancer that forwards requests to the keycloak proxy. It is accessed publicly like https://protected-webapp.example.com.
Our issue is thet the webapp relies on the Host header from the http request for creating URLs, so now we are getting the internal hostname (webapp.internal:6543) in the browser, which of course does not work from the internet.
I see that the Host header is set by the keycloak proxy to the value of upstream-url.
I tried to set the Host header manually like this:
headers:
Host: protected-webapp.example.com
But still it gets to the webapp with the upstream-url value.
Is there any way to set the Host header to a custom value?
Thanks!

Hi I've also have kinda the same problem.
I have 2 containers in a Kubernetes POD. One is mapped to PORT 8080 (the actual application) and another container with the keycloak-proxy thing. The thing is if I try to access the internal container with trailing slash ('/'), i.e. <PUBLIC_URL>//, then after the login on keycloak side I am being sent back to the <PUBLIC_URL>// and everything works. BUT, if I go to the URL without the trailing slash, i.e. <PUBLIC_URL>/, then I will be redirected back from Keycloak after a successful login to http://localhost:8080/ which is not good.
How can I solve this?

@songokudbz try to set config redirection-url="<PUBLIC_URL>"

@jangaraj it did not do the trick. My upstream url looks like this:
upstream-url: "http://localhost:{{ service.ports[0].targetPort }}"
do I need to change it as well to the PUBLIC URL?

@songokudbz: No, you don't need to update upstream-url. I think that redirect to the localhost is generated by your app, not by keycloak-proxy -> debug/fix your app code/config.

As of 2.1.0, you can now set the Host: header in your headers:.

Closing the issue as it was fixed in v2.1.0


Updates to dbt Explorer

What are you changing in this pull request and why?
Updates to dbt Explorer

Update this page https://docs.getdbt.com/docs/collaborate/explore-projects with the latest changes
Create a new subpage and move this section https://docs.getdbt.com/docs/collaborate/explore-projects#about-project-level-lineage and all its subsections to it
Create a release note about this update

Checklist

[x] Review the Content style guide so my content adheres to these guidelines.
[x] For docs versioning, review how to version a whole page and version a block of content.
[ ] Needs review from PM

Adding new pages (delete if not applicable):

[ ] Add page to website/sidebars.js n/a for release notes
[x] Provide a unique filename for the new page

hey @nghi-ly and @cafzal - committed the changes, especially the links, and will merge this now


added create query parameter for update document

closes #186
Signed-off-by: NeelParihar<EMAIL_ADDRESS>

Great! Did you test it against the server?

Yes it is working as expected 👍


v3 fails to install (postinstall)

Using yarn to install 3.0.0:
Exit code: 2
Command: npm run build && npm run build:utils
Arguments:
Directory: ....\node_modules\xstate
Output:
><EMAIL_ADDRESS>build ....\node_modules\xstate
> tsc && webpack -p ./lib/index.js ./dist/xstate.js --config webpack.config.js

error TS2688: Cannot find type definition file for 'mocha'.
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR<EMAIL_ADDRESS>build: `tsc && webpack -p ./lib/index.js ./dist/xstate.js --config webpack.config.js`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm WARN Local package.json exists, but node_modules missing, did you mean to install?```

Install xstate@latest, v3 is not out yet. (I haven't even written documentation 😅 but I intend to for V3).


fix a[tabindex=0]

Fixes https://github.com/davidtheclark/tabbable/issues/2

@davidtheclark re: tests. This is barking at me about saucelabs credentials. Can you test it locally?

Thanks @afraser! I'll look into it soon.

Thanks to you for sharing this code, good stuff.

Merged in 82edb01c7aab4290a6dd585b8894ea6363c59d8d

Published in 1.0.1


ng#directive#ngOptions: Correctly assign disabled attribute with valid value.

Fixes an issue where the attribute 'disabled' was assigned to an element, but the value of the attribute wasn't enforced. This correctly assigns the 'disabled' attribute with the value 'disabled' (Fixes CSS selectors such as option[disabled] and option[disabled="disabled"], et al.) This is more consistent with other angular implementations (see: ngDisabled);

I signed it.


[BUG] Module '"@refinedev/core"' has no exported member 'Link'

Describe the bug
src/components/header/index.tsx:3:25 - error TS2305: Module '"@refinedev/core"' has no exported member 'Link'.

3 import { useNavigation, Link } from "@refinedev/core";
                          ~~~~

Found 1 error in src/components/header/index.tsx:3

Steps To Reproduce
Try example invoicer app
npm create refine-app@latest -- --example invoicer

run build command
npm run build

Expected behavior
the invoicer app should sucessfuly builded
Packages
"@refinedev/antd": "^5.43.1",
"@refinedev/cli": "^2.16.38",
"@refinedev/core": "^4.54.1",
"@refinedev/devtools": "^1.2.8",
"@refinedev/react-router-v6": "^4.6.0",
"@refinedev/strapi-v4": "^6.0.8",
"antd": "^5.17.0",
"antd-style": "^3.6.1",
"axios": "^1.6.2",
"react": "^18.0.0",
"react-dom": "^18.0.0",
"react-input-mask": "^2.0.4",
"react-router-dom": "^6.8.1"

Additional Context
The latest changes on the invoicer app that i try is https://github.com/refinedev/refine/commit/ac31926c2e8701ccaf8d6111ade924df35133aab

We've merged the release PR, it should be available soon.


Ambiguous code examples in documentation

An example below from https://docs.vespa.ai/en/embedding.html#embedding-a-query-text:

{
"yql": "select * from sources * where ...",
"query": "semantic search",
"input.query(embedding)": "embed(e5, contextualized search)",
"input.query(embedding2)": "embed(e5, neural search)"
"ranking": "semantic",
}

This code is ambiguous with the "...". How can we really use the two query embeddings here?
An other example from https://docs.vespa.ai/en/nearest-neighbor-search-guide.html#multiple-nearest-neighbor-search-operators-in-the-same-query:

vespa query
'yql=select title, matchfeatures from track where ({ label:"q", targetHits:10}nearestNeighbor(embedding,q)) or ({label:"qa",targetHits:10}nearestNeighbor(embedding,qa))'
'hits=2'
'ranking=closeness-label'
"input.query(q)=$Q"
"input.query(qa)=$QA"

Are "$Q" and "QA" 2 shell variables, or are they part of YQL syntax?
It looks like a detail, but I had to refer to blog articles to find useable code too ambiguous in the documentation.

This code is ambiguous with the "...". How can we really use the two query embeddings here?

Because you can retrieve by price > 1 and still have those embeddings created, or you can have four nearestNeighbor query operators (connected by or/and/rank). That is the this example does not demonstrate a specific query tree (retrieval).

Are "$Q" and "QA" 2 shell variables, or are they part of YQL syntax?

No, they are shell variables set in the section above.

where rank({targetHits:100}nearestNeighbor(doc, embedding), {targetHits:100}nearestNeighbor(doc, embedding2))

where ({targetHits:100}nearestNeighbor(doc, embedding)) or ({targetHits:100}nearestNeighbor(doc, embedding2)))

Thanks @jobergum. But this issue is about the whole documentation: all code examples should be more realistic.
For instance, your three examples would be great in the documentation as examples of hybrid and multi vector queries.

Yes, I will add them to the linked resource.

this issue is about the whole documentation: all code examples should be more realistic

Feel free to point out concrete examples where we do not use realistic examples.
On the shell variables. I don't know how to improve on it.

Just expanding all variables would be clearer. People are scanning the documentation with a narrow vision.
(You will not believe me, but I did not see the variables content in the documentation, until now !!)
vespa query \
    'yql=select title from track where ({targetHits:10}nearestNeighbor(embedding,q)) or ({targetHits:10}nearestNeighbor(embedding,qa))' \
    'hits=2' \
    'ranking=closeness-t4' \
    "input.query(q)=Total Eclipse Of The Heart query vector" \
    "input.query(qa)=Summer of ‘69 query vector"

Good idea. We can rewrite this guide to use native embedders instead.

Fixed by https://github.com/vespa-engine/documentation/pull/2847 and now live on https://docs.vespa.ai/en/nearest-neighbor-search-guide.html


Memory Leaks when using with react-router v4

I'm receiving that error from my Home component when switching into a different route that de-renders it. (Using <Trail /> in Home)
Seems like some listeners are not being removed. Is this a known bug?

Still, the components should guard against this.
    componentDidMount() {
        this._isMounted = true;
    }
    componentWillUnmount() {
        this._isMounted = false;
        // kill any pending calculations
    }

And instead of just using this.setState(...), always use this._isMounted && this.setState(...) instead.

I do this mostly everywhere where it matters. That's why i'd like to see a piece of code that produces it, somewhere i must've forgotten to put up mount checks.

I get it from Keyframes. Just updated to latest version (5.8.0) and it's reproducible in my app.
I have const AnimationContainer = Keyframes.Spring({ ... }) for an intro animation, and when you hit the browser back button before the animation is finished, it happens.
index.js:2178 Warning: Can't call setState (or forceUpdate) on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in the componentWillUnmount method.
    in Keyframes (created by Component)
    in Component (created by Nodes)
    in Nodes
    in g
    in svg
    ...

However what's strange is... You seem to have a mount guard already: https://github.com/drcmda/react-spring/blob/master/src/Keyframes.js#L33
It's the only place calling setState in that file..

Nevermind. Didn't do the update right - still had 5.6.10 in my DLL. Purged it and 5.8.0 is just fine.


Breach link on readme redirects to adware/malware

Recommend removing it immediately: http://breach.cc/

Will remove.

Looks like it’s fixed, thanks!


Update all cnf examples README

Description
This PR will update documentation for all example cnfs, so it will be aligned with installation and usage guide.
Issues:
Refs: #1951
How has this been tested:

[ ] Covered by existing integration testing
[ ] Added integration testing to cover
[ ] Verified all A/C passes

[ ] develop
[ ] master
[ ] tag/other branch

[ ] Test environment

[ ] Shared Packet K8s cluster
[ ] New Packet K8s cluster
[ ] Kind cluster

[ ] Have not tested

Types of changes:

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[X] Documentation update

Checklist:
Documentation

[ ] My change requires a change to the documentation.
[X] I have updated the documentation accordingly.
[ ] No updates required.

Code Review

[ ] Does the test handle fatal exceptions, ie. rescue block

Issue

[ ] Tasks in issue are checked off

Thank you for the PR.
Only markdown changes. No build required. Merging this PR.


Update write vectored

Description

Adds comments and tests to writev_syscall
Adds stream functionality to writev_syscall
Update write_vectored_to_pipe

Fixes # (issue)

Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?

tested using cargo test --lib
Checklist:

[x] My code follows the style guidelines of this project
[x] I have commented my code, particularly in hard-to-understand areas
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[ ] Any dependent changes have been added to a pull request and/or merged in other modules (native-client, lind-glibc, lind-project)

I think this looks good but its failing tests, I think due to you adding write_vectored_at to lib.rs. I know you have to do that but its causing some issue with the runner. @yashaswi2000 can you also give this a review and look at why the test is failing?

the build itself is failing, @rupeshkoushik07 are you able to run cargo test on your local?

@yashaswi2000 Even after adding #![feature(unix_file_vectored_at)] to lib.rs, I still encounter the same error locally.


Support concat_batches for 0 columns

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

label_issue.py automatically added labels {'arrow'} from #4662


Subsequent fade on submobject of TexMobject not behaving as epected

I would like to fade out and fade in a submobject of a TexMobject. In my example below, I would like to see the "B" disappearing and appearing again. However, on my system the fade in does not work. The B remains faded out.
Is my assumption on the expected behavior correct? Or am I using the wrong approach for the second call to the fade method? I would appreciate any tips or hints!
I am on manimlib 0.1.11 in a linux environment.
Thanks for the great library!
class FadeInFadeOutSubMobject(Scene):
    def construct(self):

        text = TexMobject("A","B","C")
        self.play(FadeIn(text))
        self.wait(1)
        self.play(FadeOut(text))
        text[1].fade(1)
        self.wait(1)
        self.play(FadeIn(text))
        self.wait(1)
        self.play(FadeOut(text))
        text[1].fade(0)
        self.play(FadeIn(text))
        self.wait(1)

from manimlib.imports import *

class Issue(Scene):
    def construct(self):
        text = TexMobject("A", "B", "C")
        self.play(FadeIn(text))
        self.wait()

        self.play(FadeOut(text[1]))
        self.wait()

        self.play(FadeIn(text[1]))
        self.wait()

Thank you! Much appreciated. Your solution works.
I noticed that I misunderstood how the fade method works. The code below is an alternative to your solution.
I am closing this issue.
class FadeInFadeOutSubMobject(Scene):
    def construct(self):
        text = TexMobject("A","B","C")
        self.play(FadeIn(text))
        self.wait(1)
        self.play(FadeOut(text))
        text[1].set_fill(opacity=0)
        self.wait(1)
        self.play(FadeIn(text))
        self.wait(1)
        self.play(FadeOut(text))
        self.wait(1)
        text[1].set_fill(opacity=1)
        self.play(FadeIn(text))
        self.wait(1)


Rewrote docker container using bioconda environment.yml

Looks like the docker build has been failing for nearly a month: https://hub.docker.com/r/scilifelab/ngi-rnaseq/builds/
Took this as an opportunity to refactor using bioconda. Need to check that this generates containers that work offline - not entirely sure that all required R packages are installed yet.

Cool!
Test is passing, so I'm merging.
The Travis error seems to be related to #214 not this PR

hah, ok cool :) The changes are all based on the docker build and the tests only use the latest dockerhub version so won't have been checking the new code. But the old code has been broken for a month or so anyway, so I guess this won't be much worse..??

Yeah, precisely


Segmentation fault 11 when inherit from ScrollableGraphView

Hi,
I have Command failed due to signal: Segmentation fault: 11 when trying to inherit from ScrollableGraphView:
@IBDesignable
@objc open class ProductivityGraphView: ScrollableGraphView {

}

While loading conformances for 'ProductivityGraphView' at

I am able to subclass now in version 4 of the component.
import UIKit
import ScrollableGraphView

@IBDesignable
@objc class ScrollableGraphViewSubClass: ScrollableGraphView {

    override init(frame: CGRect, dataSource: ScrollableGraphViewDataSource) {
        print("in subclass")
        super.init(frame: frame, dataSource: dataSource)
    }

    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
}

This works for me. If anyone else experiences this please reopen and post the call stack please.

@philackm thanks!🙏


Verify all iroha repo-related links

Since there are changes to the hierarchy of the branches in the main /iroha repo, all of the links leading to the repo, its branches, specific files and crates, must be checked and verified.

edits added to PR #504


Question: Summary of defined/undefined values in P4-14 and P4-16

I knew there were some differences in the specs of the 2 languages here, but didn't have in my head exactly what they all were, so I started searching through both specs for words like "defined" "undefined", "specified", "unspecified", etc. and came up with the following.  I would appreciate it if someone familiar with these things could see if I am missing anything relevant, or if any of what I have is incorrect.
Basically, in P4-14 v1.0.3 every user defined metadata field value is defined in all situations.  They have optional initializer expressions in the syntax when metadata is defined, defaulting to an initial value of 0 if there is no initializer expression.  For intrinsic metadata, the only exception I saw was the field 'egress_spec', which explicitly says it is undefined for each packet until the P4-14 program assigns it a value, or the packet is dropped and it then doesn't matter that egress_spec is undefined.  For headers, their fields are explicitly stated to have undefined values if the header is invalid.  I don't recall finding anything explicitly mentioning this, but suspect the intent is that when the parser begins, all headers have their validity bit set to invalid.
In P4-16 1.0.0, there are no optional initializer expressions for user defined metadata, and it is explicitly stated that reading the value of a variable that has not been initialized yields an undefined result.  Intrinsic metadata has nothing defined in it in the P4-16 spec -- that is left to the architecture to specify.  For headers, it is pretty much the same as for P4-14 v1.0.3, including a mention that "When a header is created its validity bit is automatically set to false.", so it seems that while there are many situations in which a header field's value can be undefined, a header's validity bit is always defined.
Look at the definition of the parser in P4-16's v1model.p4 here https://github.com/p4lang/p4c/blob/master/p4include/v1model.p4#L149-L152 and copied below:
parser Parser<H, M>(packet_in b,
                    out H parsedHdr,
                    inout M meta,
                    inout standard_metadata_t standard_metadata);

Although the spec says that out parameters lead to undefined behavior, I believe the special mention of headers automatically having their validity bit set to false when the header is created overrides that, yes?  And thus even if the parser immediately did a 'transition accept' in the start state, every header inside of type H would have its validity bit initialized to false.  Is that correct?
Now 'meta' and 'standard_metadata' are inout here.  It seems to me that the architecture could choose to specify initial values for all of the fields inside of them, but it could also choose to stay at the least thing promised by the P4-16 spec, which is that all of their field values are uninitialized and undefined.  True?
And if an architecture had direction 'out' instead of 'inout' for parameter 'meta' here, then likewise the architecture could still choose to be 'more defined' than the P4-16 spec and say "even though the spec says these uninitialized variables have undefined values, in our architecture we guarantee they are all initialized to 0 -- note that this could lead to non-portability from a program written on our architecture to another architecture that does not guarantee this property".  True?

Hi Andy,
I do agree that there are some loose ends to tie.
I think that parameter direction is very important for the architecture definition and needs to be used to express the architectural intent. At some point I remember @mbudiu-vmw proposing to think about  P4 parsers and controls as callbacks for a black box, which represents the overall architecture. I think that it helps enormously and allows us to have the following guidelines:

in parameters should be used in the cases where the architecture is known to initialize the parameters to some well-defined values (as per architecture spec) and clearly will ignore the values these parameters will have after the parser reaches accept/reject state or the control reaches its end
inout parameters should be used in the cases where the architecture is known to initialize the parameters to some well-defined values (as per architecture spec) and clearly will use the values these parameters will have after the parser reaches accept/reject state or the control reaches its end
out parameterss should be used in the cases where the architecture is known not to initialize the parameters to any particular values, expecting instead the parser/control to do that. In other words, reading these parameters before they have been written, while completely legal,  will produce an unspecified value and the compiler should produce a strong warning if it can detect this. These these parameters will clearly be used by the architecture after the parser reaches accept/reject state or the control reaches its end

Now, in case of  headers, I think it is, indeed, extremely convenient to have the validity bits being cleared by the architecture, meaning that if we want to be pedantic, we will say that even though a header might be an out parameter, its validity bit will, in reality be inout and codify that rule in the spec. For other directions there is no difference.
For all the non-header values (user metadata, intrinsic metadata), if an architecture guarantees that they are 0 or something, I would recommend using inout.  Otherwise (especially for the user metadata), it is probably better to use out and let the user initialize it implicitly in the control. In fact, that was the reason I was asking for "all zeroes" initializer ({}) at our last meeting.
Thanks,
Vladimir

The semantics of copy-in/copy-out is that your parameters are copies of the arguments. Out parameters are always uninitialized. Uninitialized headers are always invalid.

@mbudiu-vmw "Out parameters are always uninitialized."  I agree that an architecture need not promise to initialize 'out' parameter values if it doesn't want to -- the P4-16 spec allows this.  If an architecture stated "All 'out' parameters will be initialized to 0, guaranteed." that would not violate the P4-16 spec, would it?  In my opinion, that sounds like "we implement the spec, plus some more stuff on top of that, for your convenience".

You cannot override this. The out parameters start uninitialized and then after the call is done they are copied on top of the argument. Even if the argument was initialized, copying would destroy its value.

I think @jafingerhut is asking if a target could implement
"uninitialization" as zeroing out.
N
On Sun, May 21, 2017 at 5:21 PM Mihai Budiu<EMAIL_ADDRESS>wrote:

You cannot override this. The out parameters start uninitialized and then
after the call is done they are copied on top of the argument. Even if the
argument was initialized, copying would destroy its value.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/p4lang/p4-spec/issues/273#issuecomment-302973461, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABwi0lLn2fRGme8dgggQRNbJbguJDCVYks5r8NUHgaJpZM4NhoW3
.

It looks like section 6.7 says precisely that:

out parameters are uninitialized (parameters of type header or header_union are set to “invalid”);

I think the confusion is purely linguistic, because the sentence above basically says that the valid bits of uninitialized headers/header_unions (and we think of them as integral part of those) are initialized to 0 :)

Implementing 'uninitialization' as zeroing out is actually more work for the target designer. E.g., on a pipelined FPGA target, pipeline registers are used to store the out parameters. Zero-out the register after each packet takes a cycle, and modifying the register takes another cycle. The target which implements zero-out effectively only achieve 50% of the max throughput. By forcing out to start as uninitialized, we are shifting the "burden" to p4 programmers, and forcing them to write P4 programs that assign a value to each register by default. This helps the target designer to save the cycle from resetting the register after each packet and results in higher performance P4 programs. While this may be a bit inconvenient at the beginning for the P4 programmer, they will thank us when they actually run the program on a real target.

Unintialized means that reading from it returns undefined. 0 a legal undefined value.

So there can be many implementations that save work, and/or achieve higher performance, by taking advantage of the fact that the P4 specs allow undefined behavior in certain situations.  I understand that.  Completely.  Implement them with my blessing (well, maybe with my tolerance -- I don't actually like the undefined behavior in the spec, but I'll live, and even sleep well, with it there.)
But undefined behavior, in most cases at least, actually means "the undefined bit vectors/variables are filled with some actual bit values, but you can't predict what those values will be in advance of running your program, without knowing a whole lot more details about the implementation than you want to know".  Sure, someone could create an implementation, e.g. a Verilog simulator, that made those values Xs instead of 0s and 1s, but I doubt any production implementation would do that.  bmv2 developers don't even want to do something like that, because of the lower performance that might occur (although they are willing, as a special build time option).
All I am saying is that, regardless of what 99% of implementations might do, 1% of them can say "Hey, you know those places in the spec that say the behavior is undefined?  We decided to help you out a little bit there.  We are going to some extra effort to make those behaviors defined, e.g. by initializing variables to 0 when they are created, before you assign any values to them explicitly in your program."  If someone can tell me how such an implementation violates the spec, and an experiment one could use by running a P4 program on that implementation that demonstrates it violates the spec, I'll give you $1 (sorry, only the first person to do so, not everyone).

@jafingerhut,

All I am saying is that, regardless of what 99% of implementations might do, 1% of them can say "Hey, you know those places in the spec that say the behavior is undefined? We decided to help you out a little bit there. We are going to some extra effort to make those behaviors defined, e.g. by initializing variables to 0 when they are created, before you assign any values to them explicitly in your program."

I am afraid that if we go this way than this 1% of implementations will easily screw up either the rest of the 99% of implementations or the programmers who are going to use it and were to follow this guidance. What's worse is that the implementation will not, indeed, violate the spec, but the guidance above will encourage people to violate the spec and I am not sure what's worse.
Ultimately, the program is about expressing the programmer's intentions, while the rules are about the intentions that must be expressed. We either need to make a rule that the programmer needs to express the intention that a certain variable is initialized or make the rule that it is not needed (but the variable will still be initialized). Currently the intention to initialize must be  expressed via the explicit initializer or by declaring a parameter to be either in or inout. All the other situations lead to uninitialized values and from my perspective that's good, because it is clear.
While it is difficult to prescribe what people should do, my preference would be if those 1% of implementations say what they do differently, e.g. "Hey, you know those places where you initialize your variables? We decided to help you out a little and made this initialization free".  This way people will still be encouraged to express their intentions, while reminded that it's cheap.

@vgurevich  Such an implementation doesn't encourage people to violate the spec, not even a little bit.  It might encourage them to write non-portable programs, true, but an implementation does not violate the spec by allowing non-portable programs to be run on it.  P4 externs are a far more likely source of non-portability, and those are in the spec, by design.

@vgurevich Regarding your first comment on this issue, I will quote you here, then reply below that, on one point:
"Now, in case of headers, I think it is, indeed, extremely convenient to have the validity bits being cleared by the architecture, meaning that if we want to be pedantic, we will say that even though a header might be an out parameter, its validity bit will, in reality be inout and codify that rule in the spec."
My reading of this line of the spec "When a header is created its validity bit is automatically set to false." seems to satisfy your wish.  We could repeat it for emphasis in the case of out parameters specifically, but it seems to be a consequence of my quoted sentence already.

@jafingerhut,
On who encourages what. I think we are generally in agreement. Yes, those systems will not violate the spec. Yes, I should have been more careful: programs written by the users do not violate the spec (only the implementations do); instead they are non-portable. I think we also agree that encouraging non-portability is not a good thing to do.
On non-portability of "above-and-beyond-the-spec" behavior vs. externs. The difference is that if people design things right, the non-portability of externs will be determined at the compile-time. In other words, if one arch supports registers and another does not, that will mean that the corresponding extern will be missing on the second arch, the program will refuse to compile and the programmer will have their work cut out for them. Similarly, if one architecture supports 128-bit registers, but another one only supports up to 64-bits, it will be determined at compile-time. like-wise, if one architecture supports three-color meters and another one supports two-color only (or, for example one supports color-blind and another one supports color-aware ones), all these differences can be easily detected at compile-time because (hopefully) these externs will have different names to begin with. On the other hand, if one arch supports this "behind-the-scenes" initialization and the programmer decided not to express his intent in the program text, the compiler for another arch will have no way to even detect the problem.
On the uninitialized headers having the validity property initialized. Looks like we are in total agreement between ourselves and with the spec. Repeating it in a couple of key places won't hurt to prevent similar kind of confusion by the future readers.

Agreed that the compiler should be quick to discover non-portability issues involving externs.
The point you bring up about the imagined "initialize things to 0 for you" architecture vs. other architectures that do not -- there is already such an issue between different implementations today, because the spec says the values are not defined.  A program might work perfectly well on one architecture/implementation, because it happens to rely upon how that implementation happens to initialize things the spec says are undefined, without knowing it, and the compiler does not tell them.  Sure, it is supposed to try to warn people about use of uninitialized variables, but it cannot do it perfectly because of unknown table content properites that the control plane satisfies (or doesn't satisfy).
If you are worried about portability issues because of undefined behavior, the most effective way to get rid of it is to eliminate the undefined behavior.  I am not now proposing the spec change to do this.  I just want to point out that my proposed architecture is not the cause of non-portability here.

I agree with @jafingerhut, both on this point and the rest of the points being made in this thread. To summarize:

It is legal for a target to implement uninitialization by zeroing out.

For a program to be portable, among other things, it must not make any assumptions about any of the undefined values that it encounters when evaluating the program.

In the short term, I know that a number of us are highly motivated to implement a "safe" variant of P4_16 where all values accessed must be statically initialized. This safety analysis would be a conservative way of checking point 1 above.
Finally, note that the thing we should be far more worried about is architectures that implement uninitialization by clearing the valid bit and doing nothing else. As @hanw notes, this is cheap. However, in practice, I fear such behavior is likely to mask many bugs...
-N

One nit: uninitializing headers by zeroing out should make sure that the header is still invalid.

Correct.

@jnfoster If an architecture implements uninitialization of headers by clearing valid bits and nothing else, isn't having a tool that can achieve your point 2 exactly the kind of thing that would avoid undefined behavior on such an architecture?

@jafingerhut is this something we could fruitfully discuss on 11/27 or should we defer to a later meeting?

This PR: https://github.com/p4lang/p4-spec/pull/450
contains a proposed change to the P4_16 spec intended to address this issue.  I think we could fruitfully discuss the text of that PR.

Great. Many thanks. I'd missed that this was cross-linked with issue #285 not this issue.

Actually, I might be getting them mixed up, now that you mention it.  #285 and #450 are definitely linked to each other.  Let me re-read this issue and #285 to see if there is anything distinct about this one that needs addressing separately.

@jafingerhut @vgurevich can we close this issue now?

All of the issues raised I think have been addressed in one way or another.

Great! Closing.


release to npm

Would you be able to make this module available on npm? Thanks!

I just published it on npm.


[WIP] Tile bounds that fall within aoi_boundary but not a src_img ignored. isntance_mask only rasterizes labels where there is good data in reference_im

Issue
I found the tile bounds issue by trying to use split_geom via the raster tiler to tile a single Landsat scene that partially intersected with the state of Nebraska (my aoi_boundary). Thjis resulte din many empty tiles because tile bounds outside the landsat image were included.
The instance_mask issue is shown here:

Where the tile partially falls outside the raster image labels shouldn't be created because no data values like -9999.0 will be associated with those labels. This also handles issues that could arise if there are no data values in the corners of rasters (like there are for some Landsat collections).
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected - these changes will not be merged until major releases!)

How Has This Been Tested?
I self tested on my own datasets and ran this against existing tests. Whereas before the aoi_boundary fix the following tile would be empty and before the isntance_mask fix there would be labeled pixels where the image had nodata, the issues are shown to be fixed below when I plot the first raster tile and overlay the label tile. I can add a test later.

Checklist:

[x] My PR has a descriptive title
[ ] My code follows PEP8
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new errors
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] My PR passes Travis CI tests
[ ] My PR does not reduce coverage in Codecov

closed because of a messy rebase


Bump tower-web-macros version to 0.3.2

Correct me if I'm wrong but I think you forgot to update the version of tower-web-macros in the latest commit (b4210086ae3256eb33509b9e340a64dc78c0add7).
https://github.com/carllerche/tower-web/blob/b4210086ae3256eb33509b9e340a64dc78c0add7/Cargo.toml#L66
Should be:
tower-web-macros = { version = "0.3.2", path = "tower-web-macros" }

Hmm, yeah, looks like it!


[backport] Assert that all the pointers are in the same device in concatenate

Backport of #3285

[automatic post] Jenkins, test this please.

Jenkins CI test (for commit c17b64dcb0121ee9b21e477d394c270d8b62cbcb, target branch v7) failed with status FAILURE.

NameError: name 'pytest' is not defined 😁

Jenkins, test this please

Jenkins CI test (for commit a5c4c37f34e9fec907bb12ff62354590353a64a2, target branch v7) succeeded!


Do += -= and scalar *= /= in place

Lower stack usage for += and -= matrix operations, as well as *= and /= scalar-matrix operations

Coverage decreased (-0.5%) to 99.469% when pulling 5315efed9bc9aeec094f227a152a067d756b5a57 on lower-stack into f529358e9ac28b0809572c14a964ba7ba691adc4 on master.


Issue/2 Substitute OC with OT Collector

This PR substitutes the OC collector with the OT collector and removes the OC agent, since it is not necessary anymore. This is only the first step for completing #2.

TODO OT Collector needs testing with real data. Then merge.

The switch from OC to OT collector has already been completed.


cmp autocomplete menu doesn't always close

I've noticed that when the cmp popup is displaying suggestions, if I manually type in the value and hit Ctrl + c, the pop up menu seems to get stuck.

My cmp configuration can be found here: https://github.com/wonbyte/.dotfiles/blob/main/nvim/.config/nvim/lua/config/cmp.lua

https://github.com/hrsh7th/nvim-cmp/commit/0dcc2eb5d32a71fac60f507c71dd17b4711b4b76
Now you should config it by yourself.

<C-c> support was added.


One-hot encoding with array

I am working with a dataset that includes many categorical variables, and using dummy variables enlarges the number of variables significantly. I was hoping to use vectors for each categorical variable but I am unsure whether SOMPY would allow for such a datatype to work.
If I were to encode animal[cat, dog] as a variable called animal with values [0,1] and [1,0], would SOMPY be able to hand this or should I make variables for each type of animal with dummy variables?
Thank you!

Same question, does sompy handle categorical variables? After looking the code sompy.py I did not see any function which play with categorical data.


Adds help topic for module.

If you ship this then users of posh-git will be able to execute "man about_posh-git" and get the info that is currently in the readme.md file.  It is recommended that PowerShell modules provide an about help topic for users to get started with using a module.  It is also a very handy way of looking up the "legend" for the status prompt.
In case someone has their console width set to 80 chars, we limit each line's length to fewer than 80 chars.  Also, PowerShell help files are just text which get dumped to the console.  There is currently no support for markdown rendering.

It would be neat to generate this from the readme somehow, but we'll live with double maintenance for now. Thanks for the contribution!


Update tools.md

Update as Music Sheet Viewer has now its dedicated Block for the Block editor (Wordpress 5.0 and above).

Thanks @efreja . Looks good. Could you please add on "Block" a link to any explanation you find appropriate (maybe to your own documentation of the plugin or at Blocks)? Not sure everyone understands what "Block" means.

Thanks Stefan. But not sure it deserves details at that level... People interested in that paragraph are either people that wish to go to Wordpress and that don't know about it.. in that case, the term shortcode is not even speaking to them.
Or people that already know Wordpress in that case they know what is a block (main feature for a couple of years), and will find useful to know that the plugin provides a Block besides a shortcode. Very few shortcodes have their Block version, and it's worth mentioning it for people that have switched to the block editor and that don't want to deal both with shortcodes and blocks. At last FYI, customized blocks are mini-editors dedicated to one purpose. For the Music Sheet Viewer, you have a screenshot at the bottom of page https://wordpress.org/plugins/music-sheet-viewer/#description.
Thanks

Thank you. Totally fine with me. Just wanted to give feedback that it could be confusing for some readers.

Thanks


feat(datepicker): add datepicker component

Usage
<ux-datepicker> </ux-datepicker>
<ux-datepicker type="datetime"> </ux-datepicker>

<ux-datepicker type="date"></ux-datepicker>

<ux-datepicker type="time"></ux-datepicker>

Year List

jaw drop. Nice work

This will be added to the new Aurelia UX Components library.


Readme: simplify install

Composer picks last possible stable by default. This also allows installing never version.

Thanks @TomasVotruba


Expand Windows PATH tag to Unix-Based and Inspired OSes

Currently, we only have a tag for the windows PATH variable. I suggest we expand this tag to explain what the path is, and maybe explain or give a guide on how to alter it.

I don't think we should extend the windows path tag as it's already quite long. We could add a separate tag to explain how to modify the PATH, although that differs depending on OS so we could end up with quite a long tag, and i'm not sure how useful it would actually be.
One option would be to have:

A guide on the site explaining how to add Python to path on windows, with the method here https://github.com/wookie184/python-guides/blob/main/windows/add-to-path.md, possibly as well as detailing how to add it to path manually, and maybe suggesting reinstalling if all else fails with a link to a page on how to install it properly.
A py-launcher tag, similar to the current windows-path tag (and remove the windows-path tag), which explains how to use the py launcher. Would link to the site page.
A general path tag, which just explains what PATH is, and links to the site page for how to change it on windows, and maybe another page for changing it on unix systems.

I'm not sure what the use of a tag explaining how to change the PATH on a unix system would be in the context of Python (as I don't use a unix system). Is it common for users to have a Python install on linux but not to be able to access it because it isn't on PATH? From what i'm aware, the main recommended ways of installing Python would be through a package manager, or pyenv, both of which would usually handle PATH modification for you.

@wookie184 I'd probably just do the path tag


Fix typos in documentation examples

This PR fixes 2 typos on the processes and threads example.

The child process snippet had an extra closing parathesis.
The parent process referenced an undefined variable.

Thanks!


Add workDir API to the script and command operation APIs to make parametrize the working directory

Explanation
The working directory for the script and command operations is hard-coded for the test directory. For some scripts it can affect the logic of some commands like cp. This is directly affects the end users of uptest after kuttl to chainsaw migration.
This PR adds workDir API to the script and command operation APIs to make parametrize the working directory.
Related issue
Fixes #1912
Proposed Changes

Checklist

[x] I have read the contributing guidelines.
[x] I have read the PR documentation guide and followed the process including adding proof manifests to this PR.
[ ] This is a bug fix and I have added unit tests that prove my fix is effective.

Further Comments

@sergenyalcin did you see my reply on slack https://kubernetes.slack.com/archives/C067LUFL43U/p1725360878442449 ?

@sergenyalcin I'm going to merge this and do follow ups.
Thanks for initiating the changes.

/cherry-pick release-0.2


Use array pointers, rather than arrays

Passing keys as arrays rather than slices or pointers to arrays seems like a good way to spray key material all over the stack. I'd suggest using pointers in those cases so you at least have the ability to zero the memory if desired.

That's a really good point! I notice that @agl used array pointers in his original ed25519 code, but the one that landed in x/crypto just uses byte slices. I don't know if they're equivalent in stack behavior- do you?

Byte slices are equivalent to array pointers, except that they also store a length and a capacity. In the case of known-length keys and such, length isn't particularly useful, and capacity is even less useful. The only problem with array pointers is that they necessitate extra copying if you need to go from a slice to an array pointer, and don't want to use unsafe.

Pretty clear that the right thing to do is change the arguments to array pointers- thanks for pointing this out.


Unresolved SIDs in unmanaged user rights cause a failure

I've noticed that if we have unresolved SIDs in user rights that we are not trying to manage with DSC, the DSC code will still fail. Is it possible to make the code only attempt to resolve the members of the specific user right that is being configuration managed to avoid this issue?

Closing this as duplicate to #78


how many gpu is needed to reproduce the performance?

how many gpu is needed to reproduce the performance

2 x RTX3090


Get rid of browserify/watchify/whateverify

Electron has node-integration so it is actually useless (and takes almost a full minute to install on travis!).

This might be a blocker for appveyor - currently we're running over the 40 minute limit! Gotta simplify that.


Display mode does not work with tagbox widget

Are you requesting a feature, reporting a bug or ask a question?
Bug
What is the current behavior?
Tagbox dropdown is selectable when mode === 'display'
What is the expected behavior?
Tagbox dropdown shoud not be selectable when mode === 'display'
How would you reproduce the current behavior (if this is a bug)?
https://plnkr.co/edit/ICfNz8AUW9CaMboVRXV5?p=preview

Probably this issue should be created in this repo - https://github.com/surveyjs/widgets/
I've cloned this issue into the https://github.com/surveyjs/widgets/issues/56

ok, thanks! I guess this https://github.com/surveyjs/widgets/ is the right repo


Add handling for cri-docker

Often times the cri-docker components are not running as expected during the preflight checks for kubeadm init. This handler ensures that they are running before proceeding to kubeadm init.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

4 of 8 (50.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.006%) to 65.257%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

deploy/deploy.go
4
8
50.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.006%

Covered Lines:
4645

Relevant Lines:
7118

💛  - Coveralls

/gcbrun


AET Upgrade Notes - initial document

Description
AET Upgrade Notes document for AET admins
Motivation and Context
If you are upgrading AET from the previous version, this document will keep notes that will help you do all necessary configuration changes that were introduced in comparison to previously released AET version.
Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.

I hereby agree to the terms of the AET Contributor License Agreement.

Could you please add this file to _Sidebar.md?


Update README.md

Added explanation that this is an open source project you can contribute.

Please feel free to contribute this project.


Expose a prefixed property

This exposes a property called prefixed which stores the prefix or false when Object.create() is available.

LGTM :+1:

Coverage remained the same at 100.0% when pulling 47ddb33856f98afb936f64cdae57b99805eb9100 on prefix into 1b479ec043fe41156bbf73295674828451b78ea6 on master.


proposal: cmd/go: provide a portable and simple way to run SDK-like Go tools

The Gio library contains a module (gioui.org/ui) for creating GUI programs in Go. For desktop platforms, running a Gio program is as easy as any other Go program, provided you have a few common system libraries and a C compiler installed:
$ go run gioui.org/apps/hello

Running Gio programs on Android, iOS and in the browser requires packaging several support files and meta data, so the Gio project includes the gogio tool in the `gioui.org/cmd module to automate the tedious work.
Note that the gogio tool is not general purpose: it is intrinsically bound to the gioui.org/ui module. Similar examples are the gobind and gomobile tools from the Gomobile project.
This issue is about providing an easy and portable way to run such support tools.
In https://github.com/golang/go/issues/33468 I described a possible solution in terms of go run because go run is very close to what I want. This is the simple and portable one-liner for creating an Android app for a Gio program:
$ go run gioui.org/cmd/gogio -target android gioui.org/apps/gophers

Unfortunately, according to https://github.com/golang/go/issues/33468#issuecomment-518743427, #25416 and https://github.com/golang/go/issues/25416#issuecomment-401882645, it is almost accidental that go run can run the above one-liner.
go install
@bcmills brings up the usual way to use Go tools: go install and setting up $PATH to run them:

You could give separate instructions for cmd.exe and for Unix-like shells. Or assume that they  have their PATH configured appropriately (perhaps by reference to some other document) and tell everyone:

go install gioui.org/cmd/gogio
gio -target android gioui.org/apps/gophers

However, setting up PATH is not portable and not nearly as simple as go run, in particular for Windows users.
Case in point: go env can now set environment variables for the Go tool because (https://github.com/golang/go/issues/30411)

Setting environment variables for go command configuration
is too difficult and system-specific.

go build
https://github.com/golang/go/issues/25416#issuecomment-389495625 suggests
$ go build -o /some/dir/gogio gioui.org/cmd/gogio
$ /some/dir/gogio ...

which doesn't depend on the environment, but still more awkward than just go run.

As a variant to the above, provide a portable and simple way to run a go install'ed binary that doesn't depend on the environment.

In https://github.com/golang/go/issues/33468#issuecomment-518743427, @bcmills brings up an interesting point:

When working within a module in module mode, go run should produce a reproducible result, not always upgrade to the latest version.

I agree that within a module the result should be reproducible which is the reason go run records the version of the command in a current module's go.mod.
However, that means that within a module, go running gio is superior to running a previously go install'ed version, just because the tool version is reproducible with go run, but not with the binary that happens to be in GOBIN.
So go install is not always the correct choice, even if we assume PATH is correctly set up.

As a variant to the above, provide a portable and simple way to run a go install'ed binary that doesn't depend on the environment.

It is possible to get the path to the installed binary in a portable way, with something like:
go list -f {{.Target}} some/main/pkg

Note that this will still resolve the version and do extra work outside a module, so it's not instantaneous.

It is possible to get the path to the installed binary in a portable way, with something like:
go list -f {{.Target}} some/main/pkg

Note that this will still resolve the version and do extra work outside a module, so it's not instantaneous.

Thank you. My current thinking is that the speed of go run outside a module is not that important; most actual uses will be from inside a module.

Unfortunately, according to #33468 (comment), #25416 and #25416 (comment), it is almost accidental that go run can run the above one-liner.

It seems like your use cases for running this tool would always be within a module, though -- it's only relevant when developing programs using your giou.org/ui module. And for that, go run (or go build blah && ./blah, for caching the executable) seem just right.

CC @myitcv @rogpeppe @thepudds

ISTM that #31173 would solve this reasonably, particularly if combined with an idea from @ianthehat of being able to pass a -modfile argument to the go command to ask it to use a different go.mod file .

A random list of points to add to the conversation, followed by a question on how we should move forward:

https://github.com/golang/go/issues/30515#issuecomment-480611127 represents the most recent discussion about this from a golang-tools perspective
in the golang-tools discussions, it was generally agreed/observed that the "within a module" use case is one part of the problem/solution space: being able to install/run "globally" (i.e. "outside of a module") is also a problem that needs solving. Indeed @ianthehat sort to define this more precisely:

The concrete use cases people have suggested so far are:

go code generators (often from go generate lines) which must be versioned at possibly per invocation granularity
code analysis tools (the kinds of things we are trying to merge into gopls, an also gopls itself of course) which may need to be versioned per project
System wide installs of binaries, for the kinds of instructions people put on their wiki

per previous threads with @bcmills, @rsc and others, it's not clear to me that these changes have to be made to cmd/go. @rsc made the point (somewhere I can't now recall) that trying to load too much into cmd/go effectively has costs associated with it, costs that aren't necessarily outweighed by the cost of putting this functionality in a different command. I have definitely come to appreciate this point more, although the attraction of having everything in cmd/go remains
if the changes are not made as part of cmd/go, then the command within which the functionality sits must ultimately be distributed with Go (a la godoc in the old days): the overhead of installing a command to install/run other commands is too high. This obviously doesn't preclude developing something in x/tools as a starting point
gobin is an experiment that covers the cases of "within a module" and "outside a module". It has been largely successful in acting as a hybrid run/install command that sits atop cmd/go. gobin respects replace directives (and could respect exclude directives, this is simply not implemented)
gobin seeks to optimise the cost of running main packages. It is faster than go run, but currently nowhere near as fast as running something from PATH. However it does obviate the need for setting PATH which is a big win. I'm sure there is more scope for optimisation here, particularly if we can start to build on assumptions about the pristineness of the module cache (arguably if the user messes with the module cache it's their own problem)
one conclusion we (read @myitcv, @rogpeppe and @mvdan) have (almost) reached with gobin to date is that in the "within a module" scenario, polluting the main module with tool dependencies is not good. https://github.com/myitcv/gobin/issues/81 proposes the use of nested modules for this reason
whatever and wherever the solution lies:

it must be able to support further replace and exclude directives, and build flags/constraints
it must be possible to cross compile
version information for all modules (including the main package's module) must be available in the resulting binary

Next steps
This issue has been rumbling in the background for some time now and it seems, to my mind, worthy of tackling given the plethora of problems/issues/common stumbling blocks it would help to avoid (arguments along similar lines to why go env -w is preferable to people setting environment variables). Continuing some sort of gobin-like experiment in x/tools feels like a good next step, regardless of whether that work is adopted into cmd/go or not.
@rsc, @bcmills, @ianthehat - what do you see as the next steps? Any thoughts on how best to proceed from here?

Closing this proposal in favour of #42088 (go run package@version), which neatly solves my original issue.

Closing this proposal in favour of #42088 (go run package@version), which neatly solves my original issue.


Add DownloadDistmapResult check for _SUCCESS on startup

This adds a check to the _SUCCESS file on startup to avoid downloading truncated data due to non-termination of the MapReduce job. This check can be disable with an advance argument to allow the user to download data for debugging, but it is not recommended.
In addition, this commit reformats the code a bit without logic impact and with improved error messages for the download of only some parts (debug argument).
Closes #470

I think it is fine.
Cheers
Rupert
2018-06-06 17:35 GMT+02:00 Daniel Gómez-Sánchez<EMAIL_ADDRESS>
@magicDGS commented on this pull request.
Waiting for @robmaz https://github.com/robmaz comments.
In src/main/java/org/magicdgs/readtools/tools/distmap/
DownloadDistmapResult.java
https://github.com/magicDGS/ReadTools/pull/471#discussion_r193455773:

 public Set<String> partNames = new HashSet<>();

private static final String DISABLE_SUCCESS_CHECK_ARG_NAME = "disable-success-check";
@Advanced
@Argument(fullName = DISABLE_SUCCESS_CHECK_ARG_NAME, doc = "Disable the check for the _SUCCESS file on the input folder.", optional = true)

@robmaz https://github.com/robmaz, can you comment on this argument
description? It will appear as an advance argument in the help, but maybe
we can be more explicit in that this is not recommended unless you know
what they are doing. Any suggestion for the phrasing?
In src/main/java/org/magicdgs/readtools/tools/distmap/
DownloadDistmapResult.java
https://github.com/magicDGS/ReadTools/pull/471#discussion_r193456408:

@@ -113,16 +118,35 @@ protected void onStartup() {

 }

/** Find all the part files **/
private void findPartFiles(final Path inputPath) {

   // first check the _SUCCESS file

   if (!disableSuccessCheck && !Files.exists(inputPath.resolve(SUCCESS_FILE_NAME))) {

@robmaz https://github.com/robmaz - I opt for only check the existence
if requrested, but do not log a warning if the argument is specify. The
idea is that if the program fails in the first place, and the user
specifies the argument, it should be aware of the error message. If someone
use always the argument, it is their own responsibility.
Are you ok with this?
In src/main/java/org/magicdgs/readtools/tools/distmap/
DownloadDistmapResult.java
https://github.com/magicDGS/ReadTools/pull/471#discussion_r193456604:

@@ -113,16 +118,35 @@ protected void onStartup() {

 }

/** Find all the part files **/
private void findPartFiles(final Path inputPath) {

   // first check the _SUCCESS file

   if (!disableSuccessCheck && !Files.exists(inputPath.resolve(SUCCESS_FILE_NAME))) {

       throw new UserException(String.format(

               "Unable to find %s file. Input folder might not contain a successful run (--%s to disable this check, which might produce a truncated output).",

               SUCCESS_FILE_NAME, DISABLE_SUCCESS_CHECK_ARG_NAME));

Are you ok with this message or you wanna something more specific?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/magicDGS/ReadTools/pull/471#pullrequestreview-126431710,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ad_FfO04NDTukNyUmYeBqWlvhL_O1Hgkks5t5_bDgaJpZM4Uc4Ix
.

Thanks for looking at it. @robmaz!


Revert "Registry api code migration"

Reverts partially-complete NASA-PDS/registry-sweepers#3

My fault for not marking #3 as Draft


Add uniarg for new feature

UniArg helps extending argument from pop() to pop()/stack()/const(), which is useful in wasm instruction extension.

Wrong PR target, sorry for the mistack.


Ability to Choose Destination file (instead of same directory)

For some contexts, I think having the option to decide where the output file is going to fall is a convenient option and I don't think it would require a lot of work or add complexity.
Thoughts?

@kingmatusevich You can already decide where your output will go simply by using the cd command before you invoke other-transcode. Your request is actually a duplicate of issue #9 where I've detailed my reasoning for not implementing this. Sorry.

@kingmatusevich BTW, choosing the output filename isn't feasible either since other-transcode can take multiple inputs.


Fixed Flow Errors

I've bumped the version of flow in our project so that it matches with react-native's flow version (0.33). It fixes this weird error:
node_modules/react-native/Libraries/EventEmitter/EmitterSubscription.js:0
EmitterSubscription. Duplicate module provider
current provider. See: example/node_modules/fbemitter/lib/EmitterSubscription.js:0

node_modules/react-native/Libraries/EventEmitter/EventSubscription.js:0
EventSubscription. Duplicate module provider
current provider. See: example/node_modules/fbemitter/lib/EventSubscription.js:0

node_modules/react-native/Libraries/EventEmitter/EventSubscriptionVendor.js:0
EventSubscriptionVendor. Duplicate module provider
current provider. See: example/node_modules/fbemitter/lib/EventSubscriptionVendor.js:0

I'm new to flow. So, I haven't yet figured out why it is not picking up libraries ex-navigation and react-native-vector-icons from example/node_modules.
I ignored @exponent/ex-navigation in .flowconfig since the library had tons of flow errors. Didn't make sense to have those errors in our flow results.
Otherwise, the changes I've made are obvious enough I believe. Do let me know if everything is in order. Thank you.
Fixes #50.

Thank you. You'll need to add following so that the module not found error is gone,
module.name_mapper='^exponent$' -> 'emptyObject'
module.name_mapper='^@exponent/ex-navigation$' -> 'emptyObject'

Same for any other module you ignored. i'll go to sleep now. Will review properly tomorrow.

I haven't yet figured out why it is not picking up libraries ex-navigation and react-native-vector-icons from example/node_modules

It's because they aren't there as travis runs npm install only on the root directory. We might need to change the travis script to something like this so it installs for both,
language: node_js
cache:
  directories:
    - $HOME/.npm
    - $HOME/.yarn-cache
    - node_modules
node_js:
  - 'stable'
before_install:
  - npm i -g yarn
install:
  - yarn
  - cd example && yarn
script:
  - npm run flow -- check
  - npm run lint

@satya164 I ran npm install inside the examples directory and tried. It was the same case. Module not found errors popping up. So even if Travis runs npm install inside examples, we'd have the same problem.
For now, I'm adding the name_mapper you proposed.

@sreejithr That's weird. Probably we need to add those into the devDependencies of the main project itself.
cc @grabbou

@satya164 Ya we can do that. But how about having flow setup inside the example project?
And if a npm run-script flow in the root directory won't run flow in subdirectories, we can make the flow command do flow-bin in both root and example directories.

@sreejithr We'd have to set it up at 2 places then. Having flow in root project gives us errors and autocompletion when working on it.

@satya164 I'll research about getting flow detect node_modules in subdirectories first.

@sreejithr Thanks :)


Add rubocop support with dpn_cops baseline and TODO file

Closing this because it will not work on code climate.