platforms/avr/led_sysdefs_avr.h: No such file or directory

Veryfing code using this library in Particle Build fails with this error:
FastLED/led_sysdefs.h:19:43: fatal error: platforms/avr/led_sysdefs_avr.h: No such file or directory
 #include "platforms/avr/led_sysdefs_avr.h"
                                           ^

My code is cribbed from the "Fire2012" example.

I'm seeing the same error when building any of the fastLED examples for Photon.  They run fine on a spark core, but I can't build anything for a photon.  I forked the library and am working on a fix now -- I'll comment if I get anywhere.

@enjrolas I have also heard that it's a kernel thing and that the more recent versions of the develop branch in https://github.com/spark/firmware provide this functionality. I have tried running that kernel and bricked one of my Photons. :/

FastLED doesn't fully support the photon yet, which is most likely the biggest source of issues for folks trying to build for it.

Dan! Again, we meet again! Let me (and others I'm sure) know if you have a paypal donation link -- your library is a huge part of our livelihood for sure. I think I speak for others with this, and obviously myself but thank you for such the hardwork on this lib. It is HUGELY appreciated.

This seems to be caused by FastLED library not loading the correct header file for the Photon platform. It's somehow defaulting to AVR - I've confirmed my suspicion after doing a Google search and finding [this thread] (https://community.particle.io/t/fastled-on-photon/11933/3).
It also seems that the developers are aware of this issue for quite some time, and they've already got a hold of some photons so I am convinced it's only a matter of time until we can use FastLED on the photons.
Btw, thanks a lot to the developers for this amazing library.

Yes - because there are so many arduino variants and because of some fallback things I have in the code if the library doesn't recognize the platform you are building for it drops back to unspecified arduino based avr.

In my surfing, I also encountered some discussion of a branch of the Particle firmware that claims to add the necessary features for one to compile locally. I downloaded this firmware, built it, flashed it. It was not retaining wifi credentials between  power cycles.
I didn't achieve anything valuable, quite the opposite: about 20 minutes into playing with it, I accidentally touched 5V to the 3V3 pin and cooked it. :-1:

Thank you Dan - for all of your hardwork!!!
Sent from my iPhone

On Jul 18, 2015, at 2:46 PM, Daniel Garcia<EMAIL_ADDRESS>wrote:
Yes - because there are so many arduino variants and because of some fallback things I have in the code if the library doesn't recognize the platform you are building for it drops back to unspecified arduino based avr.
—
Reply to this email directly or view it on GitHub.

@stevesparks, you've brought up an interesting subject. I've currently got 2 photons, the first one I had worked for a few days, and after flashing a series of sketches built using the particle IDE, one day it decided by itself to never forget its wifi settings (not even after a full factory reset performed several times), and flashes from the particle IDE, but you never see anything going on.
This one I had purchased from @enjrolas for his L3D cube. He sent me a replacement, which last evening after the confusing setup (never can get it to work right the first time without debugging) I got connected and had flashed it a few times with the same sketch to make sure it was working OK.
But then, I powered it down for an hour or so, and when I powered it back on it had not only forgotten the wifi settings (just like yours apparently) but also the firmware I had loaded last into it.
So I might be asking a dumb question, but is there a way to flash firmware into the photon (just like you would do a bootloader flash via ICSP into the Arduino's Mega328P) - and really reset everything on the hardware, or are we stuck with the known options (cloud, USB flash)?

ummm, regarding my last question, it seems the option would be to put the device in DFU mode and use the CLI utilities to load the compiled binary - as it is explained in item #4 on the README.md.
I was hoping to try and revive my 'dead' photon but I recall having tried to flash it with the device in dfu mode but it yielded nothing.

@wmoecke Great questions and I want the answers too; Let's go find an answer, but probably not in the FastLED repo. :grinning:

Makes perfect sense, I apologize for the off-topic. Got carried away.  :-)
"Success consists of going from failure to failure without loss of
enthusiasm" - Winston Churchill
2015-07-18 19:38 GMT-03:00 Steve Sparks<EMAIL_ADDRESS>
@wmoecke https://github.com/wmoecke Great questions and I want the
answers too; Let's go find an answer, but probably not in the FastLED repo. [image:
:grinning:]
—
Reply to this email directly or view it on GitHub
https://github.com/focalintent/FastLED-Sparkcore/issues/2#issuecomment-122602503
.

@wmoecke If the code commits I referenced find their way into the device firmware updater supported by https://build.particle.io/build, I would expect the stock build of FastLED to just start working and moot this issue entirely.
I suggest that @focalintent need not work on this immediately, but instead, we might wish to push for Particle to make the change.

But @stevesparks, how about that issue you mentioned when you flashed that fork into your photon? Wouldn't that affect all photons that try to use the library flashing code from the particle IDE?

The underlying truth here is that Particle shipped us Photon parts containing a given build, "Build X". Their UI offers a FastLED library for Photon development which is not compatible with Build X. I'm sure this is a mixup because I assume FastLED works fine on Core. Solution: Particle needs to fix FastLED in their UI for Photon, or strip it out.
If this involves pushing new Photon firmware that works as well as the current shipping stuff and includes those #define statements, fine with me. If it involves them hacking their copy of FastLED, pretty much also fine with me. Either way I feel like it's their bug to fix.

No, it is my bug to fix - because every hardware platform requires extensive plowed/validation/optimization.  Personally I wouldn't trust particle to port FastLED to their platform (and from a quick look at the data sheets the I/o register layout for the photon is different enough from what's used in the core that it isn't going to just be a couple of quick defines to make it work.

To expand on my above comment, FastLED is unique amongst most arduino-style/friendly libraries in that I bypass pretty much everything in the arduino environment and talk directly to the underlying hardware at the lowest levels (sometimes in asm, even bypassing the compiler).  It means that porting FastLED to new hardware often involves an evening (or few) digging through the data sheet/user manual for the cpu (and really, how many arduino users are even aware that there is dedicated documentation at such a low level).

Ummm, that explains the 'fast' in FastLED - It's been literally just a few days since I've been made aware of this library, and since my first glimpse at some of the high level code, been thinking, "how the hell they've managed to make the calculations so much faster on the arduino" - now there's the answer.  :+1:
Coding in pure assembly language comes with a price - it's not 'adaptable' or 'portable' in any sense. Each new hardware platform will require its own version coded to cope with their idiossincrasies. I hope I spelled that word right. Too late for googling now.

So is this still an open issue? Will using this with a Particle Photon brick the device?

Yes, this is still an open issue, I haven’t had the time to work on the Photon port yet.

On Sep 7, 2015, at 10:32 AM, Robert Schanafelt<EMAIL_ADDRESS>wrote:
So is this still an open issue? Will using this with a Particle Photon brick the device?
—
Reply to this email directly or view it on GitHub https://github.com/focalintent/FastLED-Sparkcore/issues/2#issuecomment-138346427.

@focalintent I'm hoping to get an installation up and running for Halloween using the Particle Photon / FastLED / DotStars. Is there anything I can do to help? (Unfortunately my ASM skills are way out-of-date or I'd take a crack at porting it myself.) I'm curious about when you might take this on, or how the community could help? As with all open source projects, I'm grateful for your efforts to port this, so a big thanks for your work!

Mostly it is just a matter of getting the time to work on it - I have a full time job and a couple of contracting jobs that are taking up my time at the moment.  If things go well, I can probably poke at it a bit next weekend.

Got here through a search for the aforementioned error. I'd love to see a port happen at some point. :)

One more vote for a port! I got as far as figuring out that to detect the photon I need:
#elif defined (STM32F2XX)
Then I ran into about a thousand errors because I undoubtedly have my project setup wrong. I would be happy to donate as well if it helps. I really need this library for my Halloween/Christmas lights! The NeoPixel library is nowhere near fast enough!
Thanks!
James

Good news, everyone! I added the support for Photon.
See my comment in the master FastLED library.

Would be nice if the corrected version could be pushed to Particle Build (Web IDE) soon.

I've pulled the pull request over to the branch - does the particle build ide not pick it up?  (I really hate their dev environment sometimes).

Unfortunately not.
You'd have to nodge up the version number in spark.json (which I think you did already anyway) and the go into Particle Build, into libraries (as you did first time putting it online) and CONTRIBUTE LIBRARY again.
After validating and importing the new version you need to publish it again too.
All that to ensure that no half-baked commits or untested work-in-process versions go public.

Heh - I haven't touched the particle build ide since putting up the initial version of the library - I'll hopefully have some time to poke at it over the thanksgiving break.

That would be great :+1:

I'm sorry if I am missing something obvious here, but has this been pushed through yet? I just tried building "Fire2012.ino" on my Photon running the latest firmeware and latest FastLED and I'm getting that same AVR #include issue.
focalintent - I appreciate the work you've put into this, thank you.
Everyone else - thanks for your time!

Is the fixed library already in the particle build environment or do I need to manually add it via the local IDE?
As the current version there is 3.1.3 but still get the same error from the op.

I need to actually push the changes to the web based build system - which i'll do when I get back from traveling for the holidays.

Awesome, thanks :+1:

So excited for Fast LED! Thanks, refreshing the IDE like a kid at Christmas. I'm no whiz but if there is anything I can do to help please let me know.
I've not been able to get code to work using the local Particle IDE - it compiles successfully but then, after flashing ,my Photon goes into S.O.S. mode with 5 blinks for "Usage Fault" which I don't get...

Rather excited to get FastLED onto my Photon as well! Been waiting a while for this! Hope your holidays went well, Dan!

Pushed to the particle ide - thanks again, @eklex for doing the kicks!

I'm still getting a build error in the particle web IDE -- the usual
FastLED/led_sysdefs.h:19:43: fatal error: platforms/avr/led_sysdefs_avr.h: No such file or directory
#include "platforms/avr/led_sysdefs_avr.h"
^
@focalintent  -- is it working for you in the particle web IDE, or the local IDE?

FWIW, I also downloaded the current git repo, added the project folder to the local particle dev IDE, and tried to compile, and I got the same error.

I currently do not have a setup that I can easily test sparkcore stuff with (and won't for another week or so - juggling a bunch of other stuff and need to find my particle hardware) - so I'm relying on @eklex's work for the moment.  However, multiple people have reported being able to pull the current https://github.com/focalintent/FastLED-Sparkcore master and have it work for them - so I wonder if there's something else going on with your setup?
Although it's looking like something in the particle web ide didn't update.
(I really hate their web ide/platform from a library maintainer standpoint, it's almost irritating enough to the point where I sometimes get tempted to completely punt spark core/photon support - as it is, the spark core library is always behind what I do on the main FastLED repo)

It looks like there's something you have to do in the particle IDE to use a newer version of a library, it's not enough for me to update the library version.

Yeah had the same issue and selecting 3.1.4 manually fixed it.
Did have to change some things from the FastLED sample sketch as otherwise it wouldn't compile, got it to work in my AtmoOrb sketch like this:
https://github.com/ambilight-4-mediaportal/AtmoOrb/blob/master/Particle/Photon/AtmoOrb_UDP.ino

Yeah - not all of the sample sketches have the FASTLED_USING_NAMESPACE; bs in there - where there other changes you had to make?
I'l try to keep the library more up to date - there's a bunch of major changes coming down the line (check out https://github.com/FastLED/FastLED/wiki/RGBSet-Reference) - but the fact that the sparkcore stuff has to live in a separate repo makes keeping it in sync a pain in the ass :(

Sample had #include "FastLED.h" in there but particle IDE places the correct one with extra path at the top automatically so that fixed itself, also added the version check from the library at the top just in case.
CRGBSet looks very nice, thanks for your on this as this is so much better than NeoPixel :+1:

One or two things you need to do/know about libraries in Particle Build is that it keeps a local "inventory" of known libraries that might need to be refreshed to make a new version visible (sometimes you even need to press the CLEAR CACHE button in the Build properties drawer).
And once you import a lib to your project its files will actually be copied over into your remote project folder (which you never actually see), so whatever updates happen on the original library will not be carried over to your project to avoid possible breaking of running code.
To upgrade an already imported lib, you need to remove the old one and reimport the new one.

I just wanted to take a minute to thank you, Dan. I really appreciate all the hard work you put into keeping things up to date! I'll definitely be playing with the library for some time to come! Keep up the awesome work! :+1:

I cleared the cache and I created a new app, but I still get this error. Am I doing anything wrong ?
FastLED/led_sysdefs.h:19:43: fatal error: platforms/avr/led_sysdefs_avr.h: No such file or directory
#include "platforms/avr/led_sysdefs_avr.h"
Thanks Dan for the library, I'm using it on arduino and I really love it !

You have to go into the info for the library and make sure you are using version 3.1.4 or later of the library.  As mentioned, particle's build system doesn't seem to do this automatically.  Unfortunately I can't describe exact steps to you right now because their web ui isn't loading for me at all.

@tchinou1
Add some step by step screenshots:
Step 1 - Select Library as normal
http://s15.postimg.org/aqb98kt57/step1.png
Step 2 - Click on the highlighted info button
http://postimg.org/image/8x8ck97yf/
Step 3 - Click on the highlighted 3.1.4 version
http://postimg.org/image/eb74rsxon/
Step 4 - 3.1.4 should now be selected where after you can add it your app
http://postimg.org/image/s11o0lksn/

Thanks yes I don't get the error anymore, but I get a bunch of weird errors. Like if the library wasn't include, but it is.
Ex:
error: 'CRGB' does not name a type
error: 'TProgmemRGBPalette16' does not name a type
error: 'FastLED' was not declared in this scope

Make sure to use this at the top as some of the samples out there are invalid.
#include "FastLED/FastLED.h"
FASTLED_USING_NAMESPACE;

#if FASTLED_VERSION < 3001000
#error "Requires FastLED 3.1 or later; check github for latest code."
#endif

Full example here using that here:
https://github.com/ambilight-4-mediaportal/AtmoOrb/blob/master/Particle/Photon/AtmoOrb_UDP.ino

Thanks it's working right now ! :)

As always, thanks to Dan and all for the huge efforts they make. Please post a paypal donate address! I am so happy the you've ported to photon but am struggling with lots of noise and chatter/flickering on larger chains of APA102c. 1m of 30 per works well, one I get to 2 m things fall apart. I hope to get an 11/66 matrix running for these kids I'm volunteering with so the situation has me sweating.
Using the dotstar library works a lot better... Spidiey senses tingle around data rate, maybe the speed is less forgiving over greater lengths? But get an error with this declaration while plugged to default(?) A5 data and A3 clock
FastLED.addLeds<APA102, RGB, DATA_RATE_MHZ(12)>(leds, NUM_LEDS);
It doesn't like  I looked a bit into dividing SPI rate in Photon reference materials but am out of my league with clock level stuff. Do I need to run SPI begin? Set its frequency? . Maybe someone have advise on pin setting/best timing with photon and APA102s.
I'm converting to 5v levels for data with a 74hct245. I'm going to try distorting powers more frequently first but ask about the clock assuming I'll be back soon ;-)
Thanks for reading This prattling comment. Sorry.

https://github.com/FastLED/FastLED/wiki/SPI-Hardware-or-Bit-banging documents how to adjust the SPI data rate.  The dotstar library defaults to an 18Mhz data rate, slower if you are bit-bnaging (e.g. using non-hardware SPI pins) - FastLED defaults to 24Mhz, and I've seen that be a problem with longer strips.  FastLED is pretty aggressive in the bit-banging code, it's possible it is running too quickly (I can toggle clock lines _really fast- very easily :) - changing the data rate down to something like 10-12Mhz might help with what you're seeing.
(Also - in the future - more conversational help type stuff should go to the g+ community - http://fastled.io/+ - or into new issues - having an issue veer off into a half dozen different things makes them far less useful in the long run :)

Ah!  Now I remember - I haven't actually implemented hardware SPI support for the photon/spark core (their web ui/dev environment got to be too irritating for me to keep working on it) - so everything is going to use bit-banging - which, if the data rate is set to high may result in flipping ports too quickly.  (As it is, I think there's a performance optimization in there that I have to take out because it causes too many problems - but in the meantime, changing the data rate to something lower should help).

Just to add to what lessavyfav was saying I am having the same issue - 1m
144led apa102 string glitching out quite a bit. I'll have to give the data
rate a shot though. How difficult would it be for one to add support for
hardware SPI? I'm not expert programmer but if it isn't anything too
difficult I wouldn't mind poking around...
On Tue, Dec 15, 2015 at 12:54 AM, Daniel Garcia<EMAIL_ADDRESS>wrote:

Ah! Now I remember - I haven't actually implemented hardware SPI support
for the photon/spark core (their web ui/dev environment got to be too
irritating for me to keep working on it) - so everything is going to use
bit-banging - which, if the data rate is set to high may result in flipping
ports too quickly. (As it is, I think there's a performance optimization in
there that I have to take out because it causes too many problems - but in
the meantime, changing the data rate to something lower should help).
—
Reply to this email directly or view it on GitHub
https://github.com/focalintent/FastLED-Sparkcore/issues/2#issuecomment-164651316
.

@focalintent 1+ on the pita web IDE (I maintain the Particle (Spark) OneWire lib) and Thanks for your work on this one. I have been playing with 1m x 60 DotStars using my own code and hardware SPI on the Photon and Electron. I'm driving the interface directly (3.3v I'd only switch to 5v if I had long wires between the Photon and the strip, bout 12" now) to the DotStars and running the data at 50MHz without issue. The OneWire lib is all bit banged and when doing high speed banging on bits you need to take some special care depending on the specific platform if using fast pin functions (I haven't looked yet but I will be). I have a 4mx60 strip on the way that I will test with this coming weekend. I'll post the results using hardware SPI and your bit banging if I can get the lib to compile and run.
Since I'm only planning to use the APA102 LEDs, I vote for hardware SPI support, forget the bit banging!
This repo was last updated 2 months ago, I pulled it a couple days ago for local dev and had the AVR error. In the webIDE, switching to 3.1.4 passes that error which makes me wonder 'where is the latest code for Particle?'
I'm sure I'll figure it out, once I get a test running I'll test on the Electron as well for you.

:+1:

@Hotaman You might want to open an new issue and ping @focalintent

@kri5
I have it compiling now in dev with the Fire2012 demo on a Photon. I just needed to track down all the required defines and values. The json indicates it is the correct code and it does work just fine when properly configured.
Probably the biggest problem is that none of the examples currently work out of the box so there is no base reference as to how to get it to work. You have to want it!

For a working sample of Fire2012 with programmable Color Palette with FastLED and Photon you could go with this one:
https://gist.github.com/RickDB/aec4cdc3a84310f81f05

Make sure to use this at the top as some of the samples out there are invalid.
#include "FastLED/FastLED.h"
FASTLED_USING_NAMESPACE;

#if FASTLED_VERSION < 3001000
#error "Requires FastLED 3.1 or later; check github for latest code."
#endif

Hooray! Adding FASTLED_USING_NAMESPACE; is exactly what I needed to add in order to fix my FastLED code written on a local build environment (using the CLI tools to compile on the cloud).
Thank you, thank you, thank you @RickDB, @focalintent, everyone for this. I'm stoked. I modified the NoisePlusPalette.ino code to spread the visuals across a 8x8x8 LED cube made out of 512 WS2812B's.
Happy.


Unable to remove query parameters in visitor

Describe the bug
Unable to remove query parameters in visitor.
To Reproduce
Attempted to remove query parameters using a visitor.
    'remove-hidden-parameters': () => {
      return {
        Parameter: {
          leave(parameter, ctx) {
            if (parameter['x-hidden']) {
              delete ctx.parent[ctx.key];
            }
          }
        }
      }

Expected behavior
Expected query parameters with x-hidden: true to be removed.
Actual behavior
YAMLException: unacceptable kind of an object to dump [object Undefined]
    at writeNode (/usr/local/lib/node_modules/@redocly/openapi-cli/node_modules/js-yaml/lib/js-yaml/dumper.js:779:13)
    at writeBlockSequence (/usr/local/lib/node_modules/@redocly/openapi-cli/node_modules/js-yaml/lib/js-yaml/dumper.js:542:9)
    at writeNode (/usr/local/lib/node_modules/@redocly/openapi-cli/node_modules/js-yaml/lib/js-yaml/dumper.js:763:9)
    at writeBlockMapping (/usr/local/lib/node_modules/@redocly/openapi-cli/node_modules/js-yaml/lib/js-yaml/dumper.js:657:10)
    at writeNode (/usr/local/lib/node_modules/@redocly/openapi-cli/node_modules/js-yaml/lib/js-yaml/dumper.js:750:9)
    at writeBlockMapping (/usr/local/lib/node_modules/@redocly/openapi-cli/node_modules/js-yaml/lib/js-yaml/dumper.js:657:10)
    at writeNode (/usr/local/lib/node_modules/@redocly/openapi-cli/node_modules/js-yaml/lib/js-yaml/dumper.js:750:9)
    at writeBlockMapping (/usr/local/lib/node_modules/@redocly/openapi-cli/node_modules/js-yaml/lib/js-yaml/dumper.js:657:10)
    at writeNode (/usr/local/lib/node_modules/@redocly/openapi-cli/node_modules/js-yaml/lib/js-yaml/dumper.js:750:9)
    at writeBlockMapping (/usr/local/lib/node_modules/@redocly/openapi-cli/node_modules/js-yaml/lib/js-yaml/dumper.js:657:10) {
  reason: 'unacceptable kind of an object to dump [object Undefined]',
  mark: undefined
}

openapi-cli Version(s)
What version of openapi-cli are you using?
1.0.0-beta.18
Node.js Version(s)
v14.14.0

Side note: @sirianni you may want to update to a newer version of openapi-cli (we have released 1.0.0-beta.60 which has many improvements and bug fixes since beta.18). https://redoc.ly/docs/cli/changelog/

Also, this may be helpful: https://redoc.ly/docs/cli/guides/hide-apis/#pluginsdecoratorsremove-internal-schema-properties.js

Thanks @adamaltman .  We are already successfully using the approach from https://redoc.ly/docs/cli/guides/hide-apis/#pluginsdecoratorsremove-internal-schema-properties.js
The issue is that this doesn't work for internal-only query parameters.

@adamaltman yes


Allow path variables to be optional

What problem does this feature solve?
Currently, when providing a path in an endpoint like /carriers/:carrier, all path variables (:carrier) are required. But this isn't the case with all endpoints.
For example: /external_integration_provider_credentials/:name/:version would not be able to be added correctly as :version is optional but the SDK will treat it as required.
What should the solution look like?
A syntax like the following:
/external_integration_provider_credentials/:name/:version?

Should mean that :name is required, but :version is optional. SDK should not throw errors when :version is not passed.
Relevant log output
No response
Additional context
No response

:tada: This issue has been resolved in version 2.3.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fix strictness in PlutusTx.IsData.TH (PLT-5830)

Currently:
let body =
        [|
            let !indexMatchCase = $(handleList argNames argsExpr)
                !fallthrough = $kont
            in BI.ifThenElse ($ixExpr `BI.equalsInteger` (index :: Integer)) (const indexMatchCase) (const fallthrough) BI.unitval
        |]

This is wrong - indexMatchCase and fallthrough should be non-strict, because (1) only one of them will be evaluated; (2) evaluating indexMatchCase when it shouldn't be evaluated can lead to BI.head [] (e.g., in the UnsafeFromData (Maybe a) instance); (3) evaluating fallthrough when it shouldn't be evaluated can lead to PT1 (reconstructCaseError).
But why does it work now? Because bang patterns in TH quotations are ignored, so in the splice, there's no bang pattern on indexMatchCase or fallthrough.
For the other bang patterns, we do want them to be strict. This PR fixes them.

What about the explanatory note?

What about the explanatory note?

Oh, right, I'll open a new PR for that.


Incremental mode does not work with a different date format.

I have been trying to load data from SAP HANA to HDFS and I am using "AEDAT" as the incrementing column.
The date format "AEDAT" has is "YYYYMMDD", but the Kafka connector gives out the following error:
[2020-10-05 16:37:13,587] ERROR WorkerSourceTask{id=incremental-source-0} Task threw an uncaught and unrecoverable exception (org.apache.kafka.connect.runtime.WorkerTask:186)
java.lang.IllegalArgumentException: The Incrementing column is not found in the table or is not of correct type
        at com.sap.kafka.connect.source.querier.IncrColTableQuerier.getIncrementingColumn(IncrColTableQuerier.scala:106)
        at com.sap.kafka.connect.source.querier.IncrColTableQuerier.<init>(IncrColTableQuerier.scala:21)
        at com.sap.kafka.connect.source.GenericSourceTask.$anonfun$start$8(GenericSourceTask.scala:121)
        at com.sap.kafka.connect.source.GenericSourceTask.$anonfun$start$8$adapted(GenericSourceTask.scala:99)
        at scala.collection.immutable.List.foreach(List.scala:392)
        at com.sap.kafka.connect.source.GenericSourceTask.start(GenericSourceTask.scala:99)
        at org.apache.kafka.connect.runtime.WorkerSourceTask.execute(WorkerSourceTask.java:215)
        at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:184)
        at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:234)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

hana-source.properties
name=incremental-source
connector.class=com.sap.kafka.connect.source.hana.HANASourceConnector
tasks.max=1
topics=saptohdfs
connection.url=jdbc:sap://xx.xx.xx.xx:30041/
connection.user=user
connection.password=pass
saptohdfs.table.name="SAPHANADB"."EKPO"
mode=incrementing
saptohdfs.incrementing.column.name="AEDAT"

hdfs-sink.properties
name=hdfs-sink
connector.class=io.confluent.connect.hdfs.HdfsSinkConnector
hdfs.url=hdfs://ip-10-1-1-131.ap-south-1.compute.internal:8020/warehouse/tablespace/external/hive
tasks.max=1
topics=saptohdfs
flush.size=3
hive.integration=true
hive.metastore.uris=thrift://ip-10-1-1-131.ap-south-1.compute.internal:9083
schema.compatibility=BACKWARD
format.class=io.confluent.connect.hdfs.avro.AvroFormat
#value.converter=io.confluent.connect.avro.AvroConverter

ABAP AEDAT type is actually not a valid DATE type but represented as type NVARCHAR(8) in HANA.
The incremental mode only works with SQL numeric or date/time/timestamp types.

@elakito So, how can someone make it work in incremental mode? I am new to Kafka Connect. Please help me out here.

@xrokrx We could support other comparable types such as NVARCHAR. I think this incremental loading part needs other changes as well. But first, I'll add this additional type handling to the current implementation.

It still gives out this error in incremental mode.

It still gives out this error in incremental mode.

@xrokrx did you use the build from the PR branch? We haven't merged the change to master. The fix is still only in the PR branch. If yes, we need to see the table column definition of your table to see if that column type is covered by the types added in this fix.

@xrokrx It looks like you are using the master branch because the error at line 106 or IncrColTableQuerier.scala shown in your terminal indicates the code in the master branch. In the fixed code, the same error would be raised at line 101.
https://github.com/elakito/kafka-connect-sap/blob/ay-incr/src/main/scala/com/sap/kafka/connect/source/querier/IncrColTableQuerier.scala#L101

@xrokrx It is merged in master.

@elakito Hi, Sorry for the late response. I tested it. It is still giving out the same error.

@elakito Hi, Here is the error stack trace.
[2020-11-25 14:17:16,846] INFO WorkerSourceTask{id=incremental-source-0} flushing 0 outstanding messages for offset commit (org.apache.kafka.connect.runtime.WorkerSourceTask:443)
[2020-11-25 14:17:16,847] ERROR WorkerSourceTask{id=incremental-source-0} Task threw an uncaught and unrecoverable exception (org.apache.kafka.connect.runtime.WorkerTask:186)
java.lang.IllegalArgumentException: The Incrementing column is not found in the table or is not of supported type
        at com.sap.kafka.connect.source.querier.IncrColTableQuerier.getIncrementingColumn(IncrColTableQuerier.scala:100)
        at com.sap.kafka.connect.source.querier.IncrColTableQuerier.<init>(IncrColTableQuerier.scala:21)
        at com.sap.kafka.connect.source.GenericSourceTask.$anonfun$start$8(GenericSourceTask.scala:121)
        at com.sap.kafka.connect.source.GenericSourceTask.$anonfun$start$8$adapted(GenericSourceTask.scala:99)
        at scala.collection.immutable.List.foreach(List.scala:392)
        at com.sap.kafka.connect.source.GenericSourceTask.start(GenericSourceTask.scala:99)
        at org.apache.kafka.connect.runtime.WorkerSourceTask.execute(WorkerSourceTask.java:215)
        at org.apache.kafka.connect.runtime.WorkerTask.doRun(WorkerTask.java:184)
        at org.apache.kafka.connect.runtime.WorkerTask.run(WorkerTask.java:234)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
[2020-11-25 14:17:16,848] ERROR WorkerSourceTask{id=incremental-source-0} Task is being killed and will not recover until manually restarted (org.apache.kafka.connect.runtime.WorkerTask:187)

@elakito Hi, Any update?

@xrokrx I am puzzled with this situation. Could you look at the column type of this table? I was told AEDAT is normally represented as NVARCHAR in HANA and if that is the case, it should have been handled with the current version. Unfortunately, the current code doesn't write the type name when this situation happens. So, I just added this error text to the master branch code. https://github.com/SAP/kafka-connect-sap/commit/35d0e66dad84d91f557a44bb3ff716dbe044a920
If you cannot inspect the column type of your HANA table using Hana Tool, you could try the updated code to find it out. Thanks.

The current code should log the column name and the type when the assigned type is unexpected/unhandled. As mentioned, if you can look at your table and tell us its column type seen in the HANA table. I only know AEDAT being represented as NVARCHAR in HANA.


Integrate Condition Value Sets into CQL logic

Conditions value sets with common names: https://docs.google.com/spreadsheets/d/1oqmt-ykjkurdw_4Gn043QuEQBt2qTyWx/edit?usp=sharing&ouid=114658391514455419481&rtpof=true&sd=true
Conditions value set library in IG: https://build.fhir.org/ig/HL7/fhir-us-mcc/branches/master/mcc_chronic_condition_value_sets.html

Dave update: 200+ value sets. Have 50 or so in there. Problem encountered: What does it mean when a patient condition classifies into more than one value set? Result is that a condition will appear more than once grouped into different value sets. Need to review; perhaps at Connectathon (Himali, Emma, Gay??).


temporarily fix t3k pipelines by disabling broken tests

T3K pipelines are failing and hard to maintain.
Disabled relevant tests and made issues tagging relevant owners
https://github.com/tenstorrent/tt-metal/issues/10317
https://github.com/tenstorrent/tt-metal/issues/10321
https://github.com/tenstorrent/tt-metal/issues/10320
https://github.com/tenstorrent/tt-metal/issues/10323
https://github.com/tenstorrent/tt-metal/issues/10324
https://github.com/tenstorrent/tt-metal/issues/10322

#10322 has been fixed.

all t3k workflows back and passing


Revert "fix check all the cases before build_search_argument (#44615)"

Reverts apache/doris#44801

run buildall


[ContentBundle] StructureExtension documentation

By @wachterjohannes from https://github.com/sulu-cmf/SuluContentBundle/issues/138

https://github.com/sulu-cmf/sulu/pull/120
https://github.com/sulu-cmf/SuluContentBundle/pull/137

@wachterjohannes Probably @dantleech will do that for you after the refactoring ;-)


New Applications can be started when in between intakes

As an applicant
I want to be able to create new applications in between intakes
so that I can get a jump start on the next intake
Acceptance Criteria:

[ ] The 'Create Application' button is enabled when in between intakes

With this user story, there appears to be a risk that users are starting an application with an oudated form. Was this considered? I see this is at the top of the "next sprint candidates" too. Is this that high priority?

Blocked by discussion with NWBC about whether they want to allow applicants to create applications between intakes.

Feedback from NWBC
"There is a risk that Intake 2 might be different, or have a different focus...Current risk mitigation would be not to let them create new applications in case criteria change."

Hey team! Please add your planning poker estimate with Zenhub @AntBush @matthieu-foucault

Closing because current functionality is what we want: applicants can't create applications between intakes.


Initial line of a Polygon Mapbox and MapLibre disappears at 0 and 180 degrees whilst drawing

Whilst drawing a using the Mapbox or MapLibre adapters the initial line appears to disappear when in the 0 and 180 degree positions. See this GIF for an example:
https://user-images.githubusercontent.com/8822075/205132213-337023cf-d632-4836-b18b-0dcb35e785f3.mp4
This should be fairly easy to replicate, simply start drawing a polygon using the Mapbox Adapter and rotate the line 360 to see it flash and reappear as you move past the 0 and 180 degree marks.

This was happening because of the tolerance property defaulting to 0.375. Setting it to 0 prevents simplification of the GeoJSON and this glitch.  Fixed in 0.0.1-alpha.23.


FAST Farm infrastructure improvements

Feature or improvement description
This pull request adds the regression test infrastructure as well as enables a single regression test (TSinflow) to run within GitHub Actions. It also updates the CMake configuration to search for the Fortran libraries of OpenMP rather than require the C and C++ libraries., as well.
I've also changed the name of the executable from openfast-farm to fast-farm for consistency with other references to this software.
Impacted areas of the software
FAST Farm CMake configuration and regression test infrastructure
Additional information
Its not ideal to have multiple copies of the 5MW turbine directory in r-test and multiple copies of the controllers. I'm looking at ways to simplify this, but in the meantime we can continue with the setup here.
Also, the test cases were initially created by @kshaler and updated by me in the fastfarm branch of the r-test repository.
the LESinflow test case is not yet enabled due to out of date input files.
For review: @jjonkman @kshaler

Removing that space in all of the VTK files leads to this error:
At line 8604 of file /Users/rmudafor/Development/fastfarm/modules/nwtc-library/src/NWTC_IO.f90
Fortran runtime error: Bad integer for item 1 in list input

Error termination. Backtrace:
#0  0x111a6bebd
#1  0x111a6cb75
#2  0x111a6d76b
#3  0x111c91008
#4  0x111c95019
#5  0x111c95bd2
#6  0x110781d55
#7  0x1107f2bbc
#8  0x1107e51d9
#9  0x10fc5c205
#10  0x10fcb10f3
#11  0x1112e85ce

The space in the vtk files is standard. Can we change the source code to include the space?

@kshaler -- Where are you getting that a space before field is standard?  I don't see that in the VTK documentation, and all examples show FIELD showing up in the first column: https://vtk.org/wp-content/uploads/2015/04/file-formats.pdf.  Did you change this in your branch of FAST.Farm?
@rafmudaf -- I've not seen this error before.  Probably need to run this one through the debugger to understand what is going on.

All the vtk files I have have that space in front of FIELD. So maybe it's changed somewhere in SOWFA?

@kshaler -- Yes, sounds like the problem is in SOWFA.  But I'm also not sure you've been running FAST.Farm with these files, unless you've changed the FAST.Farm source code on your branch accordingly; did you do that?

Hi @rafmudaf and @kshaler,
Thanks for developing these FAST.Farm r-tests!  I reviewed these a bit; here are some small changes I propose:

It looks like the executable compiled with CMake is named fast-farm instead of FAST.Farm, which is compiled with Visual Studio.  Is there a reason for this difference? The FAST.Farm documentation uses the dot.  Can CMake be changed accordingly?
It would be great if the duplicated files from the OpenFAST r-tests could be eliminated (the duplicated InflowWind, AeroDyn, and ElastoDyn input files for the NREL 5-MW baseline turbine; the duplicated *.fst and ServoDyn files are needed).
The LESinflow and TSinflow directory structures are set up differently, with one having the OpenFAST model in a subdirectory and the other without.  I don't see any reason for this difference, so, I suggest organizing the file structure to be the same for both tests.
The FAST.Farm input files (*.fstf) do not have the most up-to-date formatting regarding variable names and comments.  Can these be updated based on the attached template? FAST.FarmInputFile.fstf.txt
For the LESinflow case, I don't think high-resolution files beyond Amb.t900.vtk are used because the simulation is only 90 s.  I suggest deleting the extra files (Amb.t901.vtk through Amb.t996.vtk).
For the TSinflow case, I'm a bit confused where the dX_Low = 9.71 m comes from.  I calculate a mean wind speed of the TS wind field of 8*(175/85)^0.2 = 9.24 m/s, based on TS inputs in 90m_08mps.inp.  With a time step of 0.1 s, this equates to a dX_Inflow of 0.924 m and 9.71/0.924 = 10.5, which is not an integer.  Also, I would expect dX_High = dX_Low in this case.
The file NRELOffshrBsline5MW_Onshore_ElastoDyn.dat does not appear to be used; suggest deleting.

What is left to push this?

Thanks for the comments. My response to the points that relate to me are below.

It looks like the executable compiled with CMake is named fast-farm instead of FAST.Farm, which is compiled with Visual Studio. Is there a reason for this difference? The FAST.Farm documentation uses the dot. Can CMake be changed accordingly?

I agree that the name of the executable should match what your team has in the documentation or have been previously using. I changed it from openfast-farm to fast-farm in https://github.com/jjonkman/OpenFAST/pull/15/commits/2776fdc6d038ec476663d803b2666d16ade3524a and again to FAST.Farm in https://github.com/jjonkman/OpenFAST/pull/15/commits/eb578ba574866772ef1689829f6bcfcec94da96c. This last commit can be referenced if the binary name needs adjusting in CMake in the future.

It would be great if the duplicated files from the OpenFAST r-tests could be eliminated (the duplicated InflowWind, AeroDyn, and ElastoDyn input files for the NREL 5-MW baseline turbine; the duplicated *.fst and ServoDyn files are needed)

The automated test system requires this so that the FAST.Farm tests do not depend on the OpenFAST tests. This is a limitation of the regression test system, but I'm working on solving that problem in the larger context. Let's keep it as is for now, but it will be resolved in the near future.

The file NRELOffshrBsline5MW_Onshore_ElastoDyn.dat does not appear to be used; suggest deleting.

Good catch, its been removed

From an infrastructure perspective, I think the only thing remaining is updating the LESinflow test so that it can run with this version of FAST Farm and also addressing @jjonkman's comments.

Thanks, @rafmudaf.  Can you also help with bullets 3-5?  This requires moving files around and ensuring the paths and formatting are set up correctly in the input files.
I've now fixed the error that was causing FAST.Farm to fail when the FIELD keyword was used on line 9 of the VTK files--see: https://github.com/jjonkman/OpenFAST/commit/25f89af8a3b4749be67a542633b2cb9c938f1408.  This should now enable the LESinflow case to run. (However, there still cannot be a space before FIELD keyword.)  FAST.Farm now reads the VTK files OK, but I noticed the OpenFAST input files for this test are old, not having yet been upgraded to a format compatible with the dev branch.  @rafmudaf -- Can you update the files for this case and ensure it runs to completion?
@kshaler -- Please respond regarding dX_Low and dX_High from bullet 6.

I've updated the FAST.Farm input file to have the correct discretization values.

Thanks @kshaler.
@rafmudaf -- Can you merge Kelsey's change for the TSinflow case and address bullets 3-5 in the r-test?  Hopefully FAST.Farm will then execute these cases as expected.

@jjonkman I've addressed those three items in your list in https://github.com/jjonkman/OpenFAST/pull/15/commits/631602fff0bdd6ed3556b0f7488a6e402b78f176.

Anyone know why GitHub Actions isn't running?

@jjonkman the automated tests have passed, so this is ready for review.


Access LookupInBuilder

I need to access LookupInBuilder from outside
To promisify lookupIn

@couchbase I already signed CLA

Hey @sm2017 ,
Would you be able to check your Gerrit settings and confirm the email address indicated above is attached to the account you signed the CLA with?
Cheers, Brett

I repead github oauth author again , and gerrit signed in me , and shown my username at top right corner of page
But the email address is empty in Gerrit setting

Hey @sm2017, inside your Gerrit Settings, there is a button to add additional email addresses linked to your account.  Please link the address above to have the patch pulled through!  Cheers, Brett

Done

Hey @sm2017 ,
I'll get this merged before the next release.
P.S. Our system still doesn't see you having signed our CLA.  Any chance you could double-check your gerrit email and CLA settings?
Cheers, Brett

Hey @sm2017,
I'm going to close this and manually update/include your requested change through here:
https://issues.couchbase.com/browse/JSCBC-509
http://review.couchbase.org/100151
Cheers, Brett


Windows support broken by Socket

The commit https://github.com/stackotter/swift-bundler/commit/7bfcf2069930ab484ec4beb377ebda2d375ad4bd adds dependency on https://github.com/stackotter/Socket, which blocks building on Windows.
To restore the support, we may make the dependency and related functionalities platform-specific.

Ah, unfortunate, that may require making our own socket library in future then (or updating that old one), cause I'd like to eventually bring hot reloading to windows too.
I'm currently in the middle of refactoring a bunch and bringing hot reloading to Linux so I'll look into addressing this as part of/after that.
Are you using swift bundler on windows at the moment? I don't recall ever putting effort into making it support Windows so that's kinda cool if it does even if it's indirectly via the linux platform option

@stackotter I think issues are disabled on that project, but might be worth mentioning ZeroMQ, it has solid cross-platform support, with TCP sockets on Microsoft Windows, and Posix sockets on macOS and Linux.

Does ZeroMQ let you just use their cross-platform tcp socket wrapper?


JSDoc type annotations work in VSCode but not Monaco

monaco-editor npm version: 0.6.1
Browser: All
OS: all
If I put this code in VSCode 1.5.3
/** @type {WebGLRenderingContext} */
var gl = canvas1.getContext("webgl");

/** @type {CanvasRenderingContext2D} */
var ctx = canvas1.getContext("2d");

Both gl and ctx will get the correct auto-completion for their respective types but the same code does not get auto completions in Monaco.  Note: Monaco does know the definitions of WebGLRenderingContext and CanvasRenderingContext2D as I can type WebGLRenderingContext.prototype. and see all the completions.
Is this a feature I just need to enable? Is it just not yet pulled from VSCode? Or is it a feature that's not meant to be part of Monaco?

Hmm, it's a surprise for me too. @jrieken any ideas?
I've also found function annotations to not be working
/**
 * @returns {string}
 */
function f() {
	return canvas1;
}

We ship different versions of TypeScript in the standalone editor and VS Code

Meaning if I just upgrade the TypeScript support to the same version in VS Code it will start working? Or, meaning the stuff in VS Code is not compatible with Monaco?

Well if you're curious I added the monaco editor to http://webglfundamentals.org.  All of the examples run in a codepen style editor using monaco. Every sample has this at the top
  /** @type {HTMLCanvasElement} */
  var canvas = document.getElementById("canvas");
  var gl = canvas.getContext("webgl");

If monaco supported type annotations like VSCode then from that both canvas and gl would support all the intellisense like functions.
If there's a way to make that work that would be great.

@jrieken is there any progress with this issue?

closing as dupe of #177

I'm confused how #177 relates to this. #177 is closed saying the project is now on TypeScript 2.1 but this issue, issue #203 still doesn't work.
Is there's a way to make it work? Or if not could you please re-open this issue?

I can confirm JSDoc annotations still don't work.
@jrieken Perhaps there is more to getting them work than updating to TS 2.1

Is there any way to hint Monaco of the type of a given function parameter dynamically (eg without modifying the editor source) ?
I tried dynamically creating a d.ts for a given function signature, but when you declare that function in the editor it treats it as an override, and ignores the type information I added.
See
http://stackoverflow.com/questions/43037243/provide-type-hints-to-monaco-editor

I have added a PR in monaco-typescript.  The providers for monaco-editor are greatly simplified from the language features for vscode.  In vscode there is now further abstraction away from the language services which also extractions the documentation and tags from the quick info and returns them from the hover provider.

@kitsonk  I had a quick look at your PR ( https://github.com/Microsoft/monaco-typescript/pull/14 ), I don't think it actually fixes this issue, which is about having the Monaco know the type of a parameter from the JSDoc annotations, so that code complete / intellisense works on that parameter?

This works for me (without https://github.com/Microsoft/monaco-typescript/issues/14) on master. It is important to know that this is supported in JS files only and the we interpret files as JS when they have an uri-path that ending in .js like some/path/some/file.js. When no ending is available make sure to use the allowJs-compiler setting

The fix for this (https://github.com/Microsoft/monaco-typescript/commit/9b5c885b40c385b726f70627c7957c2e1436aa0e) will be in the next release.

Cool. Just to confirm @jrieken, a and b will have code complete within the body of foo()?


[go_router] suport transitionDuration for  CupertinoPage

suport transitionDuration for  CupertinoPage

@philos3 Can you be more specific about this? Have you tried transition_animations's example?


feat: added new kafka topic configuration properties

Description
The following updates are introduced for the kafka topic configuration object:

Updated additionalProperties as true.
Added 4 new properties as proposed in the issue.

Please check the related issue for more details.
Note: Once we are happy with the changes I'll create another PR to update the bindings' README file in the other repo.
Related issue(s)
Resolves the following issue: https://github.com/asyncapi/bindings/issues/231

Very much needed! 👍 We're struggling to work around these gaps with x- extensions.

Hey, please just remember that JSON Schema is just a tool, not a spec itself so whatever is added to JSON Schema, first need to be added to Kafka Binding spec -> https://github.com/asyncapi/bindings/tree/master/kafka

I've updated this PR as a draft because the following PR needs to be reviewed first:

https://github.com/asyncapi/bindings/pull/238

Given the related bindings PR (https://github.com/asyncapi/bindings/pull/238) got merged I think we can continue with this one.
I've added a new schema version (0.5.0) to reflect the new changes in the kafka topic configuration object.
It would be great if you could re-review this PR @dalelane.

Sorry guys, I've messed around with my commits. I had a problem verifying my signature but now it's fixed.
It seems like extra checks (Test NodeJS PR ones) were added because of my commit changes. If it's necessary, I can close this PR and create a new one.
Can you please re-approve the PR? @dalelane

Hey guys, can you please approve that 1 workflow? It seems like we need to run that workflow before the merge.  @dalelane @smoya

/rtm

@derberg @gokerakc sorry I missed that when I did the review - I've added a PR now at https://github.com/asyncapi/spec-json-schemas/pull/501

Thanks @dalelane!


Fix toasts to use API errors

Blocked by https://github.com/GuthrieW/shl-trading-cards/issues/92

Not actually a desirable behavior.


revert converting scylla_cloud_io_setup to python library

This is v3 of #347.
Change list are:

fix error on scylla_cloud_io_setup which was not committed on v2 accidentally

The decision converting scylla_cloud_io_setup to python library was mistake,
since there are some users who wants to construct IaaS image by themselves,
not using our official image.
They will need to invoke scylla_cloud_io_setup from shell, not python.

Created v3, but it haven't passed SCT, because the test failed with another issue: https://github.com/scylladb/scylla/issues/10455
I have a patch for this, but it's not merged yet:
https://github.com/scylladb/scylla/pull/10467
Now I'm trying to test this with modified master branch (with 10467 patch).

Rebased with latest next.

Jenkins test passed for newly pushed version: https://jenkins.scylladb.com/view/master/job/scylla-master/job/releng-testing/job/ami/1513/

@syuu1228 https://jenkins.scylladb.com/job/scylla-master/job/releng-testing/job/next-machine-image/394/ is failing in artifact tests (all of them), not sure if it's related to your patch or not, but please verify it

Fixed the error, running next-machine-image test:
https://jenkins.scylladb.com/job/scylla-master/job/releng-testing/job/next-machine-image/398/

Fixed the error, running next-machine-image test: https://jenkins.scylladb.com/job/scylla-master/job/releng-testing/job/next-machine-image/398/

Test passed.

@syuu1228 Do we need also to backport this to 5.1 and 2022.2 ?


this main.py not

This main.py not running
(videoEnv) C:\Users\dangh>cd test
(videoEnv) C:\Users\dangh\test>cd video-subtitle-extractor
(videoEnv) C:\Users\dangh\test\video-subtitle-extractor>python main.py
Running Verify Fluid Program ...
W0818 00:59:54.542205 20912 device_context.cc:404] Please NOTE: device: 0, GPU Compute Capability: 6.1, Driver API Version: 11.4, Runtime API Version: 10.2
W0818 00:59:54.548205 20912 device_context.cc:422] device: 0, cuDNN Version: 7.6.
Your Paddle Fluid works well on SINGLE GPU or CPU.
Your Paddle Fluid works well on MUTIPLE GPU or CPU.
Your Paddle Fluid is installed successfully! Let's start deep Learning with Paddle Fluid now
使用GPU进行加速
请输入视频完整路径：C:\Users\dangh\test\video-subtitle-extractor\main\EP02.mp4
帧数：49924.0，帧率：25.00011155895556
【处理中】开启提取视频关键帧...

It is running. If you want graphic interface, you can run gui.py, which is recommended.


Extra question about horizontally scaled Stunner

I've been trying to understand a bit more how ICE works, particularly in the case of multiple Stunner pods in the symmetric ICE model.
In https://github.com/l7mp/stunner/issues/31#issuecomment-1234234671 the following was mentioned

I'm not sure we're using the word "looping back" in the same sense. We use this term to mean that in the headless model, when there is no media server at all, both clients open a relay candidate on STUNner and then these magically get looped back to one another during the ICE conversation, connecting the two clients. This works because both relay candidate's contain pod IPs, so this is a fairly standard TURN server use case it is just that the relay candidates are opened "inside" the cluster.

The communication that seems to be being established is client -> stunner_a <-> stunner_b <- media server.  Is there any documentation or details about how the stunner_a <-> stunner_b communication is being established by ICE?  Or is this something that Stunner is doing that is extra to ICE?

:-D This is one of those tricky parts in ICE and TURN that just magically works out of the box, without us having to configure or add anything. I was also puzzled when I first discovered this...:-)
Here is the process flow:

the client obtains a TURN allocation from stunner_a, suppose that the transport relay address (the UDP connection opened by STUNner inside the Kubernetes private pod-pod network that will it will use to forward the TURN payload received from the client) is IP_a:port_a, where IP_a is the IP of the stunner_a pod;
the client generates an ICE candidate of type relay with the relay address IP_a:port_a and sends it along to the media server via the signaling connection;
the media server opens a TURN allocation on stunner_b, suppose that the transport relay address is IP_b:port_b, where IP_b is now the IP of the stunner_b pod;
the media server sends the ICE relay candidate, including the relay address IP_b:port_b in it, to the client via the signaling connection;
the client starts ICE negotiation and, at a certain (very late) point during the ICE conversation, it selects the ICE candidate pair corresponding to the two ICE relay candidates (its own as the local candidate, plus the one received from the media server as the remote candidate);
the client creates a permission on the TURN allocation at stunner_a to send to IP_b (the IP corresponding to the remote ICE candidate in the selected ICE candidate pair);
the client tries to connect via its TURN allocation through the relay address IP_a:port_a to IP_b:port_b (the relay address in the remote ICE candidate), which just happens to be the transport relay address created by the media server on stunner_b (this is the only "magical" part here, but there is no magic here at all, it's how ICE negotiation goes over relay candidates);
the connection attempt will most probably fail, since the media server still hasn't created a TURN permission for receiving traffic from IP_a over its TURN allocation;
the media server also enters the ICE negotiation phase (in fact, with trickle ICE the negotiation starts immediately and the connection attempt is made right after the relay candidates become available);
the media finally selects the relay-relay ICE candidate pair (note that this is always the least preferred ICE candidate pair since TURN is considered "expensive" in the ICE RFC, but this is only because TURN servers often add significant delay due to being hosted far from the media server, but this is not the case for STUNner whose extra latency/jitter is typically in the 10-100 microsecond range by being in the same cluster as the server);
the media server creates a TURN permission (this is why you must add the service covering all stunnerd pods to the backend of the UDPRoute for symmetric ICE, otherwise the permission will not be granted by STUNner) to IP_a (since for the server the remote ICE candidate is now the relay candidate received from the client);
the media server tries to connect via the relay address IP_b:port_b to IP_a:port_a (the relay address of the client);
the connection request is now successful, since both parties have permission to send to the other, and both the sender and the receiver IP:port in the connection attempts (this is usually a STUN Binding request) are exactly the ones as specified in the relay candidates;
ICE enters into the connected state and the media can start to flow between the client and the server over the negotiated connection.

The traffic flow is something like the below:
client <--TURN--> stunner_a(IP_a:port_a) <--UDP--> (IP_b:port_b)stunner_b <--TURN--> media server

Note that in symmetric ICE mode both parties have to go through STUNner, which adds some extra processing compared to asymmetric ICE where only the client uses STUNner, the media server connects directly to the relay address via UDP as it is in the same IP subnet as the stunnerd pods:
client <--TURN--> stunner_a(IP_a:port_a) <--UDP--> media server

Note that even with symmetric ICE the ICE negotiation usually succeeds over asymmetric ICE and never reaches the relay-relay case. This is because, as mentioned above, ICE tries the candidate pairs in order of priority and the relay-relay pair is always the last one (minus TCP, I never know how TCP host/srflx candidates are prioritized versus UDP relay candidates). Before the relay-relay candidate, however, ICE will try to match the client's relay candidate with the media server's host candidate (this will contain the media server's own pod IP) and this will be successful due to the above so the relay-relay pair is never used.
 That's why we advise against using it unless it's not absolutely necessary.
Hope this clarifies the symmetric ICE case.

That's a great explanation; thank you so much!

Closing this for now, feel free to reopen if something comes up.


fix link - troubleshooting-ci.md

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app


Negative weights from max_sharpe function

What are you trying to do?
Sorry for my poor English in advance.(Currently, I am university student from South Korea)
I am trying to get optimal portfolio with Korean assets.
Here is my example code for better explanation
mu = expected_returns.mean_historical_return(df)
S = risk_models.CovarianceShrinkage(df).ledoit_wolf()
ef = EfficientFrontier(mu, S, weight_bounds=(0,1))
weights = ef.max_sharpe()
print(weights)

df is stock price dataframe.
And for the output, which is weights, I am keep getting some negative weights.
I don't get it why I am getting negative weights despite setting boundaries(weight_bounds=(0,1))
Plus, it doesn't even raise error.
What have you tried?
I applied another efficientFrontier method, 'efficient_return' and it works fine.
ef.efficient_return(0.2)
.

Very strange. Are they big negative weights? Or near zero (in which case it might just be a floating point thing)

thank you for rapid reply.
I will give you more detailed explanation about output of my expected return and risk model.
mu = expected_returns.mean_historical_return(df)
>>>
252670.KS   -0.559241
091220.KS    0.046982
114800.KS   -0.310602
251340.KS   -0.325860
233740.KS    0.502901
dtype: float64

S = risk_models.CovarianceShrinkage(df).ledoit_wolf()
>>>
           252670.KS  091220.KS  114800.KS  251340.KS  233740.KS
252670.KS   0.281960  -0.129378   0.139624   0.137063  -0.262158
091220.KS  -0.129378   0.125743  -0.065309  -0.055681   0.105773
114800.KS   0.139624  -0.065309   0.077408   0.069616  -0.133249
251340.KS   0.137063  -0.055681   0.069616   0.113887  -0.205718
233740.KS  -0.262158   0.105773  -0.133249  -0.205718   0.401651

ef = EfficientFrontier(mu, S, weight_bounds=(0,1))
weights = ef.max_sharpe()
>>>
OrderedDict([('252670.KS', -2.878111693e-07), ('091220.KS', 2.926511146e-07), ('114800.KS', -1.105321317e-07), ('251340.KS', 2.917380841e-07), ('233740.KS', 0.9999998137326296)])

Hi @Younghoon-Lee,
Those are very small negative weights, so it's just a numerical thing. Use ef.clean_weights() if you would like a nicely-formatted output that has been rounded.
One comment: the optimiser has essentially given 100% weight to the last asset – probably because its return is so much higher than the other assets.
Hope this helps!
Robert


Is there a reason for making the whole layout client side?

More of a question than an issue - is there a reason to make the whole layout.tsx "use client", rather than just the ? That seems to defeat the purpose of NextJS's server side rendering.
I've embedded the progress bar in a component, which is marked "use client" and then imported into the layout.tsx, so the layout can stay server side. It seems to be working - any reasons why that wouldn't work?

The component must be used in a "use client" because it uses react hooks (which only work on the client side).
The solution I proposed in the readme is to create a "use client" provider that you add to your layout.tsx, without having to put "use client" in your layout.tsx.
I hope I was able to answer your question.

Oh I see - I misunderstood your documentation here, my bad. I just made a little PR if you're open to suggestions.


no-missing-import does not work with "paths" from "tsconfig.json"

In a monorepo, you typically use the "paths" option inside of the "tsconfig.json" file to make your individual packages aware of each other like this:
tsconfig.json
{
    "paths": {
      "foo": ["packages/foo/src/index.ts"],
      "bar": ["packages/bar/src/index.ts"],
    },
}

However, this triggers false positives for no-missing-import.

Any updates on this?

🤔 I have not had this issue in my monorepos, could you make a small reproduction repository?

Here are a couple of screenshots from a yarn v3 repo:

I have not needed the "paths" property at all for importing files, I have only needed this for importing additional types that I don't directly import, eg in another package:

I think I found the issue, it turns out that when the depended upon package is not built (at least once) then the file shows up as missing!


Update MDM and MDSD image tags to master_20210905.1

Which issue this PR addresses:
Updates the latest MDM and MDSD image tags
Test plan for issue:
N/A
Is there any documentation that needs to be updated for this PR?
N/A

Just saw that !1733 addresses this change.  Closing this PR


Question Dashboard Implementation

Fixed Issues
Implemented Infinite scrolling and search for questions on question dashboard
Files Changed
question-dashboard.component.ts: modified functions getAllQuestions,categoeryWiseFilter, difficultyWiseSearch and added getQuestionsOnScrolling .
question-dashboard.html :modified infinite scrolling added.
QuestionRepository.cs: GetAllQuestionsAsync Modified, GetNumberOfQuestionsAsync added
QuestionController: GetAllQuestionsAsync Modified
IQuestionRepository: GetNumberOfQuestionsAsync added.
QuestionRepositoryTest.cs: GetAllQuestionsAsyncTest() commented.
Systemjs.config.js: library angular2-infinite-scrolling added
Checks

[X] Naming Conventions
[X] Server side code comments (proper English, grammar and no spelling mistakes)
[X] Client side code comments (proper English, grammar and no spelling mistakes)
[X] Unused variables, methods, blank spaces and name spaces.
[X] Optimal Code and code formatting
[X] Commit History is proper, no merge is done.
[X] Commit/pull request messages should be proper to justify your feature
[ ] All test cases are executed provided by tester.

Known Issues
Comments
NA

This change is

SonarQube analysis reported 2 issues

 2 major

Watch the comments in this conversation to review them.

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 systemjs.config.js#L5: Remove the unused function parameter "global".

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 systemjs.config.js#L5: Remove the unused function parameter "global".

SonarQube analysis reported 1 issue

 1 minor

Watch the comments in this conversation to review them.

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 systemjs.config.js#L5: Remove the unused function parameter "global".

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 systemjs.config.js#L5: Remove the unused function parameter "global".

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 systemjs.config.js#L5: Remove the unused function parameter "global".

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 systemjs.config.js#L5: Remove the unused function parameter "global".


Eliah Kagan: Watch draifuwalifecenter.wordpress.com

Eliah Kagan requests the watch of the watch_keyword draifuwalifecenter\.wordpress\.com. See the MS search here and the Stack Exchange search here.

draifuwalifecenter\.wordpress\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Shree in Charcoal HQ


Could you share online mobilenetv2 pretrained model?

I want to reproduce by ncnn

Hi, please check here: https://github.com/mit-han-lab/temporal-shift-module/blob/master/online_demo/main.py#L78.


Roll engine 5f5713e33971..af04338413c3 (8 commits)

git@github.com:flutter/engine.git/compare/5f5713e33971...af04338413c3
git log 5f5713e33971..af04338413c3 --no-merges --oneline
2019-11-08<EMAIL_ADDRESS>Manual roll of Dart e68ca9b652acdb642668a6acb5f630d5be6c03da...fa4379946109467c8a48f20f19d83d7c72968a3e (flutter/engine#13756)
2019-11-08<EMAIL_ADDRESS>Revert "Reland "Guarding EAGLContext used by Flutter #13314" (#13755)" (flutter/engine#13757)
2019-11-08<EMAIL_ADDRESS>[web] Support gif/webp animations, Speed up image drawing in BitmapCanvas.  (flutter/engine#13748)
2019-11-08<EMAIL_ADDRESS>Reland "Guarding EAGLContext used by Flutter #13314" (flutter/engine#13755)
2019-11-08<EMAIL_ADDRESS>Move TextRange from the framework to dart:ui. (flutter/engine#13747)
2019-11-08<EMAIL_ADDRESS>Roll src/third_party/skia 8c1e265f6f81..c88d1774ed50 (7 commits) (flutter/engine#13754)
2019-11-08<EMAIL_ADDRESS>Revert "Always use IOSGLContextSwitch to access EAGLContexts to prevent plugins from polluting Flutter's EAGLContext (#13314)" (flutter/engine#13753)
2019-11-08<EMAIL_ADDRESS>Always use IOSGLContextSwitch to access EAGLContexts to prevent plugins from polluting Flutter's EAGLContext (flutter/engine#13314)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

Auto-roller completed checks. About to merge.


Fix issue 3611

Motivation
Prevents lodestar from crashing when there are files that cannot be parsed as a keystore on startup.
Description
Have the parsing oppression in a try, so errors can be caught without terminating process.
Closes #3611
Steps to test or reproduce

Put other files, specifically the deposit_data.json files in the /keystores folder.
Run the validator client
Receive object expected error.

@dadepo Please name PRs with meaningful titles. Just puting the issue number doesn't give context. Specifically:

Short and descriptive summary
Should be capitalized and written in imperative present tense
Not end with period

Example: "Add Edit on Github button to all the pages"


CSET Documentation (Visualising a recipe graphically): missing -r in both command examples

Describe the bug
In the CSET Documentation under 'Getting started' --> Visualising a recipe graphically there are two commands that are missing -r causing an error.
How to reproduce
Include -r in both commands:
cset graph -r recipes/mean-air-temp-spatial-plot.yaml
cset graph --details -r recipes/mean-air-temp-spatial-plot.yaml
Expected behaviour
The recipe will be found which will allow graphs on whats going on in the recipe to be produced.

https://metoffice.github.io/CSET/getting-started/visualise-recipe.html


find() should return 'Not found' for out of scope items

Currently find(arrayWithOutOfScopeItem) ignores out-of-scope items when returning the array of items.  Instead, find(...) should return an 'Item not found' error in place of the out of scope items.
Closes #116.

@gr2m -- I noticed that there was one line that wasn't covered under any tests, but since the use case didn't pertain directly to this change, I was going to save it for another PR.  Do you agree, or would you like me to add the test to this PR?

I noticed that there was one line in find.js that wasn't covered under any tests, but since the use case didn't pertain directly to this change, I was going to save it for another PR. Do you agree, or would you like me to add the test to this PR?

As you prefer, both is fine with me :) Thanks for your great help Rob, it motivates me a lot to push things forward myself

I've made the requested changes to the error object.

As you prefer, both is fine with me :)

I'm somewhat obsessive about keeping separate concerns on separate issues, so I'll create a separate PR.

Thanks for your great help Rob, it motivates me a lot to push things forward myself

You're most welcome!  Me motivating you is motivating me (and now my eyes have crossed!).

@gr2m -- I just checked out master and ran a coverage test and it looks like this commit somehow IS the culprit of several lines no longer being covered.  On second thought, I'll add the tests to this PR to make sure that we're still at 100% on all files.

okay, thanks!

@gr2m back to 100% coverage.  Please see above comment re: Array.every.  Also, note:

to keep with the DRY principle, since I reused the isNotFoundError function from update-or-add.js, I moved the code into a module in the utils directory
I had to change the test for typedObjects.length === 0, since we're now passing through 'Not Found' errors.

@gr2m - Thank you for the feedback.  Changes incorporated.  It looks like consistently returning an array when an array is passed into find also makes the code a little cleaner.  There were some catch clauses within the *OrAdd functions that are no longer reached, so I removed those lines from update-or-add.js and find-or-add.js.
And it looks like we no longer need the isNotFoundError function within find.js anymore, so I moved it back into update-or-add.js.

fantastic work Rob, the PR looks great now!
LGTM
ping @hoodiehq/maintainers 👀

LGTM


Prevent the player for moving and pass through colliders

Overview
Hello, I have a problem. I would like to prevent the player for moving in certain moments, but I dont know how to do this or if there is a way to do that.
Another problem is that you can go though colliders because you move with teleport, so if you aim to a wall you wont move but if you aim to the wall bottom you will pass though
Expected Behavior
Prevent the player for moving and prevent him to pass though walls
Actual Behavior
Cant do this / Dont know how to do this
Steps to reproduce
No steps.
For walking though a wall just aim to thw wall floor and you will pass though.
Unity Editor Version
2019
Mixed Reality Toolkit Release Version
v2.0 RC1 Refresh

Super late response, but I think this would require updating the teleportation system yourself to factor in other surfaces when considering places to teleport. @davidkline-ms, is there any way to create surfaces that are teleportation-not-allowed? I'm curious if this could be marked this way, or if this is just something that could be done by also looking at teleport requests and seeing if they are too close to some other user-specified surface type.

Has this really  not been fixed in two years?

We're using the built-in XRI locomotion system in MRTK3, which has support for all of this and more :)
<EMAIL_ADDRESS>


[Bug] Space in Common Class Project triggers some issue while MAUI Class Library is refer on it

Description
Issue Description:
I encountered an issue in .NET MAUI related to project references when creating a new class library with spaces in its name. The issue seems to cause a build failure with the CS0006 error, indicating that the metadata file could not be found.
Steps to Reproduce:

Create a new class library project in Visual Studio.
Include spaces in the project name during creation.
Reference this class library project from a .NET MAUI project.
Attempt to build the solution.

Expected Behavior:
The .NET MAUI project should be able to reference and build successfully, even if the class library project has spaces in its name.
Actual Behavior:
The build fails with a CS0006 error, stating that the metadata file could not be found.
Environment:

.NET MAUI version: [8.0.x]
Visual Studio version: [Visual Studio 2022]

Class Library with space will trigger some errors.

Class Library without space.
Most of the content in this Report was generated by AI
Steps to Reproduce
No response
Link to public reproduction project repository
No response
Version with bug
8.0.3
Is this a regression from previous behavior?
Not sure, did not test other versions
Last version that worked well
Unknown/Other
Affected platforms
I was not able test on other platforms
Affected platform versions
No response
Did you find any workaround?
No response
Relevant log output
No response

Is it only failing when referenced from a MAUI Class Library? Given it's a CS error, I'd probably start with dotnet/roslyn. CC @jaredpar who has opinions.


support deletion of project updates

What does this PR do and why?
Provide a description of what this PR does. Link to any relevant GitHub issues, Notion tasks or Discord discussions.
Screenshots or screen recordings
If applicable, provide screenshots or screen recordings to demonstrate the changes.
Acceptance checklist

[ ] I have evaluated the Approval Guidelines for this PR.
[ ] (if relevant) I have tested this PR in all supported browsers.
[ ] (if relevant) I have tested this PR in dark mode and light mode (if applicable).

Current dependencies on/for this PR:

main

PR #3883

PR #3884

PR #3885

PR #3886

PR #3887

PR #3888   👈

This comment was auto-generated by Graphite.

@wraeth-eth started a stack merge that includes this pull request via Graphite.

Graphite rebased this pull request as part of a merge.


⚠ ClamAV has degraded performance

In f466bb1, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 54 ms

Resolved: ClamAV performance has improved in f747330.


feature: KubeStellar creates a paradigm shift for our users - the need to keep track of context since multicluster is the normal mode of operation

Feature Description
I am always fearful that I will issue a command to the wrong cluster when I am using KubeStellar.  I try to keep track of this with kubeconfig files, not context.  The combination of openshift login (token that expires every 24 hours) and space framework for WECs... When you have to do this for 1000's of clusters, this presents a real issue.
remembering where you are in the kubestellar universe is difficult. I think now that we are moving into a universe where multi cluster is normal, we might need to make this easier for our user.  In the past, kube did not need this because it was 1:1 for normal ops.  For us, 1:many is now the norm.
what would a terminal session be without a prompt that shows you your context?
Proposed Solution
2 suggestions, and I am sure there are more

could we introduce a "kubestellar tip" that shows someone how to add the "kube context" on the command line prompt?

something like
/users/me/projects> (kubeconfig=admin.kubeconfig)

maybe our kubectl commands report context as you run them.

... lets get creative and look around for and/or think of other possible options
Want to contribute?

[ ] I would like to work on this issue.

Additional Context
@KPRoche @francostellari do either of you have some ideas from all your lab work?  Maybe it's like keeping tack of ssh connections in a ssh/config file?  There must be something out there (a methodology, suggestion, app) that can do the job of keeping track of this type of 1:1 connections to keep people from making changes on the wrong system.

One option would be for kubestellar to check for a kubeconfig (or even a simple text file) in the directory from which you issued the terminal command in the absence of command flags specifically setting kubeconfig, namespace, or context.
If present, use the local file, if not, default to the current environment settings. AND say in the response to the command which kubeconfig, ns, and context you are using.
Then you would simply need a folder corresponding to each location. That's still a lot, but you could organize it with directory structures.
OR added functionality where you can set a nickname for a target (location/workload) and invoke that, and kubestellar can find the matching kubeconfig, namespace and context.

could we somehow pull a small bit of info from the file currently pointed at by the KUBECONFIG env var and then add that to the command line in the shell?

The fundamental problem here is from the Kubernetes world, KubeStellar did not introduce it.  Already in the Kubernetes world people deal with multiple clusters, multiple kubeconfig files, and multiple "contexts" within a kubeconfig file. kcp adds something: the concepts of current workspace and previous workspace.
The Kubernetes world gives users choices about how to organize their kube client configs into kubeconfig files and contexts within those kubeconfig files. I have not seen any demonstrations of this in the course of working on this project, but that is a variable. kubeconfig file contents can be merged, can be split.
I have seen people express different preferences from @clubanderson . It is not clear to me that there is one right way to exercise the user's freedom here.
Helping users make the relevant bits of state visible is definitely good. That is primarily two things: which kubeconfig file will be used, and which context within that kubeconfig file. kcp adds one more thing of high interest: which workspace is current.

I would not favor changing the way that kubectl selects the client config to use. Adding output to stdout sounds bad to me, since scripting is a thing. Adding output to stderr is not inconceivable. But since context (broadly construed) visualization in shells is a thing, I like that approach the best. Also, @eaepstein suggested a style of usage in which (if I recall correctly) the kubeconfig file is explicitly specified in each command.

found an answer to my kube context woes... I use oh-my-zsh (https://ohmyz.sh/) with powerline9k/10k (https://github.com/Powerlevel9k/powerlevel9k
I simply put:
POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(kubecontext)
at the end of my ~/.zshrc file
and now I have the current context and namespace from the kubefonfig currently pointed to by the KUBECONFIG env var.
@KPRoche give this a shot please.

looking at it... you're aware powerlevel9k has big "obsolete" warnings all over its page recommending powerline10k instead?

@KPRoche would you be so kind as to research how to use 10k, instead of 9k, with oh-my-zsh to show the context as I was able to do?

kubectl offers two ways to explicitly specify a cluster target:

using --context flag when more than one context is contained in the default/specified kubeconfig file path, or
setting/overriding the KUBECONFIG envar.

However, --context is currently broken for some of kubestellar's kubectl plugins because they call the kubectl-kcp executable which reserves the use of --context for the KCP space.
It is easy to specify to kind where to put the kubeconfig when starting a cluster:
kind create cluster --name kshost --kubeconfig=kshost.kubeconfig
Given that each kubectl target has its own kubeconfig file, the KUBECONFIG envar works nicely with an alias. For example:
alias kc-guilder="KUBECONFIG=$PWD/guilder.kubeconfig kubectl"
And if multiple contexts already exist in a kubeconfig, they can be extracted easily:
kubectl config view --minify --flatten  --context kind-guilder > guilder.kubeconfig

good point @eaepstein.  The reason I brought up this issue is because maybe we can create something that is better than the 'export' or 'context' solution.  I am using a terminal enhancement to help me keep track of where I am.  Maybe that guidance is enough, maybe there are other solutions out there addressing this, maybe we could use or enhance or create something to help our users
@KPRoche please advise on how best to add 10k (instead of 9k) to get the desired affect.

@clubanderson There are a few drawbacks to replying on the command line prompt for context.
With a stateful command line, it takes an extra command when switching contexts:

change context
use common "kubectl" command to modify state

Another issue is when reviewing a history of commands issued. There is no command line prompt when reading history, one must look back to previous commands to figure out what context "kubectl" was modifying.
Following directions in the example documentation was also a problem for me, as the last change context command was somewhere above, often on a previous page.
Using different aliases for kubectl is self documenting and can be more efficient at times.

@clubanderson I forgot to comment on the problem of maintaining many individual kubeconfig files.  OCM has a nice feature that supports forwarding API requests to managed clusters:
https://open-cluster-management.io/scenarios/pushing-kube-api-requests/


system_debug_ios test is flaky

The post test assertion failure seems to only fire some of the time. Looks like its only passed on mac-14 in recent history.
2019-10-17T15:59:29.549550: stdout: [  +17 ms] 00:00 +1: All tests passed!
2019-10-17T15:59:29.578301: stdout: [  +28 ms] Stopping application instance.
2019-10-17T15:59:29.578400: stdout: [        ] Stopping application.
2019-10-17T15:59:29.579704: stdout: [   +1 ms] "flutter drive" took 26,091ms.
2019-10-17T15:59:29.596408: "/Users/flutter/.cocoon/flutter/dev/devicelab/../../bin/flutter" exit code: 0
2019-10-17T15:59:29.604828: Task failed: failed assertion in service extensions test2019-10-17T15:59:29.605084:

Stack trace:
2019-10-17T15:59:29.625838: bin/tasks/service_extensions_test.dart 119:5               expect
bin/tasks/system_debug_ios.dart 91:3                       checkWarningHomeScreenLaunch

Which is https://github.com/flutter/flutter/blob/a36f809e27e3dcf19b26aa40292cb02fe51df483/dev/devicelab/bin/tasks/system_debug_ios.dart#L80

The test is currently disabled because according to the comment it doesn't pass on iOS:
https://github.com/flutter/flutter/blob/c1112d3f7ea8452ea0069407de588987894def09/dev/devicelab/manifest.yaml#L567
Closing this flake for now.


SagePay Strong Customer Authentication and 3D Secure v2

Sage pay now has a requirement to do all ecommerce transactions to be processed via secured industry protocol such as 3D Secure. They will not allow transactions which does not have Strong Customer Authentication. More details.
Is this issues being addressed already? or will there be any updated regarding this?

Please close this issue if you think this previous issue covers the changes: https://github.com/thephpleague/omnipay-sagepay/issues/135

It is. Many thanks.

Ta. We are at the stage of going through the docs to see what needs to be done. So eyes are on it, but no progress with implementation so far as I am aware.


Deploy VM shutdown when idle?

Review that the auto-shutdown of idle VMs is working.
Assess the impact on the user

The impact assessment means:

When a machine is shut down through being idle, how does the UI represent that?
Can the user restart the VM from the UI?

If the user can work with this without problems, that's great. If not, more tickets will be needed to allocate the work to fix it, and priorities decided, depending on the level of inconvenience.

The UI fetches the status of the VM from Azure and not from COSMOS. So the power status of the machine correctly reflects on the UI.
Yes, a user can control the VM from the UI.

Apply a logic that fetches the tag of the machine to be shut down. If the tag says "Don't shut me down" then do not shut it down... This is a feature extension of the existing solution.


s

Expected behavior
Actual behavior
Information about the Issue
Steps to reproduce the behavior

...
...

No information provided - Closing


Refactoring

refactoring
use a real database for couchdb integration tests (not only a mock like before)
fixes a bug that sometimes led to missing wc_ids in newly created items
improve styling

prevent cut off table rows / images
style all buttons
change some colors
loading animations

wow! nice work!
I'm not sure how far I'll get with reviewing everything (as it's 172 files changed), are there any critical passages that I should focus on?

wow! nice work!
I'm not sure how far I'll get with reviewing everything (as it's 172 files changed), are there any critical passages that I should focus on?

Not specifically, but you could run it locally and see if you like the styling or find any bugs.


Process for creating apollo fullstack example

I am looking at your https://github.com/prisma/nexus/tree/develop/examples/apollo-fullstack example.
I cant figure out what commands you used to generate the project. Can you shed any light on that?
Thank you.

npm start should start the server and generate the types/graphql assets. Otherwise the rest of the code was adapted from https://github.com/apollographql/fullstack-tutorial


Validating HMACs with incremental computation

As far as I can tell, it's currently not possible to create a MAC from data with swift-crypto. The only way to validate an existing MAC that wasn't computed by swift-crypto in the current process (e.g. a MAC that was sent as part of an HTTP request, or a MAC that was saved to disk between process launches) with the HMAC API is to use isValidAuthenticationCode, which requires that the data you're validating fits in contiguous memory.
Motivation:
Most of the HMAC API is oriented around allowing computing HMACs from incremental data. Not being able to validate a MAC with this mode of operation directly seems like an oversight in the API. I can compare the MAC bytes manually, but swift-crypto doesn't expose its safeCompare function so it wouldn't be constant time any more.
Importance:
Low

I knew there had to be something I was missing MessageAuthenticationCode has an equatable conformance which allows comparing a code to a type conforming to DataProtocol which allows comparing a computed code to one computed in another process


Training Failing

I have created the project template as per Julien Simon and replace the project files with this repository. When executing the pipeline the training fails at the TrainEvaluateRegister stage. Looking up on CloudWatch logs I notice this error pop up.
boto3.exceptions.S3UploadFailedError: Failed to upload /home/model-server/tmp/tmps6xncsc5/model/model.pkl to mlflow-artifacts-982563744386/1/c2eefcdff57d4b2bb0014f934fe7204d/artifacts/model/model.pkl: An error occurred (AccessDenied) when calling the PutObject operation: Access Denied
I have attached the Amazon S3 Full Access policy to my Sagemaker Studio role.

I have also checked the execution role inside of Sagemaker studio using Console Python3 terminal with the following commands.
import sagemaker
sagemaker.get_execution_role()
It gives the same execution role as the one with the above policies.

I have edited the policy document to include the s3 bucket by name in the put operation allowed actions.


Seqvar ACMG display is "blipping"

Describe the bug
The ACMG display for seqvars is not displaying correctly but jumping back and forth between being displayed and not being displayed.
To Reproduce
Steps to reproduce the behavior:

Go to https://reev.cubi.bihealth.org/seqvar/grch37-6-165827027-A-C
Scroll down to ACMG seqvar component
See it the card appear and disappear.

Expected behavior
It should be displayed.
Screenshots
N/A
Additional context
N/A

Caused by a logic error when loading ACMG rating from server and improper condition in watch().


Add Vec::drain and String::drain.

Closes https://github.com/rust-embedded/heapless/issues/334 and https://github.com/rust-embedded/heapless/pull/365.

could you add tests?

I can't quite figure out the miri error. Note that the implementation is almost 1:1 copied from std, so I'm not sure if it's a false positive.

rebased it for you on top of the new VecView impl.

@Dirbaio, thanks!


yep-312 - has-reference-position

@ddkohler can you write up a summary of the offline conversation about this yep so that it is something we can reference here later?

Offline conversation:

Discussed the idea of a reference frame, where the relationship between client coordinates to native motor positions might be an offset, a scalar factor, or a complex functional form that needs many parameters. Rather than just an offset and invert option, the trait should allow arbitrary coordinate changes (provided they are 1:1).  The parameters will be left up to the daemon, with the exception of the reference_position/offset parameter, which should be a fairly universal parameter.
This allows different units between reference frame and native motor coordinates (also: get_native_units() and get units() can be different)
add more methods, specifically to set/get native positions, units, (get) native limits
set_reference and set_reference_native
properties:

offset
native offset
native position
native destination


Php7.2 is not supported

I am using php 7.2.26, but this only support php8.1

Unfortunately the package are utilizing features that are only available in PHP 8.1.
Therefore, PHP 8.1 is the min. required version.


No route for omniauth failure

Environment

Ruby 2.3.6p384
Rails 5.2.0
Devise 4.4.3

Current behavior
The failure callback /users/auth/failure can't find a route. I'm getting No route matches [GET] "/users/auth/failure"
Expected behavior
Devise already defines routes for the callbacks /users/auth/<proveder>/callback. Why not for /users/auth/failure?

Sorry, it is my fault. I still had this in my config/initializers/omniauth.rb
# see here: https://github.com/intridea/omniauth/wiki/FAQ
OmniAuth.config.on_failure = Proc.new { |env|
  OmniAuth::FailureEndpoint.new(env).redirect_to_failure
}


Problems starting a mezzanine project with Drum installed

Hi, I'm having some problems launching a drum project
When I use this command
mezzanine-project -a drum project_name
I get this error, regardless of the project_name used:
CommandError: 'project_name' conflicts with the name of an existing Python module and cannot be used as a project name. Please try another name.
Any thoughts?
Thanks

Could you post this to the Mezzanine mailing list instead? Thanks.

I have the same problem. Is there a fix?

Hi!  The same problem.


Seed.js not working properly

The Invoice service relies on "context.currentUser?.id" to create an Invoice, which doesn't work running "yarn rw db seed"
Seems tricky to establish user context within the seed.js file, so I was trying to seed a user first and providing that but couldn't get it to work.
Still learning the ins and outs of Prisma and Redwood and don't totally understand the input types it asks for while creating the Invoice while providing a User but it seems possible

Hi @matthalvorson33! I'm not sure if the Seed step is even needed anymore. See https://github.com/redwoodjs/example-invoice/issues/35
@peterp is the original author here. Peter, could you help clarify? Also see relate PR https://github.com/redwoodjs/example-invoice/pull/50

Thanks for pointing me there, I hadn't seen that yet. Appreciate the help :)


Doesn't work anymore

Modern browsers aren't supportin legacy crooks anymore, please update all these outdated libraries.

This tool still works in current Chrome/Firefox.