[Core] Add logging to understand what's going on

There should be some logs indicating what's going on when the migrations are running.
This would definitely help end users.

Any progress on this?
I've recently encountered several cases where my app is hanging on startup which I believe is due to liquigraph (probably while trying to lock the DB). Since there is nothing in the logs, this is hard to investigate...

Hi, thanks for the reminder. We're currently working on infrastructure and did not get back to this issue.
Would you like to submit a PR or review one? This should not require too much effort.
This is an important one, we'll try to push something asap otherwise.

@geld0r sorry to resurrect an old discussion, but some work has been done now and merged into master. Feel free to check https://github.com/liquigraph/liquigraph/commit/fa9d07e1836bc7dd98f981fc0b6e21c6920fe151 and reopen this issue if you think some important details have been left out.


Add trinkets (unobtrusive armor slot extensions)

Adds Trinkets 3.7.1 to client+server

Was reviewing it just now, looks good. merged before I could


remove old featuregates

These are now enabled by default and don't need to be in our list.

/lgtm

/lgtm


Bug bounty testing - please do not approve  vuqbqf

Bug bounty testing - please do not approve  vuqbqf

This repo is in maintainence mode. Please check as we moved Koalas to Apache Spark. Please check https://github.com/apache/spark/tree/master


Chore cover with tests

Cannot find module '../util/file' from '/home/travis/build/d6u/web-playground/lib/ServeAssets/getRoot.js'
travis-ci is case-sensitive. Try updating all references to util/file to util/File.

lib/util/Assets.js: Cannot read property 'postProcessors' of undefined Looks like mockPlayground should also mock css in createAssetFileIfNotExist test?

Current coverage is 89.70%

Branch #13 has no coverage reports uploaded yet.

No diff could be generated. No reports for master found.

Powered by Codecov. Updated on successful CI builds.

@nanek :+1:


With v7Lib v22.1.1 app:theme is now deprecated.

Since upgrade to appcompat-v7:22.1.1
I/ViewUtils﹕ app:theme is now deprecated. Please move to using android:theme instead.

I fear that this library is abandoned

Where did you find app:theme? I can't find any reference to it in the source code.

I don't look for the source code. I use maven and when I update the appcompat-v7 Lib to v22.1.1 ,the logcat show this info when my app is init......

I had to bail on this and moved to:
https://github.com/mikepenz/MaterialDrawer
It's more work, but Mike is prolific about keeping the lib updated.

This is a major issue, would be great if there was some workaround...


fix: SimpleMenu - trigger style props as "IconButton"

What does it do?
Update the style props applied to the SimpleMenu/MenuTrigger component, in case of this trigger is used as a IconButton.
Why is it needed?
To fix the problem that the SimpleMenu/MenuTrigger, when used as IconButton, is not showing the icon inside the button (due to the button-padding applied, not lefting any space to render the icon-svg into it).
How to test it?
Running the Storybook locally, or checking the online preview.
Check that the v2/SimpleMenu is displaying the Icon inside the trigger-button, when using the combined props:
<SimpleMenu as={IconButton} icon={<More />}>
  ...
</SimpleMenu>

Related issue(s)/PR(s)
#1418

Is this PR still relevant ? @udimberto

Not anymore, @HichamELBSI, thank you


[WFLY-9035] TransactionAttribute annotation is inherited from interface which not according to the spec

Jira: https://issues.jboss.org/browse/WFLY-9035

@stuartwdouglas Stuart, can you please check it?

retest this please


Prevent duplicate usernames based on IP

there is a possibility of duplicate usernames causing confusion

i've solved this for know we do user#id  and id is calculated based on ip


Cleanup some errors in typedef comments and remove duplicated HOWTO f…

Was confused by some of the comments which referenced no longer existent files, so I fixed those.
Also, zbuff_decompress.c contains a comment block that is similar to zbuff.h (but is slightly out of date) so I removed it.
davidlam-mbp:zstd davidlam$ diff ./header_doc src_doc
14,17c14,16
< *  The content of `dst` will be overwritten (up to *dstCapacityPtr) at each function call, so save its content if it matters, or change `dst`.
< *  @return : 0 when a frame is completely decoded and fully flushed,
< *            1 when there is still some data left within internal buffer to flush,
< *            >1 when more data is expected, with value being a suggested next input size (it's just a hint, which helps latency),
---
> *  The content of @dst will be overwritten (up to *dstCapacityPtr) at each function call, so save its content if it matters, or change @dst.
> *  @return : a hint to preferred nb of bytes to use as input for next function call (it's only a hint, to help latency),
> *            or 0 when a frame is completely decoded,
21c20
< *  output : ZBUFF_recommendedDOutSize== 128 KB block size is the internal unit, it ensures it's always possible to write a full block when decoded.
---
> *  output : ZBUFF_recommendedDOutSize==128 KB block size is the internal unit, it ensures it's always possible to write a full block when decoded.

Should we/I also add comment to zbuff.h saying that functions there will be deprecated by equivalent ones in zstd.h?

These are good points @david-y-lam .

Should we/I also add comment to zbuff.h saying that functions there will be deprecated by equivalent ones in zstd.h?

Yes

updated


Twitter Home timeline

Hello,
Could you tell me how to have my Twitter Home timeline? The names in andstatus are not the same.
Thank you.

Hello,

I just did clean install of AndStatus,
pressed "Get started" of the first screen,
selected Twitter type of social network,
logged in on the Twitter's web page as "andstatus1",
authorized my app on a prompt,
and I was automatically forwarded to this Home page (see screenshot below).

At what step do you have a problem?

I am french so my phone uses French language. On my timelines I have one called "Principale" (please see screenshot below), I suppose (but I am not sure) it is the "Accueil" (Home) timeline.

So to check, I changed the settings in AndStatus to use English in the app. But the "principale" timeline didn't change and is still called "principale" (it should have switched to English I suppose).
Thank you.

Looks like this is a bug: Names of timelines are always in Device default language, and not in the selected "App language".
I will fix this now and let you know!

@arnauldb I made a fix plus updated translations, please test v.56.04 from here: https://github.com/andstatus/andstatus/issues/456

I made a fix plus updated translations, please test v.56.04 from here: #456

Thank you. I installed through F-Droid so I prefer to wait for a F-Droid update rather than installing an .apk directly.


Don't issue a code reload after migration

The migration of the data wasn't happening first?

It is but the pin response handling that happens after we query generates a codeChanged event with state change regardless: https://github.com/SmartThingsCommunity/SmartThingsEdgeDrivers/blob/main/drivers/SmartThings/zigbee-lock/src/init.lua#L101


Return 400 request errors from Shippo

Currently the detail field equals response.__all__, which is undefined.
Instead, pass back the body of the response.

Correction... sometimes response.__all__ is defined and sometimes it's not. Emailed Shippo for clarification here.

@kevinburkeshyp Should we wait to merge until we hear back from Shippo? I'm sure you've thought about it already, but we can probably try to get this merged upstream if this is the right move in the end.

Potentially... the error handling should handle all cases here, unless Shippo decides to add multiple levels of nesting to their 400 Bad Request responses.
Shippo handled this by setting detail: JSON.stringify(response), which I think is a little more brittle, the  parser we have in ShippoValidationError can handle anything you throw at it but would leave a JSON string alone. https://github.com/goshippo/shippo-node-client/blob/master/lib/Resource.js#L132

FWIW just talked with shippo and they're committed to keeping the current error structure for now. The parser I have currently can handle strings or objects or __all__ or whatever you throw at it. Voting to keep this as written and do error parsing/handling in our own code.

(I also sent them the details of how we're parsing error responses so they should know if they update the format and break it)

Okay, since it sounds like Shippo won't be changing anytime soon +1

+1


A question about epoch time breakdown

Dear author of BNS-GCN,
I have a question about the epoch time breakdown.

For the first time in the picture, is it the computation time or is it the total time of one training epoch?
I have already added --no_eval argument. But the time breakdown results are still strange and seem not following the results in the paper. That's why I ask this question.
Thanks!

Thank you for your interest to BNS-GCN. It represents the total time of one training epoch.

Thanks for the reply. I will close the issue.


BSOD   page fault in nonpaged area

Hi, thanks for your work.
When I try to manual map my driver, I get BSOD and error code is "page fault in nonpaged area", any ideas?
thank you very much

If hello world driver loads fine there is a problem in your driver, make sure you are not using driver entry params, and you have set custom driver entry, page fault in non paged area just mean that an exception occurred in the memory area of your driver


LoRa ?

Hi Martin,
I've tried your repeater mod and it works very well. Now I'm wondering if this could be extended to really great distances with two esp8266 connected to LoRa modules (eg. SX127x based ones or similar SPI bus based LoRa devices). That would be truly amazing!

Might work and I have actually ordered two of these LoRa modules already. Technically it might work to treat the LoRa-Link as a kind of a p2p link between two routers. However, the expected bandwidth would be veeeeery slow and IP is because of its overhead surely not the best protocol for this technology. Also putting heavy load on an private LoRa link would violate the fair use policy, as it would interfere with anybody else trying to use LoRa in the area.

Yes, this would be very slow and I don't think it is for video streaming :). I think the implementation could be a reference for any serial type link in the future. LoRa can be a "good" experimental platform since this is the most problematic one. As for the speed: in this case esp8266 would compress raw wifi frame before packetizing for LoRa sending... and other tricks can be used to "speed it up" a bit.

LoRa would be great, and not specifically with LoRa WAN either, the P2P would suffice for general remote data collection. I connected 4 Wemos in series (1 ESP communicates to the next as its AP) using Martins code and connected a Linux device at each level. The Linux machine could browse the web using level 1-3, but level 4 failed... most likely due to heavy delay in relay between each ESP.
How does this relate to LoRa? Sending simple messages across the same setup, say PING to bbc.com, did not seem to suffer a degrading packet loss or increase in round trip time, being 16012ms @ 5% packet loss at each level (not degrading at each level!). So if you only need simple communication, like small IoT MQTT messages, the ESP8266 would be fine in a series (or specifically Star) configuration (say 4 layers at 4096 devices (8^4) in theory). LoRa would be great at the same Use Case, small messages but over longer distance. Would defiantly lower development overheads being able to use HTTP or TCP/IP libraries instead of bespoke radio packet assembly. I would love to test a LoRa version of this!
Great work Martin!!

As @martin-ger said IP is probably not the best protocol over LoRa since it could easily cause unnecessary packets to be sent over a public channel that has limited capacity.
Instead it would be interesting to bridge MQTT over LoRa. This would allow two mesh networks to communicate over LoRa via MQTT. Since MQTT is designed for low bandwidth lossy connections it would match up better with the requirements of LoRa. (You could even use MQTT-SN which further reduces bandwidth)

That's right. Did some experiments with LoRa. It is incredably slow and packets are short compared to WiFi (that's the spec). Doesn't make any sense to do TCP/IP over it. LoRaWAN is a reasonable approach for integrating it into the IoT, MQTT-SN sounds good as well, if you want a pure local setup. Maybe I'll find a student willing to setup a prototype for that...


Update interpreter to calculate cost of the program - for all opcodes

Updated parser to calculate gas for crypto opcodes.
Added tests

LGTM

LGTM


Error running Keras example notebook

I am trying to run the CIFAR10 Keras notebook here on SageMaker, but I run into the following error when I try to create the training job:
ValueError: Error training sagemaker-tensorflow-2018-07-04-02-30-42-260: Failed Reason: AlgorithmError: uncaught exception during training: 'Sequential' object has no attribute 'train_function'
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/container_support/training.py", line 36, in start
    fw.train()
  File "/usr/local/lib/python2.7/dist-packages/tf_container/train_entry_point.py", line 164, in train
    train_wrapper.train()
  File "/usr/local/lib/python2.7/dist-packages/tf_container/trainer.py", line 69, in train
    estimator = self._build_estimator(run_config=run_config)
  File "/usr/local/lib/python2.7/dist-packages/tf_container/trainer.py", line 96, in _build_estimator
    return tf.keras.estimator.model_to_estimator(keras_model=model, config=run_config)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/keras/_impl/keras/estimator.py", line 504, in model_to_estimator
    keras_weights)
  File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/keras/_impl/keras/estimator.py", line 415, in _save_first_checkpoint
    if not model.train_function:
AttributeError: 'Sequential' object has no attribute 'train_function'

I have looked at the Keras estimator code where it is failing here and it seems like the model returned by _clone_and_build_model(...) is not properly wrapping the Keras model so that it has a train_function.

This seems to be a problem with Tensorflow and not SageMaker in particular. I found a relevant issue in the Tensorflow repo here, so I will close this issue and follow that one.


NIFI-7178 - Handle the case when schema is not available

Thank you for submitting a contribution to Apache NiFi.
This little fix contains an NPE fix. This NPE happening in the JsonPathRowRecordReader.java if the schema is not descript all fields in the input JSON.
https://issues.apache.org/jira/browse/NIFI-7178
Description of PR
This little fix contains an NPE fix. This NPE happening in the JsonPathRowRecordReader.java if the schema is not descript all fields in the input JSON.
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

[x] Is your initial contribution a single, squashed commit? Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not squash or use --force when pushing to allow for clean monitoring of changes.

For code changes:

[x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[x] Have you written or updated unit tests to verify your changes?
[x] Have you verified that the full build is successful on both JDK 8 and JDK 11?
[x] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[x] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[x] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[x] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[x] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

+1, merged to master, thanks @taz1988 for your contribution!


can't add route

Hey @oldwang12,
the route is probably missing a name in the second tab (Name & Description)
I agree that this is not pretty obvious and it will be improved in the next release :)
Best,
Eduard

Hey @oldwang12,
the route is probably missing a name in the second tab (Name & Description) I agree that this is not pretty obvious and it will be improved in the next release :)
Best, Eduard

I added it using API

can you share the parameters of your API call?


Search's height was too large, and added spacing to main form.

@peterp I think you can remove the submit-button class

Otherwise +1

+1


Add suport for range subqueries

This commit extends the implementation of subqueries to also cover
range queries. It does that by introducing a generic, timestamp-aware ringbuffer
which can be used to add and drop samples within a certain window.
For now the ringbuffer is only used for subqueries, but the idea is to
also use it in the matrix selector to simplify the windowing logic.

Posting benchmark results for reference
CPU
RangeQuery/subquery-8       81.9ms ± 0%    37.7ms ± 1%   -53.91%  (p=0.008 n=5+5)

Mem
RangeQuery/subquery-8       24.2MB ± 0%    31.5MB ± 0%   +30.49%  (p=0.008 n=5+5)`


is there a way to indicate days, which can't be selected, with regular selector shape of different color?

... or make text for those dates faded?

Hi there. You can just call calendar.selectDate() for you unselectable date. In the calendar, can't be selected means can't be tapped, but selecting with function is not disabled.  You can configure the shape and color of your disabled dates with FSCalendarDelegateAppearance by giving them special selection colors.

hi again. i managed to add borders for specific unselectable cells by using this code
	func calendar(calendar: FSCalendar!, appearance: FSCalendarAppearance, borderDefaultColorForDate date: NSDate!) -> UIColor {
		if self.datesUsed.contains(date) {
			return UIColor.grayColor().colorWithAlphaComponent(0.5)
		}
		return UIColor.blackColor().colorWithAlphaComponent(0)
	}

	func calendar(calendar: FSCalendar!, shouldSelectDate date: NSDate!) -> Bool {
		if self.datesUsed.contains(date) {
			print("date is not selectable")
			return false
		}
		return true
	}

as a result i got this
https://s14.postimg.org/4bzzockl9/Screen+Shot+2016-03-26+at+09.08.01.png
the only thing missing is changing fill color of those disabled days (17, 24, 25). is it possible?

i also noticed the date number is not perfectly centered inside the circles. hopefully that is something that you can fix.

About  changing fill color of those disabled days

call calendar.selectDate to your disabled date. Yes you can do that.
use - (UIColor *)calendar:(FSCalendar *)calendar appearance:(FSCalendarAppearance *)appearance selectionColorForDate:(NSDate *)date function of FSCalendarDelegateAppearance to manager the color of the disabled dates. Please download the example to see the full usage.

About the vertical offset of the day text.

As you can change the font of the day text, the baseline of the font might be different. So the vertical offset of the day text might be different for different font.
If you really want to adjust the y position of the text, use calendar.appearance.titleVerticalOffset and calendar.appearance.subtitleVerticalOffset to adjust it by yourself.

Thanks.

thank you!

No Progress Still Same Issue exist


Feature request: optional forced iri update

Hello,
First: I've had a long and productive talk with h3n. He helped to see things more clearly. Thx.
My problem with the network: There are now several versions in the wild. The most recent is <IP_ADDRESS>. But as hugh network it should stay as monolithic as possible. So older versions should deprecate over time and defunced.
I propose that every nelson installation should be able to learn about new versions automatically. If there is a confirmed new version found then the local node is forced to update (optional but default: on) the IRI at a random point within lets say 30 days. After that plus a grace time the local nelson can discard older nodes because there virtually none.
If you need to install an old version for what ever reason then just switch off this option.
Positive:

One network, one version
~30 days to revoke a version
all nodes have 99.995% uptime within the update time (asuming 30 seconds restart time within these 30 days)
network downtime closest to 0%
new versions only need to know how to talk to version minus 1
option is optional :)
nelsons learn about the version distribution in the network

Negative:

single outdated nodes are bound to their one small world (micro netsplit)

... and no, hardware nodes a unlikely full nodes. So there is no point here.
This can work.
Please discuss it before you close it.
Michael

IMO the Default should be Off, where the end user accepts the liability of enabling this options rather than having it forced on them if they skip over it. situations could arise where say the main repo is compromised someone pushes a malicious update, nelson automatically grabs the update. now we have  rogue nodes that will start propagating through the network as nelson updates, until breach is fixed, and may linger for sometime if the operator doesn't notice and is taking a hands off approach

I also think that auto-updating versions at this stage is risky. Although the last <IP_ADDRESS> simply required replacing the jar file, the last upgrade required to restart IRI with --rescan option due to database scheme updates. It might be the case in the future that an update requires some manual action depending on the instructions provided by IOTA devs.

I think there should be a certain separation of concerns. Nelson just manages the neighborhood. It is not an update manager for IRI. While some kind of automatic IRI updates might be useful, they can also be risky, as suggested above. It has to be discussed outside of the Nelson scope, IMHO.
Thanks for the suggestion, though!


feat: enable changing channel axis

I wonder if we could have similar code as
https://github.com/jina-ai/jina-hub/blob/26faf53637a66d3a0ea30c1b8875e3276faafe4c/encoders/image/ImageTorchEncoder/__init__.py#L88
This is useful in some cases

I am not sure if we should go this way. Since normally ImageNormalizer is needed before most of our ImageEncoders.
Have u checked why it is not working for you adding rhe ImageNormalizer before?

I copy-paste the configuration of ImageNormalizer in our cross model example but still failing. I haven't got too much time to look into it. I guess it's not a big issue but just need some time to check

I am not sure if we should go this way. Since normally ImageNormalizer is needed before most of our ImageEncoders.
Have u checked why it is not working for you adding rhe ImageNormalizer before?

This decreases the dependency of the clip encoder on ImageNormalizer. We can either configure it at ImageNormalizeror here.
Yet the disadvantage I can see is that this will introduce more parameter, which may make ppl confused.

I am not sure if we should go this way. Since normally ImageNormalizer is needed before most of our ImageEncoders.
Have u checked why it is not working for you adding rhe ImageNormalizer before?

This decreases the dependency of the clip encoder on ImageNormalizer. We can either configure it at ImageNormalizeror or here.
Yet the disadvantage I can see is that this will introduce more parameter, which may make ppl confused.

The problem I see is that putting this here, may make the channel being changed more than once. After all, ImageNormalization is always needed.  Also it may be confusing because then there are 2 ways of achieving the same thing.
And since there is no way you will avoid the need to use ImageNormalizer, I would not add this here

I am not sure if we should go this way. Since normally ImageNormalizer is needed before most of our ImageEncoders.
Have u checked why it is not working for you adding rhe ImageNormalizer before?

This decreases the dependency of the clip encoder on ImageNormalizer. We can either configure it at ImageNormalizeror or here.
Yet the disadvantage I can see is that this will introduce more parameter, which may make ppl confused.

The problem I see is that putting this here, may make the channel being changed more than once. After all, ImageNormalization is always needed. Also it may be confusing because then there are 2 ways of achieving the same thing.
And since there is no way you will avoid the need to use ImageNormalizer, I would not add this here

Yes, I agree. Maybe I need to figure out what's the issue with ImageNormalizer.

I am not sure if we should go this way. Since normally ImageNormalizer is needed before most of our ImageEncoders.
Have u checked why it is not working for you adding rhe ImageNormalizer before?

This decreases the dependency of the clip encoder on ImageNormalizer. We can either configure it at ImageNormalizeror or here.
Yet the disadvantage I can see is that this will introduce more parameter, which may make ppl confused.

The problem I see is that putting this here, may make the channel being changed more than once. After all, ImageNormalization is always needed. Also it may be confusing because then there are 2 ways of achieving the same thing.
And since there is no way you will avoid the need to use ImageNormalizer, I would not add this here

I doubt this code could work as expected,

Why is this failing?
!ImageNormalizer
with:
  target_size: 224
  img_mean: [0.485, 0.456, 0.406]
  img_std: [0.229, 0.224, 0.225]
  channel_axis: 0
metas:
  name: normalizer
requests:
  on:
    IndexRequest:
      - !CraftDriver
        with:
          executor: normalizer
    SearchRequest:
      - !CraftDriver
        with:
          executor: normalizer
    ControRequest:
      - !ControlReqDriver {}

Why is this failing?
!ImageNormalizer
with:
  target_size: 224
  img_mean: [0.485, 0.456, 0.406]
  img_std: [0.229, 0.224, 0.225]
  channel_axis: 0
metas:
  name: normalizer
requests:
  on:
    IndexRequest:
      - !CraftDriver
        with:
          executor: normalizer
    SearchRequest:
      - !CraftDriver
        with:
          executor: normalizer
    ControRequest:
      - !ControlReqDriver {}

For example,
because my input data before craft() is (300,300,3), if channel_axis: 0,
then raw_img = _load_image(blob, self.channel_axis) will fail, because the code expect it to be -1.

Why is this failing?
!ImageNormalizer
with:
  target_size: 224
  img_mean: [0.485, 0.456, 0.406]
  img_std: [0.229, 0.224, 0.225]
  channel_axis: 0
metas:
  name: normalizer
requests:
  on:
    IndexRequest:
      - !CraftDriver
        with:
          executor: normalizer
    SearchRequest:
      - !CraftDriver
        with:
          executor: normalizer
    ControRequest:
      - !ControlReqDriver {}

For example,
because my input data before craft() is (300,300,3), if channel_axis: 0,
then raw_img = _load_image(blob, self.channel_axis) will fail, because the code expect it to be -1.

So put channel_axis to be -1. It is a parameter.

Why is this failing?
!ImageNormalizer
with:
  target_size: 224
  img_mean: [0.485, 0.456, 0.406]
  img_std: [0.229, 0.224, 0.225]
  channel_axis: 0
metas:
  name: normalizer
requests:
  on:
    IndexRequest:
      - !CraftDriver
        with:
          executor: normalizer
    SearchRequest:
      - !CraftDriver
        with:
          executor: normalizer
    ControRequest:
      - !ControlReqDriver {}

For example,
because my input data before craft() is (300,300,3), if channel_axis: 0,
then raw_img = _load_image(blob, self.channel_axis) will fail, because the code expect it to be -1.

So put channel_axis to be -1. It is a parameter.

No, -1 won't work as well 😂 . Because Clip expects it to be 0. There's no way to make it work if I didn't modify the ImageNormalizer or the clip encoder

Why is this failing?
!ImageNormalizer
with:
  target_size: 224
  img_mean: [0.485, 0.456, 0.406]
  img_std: [0.229, 0.224, 0.225]
  channel_axis: 0
metas:
  name: normalizer
requests:
  on:
    IndexRequest:
      - !CraftDriver
        with:
          executor: normalizer
    SearchRequest:
      - !CraftDriver
        with:
          executor: normalizer
    ControRequest:
      - !ControlReqDriver {}

For example,
because my input data before craft() is (300,300,3), if channel_axis: 0,
then raw_img = _load_image(blob, self.channel_axis) will fail, because the code expect it to be -1.

So put channel_axis to be -1. It is a parameter.

No, -1 won't work as well 😂 . Because Clip expects it to be 0. There's no way to make it work if I didn't modify the ImageNormalizer or the clip encoder

Ok, so the shape of ur input image is different as in the crossmodal search.
I think it makes sense to add target_channel_axis as parameter

Why is this failing?
!ImageNormalizer
with:
  target_size: 224
  img_mean: [0.485, 0.456, 0.406]
  img_std: [0.229, 0.224, 0.225]
  channel_axis: 0
metas:
  name: normalizer
requests:
  on:
    IndexRequest:
      - !CraftDriver
        with:
          executor: normalizer
    SearchRequest:
      - !CraftDriver
        with:
          executor: normalizer
    ControRequest:
      - !ControlReqDriver {}

For example,
because my input data before craft() is (300,300,3), if channel_axis: 0,
then raw_img = _load_image(blob, self.channel_axis) will fail, because the code expect it to be -1.

So put channel_axis to be -1. It is a parameter.

Just for explanation:
Ideally, I want this:
(300,300,3)->(3,224,244) with crafter->(num_batch, 3,224,224) with clip encoder.
With current crafter and clip encoder:

channel_axis=-1 for crafter: (300,300,3)->(224,224,3) with crafter->(num_batch,224,224,3) with clip encoder. the clip encoder will have error
channel_axis=0 for crafter: (300,300,3)->(224,224,3) with crafter, then there will be errors in crafter.

Why is this failing?
!ImageNormalizer
with:
  target_size: 224
  img_mean: [0.485, 0.456, 0.406]
  img_std: [0.229, 0.224, 0.225]
  channel_axis: 0
metas:
  name: normalizer
requests:
  on:
    IndexRequest:
      - !CraftDriver
        with:
          executor: normalizer
    SearchRequest:
      - !CraftDriver
        with:
          executor: normalizer
    ControRequest:
      - !ControlReqDriver {}

For example,
because my input data before craft() is (300,300,3), if channel_axis: 0,
then raw_img = _load_image(blob, self.channel_axis) will fail, because the code expect it to be -1.

So put channel_axis to be -1. It is a parameter.

No, -1 won't work as well 😂 . Because Clip expects it to be 0. There's no way to make it work if I didn't modify the ImageNormalizer or the clip encoder

Ok, so the shape of ur input image is different as in the crossmodal search.
I think it makes sense to add target_channel_axis as parameter

yes, exactly. I will close this and add that in the ImageNormalizer

Good, thanks for the explanation!!


Curve subgraph missing steth/eth and mim pool, 3pool

resolved in https://github.com/messari/subgraphs/pull/443, which fetches top 100 pools by TVL (rather than default address sort) or allows user to input a pool address


Pass 'encoding' param of VFS' readFileSync to 'toString'

What kind of change does this PR introduce?
Fixes #1133
Checklist:

[x] Unit Tests
[ ] Documentation N/A
[ ] Update CHANGELOG.md N/A
[x] Ready to be merged

Thanks


[cdk8s] ts: Enforce ServiceSpec types

Description of the feature or enhancement:
As of now, most of ServiceSpec types (and others, actually) are string typed. Some props, though, could be easily type enforced in order to avoid errors. externalTrafficPolicy, for example.
Use Case:
We don't want failed deploys due to mistyping. Plus, being aware of the actual configuration options saves us a lot of time when coding (:
Proposed Solution:
Scan kubernetes documentation looking for typing restrictions and implement them in cdk8s.
Other:

[x] :wave: I may be able to implement this feature request
[ ] :warning: This feature might incur a breaking change

This is a :rocket: Feature Request

@jwnx The types of the generated properties are derived from the json schema.
The externalTrafficPolicy property is unfortunately types as a string, not an enum:
https://github.com/instrumenta/kubernetes-json-schema/blob/master/v1.15.0/_definitions.json#L11058-L11060
"externalTrafficPolicy": {
  "description": "externalTrafficPolicy denotes if this Service desires to route external traffic to node-local or cluster-wide endpoints. \"Local\" preserves the client source IP and avoids a second hop for LoadBalancer and Nodeport type services, but risks potentially imbalanced traffic spreading. \"Cluster\" obscures the client source IP and may cause a second hop to another node, but should have good overall load-spreading.",
  "type": "string"

I'm not sure scanning the documentation itself is a sustainable method of enforcing types.
This is exactly the type of stuff that can be solved in cdk8s-plus.
Closing in favor of https://github.com/awslabs/cdk8s/issues/301


how i to scroll horizontal with SliverGrid

i wanted help to go scroll horizontal with SliverGrid

Hi,
This issue doesn't seem to describe a bug or a feature request. Please see https://flutter.dev/community for resources and places where you can ask questions like this.
You may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
Closing, as this isn't an issue with Flutter itself. If you disagree, please write in the comments and I will reopen it.
Thank you


PR for updating and reorganizing docs

After a brief discussion with @bremond and @fperignon, we propose to reorganize a bit the documentation to simplify the organization of the documentation and also to avoid doublons.
The top level of the contents could be as follows

Installation guide
Getting Started
User guide
Examples
Developper doc
Download Siconos
Talks and Presentations
Contacts
Related project and Platforms
Bibliography

In the following comments, I propose to give a list of the most urgent modifications we can implement

Developper Doc
The developper doc contains

Python API documentation
C++ API documentation
The developper  notes (mathematical formalism)

Python API
The documentation contains the documentation of the python code of Siconos that consists in

swig generated files.

todo: doxy2swig generation has to be updated and improved

python code (for instance in io.swig.io)

todo: the documentation in the code has to be reported using sphinx (automodule, ...) or pydoc

We must also move the documentation on the usage of the Python API  to the user guide or to the tutorials


[WIP] perform the actual migration to JUnit 5

feel free to push changes to this branch
This migrates most of the tests to JUnit 5 -
though it doesn't migration the assertions library itself.
Currently broken is the FieldParametricTest since I didn't finish migrating
the parameterization. That will happen 'soon'

OK, I've created a branch too in my fork for the migration to JUnit 5, since I cannot push directly to this branch. I already had some of the test classes fully migrated and committed in my local repository before you created this branch, so there were some merge conflicts when I rebased my local branch onto yours, but I've reviewed them all, and the only conflicting changes made by you I've overwritten were the imports and the parentheses next to the previously parameterized Test annotations for test methods where an exception should be thrown.
I'm not sure, but i think that, if the branches are merged via GitHub, GitHub creates an extra merge commit, making the history look ugly, so maybe you'd prefer to pull my branch into your local repository and push it to this branch, provided you agree with my commits. But I've only been here for a short while, so I don't know what the usual modus operandi in situations like this is.

@Schamschi lets work off of this branch (I could give you write access). once we have a correct diff, I'll squash and commit (giving you appropriate credit). This way we could use git for development, but avoid merge commits.

I invited you to edit my fork of commons-numbers.

Excellent, thanks. I suggest that we wait with the fraction module until the branch fraction-dev is merged to the master branch, to reduce the chance of conflict.

@Schamschi I just merged master and pushed. Note this is a force-push so you may need to recreate the branch (I'm not 100% sure why that was required, but what's done is done)

Thanks for letting me know, and it's a good thing you did, because with this force push, you overwrote my migrations of 13 classes from the gamma module, which I had already pushed to the branch. Luckily, I still had them saved in my local repository so I could re-commit them, but the next time you do this, could you please first update your local copy of the branch?
Also, when you merged the master branch, you overwrote several changes from the fraction-dev branch when resolving the arisen merge conflicts. Some of these overwrites were beneficial, e.g. converting tabs to spaces or removing redundant whitespace, but some, i.e. those where you refactored the code to use assertThrows, were problematic, because in some cases the merge from the fraction-dev branch to the master branch caused the test methods to invoke different methods/constructors than before, and when you resolved the merge conflicts, you reverted the test methods to invoke the old methods/constructors, which in some cases did not exist anymore, causing the code to be not compilable.
I think I have fixed these issues now with my latest commmit.

but the next time you do this, could you please first update your local copy of the branch?
I think I figured out what I did wrong: my branch was set up to track origin/master instead of our working branch. thus, when I did git pull it didn't actually do what I wanted.

because in some cases the merge from the fraction-dev branch to the master branch caused the test methods to invoke different methods/constructors than before, ... I think I have fixed these issues now with my latest commit.

Thank you.
Right now the only things failing are
[ERROR] /Users/eax/svn/apache/commons/numbers/commons-numbers-arrays/src/test/java/org/apache/commons/numbers/arrays/LinearCombinationTest.java:[39,29] incompatible types: long cannot be converted to java.math.BigInteger
[ERROR] /Users/eax/svn/apache/commons/numbers/commons-numbers-arrays/src/test/java/org/apache/commons/numbers/arrays/LinearCombinationTest.java:[40,29] incompatible types: long cannot be converted to java.math.BigInteger
[ERROR] /Users/eax/svn/apache/commons/numbers/commons-numbers-arrays/src/test/java/org/apache/commons/numbers/arrays/LinearCombinationTest.java:[41,29] incompatible types: long cannot be converted to java.math.BigInteger
[ERROR] /Users/eax/svn/apache/commons/numbers/commons-numbers-arrays/src/test/java/org/apache/commons/numbers/arrays/LinearCombinationTest.java:[44,29] incompatible types: long cannot be converted to java.math.BigInteger
[ERROR] /Users/eax/svn/apache/commons/numbers/commons-numbers-arrays/src/test/java/org/apache/commons/numbers/arrays/LinearCombinationTest.java:[45,29] incompatible types: long cannot be converted to java.math.BigInteger
[ERROR] /Users/eax/svn/apache/commons/numbers/commons-numbers-arrays/src/test/java/org/apache/commons/numbers/arrays/LinearCombinationTest.java:[46,29] incompatible types: long cannot be converted to java.math.BigInteger
[ERROR] -> [Help 1]

which I'm looking at now

@grimreaper Indeed, this class does not compile (I hadn't noticed until now), however, this has nothing to do with your merge. It was the merging of the fraction-dev branch into the master branch that caused the class LinearCombinationTest to break. Apparently, the class BigFraction does no longer contain a BigFraction(long, long) constructor, so naturally, the class LinearCombinationTest cannot compile. It worked before the merge (you can test it with the master branch).
I'm going to create a JIRA ticket. This is frustrating.

JIRA ticket created.

I had fixed it on this branch, and the upstream fix broke my fix. In any case, master is now merged.

All tests but one test passes now: FieldParametricTest
This class was giving me confusion before too - I have not yet figured out how to create parameterized tests in a similar way to junit 4 via the constructor. I did manage to make this pass by writing an argumentresolver but that seemes like overkill

@grimreaper

I had fixed it on this branch, and the upstream fix broke my fix.

Oh, I'm sorry about that, I obviously forgot to check whether you had already fixed the issue on the branch. Still, apparently this class was not the only one that was broken by the merge of fraction-dev, and since this mess-up occurred on the master branch and not on our migration branch, I think it is better if it is also fixed on the master branch. But it's true, I overlooked the update in this branch. Will try to be more attentive the next time.

I agree  - it should have been fixed on master and I'm not upset or frustrated my fix was ignored :)

@grimreaper Excellent :D By the way, I don't know how much progress you've made with FieldParametricTest, nor have I really looked at this class, but the JUnit 5 user guide says that parameterized tests are currently an experimental feature, meaning it could be removed any time with prior notice (it says so in section 7.1 of the user guide). But as I said, I haven't looked at the class at all, I just thought I'd let you know in case you aren't already aware of this.

@Schamschi  while we're changing stuff - what do you think about static imports for "assertEquals" and friends?

the JUnit 5 user guide says that parameterized tests are currently an experimental feature

I did not notice this, but it may mean that I could just simplify the parameters. There aren't too many so auto-generating tests or just doing single tests in a loop might be sufficient.

@grimreaper

what do you think about static imports for "assertEquals" and friends?

I just stumbled upon a curiosity in the class TestUtils of the commons-numbers-core module, which I've overlooked in my last commit. From looking at the first two methods TestUtils.assertEquals(double, double, double) and TestUtils.assertEquals(String, double, double, double), it seems to me that the assertEquals method invoked in TestUtils.assertEquals(double, double, double) should actually be the one from TestUtils, and not the one from Assert. Maybe this was originally so, and then somebody carelessly refactored the method to invoke the respective method from Assert (it's impossible to tell from the commit history).
I'm not sure if this is an argument against static imports, but in this specific situation, static imports would certainly have caused confusion. Also, I'm not sure whether replacing the explicit Assert/Assertions references with static imports is within the scope of this branch. I could imagine that the commit history would be easier to follow if we just convert everything from JUnit 4 to its closest JUnit 5 equivalent without changing more than necessary in this branch, and changing things like static imports or replacing try-catch-constructs with assertThrows not before the migration is completely performed.
Ironically, the aforementioned assertEquals methods declared in TestUtils are completely pointless anyway, because the assertEquals methods from JUnit4 Assert, as well as from JUnit5 Assertions already consider two NaN doubles equal, so they behave exactly like these methods in TestUtils. But then again, fixing this might be outside the scope of this branch.

I got FieldParametricTest working - it may not be the best way, but at least it passes.

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for Apache Commons Numbers 1.0-SNAPSHOT:
[INFO]
[INFO] Apache Commons Numbers ............................. SUCCESS [  3.892 s]
[INFO] Apache Commons Numbers Core ........................ SUCCESS [  3.600 s]
[INFO] Apache Commons Numbers Complex ..................... SUCCESS [  2.258 s]
[INFO] Apache Commons Numbers Complex Streams ............. SUCCESS [  2.232 s]
[INFO] Apache Commons Numbers Primes ...................... SUCCESS [  2.030 s]
[INFO] Apache Commons Numbers Quaternion .................. SUCCESS [  2.106 s]
[INFO] Apache Commons Numbers Fraction .................... SUCCESS [  2.121 s]
[INFO] Apache Commons Numbers Angle ....................... SUCCESS [  2.063 s]
[INFO] Apache Commons Numbers Gamma ....................... SUCCESS [  5.229 s]
[INFO] Apache Commons Numbers Combinatorics ............... SUCCESS [  5.304 s]
[INFO] Apache Commons Numbers Arrays ...................... SUCCESS [  2.236 s]
[INFO] Apache Commons Numbers Field ....................... SUCCESS [  2.402 s]
[INFO] Apache Commons Numbers Root Finder ................. SUCCESS [  2.288 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  38.109 s
[INFO] Finished at: 2019-06-08T17:58:57-07:00
[INFO] ------------------------------------------------------------------------

Coverage remained the same at 94.381% when pulling fe4d700c02f7560a6940740f8cad4ec09efb5f83 on grimreaper:eax/simple-migrate-map into 924314078a5b76587f766bf711f9efae795c3a15 on apache:master.

@grimreaper Congratulations! I'll continue with the complex-stream and complex module (working my way up alphabetically from bottom to top, for some reason …).
About the fraction module: I see that you have requested that pull request #36 be delayed until after the migration to JUnit 5. However, I would be in favor of merging the referenced pull request already before the migration (provided it is updated so that it can be merged with master), because this pull request has been slowly decaying into oblivion ever since I submitted it, which was both before we started working on the migration and also before the fraction-dev branch was merged into master. At the time of its submission, the pull request conflicted with the development on fraction-dev because I wasn't aware of the active development on fraction-dev back then, so the pull request was not merged. Now, fraction-dev has been merged into master, but of course, now the pull request conflicts with master, so again, it cannot be merged.
So there are two options: I either update the pull request so that it can be merged, or I put it to rest, burying it in the depths of unmerged pull requests and have all the work that went into it go to waste. I'm still undecided on this, but in case I opt for the former, I think it would be much less work to reconstruct the changes that have already been applied to the class FractionTest in the migration branch (which I would be willing to do) than to refactor the pull request to not only be compatible with the merge of the fraction-dev branch, but also with the migration to JUnit 5.
So I'd suggest that we wait with the fraction module until the pull request is closed, whether it is merged or discarded. What do you think?

Sorry about the confusion about fraction-dev. If you can collect these comments into a post for the mailing list and/or a JIRA ticket I will tend to it this week. I had no idea outside modules were calling BigFraction and I'm happy to put the long-based constructor back in.

Also, no force pushing please. There is always a way to avoid it. :)

@ebarnhill Thank you for the offer, but the problem arising from the removal of the long-based constructor in BigFraction has already been fixed after I had created the JIRA ticket which I linked to earlier.

However, I would be in favor of merging the referenced pull request already before the migration (provided it is updated so that it can be merged with master), because this pull request has been slowly decaying into oblivion ever since I submitted it,

I didn't actually see that this was you. In that case go ahead and submit it. My main concern was someone causing merge conflicts indefinitely with our work.

@Schamschi take a look at the current status. Tests still pass, but its more "junit 5" like

@grimreaper Why did you agree to wait for the pull request #36 to be merged (or closed unmerged) and then go ahead and refactor FractionTest anyway? Not only did I replace several Assert.assertEquals pairs comparing the numerator and denominator separately with a single call to the method assertFraction, which already reduces the number of Assert references drastically, but I also added anonymous blocks in the test methods to make them a little less messy, and resolving the conflicts arising from the introduction of these anonymous blocks in a merge or rebase is very laborious – I already did it once yesterday when updating my pull request to be compatible with the changes introduced by the merge of fraction-dev, and the thought of doing it a second time is rather off-putting.
Besides, I don't think assertEquals(a, b) and assertTrue(a.equals(b)) are 100% interchangeable, because, the way I see it, they reflect different intentions, even if they may be functionally equivalent most of the time. Judging by its design and the names for the parameters, assertEquals(a, b) is meant for situations where you have a pre-computed (at compile- or runtime), "expected" value, against which an unknown, "actual" value computed at runtime is checked. But there may be situations where both values are unknown, and one is not necessarily more correct than the other, for example, when comparing two hash codes, or when testing the equals method itself.
Speaking of testing the equals method: Although not done in this case as far as I am aware, I could imagine a scenario where one would want to test of the symmetry of the equals method by testing both a.equals(b) and b.equals(a). assertEquals does not specify whose object's equals method is called, so replacing assertTrue constructs with assertEquals constructs here seems inappropriate. A situation related to this can be found in the class BigFractionTest, line 601, where the original code called the equals method of BigFraction with a Double argument:

Assert.assertFalse(zero.equals(Double.valueOf(0)));

So in this case, it is crucial for the validity of the test that the equals method of the BigFraction instance zero is called, and not the equals method of the Double. However, in its current version, the equals method of Double is called:

Assertions.assertNotEquals(0.0d, zero);

0.0d is implicitly boxed to Double, and since assertNotEquals calls the equals method of the first argument (which is an implementation detailed and not documented), the test becomes useless.
By this logic, there are situations where I find your conversion from assertTrue to assertEquals absolutely beneficial, for example, the testParse() method in the class ComplexTest from the "complex" module, or testMath843() in PrecisionTest in the "Core" module, thank you.
Also, the original parameter order for assertEquals in SmallPrimesTest was correct, and your change to the file ArithmeticUtilsTest in the commit "Simplify junit" also has the parameters in the wrong order, but I don't have time to fix it now, maybe you can tend to it if you get back here before I do.

@grimreaper PR #36 has been merged into master. Since you said it's OK if the pull request is merged, I completely overwrote the previous version of FractionTest from this branch with the new version from master when merging master into this branch, and restored the changes that had been made to FractionTest in this branch up to that point. From then on, I migrated the file from scratch, meaning I didn't include any of your later changes (this is exactly the scenario I wanted to avoid by agreeing on which pull request should be merged first before any major changes are performed in this branch that would conflict with the other pull request).
I also removed the last unused imports, so the branch is now completely independent of JUnit 4.
I, on my part, am finished with this branch. Do you intend to work any further on it? If not, what to do next? Write to the dev mailing list? I guess the pom.xml will have to be modified to remove any dependency related to JUnit 4, but I'm not sure how, since I didn't understand all of the changes made to it when adding JUnit 5 as a dependency alongside JUnit 4.
In any case, thank you very much for your help.

@Schamschi I would try locally just removing these lines:
    <dependency>
      <groupId>org.junit.platform</groupId>
      <artifactId>junit-platform-runner</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.junit.vintage</groupId>
      <artifactId>junit-vintage-engine</artifactId>
      <scope>test</scope>
    </dependency>

These are to support JUnit 4. If your branch has no JUnit 4 then it should be OK.

, on my part, am finished with this branch. Do you intend to work any further on it? If not, what to do next? Write to the dev mailing list?

Yes. We should send it to the list for review. After that we should squash the changes into a single commit and merge.

I guess the pom.xml will have to be modified to remove any dependency related to JUnit 4, but I'm not sure how, since I didn't understand all of the changes made to it when adding JUnit 5 as a dependency alongside JUnit 4.

I'll follow up with that after the merge.

From then on, I migrated the file from scratch, meaning I didn't include any of your later changes (this is exactly the scenario I wanted to avoid by agreeing on which pull request should be merged first before any major changes are performed in this branch that would conflict with the other pull request).

Sorry about that. I got carried away and kind of forgot :/

Also, thank you for all your help: you did the crux of the work.


NoMethodError: undefined method `schema_format' for ActiveRecord::Base:Class (NoMethodError)

Hey all :wave:
After upgrading our Rails (7.12 on Ruby 3.2.2) app to the latest hairtrigger version 1.1.0, when running rake db:migrate we get the following exception:
NoMethodError: undefined method `schema_format' for ActiveRecord::Base:Class (NoMethodError)

We are using postgres and the sql dump format. Downgrading the gem back to 1.0.0 resolves the issue for our application.

Fixed https://github.com/jenseng/hair_trigger/pull/118

thanks everyone, and sorry for the trouble! the fix has been released in v1.1.1

Wow that was a quick turnaround, thanks @ollym @jenseng!! I checked on our app and on 1.1.1 the issue is resolved :+1:


Added code to reduce APK size

shrinkResources true : for Resource shrinking
minifyEnabled true : for Code Shrinking
More details Here: https://developer.android.com/studio/build/shrink-code

haha thanks


Fix loop in diff_iso_date

Closes #29
Fixes the issue that was being causing diff_iso_date to loop and notes it for the future.
Adds the test case that was causing the initial issue.

There's an issue with calculating negative durations. I'm working on updating the above.


plant ovary adaxial epidermis (PO:0005024) & vary abaxial epidermis (PO:0005023)

The PO terms "plant ovary adaxial epidermis" (PO:0005024) and "plant ovary abaxial epidermis"(PO:0005023) use the words adaxial and abaxial in a very unusual way. The adaxial side of the ovary has traditionally been used to refer to the side of the ovary that backs on the inflorescence axis (in first order branching systems), and the abaxial side is the side that is adjacent to the subtending bract. In the current terms "adaxial" is used to refer to the central axis of the flower, a use that is almost completely unknown in plant anatomy. These terms would make much more sense if they were changed to be "plant ovary inner epidermis" (PO:0005024) and plant ovary outer epidermis" (PO:0005023). The revised terms would then more clearly refer to the epidermis that lines the locules (PO:0005024) and the epidermis that surrounds the ovary on the outside (PO:0005023).

"plant ovary adaxial epidermis" (PO:0005024) and "plant ovary abaxial epidermis"(PO:0005023)  have been renamed "plant ovary inner epidermis" (PO:0005024) and plant ovary outer epidermis"(PO:0005023).  The current names have been added as related synonyms.
names have been corrected in related terms as well. The changes will be available on the Planteome Development browser (http://dev.planteome.org/amigo) tomorrow (reloads nightly) and on the live Planteome site (http://planteome.org/amigo) after the next db release, probably about mid-April 2019.


Adding support for North Central US and South Central US

Hi @ShirleyWang-MSFT, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (shwang). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, or work for Microsoft Open Technologies, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;


Bench Bot for Release Weights

@mordamax and I figure it makes sense to make the bench bot also run the release weight benchmarks, which are currently still ran manually by RelEng on bm4, 5, & 6 (not BM3).
The way it works now is that it runs benches for all pallets in per-runtime batches, so we have 4 jobs right now (rococo, westend, kusama, polkadot), and then we're manually applying the changes to our release branch. Having only 3 machines to run in parallel, we can't run them all at once - so i think it would make sense to

add a 4th bm machine for this
allow us to queue these jobs using the bench bot
commit the results back to the pr/branch where it was triggered

This is essentially very similar to what it does right now when ran for individual pallets in a PR.

it's also important to not use bm3 for this as to not block the bench bot for other devs during this time, which has been a complaint in the past.

as I learnt from @alvicsam, ci-cd team won't add 4th BM for release automation due to https://github.com/paritytech/ci_cd/issues/583
so we need to migrate first, and then we get a new tag for this, and only then we can implement it in command bot


The tooltip loses its position when typing and deleting large amount

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open web chrome
Click on + icon and click on send money
Place your mouse on the currency and notice that the tooltip is in center
Now without moving your mouse, just type in large number and delete it
Notice that the tooltip loses its position

Expected Result:
The tooltip should not lose its position when typing and deleting large amount continuously
Actual Result:
The tooltip loses its position when typing and deleting large amount continuously
Workaround:
unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

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

Version Number: 1.2.90-4
Reproducible in staging?: y
Reproducible in production?:  y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:
https://user-images.githubusercontent.com/43996225/228030251-531fe5f4-3d24-433e-9835-fd351c566638.mp4
https://user-images.githubusercontent.com/43996225/228030268-65ad256e-dda3-4322-9705-597dd9237de3.mp4
Expensify/Expensify Issue URL:
Issue reported by: @priya-zha
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1679902897561019
View all open jobs on GitHub

I do not think that the tooltip should show when the cursor is not hovering over anything actionable - That would not be expected, closing as not a bug


A first attempt at creating a rake task that generates fake patient data

I rule and have completed some work on Case Manager that's ready for review!
Hallo! Based off of Colin's request and starter code outlined in #1835, I built a rake task that generates fake randomized patient data, including external pledges, calls, practical supports and fulfillments -- accounting for the fact that some of them is null. You can run the task by running rails db:seed:create_fake_data. This is a first stab! Edits and suggestions super welcome.
This pull request makes the following changes:

Created a file called create_fake_data.rake in lib/tasks
In that file, in the namespace db:seed, created a rake task that generates fake patient data 5000 times

Question/musing for @colinxfleming:

The randomized logic wasn't at all based on reality (e.g. 75-80% fulfillment rate -- I just made fulfillments for fake patients whose index numbers are even and has a pledge sent). I wasn't sure whether they need to be!
What else would be helpful? Tests? Logs?

oh ps on your questions: if you know off the top of your head how to make the rates a little closer then go ahead and adjust the math, but don't put more time than that into it, as we can always tune it later.
Don't worry about tests or logging - if you want to be thorough you can add a puts Patient.count  at the end similar to what the seeds file does but I've never really gotten much mileage out of testing rake tasks themselves like that, and what we're doing here isn't production-facing anyway.

Hiya! I incorporated some of your comments, but not sure if my modulo stuff makes sense. Would love to chat about it more. Didn't really have anything off the top of my head to make the rates closer to reality, but would love to be present when folks are fine-tuning that! :) Another thing that could be done better is making sure the external_pledge + patient_contribution + fund_pledge doesn't exceed/isn't under the procedure_cost.

(FYI still working on this — getting some help reducing the use of rand! :)

@harumhelmy what's next steps on this, anything I can help with to push it over the finish line?

Thanks for the patience and the bump, @colinxfleming! Got some help from @amackcrane and learned things about seeding Ruby's pseudo-random number generator. The task spits out the same thing every time now! It's still missing some demographic information, and I'm wondering if that's something we want, as well, and how realistic we'd want that information to look (i.e. how taking into account the gaps in our CMs data collection). I guess I'm still unclear how the data wranglers will use this.

The goal of having this rake task around is that when an analyst is hacking on our data or trying to build a report, we'd like to provide them a kinda-close example of what it looks like, without actually having to give them a real pull. We have gaps in our real-life data, too, because we don't require demographic fields and CMs don't always drop them in, even for folks who get pledges.
I think this looks pretty good to my eyes - @harumhelmy please mark this ready when you feel done working on it and we can get it in. (I think it's mergeable for sure, but want to make sure you don't have any punchlist items left!)

Thanks Colin! Marked it as ready for now — I figured we can always add more demographic info later.


ERROR.....

Hi,
I try to run your example but I get Error......and I can't run it.
Also can you make your class compliant from iOS 8.0
Thank you in advance
George Gerardis

HI.
IOS8.0 has a lot of ui problems. So iOS8.3 or later support.
Thank you.

오후 2:16, George<EMAIL_ADDRESS>작성:

Hi,
I try to run your example but I get Error......and I can't run it.
Also can you make your class compliant from iOS 8.0
Thank you in advance
George Gerardis
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/dave-ios/DPDropDownMenu/issues/2, or mute the thread https://github.com/notifications/unsubscribe-auth/ABVOXo2ikMCkmSwGXMVzkdsBujUMJ6tfks5r78irgaJpZM4Nhf3D.


Return a new circuit object after execution

This fixes an issue I was having with my ClockListAnnotations being duplicated.
h/t @azidar

@azidar can you explain how this fix works?

Yes, so right now, the contract for Transformations is that they receive all annotations, but only pass on the ones they add. Then, between running transformations, the compiler will merge the new annotations with the other annotations (it saves them before passing the CircuitState to the transformation).
I think this is a bad API, and most certainly should be changed, because it makes this error super easy to do, and debugging it is very difficult unless you know where to look. This has been on my plate for some time, but seemed like a low priority item.

@azidar thanks for the explanation. Will probably escalate as people start writing their own transforms


Clean up server.js

Server.js has become larger over time taking on a bunch of functions that would be better split out into utilities.  This streamlines server.js back to basics making it easier to see what's going on.
Notes:

Moves the locations whitelist into the locations directory - keeping all the location functionality in a single place

Moves sending email validation & logic into the email directory

Moves Raven and anything that was a standalone function into a utilities file.

oh no!


Need validation for item id: property

I had a devil of a time trying to figure out what was going on with a new item that I was adding to our ssl-certificates vault.  When I ran the knife vault create ssl-certificates item-name -J item.json -A... -S... command, it reported success.  But when looking on the chef server, I would only see an item-name.net_keys item without any matching item-name item in the data bag.  Moreover all subsequent attempts to interact with that item via knife vault would fail with a message: ERROR: ChefVault::Exceptions::ItemNotFound: ssl-certificates/item-name does not exist, use 'knife vault create' to create.
  I had failed to update the id property and so the id property was the same as another already existing item in that data bag.  As a result, instead of writing a new item-name item into the bag, it was overwriting the old-item-name item!  Suffice it to say this is bad.
Knife vault needs to validate that the id value of the json matches the name of the item being created/updated and if it does not match, fail with an appropriate message.
Strictly speaking this issue may properly belong to the knife utility itself.  I did not test it with a regular data bag but they may present the same problem.  However, it is especially problematic for vault and I think vault should protect itself defensively from this issue.
This is with chef-vault 2.5.0.

knife data bag create does let you specify an item name on the command line, then change that item name by changing the 'id' attribute.  The issue with knife vault create is that the name of the keys item has been set prior to letting the user edit the data bag (or in your use case populate it from the JSON document).
It should be fairly simple to add validation to ensure that the id of the keys data bag item equals the name of the data bag item suffixed with _keys, and bomb out if that isn't the case.  With luck, just a couple of lines added below validate_id!(item_id) in ChefVault::Item#save.
As this is more an enhancement to protect users from invalid input as opposed to a bug in chef-vault itself, I'll target this for the next release, which I hope should be out in the next month or so.

Works for me.  Anyone who shoots them self in the foot like I did in the mean time will hopefully find this post.

I've added protection for this in the branch issue_149_validate_id, which I plan to merge into the upcoming 2.6.0 release by end of week.


Can I use this package to do online path planning ? If yes how can I do that ?

This in not a support channel. Please only open issues if there is actually something wrong with the code. If you have questions pose them here: http://discuss.px4.io/

Okay thank you

@mrivi  would you please help me with that ?


Add Support for AVIF Images

Summary
AVIF is a new image format supported by all major browsers that has far better image compression than WEBP.
https://jakearchibald.com/2020/avif-has-landed/
Motivation
Better page load performance.

I don't really know what "major browsers" you are talking about, because according to Can I Use AVIF image file formats are only supported by Chrome 85<=

Firefox is behind a flag and support will be turned on very soon, Edge is now Chromium based, so also has it. Apple created the thing, so they won't be that far behind. That's all major browsers right there.

Firefox is behind a flag and support will be turned on very soon, Edge is now Chromium based, so also has it. Apple created the thing, so they won't be that far behind. That's all major browsers right there.

I didn't disagree with your idea, I was just showing that the Avif image format is not supported by all major browsers currently...

Hey,
i have checked the roadmap and @hjvedvik as added a entry which sounds similar to this enhancement:
https://github.com/gridsome/gridsome/projects/2#card-27048529
If the image processing as a dedicated plugin, we could create could replace it easily with a another one ( like AVIF, webp etc.).


term.refresh problems

Executing a term.refresh doesn't seem to be actually refreshing.    I've had to modify the resize method with a custom method for a few reasons, and that's working well.   But after a resize I'm calling:
    term.refresh(0, term.rows - 1);

And I would expect it to redraw the existing contents to fit the resized screen.   But it doesn't appear to be happening at all.   If the screen is set to smaller, the text is just cut off.       Any new lines added fill the space properly.   I've been trying to add some breakpoints in to figure out if it's being called, but no success thus far.
EDIT: Even inspecting the this._terminal.rowContainer() element before its' being appended on the refresh shows each line being cut off instead of being put on to the next line.   Further researching this shows that as it's working through the number of lines, when it calculates the width of the terminal, it is just cutting off the content at that width and it's just disappearing from the dom instead of being put onto the next terminal line.
Details

Browser and browser version: electron 1.7.8
OS version: mac os 10.12.6
xterm.js version: 2.9.2

I think you're after this feature which we don't support yet: https://github.com/sourcelair/xterm.js/issues/622


Bumped development release number for 1.30

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm

/approve

/unhold


takeWhileInPlace overshoots bounds

ArrayBuffer(true, false).takeWhileInPlace(_ == true)

throws an out of bounds exception (as do all the mutable sequences).
(ListBuffer also throws an index out of bounds exception--should check to make sure this is working efficiently.)

Fix #409 first--this one is probably a consequence of that?

Yes indeed.

Fixed by #423.


search results alphabetical order

I need the results with alphabetical order. How can i achive this? Anyone help me

Try this little plugin to sort your results:
http://tinysort.sjeiti.com/


[Query Tracker] Add ability to pass DECLARE parameters to YQL queries

YQL supports DECLARE syntax for parameters passed outside of query text
Currently, there is no way to pass them via query tracker api. We need to support that
We need to add ability to pass parameters to YQL queries started with start_query API
One way to do it is to parse "settings" of the query

Current workaround is to use FileContent in a query and pass files via files parameter of start_query
Example

any updates?


19450 - Accessibility: Header of SI standalone filing - logged out

*Issue:19450 *https://github.com/bcgov/entity/issues/19450
Description of changes:
Accessibility: Header of SI standalone filing - logged out
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the namex license (Apache 2.0).

/gcbrun

Temporary Url for review: https://bcregistry-btr-dev--pr-120-9qqyva0x.web.app


Add the slack platform support

?

Please could you response me quickly?

@nykma could you take a look by next Monday?

I'll take a look after this CI check is passed.

Rewrite

Why this error?

shell script error

Run again
go build config/main.go
./main

Look at the first line of the shell script file
[ -f "config/main.go" ]

Your CI check is failed. It's not CI's fault.

Reply me on telegram

Reply me on telegram

@ars0x Hi, Thanks for your contribution.
Please communicate here to make this context visible to other community members.


Add Query Capability: find order by customer_id to the model

Hey team! Please add your planning poker estimate with Zenhub @even1111112 @PepperandSummer @un-poco @yjhsieh2022


Supports live resizing (sdl2 only)

Today, when the window is resized content is black or just partially drawed. This is because poll() is blocked until we release the mouse.
But we can catch the resize event in the event filter. So the idea is to catch and force the window resize, and force drawing. Works like a charm.
Tested on OSX 10.14 with SDL 2.0.5 and retina screen.
Credits goes to @arafangion for the initial code.
Fixes #2844

Works like a charm :+1:


proposal: cmd/go: standard-library vendoring in module mode

This proposal is both a fix for #26924, and a means for users to explicitly upgrade the golang.org/x dependencies of the standard library (such as x/crypto and x/net).
Proposal
The standard library will ship with three go.mod files: src/go.mod (with module path std), src/cmd/go.mod (with module path cmd), and misc/go.mod (with module path misc).
The std and cmd modules will have vendor directories, containing modules.txt files in the usual format and managed using the standard Go 1.13 vendoring semantics (hopefully #30240).
The std and cmd modules differ somewhat from ordinary modules, in that they do not appear in the build list.

No module outside GOROOT/src may declare its own module path to begin with std or cmd.
No module may explicitly require, replace, or exclude any module whose path begins with std or cmd. (Their versions are fixed to the Go release in use.)

For files within GOROOT/src only, when we resolve an import of a package provided by an external module, we will first check the build list for that module.

If the build list does not contain that module, or if the version in the build list is strictly older than the one required by the standard-library module containing the file, then we will resolve the import to a directory in the standard library, and the effective import path will include the explicit prefix vendor or cmd/vendor.

The explicit prefix ensures that no two packages in the build will have the same import path but different source code.
It also ensures that any code loaded from a valid module path has a corresponding module in the build list.

If the version in the build list is equal to than the one required by std or cmd, that version is not replaced in the main module, and the package exists in the corresponding vendor directory, then we will load the package from vendor or cmd/vendor with its original import path.

This eliminates network lookups if the main module is std or cmd itself (that is, if the user is working within GOROOT/src).
We assume that the code in GOROOT/src/vendor and GOROOT/src/cmd/vendor will remain pristine and unmodified.

If the version in the build list is greater than the version required by std or cmd, or if the version is equal and the module is replaced, then we will load the package from the module cache in the usual way.

This may cause substantial portions of the library to be rebuilt, but will also reduce code duplication — which should result in smaller binaries.

(CC @rsc @bradfitz @jayconrod)

I am strongly in favor of using modules for vendoring in the standard library, instead of ad-hoc copies, but I don't see the reason to let applications override standard library dependencies. Was this widely requested, or something we wished we had often?
Speaking for x/crypto, I actually don't want to have to figure out if a crypto/tls internal failure is due to a replaced chacha20poly1305.
Also, I don't see why we'd let users override vendored dependencies but not standard library packages. The difference between golang.org/x/crypto/chacha20poly1305 and crypto/aes should be an implementation detail of crypto/tls. Then why can one be overridden, and the other not? Feels arbitrary.

cc @ianthehat
I share some of @FiloSottile's concerns. Allowing users to override std dependencies, especially crypto dependencies, is scary. But not allowing this would be against the spirit of modules.
There are some safeguards here, but I'd love to solve this without making the module resolution and package loading logic more complicated.
Possibly dumb, low-tech idea: what if we vendor these modules without using vendoring? We could run go mod vendor, then rename the vendor directory to something else (internal/vendor_) and fix up the imports? That would fix #26924 and move complexity out of cmd/go, into tools.

what if we vendor these modules without using vendoring? We could run go mod vendor, then rename the vendor directory to something else (internal/vendor_) and fix up the imports?

We have that today, in internal/x. We could fix #26924 using the same strategy in cmd, if we're ok with code duplication for the x repos. (The goal of this proposal is to reduce that duplication.)

@FiloSottile

I don't see the reason to let applications override standard library dependencies. Was this widely requested, or something we wished we had often?

It has come up at Go team summits from time to time, and while we don't see many complaints about upgrading x repos explicitly, we do see fairly frequent complaints about binary sizes (#6853 is canonical).
The two are closely related, in that one way you can end up with an overly-large binary is by pulling in a redundant copy of an x repo from the standard library.
Per my favorite quote from C. A. R. Hoare's Hints on Programming Language Design:

[L]isten carefully to what language users say they want, until you
have an understanding of what they really want. Then find some way of
achieving the latter at a small fraction of the cost of the former. This is
the test of success in language design, and of progress in programming
methodology.

Speaking for x/crypto, I actually don't want to have to figure out if a crypto/tls internal failure is due to a replaced chacha20poly1305.

We probably should start requesting the output of go list -m all in the issue template, for precisely that reason. (The same problem can occur when someone reports an issue against x/net, and that has ~nothing to do with the standard library.)
But consider the opposite direction, too: wouldn't it be nice for folks to be able to, say, test the interaction of TLS 1.3 with their dependencies written against 'net/http`, without having to also run a bleeding-edge version of the compiler and runtime (with any associated runtime bugs)?

Also, I don't see why we'd let users override vendored dependencies but not standard library packages. The difference between golang.org/x/crypto/chacha20poly1305 and crypto/aes should be an implementation detail of crypto/tls. Then why can one be overridden, and the other not? Feels arbitrary.

That seems like a great argument for making many of the standard-library packages thin forwarding shims around x/ packages. I may file that proposal, in fact, but it's separate from this one. 🙂

I'm definitely sympathetic to reducing code duplication and binary size, but I'm also concerned about complexity and special cases.
I think we should resolve #26924 using the internal/x approach in order to unblock other module work for 1.13, and we should talk further about modularizing the standard library after 1.13. Just to confirm my understanding, converting cmd/vendor to cmd/internal/x would not significantly increase binary or SDK download size, right?

@bcmills @FiloSottile

We probably should start requesting the output of go list -m all in the issue template, for precisely that reason. (The same problem can occur when someone reports an issue against x/net, and that has ~nothing to do with the standard library.)

This is the same reaction I had when I saw the objection over updating the std lib versions. Make it easy and known how to list module versions and request it in issues. I also remember when Azure had to vendor a patched version of crypto/tls to access to hit their TLS endpoints in their SDK, then fork the world to make it reference the fork.

@jayconrod, in looking at the details of this, it seems to be by far the simplest way to make module-mode vendoring work for vendoring in the standard library.
go mod vendor uses the import graph to figure out which packages to copy, so it's much simpler to have the module-provided packages in the import graph than to try to build some other analysis (and vendoring tool) specifically for the standard library.

I don't disagree with including go list -m all in issue reports, but it still does not make me feel good about letting users swap chacha20poly1305 backends to crypto/tls. TLS already has too many joints, and joints in cryptography are where things break. I'd rather not to have to keep in my head an extra dimension of the compatibility matrix.

@bcmills I agree that this is probably the simplest way to make module-mode vendoring work in the standard library in terms of new code that needs to be written. My concern is that this makes package loading harder to reason about. In particular, this proposal means that you may get either one or two copies of some packages, depending on what version the main module requires or whether it has a replacement. We have the same risk of conflict with exported types or global state as we do today, but  now the risk is more subtle.
Here's a possible alternative (with some drawbacks at the end):

The Go SDK ships with go.mod files for std, cmd, and misc, as described above.

Imports starting with std/, cmd/, or misc/ are resolved to those modules. This will require new logic, but it would replace existing GOROOT / GOPATH package resolution.
These modules may have normal requirements on x/tools, x/net, etc.

The Go SDK ships with a pkg/mod directory, which would contain dependencies of the standard modules. It would be in the normal module cache format. It would act as a fallback read-only cache before going to the network.
For packages that should not be user-replaceable (i.e., chacha20poly1305), we would create private copies in internal/x. I'm hoping there wouldn't be many of these, so we could still mostly avoid code duplication in binaries.

I think writing a tool to do this would be fairly straightforward. Maybe this is something gorelease should do.

I'm realizing some drawbacks to this approach though, as I'm typing this out.

This would increase SDK size, since pkg/mod would include sources for packages we don't depend on. Not sure how much this would add.
Our dependencies on x/tools, x/net would effectively set global minimum versions for those modules. MVS would override user requirements on older versions.

Our dependencies on x/tools, x/net would effectively set global minimum versions for those modules.

Not only that, but all of their transitive dependencies too: for example, various parts of x/net and std currently depend on x/text, and x/text has a dependency on x/tools via golang.org/x/text/cmd/gotext and golang.org/x/text/message/pipeline. x/tools has a fairly broad dependency graph (see #29981), so we would be setting minimums for a lot of arbitrary modules.
Note that everything in cmd should be a package main, so nothing can import it. That makes the cmd module a bit easier to handle than std, since it mitigates the code bloat from using a vendor directory: we know affirmatively that no binary that links against cmd will also link against a redundant x repo.
misc is similar to cmd: it does not have a globally-addressable import path, so the only time you can build anything in misc is if it's the main module.

@FiloSottile

TLS already has too many joints, and joints in cryptography are where things break. I'd rather not to have to keep in my head an extra dimension of the compatibility matrix.

I can certainly sympathize with that, but in that case, is there a fundamental reason for the implementation of crypto/tls to live in the standard library at all?
That is: if it's that tightly coupled to x/crypto, why not make it a forwarding façade over an implementation in x/crypto? That would preserve the advantages of decoupling the release cycle and reducing code bloat, while keeping the compatibility dimensionality roughly equivalent to x/crypto today.

To summarize so far: it seems that there are some concerns about the module-upgrade behavior, but no objections to the remainder of the proposal.
Since a lot of this work needs to happen early in the cycle, I'm going to go ahead and implement a more limited form: for now, we'll always resolve dependencies of the standard library to the packages in the vendor directories, and we'll only treat them as part of the external module if the working directory is within the std or cmd module proper.

TLS already has too many joints, and joints in cryptography are where things break. I'd rather not to have to keep in my head an extra dimension of the compatibility matrix.

I can certainly sympathize with that, but in that case, is there a fundamental reason for the implementation of crypto/tls to live in the standard library at all?
That is: if it's that tightly coupled to x/crypto, why not make it a forwarding façade over an implementation in x/crypto? That would preserve the advantages of decoupling the release cycle and reducing code bloat, while keeping the compatibility dimensions roughly equivalent to x/crypto today.

Making the implementation of crypto/tls swappable is interesting, and I had explored a different approach in #21753. However, I'm not sure we want to move something so core to most applications to x/crypto. For example, the security release process of x/crypto is far, far weaker.
Maybe we could still make main security releases which just bump the x/crypto dependency, but there's a lot of moving parts to this all, and I'd like to see it as a separate proposal.
(Also, I'm not convinced by the argument that a x/crypto dependency that I don't want to be a joint makes crypto/tls  substantially different from any other standard library package.)

I'm not convinced by the argument that a x/crypto dependency that I don't want to be a joint makes crypto/tls substantially different from any other standard library package.

Agreed, but I think the point generalizes: any package in std that is tightly coupled to one in x could be replaced with a forwarding shim that isolates the coupling within the module.

I have two questions about this proposal.

The standard library will ship with three go.mod files: src/go.mod (with module path std), src/cmd/go.mod (with module path cmd), and misc/go.mod (with module path misc).

The standard library has a policy on which packages are allowed to import which others. It's codified in:
https://github.com/golang/go/blob/889aa5eb98ff2a5134f5b075525479da399e5c4f/src/go/build/deps_test.go#L23-L24
Have you considered following the L0/L1/L2/(L4+everything else) tiers there to guide std lib module boundaries (e.g., having stdl0, stdl1, stdl2, stdl4modules rather than a singlestd` one)? Would there be benefits in doing so?

The std and cmd modules differ somewhat from ordinary modules, in that they do not appear in the build list.

What is the motivation to make these modules differ from ordinary modules?

Have you considered following the L0/L1/L2/L3/(L4+everything else) tiers there to guide std lib module boundaries (e.g., having stdl0, stdl1, stdl2, stdl3, stdl4 modules rather than a single std one)? Would there be benefits in doing so?

That's an interesting idea, but one of the nice properties of this proposal is that the module boundaries follow the same rules as for ordinary module boundaries: std encompasses the whole tree from src/go.mod up to cmd/go.mod. That allows us to use ordinary module-mode logic for things like vendoring when within that tree, with minimal tweaks to remove the std prefix.

What is the motivation to make these modules differ from ordinary modules?

std is tightly coupled to the compiler and runtime, so attempting to upgrade or replace it independent of the rest of the toolchain would be extremely error-prone.
Similarly, cmd is tightly coupled to the compiler: it's not at all clear what things like go tool vet should do if you've replaced cmd with something else.

Before proceeding with the vendoring changes, I would feel a lot better if @rsc and @ianthehat LGTM'd this proposal, and I want to make sure @FiloSottile is satisfied. What do you think about holding a feedback session?

We plan to make the standard-library vendor directories work in 1.13, but will defer for a later release the decision on whether (or how) to allow user modules to upgrade them.
(That is: for 1.13, the std-vendored modules, viewed from outside std, will continue to be treated as packages in the standard library and not part of the corresponding external module.)

any progress for this proposal?

We've recently had a case that touches @FiloSottile's comment. Working with a broken device containing borked certificate we needed to modify crptoybtes (https://groups.google.com/u/1/g/golang-nuts/c/wlhj5RFXh9g). Unfortunately it was a huge endeavour to apply this patch consistently throughout local, ci and docker build. We are aware that this patch is not suitable for upstream or any other purpose but it would have been convenient to have a simpler way of applying it.
Is there anything that could move this proposal into the active column of the proposals project?

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

/cc @matloob @bcmills

It sounds like people are generally OK with this. There is some question about whether there are problems with x/crypto being too tied to the main repo, but if so we should find and fix those.

Are there any objections to making this change?

Over the past few years we actually brought a lot from x/crypto into std, so these days only chacha20poly1305, hkdf, and cryptobyte are vendored into the standard library. This makes upgrading x/crypto both less troublesome and less useful.
I find it a bit weird to expose upgrading these specific packages but not anything else in the stdlib to applications. Why can they upgrade ChaCha20Poly1305 but not AES-GCM? Why can a X.509 parsing bug be fixed with a replace if it's in cryptobyte but not if it's in the crypto/x509 caller? These is no answer because we never designed that boundary to be meaningful: vendoring a package was an implementation detail, not a visible decision. This change would expose it.
Looking at the full list of vendored packages, this doesn't feel arbitrary only for x/crypto.
# golang.org/x/crypto v0.0.0-20220722155217-630584e8d5aa
## explicit; go 1.17
golang.org/x/crypto/chacha20
golang.org/x/crypto/chacha20poly1305
golang.org/x/crypto/cryptobyte
golang.org/x/crypto/cryptobyte/asn1
golang.org/x/crypto/hkdf
golang.org/x/crypto/internal/poly1305
golang.org/x/crypto/internal/subtle
# golang.org/x/net v0.0.0-20220920203100-d0c6ba3f52d9
## explicit; go 1.17
golang.org/x/net/dns/dnsmessage
golang.org/x/net/http/httpguts
golang.org/x/net/http/httpproxy
golang.org/x/net/http2/hpack
golang.org/x/net/idna
golang.org/x/net/lif
golang.org/x/net/nettest
golang.org/x/net/route
# golang.org/x/sys v0.0.0-20220804214406-8e32c043e418
## explicit; go 1.17
golang.org/x/sys/cpu
# golang.org/x/text v0.3.8-0.20220722155301-d03b41800055
## explicit; go 1.17
golang.org/x/text/secure/bidirule
golang.org/x/text/transform
golang.org/x/text/unicode/bidi
golang.org/x/text/unicode/norm

In other words, it's nice if by luck a bug is fixable by replacing cryptobyte, but I think it would be more useful to talk about this in the broader context of a plan that involves carving out the runtime and compiler independent pieces of std that folks might want to upgrade, like the whole crypto/tls tree, net/http, etc. That would consistently relieve pressure on backport choices and make it easier to adapt to unsupported cases without forking the whole toolchain, which feels like the actual need here.

If the version in the build list is equal to than the one required by std or cmd, that version is not replaced in the main module, and the package exists in the corresponding vendor directory, then we will load the package from vendor or cmd/vendor with its original import path.

Out of curiosity, shouldn't we be able to deduplicate code and get smaller binaries in this case as well? The benefits are only mentioned in the third case (build list has a newer version), but not in this second case (build list has the same version).

@FiloSottile, I agree that this proposal would be more useful if more of the standard library could be upgraded.
The process seems straightforward enough: for a given package in std, define a corresponding package in an x/ repo, and turn the std package into a thin forwarding shim around the x/ package. Then, upgrading the x/ package automatically upgrades the std package as well. We would just need a consensus as to which std libraries should become wrappers, and perhaps extend the main-repo API checks to also run for the relevant x/ packages.

To be clear, this change is not really being made just for x/crypto. It's a step toward a more rational relationship between std and x. We'll see what the next step is after we take this one.

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No module outside GOROOT/src may declare its own module path to begin with std or cmd

Searching for "module std" filename:go.mod on Github yields 339 results, for "module cmd" filename:go.mod there are 485 results.
If I understand correctly, those would break.
If we want to avoid breaking them, we could use for example golang.org/std and golang.org/cmd as the module names instead, as those do not seem to be used now.

std and cmd are already special names, as documented at https://pkg.go.dev/cmd/go#hdr-Package_lists_and_patterns.  I'm a bit surprised that it works to use those as module names.

Looking at search result counts is inaccurate. Those are all copies of the Go source tree.

std and cmd are already special names, as documented at https://pkg.go.dev/cmd/go#hdr-Package_lists_and_patterns

Ah, missed that, thanks for the link! I was checking https://go.dev/ref/mod#module-path before I posted my comment and that page does not mention std nor cmd as special name.

Looking at search result counts is inaccurate. Those are all copies of the Go source tree.

Fair point. I haven't counted how many are copies of Go source tree. Could be that most of them are.
There are some examples that aren't copies of Go source tree:

example 1
example 2

To be clear - I'm fine with disallowing module names beginning with src and cmd, just wanted to point out that there are some existing modules like this in the wild.

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group


Can run a widget notebook twice is failing intermittently

TestResultNotebook-raw-nonConda-3.9--ubuntu-latest (1).zip
Error: Widget did not load successfully during execution
at Timeout.<anonymous> (src/test/common.ts:57:20)
at listOnTimeout (node:internal/timers:557:17)
at processTimers (node:internal/timers:500:7)

This test no longer exists