1.0

Hi there!
How close is a 1.0 release?
I have a few days to spare, so if there is something I can do to help, let me know!
I'll start by checking out the code and get a feel for it :smile:

Wow, I really appreciate the offer :)
There are a bunch of breaking changes I want to make before 1.0. I also want to rename the project to something more catchy like MobX did (switching from Mobservable). See the Projects tab for a broad outline.
If you're interested in helping out, I ordered the cards in the backlog in ascending order of difficulty, and I can elaborate on the design goals if you decide to tackle them. No pressure though :)

Here is a braindump for potential project names and punchlines
-- State puns --
federation.js - the best way to manage your state
decentralized.js - the best way to manage your state
president.js - the best way to manage your state
monarch.js - the best way to manage your state
republic.js - the best way to manage your state

--React / flux / mobX name plays--
xact.js - a faster, stronger, easier mobX

-- other --
infer.js
deduce.js
compose.js
fragment.js
catalysis.js
synthesis.js

Curious why not leave it derivable? I really like the name.
On Tue, 25 Apr 2017 at 12:05 Oskar Börjesson<EMAIL_ADDRESS>wrote:

Here is a braindump for potential project names and punchlines
-- State puns --
federation.js - the best way to manage your state
decentralized.js - the best way to manage your state
president.js - the best way to manage your state
monarch.js - the best way to manage your state
republic.js - the best way to manage your state
--React / flux / mobX name plays--
xact.js - a faster, stronger, easier mobX
-- other --
infer.js
deduce.js
compose.js
fragment.js
catalysis.js
synthesis.js
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ds300/derivablejs/issues/60#issuecomment-296983037,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAB3gknjwNAYn4q-71DN9HrzXbMEMA55ks5rzcVUgaJpZM4NBv5k
.

I've talked to a few smart people who think it is not catchy enough and sounds too mathsy. In hindsight I agree. @oskbor thanks for the suggestions. I really like xact, but it is already taken on npm :(

Hi, @ds300 ! How can we help with moving current version out of beta? Currently installing confuses. We should add resolutions for dependencies when using react-derivable.

Sorry to hear that. I think the only thing that needs doing is updating the docs. At this point I'd be happy with normal markdown docs. It would be great to have someone help with that!

Updates on this? Also happy to help.

@eranimo we will appreciate the help with docs.


Major code re-factor, runtime improvement by over 347%.

Code now return all the build before the user even inputs the constraints.
(This is actually my first ever honest-to-god Pull Request, literally)

o wow


istio_init 1.4.0 not found

Hello! I'm trying to upgrade Istio on my kubernetes cluster to version 1.4.0, but after upgrade docker can't find auto-injected sidecar init container (docker.io/istio/proxy_init:1.4.0). Could you please add proxy_init:1.4.0 image to docker registry?

This is working as intended, we removed this image. You should use proxyv2 as our installation does

Sorry to bother you, I have my values.yaml messed up. Thanks!


Opening a transaction will freeze all other db transactions

When opening a transaction, any other Put operation will freeze the execution:
To reproduce the issue create a simple go module:
go mod init leveld-issue
go get github.com/syndtr/goleveldb/leveldb
# add main.go from below
go run main.go

package main

import (
	"fmt"

	"github.com/syndtr/goleveldb/leveldb"
)

func main() {
	fmt.Println(" => opening db")
	db, _ := leveldb.OpenFile("db", nil)
	defer db.Close()

	transaction, _ := db.OpenTransaction()
	defer transaction.Discard()

	fmt.Println(" -> [transaction] putting A1")
	transaction.Put([]byte("A1"), []byte("value"), nil)

	// now even if we want to put something into the database
	// it will freeze!
	// if `db.Put(...)` is removed, the program will run fine ...
	fmt.Println(" -> putting A2")
	db.Put([]byte("A2"), []byte("value"), nil) // <-- will freeze here!

	// will never be reached
	fmt.Println(" -> [transaction] commit")
	transaction.Commit()
}

Okay, thanks for clarifying 👍


Customizations to plots

Description
Enable customization to plots such as defining transparency, fill color, line color etc.

The plotting library already supports customizing fill/stroke color/opacity/line-dash for both marks and guides (reference lines).
See https://wave.h2o.ai/docs/api/ui#mark
For example, ui.mark(..., fill_color='#ff0000', fill_opacity=0.5, ...).
Or shorter: ui.mark(..., fill_color='rgba(255,0,0,0.5)', ...).
There are no plans to support shadows or gradients. Ref chartjunk.


X-Content-Type-Options header set to incorrect value

Hi
X-Content-Type-Options is incorrectly set to 1 (the on/off value from the settings screen) instead of 'nosniff' - the only correct value.
GET / HTTP/1.1
Host: www.pontofx.com

HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: no-cache, private
Date: Wed, 16 Sep 2020 23:37:31 GMT
Strict-Transport-Security: max-age=2592000
Referrer-Policy: strict-origin-when-cross-origin
X-Frame-Options: deny
X-Content-Type-Options: 1
X-XSS-Protection: 1; mode=block
Set-Cookie: october_session=eyJpdiI6Im9jdG5nR3BEYVdlaUhVSEthYXM5a0E9PSIsInZhbHVlIjoiK2dTRVhGR1wvN0piQ2lwMDlKQ1h6ZmoyeFkwUktEUHZkaUtibG1HMTQ5blpINmFlTlwvNGlwVGRXXC9yWTBrZUNDcDBJeTR1YzNtT2trd0ZXRkJaVzl0Uk9uV1BsS1Nmb1gzaHJmUGJoaVpOUG9qMmJzZllLS0dRbTdBTEptbk54eEciLCJtYWMiOiJkNmFiZjdhMTk3NWRkYWFlOWQwYjMwMjFlMjIxYmFiZDIwMGMyNmQ4ZWM1ZDhmOGE5YTAxZWU4YTM0ZmRiYmY5In0%3D; expires=Thu, 17-Sep-2020 01:37:31 GMT; Max-Age=7200; path=/; secure; httponly; samesite=strict

This can be fixed by changing line 121 in file classes/HeaderBuilder.php to
return new HttpHeader('X-Content-Type-Options', 'nosniff');

Whoops, looks like I forgot to change that after modifying how the miscellaneous header settings are stored. After the update is finished building and the update is installed, you may have to re-save your settings to clear the cache and activate the new value.


Support struct with slice of primitives

Thanks, I will take a look tomorrow. Theoretically this should be fixed by https://github.com/cristalhq/aconfig/pull/129 if you can test this change that would be awesome (I assume you have a (test-)case for that 😉 )

Thanks, I will take a look tomorrow. Theoretically this should be fixed by #129 if you can test this change that would be awesome (I assume you have a (test-)case for that 😉 )

Thank you @cristaloleg, I've tried to port the test I wrote to your branch but I got the same panic from mii function.

Can you share the test log, please?

=== RUN   TestSliceOfStructsWithSliceOfPrimitives
--- FAIL: TestSliceOfStructsWithSliceOfPrimitives (0.00s)
panic: bool true [recovered]
	panic: bool true

goroutine 68 [running]:
testing.tRunner.func1.2({0x1024f2380, 0x140001d9240})
	/opt/homebrew/opt/go/libexec/src/testing/testing.go:1389 +0x1c8
testing.tRunner.func1()
	/opt/homebrew/opt/go/libexec/src/testing/testing.go:1392 +0x384
panic({0x1024f2380, 0x140001d9240})
	/opt/homebrew/opt/go/libexec/src/runtime/panic.go:838 +0x204
github.com/cristalhq/aconfig.mii({0x1024f0e40?, 0x1025f2108?})
	/workspace/aconfig/reflection.go:395 +0x100
github.com/cristalhq/aconfig.m2s(0x10250eca0?, {0x10250eca0?, 0x140001cd3e0?, 0x1?})
	/workspace/aconfig/reflection.go:366 +0x400
github.com/cristalhq/aconfig.(*Loader).setFieldData(0x1024f9ca0?, 0x140001eca50, {0x1024efd00, 0x140001e24b0?})
	/workspace/aconfig/reflection.go:204 +0x83c
github.com/cristalhq/aconfig.(*Loader).loadFile(0x140001f1320, {0x1024acfa0, 0x2a})
	/workspace/aconfig/aconfig.go:376 +0x318
github.com/cristalhq/aconfig.(*Loader).loadFiles(0x140001f1320)
	/workspace/aconfig/aconfig.go:330 +0xfc
github.com/cristalhq/aconfig.(*Loader).loadSources(0x140001f1320)
	/workspace/aconfig/aconfig.go:265 +0x7c
github.com/cristalhq/aconfig.(*Loader).loadConfig(0x140001f1320)
	/workspace/aconfig/aconfig.go:241 +0x68
github.com/cristalhq/aconfig.(*Loader).Load(0x101000100?)
	/workspace/aconfig/aconfig.go:231 +0x6c
github.com/cristalhq/aconfig.TestSliceOfStructsWithSliceOfPrimitives(0x140001dcd00?)
	/workspace/aconfig/aconfig_test.go:1568 +0xc4
testing.tRunner(0x140001dd040, 0x102520688)
	/opt/homebrew/opt/go/libexec/src/testing/testing.go:1439 +0x110
created by testing.(*T).Run
	/opt/homebrew/opt/go/libexec/src/testing/testing.go:1486 +0x300

FAIL	github.com/cristalhq/aconfig	0.125s

@cristaloleg Can we push this fix to the current parser and port it later to the new parser PR?

Yeah, totally agree. Will merge & release a new version. Thanks!

Here we go https://github.com/cristalhq/aconfig/releases/tag/v0.18.2

@cristaloleg Thank you Oleg, appreciate it


Small cleanup of  TemporalConvolution.lua

Cleaner way of what fbesse was doing (thanks fbesse!) and typo fix

Thanks Natalia.


Can benchmarking functionality have used externalities extensions?

Having a talk with @cheme about externalities, it appears that a lot of the optional host functions that can be used in some context and not others are declared as:
#[cfg(feature = "std")]
sp_externalities::decl_extension! {
	/// An externalities extension to submit transactions to the pool.
	pub struct TransactionPoolExt(Box<dyn TransactionPool + Send>);
}

But it seems like the benchmarking code is declared right into the main trait Externalities.
Why is this? could it have been done otherwise?

No. It currently could not. The problem is that you need access to the overlay and that overlay is already part of the object that implements the externalities crate. However, if we move everything over to just use extensions, we probably could do the switch for benchmarking to have their own extension and I would like this.

You are talking specifically about these functions here?
https://github.com/paritytech/substrate/blob/c8653447fc8ef8d95a92fe164c96dffb37919e85/primitives/externalities/src/lib.rs#L282-L287
We could try feature gating them at least. But that would introduce the runtime-benchmarks feature into some crates which normally dont have it, like sp-state-machine.
Do you think its worth it?

I don't think it is wort it. I would like to solve it as I pointed it out above.


Resource Map with dynamic resources, with wildcards and options for how to pay

Write a class that can keep track of "resources", i.e. Int values that can change over time and can be influenced by other effects.

Also support wildcards, so that you can have a resource that counts as "one of X/Y/Z" (such as a wildcard in Splendor).
Some resources can even count as "all of X/Y/Z" or "two of X/Y/Z" (so if you use/remove the X one, you will have "one of Y/Z" left)
Different games may have different options for how to pay. So support priorities within the resources (to make wildcards be used first/last for example), and add a way to find out "How can I pay 3 X and 1 Y?"
Listeners and modifiers for when values are changing ("Whenever X changes by Y, gain 1 extra")

This class should be able to replace Caravan in Spice Road, and Money in Splendor.
This class can be created individually and can be posted for review.

Wildcards and resources that counts as "one of" or "all of" is currently no need to support, and I also see a very limited use-case for that. There might be some use-cases for it, but it is more coupled with actions than with resource maps themselves.
Listeners have a high potential use-case in for example in Alchemists, to things like "When you gain reputation, gain one more reputation" (although that also kinda includes a modifier)
Modifiers have a use-case in Cardshifter-like games and for potential advanced rules for other games, such as Splendor: "For the next 3 turns you have 1 wildcard to use"


Create unit_test.py

Created unit test file, maybe it will need some changes later.

Did some changes in the code

Actually, I added the assert statement.

The last file, used a different method and latter on I checked that the HW states that we should include assert.

Hi Arif , in you code, the expected periodic times provided in the test cases are incorrect according to the formula for a simple pendulum.

@reshnashrestha You are correct, thank you. But it is not finalized yet.
Thanx anyway,

@uarif yeah. I tried to run this. Okay hope you fix it soon.


Current location

Proposal for #33

I like how this works.
The way this is plugged into the geocoding results is a little hacky though I think. If I may, I would re-organize a little to make better use of typescript's type system.

Sure, of course, please feel free to rewrite it :)

Okay, I've re-factored some parts. I don't understand the remaining TODO though. If you feel that this is ready to be merged go ahead please. 😀

Thanks!

I don't understand the remaining TODO though.

Will remove this. The TODO does not belong into this branch. Only for my experimental navi branch where I continuously request the location after this (initial) location request.

Only for my experimental navi branch where I continuously request the location after this (initial) location request.

I see. I had accidentially checked out this branch at some point and was confused how complicated the current location selection was :-)


Shallow copy in use_state

Since the users have to create a shallow for the __eq__ check in use_state to be sensible we might as well just create a shallow copy of the state variable so that the user doesn't have to copy the object themselves.

This is a good idea but I'm inclined to not do it. I think it's less confusing when we expose all this machinery explicitly and explain what's happening.

React forces the users to understand and use shallow-copy https://react.dev/learn/updating-arrays-in-state
When in doubt, I like to do it the way React does it.


Chat Completion Readable Stream

Is this function already implemented?

Example code:
// https://github.com/dexaai/openai-fetch
import { OpenAIClient, type ChatParams } from 'openai-fetch';

let partialResponseText = ''

async function readStreamChunks(stream: ReadableStream, cb: Function) {
    const reader = stream.getReader();

    // A function to handle reading each chunk
    async function read() {
      const { done, value } = await reader.read();
      if (done) {
        cb();
        return;
      }

      console.log('delta chunk response', value.choices[0].delta.content)
      partialResponseText += value.choices[0].delta.content
      console.log('concat partial response', partialResponseText)

      // Recursively read the next chunk
      read();
    }

    // Start reading
    read();
  }

const readableStream: ChatStreamResponse = await client.streamChatCompletion({
    model: "gpt-4-turbo-preview",
    messages: [
        {
            role: "system",
            content: "Tell me a story about openai-fetch, a library that can stream OpenAI responses."
        },
    ],
    temperature: 0.7,
    n: 1,
} as ChatParams);

// start reading the stream
readStreamChunks(readableStream, () => {
    console.log('full response ready', partialResponseText)
})


Support for Userns Mode

This PR adds support for HostConfig.UsernsMode.

published a new release including this pr https://github.com/softprops/shiplift/blob/master/CHANGELOG.md#050


Studio not working

I got this message

@MaximumADHD please fix it

I encountered the same issue, but it's working again now... probably something else

Same thing happens to me, it happens like 95% of the time. Force Reinstallation fixes it, however, it only fixes it for only that session.

Make sure you have the latest mod manager version installed. This has been patched.

It works now thank you

Necvermind it broke again

Try forcing a reinstall @DionBlox1?

Still no work

I encountered this on eed5f2d and b09aca1

Can you guys elaborate on what's happening?
Is it throwing an exception, is it just never starting?
I need more information to see if I can reproduce it on my end.


mlc-llm build error

I was wondering if you could provide some advice or pointers on how to deal with the following error when building mlc-llm. It seems that the only file that doesnt build properly is mlc-llm-cli:
In file included from /usr/include/string.h:535,
                 from /home/ubuntu/mlc-llm/3rdparty/tokenizers-cpp/sentencepiece/src/../third_party/protobuf-lite/google/protobuf/stubs/port.h:39,
                 from /home/ubuntu/mlc-llm/3rdparty/tokenizers-cpp/sentencepiece/src/../third_party/protobuf-lite/google/protobuf/stubs/macros.h:34,
                 from /home/ubuntu/mlc-llm/3rdparty/tokenizers-cpp/sentencepiece/src/../third_party/protobuf-lite/google/protobuf/stubs/common.h:46,
                 from /home/ubuntu/mlc-llm/3rdparty/tokenizers-cpp/sentencepiece/src/../third_party/protobuf-lite/google/protobuf/message_lite.h:45,
                 from /home/ubuntu/mlc-llm/3rdparty/tokenizers-cpp/sentencepiece/third_party/protobuf-lite/message_lite.cc:36:
In function ‘void* memcpy(void*, const void*, size_t)’,
    inlined from ‘google::protobuf::uint8* google::protobuf::io::EpsCopyOutputStream::WriteRaw(const void*, int, google::protobuf::uint8*)’ at /home/ubuntu/mlc-llm/3rdparty/tokenizers-cpp/sentencepiece/src/../third_party/protobuf-lite/google/protobuf/io/coded_stream.h:699:16,
    inlined from ‘virtual google::protobuf::uint8* google::protobuf::internal::ImplicitWeakMessage::_InternalSerialize(google::protobuf::uint8*, google::protobuf::io::EpsCopyOutputStream*) const’ at /home/ubuntu/mlc-llm/3rdparty/tokenizers-cpp/sentencepiece/src/../third_party/protobuf-lite/google/protobuf/implicit_weak_message.h:85:28,
    inlined from ‘bool google::protobuf::MessageLite::SerializePartialToZeroCopyStream(google::protobuf::io::ZeroCopyOutputStream*) const’ at /home/ubuntu/mlc-llm/3rdparty/tokenizers-cpp/sentencepiece/third_party/protobuf-lite/message_lite.cc:419:30:
/usr/include/aarch64-linux-gnu/bits/string_fortified.h:29:33: warning: ‘void* __builtin___memcpy_chk(void*, const void*, long unsigned int, long unsigned int)’ specified size between<PHONE_NUMBER>1562067968 and<PHONE_NUMBER>3709551615 exceeds maximum object size<PHONE_NUMBER>854775807 [-Wstringop-overflow=]
   29 |   return __builtin___memcpy_chk (__dest, __src, __len,
      |          ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
   30 |                                  __glibc_objsize0 (__dest));
      |                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~

I have never seen this warning before... But based given warning message, you may try omit that warning flag?

After following the build instructions on mlc llm's website I realized that this no longer compiles a mlc-llm-cli file. The guide instead sets up an alias for calling mlc llm in python which I was able to get working.


Consistent seed handling

In CityEngine, we compute a random seed for a shape once based on its geometry. After that, the user can freely change the seed, but there is no way to reset the seed to its initial value implicitly (i.e. you have to explicitly remember the initial seed and manually set it to achieve a reset).
Essentially, the seed is an attribute that is always in override mode (as described in #50) and initialized to a random seed.
In serlio, we are not consistent, but use different seeds to compute the default attribute values and generate models. As far as I could see, the random seed for generating the models even relies on uninitialized memory (i.e. it just uses whatever value is returned from an uninitialized plug).
Task:

Ensure that the seeds for both default attribute computation and model generation are always the same.
Make the behavior of the seed consistent with CityEngine.

Internal ticket CE-7381

Fixed in v2.0


Add localization example to custom-environments

Is your feature request related to a problem? Please describe.
As developers for non native English need the tutorial to localize the Studio Lab interface.
Describe the solution you'd like
We can localize the interface by using jupyterlab -language-pack.
We will introduce how to install and setup the language pack.
Describe alternatives you've considered
None
Additional context
I will create the pull request for this issue.

Great suggestion!

I added the example.


Option to disable "Clear cookies and site data when you close all windows"

Description
Option to disable "Clear cookies and site data when you close all windows"
Who's implementing?

[ ] I'm willing to implement this feature myself

The problem
Makes it possible to disable this setting through options. This will be useful when using --app
Possible solutions
Option to disable it
Alternatives
Patch to disable prefs-only-keep-cookies-until-exit.patch
Additional context
No response

https://ungoogled-software.github.io/ungoogled-chromium-wiki/faq#why-do-i-have-to-login-to-websites-every-time-i-open-ungoogled-chromium

https://ungoogled-software.github.io/ungoogled-chromium-wiki/faq#why-do-i-have-to-login-to-websites-every-time-i-open-ungoogled-chromium

how can I turn it off using the options? I need this because I'm using ungoogled-chromium with --app

how can I turn it off using the options?

As you would usually do this.

As you would usually do this.

I created this pr because there is no such thing in ungoogled-chromium

how can I turn it off using the options? I need this because I'm using ungoogled-chromium with --app

chrome://settings/cookies takes one to this screen:

where you can unselect the setting.

where one can unselect the setting.

I mean command line options

If you turn it off in the options screen, it will also be turned off when you launch Chromium "with --app" next time. This setting is saved to your Chromium profile.

I'm using ungoogled-chrome in app (or kiosk) mode. this means that I don't want to force users to change this setting manually, I want a command line option for this

I'm using ungoogled-chrome in app (or kiosk) mode. this means that I don't want to force users to change this setting manually, I want a command line option for this

Your options are:

Submit PR with this option exposed via commandline for a review
Patch ungoogled-chromium locally while building to change the default
Use another browser, which has this enabled by default


Name not globally unique

App Insights names can be duplicated, so long as they are in different Resource Groups.
They do not have to be globally unique.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ef53756a-035b-7630-6f91-a016805c526e
Version Independent ID: 7d54b530-6eb1-5430-8a5b-27c335f5baec
Content: Create a new Azure Application Insights resource
Content Source: articles/azure-monitor/app/create-new-resource.md
Service: azure-monitor
Sub-service: application-insights
GitHub Login: @mrbullwinkle
Microsoft Alias: mbullwin

@jn-altius Thank you for the feedback!  We are investigating this and will get back to you shortly.

The one advantage of globally unique resource names is that it simplifies cross resource queries, whereas if you have duplicate names you need to use a fully qualified name in your queries since it can't disambiguate the resource by name alone and the query would otherwise fail. Your point though is absolutely correct, I will update that section to make clear why we recommend globally unique names even though it is technically not required.

I have updated the doc internally. The change will go-live in the public repo later today.

#please-close


Write a TypeScript program to convert minutes to weeks

Description
Write a TypeScript program to convert minutes to weeks
1 week = 7 days = 168 hours = 10080 minutes
Input  : 50400
Output : 5

How to contribute

Save the solution in ConvertMinutesToWeeks.ts file
Add ConvertMinutesToWeeks.ts file in convert-minutes-to-weeks folder

!assign


Az command couldn't use classic deployment model

section : Enable the diagnostics extension if you use the classic deployment model
I think classic deployment model can't use Az command.
But the example which include the section use Az command.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 1004d268-8e8b-a08c-f31d-5b099cb38132
Version Independent ID: 732f5f54-eb4b-97f3-a46a-d07825bd3e34
Content: Use Azure PowerShell to enable diagnostics on a Windows VM
Content Source: articles/virtual-machines/extensions/diagnostics-windows.md
Service: virtual-machines-windows
GitHub Login: @sbtron
Microsoft Alias: saurabh

@kensugasa Thank you for your feedback . We will investigate and update this thread further.

@kensugasa Thanks for the feedback.
You are correct. We will update the document.

Thank you for your replying!
I'm waiting for the fixing.

@kensugasa  $Storage_Context is not defined anywhere. When you tried, Did you set any value to that variable outside of the script?

Updated the script to reflect the suggested changes

I submitted a pr to change the commands.  Changed will reflect in hours.

Changes are reflecting now. I am closing the issue now


Closure conversion: for loops

Closure conversion needs to support capturing the for-loop variable and pay special attention to the fact that a new variable is introduced per iteration.

Proposed fix in CL 520497013.

Fixed by 34036c5aac323fe251db558ab9986eaa06408602.

The fix wasn't correct.
@asgerf has made a test that demonstrates why.
The problem is that other initializers can capture previously defined loop variables, and that updates can also capture loop variables. For example:
  var closure;
  for (var i=0, fn = () => i; i < 3; i++) {
    i += 1;
    closure = fn;
  }
  Expect.equals(1, closure());

Fixed by 6b464934860f5898ea71285306096ff60bad4563.


PlugCapture and PlugContext

@josevalim if you don't mind taking a peek 🙂

Looks great! I have dropped just one minor comment. Two other suggestions are:

You are testing last_event_id_and_source in PlugCapture but you may also want to test it directly when calling Sentry.capture_exception directly

I would remove phoenix as a dependency. Potentially bump the plug_cowboy dependency to "~> 2.3" since we will need it for excluding domains (or do it in another PR)


GS/DS Output panel is empty even though geometry shader is used in Vulkan when using Multi View

Description
Mesh Viewer -> GS/DS Output panel is empty even though geometry shader is used in a Vulkan 1.3 app. But only when Multi View rendering is used.
I have created a simple pass-through geometry shader. It takes 1 triangle and outputs 1 triangle with the same attributes - only changes gl_Position so I can be sure that geometry shader actually did something. The output of the fragment shader is exactly as expected if the geometry shader did its work. All other panels (VS Input and VS Output) show expected data. GS/DS Output shows nothing but column headers: VTX, IDX, _sig13._child0, ... (some of them, duplicated - see screenshot below). GS/DS Out panel under Preview (the one used for preview of 3D data) shows no data as well.
However, this happens only when Multi View rendering is used. I have 2 passes for G-buffers and 1 actual pass for swapchain (each is implemented as a separate render pass with a single subpass). G-buffer passes (using only off-screen color framebuffer attachments/render targets) use Multi View rendering (in my case 10 draws of the same scene with different view matrices provided by UBO). Each draw outputs to a separate layer of the image. Multi View works flawlessly. When I used a similar pass-through geometry shader in my only color pass that provides the final color for swapchain image, and which does not use Multi View, GS/DS Output panel worked without problems. This panel displays data also in case I change my G-buffer draws from Multi View to standard  (single-layer) ones. Using Multi View with a single layer does not help.
There are no warnings or errors provided by validation layers. Device features for GeometryShader, Multiview as well as MultiviewGeometryShader are all available and turned on.
Screenshots:
VS Output
GS/DS Output
Geometry shader code:
#version 450
#extension GL_KHR_vulkan_glsl : enable
#extension GL_EXT_multiview : enable

layout (triangles) in;
layout (triangle_strip, max_vertices = 3) out;

// IN attributes (from VS)
layout (location = 0) in vec3[] inWorldPos;
layout (location = 1) in vec3[] inNormal;
layout (location = 2) in vec3[] inColor;

// OUT attributes (to FS)
layout (location = 0) out vec3 outWorldPos;
layout (location = 1) out vec3 outNormal;
layout (location = 2) out vec3 outColor;

void main()
{
    gl_Position = gl_in[0].gl_Position + vec4(2, 2, 0, 0);
    outWorldPos = inWorldPos[0];
    outNormal = inNormal[0];
    outColor = inColor[0];
    EmitVertex();

    gl_Position = gl_in[1].gl_Position + vec4(1, 1, 0, 0); // this is used intentionally for obvious distortion of image
    outWorldPos = inWorldPos[1];
    outNormal = inNormal[1];
    outColor = inColor[1];
    EmitVertex();

    gl_Position = gl_in[2].gl_Position + vec4(2, 2, 0, 0);
    outWorldPos = inWorldPos[2];
    outNormal = inNormal[2];
    outColor = inColor[2];
    EmitVertex();

    EndPrimitive();
}

Steps to reproduce
I have shared a capture file via provided e-mail.
I am not aware of doing anything special in my app so reproduction steps should be as straightforward as creating Vulkan 1.3 app with a simple pipeline consisting of VS, GS, and FS and using Multi View rendering. GS can be as simple as pass-through (see code above). Run app in RenderDoc 1.18 or 1.19 and look at Mesh Viewer -> GS/DS Output panel which is empty. Turn off Multi View rendering and GS/DS Output should have data in it.
Environment

RenderDoc version: stable 1.18 and 1.19 (versions 1.17 and lower do not support Vulkan 1.3 so I could not test it)
Operating System: Windows 11
Graphics API: Vulkan 1.3

I am running RTX 3070 Ti with driver version 512.59.

This is unfortunately due to effectively a hardware/implementation limitation. Geometry and tessellation shader outputs are only available in RenderDoc via transform feedback, and transform feedback cannot be used with multiview. Unless a new extension is provided in future to allow this it won't work in RenderDoc, and I don't expect that to ever happen.
In theory for geometry shaders with no expansion and providing there's no tessellation active, it would be possible to implement the mesh output without using transform feedback as is done for vertex shaders. However given that geometry shaders are used rarely at best, and I would imagine their use with multiview even rarer still, this is so niche a case that I don't think I would even accept a pull request of an implementation that does that given the tradeoff of code complexity vs benefit.

That is totally understandable. However, it would be nice to at least show something along the lines "GS/DS Output is not supported when Multi View is used". I have spent hours wondering why my GS provides no output.


CAMEL-11716: Fix sql-stored to return result from function call

Thanks the PR has been merged :-) Can you close this?

Closed has merged.


[WIP] Debian10 support

This upgrades the systemvmtemplate base to Debian 10 with openjdk-11.
Fixes #3654
Prev. https://github.com/apache/cloudstack/pull/3797
Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✔debian. JID-1246

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✔debian. JID-1248

Trillian test result (tid-1571)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 40626 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4104-t1571-kvm-centos7.zip
Intermittent failure detected: /marvin/tests/smoke/test_routers_network_ops.py
Intermittent failure detected: /marvin/tests/smoke/test_vpc_redundant.py
Smoke tests completed. 82 look OK, 1 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL
Failure
356.68
test_vpc_redundant.py

test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers
Failure
342.19
test_vpc_redundant.py

@rhtyd can you incorporate teh change in #3921 in this one?

@Spaceman1984 can you merge/push your PR commits (or patch https://patch-diff.githubusercontent.com/raw/apache/cloudstack/pull/3921.patch) to this branch?

Looks like testing with kvm passed, we'll need to kick tests against other hypervisors manually from Trillian.
@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✖centos7 ✖debian. JID-1277

@blueorangutan package

@rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress.

Packaging result: ✔centos7 ✔debian. JID-1287

Kicked matrix smoketests on jenkins by overriding the built systemvmtemplates

The systemvmtemplate build log: http://download.cloudstack.org/systemvm/4.15/build.log
Public URL for dev-testing until GA: http://download.cloudstack.org/systemvm/4.15/

@rhtyd I have two concerns
(1) does Trillian use new debian10 template in tests ?
(2) is python2 or python3 installed in debian10 ?

Hi @weizhouapache

Trillian by default uses branch/version specific systevmtemplates, but allows option to override. For testing this PR, I'm not using BO but passing systemvmtemplate overide on our internal Jenkins. This gives us ability to test a PR with a new systemvmtemplate.
Currently, no python3 is not installed in this PR. Are you/anyone-else working to migrate VR scripts from py2 to py3, then I can make changes in this PR to install python3 (make the template future ready).

Trillian test result (tid-1619)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 38950 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4104-t1619-kvm-centos7.zip
Intermittent failure detected: /marvin/tests/smoke/test_kubernetes_supported_versions.py
Smoke tests completed. 82 look OK, 1 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_01_add_delete_kubernetes_supported_version
Error
1807.60
test_kubernetes_supported_versions.py

Trillian test result (tid-1620)
Environment: vmware-67u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 59548 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4104-t1620-vmware-67u3.zip
Intermittent failure detected: /marvin/tests/smoke/test_deploy_vm_root_resize.py
Intermittent failure detected: /marvin/tests/smoke/test_vpc_redundant.py
Smoke tests completed. 83 look OK, 0 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

Hi @weizhouapache

Trillian by default uses branch/version specific systevmtemplates, but allows option to override. For testing this PR, I'm not using BO but passing systemvmtemplate overide on our internal Jenkins. This gives us ability to test a PR with a new systemvmtemplate.
Currently, no python3 is not installed in this PR. Are you/anyone-else working to migrate VR scripts from py2 to py3, then I can make changes in this PR to install python3 (make the template future ready).

@rhtyd nice, thanks.
let's merge it, and upgrade to python3 in systemvm template along with python2->python3 support (it seems to be part of centos8 support).

@weizhouapache

I checked python3 was already installed on the built systemvmtemplate, but I've added explicit pkg to be installed
python2->3 migration is not done in the centos8 support PR; the systemvm continue to be on Debian where python2 ships by default (with the python package)

code lgtm
did not test it

Trillian test result (tid-1638)
Environment: xenserver-71 (x2), Advanced Networking with Mgmt server 7
Total time taken: 64333 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr4104-t1638-xenserver-71.zip
Intermittent failure detected: /marvin/tests/smoke/test_kubernetes_clusters.py
Intermittent failure detected: /marvin/tests/smoke/test_scale_vm.py
Intermittent failure detected: /marvin/tests/smoke/test_vpc_redundant.py
Smoke tests completed. 80 look OK, 3 have error(s)
Only failed tests results shown below:

Test
Result
Time (s)
Test File

test_05_deploy_and_upgrade_kubernetes_ha_cluster
Failure
1863.68
test_kubernetes_clusters.py

test_01_scale_vm
Failure
24.62
test_scale_vm.py

test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL
Failure
459.52
test_vpc_redundant.py

test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers
Failure
403.47
test_vpc_redundant.py

Checked test failures not related to this PR on XenServer, overall all tests have passed.


show dynamic badge examples with a base

this makes them a bit nicer to copy & paste

Messages

:book:
:sparkles: Thanks for your contribution to Shields, @chris48s!

:book:

Thanks for contributing to our documentation. We :heart: our documentarians!

  Generated by :no_entry_sign: dangerJS

I guess this isn't showing up in the review app because there is no baseUrl configured.
The idea of the badge maker is that it'll give you a full URL you can copy and paste. These paths feel like examples which give you the general idea. Even with the prefix, they are not copy-and-paste friendly.
I prefer this without the prefix, though don't want to block this if you feel strongly about it.

(Not that the badge maker is as friendly as it could be.)

Yea, I hear you. I'm fine with that. Though we should definitely make the builder better!
I code on a small laptop, and that region of the page looks especially cluttered in a small browser window.


CommonMark code block class names

This is a very simple fix that changes TypeDoc to follow the CommonMark spec for code blocks:
https://spec.commonmark.org/0.27/ Example: https://spec.commonmark.org/0.27/#example-109
Right now TypeDoc prints out code block prefixes with lang- as the prefix, which is far I understand it, is legacy from Highlight.js. Since TypeDoc uses Highlight.js, lang-, language- and even un-prefixed values are supported... But by enforcing the CommonMark standard developers will be able to leverage other CommonMark tools with TypeDoc.

Looking at the tests and there are a ton of failings in there that are unrelated, looks like the CI environment needs some attention.

The changes you've included so far sound good. Yeah, I'm aware of the test issues. #762 includes some fixes to how the tests are run so they aren't overwritten. I'll need to review why the models changed in the snapshot tests and correct things in a separate PR so leave things as they are until those are fixed.

Sweet. Looks like your markedjs/marked#1265 PR ended the need for this. Thanks for your contributions! The updated specs now use the updated prefix
https://github.com/TypeStrong/typedoc/blob/eace04a441bdd558a859ac84ff78cd8f59775e1c/src/test/renderer/specs/index.html#L78-L81


Extensions inherit the availability of the extended type

Automatically apply the availability of the extended type to its extensions. As such, there is no need to repeat the availability attribute on extensions for them to have the same availability.

@swift-ci Please smoke test

@swift-ci Please test source compatibility

@swift-ci Please smoke test

@swift-ci Please test source compatibility

@swift-ci Please smoke test

@swift-ci Please test source compatibility

Can one of the admins verify this patch?

Please update the base branch to main by Oct 5th otherwise the pull request will be closed automatically.

How to change the base branch: (Link)
More detail about the branch update: (Link)


[breaking] [jvm-packages] Remove rabit check point.

Add numBoostedRound to jvm packages
Remove rabit checkpoint version.
Change the starting version of training continuation in JVM [breaking].
Redefine the checkpoint version policy in jvm package. [breaking]
Rename Python check point callback parameter. [breaking]
Unifies the checkpoint policy between Python and JVM.

The last item is a bit more subtle, the change aligns JVM packages with Python packages. After this PR, training continuation counts iteration from 0 instead of from the previous starting iteration. The checkpointing scheme is changed to use boosting versions. I don't understand the previous versioning scheme, likely a legacy inherited from rabit.

@wbo4958 Could you please help review this when you are available?

GLTM.


Inconsistent tests

Lately I've had to restart the tests in Travis multiple times to get them to pass. I think we have a test that acts wierd. Right now this is the problem:
=== RUN   TestTopic/baz.bar.foo
2018/08/12 22:08:19 client: publishing 2f5b0a93-04e8-4601-9d3d-7a33fe97b018
2018/08/12 22:08:19 client: did publish message
2018/08/12 22:08:19 client: got delivery
2018/08/12 22:08:19 server: got delivery on queue foo.# correlation id 4779bc5b-332e-4fd4-9e49-6c7b5c8720f7
bindings_test.go:104 foo.bar.baz does not equal baz.bar.foo
2018/08/12 22:08:19 server: stopped waiting for messages on queue 'foo.#'
2018/08/12 22:08:19 server: stopped waiting for messages on queue 'foo.*'
2018/08/12 22:08:19 server: stopped waiting for messages on queue 'baz.*'
2018/08/12 22:08:19 server: listener exiting gracefully
--- FAIL: TestTopic (0.09s)
    --- FAIL: TestTopic/foo.bar (0.03s)
    	bindings_test.go:107: foo.# NOT called on foo.bar
    --- FAIL: TestTopic/foo.bar.baz (0.00s)
    --- FAIL: TestTopic/baz.bar.foo (0.00s)
    	bindings_test.go:102: foo.# WAS called on baz.bar.foo with body foo.bar.baz

If I restart the tests it can suddenly pass.

=== RUN   TestTimeout
2018/08/12 22:11:14 server: staring listener: amqp://guest:guest@localhost:5672/
2018/08/12 22:11:14 client: did publish message
2018/08/12 22:11:14 server: waiting for messages on queue 'myqueue'
2018/08/12 22:11:14 server: got delivery on queue myqueue correlation id 795c73c0-dada-422b-bf07-918bb93bf584
2018/08/12 22:11:14 server: got delivery on queue myqueue correlation id ed694979-3696-4b07-8312-4a142d064f43
2018/08/12 22:11:14 client: connecting...
2018/08/12 22:11:14 client: starting up
2018/08/12 22:11:14 client: running publisher
2018/08/12 22:11:14 client: publishing 3d6d38aa-0864-4d61-9d64-22672e8c8076
2018/08/12 22:11:14 client: did publish message
2018/08/12 22:11:14 client: waiting for replies
2018/08/12 22:11:14 client: connecting...
2018/08/12 22:11:14 client: starting up
2018/08/12 22:11:14 server: got delivery on queue myqueue correlation id 3d6d38aa-0864-4d61-9d64-22672e8c8076
2018/08/12 22:11:14 client: could not find where to reply. CorrelationId: 3d6d38aa-0864-4d61-9d64-22672e8c8076
2018/08/12 22:11:14 client: running publisher
2018/08/12 22:11:14 client: publishing 06723efe-2cec-4163-8536-e9de66c5df93
2018/08/12 22:11:14 client: did publish message
2018/08/12 22:11:14 client: waiting for replies
2018/08/12 22:11:14 client: connecting...
2018/08/12 22:11:14 client: starting up
2018/08/12 22:11:14 server: got delivery on queue myqueue correlation id 06723efe-2cec-4163-8536-e9de66c5df93
2018/08/12 22:11:14 client: could not find where to reply. CorrelationId: 06723efe-2cec-4163-8536-e9de66c5df93
2018/08/12 22:11:14 client: running publisher
2018/08/12 22:11:14 client: publishing 7587e272-df4d-45cf-be51-820ca0c6193b
2018/08/12 22:11:14 client: did publish message
2018/08/12 22:11:14 client: waiting for replies
2018/08/12 22:11:14 server: got delivery on queue myqueue correlation id 7587e272-df4d-45cf-be51-820ca0c6193b
2018/08/12 22:11:14 server: stopped waiting for messages on queue 'myqueue'
panic: send on closed channel
goroutine 189 [running]:
github.com/bombsimon/amqp-rpc.(*Server).runHandler.func1(0x6a2348, 0x6c2c00, 0xc4201e8840, 0xc4200c5d90, 0xc4201b5aa0, 0xc4200b6800, 0x6c27c0, 0xc4201b5aa0, 0x0, 0xc420201050, ...)
	/home/travis/gopath/src/github.com/bombsimon/amqp-rpc/server.go:308 +0x170
created by github.com/bombsimon/amqp-rpc.(*Server).runHandler
	/home/travis/gopath/src/github.com/bombsimon/amqp-rpc/server.go:301 +0x22f
FAIL	github.com/bombsimon/amqp-rpc	3.127s

Pretty sure the panic is caused by the fact that I made the delivery handling in separate go routines which makes it possible for the server to close the responses channel before the last response has been pushed to the queue.
I'll add a wait group for this I think, I wonder though what will happen with the one consuming from that channel...
The topic test that fails is weirder thought, I'll have to look into that.

→ amqp-rpc [master] for _ in {1..20}; do GOCACHE=off go test ./... > /dev/null 2>&1 && echo "Exit status: $?"; done
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0

Can't reproduce the first one so I'm closing this with a new commit.


Reconsider basic serialization support

Math.NET Numerics currently does not provide any serialization support out of the box. This is by design, as serialization is very application specific with numerous options. We could never satisfy all use cases and would rather not limit ourselves with design constraints based on the lowest denominator (and have our code crippled with all kind of attributes and helper logic).
However, supporting just one approach on a data-representing types like RunningStatistics, Histogram, and vectors & matrices could make integration much more feasible. Quite a few serializers including FsPickler have a fallback for ISerializable types, so this could be a way forward.
Any thoughts on this?

Here's a rough guide of how you could make a type serializable in FsPickler: http://nessos.github.io/FsPickler/overview.html#Serializable-Types
In C# code, adding SerializableAttribute at the class definition should suffice to make the type serializable by libraries such as BinaryFormatter and FsPickler, provided of course that all of its fields are also of serializable types.
In general, I would recommend against using ISerializable since it's a very error-prone pattern. My pattern of preference is DataContract serialization since you have easy and explicit control of the serialization format. It is also very capable, particularly when combined with OnSerializing/OnSerialized and OnDeserializing/OnDeserialized callbacks. Here's a sample implementation that combines the two in F#.

Math.Net is a library to do calculations in you logic layer.
A Matrix with its Storage class is a quite complex object to serialize in contrast to a DTO.
There is MathNet.Numerics.Data to write (serialize) you matrices and vectors and
most serializes support surrogate types to serialize complex object graphs.
Also notice versioning when doing serialization.
see https://twitter.com/terrajobst/status/662690170425094145

Thanks @tibel for reminding me - yes, this is essentially the reasoning behind the current design.
Maybe for context, this came up in a distributed computing scenario where there is a need to be able to transfer some data structures over the wire between nodes in a simple and efficient way (assuming the same version).

Yes, I think serialization for basic storage types for ephemeral purposes in version-homogeneous distributed computations seems entirely reasonable.

Hi @cdrnet, did you consider Bond? https://microsoft.github.io/bond/why_bond.html
It support multiple ways to serialize, it is lighting fast (it beat the crap out of our structs/unmanaged based solution by more than 4x), it could allow eventually to talk with software written in Python or C++, and shouldn't be too difficult to provide external bindings to the objects themselves.
If you are considering provide a solution for serialization it is a must evaluate.

@redknightlois I don't know of any .NET general purpose libraries (of the kind of Math.NET Numerics) that take dependencies on specific serialization technologies like Bond.
As @eiriktsarpalis describes, for the purposes being discussed here, the appropriate way to specify serialization independent of serialization format is by using the DataContract attributes (ISerializable can also be used if assembly homogeneity between producer and consumer can be assumed)

@dsyme That's why I said that it can be provided as an external binding.
As a user of MathNet myself when I had to serialize we had to write custom providers. We are currently using Bond because for us performance is important, but I also see the flexibility of protocol transcoding could be useful in general.  ISerializable and DataContract aren't really that generic either, so I doubt the real value that can provide I know for a fact it wouldn't have add much value for us at least because it is pretty basic and rigid.

@redknightlois OK, that makes sense.  The email chain that led to this issue was about serialization of inputs, intermediate results and outputs suitable for use in homogeneous distributed computation of the kind supported by http://mbrace.io, which uses FsPickler under the hood.
I agree that in other settings you want to use other serialization formats.

So a way to move forward could be to:

Add DataContract/DataMember attributes for simple ephemeral serialization (higher priority, next minor release).
Extend MathNet.Numerics.Data with extra packages for specific serialization frameworks (e.g. Bond providers, picklers, maybe something for protobuf) for durable serialization - optimized and considering forward and backward compatibility/versioning (lower piority).

DataContract instead of Serializable because to my understanding the latter is not available in any portable profiles nor the vnext stuff.

@cdrnet That's a great plan

DataContracts for RunningStatistics, DescriptiveStatistics and Histogram have been released in v3.9.0.

@redknightlois you mentioned you have already written custom providers for Bond. Assuming we'd provide such providers out of the box (as extra packages, like the data packages). Would such a generic provider in practice be useful in your very specific case, or would you need/want to implement your own providers anyway in order to tweak to your specific Application concerns, and also to keep full control over it?

We built very custom schemas for it, but it could have being far easier if there would have been schemas for basic data types already there. We did go an extra mile and also incorporate some of the ideas that allow Bond to be insanely fast too, but that is another story.


turtle-wow: fix error when auto-dismount is not enabled

Following error shows up when the turtle-wow module is enabled but auto-dismount is disabled:

Closed because I didn't realize adding another commit would also add it to the PR 😛


Fix grpcio_{reflection,health_checking} packaging

Fixes https://github.com/grpc/grpc/issues/12992.
I have tried it out and it seems to work (including looking into the final generated artifacts on our CI infrastructure), but we should make sure to manually test the PyPI packages when we upload the 1.8-rc to ensure nothing break in the process of installation from PyPI to make sure no accidents happen.

I think I understand the issue a little better now thanks!
It looks like the workaround is to pull out grpcio-tools from the dependencies because the protos get compiled as part of our distribution process anyway.
It feels like doing
try:
  import health_commands

is a roundabout way of detecting if we are in the artifact build.  Can we just add an environment variable instead?

@kpayson64 Yes, that is essentially what we do. We could make it an environment variable, but unless there is an existing environment variable we can rely on, my sense is it just "spreads the disease" giving us the illusion that we actually cleaned this hack up (but we simply moved it elsewhere), and then we will have to ensure we propagate the environment correctly, making it more fragile. The import check is a pretty direct way to verify the ground truth directly, instead of relying on an external party to let us know what state we are in (and potentially lie about it).

@mehrdada I would argue that this PR introduces a new mechanism anyways, you are now excluding a file from our distribution as a means of detecting if we are in the github repo or in a packaged distribution.  I'd much rather use a different detection mechanism that isn't so roundabout.

@kpayson64 The *_commands files that are excluded from the distribution should be excluded either way though, as "building" the distributed package is unnecessary and can potentially cause behavior drifts based on the grpcio-tools version installed at the time of build. It's much better to just ship pb2s (which we always did) and don't potentially overwrite them on build. Whether or not using a flag is a good idea, I am just slightly against based on the rationale above, but could be convinced otherwise. I'm interested in hearing what @nathanielmanistaatgoogle thinks about either of the two approaches. (If we end up deciding on a flag, we should also specify where it should be set too.)

6f424b71b35fc1322fc7aa is a great change; pull it out of here and into its own pull request.
When you say "nor would they contain the Python module that does the preprocessing code generation from the respective .proto files", which module is "the Python module that does the preprocessing code generation"? (This may be as simple as changing the prose to read the "_commands" Python module.)
I think I also agree with @kpayson64 about the trigger mechanism here. Is this code drafted in the shape it's in because you wanted to make a minimal change (usually a good thing when fixing a bug)? Could a better change be made by making a deeper cut? Something that strikes me as a decent idea: should "build the _pb2.py file" be a judgement made based on the absence of the desired _pb2.py file, rather than the presence of the <something>_commands module?

Changing the outer build system is an option that is on the table; either in this pull request or another. Is it the right thing to do?

I agree with both comments, the outer build system could use a refactor, but if we want some determinant that exists today, checking for the existence of pb2_grpc.py modules is preferable.

PTAL

Closing in favor of the alternate solution of revamping the build process of health and reflection packages: https://github.com/grpc/grpc/pull/13376

KI: Node interop failures


Reproducing Table 11 for classification

Thanks for this package @JieyuZ2 -- do you happen to have an orchestration script for reproducing Table 11 (and therefore Table 3) in the Wrench paper?

Hey @pmangg
We basically use scripts like this for experiments. Hope that will help!

Hi, @JieyuZ2 . I got a similar problem, and I've tried the search script, but it seems it is still hard to get a fair comparison (meanwhile only part of search spaces are included in the script). Is it possible to offer detailed parameters?

Hey @mrbeann, please see Table 10 of our paper


Keyboard accessibility

This branch was started from release 1.7.13.
Adds keyboard accessibility to the gallery navigation.

Thanks for the PR and wanting to improve Featherlight.
I'm afraid I can't merge this as is though.
First, it's not clear to me why you'd want this; aren't left and right arrow keys more intuitive and convenient?
Second, changing span to a is a breaking change.
Finally, it is not acceptable to rely on the title attribute not being changed by the user.


MRG, BUG: Fix sphere glyphs

Closes #8192
In this PR on mayavi:

pyvista:

these look different but I think it might just be a subtle angle/perspective difference (?), here's a different angle:

@GuillaumeFavelier can you look and see if the difference is meaningful and if necessary push commits to fix it? Also might be a good idea to check the code for any other instances of if/elif/elif and change them to if/elif/else with an assert like I did here (preferably with a user-friendly _check_option so that the assert is just an internal sanity check).

Many thanks for refactoring quiver3d(), it greatly helps!
There is indeed a difference on how the glyph is centered.
lower opacity on the glyph, center with a red sphere:

mayavi
pyvista

Of course we want the backends to be consistent. By default, I will assume that Mayavi is the desired result and modify _pyvista.py accordingly.

Using the sphere mode, I have second thoughts though...

Mayavi
PyVista

Ideally, I think we want the glyphs to behave like Mayavi in cone mode but like PyVista if the sphere mode is selected right? @agramfort , @larsoner

Ideally, I think we want the glyphs to behave like Mayavi in cone mode but like PyVista if the sphere mode is selected right? @agramfort , @larsoner

I would very much say: yes

No wait. The center of the sphere should be at the exact location where the "red dot / origin" of the cone is. I cannot see in the pics whether for pyvista, the center of the sphere is shifted "to the outside" of the brain, away from the surface. This is not what we want: the center should rest on the surface.

For PyVista, the center of the spheres and the red dots are at the position. Does it answer your question? I can push a test commit and you can verify.

For PyVista, the center of the spheres and the red dots are at the position. Does it answer your question? I can push a test commit and you can verify.

Great, that answers my question.

I pushed d2fc5fb for testing purpose only. You can take a look @hoechenberger, @larsoner. It could be reverted before merge.

x
Mayavi
PyVista

cone

sphere

I pushed 8d51365 to make the cone radius consistent too:

Mayavi
PyVista

That looks right to me. For quiver matplotlib has the "pivot" argument, but we should just document that it's always the tail for arrows and cones and center for sphere (and make sure that this is the case). Not sure which cylinder should be, probably tail.

Not sure which cylinder should be, probably tail.

I would say tail, too, to be consistent with cones.

For plot_sparse_source_estimates() no cylinder mode is available but in general, when quiver3d() is used with cylinder, there is a glyph_center parameter to change the 'pivot'.

Ahh okay, so no changes needed then I think!

@larsoner and @GuillaumeFavelier merge if you're happy
thx


Improving events page UI

as card width is too big as compare to its height its not looking soo nice i can improve it
please assign this to me

Yes sure!! @babitarit

please assign it to me so that i can start working

Hello, I'm a contributor to GSSOC'23 I am very much Interested in contributing to this project .I am Skilled in web development and I am ready to collaborate and follow all project guidelines.
I will try to make it as different as possible and exciting also.
Please assign it to me. Thank you in advance.😇

Hello, I'm a contributor to GSSOC'23 I am very much Interested in contributing to this project .I am Skilled in web development and I am ready to collaborate and follow all project guidelines.
I will try to make it as different as possible and exciting also.
Please assign it to me. Thank you in advance.😇

Hey @AMAN-BAGADIYA ,thanks for stepping up. As this project is open source, u can open a PR. We will be happy to review and merge the request!!


large backlog of pull requests

Hi,
we seem to have a large backlog of PR's?
Any thoughts on how we can get through them and get them merged?
Happy to help out any way I can

I was thinking of creating the fork where the PR's can be approved (or at least reviewed). Plenty of PR's are still pending from me as well.
Would someone support the idea?

I think the first thing, is to somehow poriortise them, I guess people will
start reviewing stuff that is important to them, for me would be the bybit
v5 for example, then once it is reviewed by some contributors, then the
core team can be tagged to look at it.
but if no review by other contributors, then no merging, as I guess it is
not that important.
Douggie
On Thu, Nov 2, 2023 at 11:28 AM Dmitri Karpovich @.***>
wrote:

I was thinking of creating the fork where the PR's can be approved (or at
least reviewed). Plenty of PR's are still pending from me as well.
Would someone support the idea?
—
Reply to this email directly, view it on GitHub
https://github.com/knowm/XChange/issues/4783#issuecomment-1790550556,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBUO2REXMBCJHL7FZSG4PTYCN7U7AVCNFSM6AAAAAA6WBLGJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJQGU2TANJVGY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Unfortunately there is no activity from core team since couple of months. That makes me think of creating the fork

ahhhh!!!!!! i see.
On Thu, Nov 2, 2023 at 11:42 AM Dmitri Karpovich @.***>
wrote:

Unfortunately there is no activity from core team since couple of months.
That makes me think of creating the fork
—
Reply to this email directly, view it on GitHub
https://github.com/knowm/XChange/issues/4783#issuecomment-1790568595,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBUO2RQT6XFEEFB74XUZVLYCOBJLAVCNFSM6AAAAAA6WBLGJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJQGU3DQNJZGU
.
You are receiving this because you authored the thread.Message ID:
@.***>

So options
Option 1 - Create a fork with new approvers, this seems a bit nuts, just add more approvers to existing project.
Option 2 - Ensure that a PR has to be reviewed by a contributer before it is reviwed by an approver, this kinda ensures the prioity is self selecting.
Option 3 - Add more approvers to the existing project.
I kinda thinking a combination of 2 and 3.
@timmolter @makarid @npomfret @mmazi  what do you guys think?

Hello.
I agree that PR is viewed poorly.
Also, important!, somebody need to clear up a huge number of old error reports.
Option 1 - IMHO, bad. Project stratification, unclear prospects.
I vote for 2 and 3

ping @walec51 @timmolter @makarid thougths?

Hello everyone. I guess the best solution is everyone to fork his/her own
version of the project and if one is willingly to fork the whole project
and maintained it for the long term we can just use his/her fork. @Tim
Molter @.***> had said in the past that he had no time to give to
the project, totally understood, I will respect that.
On Tue, Nov 7, 2023, 2:03 PM douggie @.***> wrote:

ping @walec51 https://github.com/walec51 @timmolter
https://github.com/timmolter @makarid https://github.com/makarid
thougths?
—
Reply to this email directly, view it on GitHub
https://github.com/knowm/XChange/issues/4783#issuecomment-1798370482,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHIWQ7YAT36LFXQXRHOTUBTYDIPSVAVCNFSM6AAAAAA6WBLGJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYGM3TANBYGI
.
You are receiving this because you were mentioned.Message ID:
@.***>

Given everything is set up ci etc , can we not just add maintainers, I am
happy to maintain it and take over from tim.
On Tue, Nov 7, 2023, 12:11 PM Makarid @.***> wrote:

Hello everyone. I guess the best solution is everyone to fork his/her own
version of the project and if one is willingly to fork the whole project
and maintained it for the long term we can just use his/her fork. @Tim
Molter @.***> had said in the past that he had no time to give to
the project, totally understood, I will respect that.
On Tue, Nov 7, 2023, 2:03 PM douggie @.***> wrote:

ping @walec51 https://github.com/walec51 @timmolter
https://github.com/timmolter @makarid https://github.com/makarid
thougths?
—
Reply to this email directly, view it on GitHub
https://github.com/knowm/XChange/issues/4783#issuecomment-1798370482,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AHIWQ7YAT36LFXQXRHOTUBTYDIPSVAVCNFSM6AAAAAA6WBLGJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYGM3TANBYGI>

.
You are receiving this because you were mentioned.Message ID:
@.***>

—
Reply to this email directly, view it on GitHub
https://github.com/knowm/XChange/issues/4783#issuecomment-1798382102,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBUO2UUVVMIG5CIEKV6KTLYDIQQ5AVCNFSM6AAAAAA6WBLGJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYGM4DEMJQGI
.
You are receiving this because you authored the thread.Message ID:
@.***>

fork is the last thing.
We need a person who will carry the project so that the majority of users start using its version.
Otherwise, there will be a bunch of forks, which over time will lose any ability to merge them with the main branch.
This will definitely not benefit the project.
I really don't understand why not give a few more people the opportunity to service the project?
yes, the quality may suffer a little, but the project will remain a single whole and will continue to develop...

I am happy to take on Tim's role
On Tue, Nov 7, 2023, 2:06 PM Ilya Smirnov @.***> wrote:

fork is the last thing.
We need a person who will carry the project so that the majority of users
start using its version.
Otherwise, there will be a bunch of forks, which over time will lose any
ability to merge them with the main branch.
This will definitely not benefit the project.
I really don't understand why not give a few more people the opportunity
to service the project?
yes, the quality may suffer a little, but the project will remain a single
whole and will continue to develop...
—
Reply to this email directly, view it on GitHub
https://github.com/knowm/XChange/issues/4783#issuecomment-1798591520,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBUO2UH6NVYBZKY3WI4PQTYDI55FAVCNFSM6AAAAAA6WBLGJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJYGU4TCNJSGA
.
You are receiving this because you authored the thread.Message ID:
@.***>

@makarid are you able to add mainters? May be add me, @ bigscoop @rizer1980 as a start?
My start would be

People have to get their PR's reviewed by another contributor
the maintainers do the final reivew and merge.

I totally agree to add more maintainers but I don't have access to do it. @Tim
Molter @.***> and I think @badgerwithagun can
On Wed, Nov 8, 2023, 9:17 AM douggie @.***> wrote:

@makarid https://github.com/makarid are you able to add mainters? May
be add me, @ bigscoop @rizer1980 https://github.com/rizer1980 as a
start?
My start would be

People have to get their PR's reviewed by another contributor
the maintainers do the final reivew and merge.

—
Reply to this email directly, view it on GitHub
https://github.com/knowm/XChange/issues/4783#issuecomment-1801222578,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AHIWQ7Z6C4QDMNCSRHSVAA3YDMWZTAVCNFSM6AAAAAA6WBLGJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBRGIZDENJXHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

I'm happy to add more maintainers. Who should I add?

@timmolter  pleased you are alive!
May be @bigscoop @rizer1980 and @douggie as a start? This is just based on how has a few PR's out there. @bigscoop @rizer1980  or anyone else?
@timmolter I am happy to take over the whole mainter thing (i.e. your role), i.e. ci pipelients etc etc, if you want to hand over the reins fully, we can do a chat some time and share any passwords to switch over users etc etc if I need more access than just maintainer.
Douggie

@bigscoop @rizer1980 if you have any pressing PR's can you get them reviwered by another contributer first.
I will review the following PR's as I would like them in
https://github.com/knowm/XChange/pull/4771
https://github.com/knowm/XChange/pull/4766
https://github.com/knowm/XChange/pull/4733
If anyone is able to review some of mine that would be great
https://github.com/knowm/XChange/pull/4785
https://github.com/knowm/XChange/pull/4780

@douggie  I think I still can't neither review nor merge anything because of missing role

sorry for my absence - I'm not working in the crypto space now and didn't have time to review
we should choose new maintainers based on their experience and availability
looking at https://github.com/knowm/XChange/graphs/contributors
I'm in favor of adding @douggie @makarid @badgerwithagun
as for
@rizer1980 - I'm sorry but I do not see you on the contributors page and you should build more experience before becoming a maintainer
@bigscoop - I see you have your first contributions in the project but I think it would be a little early for a maintainer role, but I couple of more PRs and experience and I think you should be granted that right

Hello, @walec51
Hurray!, I understand that we have someone to approve the PR, thx.
I don't understand why I'm not on this page...
I have 16 PRs (11 approved), plus about 10 more ready, but not published for various reasons.
Yes, I don’t have much experience in Xchange, but I wasn’t going to go somewhere I don’t know.
Clean up the backlog of issue, approve the code that I fully understand.

@rizer1980 it's because I need to manually update that page during the release process and I may have forgotten recently. You'll be on there on the next release.

I've added @douggie and @makarid . @badgerwithagun was already able to merge PRs.
@earce @jheusser @badgerwithagun @walec51 Shall I remove you as being able to merge PRs (write role)?

Since it's been a long time since XChange had a release, we should try to get one out soon. I will publish it once I get the green light, and I'll also update the contributor's list at that time.

Thanks Tim! I am back next week and will get on zee merges.
If any contributor and review other people's prs first will really help.
I will look to do a release.
On Mon, Nov 13, 2023, 4:01 PM Tim Molter @.***> wrote:

Since it's been a long time since XChange had a release, we should try to
get one out soon. I will publish it once I get the green light, and I'll
also update the contributor's list at that time.
—
Reply to this email directly, view it on GitHub
https://github.com/knowm/XChange/issues/4783#issuecomment-1808452508,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBUO2Q2EOWB23AZQEHHO63YEI74PAVCNFSM6AAAAAA6WBLGJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBYGQ2TENJQHA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Thank you very much @timmolter !

I plan to return to an active role next your so it would be nice if I could keep my status.
ps. Lets all remember that we should not merge our own PR - some other maintainer must approve it.
Please also try to maintain best practices described on our wiki: https://github.com/knowm/XChange/wiki
Keep backward comparability and do not let non generic features slip to generic interfaces and DTOs.

As about the release.
In my opinion, everything is fine with us, there were reports of problems with [Binance Us] - but now everything seems to be stable.

Back Monday so will start on a few, gate, bybit v5 will be the first ones I
will review
On Tue, Nov 14, 2023, 10:38 AM Tim Molter @.***> wrote:

Glad to see renewed activity here! Let's aim for a release late next week.
Need to get lots of open PRs approved and merged!
—
Reply to this email directly, view it on GitHub
https://github.com/knowm/XChange/issues/4783#issuecomment-1809952821,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABBUO2VTFHTLIT7U245WXUTYENCZLAVCNFSM6AAAAAA6WBLGJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBZHE2TEOBSGE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@timmolter not sure I have maintainer access yet, was just going to review and merge some PR's but no luck

5.1.1 released.


make "connection" name consistent in codebase and across tests

We've got variables and methods with a soup of variations of session/connection/cursor.
We should try and settle on a single name, preferably the same one used in the cassandra python driver, and make it consistent across dtest.
I think some of this is vestigial from dbapi2 which offered somewhat different abstraction.

Yes, we should settle on using session as the default name for a connection.


Menu buttons not showing

Buttons in menu are not showing. Tried both new textures and old that has worked before. Probably some error in the code

Nu visas knapparna igen 8e7d414c6642997fec07cd0b77665e0bd74fcaed


Issue on running tests in Workflow UI

We were now able to deploy the dc-testsuite container. It starts showing the UI and inititae the testcase @vau.
But after requesting to do the handshake it stopped working with error:
"And TGR wait for message with node "$.path" matching "/VAU""

Is there something wrong in our environment or settings?
If I change it in .env to other testcases the container does not start at all.

It was a misunderstanding at my end.


Linter doesn't work

I have installed uber-Juno, which installs all the needed Atom packages. I also have added the master branch of Lint.jl but still, nothing happens.

Closed by https://github.com/AtomLinter/linter-julia/releases/tag/v0.8.0


Fix print of a QSVC instance

Summary
Closes #218
Details and comments
Removed *args from QSVC and QSVR classes

Now while positional arguments is deprecated in sklearn and args should be removed, by removing it completely here, rather than deprecating it and removing it later, its a breaking change for anyone that happens to do that with today's QSVC/R. Maybe this is low risk - it would certainly need more code to deal with that. Maybe a different way along the lines to removing this might be to override repr (or str) in the interim as well to avoid using sklearns which has some problem it seems around args - I could only see repr in the sklearn source but I did not look too hard.
I see in the test it only tested against extra named arguments (kwargs) so no tests are impacted.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@woodsp-ibm I don't fully understand your suggestion. We can deprecate them manually (I don't think @deprecate_arguments can handle this), e.g. we still have *args in QSVC, but if they are not empty we print a deprecation warning, ignore them and don't pass them to the super class. Is it a preferable solution here?
I'd like to keep as less code as possible and not override str or repr from sklearn.

It maybe that the deprecation of args might need to be more manual and not use the decorator we have. Use of args can of course be detected - so we can say its deprecated and remove later. We could also call super init and include args if it was not empty otherwise call it without any args. That would allow any code that did have args to carry on working as it did - but I imagine in that case if one does a str/repr on it, it would still fail. One could in the interim override repr to return super repr but catch the error there and give back some other repr as a workaround which would be removed once the args are removed. How much is worth doing I guess depends - we only had the one error report so maybe its low risk as no-one really used args - indeed the tests we have use kwargs.

I don't think we have to pass positional arguments to SVC, they don't use them and this leads to the issue we have right now. We can just raise a warning and discard them.

I don't think we have to pass positional arguments to SVC, they don't use them

As far as I could tell from briefly looking at sklearn they have a deprecation decorator and end up converting any positional args to named args. Since it seems supported I do not know why the repr/str ends up failing when passed args but either way we should deprecate our exposure of args etc.

@woodsp-ibm as agreed today: we deprecate *args, raise a deprecation warning, if arguments are not empty we pass them to the super-class and if a user prints this instance and gets an error, then they must cope with the problem on their own. I certainly don't want to override additional methods.

@woodsp-ibm, I believe I have addressed all your comments above. I am seeing though that even when no args are passed into QSVR() and QSVC(), it is unable to print the class still (so the test function fails).

I was looking at this and see a couple of hours ago scikit-learn 1.0 was released and the deprecated args that SVC had allowed seems to have been removed.
As far as I could tell so far (with the 0.24.2) just having the args in the QSVC init signature is what ends up making it fail. I was starting to look at perhaps using a similar (or the same) deprecation decorator for the args, to see if that would work. But I do not know now given 1.0 is out - needs some further investigation I think.

@woodsp-ibm please take look.


Makefile,test: Support configuring the e2e testdata directory

Signed-off-by: timflannagan<EMAIL_ADDRESS>
Description of the change:
Avoid hardcoding the testdata directory that's used to configure a MagicCatalog provider.
Right now, there's two e2e-related targets: make e2e, and make e2e-local where the latter calls the former under-the-hood and specifies additional configuration options that the kind provisioner needs to create and manage hermetically sealed clusters. The problem is that the e2e target has a different working directory compared to the e2e-local target, which means that running make e2e TEST="MagicCatalog" locally will result in a failed test case as it cannot find the fbc_catalog.json configuration file from that hardcoded testdata directory.
These changes introduce an e2e suite flag that defaults to the ./testdata directory, which enables make e2e to work by itself, and the e2e-local target overrides this flag value to ../test/e2e/testdata so the CI pipeline can properly source this filepath as well.
Motivation for the change:
Closes #2687
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /doc
[ ] Commit messages sensible and descriptive
[ ] Tests marked as [FLAKE] are truly flaky
[ ] Tests that remove the [FLAKE] tag are no longer flaky

Okay I verified this fixes the original issue which was targeting to our downstream repository (but still applicable to upstream for users running make e2e explicitly with an existing cluster in hand):
$ git log
commit b9f5ecb4bee36c43ed026c1d1972c6dc31261e05 (HEAD -> updown_sync_2_copied_csv_ns_filter)
Author: timflannagan<EMAIL_ADDRESS>Date:   Fri Mar 25 12:00:14 2022 -0400

    Makefile,test: Support configuring the e2e testdata directory

    Signed-off-by: timflannagan<EMAIL_ADDRESS>...
$ make e2e/olm TEST="MagicCatalog"
make e2e WHAT=operator-lifecycle-manager E2E_INSTALL_NS=openshift-operator-lifecycle-manager E2E_TEST_NS=openshift-operators E2E_TIMEOUT=120m
make[1]: Entering directory '/home/tflannag/Documents/openshift/operator-framework-olm'
scripts/e2e.sh
~/Documents/openshift/operator-framework-olm/staging/operator-lifecycle-manager ~/Documents/openshift/operator-framework-olm
Populating nested vendor directory
all modules verified
Running operator-lifecycle-manager e2e tests
make[2]: Entering directory '/home/tflannag/Documents/openshift/operator-framework-olm/staging/operator-lifecycle-manager'
GO111MODULE=on GOFLAGS="-mod=vendor" go run github.com/onsi/ginkgo/ginkgo   -focus 'MagicCatalog' -flakeAttempts 1 -nodes 1 -timeout 120m -v -randomizeSuites -race -trace -progress ./test/e2e  -- -namespace=openshift-operators -olmNamespace=openshift-operator-lifecycle-manager -dummyImage=bitnami/nginx:latest -kubeconfig=/home/tflannag/.kube/config
Running Suite: End-to-end
=========================
Random Seed:<PHONE_NUMBER>
Will run 1 of 179 specs

SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
------------------------------
MagicCatalog
  Deploys and Undeploys a File-based Catalog
  /home/tflannag/Documents/openshift/operator-framework-olm/staging/operator-lifecycle-manager/test/e2e/magic_catalog_test.go:26
[BeforeEach] MagicCatalog
  /home/tflannag/Documents/openshift/operator-framework-olm/staging/operator-lifecycle-manager/test/e2e/magic_catalog_test.go:18
created the magic-catalog-e2e-xml9g testing namespace
[It] Deploys and Undeploys a File-based Catalog
  /home/tflannag/Documents/openshift/operator-framework-olm/staging/operator-lifecycle-manager/test/e2e/magic_catalog_test.go:26
[AfterEach] MagicCatalog
  /home/tflannag/Documents/openshift/operator-framework-olm/staging/operator-lifecycle-manager/test/e2e/magic_catalog_test.go:22
tearing down the magic-catalog-e2e-xml9g namespace

• [SLOW TEST:18.016 seconds]
MagicCatalog
/home/tflannag/Documents/openshift/operator-framework-olm/staging/operator-lifecycle-manager/test/e2e/magic_catalog_test.go:13
  Deploys and Undeploys a File-based Catalog
  /home/tflannag/Documents/openshift/operator-framework-olm/staging/operator-lifecycle-manager/test/e2e/magic_catalog_test.go:26
------------------------------
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
Ran 1 of 179 Specs in 18.413 seconds
SUCCESS! -- 1 Passed | 0 Failed | 0 Pending | 178 Skipped
PASS

Ginkgo ran 1 suite in 25.042572075s
Test Suite Passed
make[2]: Leaving directory '/home/tflannag/Documents/openshift/operator-framework-olm/staging/operator-lifecycle-manager'
~/Documents/openshift/operator-framework-olm
make[1]: Leaving directory '/home/tflannag/Documents/openshift/operator-framework-olm'

CI will verify that the make e2e-local context also works as that's what we run in the e2e workflow.

/lgtm

Welp that's some real weird behavior by tide :shrug:

DCO check is stuck -- manually merging as e2e is green.


Initial changes from stable2

Initial changes from stable2

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.ndandu599 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

b'## Copyright scan failure
Commit: f339a78136bd725513b237181876d665a50abd5c
Report detail: https://gist.github.com/rdkcmf-jenkins/02ccbf6fd960a8c101f79c69286d3d7c'

b'## Blackduck scan failure details
Summary: 0 violations, 0 files pending approval, 3 files pending identification.

Protex Server Path: /home/blackduck/github/OneWifi/2/rdkb/components/opensource/ccsp/OneWifi

Commit: f339a78136bd725513b237181876d665a50abd5c

Report detail: gist'

Hi Narendradandu: All the checks should be passing now, but please update thge CONTRIBUTING.md file to use the github version e.g. https://github.com/rdkcentral/rdkservices/blob/sprint/24Q4/CONTRIBUTING.md


Add AI Bots

Add AI bots with a basic AI bot implementation.

This has been implemented at a low level in #72 (covering basic non aggressive movement). Still require logic to support some sort of aggressive behavior when bots encounter human players.

AI bot logic added. Will be opening a new ticket to improve that logic.


super minor markdown fix

@dret I'm going to close this one as I have an outstanding task to backport the LF Training edits, which will overwrite this anyway. Thanks for the fix though


Minor - remove unused TimeUnit from MetricConfig

Heads-up: conflicts need to be resolved before this can be merged.

@ijuma Thanks for letting me know. It is rebased now.

@guozhangwang Would you have time to review this patch?

LGTM. Merged to trunk.


gnucash: 4.4 -> 4.5

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/gnucash/versions.
meta.description for gnucash is: "Personal and small-business financial-accounting application"
meta.homepage for gnucash is: "http://www.gnucash.org/"
meta.changelog for gnucash is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/k3h54rcla0pnl49v9wx2l272gk61pryg-gnucash-4.5/bin/gnc-fq-check passed the binary check.

/nix/store/k3h54rcla0pnl49v9wx2l272gk61pryg-gnucash-4.5/bin/gnc-fq-helper passed the binary check.

Warning: no invocation of /nix/store/k3h54rcla0pnl49v9wx2l272gk61pryg-gnucash-4.5/bin/.gnucash-wrapped had a zero exit code or showed the expected version

/nix/store/k3h54rcla0pnl49v9wx2l272gk61pryg-gnucash-4.5/bin/gnc-fq-dump passed the binary check.

Warning: no invocation of /nix/store/k3h54rcla0pnl49v9wx2l272gk61pryg-gnucash-4.5/bin/gnucash had a zero exit code or showed the expected version

/nix/store/k3h54rcla0pnl49v9wx2l272gk61pryg-gnucash-4.5/bin/gnucash-cli passed the binary check.

4 of 6 passed binary check by having a zero exit code.

3 of 6 passed binary check by having the new version present in output.

found 4.5 with grep in /nix/store/k3h54rcla0pnl49v9wx2l272gk61pryg-gnucash-4.5

found 4.5 in filename of file in /nix/store/k3h54rcla0pnl49v9wx2l272gk61pryg-gnucash-4.5

directory tree listing: https://gist.github.com/e3210590296041afcd8308d2a9a8f24c

du listing: https://gist.github.com/3e9b63cdb14afa4cca7732cf2b4301e1

Rebuild report (if merged into master) (click to expand)

3 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
0 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
gnucash

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/k3h54rcla0pnl49v9wx2l272gk61pryg-gnucash-4.5 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A gnucash https://github.com/r-ryantm/nixpkgs/archive/8ec9cdecbaa93e5949bb16436ece4a002b60ca01.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/k3h54rcla0pnl49v9wx2l272gk61pryg-gnucash-4.5
ls -la /nix/store/k3h54rcla0pnl49v9wx2l272gk61pryg-gnucash-4.5/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

gnucash

Maintainer pings
cc @peti @domenkozar for testing.

Result of nixpkgs-review pr 121008 at 8ec9cdec run on x86_64-linux 1

1 package built successfully:

gnucash

1 suggestion:

warning: build-tools-in-build-inputs
swig is a build tool so it likely goes to nativeBuildInputs, not buildInputs.
Near pkgs/applications/office/gnucash/default.nix:37:3:
   |
37 |   buildInputs = [
   |   ^


v1.14.3

Which issue(s) this PR fixes:
Fixes #
What this PR does / why we need it:
Need to ship new version for upcoming TD-Agent 4.3.0.
Docs Changes:
Release Note:

followed until https://github.com/fluent/fluentd/commit/f03bb926dfbe956c02269f1ebd750702e48a4847.

Add https://github.com/fluent/fluentd/pull/3553

v1.14.3 will be shipped which contains #3562.


Reformat the lists in homu/cfg.toml.

These lists change somewhat regularly, so I formatted them in a way to make
that easy.

@bors-servo r+

:pushpin: Commit 36b8700 has been approved by larsbergstrom

:hourglass: Testing commit 36b8700 with merge e583dbd...

:sunny: Test successful - travis


Can't load pretrained model

Thansk for your great work. I tried to train PS-ViT on my own dataset based on your ImageNet pretrained model. But when I use create_model(initial_checkpoint) in your code to load ps_vit_b_18.pth.tar, something goes wrong. Can you help me solve this problem? Thansk again!

Hello, I'm also following up this project recently. Is it convenient to exchange contact information? My email<EMAIL_ADDRESS>

Hi, thanks for the report.
I just fixed the bug, pls fetch the lastest version and try again.


Update packages

:tada: This PR is included in version 2.0.5 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Update to Rust 1.0.36

Remove now deprecated std::mem::uninitialized() usage.
rustfmt includes bug fixes but doesn't seem to change the indentation rules.

:tada: down with mem::uninitialized! - small request, could you reword the commit (and PR) to Rust 1.36.0, please :)

Haha, of course :) Done!


Please relase the updated provider

Back in July, the code was updated to latest version of the GitLab provider. Amongst other things, it has a new runner resource.
It seems this hasn't been properly released into the wild to be used. Would be nice.

I tried something like npm install 'https://gitpkg.now.sh/pulumi/pulumi-gitlab/sdk/nodejs?daa0ce0cb7ca979e6d2093b452d7887b6091b757' but that didn't get me far...

Hi @Fuuzetsu
I am sorry! I have just created the v4.8.0 release - it will be available in the next 30 mins
Paul

@stack72 Thank you, I was able to update the package from npm now.
I'd like to just note that the package is still out of date on the pulumi package registry: https://www.pulumi.com/registry/packages/gitlab/

The docs update is on it's way to the registry right now - it takes a little time :)


fix issue 294

Describe the PR
fix #294
Relation issue
https://github.com/swaggo/swag/issues/294
Additional context
It`s break if use alias before, all alias in operation.parser.TypeDefinitions actually.

@CaiJinKen can you help add tests?

If you have problem restart this pr.


Provide an option to act as Console transport using output from Entry.toJSON

Is your feature request related to a problem? Please describe.
When logging in context of cloud functions, cloud run, gke or gce, it's often desirable to just output to stdout or stderr to have the log entries automatically registered. It would be great if this library allowed to JUST output to stdout/stderr, behaving like a Console transport, but formatting to JSON as expected by the api.
This should allow users to reuse all the parsing/formatting/typings that @google-cloud/logging offers, without implementing a custom Transporter or Formatted.
Describe the solution you'd like
An option while instantiating this library, which when enabled would just print the JSON string and skip the stackdriver call.
Describe alternatives you've considered
Using a custom transport, formatter or passing the JSON formatted string to a Console transport.

+1 for having this feature.
@ejose19 have you decided to use a custom transporter or are you still using this library? which creates a custom log

Thanks a lot for opening this issue and really sorry for it took some time to support. I believe the 676 is addressing this issue - please take a look and let me know if this fix addressing your needs. Closing this issue for now - feel free to comment.


Bring back changes from release-v1.6.1 into main

Following v1.6.1 release of Meilisearch

@dureuill @irevoire I don't know why but the CIs fail 😢

The cargo.lock wasn't good for some reason. The xtask crate hadn't be updated to v1.6.1 (it was still v1.6.0).
Without updating this version, cargo would fail.
Normally, cargo would update the version, but due to our use of --locked (to prevent silent updates), it wouldn't.
I opened #4381 with a new branch where the Cargo.lock change is applied, it should pass the CI this time.
This PR is superseded by #4381, so closing.


Update icons.

Update icons according to IntelliJ's design guideline: https://jetbrains.design/intellij/principles/icons/

Replace Tabler Icons, since they are rounded end and a bit too thin.
Use only colors from the palette.

Before:

After:

Thanks!


Fixed case-sensitive markdown links

Description

The links to the relevant markdown files in the README.md are case-sensitive and so were giving 404s. This resolves them to the correct url.
Motivation

How Has This Been Tested?
I have committed this to my fork and clicked on the links in the readme
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] I have read the Contributing guide.
[x] My code follows the code style of this project.
[] My change requires a change to the documentation.

Thanks :)

No worries 😄


Motor dims

Updated M365 motor model to match real dimensions. (Screws aren't modeled but whatever everything else is). Most dims actually matched or were off by like 1mm, so pretty good eyeballing :) The motor model also has both the rotor and end caps trimmed down to the necessary diameter, and the end cap has air holes.
Stator, end-cap, and rotor+cable weights are specified, but will need to be re-weighed once we actually do the modifications. Other hardware (bearings, washer, nuts) just have weight calculated by volume based on 1045 steel. Screws are not included. I might go back and update these weights once we modify and measure the rotor and end cap.

The rotor output shaft is modified to fit the finalized motor dims and align the rotor and stator. Also it is made more printable. A groove in this part fits a ring, which interfaces with a chamfer on the motor rotor in order to centre the parts.

The motor module is updated to use the new motor and rotor shaft models. Casing dims do not change. Motor-to-casing clearance is 1.5mm on all sides.

We may want to add a chamfer to the end of the hex shaft so it'll easier assembling it in the CAMs, but not a big deal.

Good idea. I was thinking this in the shower this morning too. It would also help get the encoder on.
Follow-up.

Are we planning on keeping the nuts to constrain the one bearing on this shaft? did we need to print some spacer for that?

wdym? Does the last screenshot in the PR answer the question?

oops i forgot the end was cut down


HNC: Code refactoring to make set command function testable

Changes:
Separate out set command runnable function and introduce dependency function to make function testable.
Tested: manually run kubectl set commands and verified that they were
reported correctly.

/assign @adrianludwin
/assign @srampal

/assign @adrianludwin

/lgtm
/approve
/ok-to-test
/hold
@adrianludwin release hold when happy

/hold cancel
Thanks!


Add test for ticket reuse with proxy.config.ssl.server.ticket_key.filename

In the original order, a random ticket was created instead of using the global default.

[approve ci autest]

This does not fix what I'm seeing on 7.1.x. I'm still trying to debug on my side.

we still need more work on this? @randall I think you should "-1" this until it's resolved, so we don't merge it accidentally.

Yes, we should wait until we know this fixes things for @randall.  I'll go ahead and add an autest for this case.

Investigated our issue.
Root cause was differing ca-bundle.crt (pointed to via proxy.config.ssl.CA.cert.filename) across machines.
The variations were differences in order for our local CAs.

So once you fixed the ca-bundle.crt things started working even without this code change?

Ok, I must have been seeing things in Sunnyvale.  Things work with the code change and without.  So I've changed this PR into a test-only PR.  Using openssl s_client against two different instances of traffic_server using the same ticket key file to verify that the ticket can move between the two Traffic Server processes.  However, this test requires the next version of autest (1.7.0).

Sorry @shinrich for not answering your question.
Without the code change and with the identical ca-bundle.crt, tickets across hosts started working for me.

[approve ci autest]

[approve ci autest]


Does fastp remove primer sequences for aplicon sequencing results?

Hello, I've been going through the documentation and trying to find options for primer trimming. I am unsure whether the adapter trimming option could also trim primers.
Another thing I noticed is that the adapter sequence only takes ATGC but could not recognize other letters. For example, if I am using the following primers, is the program also able to trim the sequence?
Forward: 5’-GGWACWGGWTGAACWGTWTAYCCYCC-3’
Reverse: 5’-TAIACYTCIGGRTGICCRAARAAYCA-3’

Hopefully bumping this question because I would also like to know the answer!


Move to Maven

The current build scripts are from Netflix OSS and are no longer appropriate for Soabase Exhibitor as a standalone project. Move to Maven for ease of deployment. We can re-use the Soabase parent which should make it very easy:
    <parent>
        <groupId>io.soabase</groupId>
        <artifactId>soabase</artifactId>
        <version>0.11.2</version>
    </parent>

👍  @Randgalt are you working on this?

@Randgalt hasn't this been moved?

I'll try to work on this soon.