Document TRNG REQ HW API timing requirements

In Caliptra_Integration_Specification.pdf, section 8 (TRNG REQ HW API) doesn't mention timing requirements at all. These need to be documented explicitly.
We need to know the upper bound on how long this operation can take in order to set watchdog timeouts correctly.

Kor Nielsen (Google)
[7 minutes ago]
Now that the watchdog is configured externally this isn't as important.
However, we probably need to document the hard coded timeout for etrng requests. Constant is here: https://github.com/chipsalliance/caliptra-sw/blob/df44c09aab24fc72010cce83507cbab1c9e04928/drivers/src/trng_ext.rs#L18
    const MAX_CYCLES_TO_WAIT: u32 = 250000;


The loom is missing the crafting fail sound.

On the PS4 Edition, it's supposed to play that sound when you don't have enough stuff for the loom.
https://github.com/Wilyicaro/Legacy-Minecraft/assets/39068731/473c61f8-7101-4ac7-92bd-8555778cfc6c

There is currently no such sound as it was not played on the Xbox 360 Edition, thankfully they added it in PS4 Edition


Incorrect hint from analyzer

[hint] The argument type 'CapturedVariable' cannot be assigned to the parameter type 'Element' (.../dart/sdk/lib/_internal/compiler/implementation/inferrer/simple_types_inferrer.dart, line 469, col 36)
The above hint isn't correct. The code is untyped, and there exist types that implement both Element and CapturedVariable.

Assumed stale.


Sign all dlls in one task in builds

See: https://github.com/AzureAD/microsoft-identity-web/pull/2571
ESRP code signing task should sign all the dlls in one task.

completed


[edn/doc] topology diagram to show all endpoint buses as 32b

Signed-off-by: Mark Branstad<EMAIL_ADDRESS>

sorry Mark i keep on forgetting.  But if we fix the number of end points, is the edn bit-width parameterizeable? Or was it the other way around?

@tjaychen we decided on a variable number of endpoints with a fixed bus width, and choose 32b as a happy medium point. The assumption is that if an endpoint needs more or less bits per request, they can use the prim_packer_fifo to upscale/downscale the bits within the endpoint module.

sounds good.
Thanks Mark.
On Fri, Dec 4, 2020 at 7:02 AM mwbranstad<EMAIL_ADDRESS>wrote:

@tjaychen https://github.com/tjaychen we decided on a variable number
of endpoints with a fixed bus width, and choose 32b as a happy medium
point. The assumption is that if an endpoint needs more or less bits per
request, they can use the prim_packer_fifo to upscale/downscale the bits
within the endpoint module.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/lowRISC/opentitan/pull/4408#issuecomment-738832032,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH2RSXL6KPLE67MFKKJDGTSTD2X5ANCNFSM4UMP45FQ
.

@tjaychen hey Tim, if that works, can you approve this small PR?


Add a double-precision editor build to CI

This PR fixes enough of Godot's code so that it compiles with float=64 again and adds a double-precision editor build to the CI. Some of the code changes are for the OpenGL support, some are in the text server, and some are in GLTF. Once this is in CI, this will check float=64 for every commit so that it will keep compiling.

A common request is to combine it with one of the existing cicd builds, but will wait for that request.

<Akien> Adds another build to CI, which will make CI slower. I haven't assessed in detail yet.

I think we need to keep the number of builds the same.

For nonstandard builds, I would probably look at moving them to a separate CI workflow that run according to a weekly schedule. This way, we don't have to worry about stealing CI time from other commits and pull requests.

The point is to prevent merges that fail this test and have the contributors attend to the breakage. Having them be non fatal would defeat this goal.

@akien-mga Done, it's now modifying that build.

Thanks!

Floats in GDScript are always double-precision, but packed arrays can store either 32-bit or 64-bit floats in Godot 4.0. In Godot 3.x, PoolRealArray always stores 32-bit floats.

Scalar floats in GDScript are always double-precision, but packed arrays can store either 32-bit or 64-bit floats in Godot 4.0 (PackedFloat32Array vs PackedFloat64Array). In Godot 3.x, PoolRealArray always stores 32-bit floats. The same thing applies to packed/pooled integer arrays.

Ok good to know. Thank you for the very insightful reply :)


bug fix - kerberos authentication

Hello,
There were some issues with the Kerberos authentication.
However the fix only works on the newest impacket version. The minimum version present in pip and used by default (0.11.0) has an issue that has been fixed here: https://github.com/fortra/impacket/pull/1648.
The changes don't affect the standard LDAP authentication.

Seems like I forgot to test this altogether!
Thanks for the fix.


PipeCompletionCallbacks are root the state object even after callback executes

I need to look at a dump to see what is rooting the PipeCompletionCallbacks itself but it was making kestrel fail. I had to work around it like this https://github.com/aspnet/KestrelHttpServer/blob/7854c0604a3e6e50a0bea84c4fa9d9e6ca5d7057/src/Kestrel.Core/Internal/HttpConnectionMiddleware.cs#L71-L91.
/cc @pakrym

It looks like the PipeCompletionCallback isn't being cleared before returning to the array pool.
(lldb) gcroot 00007fcc5c5c97b8
HandleTable:
    00007FCDE69B15C8 (pinned handle)
    -> 00007FCCDC007CD0 System.Object[]
    -> 00007FC8DC087670 System.Buffers.ConfigurableArrayPool`1[[System.IO.Pipelines.PipeCompletionCallback, System.IO.Pipelines]]
    -> 00007FC8DC0A3688 System.Buffers.ConfigurableArrayPool`1+Bucket[[System.IO.Pipelines.PipeCompletionCallback, System.IO.Pipelines]][]
    -> 00007FC8DC0A3728 System.Buffers.ConfigurableArrayPool`1+Bucket[[System.IO.Pipelines.PipeCompletionCallback, System.IO.Pipelines]]
    -> 00007FC8DC0A3758 System.IO.Pipelines.PipeCompletionCallback[][]
    -> 00007FC8DC087980 System.IO.Pipelines.PipeCompletionCallback[]
    -> 00007FC8DC22FA50 Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.LibuvOutputConsumer
    -> 00007FC8DC221FB8 Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.Networking.UvTcpHandle
    -> 00007FC8DC222030 Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.LibuvConnection
    -> 00007FCC5C5C97B8 Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv.Internal.ListenerPrimary


[Docs] typo in readme

Documentation link: https://github.com/fidelity/theliv/blob/main/readme.md
Description:
Finally theliv aims to be an extensible framework where custom checks can be plugged in whereever required.
Change whereever to wherever

I will work on this and submit PR later


Add New Monokai Pro Theme

I'm pretty new to the emacs community, but started using Doom recently (introduced to it by Doom Themes) and have loved it. I created these three themes for myself that I rotate through depending on my mood. Wondering if any of these are worth adding in?
doom-monokai-pro

edit: removed other two themes

I'm not so sure about atom-dark -- it seems too similar to doom-one or doom-vibrant (both of which are based off of atom one dark). monokai and xcode would be welcome additions though.

It would be better to create separate PRs though. Did you based the themes on their official palettes?
If I'm not wrong, Monokai was requested quite sometime ago so it would be a great addition.

Sure, I'll move doom-xcode to a separate PR.
I based Monokai based on their official palette, except for the different background color which I set darker than what they use.
I couldn't find an official palette for the xcode theme, so I used a tool to inspect xcode and pull the RGB values.

@kadenbarlow I would think it's better to change Monokai's background to match the original one from the spec, just for the sake of keeping it as similar to the original as possible. I'll test it and use it to check all the faces work ok and that there's no contrast problems. Then if everything's ok I'll merge it! Thanks!

@ema2159 Sounds great. I updated the theme to match the Monokai Pro background and made a couple of other small tweaks so the theme more closely matches Monokai Pro. https://monokai.pro/vscode.
Let me know if any faces need tweaking and I can make changes. Thanks!

Quick question. Where did you grabbed the colors? Or how did you probed them?

On this site https://monokai.pro/.
MacOS has a digital color meter tool that I used to grab the values. For the actual background color I downloaded the theme in VS Code and inspected it there.

Hi.
What about all the different flavors of monokai-pro? Like Spectrum, Ristretto and so one. I'd love to see them in doom as well. I could create PR's for them if you'd like me to.

Go ahead! We're reviewing this current one so it may take some time

Go ahead! We're reviewing this current one so it may take some time

Hi @ema2159 . I've created a first "beta". It's not ready for a PR yet.  I've added
(package! doom-monokai-pro-spectrum-theme
  :recipe (:host github :repo "minikN/doom-emacs-monokai-pro-spectrum"))

into my packages.el and (setq doom-theme 'doom-monokai-pro-theme) into my config.el.
This is what I get: condition-case: Error in a Doom startup hook: doom-init-theme-h, (error "Unable to find theme file for ‘doom-monokai-pro-theme’")
After looking @ @kadenbarlow  theme. I suspect it's not quite accurate. As far as I know every Monokai Pro flavor/filter only provides 6 colors (Apart from black to white of course): red, yellow, orange, green, purple, cyan.
For example for the spectrum filter that would be:
#fc618d - red
#7bd88f - green
#fd9353 - orange
#fce566 - yellow
#948ae3 - purple
#5ad4e6 - cyan
As far as I know every other color is just a darkened/lightened variant of the above, like this one:

So I'm wondering where @kadenbarlow got his colors from especially pink and red as there should be only one of the two.
Cheers.

@minikN You'll notice that red is used for the vc-deleted face, not for any of the syntax highlighting. I think that red is a good indicator of deleted lines in version control and green is good for additions in version control. Also, I agree with @ema2159 It can be hard to get a consistent look across different modes. I tried to get a good balance of matching Monokai and getting a good contrast between colors in the different modes that I tried out.

@minikN You'll notice that red is used for the vc-deleted face, not for any of the syntax highlighting. I think that red is a good indicator of deleted lines in version control and green is good for additions in version control. Also, I agree with @ema2159 It can be hard to get a consistent look across different modes. I tried to get a good balance of matching Monokai and getting a good contrast between colors in the different modes that I tried out.

Alright. That clarified it. Would you be able to give an example where Monokai Pro varies between different modes? At least for JS and PHP I haven't noticed that.
Regardless, I would still recommend sticking to the original as close as possible. Monokai Pro uses #ff6188 and #a9dc76 (both with an alpha of 0.19 and 0.26) for version control (at least the VSCode implementation).

Go ahead! We're reviewing this current one so it may take some time

Hi @ema2159 . I've created a first "beta". It's not ready for a PR yet.  I've added
(package! doom-monokai-pro-spectrum-theme
  :recipe (:host github :repo "minikN/doom-emacs-monokai-pro-spectrum"))

into my packages.el and (setq doom-theme 'doom-monokai-pro-theme) into my config.el.
This is what I get: condition-case: Error in a Doom startup hook: doom-init-theme-h, (error "Unable to find theme file for ‘doom-monokai-pro-theme’")

@ema2159 Would you be able to help with that?

@minikN of course, I'll just need sometime. I'm a little busy with my new job but as soon as I can I'll lend you a hand.

@minikN wrt
(package! doom-monokai-pro-spectrum-theme
  :recipe (:host github :repo "minikN/doom-emacs-monokai-pro-spectrum"))

There are two problems with the theme's definition:

Here, you've named the theme monokai-pro-spectrum,
But here, you've announced it as doom-monokai-pro-spectrum

Try removing the provide line entirely (def-doom-theme provides the theme for you), and replace:
-(def-doom-theme monokai-pro-spectrum
+(def-doom-theme doom-monokai-pro-spectrum

@minikN Oh, I forgot to mention a third issue: you need to add the theme's directory to custom-theme-load-path somewhere in the file. e.g.
;;;###autoload
(add-to-list 'custom-theme-load-path (file-name-directory load-file-name))

@minikN wrt
(package! doom-monokai-pro-spectrum-theme
  :recipe (:host github :repo "minikN/doom-emacs-monokai-pro-spectrum"))

There are two problems with the theme's definition:

Here, you've named the theme monokai-pro-spectrum,
But here, you've announced it as doom-monokai-pro-spectrum

Try removing the provide line entirely (def-doom-theme provides the theme for you), and replace:
-(def-doom-theme monokai-pro-spectrum
+(def-doom-theme doom-monokai-pro-spectrum

Thank you @hlissner. I will try this tonight.
Is there any guideline as to how specific a theme should be? I'm talking about mode-specific faces.
Monokai Pro is pretty specific in how it highlights syntax for various modes.  As I said some modes, in my case PHP mode didn't even support all the faces needed to implement Monokai Pro properly until I created a PR for it.
I have a local repo for Monokai Pro in which I've added several new faces to PHP mode based on my PR:
´´´
;;;; php-mode
(php-block-delimiter				 :foreground fg-3)
(php-block-statement				 :foreground red)
(php-class-declaration-spec 			 :foreground red)
(php-class-modifiers 			 :foreground red)
(php-constant-assign 			 :foreground red)
(php-constant-keyword 			 :foreground purple)
(php-flow-control-statement			 :foreground red)
(php-import-declaration 			 :foreground red)
(php-include-statement 			 :foreground green)
(php-method-access				 :foreground red :slant italic)
(php-method-modifiers			 :foreground red :slant italic)
(php-method-static				 :foreground red :slant italic)
(php-namespace-declaration			 :foreground red)
(php-number					 :foreground purple)
(php-php-tag 				 :foreground orange)
(php-print-statement				 :foreground green)
(php-property-access 			 :foreground red :slant italic)
(php-property-const				 :foreground red :slant italic)
(php-property-static				 :foreground red :slant italic)
(php-string-quote				 :foreground fg-3)
(php-type-operator				 :foreground red)
(php-function-keyword 			 :foreground blue :slant italic)
(php-function-name				 :foreground green)
(php-function-call				 :foreground green)
(php-string 					 :foreground yellow)
(php-keyword 				 :foreground blue)
(php-builtin 				 :foreground purple)
(php-method-call 				 :foreground green)
(php-static-method-call 			 :foreground green)
(php-variable-name 				 :foreground fg)
(php-property-name 				 :foreground fg)
(php-variable-sigil 				 :foreground fg-2)
(php-operator                                 :foreground red)
(php-paamayim-nekudotayim 			 :foreground red)
(php-type 					 :foreground blue :slant italic)
(php-class 					 :foreground red)
(php-constant 				 :foreground purple)
(php-constant-assign 			 :foreground blue)
(php-magical-constant 			 :foreground purple)
(php-$this 					 :foreground fg-2 :slant italic)
(php-$this-sigil				 :foreground fg-2 :slant italic)
(php-errorcontrol-op 			 :foreground red)
(php-doc-annotation-tag 			 :foreground blue)
(php-doc-variable-sigil 			 :foreground fg-4)
(php-doc-$this 				 :foreground fg-4)
(php-doc-$this-sigil 			 :foreground fg-4)
(php-doc-class-name 				 :foreground fg-4)
´´´
So my question is whether or not there is a threshold as to how fine grained a theme should be.
Thanks.

So my question is whether or not there is a threshold as to how fine grained a theme should be.

It can be as fine grained as you like, so long as you avoid properties that could throw errors, e.g. :font or :family when the specified font is missing on the user's system.
That said, I wasn't aware of php-mode's faces, perhaps they should be added to doom's base theme as well, so all themes can provide rudimentary support for the mode.

So my question is whether or not there is a threshold as to how fine grained a theme should be.

It can be as fine grained as you like, so long as you avoid properties that could throw errors, e.g. :font or :family when the specified font is missing on the user's system.
That said, I wasn't aware of php-mode's faces, perhaps they should be added to doom's base theme as well, so all themes can provide rudimentary support for the mode.

Thank you @hlissner . Well as I said, https://github.com/emacs-php/php-mode/pull/594 is merged already, however https://github.com/emacs-php/php-mode/pull/606 is still in review.
Unfortunately, I'm still stuck with loading the theme. I applied the changes you mentioned.
If I now repace (setq doom-theme 'doom-one) with (setq doom-theme 'doom-monokai-pro-spectrum) in config.elI get this: condition-case: Error in a Doom startup hook: doom-init-theme-h (wrong-type-argument stringp nil).

@minikN That likely means load-file-name in (file-name-directory load-file-name) is nil. Change it to
;;;###autoload
(when (and (boundp 'custom-theme-load-path) load-file-name)
  (add-to-list 'custom-theme-load-path
               (file-name-as-directory (file-name-directory load-file-name))))

@minikN That likely means load-file-name in (file-name-directory load-file-name) is nil. Change it to
;;;###autoload
(when (and (boundp 'custom-theme-load-path) load-file-name)
  (add-to-list 'custom-theme-load-path
               (file-name-as-directory (file-name-directory load-file-name))))

This worked. Thanks!

I improved the palette and theming overall. It should look almost the same as VS Code's.

@ema2159 thanks for making those changes. Sorry been super busy at work the past week or so.

@kadenbarlow don't worry. Thanks for contributing!


Unit tests for NEBM neuron model

The NEBM neuron model for the QUBO solver does not contain any unit tests to validate its behavior. It has been tested as part of the solver but has not been tested as an individual neuron. I would like to have unit tests to validate the behavior and be sure that things have not broken when I modify the microcode

[ ] create unit test to see if the neuron compiles
[ ] create unit test to check evolution of state variable in the neuron model


[C1-DR1/2/3] Add recording callback and store audio files in specific folder

Features added:

Add recording callback for Twilio calls
Add naming of audio files based on meetingId
Add additional check on server start to create Recordings folder if does not exist

Additionally store audio files in this folder

LGTM


feat: add epub support

Adds support for .epub documents.
To test, run yarn test:single -t epub

Thanks, I rebased to fix the yarn.lock conflict.

This isn't working:

@ardsh


Improve modules support

This pull request is a rework of https://github.com/go-debos/fakemachine/pull/36, hence deprecates it.
It brings two additions in the way fakemachine handles kernel module:

Support the file modules.builtin (if present), so that when some of the modules that fakemachine needs are built in the kernel, fakemachine doesn't fail trying to copy it. This is needed in latest version of Ubuntu and ArchLinux, where the virtio modules are now builtin.
Support for xz-compressed modules. This is needed for ArchLinux.

Reworked and merged in #47, hence closing :-)


some characters does not have the namegachasplash image property

why do some characters does not have the namegachasplash property in images?

which characters?

lumine

oh i see, understandable

It's because you can't roll lumine or aether from the gacha...
also I couldn't find their portraits in the images I have.


MCEM issues

two things:

optim doesn't like -Inf as objective fun value; probably just replace -Inf in MCEM cCalc_E_llk$run() with -1e307.

for this example, it's not moving away from starting point. Works if use Nelder-Mead instead of BFGS.  Need to investigate.

consts <- list(G = 2,N = 16, n = matrix(c(13, 12, 12, 11, 9, 10,
9, 9, 8, 11, 8, 10, 13, 10, 12, 9, 10, 9, 10, 5, 9, 9, 13,
7, 5, 10, 7, 6, 10, 10, 10, 7), nrow = 2))
data = list(r = matrix(c(13, 12, 12, 11, 9, 10, 9, 9, 8, 10, 8, 9,
12, 9, 11, 8, 9, 8, 9, 4, 8, 7, 11, 4, 4, 5, 5, 3, 7, 3, 7, 0),
nrow = 2))
inits <- list( a = c(2, 2), b=c(2, 2) )
codeReparam <- nimbleCode({
for (i in 1:G) {
for (j in 1:N) {
r[i,j] ~ dbin(p[i,j], n[i,j]);
p[i,j] ~ dbeta(mean = mu[i], sd = sigma[i])
}
mu[i] ~ dunif(0, 1)
sigma[i] ~ dunif(0, 1)
}
})
inits <- list( mu = rep(.5, 2), sigma = rep(.1, 2))
modelReparam <- nimbleModel(codeReparam, constants = consts, data = data, inits = inits)
box = list( list('mu', c(0, 1)), list('sigma', c(0, .5)))
modelReparam$simulate('p')
mcemReparam <- buildMCEM(modelReparam, latentNodes = 'p', burnIn = 500, boxConstraints = box)
outReparam <- mcemReparam(maxit = 30)
outReparam

Hi Chris,
I’ll chime in a little here, being the responsible party, but it might be a little late…

First of all, I’m not happy with R’s implementation L-BFGS algorithm. In particular, it immediately quits whenever the target function evaluates to -Inf, which seems very foolish. This issue is especially problematic for the L-BFGS with box-constraints, as the default behavior for some reason appears to evaluate the function at all corners of the box. I simply cannot fathom what went into this decision for the optimizer. Because often the target function is -Inf on the boundary, this often means that the standard BFGS (without box-constraints) is more likely to be successful than the optimizer with box constraints; if the target function is undefined at the boundary, the box constraints algorithm will fail 100% of the time. However, without the box-constraints, if you have a good initial value and never wander outside the boundary, the unconstrained BFGS algorithm should work.

 In general, R’s Nelder-Mead algorithm is much more stable; it allows for evaluations of the target function to be -Inf during the search. It can be very problematic if the solution is actually on the boundary though.

 To deal with this issue of R’s L-BFGS implementation, I actually “scoot” the box constraints in by epsilon (I think I set the default to 10^-5 or something)? This way when optim tries to evaluate the function in the corners, it should get a finite value.

 That being said, I’m actually confused what’s happening in this example. As I just mentioned, the box constraints should not be an issue for mu and sigma (and I even tried scooting it in even more to no avail). Also, when I tried debugging the R-version, some of the functions were not working correctly (although perhaps those were just issues with the R side, as it did compile, which was surprising given the R version’s errors). I can dig a little deeper on that.

  If I had more time, I would have half a mind to improve R’s optim functions…

-Cliff

On Mar 30, 2016, at 10:04 AM, Christopher Paciorek<EMAIL_ADDRESS>wrote:
two things:

optim doesn't like -Inf as objective fun value; probably just replace -Inf in MCEM cCalc_E_llk$run() with -1e307.

for this example, it's not moving away from starting point. Works if use Nelder-Mead instead of BFGS. Need to investigate.

consts <- list(G = 2,N = 16, n = matrix(c(13, 12, 12, 11, 9, 10,
9, 9, 8, 11, 8, 10, 13, 10, 12, 9, 10, 9, 10, 5, 9, 9, 13,
7, 5, 10, 7, 6, 10, 10, 10, 7), nrow = 2))
data = list(r = matrix(c(13, 12, 12, 11, 9, 10, 9, 9, 8, 10, 8, 9,
12, 9, 11, 8, 9, 8, 9, 4, 8, 7, 11, 4, 4, 5, 5, 3, 7, 3, 7, 0),
nrow = 2))
inits <- list( a = c(2, 2), b=c(2, 2) )
codeReparam <- nimbleCode({
for (i in 1:G) {
for (j in 1:N) {
r[i,j] ~ dbin(p[i,j], n[i,j]);
p[i,j] ~ dbeta(mean = mu[i], sd = sigma[i])
}
mu[i] ~ dunif(0, 1)
sigma[i] ~ dunif(0, 1)
}
})
inits <- list( mu = rep(.5, 2), sigma = rep(.1, 2))
modelReparam <- nimbleModel(codeReparam, constants = consts, data = data, inits = inits)
box = list( list('mu', c(0, 1)), list('sigma', c(0, .5)))
modelReparam$simulate('p')
mcemReparam <- buildMCEM(modelReparam, latentNodes = 'p', burnIn = 500, boxConstraints = box)
outReparam <- mcemReparam(maxit = 30)
outReparam
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub https://github.com/nimble-dev/nimble/issues/127

Oh I see what is wrong with this example. It’s a degenerate posterior distribution.
In particular, if X ~ beta(a, b), then the density at X = 1 is undefined if b < 1. This is exactly what is happening in this model (although it’s much harder to see due to the reparameterization). Since we have that r[1,3] / n[1,3] = 1, this means we can approach infinite density as p -> 1 by letting b -> 0.

On Apr 1, 2016, at 12:05 PM, Clifford Anderson-Bergman<EMAIL_ADDRESS>wrote:
Hi Chris,
I’ll chime in a little here, being the responsible party, but it might be a little late…

First of all, I’m not happy with R’s implementation L-BFGS algorithm. In particular, it immediately quits whenever the target function evaluates to -Inf, which seems very foolish. This issue is especially problematic for the L-BFGS with box-constraints, as the default behavior for some reason appears to evaluate the function at all corners of the box. I simply cannot fathom what went into this decision for the optimizer. Because often the target function is -Inf on the boundary, this often means that the standard BFGS (without box-constraints) is more likely to be successful than the optimizer with box constraints; if the target function is undefined at the boundary, the box constraints algorithm will fail 100% of the time. However, without the box-constraints, if you have a good initial value and never wander outside the boundary, the unconstrained BFGS algorithm should work.

 In general, R’s Nelder-Mead algorithm is much more stable; it allows for evaluations of the target function to be -Inf during the search. It can be very problematic if the solution is actually on the boundary though.

 To deal with this issue of R’s L-BFGS implementation, I actually “scoot” the box constraints in by epsilon (I think I set the default to 10^-5 or something)? This way when optim tries to evaluate the function in the corners, it should get a finite value.

 That being said, I’m actually confused what’s happening in this example. As I just mentioned, the box constraints should not be an issue for mu and sigma (and I even tried scooting it in even more to no avail). Also, when I tried debugging the R-version, some of the functions were not working correctly (although perhaps those were just issues with the R side, as it did compile, which was surprising given the R version’s errors). I can dig a little deeper on that.

  If I had more time, I would have half a mind to improve R’s optim functions…

-Cliff

On Mar 30, 2016, at 10:04 AM, Christopher Paciorek<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
two things:

optim doesn't like -Inf as objective fun value; probably just replace -Inf in MCEM cCalc_E_llk$run() with -1e307.

for this example, it's not moving away from starting point. Works if use Nelder-Mead instead of BFGS. Need to investigate.

consts <- list(G = 2,N = 16, n = matrix(c(13, 12, 12, 11, 9, 10,
9, 9, 8, 11, 8, 10, 13, 10, 12, 9, 10, 9, 10, 5, 9, 9, 13,
7, 5, 10, 7, 6, 10, 10, 10, 7), nrow = 2))
data = list(r = matrix(c(13, 12, 12, 11, 9, 10, 9, 9, 8, 10, 8, 9,
12, 9, 11, 8, 9, 8, 9, 4, 8, 7, 11, 4, 4, 5, 5, 3, 7, 3, 7, 0),
nrow = 2))
inits <- list( a = c(2, 2), b=c(2, 2) )
codeReparam <- nimbleCode({
for (i in 1:G) {
for (j in 1:N) {
r[i,j] ~ dbin(p[i,j], n[i,j]);
p[i,j] ~ dbeta(mean = mu[i], sd = sigma[i])
}
mu[i] ~ dunif(0, 1)
sigma[i] ~ dunif(0, 1)
}
})
inits <- list( mu = rep(.5, 2), sigma = rep(.1, 2))
modelReparam <- nimbleModel(codeReparam, constants = consts, data = data, inits = inits)
box = list( list('mu', c(0, 1)), list('sigma', c(0, .5)))
modelReparam$simulate('p')
mcemReparam <- buildMCEM(modelReparam, latentNodes = 'p', burnIn = 500, boxConstraints = box)
outReparam <- mcemReparam(maxit = 30)
outReparam
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub https://github.com/nimble-dev/nimble/issues/127

Cliff, thanks, your comments about L-BFGS-F mirror what I was seeing. My
thought for buildMCEM is that we set "nan" and "-Inf" to  -1e307 to deal
with the -Inf issue.  What do you think?
In terms of degeneracy, I don't think that is what is going on. I agree
that the MLE for p[i] would have an issue if r[i]/n[i]=1, but for the
marginal likelihood, we shouldn't get an (alpha,beta) or (mu,sigma) that
forces all p[i]=1 because some of the r[i]/n[i] < 1.  When I max the
marginal likelihood using the beta-binomial, I get mu = .89 and sd=.04 for
the first group.
So I'm still not sure what is going on with the MCEM...
On Fri, Apr 1, 2016 at 12:48 PM, Clifford Anderson-Bergman <
<EMAIL_ADDRESS>wrote:

Oh I see what is wrong with this example. It’s a degenerate posterior
distribution.
In particular, if X ~ beta(a, b), then the density at X = 1 is undefined
if b < 1. This is exactly what is happening in this model (although it’s
much harder to see due to the reparameterization). Since we have that
r[1,3] / n[1,3] = 1, this means we can approach infinite density as p -> 1
by letting b -> 0.

On Apr 1, 2016, at 12:05 PM, Clifford Anderson-Bergman <
<EMAIL_ADDRESS>wrote:
Hi Chris,
I’ll chime in a little here, being the responsible party, but it might
be a little late…
First of all, I’m not happy with R’s implementation L-BFGS algorithm. In
particular, it immediately quits whenever the target function evaluates to
-Inf, which seems very foolish. This issue is especially problematic for
the L-BFGS with box-constraints, as the default behavior for some reason
appears to evaluate the function at all corners of the box. I simply cannot
fathom what went into this decision for the optimizer. Because often the
target function is -Inf on the boundary, this often means that the standard
BFGS (without box-constraints) is more likely to be successful than the
optimizer with box constraints; if the target function is undefined at the
boundary, the box constraints algorithm will fail 100% of the time.
However, without the box-constraints, if you have a good initial value and
never wander outside the boundary, the unconstrained BFGS algorithm should
work.
In general, R’s Nelder-Mead algorithm is much more stable; it allows for
evaluations of the target function to be -Inf during the search. It can be
very problematic if the solution is actually on the boundary though.
To deal with this issue of R’s L-BFGS implementation, I actually “scoot”
the box constraints in by epsilon (I think I set the default to 10^-5 or
something)? This way when optim tries to evaluate the function in the
corners, it should get a finite value.
That being said, I’m actually confused what’s happening in this example.
As I just mentioned, the box constraints should not be an issue for mu and
sigma (and I even tried scooting it in even more to no avail). Also, when I
tried debugging the R-version, some of the functions were not working
correctly (although perhaps those were just issues with the R side, as it
did compile, which was surprising given the R version’s errors). I can dig
a little deeper on that.
If I had more time, I would have half a mind to improve R’s optim
functions…
-Cliff

On Mar 30, 2016, at 10:04 AM, Christopher Paciorek <
<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
two things:

optim doesn't like -Inf as objective fun value; probably just
replace -Inf in MCEM cCalc_E_llk$run() with -1e307.

for this example, it's not moving away from starting point. Works if
use Nelder-Mead instead of BFGS. Need to investigate.

consts <- list(G = 2,N = 16, n = matrix(c(13, 12, 12, 11, 9, 10,
9, 9, 8, 11, 8, 10, 13, 10, 12, 9, 10, 9, 10, 5, 9, 9, 13,
7, 5, 10, 7, 6, 10, 10, 10, 7), nrow = 2))
data = list(r = matrix(c(13, 12, 12, 11, 9, 10, 9, 9, 8, 10, 8, 9,
12, 9, 11, 8, 9, 8, 9, 4, 8, 7, 11, 4, 4, 5, 5, 3, 7, 3, 7, 0),
nrow = 2))
inits <- list( a = c(2, 2), b=c(2, 2) )
codeReparam <- nimbleCode({
for (i in 1:G) {
for (j in 1:N) {
r[i,j] ~ dbin(p[i,j], n[i,j]);
p[i,j] ~ dbeta(mean = mu[i], sd = sigma[i])
}
mu[i] ~ dunif(0, 1)
sigma[i] ~ dunif(0, 1)
}
})
inits <- list( mu = rep(.5, 2), sigma = rep(.1, 2))
modelReparam <- nimbleModel(codeReparam, constants = consts, data =
data, inits = inits)
box = list( list('mu', c(0, 1)), list('sigma', c(0, .5)))
modelReparam$simulate('p')
mcemReparam <- buildMCEM(modelReparam, latentNodes = 'p', burnIn = 500,
boxConstraints = box)
outReparam <- mcemReparam(maxit = 30)
outReparam
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub <
https://github.com/nimble-dev/nimble/issues/127>

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/nimble-dev/nimble/issues/127#issuecomment-204541111

also, Cliff, any reason I shouldn't include the option to use a different
optimization method (e.g.,Nelder-Mead) in buildMCEM()?
On Sat, Apr 2, 2016 at 5:31 AM, Chris Paciorek<EMAIL_ADDRESS>wrote:

Cliff, thanks, your comments about L-BFGS-F mirror what I was seeing. My
thought for buildMCEM is that we set "nan" and "-Inf" to  -1e307 to deal
with the -Inf issue.  What do you think?
In terms of degeneracy, I don't think that is what is going on. I agree
that the MLE for p[i] would have an issue if r[i]/n[i]=1, but for the
marginal likelihood, we shouldn't get an (alpha,beta) or (mu,sigma) that
forces all p[i]=1 because some of the r[i]/n[i] < 1.  When I max the
marginal likelihood using the beta-binomial, I get mu = .89 and sd=.04 for
the first group.
So I'm still not sure what is going on with the MCEM...
On Fri, Apr 1, 2016 at 12:48 PM, Clifford Anderson-Bergman <
<EMAIL_ADDRESS>wrote:

Oh I see what is wrong with this example. It’s a degenerate posterior
distribution.
In particular, if X ~ beta(a, b), then the density at X = 1 is undefined
if b < 1. This is exactly what is happening in this model (although it’s
much harder to see due to the reparameterization). Since we have that
r[1,3] / n[1,3] = 1, this means we can approach infinite density as p -> 1
by letting b -> 0.

On Apr 1, 2016, at 12:05 PM, Clifford Anderson-Bergman <
<EMAIL_ADDRESS>wrote:
Hi Chris,
I’ll chime in a little here, being the responsible party, but it might
be a little late…
First of all, I’m not happy with R’s implementation L-BFGS algorithm.
In particular, it immediately quits whenever the target function evaluates
to -Inf, which seems very foolish. This issue is especially problematic for
the L-BFGS with box-constraints, as the default behavior for some reason
appears to evaluate the function at all corners of the box. I simply cannot
fathom what went into this decision for the optimizer. Because often the
target function is -Inf on the boundary, this often means that the standard
BFGS (without box-constraints) is more likely to be successful than the
optimizer with box constraints; if the target function is undefined at the
boundary, the box constraints algorithm will fail 100% of the time.
However, without the box-constraints, if you have a good initial value and
never wander outside the boundary, the unconstrained BFGS algorithm should
work.
In general, R’s Nelder-Mead algorithm is much more stable; it allows
for evaluations of the target function to be -Inf during the search. It can
be very problematic if the solution is actually on the boundary though.
To deal with this issue of R’s L-BFGS implementation, I actually
“scoot” the box constraints in by epsilon (I think I set the default to
10^-5 or something)? This way when optim tries to evaluate the function in
the corners, it should get a finite value.
That being said, I’m actually confused what’s happening in this
example. As I just mentioned, the box constraints should not be an issue
for mu and sigma (and I even tried scooting it in even more to no avail).
Also, when I tried debugging the R-version, some of the functions were not
working correctly (although perhaps those were just issues with the R side,
as it did compile, which was surprising given the R version’s errors). I
can dig a little deeper on that.
If I had more time, I would have half a mind to improve R’s optim
functions…
-Cliff

On Mar 30, 2016, at 10:04 AM, Christopher Paciorek <
<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
two things:

optim doesn't like -Inf as objective fun value; probably just
replace -Inf in MCEM cCalc_E_llk$run() with -1e307.

for this example, it's not moving away from starting point. Works
if use Nelder-Mead instead of BFGS. Need to investigate.

consts <- list(G = 2,N = 16, n = matrix(c(13, 12, 12, 11, 9, 10,
9, 9, 8, 11, 8, 10, 13, 10, 12, 9, 10, 9, 10, 5, 9, 9, 13,
7, 5, 10, 7, 6, 10, 10, 10, 7), nrow = 2))
data = list(r = matrix(c(13, 12, 12, 11, 9, 10, 9, 9, 8, 10, 8, 9,
12, 9, 11, 8, 9, 8, 9, 4, 8, 7, 11, 4, 4, 5, 5, 3, 7, 3, 7, 0),
nrow = 2))
inits <- list( a = c(2, 2), b=c(2, 2) )
codeReparam <- nimbleCode({
for (i in 1:G) {
for (j in 1:N) {
r[i,j] ~ dbin(p[i,j], n[i,j]);
p[i,j] ~ dbeta(mean = mu[i], sd = sigma[i])
}
mu[i] ~ dunif(0, 1)
sigma[i] ~ dunif(0, 1)
}
})
inits <- list( mu = rep(.5, 2), sigma = rep(.1, 2))
modelReparam <- nimbleModel(codeReparam, constants = consts, data =
data, inits = inits)
box = list( list('mu', c(0, 1)), list('sigma', c(0, .5)))
modelReparam$simulate('p')
mcemReparam <- buildMCEM(modelReparam, latentNodes = 'p', burnIn =
500, boxConstraints = box)
outReparam <- mcemReparam(maxit = 30)
outReparam
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub <
https://github.com/nimble-dev/nimble/issues/127>

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/nimble-dev/nimble/issues/127#issuecomment-204541111

No good reason I can think of not to use Nelder-Mead. In fact, given that
the analytic gradient function is not available in the MCEM algorithm, it's
that much more a competitive algorithm.
On Sat, Apr 2, 2016 at 5:57 AM, Christopher Paciorek <
<EMAIL_ADDRESS>wrote:

also, Cliff, any reason I shouldn't include the option to use a different
optimization method (e.g.,Nelder-Mead) in buildMCEM()?
On Sat, Apr 2, 2016 at 5:31 AM, Chris Paciorek<EMAIL_ADDRESS>
wrote:

Cliff, thanks, your comments about L-BFGS-F mirror what I was seeing. My
thought for buildMCEM is that we set "nan" and "-Inf" to -1e307 to deal
with the -Inf issue. What do you think?
In terms of degeneracy, I don't think that is what is going on. I agree
that the MLE for p[i] would have an issue if r[i]/n[i]=1, but for the
marginal likelihood, we shouldn't get an (alpha,beta) or (mu,sigma) that
forces all p[i]=1 because some of the r[i]/n[i] < 1. When I max the
marginal likelihood using the beta-binomial, I get mu = .89 and sd=.04
for
the first group.
So I'm still not sure what is going on with the MCEM...
On Fri, Apr 1, 2016 at 12:48 PM, Clifford Anderson-Bergman <
<EMAIL_ADDRESS>wrote:

Oh I see what is wrong with this example. It’s a degenerate posterior
distribution.
In particular, if X ~ beta(a, b), then the density at X = 1 is undefined
if b < 1. This is exactly what is happening in this model (although it’s
much harder to see due to the reparameterization). Since we have that
r[1,3] / n[1,3] = 1, this means we can approach infinite density as p
-> 1
by letting b -> 0.

On Apr 1, 2016, at 12:05 PM, Clifford Anderson-Bergman <
<EMAIL_ADDRESS>wrote:
Hi Chris,
I’ll chime in a little here, being the responsible party, but it might
be a little late…
First of all, I’m not happy with R’s implementation L-BFGS algorithm.
In particular, it immediately quits whenever the target function
evaluates
to -Inf, which seems very foolish. This issue is especially problematic
for
the L-BFGS with box-constraints, as the default behavior for some reason
appears to evaluate the function at all corners of the box. I simply
cannot
fathom what went into this decision for the optimizer. Because often the
target function is -Inf on the boundary, this often means that the
standard
BFGS (without box-constraints) is more likely to be successful than the
optimizer with box constraints; if the target function is undefined at
the
boundary, the box constraints algorithm will fail 100% of the time.
However, without the box-constraints, if you have a good initial value
and
never wander outside the boundary, the unconstrained BFGS algorithm
should
work.
In general, R’s Nelder-Mead algorithm is much more stable; it allows
for evaluations of the target function to be -Inf during the search. It
can
be very problematic if the solution is actually on the boundary though.
To deal with this issue of R’s L-BFGS implementation, I actually
“scoot” the box constraints in by epsilon (I think I set the default to
10^-5 or something)? This way when optim tries to evaluate the function
in
the corners, it should get a finite value.
That being said, I’m actually confused what’s happening in this
example. As I just mentioned, the box constraints should not be an issue
for mu and sigma (and I even tried scooting it in even more to no
avail).
Also, when I tried debugging the R-version, some of the functions were
not
working correctly (although perhaps those were just issues with the R
side,
as it did compile, which was surprising given the R version’s errors). I
can dig a little deeper on that.
If I had more time, I would have half a mind to improve R’s optim
functions…
-Cliff

On Mar 30, 2016, at 10:04 AM, Christopher Paciorek <
<EMAIL_ADDRESS><EMAIL_ADDRESS>wrote:
two things:

optim doesn't like -Inf as objective fun value; probably just
replace -Inf in MCEM cCalc_E_llk$run() with -1e307.

for this example, it's not moving away from starting point. Works
if use Nelder-Mead instead of BFGS. Need to investigate.

consts <- list(G = 2,N = 16, n = matrix(c(13, 12, 12, 11, 9, 10,
9, 9, 8, 11, 8, 10, 13, 10, 12, 9, 10, 9, 10, 5, 9, 9, 13,
7, 5, 10, 7, 6, 10, 10, 10, 7), nrow = 2))
data = list(r = matrix(c(13, 12, 12, 11, 9, 10, 9, 9, 8, 10, 8, 9,
12, 9, 11, 8, 9, 8, 9, 4, 8, 7, 11, 4, 4, 5, 5, 3, 7, 3, 7, 0),
nrow = 2))
inits <- list( a = c(2, 2), b=c(2, 2) )
codeReparam <- nimbleCode({
for (i in 1:G) {
for (j in 1:N) {
r[i,j] ~ dbin(p[i,j], n[i,j]);
p[i,j] ~ dbeta(mean = mu[i], sd = sigma[i])
}
mu[i] ~ dunif(0, 1)
sigma[i] ~ dunif(0, 1)
}
})
inits <- list( mu = rep(.5, 2), sigma = rep(.1, 2))
modelReparam <- nimbleModel(codeReparam, constants = consts, data =
data, inits = inits)
box = list( list('mu', c(0, 1)), list('sigma', c(0, .5)))
modelReparam$simulate('p')
mcemReparam <- buildMCEM(modelReparam, latentNodes = 'p', burnIn =
500, boxConstraints = box)
outReparam <- mcemReparam(maxit = 30)
outReparam
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub <
https://github.com/nimble-dev/nimble/issues/127>

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
<https://github.com/nimble-dev/nimble/issues/127#issuecomment-204541111

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/nimble-dev/nimble/issues/127#issuecomment-204711561

Ok, I've added the ability to alter the optim method and pass optim control arguments as well as setting -Inf and nan to -1e307 to avoid issues with -Inf in L-BFGS-B.


feat: add array style flag for backward compatibility

@W-12165862@

:QA notes:
using data:tree:import off of my sf-ified data branch, combined with files from https://github.com/mshanemc/cg1
flags is
files: arrayWithDeprecation({
      char: 'f',
      summary: messages.getMessage('flags.files'),
      exclusive: ['plan'],
      aliases: ['--sobjecttreefiles'],
      deprecateAliases: true,
    }),

✅ warning is produced and shows nicely.
👎🏻 message should match sf, which would say array-flag, not arrayFlag
💡 at this point in the code, you've already parsed the values and you know the flag name.  We could output the real text they should have used.   😄
two values on the flag: ../bin/dev force:data:tree:import -f data/Account.json,data/Dealer__c.json
✅ worked (tree is freaky fast)
two values on two instances of the flag ../bin/dev force:data:tree:import -f data/Account.json,data/Dealer__c.json -f data/Motorcycle__c.json,data/Lead.json
✅ worked fine
👎🏻 warning is shown twice.  Knowing what I know about the command, I'm not sure there's a good way to fix it, and I don't think this'll hit users much (you either use a comma-list, or the multi-flag thing, not both)


feat: use dependency injection for hassclient

This PR enables dependency injection as a first class citizen in net-hassclient.

Coverage decreased (-0.7%) to 75.934% when pulling 78c0407b778c50559ba3d775e634f5013c89f01d on feature/dependencyinjection into 47f65a8c2cb5f2cb6c5c8f54973dfcfc60579409 on dev.


[Scala 3] Parser issues

I've taken a look at parsing the Dotty pos test cases and I found a bunch of errors:
Issues:

[x] https://github.com/scalameta/scalameta/pull/2408

type Macro[X] = (=> Quotes) ?=> Expr[X]

[x] https://github.com/scalameta/scalameta/pull/2409

given noCaller: Caller(???) with
   override def computeValue() = ()

given C(1) with {}

given t1[T]: E[T]("low") with {}

[x] https://github.com/scalameta/scalameta/pull/2404

given [T](using e: Exp[T]): Exp[NCtx => T] with
    import NCtx.*
    def lit(i: Int) = {
      case Pos => e.lit(i)
      case Neg => e.neg(e.lit(i))
    }
    def neg(x: NCtx => T): NCtx => T = {
     case Pos => x(Neg)
     case Neg => x(Pos)
    }
    def add(l: NCtx => T, r: NCtx => T): NCtx => T =
      c => e.add(l(c), r(c))

[x] https://github.com/scalameta/scalameta/pull/2422

println(s"\"Hello\", $person")

[x] https://github.com/scalameta/scalameta/pull/2419

check_success("\"\\u0024\" == \"$\"", s"\u0024", "$")

[x] https://github.com/scalameta/scalameta/pull/2410

'{ val x: Int = ${ (q2) ?=> a } }

[x] https://github.com/scalameta/scalameta/pull/2418

 def f(x: Int) =
  assert(
    if x > 0 then
      true
    else
      false
  )
  assert(
    if x > 0 then
      true
    else
      false)
  assert(
    if x > 0 then
      true
    else
      false, "fail")
  assert(
    if x > 0 then
      true
    else
      if x < 0 then
        true
      else
        false, "fail")
  (
    if x > 0 then
      println(x)
      x
    else
      s"""foo${
        if x > 0 then
          println(x)
          x
        else
          -x
        }"""
  )

[x] https://github.com/scalameta/scalameta/pull/2417

  object Test:
  try List(1, 2, 3) match
  case x :: xs => println(x)
  case Nil => println("Nil")
  catch
  case ex: java.io.IOException => println(ex)
  case ex: Throwable => throw ex
  end try

[x] https://github.com/scalameta/scalameta/pull/2413

val y3 =
    if (1) max 10 gt 0
    then
      expr

[x] https://github.com/scalameta/scalameta/pull/2420

type T1 = (Lambda { type Arg = Int } { type Apply = List[Arg] }) # Apply

[x] https://github.com/scalameta/scalameta/pull/2412

def b2 = "".foo2(using foo)[Any]

[x] .

class Baz1 @deprecated(implicit c: C)

[x] https://github.com/scalameta/scalameta/pull/2416

def send() =
  c ! "hello"
    ! "world"
    send_! "!"

[x] https://github.com/scalameta/scalameta/pull/2415

val x * y = v

[x] https://github.com/scalameta/scalameta/pull/2423

given Context()

The only remaining one in this task is class Baz1 @deprecated(implicit c: C)

@tgodzik please feel free to close this if it's all done. (also, how do you add a link to the pr next to the checkmark?)

@tgodzik please feel free to close this if it's all done. (also, how do you add a link to the pr next to the checkmark?)

I just edit the comment, thanks for taking care of that one!


fix(material-experimental/mdc-form-field): fix baseline and handle custom controls better

Fixes the baseline of form-field controls and their inputs. Previously
the baseline was incorrect due to flex alignment and vertical-align misuse.
Improves support for custom form-field controls by ensuring that
spacing applied to MDC inputs, also applies to custom controls.

The same will be needed for the outline appearance, but
unfortunately we cannot apply any spacing to the infix until we find
a solution for: https://github.com/material-components/material-components-web/issues/5326

Also just related to this: The outline appearance is not working out very nice in our case due to the limitation with the notched-outline. In summary, we need a way to have the outline cover the whole fext-field (prefix, suffixes etc), but have the floating label be relative to the infix container.
I'm unsure if MDC will ever support what we need. We need to keep in mind that we don't implement a standard text-field.. but want to support custom form-field controls. I'm playing with the idea of just working around this.. It should help us reduce the overall CSS workarounds too, so it might be worth.


Flickering reflections when using baked occlusion culling data for terrain

The flickering is actually produced by the moving boat. So there is certain angles, where the culling does not work properly.
I was playing arround for days tracing down the problem. I could not manage to reproduce it in a new project that I can share, but I could fix it by doing this:
In the OceanPlanarReflection.cs on line 191 the cullingMatrix is calculated:
_camReflections.cullingMatrix = _camReflections.projectionMatrix * _camReflections.worldToCameraMatrix;
And for some reason, which I do not understand, it is done again after the rotaion is set at line 202.
By removing line 202 I could get rid of the flickering reflections.
» Videos

Thanks for reporting.
It looks like its set to the culling matrix from the current camera first, then set to what i would think is the correct matrix in the second step. It should be easy to verify by placing some objects in a scene and moving the camera around and watching the reflection, to see which culling matrix is correct. This stuff is also based heavily on Unity's planar reflection script from way back (i have a feeling its in the Environment standard assets pack), so we should check there and see if they do the same thing, or if its a bug we've introduced.
What we have (using the second culling matrix) has worked well so far, but we have not tested much with baked occlusion i think. I wonder if there is something here. On that topic - there is an alarmingly-similar issue described here: https://forum.unity.com/threads/water-reflections-occlusion-culling.322379/ . From 5 years go though.
When we've had a chance to play around with it myself or one of the others will post back. let us know if you find anything in the meantime.

It seems like the same problem indeed. I personally have absolutely no time to investigate any further. I have to work on the update of "Dock your Boat" and lost so much time now.

I made a mistake in the description. It is in fact different code on line 192 and 202.
So it actually is still not working. I am running out of ideas.

Please download this test project. It should include everything including the baked occlusion data. This is was created on  V2020.1.0b8 but the problem also occurs in 2019.3.
UnityProject
You will see the tilted camera creates the problem. Rotation of the Y axis will show you the flickering.
Additional note: It also happens without any terrain just some baked static spheres. It also does not matter how dense the baked data is - meaning it does not matter what parameters one chooses to bake.

more info that might help: It apperently has nothing todo with baked occlusion data. It happens also with a simple static sphere, when dynamic occlusion is activated.
Important: the camera's rotation.x and z have to be not 0.

Thanks for all of this. I recall you are developing for iOS. Are you experiencing this issue on a Mac? I have notice some oddities with the frustum on Mac that I haven't on Windows (not 100% confirmed).

Also, I am looking at the video occlusion-problem-reflectioncam.mov and it looks like that video is showing a general problem with culling? Or is that Crest specific too?

I have only seen this problem in the reflection on crest. I do not have it with the community ocean shader reflection - honestly I do not know how that works there. I can have a look.
Yes, I am on Mac targeting iOS and Android. The builds for iOS produce the same result. Have not tried Android yet.
The video occlusion-problem-reflectioncam.mov shows the reflection cam - I removed the target rendertexture for testing purpose.

Thanks. I tried the test project on Mac and I have reproduced the issue. I don't have access to Windows at the moment. This does appear to be a general issue though as I am seeing a few complaints and possible fixes.
It appears that most have solved this by disabling occlusion on the reflection camera. I will have a look at the original Planar Reflection script and BoatAttack and see what Unity has done there.

@klauskobald  is community ocean the following?:
https://github.com/eliasts/Ocean_Community_Next_Gen

Boat Attack disables occlusion culling.
The community ocean doesn't appear to disable occlusion culling. I haven't tested it though.

yes, this is community ocean I was using.

@klauskobald Thanks. I have the test project you provided. Could you please take the uploaded project down :)? I'll have a solution tomorrow.

sure

Am 07.06.2020 um 08:05 schrieb daleeidd<EMAIL_ADDRESS>@klauskobald https://github.com/klauskobald Thanks. I have the test project you provided. Could you please take the uploaded project down :)? I'll have a solution tomorrow.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/crest-ocean/crest/issues/528#issuecomment-640207783, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACD7HEXVKMDSJA6J3IYVKLRVN7ARANCNFSM4NRHGCPQ.

@klauskobald asked if there is an existing unity bug for this, did you come across one @daleeidd ? If not could you please report one? Thanks!

@huwb I had a look and I found this one which was marked as fixed years ago. I did some research and people have been reporting this bug throughout the years according to forums. I submitted a new one using built-in (upgraded to latest 2019 and imported @klauskobald test scene).
I've added a task to add baked occlusion to either the main scene or create a new scene.
@klauskobald I have added a way to disable occlusion culling for the reflection camera. Please see commit dc4b58e. Let me know if you need any assistance. I believe that the proper solution will be using planar reflection probes when Unity adds to URP.

I'll close this once 4.3 is released.

Just going to add I tried the water that comes with Unity Standard Assets. It has occlusion culling enabled. It works much better than ours (worked fine with provided reproducible scene), but it still has issues when going to a certain height where the reflections flicker and disappear.

FUN FACT: Sometimes removing code solves problems!
Reflections work with any kind of x / z rotation when these lines are removed:
//Vector4 clipPlane = CameraSpacePlane(_camReflections, planePos, planeNormal, 1.0f);            //_camReflections.projectionMatrix = _camViewpoint.CalculateObliqueMatrix(clipPlane);
// _camReflections.cullingMatrix = _camViewpoint.projectionMatrix * _camViewpoint.worldToCameraMatrix;
// _camReflections.cullingMatrix = _camReflections.projectionMatrix * _camReflections.worldToCameraMatrix;
I have no real idea what the mathematics behind this realy does. But that code is very old as I can see it being used all over the place. Maybe Unity added some magic under the hood that works against it ?
Anyhow: I checked the stats window and it shows that oclusion culling is working and a decent amount of triangles being rendered.

FUN FACT: when removing these lines it works:
//Vector4 clipPlane = CameraSpacePlane(_camReflections, planePos, planeNormal, 1.0f);
//_camReflections.projectionMatrix = _camViewpoint.CalculateObliqueMatrix(clipPlane);
// _camReflections.cullingMatrix = _camViewpoint.projectionMatrix * _camViewpoint.worldToCameraMatrix;
//_camReflections.cullingMatrix = _camReflections.projectionMatrix * _camReflections.worldToCameraMatrix;
the only problem I found is, that when the reflection cam is below the basement of the terrain, it renders a grey plane, which then creates a wrong reflection of course. I wonder why this is happening.

Disabling those lines does make it behave similar to the Water Pro in Unity Standard Assets. I found that reflections began disappearing once the camera reached about 30 height.

Unity has marked my issue as a duplicate. The following is for HDRP, but they said it won't make a difference or they will update me if that changes.
https://issuetracker.unity3d.com/product/unity/issues/guid/1210092

4.3 has been released with an option to disable occlusion culling. But since we have an open issue with Unity I will keep this open.

Since the code is based off the Unity Standard Assets which isn't support in 2019+ there will be no fix for it. A fix might be back ported to 2018 (they will let me know). If this is a code issue, then we could bring that over. If not, then I don't see why they wouldn't fix it in 2019 too.
If I wanted to press the issue further I would need to make a minimal test case to narrow down the problem. We have a workaround so I am not sure when I will investigate it further. I will wait and see what Unity says before proceeding.

Thanks for the notes. Agreed with your plan.


Allow multiple listeners on same port in Gateway API provider

What does this PR do?
The Gateway API spec allows for multiple listeners with the same (protocol,port)-tuple on gateways.
This PR removes a limitation that was preventing this behavior.
Currently, this multi-listener support is only active for HTTPS protocol, but can easily be extended to other protocols with a minor modification of the shareableListenerProtocols slice.
Motivation
Closes #9026
Additional Notes
make test actually failed with:
--- FAIL: TestLookupAddress (0.00s)
    --- FAIL: TestLookupAddress/IP_doesn't_need_refresh (130.51s)
        proxy_test.go:207:
                Error Trace:    proxy_test.go:207
                Error:          Received unexpected error:
                                dial tcp <IP_ADDRESS>:53: connect: connection timed out
                Test:           TestLookupAddress/IP_doesn't_need_refresh
    --- FAIL: TestLookupAddress/Hostname_needs_refresh (261.58s)
        proxy_test.go:207:
                Error Trace:    proxy_test.go:207
                Error:          Received unexpected error:
                                dial tcp <IP_ADDRESS>:53: connect: connection timed out
                Test:           TestLookupAddress/Hostname_needs_refresh

These DNS servers/ports are simply blocked by my infrastructure. The Gateway API tests are run before these failing tests.
make pull-images ✅
make validate ✅
make test  ✅
ok      github.com/traefik/traefik/v2/pkg/provider/kubernetes/gateway   0.127s  coverage: 60.1% of statements

Thank you for your understanding, but this PR will be replaced with a new and hopefully better PR in a few hours.
The new PR will satisfy the Gateway API spec by extending the current PR to include hostname handling as well (... each listener in a gateway must have a unique combination of hostname, port, and protocol).


[QUESTION] How to change text/hint font style and size in HtmlEditor?

How to change text/hint font style and size in HtmlEditor? Not able to figure out the right format for HtmlEditorOptions.customOptions to achive it.

Unfortunately this cannot be supported, the hint font style and size is handled by the summernote backend JS and cannot be changed through Dart.


【Bug】更新到3.6.2后，进行后台扫描书籍，持续报错

Exception:
Traceback (most recent call last):
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/engine/base.py", line 1964, in _exec_single_context
self.dialect.do_execute(
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/engine/default.py", line 747, in do_execute
cursor.execute(statement, parameters)
sqlite3.OperationalError: database is locked
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/var/www/talebook/webserver/handlers/base.py", line 51, in do
rsp = func(self, *args, **kwargs)
File "/var/www/talebook/webserver/handlers/base.py", line 85, in do
if not self.current_user:
File "/usr/local/lib/python3.9/dist-packages/tornado/web.py", line 1340, in current_user
self._current_user = self.get_current_user()
File "/var/www/talebook/webserver/handlers/base.py", line 217, in get_current_user
user = self.session.query(Reader).get(user_id) if user_id else None
File "", line 2, in get
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/util/deprecations.py", line 383, in warned
return fn(*args, **kwargs)  # type: ignore[no-any-return]
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/orm/query.py", line 1130, in get
return self._get_impl(ident, loading.load_on_pk_identity)
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/orm/query.py", line 1139, in _get_impl
return self.session._get_impl(
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/orm/session.py", line 3670, in _get_impl
return db_load_fn(
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/orm/loading.py", line 670, in load_on_pk_identity
session.execute(
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/orm/session.py", line 2229, in execute
return self._execute_internal(
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/orm/session.py", line 2124, in _execute_internal
result: Result[Any] = compile_state_cls.orm_execute_statement(
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/orm/context.py", line 253, in orm_execute_statement
result = conn.execute(
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/engine/base.py", line 1414, in execute
return meth(
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/sql/elements.py", line 485, in _execute_on_connection
return connection._execute_clauseelement(
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/engine/base.py", line 1638, in _execute_clauseelement
ret = self._execute_context(
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/engine/base.py", line 1842, in _execute_context
return self._exec_single_context(
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/engine/base.py", line 1983, in _exec_single_context
self._handle_dbapi_exception(
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/engine/base.py", line 2325, in _handle_dbapi_exception
raise sqlalchemy_exception.with_traceback(exc_info[2]) from e
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/engine/base.py", line 1964, in _exec_single_context
self.dialect.do_execute(
File "/usr/local/lib/python3.9/dist-packages/sqlalchemy/engine/default.py", line 747, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) database is locked
[SQL: SELECT readers.id AS readers_id, readers.username AS readers_username, readers.password AS readers_password, readers.salt AS readers_salt, readers.name AS readers_name, readers.email AS readers_email, readers.avatar AS readers_avatar, readers.admin AS readers_admin, readers.active AS readers_active, readers.permission AS readers_permission, readers.create_time AS readers_create_time, readers.update_time AS readers_update_time, readers.access_time AS readers_access_time, readers.extra AS readers_extra
FROM readers
WHERE readers.id = ?]
[parameters: (1,)]
(Background on this error at: https://sqlalche.me/e/20/e3q8)

sqlite3.OperationalError: database is locked 数据库被锁住了。可以先试试重启整个容器，应该能释放锁。本质原因是代码中对于并发处理不够严谨，可能有竞争状态，后面再细细优化下。

sqlite3.OperationalError: database is locked数据库被锁住了。可以先试试重启整个容器，应该能释放锁。本质原因是代码中对于并发处理不够严谨，可能有竞争状态，后面再细细优化下。

我部署完导入了13本，没有问题，刚才一次性导入1W多本，也是提示数据库被锁


Adapt Xcode project generation code to Path types

Path adoption continues with the Xcode project generation.  As before, it is in general a fairly mechanical transformation, but I did simplify some of the helper functions for project generation, but there were some ambiguities and misnomers that made things unclear otherwise.  But I've tried to keep the diffs strictly localized to converting from Strings to AbsolutePaths / RelativePaths, as appropriate.

@swift-ci please test

I found a bug in here in which we're generating absolute paths in projects.  Investigating and will push an update.

Fixed

@swift-ci please test

LGTM!

Great, thanks for reviewing.  When the test finishes I'll merge.


Can i use oak-http-proxy on web-socket requests?

Hello, i have a question. Can i use this middle-ware on web-socket requests?

Hi @Relaxe111 👋 Similarly to https://github.com/asos-craigmorten/opine-http-proxy/issues/5, this module does not support websocket proxying. I’m open to contributions if it’s something you’d want to give a go!

Given this was a question rather than a feature request going to close for now 😄


Make query case insensitive

Test App: https://stategovernment.maps.arcgis.com/apps/instant/notification/index.html?appid=9a927468d55841fa90c05bd258744113
Test map: https://stategovernment.maps.arcgis.com/apps/mapviewer/index.html?webmap=1bd849df147d4ac4837718fff04ff30d
Sample query at the rest endpoint:
Labels are showing undefined value when pop-up uses mixedcases and the field names are in uppercase. Such cases resolv in map viewer and rest end point, but it does not work in PN.

Verified in devext


Support new daemonset.updated metric name from kube-state-metrics

What does this PR do?
Adds a new metric mapping to daemonset.updated from the kube-state-metrics kube_daemonset_status_updated_number_scheduled metric (previously called kube_daemonset_updated_number_scheduled).
Motivation
In https://github.com/kubernetes/kube-state-metrics/commit/8031a708543563583990abfead7559bc29cc5b0c, the metric name was changed from kube_daemonset_updated_number_scheduled to kube_daemonset_status_updated_number_scheduled to be consistent with other metric names.
This PR adds the new mapping and leaves the old mapping for backward compatibility.
Additional Notes
n/a
Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached

I was not able to add a changelog label to the PR.

hi @rewolf
The metrics was renamed in kube-state-metrics version >= 2. So the Datadog check that support v2 is kubernetes_state_core. Because the python check that you have modified only support kube-state-metrics <= 1.9.x. More information about the reason we have build this new check here: https://www.datadoghq.com/blog/kube-state-metrics-v2-monitoring-datadog/
Also the metric change is already done in the kuberneres_state_core check: https://github.com/DataDog/datadog-agent/pull/11369
I would suggest you to migrate to the kubernetes_state_core check: https://docs.datadoghq.com/integrations/kubernetes_state_core/

Also the metric change is already done in the kuberneres_state_core check: https://github.com/DataDog/datadog-agent/pull/11369

Must have missed that when searching for references!
Thanks for the explanation @clamoriniere.
Looks like we'll have to look at migrating to kubernetes_state_core sooner rather than later, although it's going to take us a while to assess the affected scope.
I understand your suggestion and viewpoint, but if this is only one of a few breaking changes between ksm v1 and v2, it'd be great to get support for the new metric backported to this kubernetes_state check with a merge of this PR and give us time to properly prepare for migration to kubernetes_state_core.

Hi @rewolf

I understand your suggestion and viewpoint, but if this is only one of a few breaking changes between ksm v1 and v2, it'd be great to get support for the new metric backported to this kubernetes_state check with a merge of this PR and give us time to properly prepare for migration to kubernetes_state_core.

As I explained this metric renaming (kube_daemonset_updated_number_scheduled to kube_daemonset_status_updated_number_scheduled) was introduced in kube-state-metrics v2. But the Datadog kubernetes_state check only support scrapping kube-state-metrics <= 1.9.x. So this metric renaming doesnt applied to the kubernetes_state check.
The migration from kubernetes_state to kubernetes_state_core is not fully transparent, but it is worth doing it if you are using a recent Kubernetes version. It provided new useful metrics with much better performances.
If it is ok with you, I think we can close this PR.

hi @rewolf,
I'm closing this PR, feel free to reopen it if you want react on my previous comment


Segfault (SIGSEGV) on server in destroy_at after poping of first element of buffer queue

When a client connects to the server it starts updating the entity's positions and sending it to the server.
The server stores those changes in vectors and uses smart_ptrs to access those vectors. The smart pointers are stored in a de queue for that individual client. The environment client loop waits till updates are pushed into the buffer queue, pops off the first element does the work, and loops again. In the next loop, the share_ptr count for the previous change vector goes to 0 and the DTOR is called. Here stl_constructs attempt to destroy the first element of the vector results in s SIGSEGV segfault.

The segfault also occurs when the buffer is not a shared_ptr. As soon as destroy_at is called for the first element of a buffer that was initialized through net::msg::pull_complex,


logistique regression

Hello,
When we launch 2 times the same logistic regression, we don't have the same result.
For exemple, with titanic dataset :
from verticapy.learn.linear_model import LogisticRegression
drop(schema + ".lr_titanic", cursor = cur, method = "model")
model1 = LogisticRegression(name = schema + ".lr_titanic", penalty = 'None')
model1.fit(titanic_copy, ["fare", "age"], "survived")

drop(schema + ".lr_titanic", cursor = cur, method = "model")
model2 = LogisticRegression(name = schema + ".lr_titanic", penalty = 'None')
model2.fit(titanic_copy, ["fare", "age"], "survived")

the results are :

We see few differences on the coefficients. The dataset titanic is very simple, but on larger dataset, the differences are larger.
The problem seem to come from "LOGISTIC_REG", a vertica function. I don't know why and if you can fix that?
Regards,
Alexandre

Hi Alexandre,
Thanks for your report.
I'd like to highlight that the differences on the coefficients in your reported experiment are smaller than 1e-12. This is an inevitable roundoff error caused by the distributed algorithm that trains the logistic-regression model.
In fact, when the LOGISTIC_REG function is called, multiple parallel threads collaborate to calculate the resulted coefficients in several iterations. The number of threads is determined by the number of Vertica nodes and available resources (i.e., the number of processing cores per node, the available amount of memory in the corresponding resource pool, and the load imposed by other concurrent queries). Even in the experiments with the same running environment and the same number of threads, parallel threads may finish processing their assigned data in different orders in each run. This means that their interval calculated results would be aggregated in different order each time. This would consequently lead to slightly different final results in different runs due to roundoff error.
We have tested the LOGISTIC_REG function on different Vertica clusters and different data sizes and we have not observed more than 1e-9 difference in the trained coefficients.
Regards,
Arash


python311Packages.ntc-templates: 3.2.0 -> 3.5.0

Diff: https://github.com/networktocode/ntc-templates/compare/refs/tags/v3.2.0...v3.5.0
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.


ffe-message-box(-react): 'action' variant

In ffe-message-box we have a version called action but it's not implemented in the React world. Is it a version we need, or can it perhaps be removed?

@adidick and @hodoea - what do you think?

@wkillerud the code says "action", not "active". Typo?

I've never used a grey message box so it's possibly not needed. If it's not implemented in the React world that probably means it's not anywhere either, right? Which means we probably can't search for it in use. A grey version of the message box doesn't exist in the sketch template so I'm not sure how how it ended up here and what it should be used for.

It looks like this:

It's not used a lot (but a few places) internally, so it can probably be removed in the next major of ffe-message-box, especially if there's no use for it and it breaks with design guidelines.

Yeah, that looks like it does the same things as a blue info box, so unless someone else has a good reason to use it we can surely throw it out.

@selbekk I've posted in the graphic design channel on Slack to see if there's anyone else who knows where it came from.

Thanks! I noticed that it was in use on the kundeklienter BM team - hope that helps!

Regarding the team ´kundeklienter BM´. Are we talking insurance or bank? @selbekk So far no one has replied in the GD-forum channel regarding its usage..

This is the forsikring team, as far as I could tell.

Should we deprecate and later remove the --action modifier then @adidick @hodoea ? Consumers should use the tips modifier instead?

It seems like it's something that's not in use or at least in principle shouldn't have a use. Since we haven't heard from anyone else about I'm happy if you remove it.

@espenvoll Hva tenker du om denne?

OK

OK

OK

Ok, mottatt! Regner med det kommer en lenke til issue her også?
Fra: Hodo Elmi Aden <notifications<EMAIL_ADDRESS>Svar til: SpareBank1/designsystem <reply<EMAIL_ADDRESS>Dato: fredag 9. mars 2018 10.52
Til: SpareBank1/designsystem <designsystem<EMAIL_ADDRESS>Kopi: Heidi Lyngvær Stolen <heidi.stolen<EMAIL_ADDRESS>Mention <mention<EMAIL_ADDRESS>Emne: Re: [SpareBank1/designsystem] ffe-message-box(-react): 'action' variant (#22)
@espenvollhttps://github.com/espenvoll @siriochttps://github.com/sirioc @christofferaunesb1https://github.com/christofferaunesb1 @Helenethohttps://github.com/helenetho @Heilystohttps://github.com/heilysto@ChriBran1https://github.com/chribran1 Hva tenker dere om denne?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/SpareBank1/designsystem/issues/22#issuecomment-371765737, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AeQgIdCM6HMOk65WBhSnvnECyAs7WwDwks5tclDLgaJpZM4STOw9.

Aight
Med vennlig hilsen,
Christian Brandt
Grafisk Designer
Designavdelingen SpareBank 1 Banksamarbeidet
e-post: christian.brandt<EMAIL_ADDRESS>tel: 967 06 649
Fra: Hodo Elmi Aden <notifications<EMAIL_ADDRESS>Svar til: SpareBank1/designsystem <reply<EMAIL_ADDRESS>Dato: fredag 9. mars 2018 10.52
Til: SpareBank1/designsystem <designsystem<EMAIL_ADDRESS>Kopi: Christian Brandt <christian.brandt<EMAIL_ADDRESS>Mention <mention<EMAIL_ADDRESS>Emne: Re: [SpareBank1/designsystem] ffe-message-box(-react): 'action' variant (#22)
@espenvollhttps://github.com/espenvoll @siriochttps://github.com/sirioc @christofferaunesb1https://github.com/christofferaunesb1 @Helenethohttps://github.com/helenetho @Heilystohttps://github.com/heilysto@ChriBran1https://github.com/chribran1 Hva tenker dere om denne?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/SpareBank1/designsystem/issues/22#issuecomment-371765737, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AjfJXZvpkd9MgoP9oc-qYz44BrsPQ4U8ks5tclDLgaJpZM4STOw9.

@Heilysto

@Heilysto

OK

@Heilysto

@ChriBran1

@Heilysto @ChriBran1 TEST

@helenetho

hi ppl

@krisoren test

@hodoea test tilbake


Fix MNIST MLP model

Removed ReLu activation present just before softmax.
(It's not a good idea to have ReLu > Softmax immediately. The test accuracy of the model is now much better.)

Thanks. This also needs a slight doc change.
Due to the way our CI/merge works, I need to merge this the hard way.

Migrated to #1000

Thanks so much @okhat! Congrats on your first PR btw.


SCP 914, Bug?

when ever I use 914 eventually (not always the first time) it will stop opening the doors, and trap everything that was placed inside, has occured more frequently on Very Fine, so I figured it could be a feature,

Did you get any errors or anything in the log, and if so can you provide it?

I tried using a tragedy mask and setting the output to Rough, this is the error it gives:

I tried using a tragedy mask and setting the output to Rough, this is the error it gives:

@Badhamknibbs I may have found part of the problem
Taking into account this piece of code for example:
AddConversions(SCP914, lItems, "walkie-talkie", ["*"], ["@"], ["@", "old phone"], ["@", "boombox"], ["boombox"] );
the "*" parameter is not recognized and apparently gives an error.
This happens with every item.

Weird, it should handle that correctly as * is meant to destroy the item, I'll have to check it when I'm back at home


Update hello-hybrid-cloud-kerberos-trust.md

Updated the document to add a note and highlight the usage of Settings Catalog for the enforcement of Digits as the Identity Protection template UX does not have that option

Why

Closes #[Issue Number]

Changes

hello @maathangik and thank you for the feedback. I verified, and it's not required to use Settings catalog to enforce a PIN. This is what I used

result

closing the PR


Slash commands

I suggest to implement slash commands API in the library. If no one can do it now, I can.

Now they're on official announcement. Should we (or I) work on it?

Okay, as I see, many people wants it, so... I'm working on it :slightly_smiling_face:

Btw, after closing this issue I will move onto #854.

Okay, I've just finished some part of the interactions API, but first of all, as I said, I need testers and feedback. But most important, I'm implementing only gateway and REST part of interactions.
Anyone wants webhooks system (just interactions or the whole system, maybe with server) ?

Btw, take a look.

Can you open the source code by creating draft pull request so that anyone can try it by checking out?

Well, now - no. At least I need to complete basic API (such CRUD).
Until it - no, but responding hasn't yet implemented.

@sarisia Well, they're (almost) ready to go!

Any bugs please report here (maybe I forgot something idk).

Sorry for taking so long time to wait for the changes. I'm just busy.
And I'm writing this to say, that everything is okay - in near days everything will be deployed.

Sorry for taking so long time to wait for the changes. I'm just busy.
And I'm writing this to say, that everything is okay - in near days everything will be deployed.

For anyone wondering what's happening with this feature now - it's ready. We're waiting for approval and merge.

For anyone wondering what's happening with this feature now - it's ready. We're waiting for approval and merge.

Hi, since the last reply is now more than a month ago, has this been merged? And has it been documented how to register slash commands with the library?

@incapable doesn't look like it has been merged - see #856.

Well, now it's finally merged, I think now we can close this.


File management: Moving and copying - rc14

I prepared a onedata demo in order to give to our users the opportunity  to test onedata.
One of our users inform me that it isn't possible to move files among the folders.
Version used: rc14 for oneprovider, rc16 for onezone.

rc14 can be considered quite obsolete now. lots of problems like this were
solved in the next versions. When giving demo, please use the newest
version always to ensure the best user experience. We tend to solve more
bugs, that we generate :-)
On Mon, Sep 11, 2017 at 12:35 PM marcucci84<EMAIL_ADDRESS>wrote:

I prepared a onedata demo in order to give to our users the opportunity to
test onedata.
One of our users inform me that it isn't possible to move files among the
folders.
Version used: rc14 for oneprovider, rc16 for onezone.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/onedata/getting-started/issues/39, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOuppOGrImZxOSGllbCutUWtzHFkOPEks5shQz-gaJpZM4PS9fG
.

After coming talk with a developer. At the time of writing (onedata 7.06.0-rc2) all these works when done via oneclinet. In web interface, you can just copy, the 'move' operation is on our roadmap.

Thanks Michal for your answer. I will clarify this aspect to my users.
Regards
Nicola
Il 11/Set/2017 13:33, "Michal Orzechowski"<EMAIL_ADDRESS>ha
scritto:

After coming talk with a developer. At the time of writing (onedata
7.06.0-rc2) all these works when done via oneclinet. In web interface, you
can just copy, the 'move' operation is on our roadmap.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/onedata/getting-started/issues/39#issuecomment-328502277,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AWpFfVXnX089KXdDo38R5a_xOY2_dKs4ks5shRqPgaJpZM4PS9fG
.


Summary endpoint is missing total number of non-canonical blocks

Does it provide "total blocks"? "total canonical blocks?" Isn't blockchain height the same as total canonical blocks?

Yes, blockchain length is equal to the number of canonical blocks. We already include the total number of blocks. So we just need to do some arithmetic.


Fix for 0.12

Thanks! Looks like the Travis config needs updating too, but I can do that.

I might have messed up the tuples version number… may need to be 5 rather than 4.1. I get confused as to whether bower/pulp is heeding bower.json or using a different (already installed) version.

Thanks again!


Base Map tile disappeared

I had a very odd issue - I had a map loaded and the entire base map was loaded but after a few seconds (15-30 or so) one base map tile disappeared. The other data and tiles stayed one just went away. It came back after I zoomed in and out again but just hadn't seen that before.

it was google maps?

Positron Lite
On Mon, Sep 28, 2015 at 3:49 PM, javi santana<EMAIL_ADDRESS>wrote:

it was google maps?
—
Reply to this email directly or view it on GitHub
https://github.com/CartoDB/cartodb/issues/5785#issuecomment-143855859.

--
Matt Forrest
Account Manager
CartoDB — Map Your World's Data
143 Roebling St 2A, New York, 11211, USA
T:<PHONE_NUMBER> Skype: mbforr
W: www.cartodb.com
Live sessions to learn CartoDB
http://t.signauxdeux.com/e1t/c/5/f18dQhb0SmZ58dDMPbW2n0x6l2B9nMJW7sM9dn7dK_MMdBzM2-04?t=http%3A%2F%2Fcartodb.com%2Fwebinars%2F&si=5280316725395456&pi=6e3dcfdb-b0ba-402b-ccea-db69a9f3604a

There has been no activity on this issue for more several months. We are closing it. If you think this still needs to be addressed please open a new issue.


Linux Support?

I was wondering if there would be any stable Linux support?

This question has been asked multiple times on discord(https://discord.com/invite/7QMraJUsQt). Yes there will be a stable Linux version at some point.

linux is now released! https://x.com/trypearai/status/1832179554389258691


Does this package converts multi_line_text_field to rich_text_field?

I want to migrate multi_line_text_field to rich_text_field
# Before

test

# After
{
  "type": "root",
  "children": [
    {
      "type": "paragraph",
      "children": [
        {
          "type": "text",
          "value": "test"
        }
      ]
    }
  ]
}

Can I use this package for this migration?

@remy727 You might be able to, I am not fully grasping what you are trying to do though. Can you provide more context ?

Hi @mcqua007, can I also use this package to convert HTML to Shopify richtext?

Hi @mcqua007, can I also use this package to convert HTML to Shopify richtext?

@remy727  No unfortunately this goes one way. Mainly because shopify's rich text is very limited. It only has few different types of elements (h1,h2,.., p, ul, li) etc...
I am not sure why you would need to convert HTML to Shopify's richtext ? What is your use case ?

Hi @mcqua007, thank you for answering. Makes sense.
I need to migrate the old app metafield(textfield/html) to a new metaobject(richtext).

@remy727 That makes sense, that could be difficult for the reasons I outlined above. Through if the HTML has only those elements it could be done.

Got it. Thank you for your support. We can close this now.

@remy727 Yep, no problem! Have a good day!


Firefox doesn't select items in gift chests

When selecting an item in totals, accounts with that item in their gift chests will be filtered out erroneously.

Cannot replicate currently.


interactive saiw issue

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md
[X] I have updated 'mini.nvim' to latest version

Module(s)
surround
Description
The docs online say:
- `saiwi[[<CR>]]<CR>` - add (`sa`) for inner word (`iw`) interactive
  surrounding (`i`): `[[` for left and `]]` for right.

and indeed, it worked this way in the past. However, it appear that the default is now:
- `saiw?[[<CR>]]<CR>` - add (`sa`) for inner word (`iw`) interactive
  surrounding (`?`): `[[` for left and `]]` for right.

Which of these are intended?
Neovim version
0.8.1
Steps to reproduce

nvim -nu minimal.lua
enter saiwi and see it surround the word with i and not go into interactive mode

Expected behavior

nvim -nu minimal.lua
enter saiwi and see it go into interactive mode

Actual behavior

nvim -nu minimal.lua
enter saiwi and see it surround the word with i and not go into interactive mode

Oh, thanks! I missed to update it after implementing #103. I'll fix this tomorrow.

oh, ok. gotta forget and relearn the muscle memory now, lol
thanks a ton for your work on mini.nvim. i <3 this plugin!

Should be fixed now. Thanks again!

thanks a ton for your work on mini.nvim. i <3 this plugin!

Coming from a 10+ years GitHub user with (so far) a single star to 'mini.nvim' means a lot! 🙏


Add a --daemon option (or something similar)

It would be nice to have an option to run this in the background, you could always use & I guess, but it always feels hacky.

Would that be significantly different from gittorrentd?

@Tzrlk I think the idea is to add a gittorrentd -d that behaves identically to gittorrentd & but either doesn't print any logs, or saves logs somewhere special.  Seems like a good idea, happy to take a patch!

@Tzrlk gittorrentd runs in the forground. daemons are usually running in the background.


IT-10656 Handling situation when 'results' key is missing in response

@AnthonyPorthouse Can I get a ✅  as you were the one requesting changes?


remove read/write for ballot.ActiveSet

Motivation
Closes #4984
Changes

drop EmitEmptyActiveSet config
remove all access to Ballot.ActiveSet and look up from db instead
remove all writes of Ballot.ActiveSet

after this PR, miner will still accept proposal/ballot with non-empty active sets, but will save ballots without active set.

bors try

bors try

bors try

bors merge

bors cancel

bors merge


[debug_info] Revert #2008

https://github.com/caffe2/caffe2/commit/989b11fdaed94a5104e89b807e567bda4599666e needs to be reverted with this I believe - tests are failing due to debug_info references


Fields in a Table are always shown in alphabetical order

Describe the bug
When viewing the list of Fields in a Table they are always shown in alphabetical order, not the order the fields were in when the table was created/uploaded from csv. They appear this way when you are looking at the actual table itself, as well as any view or other item that populates a list of fields.
The automatically added ID field should also logically be the 1st field shown in any table, appearing at the left or top of field names, rather than appear alphabetically amongst all the table fields.
The result of this is that every time you create a new view (or other item with fields) you need to manually move every field back into its correct/logical order.
To Reproduce

Click Tables
Click any table name

Expected behavior
Field names should remain in the order they are in when the table was created/uploaded from csv.
I don't know if the order of fields is actually changed in the underlying database, or if they are just shown alphabetically whenever they are displayed.
It may be useful having an extra table property indicating if you want your fields displayed alphabetically or not.
As an example, a very simple table of people showing their name and address would have the following fields:
ID
title
firstname
surname
address
city
state
postalcode
country
But if you load that table into Saltcorn, it will show the fields as shown below, requiring you to manually move each field back into its correct order every time you create a new view or other item:
address
city
country
firstname
ID
postalcode
state
surname
title
I have also attached screenshots showing an example of a table of mine that I manually had to move each file back into the correct order when creating a view.

I don't think you're quite understanding the issue. I know how to order data on a particular field.
The issue is that when you input from a csv or create a table manually, the fields are shown alphabetically on the table page (e.g. https://xxx.saltcorn.com/table/2 ) as well as when you create a view our any other item that uses table fields/columns  (e.g. https://xxx.saltcorn.com/viewedit/config/xxx the page where you select which columns to use when creating or editing a view). Refer to the example I gave in the 1st post - this is what you see at the top of the page at https://xxx.saltcorn.com/table/2 when viewing the structure/details of any table.
I've never used any other database app or program that puts your field/column names in alphabetical order, instead of the order the fields were in. I'd be interested to know the opinions of any other developers on this issue.

I get your point now, when you created/imported from CSV with your pre-formatted table and field sequence then converted to saltcorn/postgres table it displays in alphabetical order in the field list and the initial data grid.
Upon further testing, although the initial data grid sequence is also set up alphabetically, you can customize it to your field order. Downloading the table CSV returns its original sequence too, even the API returns with the original sequence as pre-formatted from the original CSV.
Regarding the view field order, yeah confirmed that it is set in alphabetical order (Edit, Show), I just notice it now since I usually start with an empty view (clearing the initial fields and labels) to properly set up the columns and containers.

It is good that it doesn't change the underlying tables. Easiest solution might be to give an option to show fields alphabetically or not???

Upon further testing, although the initial data grid sequence is also set up alphabetically, you can customize it to your field order. Downloading the table CSV returns its original sequence too.

Where can I customise it? Are you referring to the table edit page or somewhere else?

Regarding the view field order, yeah confirmed that it is set in alphabetical order (Edit, Show)

Sorry I don't see a Show option??? Not sure which page you are referring to.
Just a thought, but deleting the pre-populated fields in a view/report/etc then adding then back in yourself, I would think you have more of a chance of missing fields.


Canteen prices and oreo notification

Added the student prices as additional information in the canteen fragment
Added support for notifications under oreo (provisional, not fully tested)

Will test it this weekend. Notification fix looks good!


Broken link in tutorial

Both links on Next Step part are broken on Image_io tutorial page.  I can't find this file under docs folder.  where is it now?

you can find them in the tutorial page. We need to fix the links


still in my head

adding staff soon

I would love to know what's on your mind. Your plan and contribute to this project

I created the repository but I did not add anything then. I'm currently setting up the github authentication but I have initialized and deployed nextjs, you can check it out.
This is the idea:
To allow github devs to save some repos that they may have come across and are interested in but didn't have the time to check them out so that they might check them later.
Sorry I did not explain that earlier. I hope I have given you insight to contribute. I'll really appreciate it if you do.
Thanks


Implement batched merging for the submit queue.

A commandline option specifying a Prow data endpoint is used to collect
results for batch tests. If a batch has passed all necessary tests and
is applicable given the current state of the repo, it will merge all
included PRs at once, without individually testing them.
This batch goroutine runs in parallel with the normal goroutine that
processes PRs sequentially. A mutex guards the critical section for merges
to avoid conflicts.

This change is

The general idea looks excellent, but needs more comments and explanation.


Consider following a source code style guide

The conventions for Python source code are defined in the PEP 8 -- Style Guide for Python Code.
The pylint can be used for checking the source code conforms to this standard.

Following the PEP8, in progress! Will close the Issue when done.


test(client): add coverage for tracing and logging at the same time

Related: https://github.com/prisma/prisma/pull/16748

Closing to clean up the open PRs list.


[Feature Request]: FYI Doc update

🔎 Search Terms
esModuleInterop
The vision
For those of you who may be struggling to get Winston to work in a Typescript environment:
PLEASE NOTE:
File transports (among other features) would not function for me until

Changed the winston reference to - import winston from 'winston' in my logging.ts
Added the "esModuleInterop": true, in my tsconfig.json.

My feature request is to add some documentation that elaborates on above, to help expand the usefulness of this lib to Typescript users.
Thanks!
Use case
No response
Additional information
No response

Spent quite some time searching google for an answer to the odd behavior and found nothing. Hence the above Doc request. Hope this helps someone.

More input FWIW: I am sure I don't fully understand the scoping rules of const in a typescript environment...
Even if you use above suggestions.
const logger = winston.createLogger( {... my options with filetransports })
const sawMill = new winston.Container();
sawMill.add('oak', logger);
sawMill.get('oak').error('This message will not make it to the files')
HOWEVER:
Using the container add directly with an anonymous object inline DOES work.
sawMill.add('oak',  {... my options with filetransports })


Jsdoc ... should parse lower precedence than union

// @noEmit: true
// @allowJs: true
// @checkJs: true
// @strict: true
// @Filename: a.js

/** @param {...string|Array} rest */
function f(...rest) {
    rest
}

Expected behavior:
Rest is of type  (string | any[])[]
Actual behavior:
Rest is of type  (string[] | any[])
Only one ... is allowed, at the beginning of a parameter, so a lot of authors reasonably assume that it has very low precedence.

Fixed by #22661


Release 0.3.0

Curl 7.69.0 has been released: https://github.com/curl/curl/releases/tag/curl-7_69_0
It includes this change: https://github.com/curl/curl/commit/7fc63d72333a36225d39c5b5624df29217136c12 and that requires a version of quiche with https://github.com/cloudflare/quiche/pull/340 - and no such release of quiche has been made yet.
Can you please release quiche 0.3.0 so there is a released version of quiche that works with the latest version of curl?

handclap

However, the latest version is draft-27

I just published https://github.com/cloudflare/quiche/releases/tag/0.3.0 :tada:

@ghedo 0.3.0 is not available on crates.io: https://crates.io/crates/quiche/0.3.0
Did you publish it?
I also noticed that one of the builds failed: https://github.com/cloudflare/quiche/runs/505575333

Ah, sorry I got distracted. It's published now.
The build failure is due to a new clippy releases that added new warnings, it's innocuous, but https://github.com/cloudflare/quiche/pull/415 should fix the problem.