Directions on "Create Stage" Page results in a CodeBuild error "no such file in directory"

:bug: Bug Report
What is the problem?
I'm on the Create Stage tutorial and I'm unable to successfully run my pipeline due to an error in the Build stage.

I see the build dir set to CODEBUILD_SRC_DIR=/codebuild/output/src213311547/src then  it attempts to access /codebuild/output/src213311547/src/lambda and that directory is not there.  I can't seem to find what code is looking at that directory.
[Container] 2020/12/24 16:34:58 Running command npx cdk synth
npx: installed 193 in 5.783s
ENOENT: no such file or directory, stat '/codebuild/output/src213311547/src/lambda'
Subprocess exited with error 1
[Container] 2020/12/24 16:35:09 Command did not exit successfully npx cdk synth exit status 1
[Container] 2020/12/24 16:35:09 Phase complete: BUILD State: FAILED
[Container] 2020/12/24 16:35:09 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: npx cdk synth. Reason: exit status 1

pipeline-stack.ts
import * as cdk from '@aws-cdk/core';
import * as codecommit from '@aws-cdk/aws-codecommit';
import * as codepipeline from '@aws-cdk/aws-codepipeline';
import * as codepipeline_actions from '@aws-cdk/aws-codepipeline-actions';
import { SimpleSynthAction, CdkPipeline } from '@aws-cdk/pipelines';
import { WorkshopPipelineStage } from './pipeline-stage';

export class WorkshopPipelineStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps)  {
    super(scope, id, props);

    const repo = new codecommit.Repository(this, 'WorkshopRepo', {
      repositoryName: 'WorkshopRepo'
    });

    // Defines the artifact representing the source code
    const sourceArtifact = new codepipeline.Artifact();
    // Defines the artifact representing the cloud assembly
    // cloudformation template + all other assets
    const cloudAssemblyArtifact = new codepipeline.Artifact();

    // The basic pipeline declaration
    const pipeline = new CdkPipeline(this, 'Pipeline', {
      pipelineName: 'WorkshopPipeline',
      cloudAssemblyArtifact,
      // Generates the source artifact from the repo we created in the last step
      sourceAction: new codepipeline_actions.CodeCommitSourceAction({
        actionName: 'CodeCommit',
        output: sourceArtifact,
        repository: repo
      }),
      // Builds our source code outlined above into a could assembly artifact
      synthAction: SimpleSynthAction.standardNpmSynth({
        sourceArtifact,
        cloudAssemblyArtifact,
        buildCommand: 'npm run build'
      })
    });

    const deploy = new WorkshopPipelineStage(this, 'Deploy');
    pipeline.addApplicationStage(deploy);
  }
}

Reproduction Steps

Verbose Log

Environment

CDK CLI Version: 1.78 and 1.80.0 (build 31132ca)
Section: https://cdkworkshop.com/20-typescript/70-advanced-topics/200-pipelines/4000-build-stage.html
Browser: n/a
Language: TypeScript

Other information

hey! it looks like you may be ignoring your lambda js files.
try adding this to your gitignore and making sure the js files make it to your repo:
!lambda/*.js

hey! it looks like you may be ignoring your lambda js files.
try adding this to your gitignore and making sure the js files make it to your repo:
!lambda/*.js

@jonathanlemonsonos very kind of you!  This was the issue.
I believe the CDK Pipeline section needs to note this.  I'm going to investigate this a little more and possibly make a PR for a doc fix.

@jonathanlemonsonos very kind of you!  This was the issue.
I believe the CDK Pipeline section needs to note this.  I'm going to investigate this a little more and possibly make a PR for a doc fix.


None Attribute Error processing LicenseListXML Issues

While deploying the production environment, a None attribute error (e.g. null pointer) occurred in the get_license_data function of utils.py.  This was due to a search not yielding a result in the following line:
licenseIdentifier = re.search(r'(?im)short identifier:\s([a-zA-Z0-9|.|-]+)', licenseInfo).group(1)
This may be resolved with PR #258 where the exception is basically ignored.  This assumes, however, that the error is due to an improperly formatted issue.
This assumption should be verified to make sure there isn't a different cause (e.g. the incorrect pattern to search).

From the flow, it looks like it checks the license list repo for all the closed issue and searches for  short identifier: <id> in the issue body. One fix would be to allow any no of spaces between : and <id>.
\s+([a-zA-Z0-9|.|-]+)
For all issues raised by the online tools, we have only 1 space in between. (utils.py line 340)

This has been resolved in PR #258 and deployed to production.


gpioa.pa9.into_alternate_push_pull(&mut gpioa.crh);

(newbie so I may be asking something stupid, but I would appreciate understand this.)
I am trying to understand why some arguments are needed, and why they need to be mutable. In stm32f4xx-hal I can do
let pin_rx1 = gpioa.pa9.into_alternate_af7();
but to accomplish a similar thing in stm32f1xx-hal I need
 let pin_rx1 = gpioa.pa9.into_alternate_push_pull(&mut gpioa.crh);
The compiler seems to know what argument I need, if I make a mistake it tells me what the single choice must be, so it is easy to fix. But if there is only one possible argument then why is it needed? (I do realize that the argument might have different values sometimes, I guess I am really asking why it cannot be part of the  gpioa.pa9 structure?)  And the fact that this argument needs to be mutable cascades back.  It means with stm32f4xx-hal I get a warning if I don't declare
let rcc = p.RCC.constrain();
whereas with stm32f1xx-hal I need
let mut rcc = p.RCC.constrain();
I have the same question about
let clocks = rcc.cfgr.freeze(&mut p.FLASH.constrain().acr);
for stm32f1xx-hal while for stm32f4xx-hal I do
let clocks = rcc.cfgr.freeze();
The result of these hal differences is that my code has a lot more cfg() statements then I think I should need. A complete working example is below. (With stm32f3xx it builds but prints gjibberish on my hardware. With stm32l1xx it does not build.)  I'm using git versions of the hals.
//! Echo console input back to console + semihost output, char by char
//!
//! Connect the Tx pin pa9  to the Rx pin of usb-ttl converter
//! Connect the Rx pin pa10 to the Tx pin of usb-ttl converter
//! Set up the serial console (e.g. minicom) with the same settings used here.
//! (Using 9600bps, could be higher but needs serial console to be the same.)

#![deny(unsafe_code)]
#![no_main]
#![no_std]

#[cfg(debug_assertions)]
extern crate panic_semihosting;

#[cfg(not(debug_assertions))]
extern crate panic_halt;

use cortex_m_rt::entry;
//use core::fmt::Write;  // for writeln
use cortex_m_semihosting::hprintln;
use core::str::from_utf8;
use nb::block;

#[cfg(feature = "stm32f1xx")]  //  eg blue pill stm32f103
use stm32f1xx_hal::{prelude::*,   pac::Peripherals, serial::{Config, Serial }, };   //StopBits}

#[cfg(feature = "stm32f3xx")]  //  eg Discovery-stm32f303
use stm32f3xx_hal::{prelude::*, stm32::Peripherals, serial::{ Serial}, };

#[cfg(feature = "stm32f4xx")] // eg Nucleo-64  stm32f411
use stm32f4xx_hal::{prelude::*,  pac::Peripherals, serial::{config::Config, Serial }};

#[cfg(feature = "stm32l1xx") ] // eg  Discovery kit stm32l100 and Heltec lora_node STM32L151CCU6
use stm32l1xx_hal::{prelude::*, stm32::Peripherals, serial::{Config, Serial }};

#[entry]
fn main() -> ! {
    let p = Peripherals::take().unwrap();

    #[cfg(feature = "stm32f1xx")]
    let mut rcc = p.RCC.constrain();
    #[cfg(feature = "stm32f3xx")]
    let mut rcc = p.RCC.constrain();
    #[cfg(feature = "stm32f4xx")]
    let rcc = p.RCC.constrain();
    #[cfg(feature = "stm32l1xx")]
    let rcc = p.RCC.constrain();

    #[cfg(feature = "stm32f1xx")]
    let clocks = rcc.cfgr.freeze(&mut p.FLASH.constrain().acr); //why can I do &mut p...  when p is not mutable?
    #[cfg(feature = "stm32f3xx")]
    let clocks = rcc.cfgr.freeze(&mut p.FLASH.constrain().acr);
    #[cfg(feature = "stm32f4xx")]
    let clocks = rcc.cfgr.freeze();
    #[cfg(feature = "stm32l1xx")]
    let clocks = rcc.cfgr.freeze();

    #[cfg(feature = "stm32f1xx")]
    let mut gpioa = p.GPIOA.split(&mut rcc.apb2);   // why an argument and why mutable?
    #[cfg(feature = "stm32f3xx")]
    let mut gpioa = p.GPIOA.split(&mut rcc.ahb);
    #[cfg(feature = "stm32f4xx")]
    let gpioa = p.GPIOA.split();
    #[cfg(feature = "stm32l1xx")]
    let gpioa = p.GPIOA.split();

    #[cfg(feature = "stm32f1xx")]
    let pin_rx1 = gpioa.pa9.into_alternate_push_pull(&mut gpioa.crh);     //pa9
    #[cfg(feature = "stm32f3xx")]
    let pin_rx1 = gpioa.pa9.into_af7(&mut gpioa.moder, &mut gpioa.afrh);  //pa9
    #[cfg(feature = "stm32f4xx")]
    let pin_rx1 = gpioa.pa9.into_alternate_af7();                         //pa9
    #[cfg(feature = "stm32l1xx")]
    let pin_rx1 = gpioa.pa9.into_alternate_af7();                         //pa9

    #[cfg(feature = "stm32f1xx")]
    let pin_tx1 = gpioa.pa10;                                             //pa10
    #[cfg(feature = "stm32f3xx")]
    let pin_tx1 = gpioa.pa10.into_af7(&mut gpioa.moder, &mut gpioa.afrh); //pa10
    #[cfg(feature = "stm32f4xx")]
    let pin_tx1 = gpioa.pa10.into_alternate_af7();                        //pa10
    #[cfg(feature = "stm32l1xx")]
    let pin_tx1 = gpioa.pa10.into_alternate_af7();                        //pa10

    #[cfg(feature = "stm32f1xx")]
    let cnfg = Config::default() .baudrate(9600.bps());  //.stopbits(StopBits::STOP1),
    #[cfg(feature = "stm32f3xx")]
    let cnfg = 9600.bps();
    #[cfg(feature = "stm32f4xx")]
    let cnfg = Config::default() .baudrate(9600.bps());
    #[cfg(feature = "stm32l1xx")]
    let cnfg = Config::default() .baudrate(9600.bps());

    #[cfg(feature = "stm32f4xx")]
    p.USART1.cr1.modify(|_,w| w.rxneie().set_bit());  //need RX interrupt?
    #[cfg(feature = "stm32l1xx")]
    p.USART1.cr1.modify(|_,w| w.rxneie().set_bit());  //need RX interrupt?

    let txrx1 = Serial::usart1(
        p.USART1,
        (pin_rx1, pin_tx1),
        #[cfg(feature = "stm32f1xx")]
        &mut p.AFIO.constrain(&mut rcc.apb2).mapr,
        cnfg,
        clocks,
        #[cfg(any(feature = "stm32f1xx", feature = "stm32f3xx"))]
        &mut rcc.apb2,
    );

    #[cfg(any(feature = "stm32f4xx", feature = "stm32l1xx"))]
    let txrx1 = txrx1.unwrap();

    // end hal specific conditional setup

    // Split the serial txrx1 struct into a receiving and a transmitting part
    let (mut tx1, mut rx1) =txrx1.split();

    hprintln!("testwrite to console ...").unwrap();

    for byte in b"\r\nconsole connect check.\r\n" { block!(tx1.write(*byte)).ok(); }

    hprintln!("test read and write by char. Please type into the console ...").unwrap();
    //writeln!(tx1, "\r\nPlease type (slowly) into the console below:\r\n").unwrap();
    for byte in b"\r\nType (slowly) below:\r\n" { block!(tx1.write(*byte)).ok(); }

    loop { // Read a byte and write
       let received = block!(rx1.read()).unwrap();
       block!(tx1.write(received)).ok();
       hprintln!("{}", from_utf8(&[received]).unwrap()).unwrap();
     }
}

This was discussed briefly in the embedded matrix chat yesterday. The reason, as I understand it is that the f4 HAL isn't as strict in terms of preventing race conditions as the f1 crate. See https://github.com/stm32-rs/stm32f4xx-hal/issues/171 for more details.
By requiring a &mut to the registers, we ensure that there are no race conditions when writing to the registers during setup. The f4 HAL does not have this check, if I understood correctly.
Regarding the clocks, my guess is that it is a hardware difference. The f1 requires something in the flash peripheral to freeze the clocks, while the f4 does not. It is also possible that that is the cause of the other differences as well, for example, there may be hardware locking present in the f4, but not the f1.
I think @therealprof who is familiar with both crates can give a less "guessy" answe
Also as I hinted in your previous issue, I'd probably consider trying to use the same code for two HALs a bit of an antipattern. The HALs should only really be used for setting up the peripherals, and after that, most of the heavy lifting should be done by the embedded-hal traits which should be implemented the same way for all HALs. So generally, you'd want to write most of your code genericallly using EH, and then pass some intialised periphrals to that code.

The original design of this API was created by japaric:
http://blog.japaric.io/brave-new-io/

Also as I hinted in your previous issue, I'd probably consider trying to use the same code for two HALs a bit of an antipattern. The HALs should only really be used for setting up the peripherals, and after that, most of the heavy lifting should be done by the embedded-hal traits which should be implemented the same way for all HALs. So generally, you'd want to write most of your code genericallly using EH, and then pass some intialised periphrals to that code.

I'm new and a bit slow, probably need more than hints. I'm not sure I understand this. I thought by using, for example,
use stm32f1xx_hal::{prelude::*,    serial::{Config, Serial }, };
I am getting stm32f1xx implementation of embedded-hal traits. So, my example is what I understood I have to do to pass the initialized peripherals to my code. Do you mean I should instead be doing something like
use embedded_hal::{prelude::*, serial::{Config, Serial }} ;
and working with that? Or do you mean something different by "most of the heavy lifting should be done by the embedded-hal traits"?

The original design of this API was created by japaric:
http://blog.japaric.io/brave-new-io/

I think that was the post that initially got me interested in Rust. Just re-reading after a few months, I understand a bit more, but will need to re-read again in a few more months. I think I've swallowed the abstraction but I'm still chewing on the details.

Also as I hinted in your previous issue, I'd probably consider trying to use the same code for two HALs a bit of an antipattern. The HALs should only really be used for setting up the peripherals, and after that, most of the heavy lifting should be done by the embedded-hal traits which should be implemented the same way for all HALs. So generally, you'd want to write most of your code genericallly using EH, and then pass some intialised periphrals to that code.

I'm new and a bit slow, probably need more than hints. I'm not sure I understand this. I thought by using, for example,
use stm32f1xx_hal::{prelude::*, serial::{Config, Serial }, };
I am getting stm32f1xx implementation of embedded-hal traits. So, my example is what I understood I have to do to pass the initialized peripherals to my code. Do you mean I should instead be doing something like
use embedded_hal::{prelude::*, serial::{Config, Serial }} ;
and working with that? Or do you mean something different by "most of the heavy lifting should be done by the embedded-hal traits"?

The HALs aren't expected to be completely interchangeable, because of hardware differences between families, etc. I think what they meant is that to be fully compatible, your API must depend only on the embedded-hal traits, it's somewhat expected that you might need to change the initialization code if you want to change chip families.
And about the f4xx-hal, both of the cases that you mentioned are unsound right now, we will probably fix them soon.

As thalesfragoso says, the init stuff in the HAL isn't supposed to be interchangeable, only the stuff behind the traits is. In your case, you may be able to do something like this:
use embedded_hal::serial;

fn main() {
    #[cfg(feature = "stm32f1xx")]
    let serial = setup_f1();
    #[cfg(feature = "stm32f4xx")]
    let serial = setup_f4();

    main_loop(serial);
}

#[cfg(feature = "stm32f1xx")]
fn setup_f1() -> stm32f1xx_hal::serial::Serial {
    // Do the setup you're already doing
}
#[cfg(feature = "stm32f4xx")]
fn setup_f4() -> stm32f4xx_hal::serial::Serial {
    // Do the setup you're already doing
}

// Main loop which uses the embedded_hal::serial::Write traits exclusively. This makes it
// independent of the HAL implementation
fn main_loop<S>(serial: S) where S: serial::Write {
    hprintln!("testwrite to console ...").unwrap();

    for byte in b"\r\nconsole connect check.\r\n" { block!(serial.write(*byte)).ok(); }

    hprintln!("test read and write by char. Please type into the console ...").unwrap();
    //writeln!(tx1, "\r\nPlease type (slowly) into the console below:\r\n").unwrap();
    for byte in b"\r\nType (slowly) below:\r\n" { block!(serial.write(*byte)).ok(); }

    loop { // Read a byte and write
       let received = block!(serial.read()).unwrap();
       block!(serial.write(received)).ok();
       hprintln!("{}", from_utf8(&[received]).unwrap()).unwrap();
     }
}

Though the two parallel setup functions would get unwieldy as the amount of things to initialise and return grows

Thanks everyone for comments and explanations, and your patients. In TheZorq2's sketch I certainly see the logic of including hardware specific details in the setup functions and out of the scope of the main program. But I'm still struggling a bit with "behind the traits". Looking at the sketch, if I understand correctly, the serial object presents the traits interface. It deals with everything hardware specific and presents just the traits to my application code. But I understood that stm32f1xx_hal provides an implementation of embedded_hal::serial that is specific to the stm32f1xx hardware, so I don't see what
use embedded_hal::serial;
does, or why it is needed in addition too, or instead of, using serial from stm32f1xx_hal.
I also see the sketch uses serial.write and serial.read rather than splitting serial into rx and tx as is done in many examples. Is there a reason that would be preferable to splitting?
I have tried filling the details into the sketch. My setup function has signature
fn serial1_setup() -> stm32f1xx_hal::serial::Serial {
and returns the structure from
stm32f1xx_hal::serial::Serial::usart1(
    p.USART1,
    (pin_rx1, pin_tx1),
    &mut p.AFIO.constrain(&mut rcc.apb2).mapr,
    cnfg,
    clocks,
    &mut rcc.apb2,
    )

but compiling gives
fn serial1_setup() -> stm32f1xx_hal::serial::Serial {
		      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 2 type arguments

and I'm stuck. (I see stm32f1xx_hal::serial::Serial::usart1 returns self, which seems to be a more complicated structure than just stm32f1xx_hal::serial::Serial.) I've tried several things without luck.
Finally, in the example in my original post I had
let p = Peripherals::take().unwrap();
...
let clocks = rcc.cfgr.freeze(&mut p.FLASH.constrain().acr);

which works but I don't understand why I can use &mut p...  when p has not been declared mutable. The compiler will not let me do that in other cases.
I very much appreciate everyone's comments as I'm trying to put together some examples that not only work but also present reasonably good style, a bit of a challenge for a newbie.

The sense of embedded-hal traits is to have hardware independent interface for external libraries like drivers for peripheral devices, connection to PC, etc. You can write driver using only these traits and be sure it will be work with any microcontroller that implements these traits. No matter stm32, riscv, esp32 or raspberry pi or something else.
But we can not write such common interface for configuring of controllers because of very big differences in low level. Some of differences you find are easy to be fixed, but other changes can break safety of access to registers.
Another problem is small and splitted community. We want to have more homogeneous code, but it is hard to work with device you don't have in your hands or are not familiar with. You can help us if you'll find more such differences.
Splitting serial on tx(transmit) and rx(receive) is very useful, as they can work independent, and you can use they in different tasks.
And the most important thing. No more "sketches". Forget this word.

I also see the sketch uses serial.write and serial.read rather than splitting serial into rx and tx as is done in many examples. Is there a reason that would be preferable to splitting?

That's my fault, just take my code as pseudocode/proof of concept :)

But I understood that stm32f1xx_hal provides an implementation of embedded_hal::serial that is specific to the stm32f1xx hardware, so I don't see what use embedded_hal::serial; does, or why it is needed in addition too, or instead of, using serial from stm32f1xx_hal.

If you only want to use the f1 crate, you can just use the structs defined here and everything will be fine. However, if you want to use multiple HALs, embedded-hal provides a common interface to them.
By writing your code to be generic over the e-h traits, it becomes implementation independent.
I'll also close this since there isn't really anything with the code to fix. Feel free to continue the discussion though :)

I was about to close this myself since the only issue seems to be my incomplete understanding, and comments have drifted a long way from the issue title. There does seem to be a jump to get from pseudocode to a working example. I think there may be an issue around having some more complete examples that work across multiple HALs, but I need to do more playing before I understand this well enough. Thanks everyone, and I will try to remember to use the term pseudocode rather than sketch next time:)


IDEA 2020.1.3 Can't solove operator ’__' when i use @RequiredArgsConstructor

Short description
when i use it like this:
@RequiredArgsConstructor(onConstructor = @__(@Autowired))

idea notify that Can't solove operator __，but it's work and it has no effect on complitation
is there any problem with me?
i could not find any answer on the internet
i have enabled the annotation processor
Expected behavior
how to solve this problem
Version information

IDEA Version: 2020.1.3
JDK Version: 1.8
OS Type & Version: window10
Lombok Plugin Version: 0.34-2020.1
Lombok Dependency Version: 1.18.10

Steps to reproduce
NO
Sample project
NO
Additional information
NO
Stacktrace
NO

I also encountered this problem
Short description
when i use it like this:
@Setter(onMethod = @__(@Autowired))

idea notify that Can't solove operator __，but it's work and it has no effect on complitation
is there any problem with me?
i could not find any answer on the internet
i have enabled the annotation processor
Please locate the cause of the problem
Version information

IDEA Version: 2020.2.4
JDK Version: 1.8.0_162
OS Type & Version: MacOS Big Sur 11.0.1 (20B29)
Lombok Plugin Version: 0.34-2020.2

@Hug125
I learned from the documentation that operator  @__  is a experimental function，it may be replaced in jdk of higher version。

@ H125
我从文档中了解到算子 @__ 是一个实验函数，可以用更高版本的jdk代替。

所以应该怎么解决呢？兄弟

@Hug125 ok


Mobile device - problem with scrolling

I am not sure if this relates to the viewport.
If I view my blog page via the mobile device, I will see the homepage, with the Menu of the left and the list of Posts on the right.
I am unable to scroll down the list of posts on the right.
(this problem is only resolved i.e able to scroll down the list of posts, if I hide the left Menu by clicking on the Menu button)
In addition, if I have additional links (using Navigation), I am unable to scroll down view the bottom part of my links and the social links. I am only able to see my photo and the first few links.
It seems like the whole page of the homepage with the Menu, is truncated if viewed via a mobile device.
My mobile device is Android with 5 inch screen, using Chrome version 45.

I have a feeling that the 'issue' I encountered above is related to a comment posted on one of your post:
http://kikobeats.com/styleguide/
which commented :
"The landing page, or div layer sitting on the blog posts could make a lot of people confused and close the page. Because people will try to scroll and it won't scroll. So you could add an on scroll trigger to retract the layer to the right instead of expecting them to click the tiny "blog" link."

Can you provide a gif of this, using recordit or something like that? I don't understand clear the issue :-(

To better illustrate the issue, I am using a mobile phone emulator:
http://mobiletest.me/samsung_galaxy_y_emulator
I used your landing page:
http://mobiletest.me/samsung_galaxy_y_emulator/?u=http://kikobeats.com
It is possible to scroll the list of pages, but not the navigation page on the left because the scrollbar is not available.

Oh, now I understand you.
The problem is device with little screen. The CSS property to control the scroll is overflow. At this moment, when you open a the aside in mobile/tablet the overflow value is hidden because:

I supposed all the time that your device is big enough.
When the device is big enough and you open the aside, you don't want experimented a bad interaction with the aside if you by mistake, like:

The point is, if I avoid to use overflow:hidden screen with big enough is bad and I use  overflow:hidden experience with devices with small screens is bad 😅.
The solution would be detect the vertical screen size and apply or not the CSS property dynamically. For example:
var h = window.innerHeight; // device screen
var lastElement = $('.social.item.hvr-grow-rotate').last().offset().top; // visible part of the web in the screen.
if (h > lastElement) $('.profile').attr('overflow-y', 'hidden'); // block scroll in big screens.

Good feedback @Kikobeats.
My comments:
I understand you intention to hide the scroll bar for big screens.
The problem is that, if the scroll bar is hidden for big screens, the list of posts appear on the right but I will not be able to scroll it down. it is the problem I mentioned above. So the list of posts become stuck giving the impression that the content is truncated.
Similarly, if my aside is open and if my aside has a reasonable long list of navigation links (for example, maybe 5 navigation links and 6 social icons), the aside is truncated. You will see the grey section, like your screenshot/capture above, hiding the twitter, linkedin icons etc.
If you limit the number of navigation links or social icons, then such a solution is not good.
An ideal solution is to have the cover takes up the whole page, just like the enhancement mentioned in #29 and #71. With this solution, you will have a scrollbar visible so that you could scroll the aside. Also, this means that the list of posts will not appear on the right by mistake, and the scrollbar will not affect it in any way.
I don't expect you to cater to all and every kind of devices (including mobile or notebook), but if you could cater to most sizes including big and small devices for mobile, then you have an elegant theme.
Your theme is very nice and it would be nicer to solve this issue.

@mickeyhoh can you write a solution as PR?

@Kikobeats, I am sorry but I don't really write codes. Do you mean to say that you need me to write some codes and activate the PR?

@Kikobeats, love the theme! Not sure on what the progress/update is on this issue, but there are a few blogs in the Showcase that are modified in such a way to "fix" this issue. Not sure if that would be of any help.

@Alexanderbez
I want to fix it and I know it will be easy, but I want to be sure to not create a lateral effect for other devices as well.
Now I think that the best solution is using viewport units in this part of the web. Ideally if somebody affected with this bug could be make a PR, I would appreciate, in other case, yes, I want to fix, but if another priority bug appear I move this on the end of my bugfix list.
btw I think that is not too much critical, the trend is screens getting bigger :P

I am not sure if I could help in any way?

@Kikobeats, I was viewing the site on a Oneplus one witch has a 5.5" screen. I'd say that's a pretty big mobile screen size.

Can you try to resolve the bug in a PR? Definitely I need more devices for
testing this :-(
On Tuesday, September 29, 2015, Alexander Bezobchuk <
<EMAIL_ADDRESS>wrote:

@Kikobeats https://github.com/Kikobeats, I was viewing the site on a
Oneplus one witch has a 5.5" screen. I'd say that's a pretty big mobile
screen size.
—
Reply to this email directly or view it on GitHub
https://github.com/Kikobeats/uno-zen/issues/72#issuecomment-144080497.

@Kikobeats, sure I can poke around and see if I can help. Also, for debugging you can use Chrome's device emulator that's built in (Device mode).
See your example blog: http://cl.ly/image/30130z0W0R2J
See another that seems to have a patch: http://cl.ly/image/270b0t1q2v1c

@Alexanderbez
Wow! Good stuff Alex.
Previously there was missing background/cover for the aside, which happened in @Kikobeats's release but not in Adrian's. Eventually @Kikobeats eventually resolved the bug (thanks Kikobeats!)
It seems that Adrian's release do not have this viewport issue. I am wondering if Adrian's could help us out?

@Alexanderbez thanks for the feedback! I want to resolve for this week :-)

I guess this bug is still being fixed?

@mickeyhoh @Alexanderbez
Can you confirm me that aside under mobile/tablet is working well now? check in my website http://kikobeats.com/, I have the pre-release version 😊

@Kikobeats. I tried it on the same mobile phone I used earlier. Looks good. I think it is fixed and it has similar results as Adrian Perez's theme that was based on your there. Well done!
@Alexanderbez, can you confirm at your end please? Do you have any smartphone or tablet or emulator to confirm the fix?

@mickeyhoh @Kikobeats, tested on my personal mobile device and via the Chrome emulator. Looks pretty good!

Thanks again @Kikobeats and @Alexanderbez !


[1.10.2 +] FEATURE REQUEST: Conduit facade compatibility with Chisels And Bits creations

I know you guys are kept busy by all the updates and other feature 'to do' lists, but I'd love to see compatibility with Chisels and Bits mod for the Conduit Facade. I'm making a 'realistic' floor by cutting out 'rafters/joists' out of oak planks, but I have conduits running thru part of that area. Being able to cover the floor from above, but still see the joists and conduits from below would be awesome.
Granted, I'm not much of a programmer, so I have no idea how much work it would be, or even if it's possible.
Keep up the good work!
Thanks

No, not possible. C&Bs are not simple blocks, they are TileEntities of their own.

That's too bad, thanks anyway.
On Fri, Jan 6, 2017 at 6:35 PM, Henry<EMAIL_ADDRESS>wrote:
No, not possible. C&Bs are not simple blocks, they are TileEntities of their own.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


Retrieve Relevant Values for Any Column

Currently in the v2 API in order to filter against a workbook, you can set any field in the dataset regardless of the makeup of the worksheet/dashboard you're filters. So for instance, if I run
worksheet.applyFilterAsync("Product Type", "Coffee",
    tableau.FilterUpdateType.REPLACE);

it will apply the filter regardless of whether or not Product Type is on my filter shelf.  However, if Product Type is on my filter shelf and, for instance, set as a context filter, it will take that into account and apply the filter in context.  This flexibility is extremely useful so I would appreciate if it can stay!
However, when retrieving filter values this "ask for any filter" approach does not work.  When running
worksheet.getFiltersAsync() it only retrieves filters that have been set up in Tableau Desktop/Web-edit (understandably) or applied via the JS API.
Will there be a method available to retrieve relevant values for columns that haven't been added to the worksheet's filter shelf?  Either a worksheet.getColumnValuesAsync("Product Type") or filtering the underlying data to specific columns (since this column may not exist on my level-of-detail as well)

Would your proposed worksheet.getColumnValuesAsync() get all values or only the unique items in said column? The latter would make it really useful and easy for creating custom filters in your web app.

Yes, ideally it would retrieve the equivalent of a “SELECT DISTINCT” for the column.  I would imagine that this would need to be a worksheet method, but a dashboard method would be very convenient

Basically you want Field.getDomainAsync (and you want to be able to get all Fields and filter to the specific one you're interested in). Is that inline with your idea?
By the way, we have Filter.getDomainAsync in the Extensions API: https://tableau.github.io/extensions-api/docs/interfaces/categoricalfilter.html, but as you're pointing out that's only if the Filter has been applied.
I definitely like this idea. If you agree with my Field.getDomainAsync idea, I will put in on the backlog.

Incredible.  Yep, exactly, Field.getDomainAsync()!


Choose license !

We need to choose a licence - and define the copyright holder - before publishing the source code.
I'm suggesting AGPLv3, but we'll probably need input from Jonathan ?

License is now MIT


You should make Kebab instead

what is this about? lol

LOL bro was so disappointed with the code that he gave the op a career advice

lol

i laughed so hard at this lmao

Kindly post your concern and the code to reproduce it.

did you not understand


SPIR-V Testing Thread

Post SPIR-V test results here. Use this archive to test. Some games may be super old and will not work even with stock FNA releases, don't expect much from games that haven't been updated in 4+ years.
Environment variables of interest:

To force a 4.6 Core Profile for RenderDoc, set FNA_OPENGL_FORCE_CORE_PROFILE=1

Not all games are compatible with Core Profile.

To force the SPIR-V profile, set FNA_GRAPHICS_MOJOSHADER_PROFILE=spirv

Template/Example Report:
OS: Fedora 30 x86_64
Graphics: NVIDIA GTX 770, version 430.26
Games Tested:

Rabbit Algebra

Breakages (with logs):

Rabbit Algebra crashes once in-game, with GL_INVALID_OPERATION error

Platinum:

Apotheon
Axiom Verge
Bastion
Blueberry Garden
Capsized
Celeste
Escape Goat
Escape Goat 2
FEZ
Fist Puncher
Hidden in Plain Sight
Quadrilateral Cowboy (Art Book)
Reus
Rex Rocket
Rogue Legacy
Shipwreck
Soulcaster I/II
Wizorb
Wyv and Keep

Gold:

Chasm
Simply Chess

Silver:

Flotilla, uses PSIZE0 which produces invalid SPIR-V
Murder Miners, maybe it's the 3D textures?

Known not to work:

CraftStudio, custom build breaks ABI
Gateways, build is absurdly out of date, my bad...
Staxel, an absolute mess
Terraria, outdated build and breaks ABI

Untested:

A Virus Named TOM
Before the Echo
Bleed
Bleed 2
Brushwood Buddies
Charlie Murder
CometStriker
Cryptark
Curse of the Crescent Isle DX
Dead Pixels II
Dust: An Elysian Tail
DwarfCorp
Flinthook
Fossil Echo
Full Metal Furies
Gnomoria
Hacknet
Hive
Hybrid Beasts
Hyphen
Interloper
Jon Shafer's At the Gates
Khet 2.0
Melody's Escape
Mercenary Kings
MidBoss
Overdriven Reloaded
Owlboy
Paladin
Press X to Not Die
Reversi
River City Ransom: Underground
Salt and Sanctuary
Skulls of the Shogun
Solaroids: Prologue
SpeedRunners
Super Rad Raygun
Square Heroes
Tatsu
The Adventures of Shuggy
The Dishwasher: Vampire Smile
Timespinner
Tooth and Tail
TowerFall Ascension
We Are Legion

OS: Windows 10 Pro x86_64
Graphics: NVIDIA GeForce GTX 1060, version 431.60
Games Tested:

FEZ (beta branch)
Chasm
Celeste
Rogue Legacy (fna-win32 branch)

Breakages:

FEZ fails to boot. There is a System.NullReferenceException thrown in FezGame.Program.Main when run with the archive provided.
Rogue Legacy console log reports the following twice during initial loading:

Program/shader state performance warning: Vertex shader in program 14 is being recompiled based on GL state.
        Source: GL_DEBUG_SOURCE_API
        Type: GL_DEBUG_TYPE_PERFORMANCE
        Severity: GL_DEBUG_SEVERITY_MEDIUM

(Interestingly, this also happens when run with FNATEST_DISABLE_SPIRV=1, but not when using the fna-win32 libs the game ships with by default.)

FEZ Windows is probably out of date, even on beta... Linux is the only working build for now.
Simply Chess is probably in the same boat as Murder Miners, will have to compare the asm to be sure.
NVIDIA debug mode does produce perf warnings for shader recompiles, so that’s normal. Release versions skip the debug context flag.

OS: Windows 10 Pro x86_64
Graphics: Intel HD Graphics 620, version <IP_ADDRESS>00
Games Tested:

Chasm
Celeste
Rogue Legacy (fna-win32 branch)
Axiom Verge
Simply Chess

Breakages:

Chasm: CRT Effect flips the viewport upside-down. (This is being addressed on the Chasm dev's side, correct?)
Celeste: Any distortion effect (such as when dashing or dying) corrupts the entire game screen:

Simply Chess: Um...

Chasm I believe now depends on the accurate behavior, disabling spirv will verify this. If not I’ll check with James...
As for the other two... looks like we’ve got some gooduns, @krolli!

I pushed vpos thing, which should help Chasm (its CRT effect was among those changed by this fix). While doing that, I also noticed vface was just wrong (if generated, it didn't pass validation) and because of some dubious logic to determine whether input is vpos or vface, it went unnoticed before I looked into the vpos.
I'll take a look at Simply Chess next, since its free. What about the others? We can either do renderdoc captures, or I can just grab them from Steam as I get to them.

Let's try for RenderDoc captures by default, but depending on how busted things are rdoc might crash, so that'll be when we have to dig up the game for real...
Will update with the VPOS fixes later today.

Just tested with the latest.
The Chasm CRT Effect doesn't have a flipped viewport anymore, but now it's got a different problem. This is me toggling between the off/on settings:

I'm having some difficulty getting RenderDoc to capture appropriately. (All captured textures are appearing as solid black.) I'll post a capture when I get that figured out...

fnaSPIRV.tar.bz2 has been updated with the latest, sorry that's late...

Hmm, I went through much of the glsl and spirv version of crt shader (though it's pretty damn long and mind-numbingly tedious to compare) and I didn't notice anything different. Guessing from what it looks like, the y coordinate for sampling of render target (is that what it's doing?) is either outside of 0-1 range, or it's same value for all fragments in a column (possibly 0). Maybe the vposFlip uniform is not set correctly.
Unfortunately, those captures seem to have zeroes everywhere, including uniforms. Can you try with stable release of RenderDoc? It certainly seems like a bug and I would be rather suspicious of nightly builds.

Looking at the capture you sent me a while ago (which has resource data as well), it seems that render target sampler has wrap mode set to CLAMP_TO_EDGE. It definitely seems to be something to do with Y adjustment of vpos. My primary suspect is definitely vposFlip uniform, probably not set at all.

@TheSpydog I found possible cause of CRT effect going haywire and pushed the fix. Location for vpos uniform was not offset to account for locations take up by vertex shader, so it was probably filled with incorrect values. Hope it will works this time.

Also, when I wrote some simple test that used the shader, I got GL_INVALID_OPERATION error generated. Wrong component type or count. . Maybe this is the same issue as you had on Simply Chess when you clicked on something.

Cool, just tested and Chasm is back to being merely upside-down in crt mode. So that's progress at least. Also coaxed a little more info out of Simply Chess. When I click on a chess piece, this pops up:
Assertion failed!
Program: mojoshader.DLL
mojoshader_opengl.c
Line 614
Expression: table->samplers[idx].offset

Pushed fix for the assert.
As for CRT, I am at a loss. Strange thing is, the capture you sent me a while ago (before vpos) which was supposed to have the upside-down problem, shows up correctly in RenderDoc for me. At least, the final result is correct. Most of the rendering is actually done upside-down and only at the end it all gets flipped back.

That makes some sense given the wacky coordinate system stuff, but i swear we sync'd this up with the latest vpos fix... if FNATEST_DISABLE_SPIRV=1 produces the correct image it's in the emitter, otherwise it's in Chasm (I'll go bother James about it).

Those screenshots are from a month-or-so old captures. Not sure what it looks like right now, since captures pretend all resources are just zeroes.
BTW, any idea whether Simply Chess is supposed to work with FNA_OPENGL_FORCE_CORE_PROFILE? I keep getting GL error even with GLSL.
System.InvalidOperationException
  HResult=0x80131509
  Message=GL_INVALID_OPERATION error generated. Invalid VAO/VBO/pointer usage.
	Source: GL_DEBUG_SOURCE_API
	Type: GL_DEBUG_TYPE_ERROR
	Severity: GL_DEBUG_SEVERITY_HIGH
  Source=FNA

Looks like they use client arrays, so that ones out for Core Profile testing unfortunately :/

FNATEST_DISABLE_SPIRV=1 does indeed produce the correct image for Chasm CRT. I've attached another capture (using RenderDoc 1.4 stable). Maybe this time it will show something interesting?
chasm_spirv.zip

Sadly, nothing. I can see source textures, but all uniforms are just zeros, which (probably because of broken transform) causes all draw calls to collapse into single point and render nothing. I see a bunch of errors and warnings in log (many times repeated):
RDOC 013552: [06:50:53]        gl_common.cpp( 706) - Warning - FBOs are shared on this implementation
RDOC 013552: [06:51:00]        gl_postvs.cpp( 439) - Error   - Failed to fix-up. Link error making xfb vs program: Link info
RDOC 013552: [06:51:00]        gl_postvs.cpp( 439) - Error   - ---------
RDOC 013552: [06:51:00]        gl_postvs.cpp( 439) - Error   - error: Varying (named vs_o0) specified but not present in the program object.
RDOC 013552: [06:51:35]        gl_replay.cpp( 339) - Warning - Attempting to read off the end of the buffer (12 196608). Will be clamped (196608)
RDOC 013552: [06:51:35]        gl_replay.cpp( 339) - Warning - Attempting to read off the end of the buffer (16 196608). Will be clamped (196608)

I don't really know whether this is something related to spirv emitter, or some other bug causing RenderDoc to fail to capture uniforms. I can only humbly ask for help from @baldurk.

That's a fun one. I think @krolli you're using RenderDoc v1.4 which didn't properly handle SPIR-V GL shaders in some situations like fetching mesh output, because it relied on driver reflection and GL transform feedback instead of patching the SPIR-V by hand. I made a change a little while ago to fix that.
The uniforms are 0 because the capture was made on a recent build of RenderDoc where unfortunately I broke SPIR-V reflection of loose global uniforms (i.e. not in a UBO). I've pushed a fix that should get it working again, but you'll need to recapture and replay on the next nightly build to get everything working now.

Well, that would explain a lot. I guess we have another round of capturing ahead of us. :)

Here's the Chasm CRT and Celeste dash effects captured with the latest nightly build:
chasm_celeste_captures.zip

So, Chasm still looks correct on my end, though it seems rather dark.

Can you open the capture on PC where it's wrong and see whether final result is flipped upside down? Also check whether first color pass ends at EID 52 with the screen upside-down or correct. For me, it is upside-down and gets flipped back in third color pass (at EID 167). All draw calls in capture have vpFlip uniform in vertex shader set to -1, except EID 99 and 167, where it is set to 1. Also, only EID 81 (CRT effect I assume) uses ps_vPosFlip which is set to vec2(1.0, 0.0).
Celeste, on the other hand, looks pretty broken for me as well, though in a different way than your gif earlier. It would help a lot to have somewhat similar capture from glsl run of the game for comparison.
There is a bunch of API use errors about vertex buffers not being bound at EIDs 16, 21, 26 and 44 which then seem to not do anything. I don't think this is related to spirv emitter (code for binding VBs is the same as glsl), but whether it is RenderDoc bug or Celeste I don't know.
Then, there is some unusual stuff happening at EID 145 and 223. In both cases, there are two textures bound to pixel shader, but Pipeline State tab only shows one. Also, call stream in API Inspector shows that two different textures were bound, but Texture Viewer shows the same thing in both slots. I wonder whether Render Doc confusion stems from some error in emitted spirv, or its a bug in RD itself. EID 145 seems to be doing distortion using what looks like normal map bound in slot 1. Assuming there is some issue with this binding and shader instead computes distortion using whatever is bound in slot 0, it might explain weird mess this produces.

I will try to figure out what might be causing the problem, but @TheSpydog, if you could do a capture from Celeste that uses GLSL emitter for comparison, it would help a lot.

Interesting. On my PC it is upside-down at EID 52, flips to its correct orientation at EID 81, and then gets flipped again (back to being upside-down) at EID 167. Also worth noting that at EID 81, ps_vposFlip is (0.0, 0.0), not (1, 0). And vpFlip is showing up as 0.00 for all EIDs.

For Celeste, I noticed that the graphics glitch still happens even with FNATEST_DISABLE_SPIRV=1. But it doesn't occur in the latest stock fnalibs distribution, so I don't know what's up there. Anyway, here's a capture of the correct glsl version:
celeste_glsl_dash.zip

The vertex buffer errors are due to use of deprecated compatibility profile functionality - before those draws with the errors you can see calls to glVertexAttribPointer with no buffer and an offset of 0xFFFFFFFFDEADBEEF. That's what RenderDoc serialises when you use client memory vertex pointers (i.e. no vertex buffer, just drawing straight from CPU memory pointers).
The texture binding issue is a little weirder. It seems like your shaders do not specify the texture binding in the SPIR-V as I'd expect, and instead sets a location and relies on glUniform1i or something like that to set the binding based on a fixed location. This seems to work but I'm really not sure if it's valid or intended, the spec leaves this is as kind of a grey area:

How do we change the location of samplers and images?

RESOLVED. You don't. Well you can using Uniform1i as usual, but you have
no way of knowing which location corresponds to which sampler or image
variable as GetUniformLocation won't work without a named variable. Best
to just treat them as immutable bindings which are specified in the
shader source or binary.

Which seems to imply that it might be legal to do this, but at the same time casts doubt on whether it's intended to be able to annotate samplers with a location.
At the moment RenderDoc ignores setting sampler uniform values for SPIR-V shaders, if I let the code set them for all shaders then the capture loads looking more correct. I'm really hesitant to do that though in case it breaks on another implementation (I'm using nvidia which is notoriously forgiving with GL).

Are you using your own build of FNA or one from archive at the top? I don't think FNATEST_DISABLE_SPIRV is in those sources.
Anyway, I noticed something that might have been the cause of RenderDoc showing only one texture. Who knows, it may have caused other issues as well. I pushed the change so if you have time, could you try it out and see if it helps Celeste? Even if the game is still broken, a RenderDoc capture from this version might be in better shape.

Ah, github and its page refreshes ... :(
I was looking at the same thing and I figured adding bindings is simple for me so I did it. Just as you, I am a bit unclear on this whole thing. I am pretty sure location is mandatory for inputs, outputs and uniform variables, but samplers are a bit weird in that regard. You definitely can't query them by name (as names can be stripped from spirv) and judging by my previous experience, not specifying location will just cause driver to assign same location to everything.
Simple fix I pushed just now should assign unique bindings and locations to samplers within pixel shader, but there is a risk of conflicting bindings between vertex and pixel shaders. I don't think Celeste uses vertex textures so it should be fine for testing it and if it works, I will just make bindings unique across whole program (same as locations are right now).
Hmm, glVertexAttribPointer issue sounds like something that should be dealt with by enabling FNA_OPENGL_FORCE_CORE_PROFILE. Didn't know RenderDoc even works with the other FNA OpenGL device. It definitely doesn't for me, when trying to debug Simply Chess. :(

FNA doesn’t do anything special for client arrays, since I usually expect ARB_debug_output to throw the error for Core. A temp hack could be added to make a staging buffer for client array input, but it might get ugly...

Tried Celeste with the latest. Doesn't seem to make a difference. Attached an updated capture.
celeste_spirv_dash_updated.zip

@flibitijibibo Nah, I didn't mean to suggest doing anything about it. I don't know that much about how GL devices are implemented in FNA, so this was just my misunderstanding.
@TheSpydog Well, capture is looking correct when I view it in RenderDoc (barring issue with client arrays), so I guess that's at least some improvement. Distortion effect is there too, although capture was almost at the end of it so it is just barely visible. When you open the capture, can you see some point at which it breaks down?

Agh, thought I had more of the distortion effect in the capture, sorry about that. EID 193 is where it goes screwy.

I found out SINCOS opcode had swapped sine and cosine values. It also used OpUndef to fill in values that (in theory) shouldn't matter. I have seen OpUndef cause driver crashes so I replaced it with zeros just to be sure. Since SINCOS is used in distort effect, it might help with the problem, so feel free to try it when you have time.

That fixed the issue! Great work. :smile:

Great, glad to hear that. Still more bugs to be squashed though. :)

@baldurk I'm going over the ARB_gl_spirv again looking for anything regarding bindings and locations of uniforms and I found this (in section "7.4.spv, SPIR-V Shader Interface Matching"):

Uniform and shader storage block variables must also be decorated with a Binding.

I think it's safe to say that this was a mistake on our side and you have it correct.

All right, after a lot of testing this weekend I can confirm that Reus, Dust: AET, Wizorb, Capsized, and TowerFall all seem to work without issue on my Intel HD Graphics machine.
I also tested Apotheon, which boots but just displays a black screen with some version text at the top. @krolli I sent you a DM on Discord with the captures and the shader files.

Well, this looks like another case of "works on my machine" capture. Can you take a look and see if you spot anything that goes wrong? I can clearly see what results should look like at EID 125 (end of Color Pass #5) just without lighting yet. After that there are a few more passes that apply lighting and some postprocesses. Both GLSL and SPIRV captures look the same.

Update on Apotheon:
The issues RenderDoc displays about "no vertex buffer bound" are present in the glsl version too, so they're probably not relevant. Also, I noticed this when comparing the two captures:
(SPIRV on left, GLSL on right)
Could the swapped ordering of the inputs be at fault?

derp, don't mind me

They certainly could. I wanted to get a better look at how sampler binding works in mojoshader/FNA to see if the default binding I put into SPIRV could be improved. Weirdly, it looks like ps_s0 and ps_s1 have same textures bound. It might be the order in which they are reported from reflection APIs that doesn't match between the two. I think RenderDoc uses various OpenGL calls for reflection with GLSL, but does its own parsing with SPIRV.

I would expect some other titles to be affected by that if it was the emitter (anything with BloomCombine/BloomExtract/GaussianBlur should use 2 samplers, for example). A possible test would be a shader that uses 3+ samplers all at once and see how RenderDoc orders the inputs.

Updated fnaSPIRV.tar.bz2 one more time, this time it's a clean master build, which has some new changes. In addition to FORCE_CORE_PROFILE defaulting to 4.6 (this was already done in the test binary), there's now an official environment variable for shader profiles, FNA_GRAPHICS_MOJOSHADER_PROFILE. Set it to spirv or glsl120 (OpenGLDevice defaults to glsl120, ModernGLDevice defaults to spirv if MojoShader has it).

Escape Goat 2 now works! Not sure what fixed it but it seems fine now.
Murder Miners has one shader not compiling, HologramBlockEffect. It appears to just be using NORMAL0 as the attribute that freaks it out. If you take a sample shader and arbitrarily change an input to be NORMAL0 it should fail to emit in spirv mode.

Tried out Flotilla. It boots, but stars are missing (PointSize) and performance is in the single digits! I'm also seeing lots of performance warnings that aren't present in the glsl120 output. It may just be a case where an Exception is getting thrown and it's causing lots of CPU perf issues unrelated to what the SPIR-V output is.

Super dumb question: I only just noticed that in spirv the vposFlip name is actually “ps_vPosFlip”. If we change that to “vposFlip” does that fix Chasm?
(For some reason I’m now wondering if that flip should be in the FLIP_RENDERTARGET define with the unmodified builtin value as the else case...)

Spirv names shouldn't matter as far as I know. It is valid for these to be stripped from shader, so we shouldn't use any function that queries things by name. That said, changing it is simple to try and I actually thought the glsl name had ps_ prefix.

Rename is in, along with some simple support for NORMAL semantic. Murder Miners should now work.
I had a look at SM_3_0 attributes and it may be a bit more work to do proper support for it. As I understand it, basically any non-built-in semantic can have index up to 7. Currently, there is direct mapping semantic+index -> location, but assuming 8 indices for almost all of them would blow up the number of locations with most of them unused. I could assign them dynamically, but then values will depend on the order in which they appear in dcl_ instructions, which doesn't have to match between vertex and pixel shader. I guess this will also have to be patched during linking, same as uniforms. :(
Flotilla is interesting. I checked the code and PointSize built-in appears to be handled, though maybe not correctly. I just found one Psychonauts shader that uses it and I think the problem is that spirv declares it as vec4 (as almost every other register) while it should only be float. I will take a look at it later and let you know when it's in.

No luck with Chasm unfortunately. Murder Miners does indeed boot now, but the main menu background is missing. It's just black in the background on spirv. Looks like an issue with color pass 1 from my brief investigation. Attaching glsl/spirv captures for comparison.
murderminers.zip

I forget where I saw it, but I believe it goes all the way up to index 9 for SM3, hence this unpleasant variable:
https://github.com/FNA-XNA/MojoShader/blob/fna/mojoshader_opengl.c#L104
But yeah, this will add another step to the link process for sure :/

Infrastructure and patching step are already there, but so far I thought we might be able to ditch it with UBOs. This won't work for attributes though. I wanted to get rid of it mostly because it forces the same shader to be compiled multiple times simply because of these mappings. :(

Hmm, I think that vertex_attrib_loc length is something else. Also, it might be wrong. :) It looks like the number of input registers (which has little to do with semantics). As far as I can tell those numbers are:
16 vertex inputs (v#) for vs_3_0
12 vertex outputs (o#) for vs_3_0
10 pixel inputs (v#) for ps_3_0
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx9-graphics-reference-asm-vs-registers-vs-3-0#input-registers
https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx9-graphics-reference-asm-ps-registers-ps-3-0#input-register-types
However, this doesn't say anything about semantics. Those come from HLSL reference and for linking vertex shader outputs to pixel shader inputs, we have to look at pixel shader input semantics: https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-semantics#pixel-shader-semantics
And now that I look at it, its interesting that they don't mention NORMAL as pixel shader input semantic, yet Murder Miners use that for connecting vertex shader output to pixel shader input. I remember reading somewhere that in DX10 or DX11, you can use any text for naming semantics between VS and PS, but I don't know how that would map to DXBC. Anyway, indices for semantics can apparently go up to n, but I couldn't find any info on what n is guaranteed to be.

n is an optional integer between 0 and the number of resources supported.

Pushed a bunch of fixes:

Point size is now float instead of vec4. According to vulkan spec, PointSize must be 32-bit scalar float.
NRM is now correctly using only src.xyz for normalization.
POW is now correctly taking absolute value of src0.

Point size thing should help Flotilla, while NRM and POW have fixed specular reflections on Simply Chess when I tested it.

With those fixes, Apotheon now displays correctly! Simply Chess also saw an improvement on my intel machine, although it's still totally texture-less:

With the latest revision it looks like Flotilla's still busted - thankfully the shader is very simple (before the FNA update the game rendered each PointSize individually, wrote this to allow for proper batching):
float4x4 WorldViewProj;

float4 VSBasicNoFog(
    float4 Position : SV_Position,
    inout float4 DiffuseColor : COLOR0,
    inout float PointSize : PSIZE0
) : SV_Position {
    return mul(Position, WorldViewProj);
}

float4 PSBasicNoFog(float4 Diffuse : COLOR0) : SV_Target0
{
    return Diffuse;
}

Technique PointEffect
{
    Pass
    {
        VertexShader = compile vs_3_0 VSBasicNoFog();
        PixelShader  = compile ps_3_0 PSBasicNoFog();
    }
}

@flibitijibibo It was what I was afraid of. Validation threw up on it. Luckily, GLSL runs into same problem, so I switched to using same check as GLSL does and now it seems to be fine. I also found similar vector/scalar mismatch in fog thanks to this, so I fixed that too (though fog probably won't work now anyway, without pixel shader support). Changes are pushed so you can try them and see if it helps.
@TheSpydog Interesting. I forgot Simply Chess had some extra problem on intel. I don't think textures are an issue here. This looks more like contents of one of the render targets, but in a capture I am looking it, it seems to only be written during GBuffer fill pass, but never read afterwards. Have you checked RenderDoc capture?
Murder Miners seem to be having some problem with cube map. Will take a look at it, I haven't checked how cube maps were implemented so far. Is it correct that character also looks different in spirv capture? He seems to be using different texture ...

Seems the validator's still unhappy for whatever reason... here's the effect binary just to be sure:
pointeffect.fxb.zip

fnaSPIRV.tar.bz2 has been updated. Additionally I've updated the OP with the complete list of FNA games to test. I'm pretty sure most of the FNA library is on a version recent enough to be using MojoShader instead of the old MGFX stuff, but if not let me know and I'll try to get a new build out. I know for sure Gateways and AVNT are on an old build, but that should be it...

I can confirm that Dust: AET and TowerFall Ascension work without issue on Intel Windows.
@krolli Oh, good catch on the Murder Miners character texture! He does indeed look different in spirv. (Seems to be using only the helmet texture?)

@flibitijibibo Pushed a fix for point size semantic being used on input. Hopefully that helps Flotilla. I didn't notice it marked point size as inout so I only tested on point size output.
@TheSpydog Assuming we're seeing the same thing, I think there is some procedural coloring of texture based on character preset going on, but it's not part of the captured frame. The input texture mapped to the character looks different between spirv and glsl:
GLSL

SPIRV

Either color change is not applied at all, or only one color is applied / overwrites all others.

That's a weird one! But in case anyone's wondering, MM does indeed render out the colors of the player model based on a user preference. It's the first screen on a fresh install and should be accessible from the menu after that. It's user-specific, so make sure you're testing multiple colors for your personal setup.

Just found a shader called MinerArmorEffect.fxb in my test suite. Sounds like that might be the one responsible. :)

Indeed it is! Worth noting that the effect is among those in MM that use 3D textures, so that's a possible starting point.

Yeah, just noticed. Given that the other broken one is using cube map, I think sampler generation code needs some reviewing.

Pushed a fix for volume and cube samplers. Wish everything was that easy to find and fix. It was a funny one though. :)

Murder Miners got an update this afternoon, may be worth testing one more time. It now also has hardware instancing, so lots and lots of vertex usages now!

Updated A Virus Named TOM to use the latest FNA, should now be testable.

Video playback should now work in core contexts as long as you use FNA_GRAPHICS_FORCE_GLDEVICE=ModernGLDevice:
https://github.com/FNA-XNA/FNA/commit/e464a53edeb2075169ab365ce229f40ae7561f78
That should fix one of the more annoying parts of testing this...

Have you guys tried Murder Miners and Flotilla recently? I don't really have those games, so I'm just fixing it blindly, but I think they should be in better shape than they were. Also, I'm at a loss for what might be wrong with Chasm and Simply Chess on Intel and I don't have one to test it on. Could the same issue be also on Linux or is it specific to Windows driver?
Anyway, I've been looking into doing some cleanup and refactoring, but I want to try and make my current way of checking changes produce less noise to result ID renumbering, so there wasn't much activity in spirv branch itself.

From what I remember Intel Windows and Mesa don't share anything, I'm not even sure if their internal docs are the same... Intel Windows might have to go in the "meh" pile until we can see how their Vulkan support handles the same modules.
I'll do a fresh re-test of everything starting on Monday.

Did a mass test of my catalog (minus the games that are maintained by the studio), and everything seems good except for Flotilla, which appears to have the same problem as before. If it's useful at all, D9VK implemented points recently:
https://github.com/Joshua-Ashton/d9vk/commit/b756e626be1ce0d88c77856f45692e6d3b80e1df

Hmm, I wonder what might be wrong with Flotilla then. Compiled shader you sent me a while ago seems perfectly fine. Going through the D9VK changes, it all looks pretty much the same, though I would have to see shaders they generate for given binary to be sure. They seem to be handling also some extra rasterizer state related to point size that I think is not exposed in xna. At least, I don't see it handled anywhere in GLSL emitter.
Can you make a capture from both GLSL correct version and broken SPIRV using renderdoc? I might spot something I am missing.

This got totally buried under some other stuff these past two weeks, my bad - one bit of good news is that we can stop looking at Simply Chess on Intel, as the game has an invalid vertex attrib layout for one of its shaders, so that’s definitely a game bug that we can’t address. Still dunno about Chasm though.
I’ll try to get a Flotilla capture tomorrow, hopefully it’s okay with OpenGL point sprite rendering...

After our investigation on discord yesterday, I went in and added patching of TEXCOORD0 input of pixel shaders to PointCoord BuiltIn when vertex shader it links to outputs PSIZE.
Unfortunately, I couldn't find any official specification of this mapping, and it seems that at least at some point in time, IHVs used to implement this slightly differently (https://stackoverflow.com/questions/12041358/hlsl-point-sprite-texture-coordinates-work-on-ati-not-nvidia).
I also had a quick look at D9VK patch you linked previously, to see how they do the mapping, but I'm not all that familiar with their architecture in general and I couldn't find anything for this. I did notice they take care to implement various rasterizer state that controls point rasterization and judging by effect file in stackoverflow question, it seems like something that can in theory show up in XNA games as well, so it might be worth keeping an eye on this as well.

The pointcoord changes work for Flotilla, so that’s good enough for me! Basically everything but PointSpriteEnable is something that can be done in the vertex data, and this is all XNA3 stuff anyway so an XNA4 update will eliminate these issues.
I think all that’s left of the tested games is Chasm, I wonder if it’s another bogus attribute like Simply Chess?

Updated the OP's test archive, after who knows how long. I think Flotilla got the last of the major features, so at this point I think we're down to the final testing process. I'll try to look at some of the untested list, but I dunno how much of it I can actually cover... but really I just care about any remaining FIXMEs in the SPIR-V subsystem. After that's covered, it's time to reformat, play through my usual checklist of feature-heavy games, and get this merged at last.

Just had a quick look at FIXMEs and TODOs still remaining. Most seem to be either present in GLSL emitter, or could be turned into notes now, since they often describe some behavior of the emitter in corner case but it's unclear whether that's a problem or not.

Sounds good, did a quick review to see if anything stood out. Using the current diff...
Already committed elsewhere:
https://bitbucket.org/krolli/mojoshader/branches/compare/spirv
default#Lmojoshader_effects.cF1333T1351
Stuff that can be committed separately:
https://bitbucket.org/krolli/mojoshader/branches/compare/spirv
default#Lmojoshader.cF524
https://bitbucket.org/krolli/mojoshader/branches/compare/spirv
default#Lmojoshader.cF1270
https://bitbucket.org/krolli/mojoshader/branches/compare/spirv
default#Lmojoshader.cF1833
https://bitbucket.org/krolli/mojoshader/branches/compare/spirv
default#Lmojoshader.cF3696T3720
https://bitbucket.org/krolli/mojoshader/branches/compare/spirv
default#Lmojoshader_opengl.cF580
https://bitbucket.org/krolli/mojoshader/branches/compare/spirv
default#Lmojoshader_opengl.cF711
https://bitbucket.org/krolli/mojoshader/branches/compare/spirv
default#Lprofiles/mojoshader_profile_glsl.cF953T953
Actual Comments:

Isn't this already declared...?
Mark this as a debug helper
Everything in testparse that's not SPIR-V can be made into its own patch as well

Most of it seems to just be cleanup that we can take in before taking in the SPIR-V stuff. I can import a zipfile full of patches for that list above, then I'll do one last pass on my own stuff before sending this to Ryan to review.

Already committed elsewhere:
...

I think you were looking at wrong branch. There is spirv-rebased that we created after last review and cleanup and that's where that fix came from. spirv branch is mostly just for my own testing but everything important should be in spirv-rebased.

Stuff that can be committed separately:
...

Most of those changes seem to have been there before I started working on it. Anyway, I agree those could be committed separately. Want me to pull them out or will you do it?

https://bitbucket.org/krolli/mojoshader/branches/compare/spirv
default#Lmojoshader.cF1833

I'm not sure this is correct. I don't remember the exact problem, but I don't think I fully understood it when I ran into this either. It's just a workaround for parser choking on TEXM3X3. I didn't include it in spirv-rebased for now.

Isn't this already declared...?

Certainly looks like it. I would probably scope the first declaration above to the for loop where it's used, unless some compiler complains.
As I mentioned, spirv-rebased should contain less noise and none of my debug tweaks/hacks, so I'd recommend looking at that one instead.

For some reason when I did a comparison of rebased on Bitbucket it complained that there were no diffs... going to guess that their Hg support is already starting to rot a bit.
In any case, if you can get all the non-SPIR-V stuff separated into separate .patch files I'll push all of them today. After that we should probably re-rebase and squash.

Do we need to worry about div-by-zero for SPIR-V? I know we had to do this for GLSL/Metal, not sure if the SPIR-V spec says anything about 1/0=INF.

If it had to be solved for GLSL, than I think so. If you're referring to NRM opcode implementation, then that one is literally using GLSL 4.50 InverseSqrt semantics. I wasn't sure at the time whether to use OpSelect, or go through the basic block dance and write some actual control flow. Not having either in there seems pretty dumb though, so I'll fill it in.

The ones we recently patched up in GLSL are RCP/RSQ, but it wouldn't surprise me if there were other instructions with the issue:
https://github.com/FNA-XNA/MojoShader/commit/135aa1838ed57f41e2818f75a79326786d2d72a2#diff-4e911017b30f49678e6ce07bf820611b

Probably should give the same treatment to those as well. Which game did it pop up as a problem? I would expect the same to show up with SPIR-V emitter.

I believe the only one with the bug still in the wild is Murder Miners, I found this with Shuggy and Reus but unfortunately I fixed those on the client side. If you need a copy ping me on Discord, I should have some gift copies available. Spydog should also have a repro case.

Pushed handling of corner cases for NRM, RCP and RSQ based on what GLSL emitter is doing. I noticed that according to DXBC docs, division by 0 in RCP and RSQ should return infinity, while NRM uses FLT_MAX instead. I decided to be consistent with GLSL emitter here and use FLT_MAX everywhere.
Unfortunately, for various reasons I haven't been able to test it on Murder Miners. If one of you guys can try it and let me know, that would be great. It's an extra commit on spirv-rebased-2 branch, so it should be fairly simple to do before/after comparison and see if the explosion particle effect problem was present before and fixed with these changes.

Just tested rebased2 and everything seems to work well, including the div-by-zero case in Murder Miners.
At this point I'm happy enough to where this can be merged - it'll be pretty much impossible to test everything, but it definitely seems to work with what I've thrown at it, so go ahead and do a final pass with any last edits, comment updates, notes for scary stuff, etc. and I'll get the final hg patch pushed before the end of December. (I'll also send the final chunk of the bounty before the year's over, just so we have everything in a single calendar year...)

Alright, I'll check it one more time to see if there are some comments worth updating. I definitely don't want to touch code unless we run into any more bugs. There are things I'd like to try to improve for some future update, but they are quite a lot more work that might require retesting everything, so not for this version.

Commit some final cleanup of TODOs, FIXMEs and testparse code (some of my unintended changes slipped through). All should be ready on my end.

The patches have been merged into upstream! From now on we'll diagnose issues on a case-by-case basis.


Unpredicted high spike

Hi,
I have tested your tool with the following pattern, which I just got :
Sell Price : 95
Buy Prices : 79, 76, 74, 69, 95, xx, 529
For the 6th value, it was around 145 but I can not tell more precisely (I sold them on an other island before that).
Even entering all the values, your tool can not predict the 529, nor the large spike. It will only predict a small spike if you do not enter the 6th or 7th value, and won't be able to tell the pattern if you do.
No time travel, and no FirstKabuBuy involved.
Thanks a lot for all your work :)
Regards,

Thanks for the data! That's definitely pointing to some sort of rounding issue - I will continue to investigate

get similiar rounding/ceiling problem with 100 buy and 90,86,80,78,75,72,67, that 78 return empty and last interval is 74-77

It seems like the first value was 80 and not 79, which lead to a wrong determination of the pattern.
Closing this issue


splash:har_reset

Current coverage is 84.52%

Merging #298 into master will increase coverage by +0.02% as of 45518aa

@@            master    #298   diff @@
======================================
  Files           37      37
  Stmts         4097    4104     +7
  Branches       531     531
  Methods          0       0
======================================
+ Hit           3462    3469     +7
  Partial        144     144
  Missed         491     491

Review entire Coverage Diff as of 45518aa

Powered by Codecov. Updated on successful CI builds.


Space after function name

I think I could get on board with all of these conventions except "space after function name". I can honestly say that I have never seen that done in any JavaScript code. In fact, I have never seen that done in ANY programming language. I wish at least that was configurable.

Sorry, this has been discussed many times before. See https://github.com/feross/standard/issues/318 https://github.com/feross/standard/issues/89 https://github.com/feross/standard/issues/311 https://github.com/feross/standard/issues/217.
If you want to configure rules, you can fork standard or use eslint directly with the standard config. That would work like this:
.eslintrc
{
  "extends": [ "standard" ],
  "rules": {
    // ... go wild here...
  }
}


feat: authentication options for the token vending machine

Addresses the tasks in #385 regarding making auth configurable for the token vending machine and adding examples. There is a new config variable that is used in the CDK appliance to determine whether to attach one of the authorizers to the GET endpoint.
The Lambda Authorizer example simply uses a hardcoded username/password check to determine whether to allow access to the TVM endpoint. The endpoint expects a couple of headers (username and password) as part of the GET request. I have verified this works with the Vite app with minimal changes (passing the headers and configuring API Gateway to expect those headers).
The Cognito example creates a user pool and requires some manual steps to get working: creating a user and app client in the user pool through the AWS portal, signing into Cognito to acquire an ID token, responding to a Cognito challenge (resetting a temporary password), then passing the ID token under the Authorization header in the GET request. I haven't yet verified that this works with the Vite app as it seems it will take more setup than the other one.
Finally, the remaining changes involve updates to the docs and package.json files.

I have verified this works with the Vite app with minimal changes (passing the headers and configuring API Gateway to expect those headers).

have you thought about how we can add some configurability to the vite app to support this as well? would love to do that in a follow-up PR.
Same thing with Cognito but I think we can go ahead and get this PR merged and then update the Vite app to use the lambda authorizer first, and then circle back for cognito.

have you thought about how we can add some configurability to the vite app to support this as well? would love to do that in a follow-up PR.
Same thing with Cognito but I think we can go ahead and get this PR merged and then update the Vite app to use the lambda authorizer first, and then circle back for cognito.

Yeah, I think there could probably be another few environment variables that the Vite app can use to determine which authentication route to take and what username/password/clientId values to use to connect to the TVM. I can certainly mess around with it more to see if there's a way to easily incorporate configurability for both lambda authorizer and cognito.

have you thought about how we can add some configurability to the vite app to support this as well? would love to do that in a follow-up PR.
Same thing with Cognito but I think we can go ahead and get this PR merged and then update the Vite app to use the lambda authorizer first, and then circle back for cognito.

Yeah, I think there could probably be another few environment variables that the Vite app can use to determine which authentication route to take and what username/password/clientId values to use to connect to the TVM. I can certainly mess around with it more to see if there's a way to easily incorporate configurability for both lambda authorizer and cognito.

let's start with the lambda authorizer one and then we can handle cognito in another PR if we decide to do it.


Make it independent of Bootstrap

It seems this is the most flexible (while staying easy-to-use) breadcrumb solution for Vue.js.
…But I don't  use Bootstrap — I use Bulma (which I really love) — So it would be great if the visual part could be completely customized.
Thank you!

@andylima Hi, already scheduled in mileston-0.4.0


Triggering XDebug

So xdebug has now been added to VCCW as per Issue #79 but how do I trigger debugging? I have modified xdebug.ini to include the following to allow for debugging -
xdebug.remote_enable=true
xdebug.remote_port=9000
xdebug.profiler_enable=true
xdebug.idekey=VCCWDEBUG
xdebug.remote_connect_back=true
xdebug.remote_autostart=true

Can this be added?
Chris.

Oh, OK please wait a couple of days.

@miya0001 Thank you!


go vet errors not detected in vagrant

There is a difference between go vet output between Vagrant environment and fresh Go environment on host, even when the same version of Go is used.
I checked it on the current master, fc1bac1f79bdabe77452f2c8e0793a0e2255e2ea
Host:
 mrostecki   master  …  github.com  cilium  cilium  make precheck
can't load package: package github.com/cilium/cilium/test/bpf: C source files not allowed when not using cgo or SWIG: bpf-event-test.c unit-test.c
go tool vet api pkg proxylib envoy plugins bpf cilium daemon monitor cilium-health bugtool
proxylib/memcached/binary/parser.go:201: github.com/cilium/cilium/pkg/envoy/cilium.LogEntry_GenericL7 composite literal uses unkeyed fields
make: *** [Makefile:220: govet] Error 1

Vagrant:
vagrant@runtime1:~/go/src/github.com/cilium/cilium$ make precheck
can't load package: package github.com/cilium/cilium/test/bpf: C source files not allowed when not using cgo or SWIG: bpf-event-test.c unit-test.c
go tool vet api pkg proxylib envoy plugins bpf cilium daemon monitor cilium-health bugtool
ineffassign .
contrib/scripts/check-logging-subsys-field.sh
contrib/scripts/check-fmt.sh
contrib/scripts/check-log-newlines.sh

I guess that's because go vet is using a cache. IMO we should somehow clean that cache or find a way to run go vet without caching.

Does running go clean -cache before running go vet in vagrant fix this?


Stealth Addresses - Question

Can this library be used to create stealth addresses as we see in Monero? I am not wanting to create a Monero app with this library but I do have an idea where stealth addresses can be useful outside of cryptocurrency.

No, there is no support for Monero stealth addresses in NSec.


implement createChannels

Why: Problem description :confused:
We want a createChannels method that is responsible for ensuring that a channel gets created.
The createChannels method should be added to a new ChannelManager. This method should use the messageService and ensureObjectives to make sure the objectives get created.

https://github.com/statechannels/statechannels/pull/3376#discussion_r595700510 has some relevent discussion.


Handle cookies without domain

Site walmart.com gives me following cookie in a response:
{'name': '_pxhd', 'value': '6da00bf937626ff8e5125263e11febead5a84e296de76905d65a533b8530821f:87aed865-d524-11ed-91eb-5a4a65507666', 'path': '/', 'expires':<PHONE_NUMBER>, 'httpOnly': False, 'secure': False}

Because there's no domain key, it raises an exception:
Traceback (most recent call last):
  File "/home/mariusz/Documents/Praca/majornetlocs-venv/lib/python3.10/site-packages/twisted/internet/defer.py", line 1656, in _inlineCallbacks
    result = current_context.run(
  File "/home/mariusz/Documents/Praca/majornetlocs-venv/lib/python3.10/site-packages/twisted/python/failure.py", line 489, in throwExceptionIntoGenerator
    return g.throw(self.type, self.value, self.tb)
  File "/home/mariusz/Documents/Praca/majornetlocs-venv/lib/python3.10/site-packages/scrapy/core/downloader/middleware.py", line 49, in process_request
    return (yield download_func(request=request, spider=spider))
  File "/home/mariusz/Documents/Praca/majornetlocs-venv/lib/python3.10/site-packages/twisted/internet/defer.py", line 1030, in adapt
    extracted = result.result()
  File "/home/mariusz/Documents/Praca/majornetlocs-venv/lib/python3.10/site-packages/scrapy_zyte_api/handler.py", line 220, in _download_request
    return _process_response(api_response, request, self._cookie_jars)
  File "/home/mariusz/Documents/Praca/majornetlocs-venv/lib/python3.10/site-packages/scrapy_zyte_api/responses.py", line 178, in _process_response
    _process_cookies(api_response, request, cookie_jars)
  File "/home/mariusz/Documents/Praca/majornetlocs-venv/lib/python3.10/site-packages/scrapy_zyte_api/_cookies.py", line 37, in _process_cookies
    domain=response_cookie["domain"],
KeyError: 'domain'

Looks good to me, I think we can merge as soon as we cover this with a test.

@Gallaecio looks like testing cookies with different possible values is not thoughtfully unit-tested and would require a refactor. For now just added a domain-less cookie to the default input list of cookies in 4b4cde3ee889efb82d1d63e538a9b018dc23511d.

No worries, I am already working on a proper test for the cookie jar part.

When can it be merged and released?

We’ll prepare a release with the change. Thanks!


Feature: ACL extension

New symbol ? could be used in broker's ACLs to allow client subscribe to any single branch of subtree at the moment but not to the whole subtree section. For instance, we've got the following topic tree:
        a
      /   \
   b1       b2
  /  \     /   \
c1   c2   c1    c2

Let's compare effect of two ACL rules:

{allow, {user, "test"}, subscribe, ["a/+/c1"]}.
{allow, {user, "test"}, subscribe, ["a/?/c1"]}.

Using rule 1 client will be able to subscribe a/b1/c1 and a/b2/c1 subtrees automatically, so all the b-level structure will be available to the client. There are some situations when you don't want to expose all the tree structure but at the same time allow clients to subscribe any specified subtopic on the c-level. Here we propose rule 2: client can subscribe e.g to a/b1/c1 or to a/b2/c1, or to the both separately, but not to a/+/c1 and if there is branch a/b3/c1 information from it will not be available to the client until he explicitly subscribe to the branch.

@dgtony, Thanks, I will check the PR later.

@dgtony
I think this can brake a BC: consider you have a topic with "?" as a level e.g. "a/?".
To circumvent this situation we can use a combination of "+" and another sign for example "!+" (everything except plus). This will not brake a BC because a plus sign can only appear together with a "/" sign, except you have no topic tree at all (this case can also be handled).


fix(angularInit): allow auto-bootstraping from inline script

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Bug fix.
What is the current behavior? (You can also link to an open issue here)
Some browsers (e.g. Safari 9.x, PhantomJS) do not set link.origin/protocol correctly, when setting link.href to null, which prevents auto-bootstraping Angular from scripts without a src attribute (i.e. inline scripts).
See also #15567.
What is the new behavior (if this is a feature change)?
Auto-bootstraping Angular from inline scripts is allowed.
Does this PR introduce a breaking change?
No.
Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

Other information:
Inline scripts are on the same origin as the loading page, so auto-bootstraping
should be allowed.
Fixes #15567.

cc @mprobst


Wrong Focused Window Border comment

Thanks for your chadwm, looks great.
While I was trying to tweak nord, gruvchad colorscheme header file, I found that blue[ ] has been commented as focused window border.
But changing gray4[ ] changes the focused window border.

Hello! So, i don't know if you solved the problem already, but here is the explanation and solution:
The actual color scheme referred to the focus and unfocused window is this tag:
[SchemeSel]
You can find it in config.def.h file inside the *colors[][3] variable. If you pay attention in there, you may see that both the foreground and the border are defined as gray4.  Here is how it looks like in the code:
                // fg   // bg  // border (the one that should be blue)
*[SchemeSel] = { gray4, blue,  gray4  },*

So, to "solve" this you simply need to change the third value from gray4 to blue, or to any color you want to be the border scheme.

@alokshandilya oh sorry that was intended! I made that change for myself but mistakenly commited it.


[BC breaking] fix issue with VCTK dataset

relates to #483

Added a note that this is BC-breaking since it changes the layout of the dataset.

By the way, this issue is also arising with some of the other datasets. It would be a good idea to update the others too.

The error appears to be due to not having rebased, which will happen automatically. I will go ahead and merge.


refactor: drastically improve mypy compatibility

About
This pull request fixes errors that mypy brings up.
(Draft until somewhen)
Checklist

[x] The pre-commit code linter has been run over all edited files to ensure the code is linted.
[x] I've ensured the change(s) work on 3.8.6 and higher.


Context menu not working with element without value

I have data grid with some empty cells and I need to be able to open context menu for those cells too. Problem is that context menu works fine for cells with some value, but not for those without value.
This works:

VS

Not working:

Solved the issue with non-breaking space.

When the element the context-menu is attached to has no "size" (such as when there's no text inside), there's really no way to "click" that element. If you look at it under Inspect Element, it normally wont show at all. Adding a non-breaking space makes the containing div/p have a size which you can click/right-click onto.


feat: add create auction v2 transaction

:tada: This PR is included in version 4.3.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


WIP Feature/add imputed countries of interest fields

Description of change
Checklist

[ ] Has a new newsfragment been created? Check changelog/README.rst for instructions
[ ] Do any added or updated endpoints appear in the API documentation? See docs/Maintaining the API documentation.md for more details
[ ] Have any relevant search models been updated?
[ ] Have any relevant fixtures (fixtures/test_data.yaml) been updated?
[ ] Have any relevant select-/prefetch-related field lists in the views and search apps been updated?
[ ] Has the admin site been updated (for new models, fields etc.)?
[ ] Has the README been updated (if needed)?

I appreciate it's a bit late in the process to ask this questions, but.... Is "imputed" really the term we want?

impute | ɪmˈpjuːt |
verb [with object]
1 represent (something, especially something undesirable) as being done or possessed by someone; attribute: the crimes imputed to Richard.
2 Finance assign (a value) to something by inference from the value of the products or processes to which it contributes: (as adjective imputed) : recovering the initial outlay plus imputed interest.

@mcbhenwood No it's not too late... maybe "reputed" is a better fit?
Also, yes this is indeed basically a prototype. We can break it into smaller commits -- I don't think you'll be disappointed with the test coverage!

I would like to review this but I have no context of why we are making this change. Can you please put something in the PR description? Thanks 🙏


Right click on an element of the interface does not work as expected

Godot version
4 beta 11
System information
Linux 64 bits (Manjaro)
Issue description
When right clicking on a node in the Scene Tree (or any other part or the interface with right click abilities) to perform an action from the popup menu, if the menu appears under the cursor, the menu entry below the cursor is "clicked" in the same event instead of reacting to a left click later.
This does not happen every times and depends highly on the position of the cursor in the popup menu but as I have my Scene Tree on the right side of the interface, the popup menu often appears under the mouse cursor. It's very annoying as it can select the "cut" command for example and I have to do Ctrl + Z to restore the deleted node and do the right click again. Sometimes it takes me 3 or 4 attempts to achieve what I was looking for!
When the popup menu is not under the cursor, it behaves like normal. I suspect the problem to be reproductible on any part of the interface (I spoted it in the Inspector as well), but there is some little chances to have the popup under the mouse cursor for the other parts of the interface (unless if we mess with it).
I saw this "bug" in the beta 10 as well, but as there is a lot of bugs reported already I though someone else would have spoted it and fixed it already.
If this is a double of another reported bug, I'm really sorry, I tried to find it in the reported issues, but there is really a lot of issues with the keywords "right click", "mouse buton" or other combinations.
Steps to reproduce
1°) Ensure the Scene Tree is on the right side of the interface (or the Inspector, but there is less chances to make it appear).
2°) Add an instance of a node not a standard node (as there is more entries in the popup menu this way).
3°) Make the scene tree width small to allow the popup menu to pop under the mouse cursor when right clicking a node.
4°) Right click a node (sometimes it does not "select" a menu entry as the mouse cursor could be over a separator).
I can provide a video if required.
Minimal reproduction project
None

It appears you may have encountered a feature of PopupMenu that allows you to select an item with the release of the mouse button, when the press of that event caused the popup to open.
This allows you to open a popup menu, slide your mouse while pressed to the item you want to select, and then release to select it. If you release faster than 150ms since the 'button down' event, this behaviour is skipped.
I'm not sure how common this functionality is in other applications - I certainly don't use it. And I wonder if it causes confusion more than it is helpful, as it is not well documented (as far as I know), and is kind of hard to document in a good place.
https://github.com/godotengine/godot/blob/master/scene/gui/popup_menu.cpp#L395-L397

Wow! After more than 25 years in the computer industry, I never saw that! O.o
Is there a way to deactivate this unintutive behavior? I didn't find anything in the settings...

Wow! After more than 25 years in the computer industry, I never saw that! O.o Is there a way to deactivate this unintuitive behavior? I didn't find anything in the settings...

This feature is present on macOS and most Linux desktop environments. Windows has never followed suit though.

I'm not using Windows and I never have seen this "feature" under Linux either (27 years under Linux).

we should refrain from adding a setting for everything

Surely allowing to disable this particular thing would be a must have for everyone not using this as it is counter intuitive.
This is really annoying when you are not familiar with.

Can you reproduce this in 3.5.1?

Can you reproduce this in 3.5.1? This may determine where it's actually a bug.
It does not act weirdly in Godot 3.5.1 (I wasn't able to reproduce).

also try enabling Single Window Mode in the Editor Settings in 4.0.beta.
Once I checked the Single Window Mode in Godot 4.0 beta, I was unable to get the "bug" anymore...

Here is a video showing the difference between the 2 modes:
https://user-images.githubusercontent.com/102065761/212202388-a98910ce-24b2-4e6e-8258-78c92d9151f8.mp4
When I right click on the nodes in my Scene Tree, I never click on the left button, all I do is normally right clicking on the node, expecting the popup menu to show up, as it does when the Single Window Mode is set. Then I press Escape to close the popup menu when it is not already closed by an auto-select-weird-feature :D

In your video, when the popup menu does not close instantly, but instead lingers for a bit, is that you holding down the right mouse button?

Nope, it is mostly because the mouse pointer is not over a clickable item (separation or between 2 buttons for example). Sometimes the popup menu is displayed outside of the mouse pointer too, so it does not "click" an item neither.
As I said, all I do in this video is making a simple right click without maintaining the mouse button. I try to make the popup menu to act normally (as you can see it working when the Single Window Mode is activated).

After more investigations, I'm able to state this fact (when I deactivate the Single Window Mode):

The auto-click behaviour only happens when I'm using more than 1 monitor (if I set my config to only use 1 monitor or to use multiple ones in mirror mode, the problem disapears, but if I'm using 2 or more monitors, the problem arises).

I also tested it with an USB mouse and the pad of my laptop and both devices trigger the auto-click when conditions are met.
My system is an Asus ROG Strix (laptop) plugged to another monitor and external keyboard / mouse.
My OS is Manjaro Linux 64 bits and I use XFCE desktop with a compositing manager on top of it (Compiz Fusion). I didn't noticed this behaviour on another application / software I use, only in Godot 4.0 betas and in particular conditions (I only noticed this since beta 10, never encountered it in previous betas, but maybe the conditions where not met, like my Scene Tree was maybe smaller and the popup menu always appeared below the mouse pointer, I don't know).
Working on battery or plugged in the wall is the same thing
I'll test it without the compositing manager when I can and report back the result as well.
I hope this helps to understand what is happening.

OK, sounds like it is not the popup menu feature that causes the issue then? Thanks for your detailed info.

I don't think so as when I use the Single Window Mode, all is fine...

Well, after more investigations and tests, I managed to make it happen totally outside of Godot (Godot wasn't even started)!
So we can close this "bug" as it is not related to Godot but more likely to my system. I'm really sorry for the false alarm here. I will simply keep the Single Window Mode active for now.
And as EricEzaM mentioned, it is indeed related to the right-click-popup feature as when I maintain the right mouse button pressed it never occurs... I discovered this feature on my system as well, thanks Calinou to have pointed it out for the Linux OS, I wasn't aware of this :D.
Again sorry to have wasted your time guys.

No worries! Glad you figured it out

Though this issue was closed, I was coming to report the same thing so I hope you won't mind if I do it here :)
Linux Mint 20 Cinnamon (4.6.7), Godot 4.2 beta 1
rightclickmenu71242.webm
There is a small delay before the menu actually appears and becomes interactive, which eats up the 150ms grace period (mentioned above https://github.com/godotengine/godot/issues/71242#issuecomment-1379517804). In the video you can see how the menu drop shadow appears first, then the menu itself. I inserted a print into a custom build to show the delay time (diff) each click, and in a small test where I clicked then release the mouse as fast as I could, I measure diff to average about 200ms.
Solution suggestions (in order of decreasing favourability):

only start counting time from when the menu actually appears (ie. when it can start accepting input); or
ensure the menu pops up slightly away from the mouse so no item is immediately under it; or
increase the threshold time to something like 250ms to compensate.

Note: I also find this doesn't happen in single-window mode, probably(?) because it can show the menu and start processing input without delay.

Did you follow the conversation and the resolution? If this is the same issue it isn't a Godot issue but a platform issue

@tom-jk Do you have an nVidia card and do you use multiple monitors by hasard?
It exists a bug in the nVidia drivers when using multiple monitors on Linux. They are working on it, but I think the issue you have (and I still have as well) is related to that. The delays you mention are caused by the Graphic Card struggling when heavy load is put on the GPU. This is why the problem only (mostly) occurs to me when using Godot, as it is heavier than my other apps on the GPU.
If you don't have an nVidia card, then I don't know what can be the cause.
The solution I found that is working for me is to use the "Single Window Mode" for Godot for now.
Hope this helps.

A menu item accidentally being selected immediately: I did get this to happen in other apps, such as the file explorer.
The menu appearing after a delay: of the apps I looked at, I only saw this in Godot.[^1]
The 150ms no-click period was added in #42173, and the pull description indicates this was in part to mitigate a linux/x11 issue. The duration was originally 100ms, but was later increased to 150ms in #55766. This replaced an earlier guard against accidental clicks (#17809 with a mouse-movement threshold).
All that's to say, is that it's sort-of a platform issue, but there's precedent for mitigations inside Godot.
TheRealSlander: I've got an nvidia rtx 2060 super, and only one monitor, at 1440x900. In terms of gpu workload, if I watch nvidia-smi's output in a terminal while bringing up the context menu in Godot, I see only a very small load on each click.
[^1]: I guess the delay before appearing is because the menu is itself a Godot window rather than a system menu, and it takes time to initialise Godot rendering stuff for a new window? (I also considered the delay might be for a menu popup animation so I turned off system animation effects to check, but no change.)