Error occurs when there is a destructured argument with a return type check.

Causes an error:
const f = (y: t.String, { x }) : t.Object => ({ x, y });

Does not cause an error:
const f = (y: t.String, { x }) => ({ x, y });

Fixed in https://github.com/gcanti/babel-plugin-tcomb/releases/tag/v0.2.1


React can't find the root component node for data-reactid value .5.

Only after loading your component I get React can't find the root component node for data-reactid value .5.
Loading via requirejs data-main attribute.

That's weird, do you mind adding some working snippet or demo repo which I can reproduce this issue?

I'm closing this issue until more details are provided.


Running lldb python scripts only outputs to OUTPUT(lldb) tab.

OS: latest macOS
VSCode version:  latest
Extension version: latest (stable)
Toolchain version: clang
Build target: x86_64_darwin
Python version: Python 3.7.7
I wrote a custom lldb script, but when I run it it doesn't output anything.  It took me a while to realize that it WAS printing, but in the OUTPUT window and not the debug console.  NOTE: I am pretty printing structure/classes with colors so the OUTPUT window also is print my escape chars in my colors.
Thanks for an amazing extension!

Yeah, I'd like to send python script output to the debug console, but it turned out to be not-trivial to do.  I'm still planning to fix it... at some point.

Instead of standard print() you must use result object for that. E. g.
import lldb

def __lldb_init_module(debugger, internal_dict):
    debugger.HandleCommand('command script add -f lldb.print_hello hello')

def print_hello(debugger, command, result, internal_dict):
    result.Print('Hello world')


Added the ability to print the size of the currently downloaded data

Hi @TheZoc ,
just merged the PR. However I had to revert 0c9073c039fda776e54136c58fdb47e59d29abad for the moment since I did some tests and it fails the find the filename correctly. It must be something in the regex but I didn't had time to look into it. Does that work on your side you say?

Hey @ndrplz,
Yeah, it works for me :D
The file you attempted probably has a character that's not being caught by that regexp.
The current regexp is:
[0-9A-Za-z ,.-+()[]]+
Marches any number, upper or lower case letters, commas, dots, minus sign, plus sign, parenthesis or brackets.
Can you provide an example of link that's failing to you?
(You can upload a simple test text file and name it to one or the files you has trouble with).
I'd be happy to improve it :)


Set rent_epoch for updated sysvars to RENT_EXEMPT_EPOCH

Problem
When we create new sysvar, we make sure that its balance is rent exempt. However, we don't force its rent_epoch to be RENT_EXEMPT_EPOCH. Instead, we are relying on rent collection code to set rent_epoch.
In the future, after we skip the rewrite (SIMD_0183 ), we will also disable rent collection SIMD_0175. Therefore, we can't rely on the rent collection code to set rent_epoch.
In this PR, we set rent_epoch to RENT_EXEMPT_EPOCH at the time of new sysvar update time.
Note that this won't affect existing sysvars since they have already all have rent_epoch set to u64::MAX. But it is a "must-have" for disable rent collection code.
A quick scan of all sysvars on mainnet shows that all of them are rent exempt and have rent_epoch set to RENT_EXEMPT_EPOCH. This is good news, which means they won't be affected by this change.
sysvar account: SysvarStakeHistory1111111111111111111111111<PHONE_NUMBER>3709551615 114979200
sysvar account: SysvarRecentB1ockHashes11111111111111111111<PHONE_NUMBER>3709551615 42706560
sysvar account: SysvarS1otHistory11111111111111111111111111<PHONE_NUMBER>3709551615 913326000
sysvar account: SysvarS1otHashes111111111111111111111111111<PHONE_NUMBER>3709551615 143487360
sysvar account: SysvarC1ock11111111111111111111111111111111<PHONE_NUMBER>3709551615 1169280
sysvar account: SysvarEpochSchedu1e111111111111111111111111<PHONE_NUMBER>3709551615 1120560
sysvar account: SysvarFees111111111111111111111111111111111<PHONE_NUMBER>3709551615 946560
sysvar account: SysvarLastRestartS1ot1111111111111111111111<PHONE_NUMBER>3709551615 946560
sysvar account: SysvarRent111111111111111111111111111111111<PHONE_NUMBER>3709551615 1009200
sysvar account: SysvarRewards111111111111111111111111111111<PHONE_NUMBER>3709551615 1002240

However, there is a very small risk for breaking consensus -the behavior of creating sysvar changed. Without the PR, sysvar was created with rent_epoch = 0 and it set to u64:max at its rent scan time. With this PR, sysvar was created with rent_epoch=u64:max. Luckily, there is only one pending feature that introduces new sysvar - partitioned reward feature in v2.1.
If we backported this PR, to v2.1 and wait for the majority of the nodes on the cluster to have this change, before we activate partitioned reward feature, then we will be fine. And all future new sysvars will follow the new pattern with rent_epoch=max at creating time.
Summary of Changes

Set syavar rent_epoch at init time
Fix tests

Fixes #

does this have to be backported to 2.1 if we hope to activate skip rewrites?

Not required for skip rewrites.
We are still doing rent scan after skipping rewrites. So we should be fine.
However, this is required before we stop rent scan.

adding @jstarry here to review.

So this behavior change means that new sysvars would have their rent epoch set to Epoch::MAX at creation. In the case of the epoch rewards sysvar, once the partitioned rewards feature is activated, we need either all nodes to be running this patch or all nodes to not be running this patch.

Luckily, there is only one pending feature that introduces new sysvar - partitioned reward feature in v2.1.

Partitioned rewards is ready for activation in v2.0 actually

If we backported this PR, to v2.1 and wait for the majority of the nodes on the cluster to have this change, before we activate partitioned reward feature, then we will be fine. And all future new sysvars will follow the new pattern with rent_epoch=max at creating time.

Since partitioned rewards will be enabled very soon on devnet and also likely be enabled mainnet in less than a month once mainnet is on v2.0, I don't think it's a good idea to merge this without a feature gate. There's no urgency in getting this issue patched, I think it can be tied to whatever feature gate we use for https://github.com/solana-foundation/solana-improvement-documents/pull/175

Instead of the approach in this PR, I would prefer a PR that uses a feature switch to update inherit_specially_retained_account_fields from INITIAL_RENT_EPOCH to RENT_EXEMPT_RENT_EPOCH. That way we cover not only new sysvars, but also new builtins and precompiles.

Also just a note that I wrote about changing the initial rent epoch to RENT_EXEMPT_EPOCH for builtins, sysvars, and precompiles here in this SIMD: https://github.com/solana-foundation/solana-improvement-documents/pull/175

Also just a note that I wrote about changing the initial rent epoch to RENT_EXEMPT_EPOCH for builtins, sysvars, and precompiles here in this SIMD: solana-foundation/solana-improvement-documents#175

Sounds good to me. I hate to introduce another feature gate. I like that we roll this into together SIMD175.

We will roll this change when we implement feature SIMD175.


Small documentation updates

There were some small glitches in docstrings that were causing errors in sphinx and also a few older changes to margin docstrings that were hanging around in an unnoticed branch.
No changes in code.

Coverage remained the same at 88.798% when pulling 0c78aff417740595f7fd0bac2e0af83a5b76619e on murrayrm:doc_updates into 9c6c61983f59b71bdbc5d57d50c26359c8c14560 on python-control:master.


Blogpost: ADO-recordset as datasource

Publish a blogpost to let people know that you now also can have an ado recordset as datasource

Published on 15.01.2022


Added swift-log-ecs to README.md

I've created a new logging backend for SwiftLog in order to log in ECS Log format. Updated README.md to include the library.
Motivation:
I created the library for any own use with Vapor but hopefully it will be useful for others as well. Can be used independently of Vapor and chained with other LogHandlers.
Modifications:
Updated README.md to include swift-log-ecs in the list of libraries.
Result:
README.md will include swift-log-ecs in the list of libraries.
P.S. If a PR is not the correct way to let you know about new libraries let me know and I'll close the PR and resubmit in the appropriate manner.

@swift-server-bot test this please


build_message_send_dict: Tweak message.realm access.

message.realm is always already set at this point in the codepath. message.sender.realm not necessarily, so that access can trigger a query. In particular it does here in populate_db in send_messages:
    for message in messages:
        message_dict = build_message_send_dict(message=message)

causing a useless realm fetch in a loop.
The assert is tweaked to go by id instead of object comparison - right now it doesn't make a difference because as mentioned, message.realm is always already fetched, but might avoid a fetch in the future and is just a better practice in general in these query-count sensitive codepaths.
Eliminating this query in a loop in populate_db reduces the amount of time taken up by this message_dict block in manage.py populate_db in my machine by 1 second - from ~7.5s to ~6.5s.

Ping on updating this, since it seems valuable to not lose track of.

Yeah, that makes sense -- we're already resolving what realm the message is when we create the Message object a bit earlier in the flow.


optimize UID->Username mapper

include a hardcoded list of all UID/username exceptions, for which Hash(username) != uid
use a batch lookup interface to grab many Usernames in one round trip
make sure we check the server's work
use mem and disk caching

So this guy is unused right now?

Yeah, unused except it's tested in unit tests

Ok I think it would be like a 1 line change to use this in chat, so that is great!

Cool, thanks @mmaxim. Yeah it should be pretty speedy.

@mmaxim all ready to go, sorry it took so long to get through CI and merging.

Thanks! I tried to use this, but it looks like something on prod is missing. Will try tomorrow.

it needed fresh code. launching that now.

ok, done


Models store reference to the training data

I think this will make it easier to implement a batch optimizer that needs to know about all the current training data.

This has now been implemented. Closing.


Installation

Hey Sir does it runs on windows? If not then how to I run it on linux?

Yes, it does run on windows, otherwise why would there be a windows binary.
One problem with windows is, that Microsoft does not ship a SCTP driver, so you would have to find your own one.
cheers
/daniel

And does it intercepts the messages of the subscriber

What exactly do you mean with 'And does it intercepts the messages of the subscriber' ?

Is this the Hack of the ss7 to attack the target?

No.

how do i get start this github

not sure why you want to start github. please clarify.

Just want to be a programme
On Sep 13, 2017 5:24 PM, "Daniel"<EMAIL_ADDRESS>wrote:

not sure why you want to start github. please clarify.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ernw/ss7MAPer/issues/16#issuecomment-329151101, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AeZhf2NlPNLLle67z1Gcyo4Ihsj5dbuFks5sh8mNgaJpZM4Mzey6
.

You can be a program, i believe in you!

Thanks dear
On Sep 14, 2017 12:54 PM, "Daniel"<EMAIL_ADDRESS>wrote:

You can be a program, i believe in you!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ernw/ss7MAPer/issues/16#issuecomment-329403771, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AeZhf4yi_B0h2cFNEjRQWmew8eUwBBZIks5siNu8gaJpZM4Mzey6
.


Possibility of detect the sleep stages on less than 5min of data

Hello,
I am using the automatic sleep staging module to detect sleeping subjects on 5 minutes of data (i know the model has been trained on long night sleep but the accuracy looks good enough in my case) but sometimes because of some cropping I have subjects with 4min58 of data and so they are left out.
Is there a reason why SleepStaging() cannot be instantiated on raw instance containing less than 5 minutes of data ?
I was wondering if it was possible to turn the 'not enough data' error into a warning but maybe there are technical issues (for example some smoothing windows with an hardcoded minimum length etc) that would make the possibility tedious to enable ?

Hi @nabilalibou,
Your intuition was right: the main reason for such a duration threshold is that YASA uses 7:30 min smoothing windows. I don't think we want to completely disable this duration threshold in YASA, but you can manually do it by to cloning YASA, installing it from the source (python setup.py develop) and then disabling this line:
https://github.com/raphaelvallat/yasa/blob/ae9ccc7fc5fd31ea0618bec59fed6b2dbf3edff7/yasa/staging.py#L204

Ok so removing the assertion allows yasa to function without any other errors on <5min data even if there is a 7:30 min smoothing windows that will be applied ?
Thx for the tips but I admit that if the only blocker is the assertion, I'd be very happy if this was replaced by a warning so that I can use the source version of yasa directly on data less than 5 minutes old 😁.
Is it a matter of restricting yasa scope to long night of sleep because you're really not sure about the model's performance on nap data ?

Ok so removing the assertion allows yasa to function without any other errors on <5min data even if there is a 7:30 min smoothing windows that will be applied ?

I actually have never tried it so I don't know, but I think most likely yes, although the output might be unreliable.

Is it a matter of restricting yasa scope to long night of sleep because you're really not sure about the model's performance on nap data ?

Indeed, but feel free to submit a PR to replace the assertion by a warning 👍

Indeed, but feel free to submit a PR to replace the assertion by a warning 👍
Will do!


Pod article missing PodAffinity

Pod article Chinese version lacks Podaffinity chapter
https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#Pod

/triage accepted
/language zh

/assign

It looks like the task has been accomplished.
/close


Fix ResponseCache handling for Android usecases

Please see the commit comments for details.
I'd also like to propose a subsequent change to make the purpose of this code more obvious:
We move the following classes into an okhttp/okhttp-android-support sub-build + include it in the standard build (but in the same packages as they are today. The okhttp-android-support code would only be for Android to use, but by keeping it in the okhttp git repository we avoid future pain when Android pull from upstream, plus we reduce the amount of Android-specific junk in okhttp-httpurlconnection.
Move these:

AndroidShimResponseCache
OkCacheContainer
android/HttpResponseCache + Test
internal/huc/JavaApiConverter.java + Test
internal/huc/CacheAdapter.java

AFAIK, the only thing stopping this is the following method on OkUrlFactory. We could move this code into okhttp-android-support in the appropriate package (e.g. a static method in com.squareup.okhttp.AndroidInternal):
/** Sets the response cache to be used to read and write cached responses. */
public OkUrlFactory setResponseCache(ResponseCache responseCache) {
if (responseCache instanceof OkCacheContainer) {
// Avoid adding layers of wrappers. Rather than wrap the ResponseCache in yet another layer to
// make the ResponseCache look like an InternalCache, we can unwrap the Cache instead.
// This means that Cache stats will be correctly updated.
OkCacheContainer okCacheContainer = (OkCacheContainer) responseCache;
client.setCache(okCacheContainer.getCache());
} else {
client.setInternalCache(responseCache != null ? new CacheAdapter(responseCache) : null);
}
return this;
}
What do you think?

This is a great idea, and will make future maintenance much easier! Want me to review as-is? Or do you want to create the new okhttp-android-support build first?

I'm happy either way. It looks like I have the morning here before you will be awake so I'll make a start on the rearrangement and see how I get on. If I make good progress I should be able to update this one easily enough afterwards.

Done, with a slight detour after I discovered a change over the weekend that broke the Android code. Feeling good we'll spot these things more easily in future with the third / main commit.

Dig. Do you mind rebasing this?

Rebased. Down to a single commit now.

Thanks!


[Update to PR #662] fix duplication of array_annotations into annotations

Handling Issue #748
The issue arises from this part of the loading routine which adds properties which are an array_annotation to a corresponding nested dict within neo_attrs, but also adds them as a regular annotation, therefore creating a duplicate.
nixio.py line 1237-1244 (in method _nix_attr_to_neo):
                elif prop.definition == ARRAYANNOTATION:
                    if 'array_annotations' in neo_attrs:
                        neo_attrs['array_annotations'][prop.name] = values
                    else:
                        neo_attrs['array_annotations'] = {prop.name: values}
                else:
                    values = list(values)
                neo_attrs[prop.name] = values

It seems that PR #662 intended not to duplicate the array_annotations, but the duplication was then introduced with the merge commit 0a4ccfae4aca7d854d3f1065bd8782136981f1ab
Please comment @Kleinjohann ?
The PR separates the properties again, to be either stored directly in neo_attrs, or in neo_attrs['array_annotations'] but not both.

It seems that PR #662 intended not to duplicate the array_annotations, but the duplication was then introduced with the merge commit 0a4ccfa
Please comment @Kleinjohann ?

You are right, this is my fault, I remember something weird happening to that code block in the merge and it seems I did not resolve it correctly.


Adding OAuth to deployment

Hi,
I tried to enable OAuth login on a deployment:
  uaa:
    login:
      oauth:
        providers:
          federation:
            type: oauth2.0
            authUrl: ***
            tokenUrl: ***
            issuer: ***
            redirectUrl: ***
            scopes:
              - openid
              - email
              - profile
            linkText: Login with OAuth
            showLinkText: true
            addShadowUserOnLogin: true
            skipSslValidation: false
            attributeMappings:
              user_name: email

The section is included in the final deployment file, but there are no changes on the UAA side. Is this feature currently not enabled, or why does it not get applied?

@fhanik thank you, correct. oauth: (( merge )) was missing in the base template and as result not merged.


Support for iOS

Hi @Winterreisender !
I was exploring this library for my current project and looks very interesting but I found that is not compatible with all platforms. It would be interesting to have this library also compatible with iOS.
Many thanks in advance!

Duplicated to #13:

Thanks for your feedback. But unfortunately our upstream project, webview, does not support iOS, so we can't do that. This repo is only a Kotlin binding for webview. If you need supporting new platforms, you could send you feedback to webview. Though it would be quite challenging (I need to buy some expensive Apple devices), I would be happy to try making Kotlin wrappers after webview adding iOS support.


If this board is to be a Upduino update, ask around in the community for improvements :)

Was just checking github for upduino related things, I have a 2.0 :)
There were a lot of complaints on the 1.0, the 2.0 is a lot better, but probably still not prefect.
I think one point of attention might be the crystal and how it's connected, since the internal 'clocks' are not very stable on this fpga :) But I'm not an expert, I literally only just started with them a week ago :)
I like the Upduino's simply because of the price point and breadboard friendly-ness making it a great little starter board for Maker projects, and people/students trying to learn FPGA. That and the open source toolchain, which is awesome of course :)

@cranphin  I agree with you. This low-cost platform makes sense to me which is why I agreed to taking on the responsibility of maintaining this and pushing it forward.
Am open to feedback and improvements! Could you please fill out the following survey to give your feedback.
https://www.surveymonkey.com/r/7YFGGY6
Also, any suggestions on forums where I can request feedback would be most welcome!

Hi!
Awesome, I wasn't sure if there would be a reply :)
I know that people had some fun and complaints with the Upduino 1.0:
https://twitter.com/oe1cxw/status/950083493073178625?lang=en
But maybe those same people would have suggestions on improvements, ping them a Twitter? :)
I will fill in your survey, at another time, in my timezone it's far too late already :)
You could always try posting a question on https://electronics.stackexchange.com/ also :)
I'll hope to come with more suggestions later :)

At work now, so not much time either, but some small things while I remember them:

To do direct programming of the FPGA (instead of via SPI flash), two 0 ohm smd bridges need to be unsoldered and resoldered, which is close to impossible. Only using flash isn't that big a deal to me, but for a fast development cycle it can be usefull to switch to direct programming more easily, for example with jumpers or switches :)
The green led connected to CDONE (D2) is rather bright, and there's no way to turn it off once the fpga is running (as far as I know). It's minor, I know :)
There's some confusions around the pins in many places/documents, I think partly also cause of faults in the original Lattice documentation. For example the RGB pins are often wrongly numbered, even on the diagram. With icestorm toolchain the following is true:
set_io led_r    41 # On board RED Led
set_io led_g    39 # On board GREEN Led
set_io led_b    40 # On board BLUE Led
But I don't know if the numbering in icestorm is correct either :)
It would be most useful to make sure at least the info here is correct, it can be determined by just writing some sample programs :)
I'm not sure what's up with the two leds that are not placed, but are in the diagram and have places on the board (LED1/LED2), looks like they connect to the FT232H, but not sure what their purpose would be. Leaving them out entirely might simplify the design :)
I know it's very low on the list, but the silk screening could be improved a bit, lots of half numbers and such right now :)
There's some minor things which I would like, but they would most likely compromise the base principle of the board, to keep it simple and cheap :)

The FT232H is a very fancy and capable chip, but because most pins are not broken out, and only few are connected to the FPGA, it's only usable as SPI programmer, and with some tweaks as a serial port. But there isn't really much that can be done about that on such a small board :)
I -think- the used flash would support quad SPI, but the needed data lines are not connected. But again it would likely complicate a simple board, and not sure how great the benefits would be. For the programmer, programming doesn't take -that- long, it might be nice to have a faster bus between the FPGA and spi flash though :)

One last thought, the Upduino 1.0 was great at being super cheap and simple, but it's held back by a very bad design. An upduino 1.1 with the design improvements of the 2.0/2.1, but without a FT232H, might see interest :)
Disclaimers:

I know nothing about FPGA's or electronics :D
I look at this from a hobby/DIY/Maker point of view :)

Thank you for the detailed feedback! Will try to reach out to some of those sites and see what I can incorporate and come up with a proposal for the community to comment on.

PS: I faced the same issues as you did with the Lattice UP40 designs all over the web (that seem to have been copied from each other without much change) and have already built this into my other project that is more commercially focussed here.. Specifically:

FPGA CRAM vs. flash programming is properly addressed. FPGA programming takes far less time than flash and makes sense in a production environment as well and not just for makers. Its already supported by the iceprog tool as well :)
Flash is qSPI (but not dual transaction ie. double-edge clock which can be added some day)
FTDI programming is moved off to another board. Allows for not just cheaper but more modular design.
Only the 3 color LED is on-board as the user interface. FPGA done LED is off-board since the end application may not have a DONE indication using an LED.
IO bank voltage is programmable using an input voltage that can be derived from the on-board regulators quite easily.

Sweet, I'm gonna have a better look over then weekend when I hopefully have some time :)
Btw. I saw you mentioning riscv on the main page.
I have PicoRV32/PicoSoc running right now on my 2.0 :)
Here I have the minimal changes I did to get this working (fork of picorv32):
https://github.com/cranphin/picorv32
Just look at the last commits :)
And keep in mind my (Current) hardware setup:
https://github.com/cranphin/picorv32/tree/master/picosoc#upduino-20-port
The same in a separate project can be found in:
https://github.com/cranphin/updosoc
I want to slowly expand that one for my own setup, but at the moment it's still very vanilla :)

Cool! I'll add this to the useful links section and also add the design to the sample code besides just the trivial blinking led.

just found this project by coincidence and  http://www.gnarlygrey.com/  site is currently down (is this somehow related?)
+1 for simplified version 1.1 without FT232H for cheap price. Basically just breakout board for the FPGA with crystal - if quad spi would work from FPGA that would be great.
+1 also for easy switching between spi flash or ram upload
I guess nowadays one can use raspberry pi for spi programming (I did it with upduino version 1.0) so having just spi pins for flash is not so big obstacle. Or one could possibly write some usb or serial to spi flasher as arduino sketch for pro mini clone or even for blue pill or stlink V2 clone (all ~$2-3 items from ebay/aliexpress)

oh, so you really took over it officially as mentioned here https://www.element14.com/community/groups/fpga-group/blog/2017/09/30/gnarly-grey-upduino#comment-222684
one more comment - upduino 1.0 was $9.99 including shipping in envelope, upduino was $13 ($16 including shipping in envelope)  - that was the best thing about it - it was very cheap entry to FPGA world in arduino pro mini style.
Your current tindie price is $19.95 and the shipping for me to Europe is another $15.00 - that's $35.
For such price most of the magic of upduino is gone. There are many other choices at that price level. But maybe if you also sold it at some store in Europe like Pimoroni it would be great (they have EUR 4 shipping for small items like raspberry zero)
I understand the price of upduino was very low - near the costs (or maybe even below as some sort of Lattice promotion?) but I just wanted to say that improved barebone 1.1 version without that expensive FTDI chip for lowest price possible (like  ~$15 including shipping) would be more useful for FPGA tinkerers than $35 device with lot of added stuff. There are already couple of other boards like that.

Hi Fanoush,
Thank you for the feedback! I had someone buy a couple of boards from Germany almost 2 weeks back and the package is still working its way to them according to my tracking info! In addition to the steep postage charge, the delivery time is also an issue.
I will ask Pimoroni if they'd be willing to carry this board. Would greatly reduce shipping cost. I did ask Sparkfun if they'd like to carry this board but was turned down. Do you have suggestions on other European based stores like Pimoroni?
Re. the next steps, heres what I'm thinking and open to feedback:

Fix the silkscreen and other minor changes based on the feedback depending on sales
Define the next version of the barebone version. I have the same ideas as you on this. A tiny stamp with the FPGA, oscillator, qSPI DTR flash and LDO's. I'd like to design this with community input. There has been a request to keep the microUSB connector on & use a TinyFPGA style bootloader and eliminate the (expensive) FTDI part and associated components.

I had to increase the price due to many factors. It has to make some money for me, unknown and low projected volume leading to manufacture in CA, California sales tax, vision to fund future UPduino/OpenSource projects from the proceeds being among them.

Hi vr2045,
I also have good experience with https://thepihut.com/ They both focus on raspberry pi but also carry other stuff and have cheap shipping.They both sell $5 Raspberry Zero for years which is very low profit item. They are not so big as sparkfun so I hope they will be willing if they understand what it is. pimoroni are really cool pirates, check their youtube
And thanks for you reply, it is great that you perfectly understand the price aspect :-)
The need for good enough profit is understood, I guess the original upduino was not made for profit as the guy was from Lattice so such very low price is not sustainable in the long run. Well unless Lattice is willing to promote is as loss leader to take over the open source FPGA market :-)

No responses from the European folks mentioned above. It would be great to have someone stock these locally and mail them out for a fee, no? Any volunteers?

I created a discord channel for discussions, please message me for the link.

Thanks, that is great news! There is 22EUR VAT free limit on EU imports (inluding shipping) so that might just fit below it.  As I already have couple of 2.0 versions, I won't be getting 2.1 as there are virtually no changes, but it will be useful when 3.0 comes. I checked the schematics of 3.0 and some comments there hint that you may have version with same board but unpopulated FTDI chip and usb going to fpga directly. Oh and I see it now also metioned here https://github.com/tinyvision-ai-inc/UPduino-v3.0/wiki#optional That looks interesting.
Additionally there is schematics bare module with just the fpga (the ICE40_SoM.pdf)? That would be also great. BTW I'd trade LEDs for 12MHz crystal there.
Can you send me link to the discord forum or just put it here if it is public. Thanks.

Good point, I was also told to look at https://www.royalmail.com/sites/default/files/International-customs-charges-leaflet-Jan-2017.pdf which requires VAT and handling charges on anything over 15GBP. This would place a limit on the price of the UPduino as well.

Thanks for providing this information, I wasnt aware that these VAT limits existed and that you have to pay VAT+handling. I will include this in my pricing so that it stays below this limit.
Yes, I agree, I wouldnt recommend getting a v2.1 if you already have the yellow board. The 3.0 fixes a lot of issues so would recommend that for newer designs.
I'm trying to implement the tinyFPGA bootloader that eliminates the FTDI chip. This needs to be tested though and will not be compatible with the Lattice programming tools...
Heres the discord link, hope it doesnt get spammed! https://discord.gg/n83M4xS, do join and comment so we can improve the design!

thanks, btw there is another option for usb bootloader, check this conversation https://forum.icebreaker-fpga.com/t/spinning-a-prototype-based-on-the-icebreaker-cchematic/50/4 - either the bootloader is all in HW/fpga logic (tinyfpga) or there is usb device part in HW logic and then software - this may be more flexible

I was simply not aware of the VAT limits to various countries! By reducing the price of the UPduino to $19 from $19.95, this falls below the VAT threshold for the UK. Should be a significant saving for UK buyers of this board as they wont be charged an additional GBP10 as handling charges.
I have updated the pricing on the Tindie site.

thanks for taking care, true that 22EUR is EU wide regulation but member countries can indeed change it, for me in CZ it is really 22 EUR(including shipping, that may also change between countries?) - as for USD to EUR conversion the customs office has its own fixed conversion rate table that changes once or twice a year so it can be in fact slightly different than real rate, not sure how UK customs handle it. It is complicated :-) But worth it so thanks for caring about this. I avoid buying stuff over this limit unless this is handled by seller (like with amazon or ebay). Not only I need to pay additional handling fee ~7EUR on top of VAT but the package is held at borders and I need to sign some papers and scan invoice and sent it to them and it can delay delivery by week or two.


Add enumerations (tagged unions)

Problem
It would be useful in Noir to support types like Option and Result which hold different values based upon a tag value. Optional values in particular would be useful for future Noir contracts.
Proposed solution
Add rust-style enumerations into noir, pattern matching and all.
The main concern is how to represent enumerations given we cannot reinterpret-cast data into another type. I propose representing an arbitrary enumeration:
enum Foo {
    A,
    B(BData),
    C(CData, Other),
    ...,
}

As a struct:
struct Foo {
    tag: Field, // Set internally, 0=A, 1=B, 2=C, etc.
    a_data: (),
    b_data: BData,
    c_data: (CData, Other),
    ...,
}

Now, given a constructor call such as Foo::B(my_b_data), the compiler can translate this into a struct initialization. There is the question of what to do for the fields of other variants like (), CData, and Other. Since these values would be guaranteed to be inaccessible by the compiler when the tag value is B, and since all values in Noir are comprised of Fields, we can initialize all these values to 0 without changing behavior:
let b = Foo::B(my_b_data);

// translated to:
let b = Foo {
    tag: 1, // B is the second variant
    a_data: (),
    b_data: my_b_data,
    c_data: (CData { field1: 0, field2: (0, 0), ... }, Other { field1: 0, ... }),
};

A concrete example
Option in this scheme could be typed as:
enum Option<T> {
    None,
    Some(T),
}

fn main(x: Option<Field>) {
    let y = Some(2);

    let x_value = match x {
        None => 0,
        Some(value) => value,
    };

    constrain y == Some(x_value);
}

Which would be translated internally as:
struct Option<T> {
    tag: Field,
    some_value: T,
}

fn main(x: Option<Field>) {
    let y = Option { tag: 1, some_value: 2 };

    let x_value =
        if x.tag == 0 { 0 }
        else { x.some_value }; // compiler guarantees that x != 0 implies x == 1

    constrain y == Option { tag: 1, some_value: x_value };
}

Alternatives considered
As a slight variant of the above translation of match, we could consider an alternate translation that explicitly checks each tag and fails if an impossible case is somehow reached:
let x_value =
    if x.tag == 0 { 0 }
    else if x.tag == 1 { x.some_value }
    else { panic("Invalid tag for Option enum") }

Where panic would be defined as:
fn panic<T, N>(msg: str<N>) -> T {
    std::println(msg);
    constrain false;

    // Now construct a value of any type T.
    // It will never be used anyway due to the previous line
    std::zeroed::<T>()
}

This would require exposing a zeroed function, which could also be used to initialize the zeroed values for the unused variants when constructing an enum.
Additional context
The actual translation of enums into structs could occur during monomorphisation since this would be the point all generic types become known and we could thus fill in default values for them. This would also be strictly after completeness checking for match expressions which would likely occur during type checking.

@jfecher This seems like a good addition, along with the match syntax. The match syntax desugaring to if conditions could also be another separate issue that is orthogonal to this (it will be limited without enums)

Something else to note about this proposal is that it still wouldn't allow us to write recursive types. For example we wouldn't be able to define a List:
enum List<T> {
    Empty,
    Cons(T, List<T>),
}

// Translated as:
struct List<T> {
    tag: Field, // 0 = Empty, 1 = Cons
    empty_data: (),
    cons_data: (T, List<T>), // oh, no infinite recursion in types is not allowed
}

Lowering this to P-LOW for now as we are aiming to tackle this post-1.0.

Proposed approach:

If time-pressure to implement, start with #[repr(u8)]-style enums
Otherwise, start with struct-style ((u8, A, B, ..)) enums so that abstractions include type metadata
(which aren't needed for #[repr(u8)]-style enums)
Start with the simplest type of match .. { .. }: all cases must be matched
Then implement #[repr(T)] enums:

// T: IsDiscriminatable
#[repr(T)]
enum Foo {
  // T0: ToFrom<T>
  Case0(T0),

  // T1: ToFrom<T>
  Case1(T1),
  ..
}

trait IsDiscriminatable {
  fn discriminant(&self) -> u8;
}

trait ToFrom<T> {
  fn to_repr(self) -> T;
  fn from_repr(x: T) -> Self;
}

Summary:

repr(T) requires T to implement IsDiscriminatable and ToFrom<T> for each case type
(This requires T0, T1, .. to be distinct,
which could be solved by including the case index or name,
i.e. ToFrom<T, 0> or ToFrom<T, "Case0">.)

Runtime match:
match x {
    Case0(y) => f(y),
    ..
}

Becomes:
if x.discriminant() == discriminant_of(Case0) {
    f(ToFrom::from_repr(x)) // with some Case0 annotation
} else {
    ..
}

Runtime construction:
let y = Case0(x);

Becomes:
let y = x.to_repr(); // with some Case0 annotation

if x.discriminant() == discriminant_of(Case0) {
I think the one thing we're missing is how to determine discriminant_of(Case0) assuming we cannot construct a Case0 value.

repr(T) requires T to implement IsDiscriminatable and ToFrom for each case type
We should probably go with a name more specific than ToFrom<T> especially since it sounds like we'll need to include the discriminant somehow. Perhaps Variant in the name somewhere would make sense.

I think the one thing we're missing is how to determine discriminant_of(Case0) assuming we cannot construct a Case0 value.

It would be more accurate to say discriminant_of("ident_path::Case0"), since we'd be looking up the definition at compile-time from it's path/identifier to determine the discriminant, e.g. from user-listed values Red = 2, Blue = 3 or from their index in the definition.

We should probably go with a name more specific than ToFrom<T> especially since it sounds like we'll need to include the discriminant somehow. Perhaps Variant in the name somewhere would make sense.

Sounds good to me

e.g. from user-listed values Red = 2, Blue = 3 or from their index in the definition.

This is the part I think we're still missing. How should users specify this on their struct for example?
I'm not pointing this out because it is unsolvable - I'm just suggesting we should nail down what this'd look like.

Similarly to how they're specified in Rust here.
In short:
#[repr(u8)]
enum Enum {
    Unit = 3,

    // overlap is an error:
    // Overlapping = 3,

    Tuple(u16), // implicitly 4

    Struct {
        a: u8,
        b: u16,
    } = 10,

    Large = 255,
    TooBig, // implicitly 256, which overflows u8 and so is an error
}

@michaeljklein ok, I think I misunderstood us wanting to allow this on structs as those structs wouldn't also have a separate enum declaration. So if you have a struct that you want to treat as an enum representation you'll still need to define a separate type to actually act as the enum and declare its variants then.


Task/remove duplicate representations

This change is

Codecov Report

:exclamation: No coverage uploaded for pull request head (task/remove-duplicate-representations@5f455f1). Click here to learn what that means.
The diff coverage is n/a.


Error: socket hang up and continuous reboot of Hue bridge

I am runnig version 0.6.9 of the adapter on ioBroker with node 6.14.0 and Raspbian 8 on RPi3 and since a few days I discovered following error in my log:
2018-03-28 21:41:35.498 - error: hue.0 Cannot get result for lightStatus13
2018-03-28 21:41:35.561 - error: hue.0 Error: socket hang up
2018-03-28 21:41:35.562 - error: hue.0 Cannot get result for lightStatus14
2018-03-28 21:41:35.622 - error: hue.0 Error: socket hang up
2018-03-28 21:41:35.623 - error: hue.0 Cannot get result for lightStatus15
2018-03-28 21:42:07.433 - error: hue.0 Error: socket hang up
2018-03-28 21:42:07.434 - error: hue.0 Cannot get result for lightStatus25
2018-03-28 21:42:07.503 - error: hue.0 Error: socket hang up
2018-03-28 21:42:07.505 - error: hue.0 Cannot get result for lightStatus1
2018-03-28 21:42:07.596 - error: hue.0 Error: socket hang up
2018-03-28 21:42:07.599 - error: hue.0 Cannot get result for lightStatus2
2018-03-28 21:42:07.658 - error: hue.0 Error: socket hang up
2018-03-28 21:42:07.659 - error: hue.0 Cannot get result for lightStatus3
2018-03-28 21:42:07.740 - error: hue.0 Error: socket hang up
After every poll of 30 sec. these errors are thrown out. I also discovered, that the Hue bridge v2 is caught in a continuous reboot loop. As soon as the adapter instance is stopped, the bridge stops rebooting, too.
Is this bug already known?
Best regards
nsign

Ich habe exakt das selbe Problem! Gefühlt seit dem letzen Firmware update von Hue im März.

I think, I found it:
https://developers.meethue.com/documentation/core-concepts
We can’t send commands to the lights too fast. If you stick to around 10 commands per second to the /lights resource as maximum you should be fine. For /groups commands you should keep to a maximum of 1 per second.
If you have more than 10 groups, it could be a problem with current implementation.


Modular Exponentiation

What the program do ?
Modular Exponentiation
In what programming language it is written?
C++

This pull request do not contains files in specific folders. Please fix it and reopen


URL for setup not working

Having had issues lately with the token, I finally had some time to try and set this up again, but now I cant get it working. When I enter https://idp2-apigw.cloud.grohe.com/v3/iot/oidc/login in a webbrowser (tried Chrome and Edge), nothing happens. Literally nothing... The URL address bar shows idp2-apigw.cloud.grohe.com/v3/iot/oidc/login, but no webpage tries to load. It remains on the same page I was before hitting enter....
Anybody else had this same issue?

same here

Use Chrome.
Start an incognito window and input https://idp2-apigw.cloud.grohe.com/v3/iot/oidc/login. Press enter.
The login page will be seen.
Enter your details. However, before signing in, ensure that you have brought up developer tools (under additional tools).
Press login.
Under "Console" in the developer tools you will then see see a "failed to launch" and the ondus://-address.
Copy the address but change from ondus to https://
Press enter
You will now be presented with the token (and some other info).
Extract the token and input the token into you config-file in HA.
Restart HA.
Voilà!

still not working, it opens up a window to log in and when im loging in it just tells me that im allready loged in with on option to go back to the application.
It looks like more a problem with the website. The ondus app does not exist anymore it wants to download the new sense app.
And der is no developer option. ;(

And this one
https://github.com/openhab/openhab-addons/tree/2.5.x/bundles/org.openhab.binding.groheondus#obtaining-a-refresh-token


Zeal taser missing from the spawnenemydummy units list

when looking for a unit to select for a spawnenemydummy element, "units/pd2_dlc_gitgud/characters/ene_zeal_tazer/ene_zeal_tazer" does not show up on the list. even looked at it in enemy spawner and if you browse units it's not there.

Fixed a while ago when updating the hashlist I assume


converted the files in the ff folders into tf2 using tf2 upgrade scri…

…pt folder names: trainner-tools-semantic-segmentation-zoo-mnn-project

@Buerkem Thanks for pull requests.Do not have enough time to test TF2. You may fork this repo to make your own:)


iOS: Add a setting to suppress alert before marking all articles as read

It would be nice to be able to disable the alert that shows up every time you mark all articles as read. Asking before marking all of the articles read should be the default, but it should be controllable with a user setting.

I would like to keep the user setting stuff as minimal as possible.  Let's see if there is a way to get rid of the confirmation alert another way.

On the Mac app we could give you a hidden preference.  We could possibly do the same thing where we have a shortcut that can toggle hidden preferences on and off.

We could add some kind of "Don't show this dialog again" thing to the confirmation alert so that people can make it go away if they don't want to see it.

We could replace the confirmation alert with a one time alert that is educational.  It could inform the user that undo is available for Mark All and remind them what the iOS 13 undo gesture is.

Do any of those sound like a better alternative to a user setting?  Do we have any other options?

Talked about this with @vincode-io, and I'm gonna change the implementation to a one-time alert.


About dataset

This is an exciting work. But 6 different datasets are used and the other four datasets are not available to me even if I read the corresponding papers. Could you provide the other four datasets used in the experiment. It would be easy to follow your work!

Thanks to your suggestion, we have uploaded three other datasets. In the future, we will also upload the ml1m dataset.

Thanks to your suggestion, we have uploaded three other datasets. In the future, we will also upload the ml1m dataset.

OK, thank you for your reply


Fix some typos and formatting

Failed on JDK9 with FutureTest.shouldNotCrashWhenRecoverFails:852 Condition not met.
Maybe tests run too slow?

Hi @valery1707, I will take a look today. We observed that 'flickering' also sometimes in the JDK8 build, see #2203 but it isn't reproducible on a local machine.


Infra for gradual React migration

Need to start combining Angular and React components, to eventually migrate to React.

Status the moment:

Angular 100%
React: 0%


[Question] Can I disable everything and only use EasyClick?

Question
I am an active user of win, mac and linux. I indeed do switch between all three OSes regularly. In general, I try to make my keyboard shortcut setups on all three systems as close as possible, to be able to switch easily. On Mac I use the app called Homerow. It works as follows: with cmd+shift+spacebar you get EasyClick. With cmd+shift+J you get the ability to scroll windows, which goes away when you press Esc. That's all it does.
It seems that win-vind is the only app to offer me the same capability on Windows. However, even though I'm an avid user of vim, I do feel quite overwhelmed by all the capabilities of win-vind. While it seems that it is a super powerful application and I'd probably benefit from learning it eventually, I don't really want to right now. I'm simply used to the workflow I have already, and it gets me 90% to the ideal, while being near-exactly replicable on all 3 OSes.
Tl;dr is there a way to just use EasyClick and nothing else?
Thanks.

@pit-ray This works great, mind if I ask additional questions?
Is there way to control click behavior once entered easyclick mode with certain bindings? I want to either ctrl+click / or normal click once after enabling easyclick, instead of having separate keybindings for easyclick_left vs easyclick_mid (or else).
Also, is there a scroll mode keybindings as well?

@kwonoj
I don't know if I caught your question correctly, but now easyclick is an independent command <easyclick>, not `<easyclick_left>, etc.
https://pit-ray.github.io/win-vind/cheat_sheet/functions/#easyclick
As with Vim, you can define the user-defined sequential command, which allows you to control the behavior after the <easyclick>. For example, map <s-f><s-f> <easyclick><click_right> and so on.
However, functions such as long pressing the control key have not yet been implemented. #41, #69.
Thanks.

@pit-ray Thanks for the answer. I'm trying couple to see if it works as intended, so far it looks like I'm misunderstanding or misconfiguration something.
The basic crux I want to achieve are

easyclick allows click with kbd combination:
This option in homerow summarizes the behavior I'm trying to achieve

once easyclick combination is entered, this option allows to trigger click only if certain kbd (space / enter in this case). The kbd input can be combined with modifiers, so for example I grabbed an element in the web browser, then ctrl-enter triggers ctrl-click, and normal enter triggers normal click.

scroll mode
a key combination that enables hjkl triggers scroll event until exiting mode.


Sdk automl text entity extraction online

This PR contains notebook which demonstrates how to use the Vertex SDK to create text entity extraction models and do online prediction using a Google Cloud AutoML model.

[x] Use the notebook template as a starting point.
[x] Follow the style and grammar rules outlined in the above notebook template.
[x] Verify the notebook runs successfully in Colab since the automated tests cannot guarantee this even when it passes.
[x] Passes all the required automated checks. You can locally test for formatting and linting with these instructions.
[x] You have consulted with a tech writer to see if tech writer review is necessary. If so, the notebook has been reviewed by a tech writer, and they have approved it.
[x] This notebook has been added to the CODEOWNERS file under # Official Notebooks section, pointing to the author or the author's team.
[x] The Jupyter notebook cleans up any artifacts it has created (datasets, ML models, endpoints, etc) so as not to eat up unnecessary resources.

/gcbrun

Error in build log:
      1 dataset = aiplatform.TextDataset.create(
      2     display_name="NCBI Biomedical" + "_" + TIMESTAMP,
      3     gcs_source=[IMPORT_FILE],
----> 4     import_schema_uri=aip.schema.dataset.ioformat.text.extraction,
      5 )
      7 print(dataset.resource_name)

NameError: name 'aip' is not defined

Noted karl. Thank you
On Fri, Feb 11, 2022, 8:57 PM Karl Weinmeister @.***>
wrote:

Error in build log:
  1 dataset = aiplatform.TextDataset.create(
  2     display_name="NCBI Biomedical" + "_" + TIMESTAMP,
  3     gcs_source=[IMPORT_FILE],

----> 4     import_schema_uri=aip.schema.dataset.ioformat.text.extraction,
5 )
7 print(dataset.resource_name)
NameError: name 'aip' is not defined
—
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/vertex-ai-samples/pull/283#issuecomment-1036331704,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ATV6CWHI6JIWF2U34DJFHQLU2UTF5ANCNFSM5ODPTEFA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

Error in build log:
      1 dataset = aiplatform.TextDataset.create(
      2     display_name="NCBI Biomedical" + "_" + TIMESTAMP,
      3     gcs_source=[IMPORT_FILE],
----> 4     import_schema_uri=aip.schema.dataset.ioformat.text.extraction,
      5 )
      7 print(dataset.resource_name)

NameError: name 'aip' is not defined

fixed issue

Comments resolved. Notebook can be reviewed

/gcbrun


Localization keys

Now that Sanity officially introduced support for localization of the UI (December 19, 2023), editors expect language uniformity across the whole Studio. I know it just happened yesterday but I’d be happy if internationalization support for this plugin was released eventually.

https://www.sanity.io/docs/localizing-studio-ui
https://www.sanity.io/docs/internationalizing-plugins-ui

I would be glad to help with this too!


MINOR: change log level in ThreadCache to trace

cache eviction logging at debug level is too high volume. This was already done on trunk but didn't make it into 0.11

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk7-scala2.11/6683/
Test PASSed (JDK 7 and Scala 2.11).

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/kafka-pr-jdk8-scala2.12/6668/
Test PASSed (JDK 8 and Scala 2.12).

merged to 0.11


Documentation for ETOR Newborn Screening Project

Problem statement
Create comprehensive and consolidated documentation
Acceptance criteria

[x] Sender/Receiver contacts (with descriptions)
[x] Short summary of current status of each connection
[x] Data types used (ORU, OML, etc) for each connection
[x] Data flow charts
[x] Accounts/Credentials saved and shared with Victor in Keybase
[x] Consolidate existing documentation

To do

[ ] ...

done and gave to Victor


default is not exported

Hi,
rollup can't handle import SvelteTable from '@hurtigruten/svelte-table'; because "'default' is not exported by svelte-table".
See Svelte REPL, same behaviour on local machine.

Thank you for the info, indeed there is no default import. You can use it by import { SvelteTable } from '@hurtigruten/svelte-table';


Update DG

Update value proposition and target user profile.
Add user stories.
Update implementation details on giveall and clean command.
Update giveall, clean and saving in manual testing section

Codecov Report

Merging #254 (24d33af) into master (32f49c5) will increase coverage by 0.26%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master     #254      +/-   ##
============================================
+ Coverage     75.65%   75.92%   +0.26%
  Complexity      683      683
============================================
  Files            94       94
  Lines          2009     2002       -7
  Branches        228      226       -2
============================================
  Hits           1520     1520
+ Misses          422      415       -7
  Partials         67       67

Impacted Files
Coverage Δ

...address/model/assignment/UniqueAssignmentList.java
86.48% <ø> (+7.47%)
:arrow_up:

...ress/logic/commands/AddAssignmentToAllCommand.java
89.47% <100.00%> (ø)

Continue to review full report at Codecov.

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

For the sample data file, nothing is changed. I just duplicated it and placed in the bin/data folder so that I can reference a sample data file in the saving data portion in manual testing section.


The Latest version have some performance bugs

Today, I updated the latest code. After running Demo for a while, CPU usage was much higher without a request.

func main() {
	// New Service
	service := grpc.NewService(
		micro.Name("go.omi.srv.say"),
		micro.Version("latest_demo"),
	)

	// Initialise service
	service.Init()

	say.RegisterSayHandler(service.Server(), new(handler.SayImpl))

	// Run service
	if err := service.Run(); err != nil {
		log.Fatal(err)
	}
}

@jzhongming what was the version you were running before?
We need to determine the code change that may have made the performance drop you are noticing.

go-plugins version: 635d628 [26 hours ago] Asim Aslam ✑  Merge pull request #384 from lqczzz/master (HEAD -> master, orig
in/master, origin/HEAD)
go-plugins version before: 453dd4a [3 days ago] Asim Aslam ✑  Fix breaking grpc code (tag: v1.2.0)
go-micro : 0440444 [13 hours ago] Asim Aslam ✑  Merge pull request #634 from micro/rcache-stop (HEAD -> master, origin/master, origin/HEAD)
go-micro befor: 89fc142 [2 days ago] Asim Aslam ✑  Update to use mdns 0.2.0 (tag: v1.8.1)

Thanks @jzhongming I'm not sure how #634 could cause the performance drop, though it does spin a new goroutine, but I would not expect that to have had a huge CPU perf hit.
The plugin part I'm not sure about, although arguable both PRs seem to be addressing similar issues. Can you provide some handler code so we can try to reproduce this?

package handler

import (
	"context"

	say "com.omi/demo/proto/say"
)

type SayImpl struct{}

var c int64

func (s *SayImpl) Hello(ctx context.Context, req *say.Request, rsp *say.Response) error {
	c++
	// log.Info("Received Say.Hello request", c)
	rsp.Msg = "Hello " + req.Name
	return nil
}

How intriguing!
it looks like it's a basic Greeter microservice?
So I picked up https://github.com/microhq/greeting-srv and launched 2 instances of it:
~/go/src/github.com/microhq/greeting-srv (master)$ go run main.go
2019/08/02 13:49:59 Transport [http] Listening on [::]:54712
2019/08/02 13:49:59 Broker [http] Connected to [::]:54713
2019/08/02 13:49:59 Registry [mdns] Registering node: go.micro.srv.greeting-b2979fef-a223-4e87-a1ec-b99b2b5f77d1

~/go/src/github.com/microhq/greeting-srv (master)$ go run main.go
2019/08/02 13:54:48 Transport [http] Listening on [::]:55033
2019/08/02 13:54:48 Broker [http] Connected to [::]:55034
2019/08/02 13:54:48 Registry [mdns] Registering node: go.micro.srv.greeting-cfe3c0bc-dba7-44fe-b6a5-565c168e2779

Just to confirm, as you can see I'm using mdns registry here...
I wrote a little shell script to test if the CPU increases:
for i in $(seq 1 100)
do
        micro call go.micro.srv.greeting Say.Hello '{"name": "Jason"}'
        sleep 0.5
done

the script adds 0.5s latency between subsequent RPC calls. I did not notice any CPU spikes o_O
I also removed the latency and hammered the service even more, but can't seem to have noticed any CPU spike in that scenario either. This is indeed tested on the latest go-micro build.
Would you be able to get some trace profile using something like pprof?

Yes, It's greeting demo.  But I  compiled it into binary. Run it. Wait half an hour ....  The Macbook pro 's CPUs will jump high... ORZ...

I've had this issue before. It's related to a slow leak of time tickers where they are not stopped when a go routine exits. This may fix it https://github.com/micro/go-micro/commit/d7929ef8f37886169e80b79981b7de944f99e2f3. It may be occurring elsewhere also. If this doesn't fit it, it may also be related to other go routine leaks where they have a for loop of time.After causing a continuous loop. But most likely related to a slow leak of go routines unrelated to the request flow.


Question: How to configure a string variable at runtime

This is not an issue with esp-homekit-demo, but a question for a coding advice/direction.
I'm building a multi sensor & AC accessory based on your libraries. Except the homekit functionality, one additional function is the ability to send temperature/humidity values at thingspeak.com online IoT database service.
The accessory sends the data by doing http GET calls at specific intervals. Before I flash the accessory, I have to put in the code the correct API key (string)  which is being transmitted along with the http call. The API string is personal and is related to my account at thingsspeak.com.
What would be the best way to set a string variable at some point during runtime (once) and use it through out the program's life?

For larger configuration I would definitely opt for an HTTP server and configuration API. For just one or two values this seems like too much. I would recommend just hardcoding it.
One other approach I was working on is to be able to download data from sysparams storage, parse it, modify it, pack and flash it back. This is totally doable and not hard at all, but requires digging into sysparams source code, and putting together some tool (e.g. based on esptool) which requires some skills. I might write such tool at some point, but no estimates yet.

thank you for your advices Maxim!

@maximkulkin Instead of creating an http server, do you think your library esp-wifi-config could be adapted to provide this functionality? A similar approach is used in HAA If I'm not mistaken.

@peros550 Up to you, but I would never do it that way for my projects. esp-wifi-config, as name suggests, is for configuring WiFi. If you want to do something other than that, it would be some kind of generic configuration UI, which poses question "how to do it in an extensible and reusable way, not too bloated for embedded?". You will probably end up with something not too reusable, but good enough for particular project - thus, a custom HTTP server as I suggested previously.


Ollie: Watch bendep.net

Ollie requests the watch of the watch_keyword bendep\.net. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

bendep\.net has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Makyen in Charcoal HQ


database upgrades must be possible for actual and old server instances

The deployment of a new version needs an update of the property <openRobertaServer.history> in the parent pom. This is needed for the database upgrade. If it is possible, this update should be removed. It adds a commit and is error-prone.

ready for prod deploy


does this work with react native

currently trying to figure out what react native multiform to use and I was wondering are there any issues that would hinder me using it in a native app? (Apologies if it is an ignorant question)

@shaksi Sorry for the last reply and thanks for the question.
It Probably does not work as ReactNative has its own markup. i.e.  wont work (... has this changed, I have not worked with ReactNative for many months now?).
You can give it a go and let us know. Unfortunately we don't have any immediate plans to get this working on mobile. I will re-open this issue if we do and let you know.


Added sdairsab

Thanks for this. Don't be alarmed if you get a notification about something failing - the CI/CD is having trouble with PRs coming from forks and I need to find time to fix it. Your profile will still appear on the site within a few minutes of the merge


Page about  MWC Floonet Faucet / MWC Testnet Faucet

The document about the faucet is not indexed by google search.
https://github.com/mwcproject/mwc-wallet/blob/master/doc/floonet_faucet.md
We need to create a page at the site, specify that it is MWC Floonet (Testnet) Faucet with fort description and add the link to the github. Google should index the page and show it in the search results.

Also mwc-wallet can't send by mwcmqs.  We better switch to the tor


Add test_gather for there_is_another | False

Sets up a valid situation where you would need there_is_another to be
directly set to false, instead of using target_number like the docs say.
First used in https://github.com/SuffolkLITLab/ALKiln/pull/580

Since this is a new test that won't break existing *.feature files and I've tested that it works locally, I'm going to merge without review.


Pass io_loop instance as **kwargs for get_application

This change is driven by google-safe-browsing's need to schedule fetches of additional blacklist data.  Instead of using a separate thread, exposing zygote/worker.py's io_loop allow application to schedule work on that io_loop.

This is an API-breaking change. Would it be better to implement this the way that initialize was implemented (e.g., check to see if the application exposed a "set_ioloop" function of some kind, and, if so, call it with the io_loop)? Or do we not care?
Eskil? Do you have thoughts?

I like that.  Perserving backward compatibility and avoiding magic are nice.  I will wait for eskil's comment before submitting another pull request.

**kwargs seems to provide a generic mechanism to expose additional information from zygote.  If zygote install base is still small, I suggest we take the opportunity to make an API breaking change rather now than later.

Smoy, I'll all good with this, but I think there's a merge conflict. The githubs won't let me merge this automatically.

I am going pull upstream changes and try to submit another pull request.

Close this request as I have submitted pull request #21 after merging with upstream changes.


an isomorphic example domvm application?

Hey, I've been silently watching this for a while with interest and today I sat down to try make an isomorphic example app with domvm and express.
Context: I'm not an experienced JavaScript developer at all. I do have some experience hacking JavaScript with jQuery, but that's it. I have very little clue about NodeJS, and I don't know any JS frameworks well (I tried mithril for a little and liked the general direction), so I might just be missing something obvious here or I might be trying to do things totally the wrong way. :)
Use Case:

graceful degradation in the absence of JavaScript.
fast initial page load on mobile devices on all routes for an application that makes API requests. (On initial page load, the server should make the API requests (and ideally pull results from its cache) and render html so that the client doesn't have to take all the roundtrips on its slow connection)
ability to open links in another tab as well as reload the page gracefully

One implication of this use case is that the application has to use the historyAPI instead of hashbang URLs - otherwise I don't know which API requests to make on the server side.
In Mithril I managed to almost get such an example app working (https://github.com/grumpi/mithril-isomorphic-example) - it has one serious flaw: Mithril can't attach to an existing DOM so everything will be rerendered when JavaScript finally runs. This is a problem when there is a form on the site since the user will lose all the data they entered before JavaScript ran. As far as I understand, domvm can attach to an existing DOM gracefully.
What I tried to do:

make a simple domvm application with a router (this seemed straightforward and works).
render all the routes of the application server-side, based on the request path. Basically, I tried to run vm.html(vm.node) after using the router on the server side. That doesn't work because the router is for browser use only.

My current ideas:

I use a modified router implementation that can run both on the server and the client, Then, there's only one Express-route in the application that handles all the domvm-routes and I have maximal code sharing between server/client.
I make one "routes" declaration format that is transformed to Express-routes and to domvm-routes. This would let me avoid modifying the router but it seems a little more involved.
I search for a different reasonable and minimal router implementation that works both in the browser and in nodejs and try to use that instead.

I'm kind of torn between wanting to make a rich, interactive, offline-enabled client side experience and not breaking the web. Essentially, if it comes down to it, not breaking the web for people who are just browsing is more important to me. (I'm fine with people who want to interact being required to use a compatible JavaScript-enabled browser.) Yet, I think I'm really close to being able to have both with domvm. Has anyone tried to do or done something like this with domvm before?
ETA: if the domvm router is supposed to become isomorphic in the future, I wouldn't mind to try help to make it so.

Before delving into any of the options I listed, I figured I'd try to see if I can do a quick hack to get server-side routing working without changing the router itself.
Apparently, all that was needed to get things to run on Node was to add window, location and history variables to the global node object. This feels hacky, but it could be worse.
In order to use hrefs generated by the router in my view, I had to define HTMLElement as well. In contrast to the previous hack, this one seems more likely to break something.
While the router appears to work, I don't get client-side rehydration of the server-rendered DOM with attach(). When I click the links generated by the router, I get page reloads instead of SPA-style navigation. When I call redraw(), nothing seems to happen. When I wipe the DOM on the client and have it mount() instead, clicking links and redrawing seems to work fine.
I'm probably doing something wrong here.
Example code at https://github.com/grumpi/domvm-isomorphic-example

Hey @grumpi
Thanks for checking domvm out. I have not personally made a fully isomorphic app with domvm yet. I've ensured that SSR (server-side rendering) and client-side hydration works in obvious ways but you're right that the router impl does not currently cater to this. I'm very interested in getting it fully working and don't think it will be difficult to do as it already supports history routing via useHist: true. I'm a bit busy today, but will take a look at your code tonight or tomorrow and give you better feedback.
cheers!

@leeoniya No need to rush. Hope you're having a nice Sunday.
I think it's great you're making this.

@grumpi thanks!
coincidentally, a lot of router-related stuff in /r/javascript today:
https://www.reddit.com/r/javascript/comments/4h8kqq/how_the_best_frontend_router_should_look_like/
https://www.reddit.com/r/javascript/comments/4h99qg/calling_all_routers/

@grumpi take a look at https://github.com/leeoniya/domvm-isomorphic-example.
it's basically working, though for initial nav might be using replaceState rather than pushState...will need to look into this a bit more but feel free to investigate.
The changes that needed to be made were:

use app.view.attach(document.body.firstChild); since you must attach to the view's root node, not the container it's mounted into. If you want to be more uniform, your view could construct <body> and then use app.view.mount(document.body, true) and app.view.attach(document.body.firstChild), just make sure your body is has nothing between </script> and </body> tags. See recent discussion: https://github.com/leeoniya/domvm/issues/56#issuecomment-213210948
use a local copy of the current domvm 1.x-dev. there was an event-binding regression in 1.1.0 that was fixed a couple days ago: https://github.com/leeoniya/domvm/issues/62
add </body> to response, cause you know...

@leeoniya thanks! It's great to see that I was indeed just doing something the wrong way.

Ok, I see now that attach needs to know the first node rendered by the view and mount just needs a container to dump things into. I just blindly assumed for no particular reason that attach and mount would take the same kind of argument. It does make sense.
Fair enough, it makes sense to check first with the development branch whenever something odd happens.
Ah, I hate when I accidentally lose closing tags. One point for rendering the body with a sane language. Though, one argument against rendering the body with domvm is that the <script> tag for the application's code will float up into the body in the browser's DOM. Seems like wrapping domvm in its own dedicated div might be more robust / standards compliant.

Now I'm approaching mocking an API request.
I suspect the place where to run API requests associated with routes is in the route's respective onenter() handler.
I noticed that these handlers are not by default being run on the server side when setting up the router. This makes sense since they might contain all kinds of UI-related initialization magic that should not run on the server.
So I figure that there is a certain part of the onenter() handler that needs to run on both client and server - the part that constructs a context for the route.
What I have now is all still very sketchy and not particularly pretty, but I didn't feel like domvm is getting in my way. In fact, it seems straightforward and flexible, just as advertised.

I noticed that these handlers are not by default being run on the server side when setting up the router.

Right, they're simply callbacks to fire for a matched route.

Now I'm approaching mocking an API request....

So I figure that there is a certain part of the onenter() handler that needs to run on both client and server - the part that constructs a context for the route.

I'm not sure what you want the server/client contexts to provide for you in the handlers. You'll have to be more specific here as to what you're trying to accomplish. If you're restricting yourself to features which will work without js enabled, your API is all HTML form GET/POST submissions, form inputs and links for everything else. No JSON, ajax/fetch, etc...right?

I'm thinking one reasonable setup for an isomorphic application is to have 1) a backend API server that is responsible for everything related to data/authentication, 2) a nodejs server that handles graceful degradation (by a) rendering and b) providing fallback routes for actions that need to access the API), 3) the user's browser where the fun stuff happens.
Realistically, let's say the API server handles HTTP/Websocket requests and serves JSON while the client running in the browser directly communicates with the API server, just like the nodejs server will. If it doesn't, it's simply a matter of putting a layer on top of it that does.
I'm looking at figuring out an architecture for code-sharing between client and server around domvm that works gracefully in this setup. I'm pretty confident I can hack things together badly, drop datastructures in the first place that makes some sense, and it will probably work more or less, but I think it would be better to do this right.
Please take my ramblings as a call for a sanity check. I'm just thinking out aloud, coming up with something.  :) I kind of hope for a community to form around domvm that is interested in doing things the "not breaking the web"-way (for the purely selfish reason of getting a glimpse at how others do things). The other frameworks I looked at drop the ball long before there is a chance to get graceful degradation. The best way to get there is probably to talk about isomorphic architectures using domvm.

I'm not sure what you want the server/client contexts to provide for you in the handlers.

When a route has some data associated with it that is referenced in its view, that should be part of the context for that route. To properly render the view for that route, the code that creates the context (e.g. by doing the API requests and whatever other processing is needed) needs to run before rendering the view - on both client and server, respectively. Maybe there's a better name than "context" I should use for that.

Maybe there's a better name than "context" I should use for that.

Context is fine, that's what it is.
This all sounds pretty sane. However, I recently had some thoughts about the feasibility of fully isomorphic apps (disregarding the no-js fallback capability) and here is what came out of it. What if your server has state/logic that should not be present on the client but is relevant to rendering? Let's say you have something like:
if (numClients < 5 && day == "tues") {
	// show or don't show some view
}

Let's say this statement is contained within some larger RenderView() function and you seamlessly wanted to be able to render it on the client rather than returning html. Now you are forced to transmit the full "context" of the server to the client as well as all rendering logic. This was one of those fundamental "uhhh..." that I had no answer for. The implication is that your views' logic (not just the rendered info) cannot rely on any private "context" and the client must have Total Information Awareness (tm).
For simple toy apps this is fine, but for anything non-trivial I'm not sure how this fundamental problem is resolved by other frameworks (if at all). You could in theory somehow "compile" the above logic on the server in real-time to eliminate the conditional and serve only the correct branch to the client, but it becomes very complex very quickly and thus impractical.

What if your server has state/logic that should not be present on the client but is relevant to rendering?

I see this as an issue that is only vaguely related to isomorphic apps. This seems to me to have something to do with the general API-based SPA architecture (or, for that matter, mobile app architecture, since they face the same challenge).
This is a matter of where to make the "cut" between client and API server. You look at your API and make sure it doesn't expose data it shouldn't. (Yes, I have the feeling that many fail at doing this right - and even if it's just by failing to install their MongoDB correctly.)
Any result you need to use in order to make rendering decisions on the client needs to be exposed by the API - however, not necessarily by exposing the actual data that is needed to compute the result. In your example, if your API server may not expose how many clients are currently online and what day it is, you can just expose something less revealing which is still sufficient to let the client know what view to use, instead.
It may seem like, suddenly, presentation logic is being written on the API server that's supposed to only handle data and the data-associated business logic. In some cases, this may even be true. However, doing it this way around seems much more sane than exposing sensitive things that are not the client's business.
Effectively, there seems to be no difference to handing out HTML artifacts generated by the server in terms of "information leaking", if done right. Generating HTML from the data on the server-side is the act of applying a function to the data. Applying a function to the data and then making that available via an API route leaks no more and no less, as long as you pick the right thing to expose.
Does that make sense?
I see the challenge in fully isomorphic, gracefully-degrading, interactive apps in how to make fallback routes for the more complex actions. I think it's fairly safe to say that there exists a class of actions that are not hard to generalize in such a way that you can automatically generate fallback routes on the nodejs server by means of code sharing. Think of anything that can be directly modeled by form submission, like "like"-buttons, newsletter signup, login, logout, etc.
When it gets more complex than that, I'm at a loss how to have things automatically degrade gracefully - other than hand-coding fallback routes and fallback views for complex interactions.

you can just expose something less revealing which is still sufficient to let the client know what view to use, instead.

yes, this is was also my thought process. you could just return a "showViewX" from the api, but i think this will get very chatty and slow or will need to return some more complex ViewState that can be a single http request. it's hard to say whether such effort to get "mostly isomorphic" is worth it. I think that sticking to the lowest common denominator without stripping a lot of js-only functionality will leave you with nothing more than the ajax-enhanced gmail that launched a decade ago.

I see the challenge in fully isomorphic, gracefully-degrading, interactive apps in how to make fallback routes for the more complex actions

I like to explore feasibility of designs by starting at some desired result rather than doing a bottom-up design from zero for a theoretically generic abstraction/concern separation. For example, you could consider making a simple contact list with keydown/ajax searching capability, a detail/edit view and a popup phone dialer using domvm. This can be done to flesh out a fully functioning VOIP widget and create the JSON API for it. Stare at your working creation in all its simple glory and then work backwards and see how much of it you can make functional without JS. When you are done with this, see how much you had to give up, how long it took you and what your new codebase looks like.
If you want to fall back to non-js, your HTTP->json translation layer must only communicate via GET/POST, since html forms do not support PUT/DELETE/PATCH. Any needed state/context will need to be shuttled back and forth via form inputs, uris and query strings. Headers/cookies/content-types exist on the server but do not exist in a client router. Etc..
You could probably get a lot of this done with enough time/effort, but again, i dont know whether it's worth supporting the 0.3% of users who somehow expect to use rich web-apps with js disabled. It's one thing if this required no additional cognitive load from a developer, but this is absolutely not the case and it is very far from trivial to develop/structure apps this way.

you could just return a "showViewX" from the api, but i think this will get very chatty and slow or will need to return some more complex ViewState that can be a single http request. it's hard to say whether such effort to get "mostly isomorphic" is worth it.

Ah, but isn't that the normal effort to get a secure and performant single-page-application (or, for that matter, any kind of secure and performant client-server application)?

I like to explore feasibility of designs by starting at some desired result rather than doing a bottom-up design from zero for a theoretically generic abstraction/concern separation.

Yes to that. While it doesn't hurt to try to mentally order things at a high level before delving into implementation, the practical way to arrive at a useful architecture seems to be to create successively more interesting example implementations. Mocking a minimal VOIP application seems a good example, actually.

If you want to fall back to non-js, your HTTP->json translation layer must only communicate via GET/POST, since html forms do not support PUT/DELETE/PATCH.

This seems unproblematic since ancient browsers didn't have PUT/DELETE/PATCH either.

Any needed state/context will need to be shuttled back and forth via form inputs, uris and query strings. Headers/cookies/content-types exist on the server but do not exist in a client router. Etc..

I think this is where the trouble starts. Basically, one would need to encode any UI state that should be reproducible in the no-js version in the query string of the URI. In a component-based design that means that every component needs to provide code that encodes its no-js-relevant state. The view context would need to have code for reconstructing the UI state from the query string, so it can be rendered on the server. Sounds possible. Though, there is a maximum length for URIs that can realistically be used: some browsers don't support very large URIs.

i dont know whether it's worth supporting the 0.3% of users who somehow expect to use rich web-apps with js disabled

I think you're probably right (even though not everyone is voluntarily without proper js support and, in practice, the number is a little higher since we have to count everyone with an incompatible browser, too). Full graceful degradation is more or less a thought experiment to me, at the moment. In practice, I think the sweet spot for graceful degradation on many SPAs is at "making all the interesting content browsable without js under dedicated URLs" - reason being that this spot seems not very expensive to reach and doesn't impose any ongoing cost on the SPA client development.
What we've brought up are these two concerns for a client-server architecture:

avoiding unintentional disclosure of information (this must be solved at the backend side by not exposing anything that shouldn't be exposed)
performance loss due to subsequent roundtrips when there are lots of client-server-calls (this should be solved at the backend side by making an interface that minimizes the number of required roundtrips)

I was wrong saying that the SPA client must always communicate with the API server directly. That would mean we have to put presentation-related logic into the API if we wanted to resolve both these concerns. Now I think the reasonable place for that to live is in the SPA server.
In my personal case, I think that a great deal of confusion comes from having been exposed to convoluted, tightly-integrated backend implementations that mix presentation-logic and data-logic. The frameworks themselves aren't really the problem, it's the convoluted way they're used.
The backend is:

the API server (written in any language/backend framework, possibly facing the public internet in order to allow connections directly between API server and SPA client for those cases where that makes sense)
the SPA server (nodejs, facing the public internet under TLS)

The frontend is:

the SPA client (running in the user's browser)

Responsibilities:

API server: serves a public API secured by authorization, authentication under TLS. Must not leak information!
SPA server: serves the code of the SPA client to the user's browser. Partially isomorphic: Renders HTML pages for 1) clients that have no JS and 2) mobile devices on horribly slow connections so they can view page content. Computes view state for AJAX-heavy view contexts by making requests to the API server and computing things on behalf of the SPA client in order to reduce roundtrips.

I don't know if there's a framework that forces/assumes an architecture like this. From what I glimpsed reading docs of frontend js frameworks, they usually just deal with the SPA client side and leave it at that. It would surely be interesting to know what the "full stack js frameworks" do to mitigate the risks of accidentally leaking information or to optimize performance for views with AJAX-heavy context setup.

https://www.reddit.com/r/javascript/comments/4htswa/isomorphic_react_and_seo_the_benefits_of_a_single/

Full graceful degradation is more or less a thought experiment to me, at the moment. In practice, I think the sweet spot for graceful degradation on many SPAs is at "making all the interesting content browsable without js under dedicated URLs"

I think at some point you have to decide whether you're delivering an app or a web page; if the former I think JavaScript is a reasonable minimal requirement and a simple notice saying "This application requires JavaScript to function" is fine. If you are delivering a web page, then JavaScript use should be minimal with the content fully reachable without it.

Renders HTML pages for [...] 2) mobile devices on horribly slow connections so they can view page content.

The irony being that delivering just the data content instead of full HTML is likely to be far more performant if the gating consideration is link speed.
A well designed API will be able to cater to different client's needs and limitations in layers. It's fairly simple to build and maintain a course-grained mobile app API on top of a fine-grained, more flexible one. Especially if one allows a standardized way of the client telling the server what data it's interested in (from the set of data the API is permitted to send that user, of course), as a response-size-limiting capability.

The irony being that delivering just the data content instead of full HTML is likely to be far more performant if the gating consideration is link speed.

Right, as soon as all the scripts have loaded, it's much faster. From what I understand, the bottleneck is both latency and bandwith. So both number of roundtrips and application size should be minimal in order to load things fast. The thing is that, if it's a pretty large application, having to wait something like 20 seconds (~ a 125kb app on GPRS at 50kbps, if I'm calculating correctly) to load all the necessary scripts before the page can render is painful and quite off-putting to prospective users.
Showing a page that lets them see content and the information that there's still something loading can be the difference between the prospective user thinking "this is total crap and doesn't work, I'm out" and "ok, this looks interesting, I'll wait until it loaded" (or "I'll look at this again when I got a better connection again"). It's about making a good first impression. Sure, we can always put a generic "It's loading"-page instead of a blank page, but that still creates a mismatch between what the user sees and what they expected following the link to the content.
I suppose one can achieve "fast enough (but still slower than dumping HTML from the server, thanks to the additional round-trip)" "time to first content" by having different builds of the SPA. Have a "non-registered user"-build that contains only content-rendering views and not the interactive parts and one "registered user"-build that makes up the whole application. In the latter case, application size is not a concern because these users will have the scripts cached (or, if they don't they at least already know what they're waiting for). Though, splitting the app in this way looks more complicated to me than just generally rendering HTML on the server.


fix: return 404 instead of 200

Summary
I fixed an issue in the code where invalid paths were returning a 200 status code instead of the expected 404

Change Type

[x] Bug fix (non-breaking change which fixes an issue)

Testing
NOTE: I tried a lot of things, various email/social logins, chat delete, etc... BUT I'm not 100% sure that this won't create new bugs
Test Configuration:
Checklist

[x] My code adheres to this project's style guidelines
[x] I have performed a self-review of my own code
[x] I have commented in any complex areas of my code
[x] I have made pertinent documentation changes
[x] My changes do not introduce new warnings
[x] I have written tests demonstrating that my changes are effective or that my feature works
[x] Local unit tests pass with my changes
[x] Any changes dependent on mine have been merged and published in downstream modules.

thanks!


db_bench does not support --help

db_bench has lots of command line options, but it does not have an option to list them all.

That's a reasonable request.
However, the target audience for db_bench is developers (who should be able to read the top of the source file), so I don't think that fixing this is worth the recurring extra work of keeping help strings in sync.
Sorry this isn't the answer you wanted, but I hope you understand the reasoning behind it.

Normally help strings are automatically kept in sync using something like gflags.

Completely agreed!
This repository is currently set up to be built & tested without any dependency. Ideally, we'd use submodules to import repositories like google/googletest and google/benchmark, and remove our stubs at util/tes{tharness,util}.{h,cc}. gflags/gflags would follow soon after that.
Sadly, figuring out the submodule story requires some work in the internal repository that we don't have bandwidth for -- at the moment, we're much more excited about adding a Windows port and taking advantage of C++11 to simplify the codebase. (no promises though)

Should this issue be left open so it doesn't get forgotten about at that time?

I think the issue should remain closed because we don't have any concrete plans / timeline for fixing it, and we can't accept a community contribution, since the blocker is in the internal repository.
I realize this is inconsistent with the slew of open issues, but we'll tackle the large backlog one bit at a time.
/cc @cmumford because I'm guessing you'd like a second opinion.

LOL.  Thank you, but I'm fine with your opinion.


Improve how the SpanFilterBuilder delegates to the SpanDataModifier.

Resolves #585.
Thanks for the idea @mateuszrzeszutek it cleaned up quite well. 🥳

Build breakage is fixed in #605. Will rebase after that's merged.


HLLSketchBuilder causes segment metadata queries to produce an error during realtime ingestion

Affected Version
26.0.0
Description
Thoughts on how to address this issue.
It seems like a bug in either Druid metadata or DataSketches implementation.
Query for up-to-the-minute segment metadata that has realtime ingestion using HLLSketchBuild yields this error
error:cannot_merge_diff_types: [HLLSketch] and [HLLSketchBuild]
HLLSketchBuild is the required aggregator for ingestion. HLLSketch is the type of the column produced by the builder when persisting a segment.
If we restrict the segment metadata query up to the prior hour (segment granularity is HOUR), we see the correct type reflected: "type": "HLLSketch"
Snippet of ingestion spec
"dataSchema": {
      "dataSource": "uniq_test",
      "timestampSpec": null,
      "dimensionsSpec": null,
      "metricsSpec": [
        {
          "type": "count",
          "name": "count"
        },
        {
          "type": "HLLSketchBuild",
          "name": "uniq_account_id",
          "fieldName": "user_account_id",
          "lgK": 12,
          "tgtHllType": "HLL_4"
        }
      ],
      "granularitySpec": {
        "type": "uniform",
        "segmentGranularity": "HOUR",
        "queryGranularity": "MINUTE",
        "rollup": true,
        "intervals": []
      },
...

Metadata query
{
   "queryType": "segmentMetadata",
   "dataSource": "uniq_test",
   "intervals": ["2000-01-01T00:00:00Z/2999-12-31T23:59:59Z"],
   "merge": true,
   "lenientAggregatorMerge": true,
   "analysisTypes": []
 }

Metadata response snippet
"uniq_account_id": {
  "typeSignature": "STRING",
  "type": "STRING",
  "hasMultipleValues": false,
  "hasNulls": false,
  "size": -1,
  "cardinality": null,
  "minValue": null,
  "maxValue": null,
  "errorMessage": "error:cannot_merge_diff_types: [HLLSketch] and [HLLSketchBuild]"
}

Same issus as #13873

This is still an issue in 29+


Nginx exposer is possibly called three times

Suspicious logs when exposing a single service:
│ time="2024-05-28T14:34:33Z" level=info msg="App local.nginx-nginx added"                                         │
│ time="2024-05-28T14:34:33Z" level=info msg="Created NGINX config file local-nginx-nginx.conf"                    │
│ time="2024-05-28T14:34:33Z" level=debug msg="Received sync from dev1 with 1 apps"                                │
│ time="2024-05-28T14:34:33Z" level=info msg="App dev1.nginx-nginx added"                                          │
│ time="2024-05-28T14:34:33Z" level=info msg="App local.nginx-nginx added"                                         │
│ time="2024-05-28T14:34:33Z" level=info msg="Created NGINX config file remote-dev1-nginx-nginx.conf"              │
│ time="2024-05-28T14:34:33Z" level=debug msg="Updating service dev1-nginx-nginx"                                  │
│ time="2024-05-28T14:34:33Z" level=debug msg="Received sync from dev2 with 1 apps"                                │
│ time="2024-05-28T14:34:33Z" level=info msg="App dev2.nginx-nginx added"                                          │
│ time="2024-05-28T14:34:33Z" level=info msg="App local.nginx-nginx added"                                         │
│ time="2024-05-28T14:34:33Z" level=info msg="Created NGINX config file remote-dev2-nginx-nginx.conf"

It looks quite ok for me

expose for server  (local)
expose for dev1 (remote-dev1)
expose for dev2 (remote-dev2)

 msg="App local.nginx-nginx added"                                         │

is the offending part

Yeah, but in the dev scenario every pod establishes local configuration as well.
In a regular scenario you would have either local or remote based on client/server nature right?


Client Allocation Request for: gfyp

Client Allocation Questions
Core Information

Name: gfyp
Website / Social Media: gfpy.com, (@gfyp, Twitter)
Region: Africa
DataCap Requested: 224 GiB
Addresses to be Notarized: f2532973298393627437546385399324
Notary Requested: Eric

This user’s identity has been verified through filplus.storage


The model is missing from https://paperswithcode.com/sota/speech-denoising-on-lrs2-vggsound

Issue still there...


Run with the new version of backoff

backoff bumpped to version 2.0

We are using some of its internal code to emulate what we've got. This broke.

Thank goodness!

Ha! I just discovered this by accident. How did you know?

Was doing a clean install in a virtual environment and it required a pin to work

New version as soon as tests pass in CI...


Cleanup 1.0 automation tools

Is your feature request related to a problem? Please describe.
Can these be deleted? What else can be deleted?
Describe the solution you'd like
Delete the following:
https://github.com/opensearch-project/opensearch-build/blob/main/manifests/manifest.linux.x64.example.yml
https://github.com/opensearch-project/opensearch-build/blob/main/manifests/manifest.linux.x64.example.yml
https://github.com/opensearch-project/opensearch-build/blob/main/.github/workflows/check-vulnerability-whitesource.yml

@peterzhuamazon Maybe you can help us identifying what's used and what's not used anymore?

@gaiksaya
https://github.com/opensearch-project/opensearch-build/blob/main/manifests/manifest.linux.x64.example.yml
https://github.com/opensearch-project/opensearch-build/blob/main/manifests/manifest.linux.x64.example.yml
@dblock
https://github.com/opensearch-project/opensearch-build/blob/main/.github/workflows/check-vulnerability-whitesource.yml
Please leave this as it be as @zelinh will need it to check out whitesource.

@dblock
https://github.com/opensearch-project/opensearch-build/blob/main/.github/workflows/check-vulnerability-whitesource.yml
Please leave this as it be as @zelinh will need it to check out whitesource.

This was deleted in https://github.com/opensearch-project/opensearch-build/pull/295 as it was disabled. Anyone can put it back when we start running it again.

[Triage] these files have been removed