chore: add .gitignore file to exclude unnecessary files and directories

Description
This pull request adds a .gitignore file to the repository to exclude unnecessary or sensitive files from being tracked in version control. The file includes patterns for:

Build artifacts (e.g., *.pyc, dist/, __pycache__/, etc.)
Environment-specific files (e.g., .env, venv/, .DS_Store, etc.)
IDE/Editor configurations (e.g., .vscode/, .idea/)
Log files and temporary files (e.g., *.log, *.tmp)

 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.

Hi @MAYANK12SHARMA
Thank you for your contribution. I appreciate it. However, this is not something that will be of much relevance over here. It's on me, sorry; I didn't complete the main README, but to give some context, this repo will have multiple scripts, not just the current one, each having its own folder.

rocket_chat_docs_spider /
some_another_source_loader /
...

So, each script can have its own set of files, including the .gitignore. Again, thank you for your contribution, and I'm sorry we can't have it merged here. Please feel free to close it.

Hi @MAYANK12SHARMA,
Thank you for your thoughtful follow-up and suggestion! Adding a .gitignore to the rocket_chat_docs_spider folder is a good idea in some cases, especially for projects that involve local builds, multiple contributors actively working on files, or IDE-specific configurations. However, for this specific repository, each script is quite self-contained, and the idea is to keep things lightweight. Since these are more like standalone data loaders, there aren't any build artifacts or complex local development setups that would necessitate a .gitignore.
That said, your interest in improving the structure is appreciated! If you're interested in making a more impactful contribution, it might be worth exploring enhancements to the existing scripts, such as adding more robust error handling, or even contributing new loaders for additional data sources (think Rocket.Chat Messages, Confluence, Google Docs, and so on).
Thank you again for your efforts—they’re definitely appreciated!

Thanks Sir


Hide marks by default

Hi,
Is it possible to not show marks by default and let them appear only when I use MarksToggleSigns?

Any solution for this @samuelevalperta ?

Any solution for this @samuelevalperta ?

I added this in my .vimrc
'''autocmd VimEnter * MarksToggleSigns'''.
It basically exec the command MarksToggleSigns once every time you enter vim.


(BKR-864) Modularize vmware fusion hypervisor

Separate vmware fusion hypervisor to an external module: beaker-vmware.

[ ] Review and publish beaker-vmware
[ ] CI should pass on this PR once the module is published

[ci skip]

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/3973/

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/3974/

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/3978/

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/4005/

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/4006/

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/4007/

@puppetlabs-jenkins retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/4010/

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/4011/

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/4013/

@puppetlabs-jenkins retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/4015/

@puppetlabs-jenkins retest this please

Refer to this link for build results (access rights to CI server needed):
http://jenkins-beaker.delivery.puppetlabs.net//job/qe_beaker_btc-intn/4017/


[proposal] Reservation supports taints and tolerations

What is your proposal:
Some use cases of the Resource Reservation regard the reservation objects as nodes, thus bringing the need to apply taints to the reservations. In this proposal, we want to support that the reservation can set taints where only pods with corresponding tolerations can allocate their resources.
Why is this needed:
Is there a suggested solution, if so, please add it:

linked to #2186


Flekschas/style header and menu

Fix Safari and FireFox issues. Adjust styling of the view header

@pkerpedjiev: Could you review and merge this asap?


[WIP] migrate from pocketfft to ducc.fft

Related to #7490
This is still at a very early stage:

one FFT test fails with a segfault (I'm looking into that)
I probably have to add BSD licensing headers to some of the ducc source files
if multi-threading should be used, we have to adjust the interface accordingly
I haven't done any proper formatting for the source changes in JAX

However I'm happy about any feedback already at this stage!

I realized that the copts in third_party/pocketfft/BUILD.bazel most likely won't achieve anything, since most of the code isin headers and will be compiled as part of  jaxlib/pocketfft_kernels.cc. So we should probably adjust the compiler options for this file...

Technical question: the CLA only covers the actual content of this PR, not the library sources themselves, correct? If so, I probably won't have to discuss this with a lawyer ;-)

There are two failures in lax_vmap_test.py where the results are too inaccurate. I don't understand the tests well enough to judge whether this is really a problem.

Thanks! I'll look at the technical aspects of this shortly.

Technical question: the CLA only covers the actual content of this PR, not the library sources themselves, correct? If so, I probably won't have to discuss this with a lawyer ;-)

I don't speak for Google's lawyers, but yes, my understanding is that the CLA applies only to your contributions, e.g., PRs.
As I mentioned before, we don't want to incorporate GPL-licensed code because it would require us to distribute JAX itself under a much more restrictive license than its current license (Apache 2). (Obviously third parties are welcome to plug in GPL code: it's just not something we ourselves want to distribute.)
To get this merged, we'd need ducc0's LICENSE information to be explicit about which files are under the BSD license and where the GPL license does not apply, i.e., a clear statement from you as the author in the project's license information that the GPL license doesn't apply to any of the files needed for FFT transformations.
Currently it looks like, for example, in ducc0 fft/fft.h is marked as BSD-licensed, but some of its dependencies (e.g., in infra/) are GPL-licensed and marked as such. We'd need everything in the transitive closure of the FFT library to fall under the more liberal license (e.g.., a BSD license, see https://opensource.google/docs/thirdparty/licenses/#notice) and for that to be clearly stated. Does that seem possible?

Currently it looks like, for example, in ducc0 fft/fft.h is marked as BSD-licensed, but some of its dependencies (e.g., in infra/) are GPL-licensed and marked as such. We'd need everything in the transitive closure of the FFT library to fall under the more liberal license (e.g.., a BSD license, see https://opensource.google/docs/thirdparty/licenses/#notice) and for that to be clearly stated. Does that seem possible?

Absolutely, that's the plan. As I mentioned above, I just didn't get around to add the change to all affected files. Will do that soon.

I'm currently updating all source files required by the FFT functionality to include the following:
/* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0-or-later */

/*
All rights reserved.

Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this
  list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this
  list of conditions and the following disclaimer in the documentation and/or
  other materials provided with the distribution.
* Neither the name of the copyright holder nor the names of its contributors may
  be used to endorse or promote products derived from this software without
  specific prior written permission.

*/

/*
 *  This code is free software; you can redistribute it and/or modify
 *  it under the terms of the GNU General Public License as published by
 *  the Free Software Foundation; either version 2 of the License, or
 *  (at your option) any later version.
 *
 *  This code is distributed in the hope that it will be useful,
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 *  GNU General Public License for more details.
 *
 *  You should have received a copy of the GNU General Public License
 *  along with this code; if not, write to the Free Software
 *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */

Would that be sufficiently clear?
I'm also updating the README.md file to mention that a subset of the ode is dual-licensed.
I'd rather not mess with the LICENSE file itself, since that is a verbatim copy of GPLv2. As far as I understand, BSD3-licensed code does not require an accompanying license file; just the licensing header in each source file should be enough.

I suspect that's fine, but for our use I'll need to get an ok from our compliance folks. But I think so long as it's clear and well-documented exactly what is covered by the BSD license they will be happy with it.

OK. In the extreme case, I could make a reduced package containing only the relevant files (not my favorite oprion, since it means more maintenance), or you can import the FFT subset into your sources directly. I don't expect frequent updates, roughly once per year or so.

If I understood correctly, a Google account is required to sign the CLA. Since I don"t have one, I suggest that @Edenhofer re-submits the patch as his own. OK?

Since the CLA bot is still unhappy, I filed a new MR at https://github.com/google/jax/pull/12120 .

#12122 was merged! Thanks for your help!


Use pydantic models for entities

This PR implements pydantic models for medperf entities. This provides validation and explicit definition of expected fields for an entity. Closes #359.

@aristizabal95 Looks awesome! I will approve after we make sure point 1 below is not an issue. I left a few comments above for:

Extra fields are defined for the Result entity. Is that a problem? This will be written locally.
Minor stuff (documentation, maybe extra code piece)
A concern about defining the fields as optional
Questions that can be addressed in new PRs:
a. The ID fields in entities currently expect int or str
b. After this PR, Benchmark.tmp seems to become useless


[stable/concourse] Clean up env var mappings using envFrom

The configmap template for concourse only serves to map values to env vars, but why can't we just do this directly? I haven't seen a chart that does this as extensively, and it seems like needless repetition each time we add a new value that needs to end up as an env var. Are there advantages to this technique that I'm missing?
Paging @mattfarina @viglesiasce @nexeck for your opinion

Addressed in #3254


Triangle exercise: readme and tests are inconsistent?

The readme says the code should raise an error if the triangle cannot exist, but the tests just have an Illogical type. One of the two is wrong, but I don't know which one.

I suppose that the tests/example are inconsistent with what is laid out in the readme. The readme is at the global level - for all the language tracks.
Looking at some other solutions - the Scala solution is consistent with the Haskell and Clojure solutions. The Rust solution returns a Result<Self, &'static str>. The C#, Python and Ruby solutions throw an exception.
Since the Clojure, Haskell and Scala solutions are equivalent, I would think that maybe the readme should be modified to accommodate.

What do to here? Create an issue for x-common?

Absolutely!

Closing. There isn't anything we are doing in xscala to address the issue.


td-agent 3.1.0 automatically stopped

fluentd or td-agent version.

dpkg -l |grep td-agent
ii  td-agent                         3.1.0-0                                    amd64        Treasure Agent: A data collector for Treasure Data

td-agent-gem list |grep td
fluent-plugin-td (1.0.0)
fluent-plugin-td-monitoring (0.2.3)
fluentd (0.14.25)
td (0.15.7)
td-client (1.0.4)
td-logger (0.3.27)

Environment information, e.g. OS.

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:        16.04
Codename:       xenial

Your configuration

<source>
  @type tail
  tag waves
  path /var/log/waves/waves.log
  pos_file /var/opt/td-agent/waves.service.pos
  format json
  time_key @timestamp
  time_format "%Y-%m-%dT%H:%M:%S.%L"
  read_from_head false
</source>

<filter **>
  @type record_transformer
  <record>
    hostname dex-aws-ir-1.wavesnodes.com
  </record>
</filter>

<match **>
  @type forward
  <server>
    host myhost
  </server>
</match>

Your problem explanation. If you have an error logs, write it together.

tail /var/log/td-agent/td-agent.log
2017-12-07 22:24:40 +0000 [info]: #0 starting fluentd worker pid=12404 ppid=12396 worker=0
2017-12-07 22:24:40 +0000 [info]: #0 delayed_commit_timeout is overwritten by ack_response_timeout
2017-12-07 22:24:40 +0000 [info]: #0 following tail of /var/log/waves/waves.log
2017-12-07 22:24:40 +0000 [info]: #0 fluentd worker is now running worker=0
2017-12-07 22:24:41 +0000 [info]: #0 fluentd worker is now stopping worker=0
2017-12-07 22:24:41 +0000 [info]: #0 shutting down fluentd worker worker=0
2017-12-07 22:24:41 +0000 [info]: #0 shutting down input plugin type=:tail plugin_id="object:3f8c9b17548c"
2017-12-07 22:24:41 +0000 [info]: #0 shutting down filter plugin type=:record_transformer plugin_id="object:3f8c993086fc"
2017-12-07 22:24:42 +0000 [info]: #0 shutting down output plugin type=:forward plugin_id="object:3f8c998ef5d4"
2017-12-07 22:24:43 +0000 [info]: Worker 0 finished with status 0

You can see here that it's starting and immediately shutting down.
PS: td-agent 3.0.1 worked perfectly

Hmm... Could you try following step?
https://docs.fluentd.org/v1.0/articles/trouble-shooting#check-uncaught-logs


[Fixes #7378] fixed tenent name validation regex, not to allow numbers.

Why the +, it would mean it has to contain 2 chars at least. A * assume you can have zero or more, so there could be a single char if you want. Remember the [a-zA-Z] imposes at least one char.

My bad, you're right.


⚠ Processors has degraded performance

In 47cd9a4, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 48 ms

Resolved: Processors performance has improved in 5c3267e.


Feature: ability to move view! macro to a separate file

The view! { ... } macro can be gigantic sometimes, and it's not always reasonable/easy to split things into smaller components. Having view! { ... } in a separate file (from the rest of the component implementation) can make the code much easier to navigate and maintain in such cases. Additionally, it would provide even cleaner separation between declarative and imperative parts.

Sounds like a good idea, but first we need to know how this would look like.
My first though was to use a new view_file!() macro:

#[relm4::component]
impl SimpleComponent for AppModel {
    type Init = u8;
    type Input = AppMsg;
    type Output = ();
    type Widgets = AppWidgets;

    view_file!("path/to/view.rs")

   ...
}

And then in view.rs:
view! {
    // regular view macro, as if it was created inside of `#[relm4::component]`
}

Maybe we could use rust modules as path specifier instead. What do you think?

Hm.. If it's identified by module path, should it actually be a proper Rust module? I guess yes, otherwise the path is invalid from the compiler PoV. But then, if it's a different module, all component-level types accessed from view macro would need to be properly qualified there (e.g with super:: if view module is child to component module). At the same time, view macro can access local variables and arguments of component methods, which breaks module's access boundaries.
I guess it'd be less confusing to just treat it as include!() file, and so identify by file path. It would also allow more freedom experimenting with a file structure, e.g. grouping all view files together in one folder (not sure if it's a good idea tho :P).
But I might be wrong at any stage of my chain of thoughts here. I never wrote complicated macros, and I don't have expertise to think about it on the level you can. So if module path won't cause those problems I imagined, then I'm completely happy with it too.

It probably makes sense to experiment a bit with this. I can try out how easy it is to add in general and then we'll see how things like IDE integration (e.g. rust-analyzer) will work out.

Do you want to check out #247 ? You could try out the external-view branch already if you want, but error reporting is horrible. Maybe we need to use Rust modules after all so that the compiler can figure out what to do with the error spans...

Wow, so fast! Unfortunately I won't be able to try it out properly until Saturday (UTC+3), I might quickly check tomorrow but not sure.

I finally tried the branch, everything works with my project. But yeah, error reporting and integration with rust analyzer are very good points in favor of modules.

Now that widget templates exist, I wonder whether those are the better option. They don't allow you to move all of the view macro into a different file, but certainly most of it and do so without any macro magic.
@azymohliad what do you think? Should we continue this effort or are widget templates good enough?

I'm happy with templates. Definitely they can help to reduce the boilerplate. I would guess that view macro in a separate file might be useful for some cases anyway. But as we discussed above, there are some issues, so maybe there's no point indeed.
I personally don't really need this feature that much anymore, because I've refactored my mess and actually separated reasonable components. I'm happy to close the issue, to be clear.
Sorry for a long silence, I've been either very busy or tired lately to look into templates properly.

No problem, thanks for your reply :)
I'll close this issue for now. Of course this can be re-opened in case it becomes relevant again.


Capability annotations are not inherited correctly

Causes customers to build libraries that are missing available functionality. See microsoftgraph/MSGraph-SDK-Code-Generator#93


Add "RenameObject"; Refactor "ReplaceObject"

@fireworkmarks , I do agree with @cannium .

You should update the column 'objectname' in table "objectparts".
Add test cases of  renaming object of multipart upload.
Ask @cannium  how to modify your variables written by broken English.

I think multipart-related tables should also be updated.

I will do some changes. how can I do for my broken English

grammerly is your friend.

grammerly is your friend.

Have a look please:https://github.com/journeymidnight/yig/pull/186


Fix client-side trim validator.

Subsequent validators now use the trimmed value instead of the original value.
fixes #7707

looks good to me.

Thanks!


Shai/eigen

Eigen support is already part of the mainline. You can use UVATLAS_USE_EIGEN directly or you can use the CMake build option ENABLE_USE_EIGEN.
Can you elaborate on the 'non-square atlas' bug you fixed?
Also, what was the motivation for moving the CMakeList.txt?


synostgpool failed to create storage pool!

@aelmardi wrote:
Hey guys,
I'm facing an issue with my DS923+ on DSM 7.2.1-69057 Update 5. (Seagate Firecuda 530)
I don't have any logs available, but it failed during the storage creation step :

Thanks in advance for your help.

I ca see what the issue is. I just need to work why it happened and prevent it happening.
Line 10 in your screenshot shows:
nvme0n1 M.2 Drive /dev/nvme0n1-/dev/nvme0n1 - Seagate Seagate FireCuda 530 ZP2000GM30013

Where it should show:
nvme0n1 M.2 Drive 1 - Seagate Seagate FireCuda 530 ZP2000GM30013

Can you download and run this test version and reply with a screenshot of the output?
https://github.com/007revad/Synology_M2_volume/archive/refs/tags/v10.0.0-TEST.zip

Hello,
Got it, here's the screenshot. Thanks for your prompt response.

What does the following command return?
sudo synonvme --get-location /dev/nvme0n1

Can't get the location of /dev/nvme0n1

That is strange because the line before that in the script is: synonvme --vendor-get /dev/nvme0n1
So I'm not sure why this line does not work for you: synonvme --get-location /dev/nvme0n1
I've got a new test version for you to test. https://github.com/007revad/Synology_M2_volume/releases/tag/v10.0.0-TEST2
It is the full script with 2 changes:

If synonvme --get-location returns an error it uses "nvme0n1" instead of expecting "M2 Drive 1".
It won't actually run the synostpool command. Instead it will echo the command so I can see what arguments it would have used.

Here's the result of the script :

I noticed another bug in your latest screenshot, which would have been the cause of the the synostpool failing.
I've released a new version of the script
https://github.com/007revad/Synology_M2_volume/releases/tag/v2.0.27

Bug fix for when synonvme --get-location fails.
Bug fix for synostgpool failed to create storage pool when Single volume storage pool type selected with only 1 M.2 drive.

@sin509
Can you download this version:
https://github.com/007revad/Synology_M2_volume/releases/tag/v10.0.0-TEST2
Then run the syno_create_m2_volume_test2.sh file and let me know if it works.

With the latest version it doesn't work for me. I'm going to reinstall my DSM to see.

You can close this issue because I believe the problem is that my M2 is not recognized either. I have created another issue:
https://github.com/007revad/Synology_HDD_db/issues/292


Memcached support fails at startup due to a bad KryoTranscoder init

Indeed, the Spring context: https://github.com/Jasig/cas/blob/master/cas-server-integration-memcached/src/main/resources/META-INF/spring/memcached-registry-config.xml#L53 references a constructor parameter which does not exist any more. It was removed when the Kryo library was upgraded to version 3.

PR: https://github.com/Jasig/cas/pull/1253


graphics: Rendering a scaled image might miss edge pixels

This test fails on MacBook Pro:
func TestImageStretch(t *testing.T) {
        img0, _ := NewImage(16, 17, FilterDefault)

        pix := make([]byte, 4*16*17)
        for i := 0; i < 16*16; i++ {
                pix[4*i] = 0xff
                pix[4*i+3] = 0xff
        }
        for i := 0; i < 16; i++ {
                pix[4*(16*16+i)+1] = 0xff
                pix[4*(16*16+i)+3] = 0xff
        }
        img0.ReplacePixels(pix)

        const h = 4096
        img1, _ := NewImage(16, h, FilterDefault)
        for i := 1; i < h; i++ {
                img1.Clear()
                op := &DrawImageOptions{}
                op.GeoM.Scale(1, float64(i)/16)
                r := image.Rect(0, 0, 16, 16)
                op.SourceRect = &r
                img1.DrawImage(img0, op)
                for j := -1; j <= 1; j++ {
                        got := img1.At(0, i+j).(color.RGBA)
                        want := color.RGBA{}
                        if j < 0 {
                                want = color.RGBA{0xff, 0, 0, 0xff}
                        }
                        if got != want {
                                t.Errorf("At(%d, %d) (i=%d): got: %#v, want: %#v", 0, i+j, i, got, want)
                        }
                }
        }
}

The situation was more complicated than I thought. On MacBook Pro 2018, the result depends on what kind of tests are executed at the same time. I think this is a bug on the GPU, but am not sure.


I can't run specific minecraft version with fabric server

I was running fabric server for Minecraft 1.17 on my server. But when I re-build my docker-compose, my container boot with Minecraft 1.17.1.
This is my docker-compose.yml:
version: "3"

services:
  mc-ksu:
    image: itzg/minecraft-server
    container_name: mc-ksu
    environment:
      EULA: "TRUE"
      MEMORY: "6G"
      TZ: "Asia/Tokyo"
      TYPE: "FABRIC"
      VERSION: "1.17"
    volumes:
      - ./data:/data
    tty: true
    stdin_open: true
    restart: always
    deploy:
      resources:
        limits:
          memory: 7.5G

  backup-ksu:
    image: itzg/mc-backup
    container_name: mc-ksu-backup
    environment:
      - RCON_HOST=mc-ksu
    depends_on:
      - mc-ksu
    volumes:
      - ./data:/data:ro
      - ./backups:/backups

networks:
  default:
    external:
      name: minecraft

And this is container logs:
mc-ksu        | [init] Running as uid=1000 gid=1000 with /data as 'drwxrwxr-x 10 1000 1000 4096 Jul 10 04:01 /data'
mc-ksu        | [init] Resolved version given 1.17 into 1.17
mc-ksu        | [init] Resolving type given FABRIC
mc-ksu        | [init] Checking Fabric version information.
mc-ksu        | [init] server.properties already created, skipping
mc-ksu        | [init] Checking for JSON files.
mc-ksu        | [init] Setting initial memory to 6G and max to 6G
mc-ksu        | [init] Starting the Minecraft server...
mc-ksu        | [04:21:13] [main/INFO]: Loading for game Minecraft 1.17.1
mc-ksu        | [04:21:13] [main/FATAL]: A critical error occurred
mc-ksu        | net.fabricmc.loader.discovery.ModResolutionException: Errors were found!
mc-ksu        |  - Mod 'Lithium' (lithium) requires version 1.17 of mod 'Minecraft' (minecraft), but a non-matching version is present: 1.17.1!
mc-ksu        | 	 - You must install version 1.17 of 'Minecraft' (minecraft).
mc-ksu        | 	 - Mod 'Minecraft' (minecraft) v1.17.1 is being loaded from the user's mod directory.
mc-ksu        | 	at net.fabricmc.loader.discovery.ModResolver.findCompatibleSet(ModResolver.java:342) ~[fabric-server-launch.jar:?]
mc-ksu        | 	at net.fabricmc.loader.discovery.ModResolver.resolve(ModResolver.java:832) ~[fabric-server-launch.jar:?]
mc-ksu        | 	at net.fabricmc.loader.FabricLoader.setup(FabricLoader.java:195) ~[fabric-server-launch.jar:?]
mc-ksu        | 	at net.fabricmc.loader.FabricLoader.load(FabricLoader.java:185) [fabric-server-launch.jar:?]
mc-ksu        | 	at net.fabricmc.loader.launch.knot.Knot.init(Knot.java:132) [fabric-server-launch.jar:?]
mc-ksu        | 	at net.fabricmc.loader.launch.knot.KnotServer.main(KnotServer.java:28) [fabric-server-launch.jar:?]
mc-ksu        | 	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
mc-ksu        | 	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
mc-ksu        | 	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) ~[?:?]
mc-ksu        | 	at java.lang.reflect.Method.invoke(Unknown Source) ~[?:?]
mc-ksu        | 	at net.fabricmc.loader.launch.server.FabricServerLauncher.launch(FabricServerLauncher.java:68) [fabric-server-launch.jar:?]
mc-ksu        | 	at net.fabricmc.loader.launch.server.FabricServerLauncher.setup(FabricServerLauncher.java:114) [fabric-server-launch.jar:?]
mc-ksu        | 	at net.fabricmc.loader.launch.server.FabricServerLauncher.main(FabricServerLauncher.java:56) [fabric-server-launch.jar:?]
mc-ksu        | 2021-07-10T04:21:13.824+0900	WARN	mc-server-runner	sub-process failed	{"exitCode": 1}
mc-ksu        | 2021-07-10T04:21:13.824+0900	INFO	mc-server-runner	Done

Looks like running Minecraft 1.17.1( But I defined VERSION: 1.17!)
It was working fine in this configuration until a few days ago, how can I continue with 1.17 instead of updating the mod?

If I remove the VERSION, I can run my server with Minecraft 1.17.
mc-ksu        | [init] Resolved version given 1.17 into 1.17
mc-ksu        | [init] Resolving type given VANILLA
mc-ksu        | [init] server.properties already created, skipping
mc-ksu        | [init] Checking for JSON files.
mc-ksu        | [init] Setting initial memory to 6G and max to 6G
mc-ksu        | [init] Starting the Minecraft server...
mc-ksu        | [04:26:27] [main/INFO]: Environment: authHost='https://authserver.mojang.com', accountsHost='https://api.mojang.com', sessionHost='https://sessionserver.mojang.com', servicesHost='https://api.minecraftservices.com', name='PROD'
mc-ksu        | [04:26:28] [main/WARN]: Ambiguity between arguments [teleport, location] and [teleport, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
mc-ksu        | [04:26:28] [main/WARN]: Ambiguity between arguments [teleport, location] and [teleport, targets] with inputs: [0.1 -0.5 .9, 0 0 0]
mc-ksu        | [04:26:28] [main/WARN]: Ambiguity between arguments [teleport, destination] and [teleport, targets] with inputs: [Player, 0123, @e, dd12be42-52a9-4a91-a8a1-11c01849e498]
mc-ksu        | [04:26:28] [main/WARN]: Ambiguity between arguments [teleport, targets] and [teleport, destination] with inputs: [Player, 0123, dd12be42-52a9-4a91-a8a1-11c01849e498]
mc-ksu        | [04:26:28] [main/WARN]: Ambiguity between arguments [teleport, targets, location] and [teleport, targets, destination] with inputs: [0.1 -0.5 .9, 0 0 0]
mc-ksu        | [04:26:28] [main/INFO]: Reloading ResourceManager: Default
mc-ksu        | [04:26:29] [Worker-Main-14/INFO]: Loaded 7 recipes
mc-ksu        | [04:26:30] [Worker-Main-14/INFO]: Loaded 1137 advancements
mc-ksu        | [04:26:34] [Server thread/INFO]: Starting minecraft server version 1.17
mc-ksu        | [04:26:34] [Server thread/INFO]: Loading properties
mc-ksu        | [04:26:34] [Server thread/INFO]: Default game type: SURVIVAL
mc-ksu        | [04:26:34] [Server thread/INFO]: Generating keypair
mc-ksu        | [04:26:34] [Server thread/INFO]: Starting Minecraft server on *:25565
mc-ksu        | [04:26:34] [Server thread/INFO]: Using epoll channel type
mc-ksu        | [04:26:35] [Server thread/INFO]: Preparing level "world"
mc-ksu        | [04:26:35] [Server thread/INFO]: Preparing start region for dimension minecraft:overworld
mc-ksu        | [04:26:36] [Worker-Main-10/INFO]: Preparing spawn area: 0%
mc-ksu        | [04:26:36] [Worker-Main-10/INFO]: Preparing spawn area: 0%
mc-ksu        | [04:26:36] [Worker-Main-10/INFO]: Preparing spawn area: 0%
mc-ksu        | [04:26:36] [Worker-Main-9/INFO]: Preparing spawn area: 0%
mc-ksu        | [04:26:37] [Worker-Main-13/INFO]: Preparing spawn area: 0%
mc-ksu        | [04:26:37] [Worker-Main-13/INFO]: Preparing spawn area: 0%
mc-ksu        | [04:26:38] [Worker-Main-12/INFO]: Preparing spawn area: 0%
mc-ksu        | [04:26:38] [Worker-Main-8/INFO]: Preparing spawn area: 4%
mc-ksu        | [04:26:39] [Worker-Main-10/INFO]: Preparing spawn area: 8%
mc-ksu        | [04:26:39] [Worker-Main-10/INFO]: Preparing spawn area: 8%
mc-ksu        | [04:26:40] [Worker-Main-11/INFO]: Preparing spawn area: 9%
mc-ksu        | [04:26:40] [Worker-Main-9/INFO]: Preparing spawn area: 10%
mc-ksu        | [04:26:41] [Worker-Main-11/INFO]: Preparing spawn area: 20%
mc-ksu        | [04:26:41] [Worker-Main-10/INFO]: Preparing spawn area: 25%
mc-ksu        | [04:26:42] [Worker-Main-11/INFO]: Preparing spawn area: 45%
mc-ksu        | [04:26:42] [Worker-Main-12/INFO]: Preparing spawn area: 72%
mc-ksu        | [04:26:43] [Worker-Main-12/INFO]: Preparing spawn area: 93%
mc-ksu        | [04:26:45] [Server thread/INFO]: Time elapsed: 10318 ms
mc-ksu        | [04:26:45] [Server thread/INFO]: Done (10.506s)! For help, type "help"
mc-ksu        | [04:26:45] [Server thread/INFO]: Starting remote control listener
mc-ksu        | [04:26:45] [Server thread/INFO]: Thread RCON Listener started
mc-ksu        | [04:26:45] [Server thread/INFO]: RCON running on <IP_ADDRESS>:25575

Looks like the script needs to name the fabric launcher files by version. In the mean time, I think you can work around this by deleting files that start with .fabric-installed- in the data directory.

I removed the .fabric-installed- and I can run fabric server with Minecraft 1.17!
Thanks a lot for advice!!!


Disable past dates

PR for https://github.com/abadi199/datetimepicker/issues/26
API:

This adds an earliestDate option

UI:

Dates outside of the range are greyed out, have no hover state, and cannot be clicked on

Future work:

Add a latestDate option
Disable month/year nav to months/years that are outside of the range
Prevent selection of a disabled date via typing
Deal with selection of times on the same day, but after earliestDate

(this in itself would only be a minor version bump, but this will land after #27, which will be a major version bump)


perf: speed up cohort definers

@sarakolding We needed to speed up the CohortDefiners. I've moved a lot of the operations to LazyFrames to accomplish that.  Thanks a ton!

(I'm merging because we need it, but will fix any comments you come up with 👍)

alright men så får du altså heller ikke nogen havregrynskugler ;-p

Så er det fixet!

aber nein @MartinBernstorff

Beklager!


[sdk] halo device rename

This is currently supported in SDK through the DevicesService, see the device update CLI command.


Consume websocket apis

Issues:

Inbound websocket changes cause user input to be erased. This is particularly annoying for modal popups which close/reopen, losing all state.
roadhog dev server doesn't forward websockets (need layer 4 forwarding), workaround should be to ignore CORS and create sockets directly to LONGHORN_MANAGER_IP - currently hardcoded to <IP_ADDRESS>

@ly5156 will fix the first issue.
I will submit another PR to fix the second issue.
And we need to merge the backend change first.
Thanks

Merged, thanks.


Cannot test for magic actions

I ran into an issue trying to assert that a property was wired in my component, but via a magic action.
Change assigned user
In my Livewire component changeUser is a property with a boolean value. I tried the following tests and both failed to match for a PCRE pattern.
Livewire::test(AssignUser::class,[
        'maintenanceRequest' => $maintenanceRequest,
    ])
        ->assertOk()
        ->assertMethodWired('$toggle(\'changeUser\')');

Livewire::test(AssignUser::class,[
        'maintenanceRequest' => $maintenanceRequest,
    ])
        ->assertOk()
        ->assertMethodWired(changeUser');

I think this could be accomplished by modifying the regular expression in the methods assertMethodWired and assertMethodNotWired to allow for magic actions.

Hey, did not know about the magic methods. Good point. Would you be willing to creat a PR for that?

Yes, definitely willing! Before I work on that, what tool are you using to test/build your regular expressions? I kept getting an error with the tester I was using with your existing regex so just looking to be consistent with existing code.

Hey, from what I remember, I did not write that regex 😅 The last few times I used AI to write it for me hehe. So if it can be improved, I'm open to that 👍


SpeechInputSource is not able to differentiate certain strings.

Before deploying an application to production we found that our application was not able to detect when the user said "112".
Input: "One One Two"
Output: Yields no results.
Input: "One One Two"
Output: Shows results for 113.
Input: "One Twelve"
Output: Shows results for 122.

This data comes from the Windows Speech APIs


Edit Repository Authorization

What happens is that I can't edit the repository even if I own it.

I already found out what's wrong with this and I can apply the necessary solution to fix this minor bug. :)

@CjayBillones Closing this issue as you fixed it already :smile:

Alright! Thanks a lot! :)
On Sat, Jun 13, 2015 at 2:48 AM, प्रथमेश Sonpatki<EMAIL_ADDRESS>wrote:

@CjayBillones https://github.com/CjayBillones Closing this issue as you
fixed it already [image: :smile:]
—
Reply to this email directly or view it on GitHub
https://github.com/codetriage/codetriage/issues/347#issuecomment-111587202
.


New Timeline section for Kaui Guide

A short section. Just 2 pages in the PDF version. LMK if you think we need more.

I agree the guide is getting unwieldy. I'll take some time to break it into separate files.


Path repos_path/cocoapods-local already exists - remove it first

`pod repo-art add cocoapods-local "https://xxxxx/api/pods/cocoapods-local"
Retrieving index from https://xxxxx/api/pods/cocoapods-local` into local spec repo cocoapods-local
[!] Path repos_path/cocoapods-local already exists - remove it first, or run 'pod repo-art update cocoapods-local' to update it
pod repo-art remove cocoapods-local [!] repo cocoapods-local does not exist
I also removed the entire cocoapods-local folder locally, but I still see this issue, when I try to add

I also met the same problem. How did you solve it

just for anyone that get's into this issue as well. I was able to fix it by going to cd ~/.cocoapods/repos and cd ~/.cocoapods/repos-art and removing the repo that has the error from both directories. It seems that the remove command is not deleting it from both.


Add to lower case func

Hey thanks for creating a PR, looks good! Only thing I would change is change the title of the checkbox "Lower Case" to "lower case".


fix: FluentDataGrid lags badly

🐛 Bug Report
The FluentDataGrid seems to struggle with lag when it displays a lot of rows (and by a lot I don't mean hundreds of thousands, not even a hundred is enough to cause this behavior).
When using tab/arrow keys to navigate through the grid, it appears that the grid gets re-rendered every time the active cell changes.
This might potentially happen with other actions as well (for example when clicking on the grid).
This becomes more apparent the more rows a grid has (since it needs to re-render more rows each time).
💻 Repro or Code Sample
In the official documentation, remove the Pagination parameter from the FluentDataGrid in the DataGridTypical.razor example.
Then use tab to focus the grid and hold down the downwards arrow key on your keyboard.
This causes the whole page to freeze until the focus caught up.
🤔 Expected Behavior
No lag.
😯 Current Behavior
A lot of lag.
💁 Possible Solution
Not a real solution but like I have written, it appears that the grid tries to re-render too often.
This should probably be limited somehow.

Have you looked at the virtualise feature of the datagrid. I think that is what you need to use.

Are you using Chrome as well? Otherwise I have no idea why it looks like this to me:
https://github.com/microsoft/fluentui-blazor/assets/143792830/c667fdbb-918a-4083-b4da-a5f11b7dd08a

Have you looked at the 'Virtualized grid' feature of the datagrid. I think that is what you need to use. It is in the samples of the datagrid.

I know of this feature but our requirement is to use pagination and we want to show around 250 items per page

Are you using Chrome as well? Otherwise I have no idea why it looks like this to me:

Tested on Edge Canary (Version 126.0.2547.0 (Official build) canary (64-bit)) and Firefox Developer Edition (Version 126.0b5). Both work perfectly fine.
Which Chrome version?

Which Chrome version?

Version 124.0.6367.92 (Official build) (64-Bit)
I did try with Edge as well (124.0.2478.51 (Official build) (64-Bit)) and the same happens. Looks like you are some versions ahead but for me it says those are the latest versions 🤔

And perhaps try with QuickGrid as well(https://aspnet.github.io/quickgridsamples/)

It seems that with QuickGrid the cells are not focusable.

Sorry. But if we can't reproduce it, we can't investigate it.

It seems that with QuickGrid the cells are not focusable.

Ah, right! We are quite focused on the whole a11y thing as we find that important.

No worries, it's just kind of weird :D


Nest can't resolve dependencies of the RedisCoreModule (Symbol(REDIS_MODULE_OPTIONS), ?). Please make sure that the argument ModuleRef at index [1] is available in the RedisCoreModule context.

// config.ts
export const redisConfig: RedisModuleOptions = {
  url: 'redis://treehole:redis@localhost:6379/1',
}

import databaseConfig, { redisConfig } from './config/database.config'

@Module({
  imports: [TypeOrmModule.forRoot(databaseConfig), UserModule, AuthModule, RedisModule.register(redisConfig)],
  controllers: [],
  providers: [],
})
export class AppModule {}

But it gave me an error
[Nest] 35656  - 2022/02/14 下午3:50:35   ERROR [ExceptionHandler] Nest can't resolve dependencies of the RedisCoreModule (Symbol(REDIS_MODULE_OPTIONS), ?). Please make sure that the argument ModuleRef at index [1] is available in the RedisCoreModule co
ntext.

Potential solutions:
- If ModuleRef is a provider, is it part of the current RedisCoreModule?
- If ModuleRef is exported from a separate @Module, is that module imported within RedisCoreModule?
  @Module({
    imports: [ /* the Module containing ModuleRef */ ]
  })

Error: Nest can't resolve dependencies of the RedisCoreModule (Symbol(REDIS_MODULE_OPTIONS), ?). Please make sure that the argument ModuleRef at index [1] is available in the RedisCoreModule context.

Potential solutions:
- If ModuleRef is a provider, is it part of the current RedisCoreModule?
- If ModuleRef is exported from a separate @Module, is that module imported within RedisCoreModule?
  @Module({
    imports: [ /* the Module containing ModuleRef */ ]
  })

    at Injector.lookupComponentInParentModules (C:\Dev\hfut-tree-hole\nest\node_modules\@nestjs\core\injector\injector.js:202:19)
    at Injector.resolveComponentInstance (C:\Dev\hfut-tree-hole\nest\node_modules\@nestjs\core\injector\injector.js:157:33)

What happen? And what should i do to solve it? I'm sure that the redis server is no wrong.

same issue here

same here, seems to be issue with nest 8

same issue here

same issue here

不是很明白，老哥能说清除一些么

same here

same issue

same

https://github.com/skunight/nestjs-redis/issues/82

same issue

Same here

Same here

Same here

Fixed by using @liaoliaots/nestjs-redis instead.

same issue

一样的问题

这个包是不维护了吗？

I had the same problem,
I saw that the version on npm and the version on gitlab were not the same:
https://github.com/skunight/nestjs-redis/releases
https://www.npmjs.com/package/nestjs-redis
To solve the problem I put myself to the version on gitlab.
Solution :
Change the package.json :
"nestjs-redis": "^1.2.2",`

Is this resolved yet?

same issue

same issue

For anyone having this issue, I resolved this by switching over to https://www.npmjs.com/package/@liaoliaots/nestjs-redis.

issue is caused by @nestjs/core and other nestjs libraries in nestjs-redis package.json dependencies. It should be moved to peer dependencies.
I guess Nest.js trying to inject ModuleRef from nestjs-redis/@nestjs/core instead of @nestjs/core installed in your app.

Same issue! now use  https://www.npmjs.com/package/@liaoliaots/nestjs-redis is works


How to get information about an event's sender?

Is it possible to get the ID and the name of an incoming event's sender?
    def receive(incoming_events)
      incoming_events.each do |event|
        # I don't know what to do here ...
      end
    end

Sorry for the late response, event.agent.id should be the id of the Agent that created the Event (event.agent.name the name).


SOLR-17057: JSON Query regression of defType

If "query" is specified with a String (not JSON structure), "defType" should parse it. Since 9.4 defType was ignored.
https://issues.apache.org/jira/browse/SOLR-17057

+1 for a 9.4.1 release for this issue. I was just upgrading the code for the upcoming AI-Powered Search book, and the most of the book's query examples are now returning no results due to this issue: https://github.com/treygrainger/ai-powered-search/issues/78
Works fine up through Solr 9.3, but most queries are broken with 9.4.0 since we use the edismax query parser through the JSON DSL for most queries.

Thank you @dsmiley !

Thanks, @dsmiley - looking forward to it! :pray:


DRILL-7330: Implement metadata usage for all format plugins

DRILL-7330: Implement metadata usage for all format plugins
Description
This pull request adds support of all format plugins for Metastore.
It contains two parts:

Making changes to collect metadata for easy group scan
Allowing usage Metastore metadata for easy group scan during querying data

To reach the first goal was added AnalyzeFileInfoProviderImpl to handle correctly EasyGroupScan tables in MetastoreAnalyzeTableHandler and specify correct table type.
Accommodated EVF scan framework to incorporate Metastore-specific additional implicit columns and handle the case of empty files when metadata should be returned.
To reach the second goal, EasyGroupScan was updated to extend AbstractGroupScanWithMetadata.
MetastoreFileTableMetadataProvider based on existing MetastoreParquetTableMetadataProvider was introduced to provide metastore metadata for file-based tables.
Accommodated ParquetPushDownFilter rule to work with easy format plugins.
Refactored some code and fixed additional issues.
Documentation
After this PR is merged, Drill Web Site docs should be updated to reflect this feature.
Testing
Added tests to verify the correctness of collected metadata and ensure that new optimizations work correctly.

Looks like a very cool feature. I've not been following the metadata implementation closely. Can you help get me up to speed by providing a bit more background information? What is the goal of this PR? Does it enable the format plugins to gather metadata if they choose, or does this PR actually add the metadata gathering itself?
As I understand it, one of the things that the metadata framework does is to infer schema. Whether inferring schema for metadata, or inferring schema for a scan, we hit the same ambiguities. How does this code handle a schema conflict? Or, do we just assume the schema is whatever we get in the sample?
How do we gather stats? Do we have the reader read all the data and have a downstream operator make sense of the data?
For files that need a provided schema (CSV, say), do we apply stats to the columns after type conversion, or are stats gathered on the raw text values? That is, does this work use the provided schema if available? How does the provided schema relate to the metadata schema?
What stats will we gather for non-Parquet files? How will we use them? Looks like there is code for partitions (have not looked in depth, so I may be wrong). Are we using stats for partition pruning? If so, how does that differ from the existing practice of just walking the directory tree?
I think that if I understand some of this background I'll be able to do a more complete review. Thanks!
Just so we're on the same page, I'm working on a revision to how we handle schema. Basically, the EVF-based operators will fully integrate the provided schema, and will be ready for a "defined" schema created by the planner (as in a classic query engine where the planner does all the schema calculations.) The idea is to use dynamic schema (what Drill has always done) when sampling the first row tells us all we need to know (as in Parquet), but to encourage a provided schema when sampling is not reliable (as in JSON.)
This means that we have a flow something like this:
User --> Provided Schema --> Scan <-- Reader <-- Input Source Schema
                               |
                               v
                     Scan output schema

The scan output schema describes the data a scan will deliver. Hopefully, this is also the schema used by stats gathering.
Do you see any potential conflicts between your metadata model and the above provided schema model?

@paul-rogers, this pull request enables the format plugin to gather metadata. Metadata gathering logic was added in DRILL-7273.
Regarding the schema, when metadata is collecting, rules are the same as for regular select queries - Drill tries to infer the table schema or uses user-provided schema.
Collecting metadata logic may become clearer after reading this section of docs: https://github.com/apache/drill/blob/master/docs/dev/MetastoreAnalyze.md#analyze-operators-description or this design doc: https://docs.google.com/document/d/14pSIzKqDltjLEEpEebwmKnsDPxyS_6jGrPOjXu6M_NM/edit?usp=sharing
In short, yes, we use a reader that reads all the data and downstream operators for transforming and storing its statistics.

For files that need a provided schema (CSV, say), do we apply stats to the columns after type conversion, or are stats gathered on the raw text values? That is, does this work use the provided schema if available?

Yes, we apply stats to the columns after schema conversion, so such stats as min/max would have correct values in the scope of natural ordering.

How does the provided schema relate to the metadata schema?

After the provided schema is used in the scan, Drill will use the resolved schema for columns and store it to the metastore.

What stats will we gather for non-Parquet files? How will we use them? Looks like there is code for partitions (have not looked in depth, so I may be wrong). Are we using stats for partition pruning? If so, how does that differ from the existing practice of just walking the directory tree?

We collect exactly the same stats for non-parquet files. We may use them in the same way as it is used in parquet - prune files when filter for specific columns is specified, prune unneeded files for limit queries. Dirs pruning would still work in the same way as it worked before changes (it also works for parquet).
I think some tests in TestMetastoreWithEasyFormatPlugin will help to understand which optimizations are added.

Do you see any potential conflicts between your metadata model and the above provided schema model?

Looks like there shouldn't be any conflicts.

@vvysotskyi, I hope the comments more-or-less made sense; I was relearning this code, and learning the metadata stuff, as I went.
An earlier note mentioned that I'm revising the managed framework. It also suggested a different way to parse out the implicit columns. To avoid blocking you, we can use the design here. Then, I'll adjust it as needed to fit the new classes. (In fact, I've already made some changes based on what I learned here.)

@paul-rogers, your comments as always highly useful - they either enforce making the code clearer and making the design better.
Thanks a lot for the review and for revising the managed framework, I definitely need your help with the managed framework, I tried do not to break the logic a lot with my changes connected with handling metadata for empty files, but I agree that it looks somewhere slightly odd.
Also, thanks for offering to use for now the design here. In this case, I'll address other CR comments ASAP and provide the intension for my changes in the managed framework classes.

LGTM, +1

@arina-ielchiieva, thanks a lot for the review!
@paul-rogers, did you have a chance to take a look at new changes?


feat: add accessibility documentation for Tag component

Closes https://github.com/yamada-ui/yamada-ui/issues/1576
Description

Added accessibility documentation for Tag.
Is this a breaking change (Yes/No):

No

https://github.com/yamada-ui/yamada-ui/issues/3014
As soon as this issue is closed, it will be reopened.

@kaehehehe @neginasu @hirotomoyamada
Please check again as I have added explanations for the internal components!


Fix a tiny detail

Keep everything consistent.

@itsjoeoui Well spotted! Thanks for your noticing this.


Add access to 'data' with indifferent access

Previously, Structural was changed to only allow access to keys via symbols, however there are projects using this library that access 'data' via 'string' keys. Since 'activesupport' is a dependency of this gem, we can leverage it to provide the desired behaviour.

I think we should keep this one open until we find out if the change could end up reversing some of the performance improvements that were implemented in the previous release.


Add wheel signal

Wheel motion signal is acquired with a magnetic angle sensor attached to the wheel.
Spike2 software is used to control the acquisition, together with the other TTL signals #4.
Minor inconvenient in the .smrx file the gain is specified as " Volt" (note the space before the word Volt).
In the neobaseextractor an additional_gain is multiplied to the Spike2 gain to perform the correct conversion. It assigned the correct conversion factor by looking for ["V", "Volt", "mV", "uV"] in the unit field of the .smrx data.
Here, being the wheel signal unit reported as " Volt" it is not matched --> the wrong conversion factor is assigned.
Solution to be discussed: for now I am just modifying the neobaseextractor to match also [" Volt", "Volts"].

stub nwb file with just the wheel motion data: https://catalystneuro-processing.s3.us-east-2.amazonaws.com/higley-lab-to-nwb/11222019_grabAM05_spont_WheelMotion.nwb

Minor inconvenient in the .smrx file the gain is specified as " Volt" (note the space before the word Volt).
In the neobaseextractor an additional_gain is multiplied to the Spike2 gain to perform the correct conversion. It assigned the correct conversion factor by looking for ["V", "Volt", "mV", "uV"] in the unit field of the .smrx data.
Here, being the wheel signal unit reported as " Volt" it is not matched --> the wrong conversion factor is assigned.
Solution to be discussed: for now I am just modifying the neobaseextractor to match also [" Volt", "Volts"].

Have you tried overriding the unit field in the extractor to be the correct "Volt"?
e.g.
self.recording_extractor.set_property(
    key="unit",
    values=["Volt"], # probably ["Volt"] * num_channels but you'll have to check.
 )

Ref

stub .nwb here


Optimise images.

Saved 1.1 MB out of 9.7 MB. 22.3% per file on average (up to 62%).
Most of those are in the docs. The most significant is probably the 4.7% (2586 -> 2464 bytes) saving in dist/images/marker-icon-2x.png after running it through pngout.
For every file, ImageOptim compared the different tools and picked the smallest file that was produced by or by a combination of advpng, pngout and zopfli for PNGs, gifsicle for GIFs, svgo for SVGs or jpegoptim and mozjpeg for JPEGs.
No related issues, no code change, no functionality change, no visual differences in images (compression is lossless).

I wasn't aware that we could squeeze the marker image a further 5% 😄


Need to update the debugging way to use the serve.json method

I think we need to update the debugging method in this article to use the serve.json method mentioned at https://docs.microsoft.com/en-us/sharepoint/dev/spfx/debug-modern-pages

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

ID: 7b7cd562-b54f-0157-2912-e8100a9dbb0b
Version Independent ID: 6b9554bd-2d7e-d8b0-7461-c80dd89f5be8
Content: Tutorial - Migrating from Edit Control Block (ECB) menu item to SharePoint Framework Extension
Content Source: docs/spfx/extensions/guidance/migrate-from-ecb-to-spfx-extensions.md
Product: sharepoint
GitHub Login: @spdevdocs
Microsoft Alias: spdevdocs

Thanks! I have added a note within the debug section to point them towards using serve configurations.


Swagger annotations $ref as string

Describe the bug

When trying to use $ref to point to an external schema json, the definition is only returned as just "string". It's not able to resolve the path to the json it seems. 'Could not resolve reference: Tried to resolve a relative URL, without having a basePath.'
/**
 * @swagger
 * /api/example:
 *   get:
 *     description: Example description
 *     responses:
 *       200:
 *         description: Success
 *         content:
 *            application/json:
 *             schema:
 *               $ref: schemas.json#/definitions/AnExampleDefinition
 */

External schema:
{
    "$ref": "#/definitions/AnExampleDefinition",
    "$schema": "http://json-schema.org/draft-07/schema#",
    "definitions": {
        "AnExampleDefinition": {
            "additionalProperties": false,
            "properties": {
                "isThisPossible": {
                    "type": "boolean"
                }
            },
            "required": ["isThisPossible"],
            "type": "object"
        }
    }
}

Any help appreciated
Reproduction
Complete
System Info
System:
    OS: macOS 12.5.1
    CPU: (8) arm64 Apple M1
    Memory: 1.84 GB / 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.19.0 - ~/.nvm/versions/node/v16.19.0/bin/node
    npm: 8.19.3 - ~/.nvm/versions/node/v16.19.0/bin/npm
  Browsers:
    Safari: 15.6.1

Used Package Manager
npm
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guide.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Check that this is a concrete bug. For Q&A, please open a GitHub Discussion instead.
[X] The provided reproduction is a minimal reproducible of the bug.

We do have a bit of a hacky workaround which is to convert our schema.json into a @swagger annotation format programatically but not ideal that we are converting for it to be used


test(server): use describe.each()() for duplicate test suites

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
563

Relevant Lines:
563

💛  - Coveralls


Implement async method decode_audio_data (however still blocking IO)

Fixes https://github.com/orottier/web-audio-api-rs/issues/423

Build fails because we need to bump the MSRV to Rust 1.75 - https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-traits.html
1.75 was released end of december 2023
I don't think this PR is very important, so maybe let's wait till June so we can keep our MSRV to lag 6 months behind


First release in 2021?

When first release planned in 2021?
Thank you,
Olexandr

Hi @vicroms
Are you clear something about the plan to release?
Thanks.

We have separated releases for vcpkg-tool (the vcpkg executable) and the vcpkg catalog.
I assume this is about the latter. I want to point out that we recommend users to use the latest sources from the vcpkg repository instead of depending on these "release".
The generated release tags are arbitrary, usually we did one every month but sometimes we forgot to do them, and since there isn't any special meaning behind when we decide to do them and no automated process to generate them, depending on new "releases" is unreliable.
If a user needs a specific revision of vcpkg, our recommendation is to checkout a specific commit or consider enabling versioning  and using the builtin-baseline field.
Finally, I'll take a look at generating a new release tag this week.

Closing this issue for now since I think it has been answered by @vicroms. Please feel free to reopen this issue if you still have other concerns.


New created projects have null adminUser

@RamRamez  has reported it

@maryjaf It's done and deployed on Staging

Thanks @mohammadranjbarz
I tested and this issue has been resolved


Tests use pytest fixtures and tempfiles

Add some tests for local_server, boolean evaluate of objects. Rewrote tests to use tempfiles and pytest fixtures.
All the tests will pass once all PR's have been merged.

I fixes the conflicts, it should be ready to merge now. Cheers

Ok. Later on today I'll be checking it out. It's 5:55 AM...
Thanks again.


Issue with expired token on Firebase Android is back?

Hi
On the Android implementation, we are having an issue that is supposed to be fixed. You can see issue #28 for reference. Every time that the application calls the OnRegistered method, it is always receiving the same token, an expired token. I don't see any other work around than to call the UnRegister method every time that I open the application. This is supposed to be fixed by now. We are missing something?
Please, enlight us.
Thank you

Sam

I'm facing the same issue.
Did you find a solution? @SamyCode

I'm explaining more.
At first release and deploy to the smartphone from VS is OK.
But If I rebuild and deploy again, the token is not changed but FCM said it's unregistered token which was just successed to send a push message.

Ah, OK.
If I do CrossPushNotification.Current.Unregister(); before new register when the app has a previous token, everything goes fine.
It resolved my issue.


fix: use project_id for GSA email

The email is invalid with id, and expects project_id. Also removes the redundant project prefix.

/assign @karlkfi

/hold

/unhold


(Hopefully) fix a flake in Spdy3ConnectionTest on Android

In some cases serverSocket is found to be null in
readAndWriteFrames().
The suspicion is that it's because of a lack of synchronization
between the thread setting the field, and the thread (started in
play()) reading it. serverSocket / port have been made
volatile to ensure the field state is flushed / read and not
cached. No flakes seen in several runs since the change.

Not sure where Travis CI is. Closing and re-opening to kick it.

The synchronization occurs with the call to executor.execute(). From the ExecutorService docs, "Memory consistency effects: Actions in a thread prior to the submission of a Runnable or Callable task to an ExecutorService happen-before any actions taken by that task, which in turn happen-before the result is retrieved via Future.get()."

That is, if you're seeing those fields not initialized, it's more likely that close() is being called before readAndWriteFrames() runs. That could be a problem, but I don't think this fixes it.
(We also had that problem in MockWebServer; the fix was 12f858caac6b9215b7d3cd84a781c812fae6c2bb

Think you're correct.


fixed quota deep copy and cyclestate

Signed-off-by: fjding<EMAIL_ADDRESS>Ⅰ. Describe what this PR does
fixed quota deep copy and cyclestate
Ⅱ. Does this pull request fix one issue?

Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews
V. Checklist

[ ] I have written necessary docs and comments
[ ] I have added necessary unit tests and integration tests
[ ] All checks passed in make test

/approve

/milestone v1.1


Passing request parameters to router

Related to a question of another user I found on StackOverflow:
https://stackoverflow.com/questions/34392834/express-js-how-can-i-pass-a-url-param-from-the-main-router-to-another-router-m
Is the only possibility to pass a request parameter to another router, to add a custom middleware function?
It would be nice if it could be passed automatically, or is there a reason why this doesn't happen? I don't really see a good reason to be honest.

Their roomRouter just needs to have mergeParams: true set. http://expressjs.com/en/4x/api.html#express.router

Makes sense, thank you!


HSEARCH-4703 backport to 6.1

https://hibernate.atlassian.net/browse/HSEARCH-4703
Backport of HSEARCH-4703 to 6.1. If I got it correctly, 6.1 didn't yet have a standalone mapper - so that results in 2 standalone test modules not being backported.
When I was running the orm6/jakarta tests locally, the build was failing with some unrelated Javadoc warning - so wanted to see if it'll work fine on CI 😃

aaaaaaaand it failed too 🥲 looking into it 😃


make iotools package

I made a new io branch to try to streamline the process of multiple users contributing their new io tools and to make it easier for all of us to test it them without hurting the master branch. I also went ahead and moved the tmy readers into the package and updated the tests accordingly. I named the package iotools since Cliff expressed a preference for that name, but it's not yet set in stone. I think this is mostly consistent with what we talked about in #261 and #29. Let me know if I missed something concerning the structure.
Please make your new IO tools pull requests against this branch rather than master.
Finally, I'm not going to merge into master until we're ready to make a series of changes to the API. I want to do at least 0.4 release with non-API breaking changes before then.

I added a reader for PVSyst files:
https://github.com/dacoex/pvlib-python/commits/io
--> added pvsyst reader
This also shows the challenge in getting metadata from CSV files of different sources.
It also shows that pvlib variable list is not complete when compared to PVSyst output, for instance.
I hope this helps to define

minimum specifications for the io readers
optional components of the readers

I think we shall agree on the general structure before improving each reader (documentation / testing)

I think we shall agree on the general structure before improving each reader (documentation / testing)

I think we essentially agreed on the general structure in #261. Is there some part of the structure that you disagree with? At this point, I think our time is better spent focusing on implementing new readers.

@dacoex thanks so much for getting this off the ground. And to @wholmgren for setting up the branch for development.  I'll get the surfrad reader uploaded, and copy the tmy readers over.  Great to see the progress!

Great! Be sure to fetch and checkout the new io branch from the main github organization before adding your surfrad reader. I already moved the Tmy readers so it shouldn't be necessary to touch them. Sorry Cliff and @dacoex for the git confusion and my poor explanations.

I think this is ready to be reconsidered after almost 2 years. In short:

tmy.readtmy2 becomes iotools.read_tmy2
tmy.readtmy3 becomes iotools.read_tmy3
new IO related tools will go in new modules under iotools, with their top-level functions exposed through iotools.api

The old functions remain but emit deprecation warnings. I marked them for removal in 0.7 for now.
Here's a link to the rendered API documentation: https://pvlib-python.readthedocs.io/en/io/api.html#io-tools
We'll make a few PRs for adding U Oregon SRML and Surfrad in the next couple of weeks. We'll make the PRs to the io branch if it's not yet merged into master at that point.
I'm ignoring the majority of the Stickler errors since they're not really new and I don't care to take the time to fix them. Unfortunately I don't know how to turn them off for this PR. At least it didn't inline the comments!

Closes #29. Closes #261.
@mikofski any new thoughts/objections on package structure 2 years later?

TL;DR: I like the new structure. iotools.read_tmy3 is a lot more elegant than tmy.read_tmy3 and I like that many different data sources and formats can be grouped together, in addition to TMY. It will be interesting to see what output formats there are in iotools, since currently there are only feature requests for inputs.
Although I think api is fine, it seems redundant, since IMO that's what __init__ is for, but I'm not opposed to api, I just think it's unnecessary. So if you think it's more explicit or that __init__ is less readable than that seems fine to me

I like the api.py and empty __init__.py idea

Sorry, that statement from 2 years ago contradicts my review here. I guess I'm ambivalent. But I respect your judgement

Hearing no objections, I will go ahead and merge this. We can easily change (or even revert) through the next release.


Key Expired: 2017-06-04 for p_conrad repository

Any change this will be updated soon?

I have updated the key. You may have to download
the key with the new signature, I don't know if it will update
automatically.
--
Cyrano UG (haftungsbeschränkt)
Alicestr. 102
63263 Neu-Isenburg
Germany
Tel.: +49 6102 821206
Geschäftsführer: Peter Conrad
AG Offenbach
HRB Nr. 47931
USt-ID: DE296491819

Thank you, I did the manual key-update.
BTW: is there a specific reason for using SHA1?
On Jun 12, 2017 6:53 PM, "Peter Conrad"<EMAIL_ADDRESS>wrote:

I have updated the key. You may have to download
the key with the new signature, I don't know if it will update
automatically.
--
Cyrano UG (haftungsbeschränkt)
Alicestr. 102
63263 Neu-Isenburg
Germany
Tel.: +49 6102 821206 <+49%206102%20821206>
Geschäftsführer: Peter Conrad
AG Offenbach
HRB Nr. 47931
USt-ID: DE296491819
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/namecoin/namecoin-legacy/issues/239#issuecomment-307849482,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZSnYulPb6aFBMzRTixslrMEL5g3HbCjks5sDW0JgaJpZM4N2Y8g
.

Keys and signatures are generated by the open build service. I have no control over them. (Except that I can request that the signature be updated.)

Got it, thanks again.


Intero versions and Stack resolvers

https://github.com/commercialhaskell/intero/blob/master/elisp/intero.el#L67 shows that the intero package itself assumes that the intero version available in the parent stack environment will be 0.1.15. As of (at least) nightly-2016-08-01, intero is sitting at 0.1.16. Attempting to install intero automatically (as usual) in such a project current fails unless one manually customizes intero-package-version.
How should this be handled? We can't exact just bump intero-package-version up to 0.1.16 here in the source, as that would alienate older snapshot users.

How should this be handled? We can't exact just bump intero-package-version up to 0.1.16 here in the source, as that would alienate older snapshot users.

We actually can do that - it will install an intero version regardless of your snapshot: https://github.com/commercialhaskell/intero/blob/master/elisp/intero.el#L1252
Not sure how it should be handled.  Some sort of build processes which substitutes the version number into the elisp??

It seems like detecting what intero is available to the snapshot shouldn't be difficult. You could keep internally a version that intero hopes for, and compare it to what's available. Then you could hard-fail on versions that differed by a major version, for API compatibility. Is intero PVP or semver?

Building intero-0.1.15 works fine on the nightly you specified:
bash-3.2$ stack new test
bash-3.2$ cd test/
bash-3.2$ echo 'resolver: nightly-2016-08-01' > stack.yaml
bash-3.2$ stack build intero-0.1.15
syb-0.6: configure
syb-0.6: build
ghc-paths-<IP_ADDRESS>: configure
syb-0.6: haddock
ghc-paths-<IP_ADDRESS>: build
ghc-paths-<IP_ADDRESS>: haddock
syb-0.6: copy/register
ghc-paths-<IP_ADDRESS>: copy/register
intero-0.1.15: configure
intero-0.1.15: build
intero-0.1.15: copy/register
Completed 3 action(s).
Updating Haddock index for snapshot packages in
/Users/chris/.stack/snapshots/x86_64-osx/nightly-2016-08-01/8.0.1/doc/index.html
bash-3.2$

Seems fine. 👍

It's not building it that's the problem, it's that with a fresh stack environment with nightly-2016-08-01 and no intero, the current intero.el will complain that 0.1.15 doesn't match the intero version available in the snapshot, 0.1.16.

@fosskers Can you give the output so that I can reproduce it?

I cleared my .stack_work, and reverted my customization of intero-package-version back to 0.1.15, as matches the current state of the source. When I first open a Haskell file in my test project, I see:
The wrong version of Intero is installed for this Emacs package.

Installing intero-0.1.15 automatically ...

Error parsing targets: Specified target version 0.1.15 for package intero does not match snapshot version 0.1.16
Could not install Intero!

We don't know why it failed. Please read the above output and try
installing manually. If that doesn't work, report this as a
problem.

WHAT TO DO NEXT

If you don't want to Intero to try installing itself again for
this project, just keep this buffer around in your Emacs.

If you'd like to try again next time you try use an Intero
feature, kill this buffer.

Fixed in stack version 1.1.0: https://github.com/commercialhaskell/stack/issues/2028

haskell-core/haskell-stack <IP_ADDRESS>_4-1
    The Haskell Tool Stack
haskell-core/haskell-stack-tool <IP_ADDRESS>_4-1 [installed]
    The Haskell Tool Stack - the binary
community/haskell-stack 1.1.2-14
    The Haskell Tool Stack (docs and libraries)

It seems the ArchHaskell repo is actually behind the official one, for once.

haskell-core seems to be going defunct. After installing the version of stack from community, intero installs into new projects as expected. Thanks guys!

Welcome!  I've split off #217 to track checking stack version


Delete Documents.Save parameters in Document.Save

Document.Save Method (Word) has no parameters in the VBE Object Browser.

italicize,
Thank you for your contribution. Your efforts help make our documentation more technically accurate.
Office Scale Team


fix services syntax in rails example

The services syntax is wrong in the Rails Getting Started example

Thanks, Rob!


Perftest does not honour the child_chain value

Follows on from an internal discussion.
https://github.com/omisego/elixir-omg/blob/6df52caa9f7aee079cb9b7f78e63ee8d1d44a80d/apps/omg_performance/lib/omg_performance/sender_server.ex#L192 suspected as the cause.
iex(17)> OMG.Performance.start_extended_perftest(10_000, alices, contract_addr, %{destdir: ".", geth: System.get_env("ETHEREUM_RPC_URL"), child_chain: "http://childchain-samrong"})
2019-09-02 09:50:09.371 [warn] module=OMG.Watcher.HttpRPC.Adapter function=rpc_post/3 ⋅Child chain rpc post "http://localhost:9656/transaction.submit" failed with {:error, %HTTPoison.Error{id: nil, reason: :econnrefused}}⋅

Thanks!
I'd vote to treat it as an opportunity to clean the way the URLs are delivered (there's two - ethereum rpc and child chain). Let's keep it as simple as possible - probably just rely on the configs and drop from the options delivered in the invocation. Nowadays both URLs can be given via ENV vars.

Let's do that after we introduce releases? They already massively clean configs and how values are to be passed in.

[ ] straight up fix honour the child_chainvalue for perf tests
[ ] cleanup configs after https://github.com/omisego/elixir-omg/pull/884

should be fixed after #1106. Let's close and open a new issue if problem persists


Error order for comparing the decimal128 or decimal256

Describe the bug
Decimal128 as a example, we use the [u8;16] to store the value of the decimal.
In order to compare the decimal128, we should use the signed compare order.
But the current implementation just compare the [u8;16] to get the order.
For example:
Decimal128(-1, 10,0).cmp(Decimal128(129,10,0) will get the result of Greater.
To Reproduce
    #[test]
    fn compare_i128() {
        let v: i128 = -1;
        let b1: [u8; 16] = v.to_le_bytes();
        let b2: [u8; 16] = 129_i128.to_le_bytes();
        println!("{:?}", b1);
        println!("{:?}", b2);
        if b1.eq(&b2) {
            println!("=")
        }
        println!("{:?}", b1.cmp(&b2));
    }

Expected behavior

Additional context

@viirya
I will fix it.

Good catch!


Adding temperature convertor

I can add a temperature convertor built using HTML, CSS, and Javascript with a good UI.

Go ahead and :

Build it.

Add it in the README.md file

Create a pull request.

#340 I have created a pull request for temperature converter, please review and merge it @DhanushNehru

Hello @DhanushNehru , @selemondev as I was working on this issue. I have created a pull request. Please review it.


Infer precise types for comprehensions over known iterables

For something like [x for x in (1, 2)], we should infer Literal[[1, 2]] instead of the current list[Literal[1, 2]]. This helps with some false positives from #275. #277 was supposed to do this but some preparatory work I did turned out to be more impactful than anticipated, so I merged it separately.

Fixed by #279


General discussion about alternative node provisioner and maybe alternative host OSes

I want to talk with you all about supporting alternative node provisioner other than coreos-cloud-init, and maybe alternative host OSes other than Container Linux in kube-aws.
Why
coreos-cloud-init is already deprecated since a year or more ago. Before coreos-cloud-init is completely dropped from Container Linux, we kube-aws users should have a solid way to keep provisioning our k8s nodes in a maintainable manner.
What
Extract parts of useradata/cloud-config-* files to declarative specs of the node roles, so that we can render various node provisioning configs from it - coreos-flavoed cloud-config and ignition/ct for Container Linux, vanilla cloud-config for Ubuntu, Amazon Linux(hopefully one used for AWS EKS), and so on.
Seems like a big change? Not really, especially for the declarative node role specs part. kube-aws has a secret mechanism to support implementing kube-aws plugins. A plugin is able to:

install arbitrary files and systemd units via the spec.configuration.node.roles configuration
add arbitrary kubelet and apiserver flags via spec.configuration.kubernetes

See https://github.com/kubernetes-incubator/kube-aws/issues/1136#issuecomment-376359784 for a working example.
Alternatives
How about simply dropping the existing coreos-flavored cloud-config templates and migrate to Ignition, probably a ct-based template? Doing so would greatly divide the kube-aws users into the two, and the early adapters for the ignition-based kube-aws would receive almost no business benefits until it matures.
So, I'd want to start by adding an optional support for Ignition-based templates, and gradually advocate people to try and migrate to it. Sounds good?
Let me retrospect where we are today. Even though Container Linux is an awesome piece of software and operating system in the world, we aren't actually leveraging it fully.
For example, we have been long disabled Container Linux's neat feature like auto-updates for extra operational confidence #1241. I believe we don't have a strong opinion to use rkt, although it did allowed us to get rid of the early-docker.service 2 years ago. Why do we need to stick ONLY to Container Linux when you don't fully utilize it? I do understand that the minimalism of Container Linux would be a great fit for the host OS of the container era. But would it justify kube-aws to be tied to Container Linux today?
Call for feedbacks
Will you keep using coreos-cloud-init until it is finally removed? Are you planning to use Ignition, or considering alternative host OSes like me?
Would you be happy with the change?
Are you Any input is welcomed. Thanks!
Relevant topics

Transforming features like kiam support to kube-aws plugins would make the transition easier. kube-aws plugins won't be affected by node provisioners by its nature. Extracting plugins out of current cloud-config would make it easy to translate it to other config formats.

Context
FYI, I'd leave old but relevant issues:
Migrating from coreos-cloud-init to Ignition: #728
General scripts/ assets that are deployed to nodes: #580
The kube-aws plugin system: #509 #751 #791

@mumoshu as per our discussion:

Which part of this could we break off first?
How will different options share parameters? Some sort of global variable set a bit like Helm?
Do you think we update a set of templates in a bucket and render later? Or we always render on upload? The second option seems less fragile but less dynamic also. Best to keep it simple for now and use the second option?
There were some previous discussions like https://github.com/kubernetes-incubator/kube-aws/issues/1089 where users update their clusters outside of kube-aws update and do not expect their changes to be wiped (but they are on controller cycles). However, we also have users who rely on kube-aws update to reset to known good values/provide update mechanism for a given cluster. Do we need to encapsulate any of that concern in this changeset? We were considering whether we needed to support optional and mandatory options in kube-aws, the latter of which is always wiped. However, the added complexity could confuse users and create more cluster problems and support issues than existing update issues. We could support generic ways to customise config? Or we just rely on separate files being easier for users to adjust and keep track of what/why they changed those.

Hi
I successfully migrated a custom kubernetes implementation from using cloud-config to ignition without any major headaches by converting my cloud-config configuration to their yaml based Container Linux config format and then using their transpiler tool to convert that to ignition json.  There are a few syntax differences between the legacy cloud-config and container linux yaml formats but a conversion is possible without having to re-write the config (I used sed).  It's not perfect but worth consideration.
Regarding supporting more host OSes's:-

Should we be opinionated and offer the best solution or be broad which will lead to more resistance in pushing out new benefits/features as we need to support multiple bases?
What will it give the users of kube-aws functionality wise? (if it runs docker and supports our features should it matter what the OS is)
Will it dilute effort and time supporting multiple different base OSes that perform the same functionality?

Personally, I wouldn't choose to support more than one OS because of the work that will be involved in supporting more than one option - I'd rather spend the time delivering features and the latest kubernetes versions.  I think it would be fine to change the OS if we think another one will be better than CoreOS but then we should/would need to manage a migration to it.

I had discussions with @c-knowles and @davidmccormick in Slack.
It was very contentful so I can't summarize it very well. TL;DR; direct support for alternative OSes in kube-aws won't justify the cost given there are huge cons regarding testing and user support.
If anyone was looking forward to alternative host OSes, it wouldn't happen in kube-aws itself. But I think it is still technically possible to make kube-aws flexible enough to accept k8s worker nodes provisioned with an another tool. It would support some use-cases.
Regarding migration to ignition, we seem to have two directions to achieve it. To translate coreos-flavored cloud-config to ignition config(json), or add kube-aws an alternative userdata template that renders Container Linux Config.
The former leaves us to stick with cloud-config as the primary configuration syntax even if the resulting config is ignition. The latter doesn't, but has a con that forces us to maintain two userdata templates.
However, I believe that we can alleviate the burden of maintaining two userdata templates by extracting almost all everything hard-coded in the current cloud-config templates(cloud-config- worker, cloud-config-controller, and cloud-config-etcd) into kube-aws plugins. So I'm inclined to go with the latter for now.
I'd appreciate any feedback on that too. Thank you very much for all your supports 👍

If we start to extract things into kube-aws plugins, we'd need a documentation for the plugin system. Ah, I remember that this is probably the third time I say this :)

extracting almost all everything hard-coded in the current cloud-config templates(cloud-config- worker, cloud-config-controller, and cloud-config-etcd) into kube-aws plugins

Btw this allows anyone to write an additional userdata template that renders vanilla cloud-config, which is then consumed by ubuntu or amazon linux or other host OSes. Please feel free to use kube-aws a library. I'm open to any ideas to make kube-aws flexible.

FYI: There is a ongoing work to build a successor to Container Linux.

Personally I don't see any reason for kube-aws to support more than one OS. The node OS should by design have little or not impact for the k8s user/admin. 'Sufficient yet minimal' is it prime criteria I think, which makes CoreOS, and hopefully Red Hat CoreOS, a good fit.

I'm not very happy with CoreOS. I've being fighting A LOT with bugs in the cloud-init, systemd, docker related, etc and sometimes the fix was too complex without reason. I've other clusters in GCloud and it never happened.
+1 to support other OS.

@jorge07 the Red Hat acquisition is probably good news then. Google and Red Hat have the resources and process to do a lot more pre-release testing than I expect CoreOS could. I imagine Red Hat will do a better job of heading off upstream bugs, as they do with RHEL. I'm not actually saying it must be CoreOS, rather just pick the best one for kube-aws and just support that one.


no  reduction in loss

The loss during training is not reducing. loss is constant at around  0.69 and and accuracy  at around 0.5

@amritbhaskar Hello, I have a same issue. Did you solve it?


Vertical scroll

This PR implements vertical scroll in case input doesn't fit the screen.
This is based on top of #372 (so I'll rebase this PR when that one is ready).
This PR also includes https://github.com/kkawakam/rustyline/commit/d84c03439b1f21faf43d2afbc57bf584d854e55c which unifies row/column measuring on unix and windows (because we use escape codes for colorful text on windows, and tab stops also work on windows, so it's basically the same)
The last commit also unifies what previously was "wrap_at_eol" thing. As it's not harmful to insert newlines after last column on unix terminals too. And it looks like it makes code and testing simpler.
This PR is tested on linux and windows.

I don't have access to a windows 7 (<10) desktop anymore.
If you do, could you please confirm that t are (still) correctly handled.
And I need to figure out why wrap_at_eol was removed.

* I don't have access to a windows 7 (<10) desktop anymore.
  If you do, could you please confirm that `\t` are (still) correctly handled.

I don't have too. Since windows 7 end of life has been reached on 14 January 2020, should we still be concerned about it? (and since the issue here is relatively minor).
There are threads on tab size that predate windows 10, so it probably works anyway.

* And I need to figure out why `wrap_at_eol` was removed.

We alwas in wrap_at_eol mode now. It works fine on unixes too.

We are always in wrap_at_eol mode now. It works fine on unixes too.

I mean wrap_at_eol was introduced because of a bug on Windows 10 and is ugly.
So wrap_at_eol is useless on Unix and may be removed once the bug is fixed...

I mean wrap_at_eol was introduced because of a bug on Windows 10 and is ugly.
So wrap_at_eol is useless on Unix and may be removed once the bug is fixed...

I don't think we can get rid of support of old versions of windows soon enough
It's not that easy to move that logic into tty/windows part without duplicating too much code. I can move it to some kind of if cfg(windows) if you wish, but it still complicates the logic and tests (I've started from that).

We are always in wrap_at_eol mode now. It works fine on unixes too.

I mean wrap_at_eol was introduced because of a bug on Windows 10 and is ugly.
So wrap_at_eol is useless on Unix and may be removed once the bug is fixed...

Also note: https://github.com/kkawakam/rustyline/pull/396
In the case terminal size is uninitialized, when we force inserting newlines we will get nicely formatted 80 chars column (assuming real terminal is >= 80). Otherwise the output will be a little bit messy.

We are always in wrap_at_eol mode now. It works fine on unixes too.

I mean wrap_at_eol was introduced because of a bug on Windows 10 and is ugly.
So wrap_at_eol is useless on Unix and may be removed once the bug is fixed...

Also note: #396
In the case terminal size is uninitialized, when we force inserting newlines we will get nicely formatted 80 chars column (assuming real terminal is >= 80). Otherwise the output will be a little bit messy.

But we will wrap uselessly, no ?

We are always in wrap_at_eol mode now. It works fine on unixes too.

I mean wrap_at_eol was introduced because of a bug on Windows 10 and is ugly.
So wrap_at_eol is useless on Unix and may be removed once the bug is fixed...

Also note: #396
In the case terminal size is uninitialized, when we force inserting newlines we will get nicely formatted 80 chars column (assuming real terminal is >= 80). Otherwise the output will be a little bit messy.

But we will wrap uselessly, no ?

No, in case we wrap, we'll get something like:
------------------------------ the physical terminal ends here --v
--- our imaginary 80 columns --v
prompt> xxxxxxxxxxxxxxxxxxxxxxxx                                 |
yyyyyyyyyyyyyyyy                                                 |
------ cursor --^

In case we don't wrap, rustyline will think the cursor is there on the second line, while the actual picture is this:
------------------------------ the physical terminal ends here --v
--- our imaginary 80 columns --v
prompt> xxxxxxxxxxxxxxxxxxxxxxxxyyyyyyyyyyyyyyyy                 |
-- but physically cursor is on the first line --^

So on every refresh rustyline would clean two lines and so input will gradually move towards the top of the screen.

By the way, this also help in testing. As I've recently discovered, you can  excute stty columns 80 and see how your application behaves on 80 columns. This also works better with manually wrapping at eol.

Maybe we should remember that the size cannot be trusted and wrap manually only in this case ?

Maybe we should remember that the size cannot be trusted and wrap manually only in this case ?

Yes. But this again, sounds like another branch (e.g. if stament) of code that has to be accounted for and tested. It works just as well when we always wrap. What downsides of this approach do you see? Code is simpler with always wrapping. I don't think putting a single byte per line on the wire has any noticeable performance differences even over a remote connection.

Code is simpler with always wrapping.
Code is simpler if we don't perform wrapping when terminal already handles it.

Note to myself: have to retest it on windows after rebase.


use pions/dtls of version v1.5.0

Codecov Report

Merging #57 into master will increase coverage by 0.26%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #57      +/-   ##
==========================================
+ Coverage   62.09%   62.35%   +0.26%
==========================================
  Files          30       30
  Lines        3063     3063
==========================================
+ Hits         1902     1910       +8
+ Misses        964      951      -13
- Partials      197      202       +5

Impacted Files
Coverage Δ

net/connUDP.go
57.5% <0%> (-1.67%)
:arrow_down:

net/tcplistener.go
60.52% <0%> (+2.63%)
:arrow_up:

net/udp.go
60.6% <0%> (+9.09%)
:arrow_up:

net/udp_unix.go
52.94% <0%> (+35.29%)
:arrow_up:

Continue to review full report at Codecov.

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


Support for JanusGraph 0.1.1

Awesome!

@analytically I will need to do one more as the changes to the MultiStoreWriteTest that allow me to change the load factor did not make 0.1.1. Are we gonna do another 0.1.X release or is everybody focused on 0.2.X now?


Start of adding @deprecated to generated scala resources

Addresses mbryzek/apidoc#315
Open questions:
Versioning currently unsupported, as generators do not store/track
apidoc versions. Should we add another attribute on deprecation to
support?
How to represent deprecation for a response body?
How to represent deprecation of a class in a union, but not the class
itself

Looks great, do you think it would make sense to add a second (optional) field to the Deprecation type where you can specify the from_version? You could use that as the second arg to the Scala @deprecated annotation.

That is my thought. Other languages can just use that in comments, for
example.
On Nov 7, 2016 09:42, "Gregor Heine"<EMAIL_ADDRESS>wrote:

Looks great, do you think it would make sense to add a second (optional)
field to the Deprecation type where you can specify the from_version? You
could use that as the second arg to the Scala @deprecated
https://github.com/deprecated annotation.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mbryzek/apidoc-generator/pull/106#issuecomment-258853244,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABdA81YQmyzf9xVia0_j5aLm2SLm6hNaks5q7zjggaJpZM4Kqv-v
.

lgtm - sean is this ready to merge?

awesome - deployed now


Ghost is dead as a solution! (not supported)

I don't understand the point of maintaining a project if you cannot use it!
There is no easy way for users to install ghost through npm. I used it for some time now. It was a reasonable solution until I decided to update it. Now I am busy solving problems!
Is it so complicated to maintain a solution? I am not asking too much am I?
Why in the world do you need<EMAIL_ADDRESS>(npm ERR<EMAIL_ADDRESS>install: node-pre-gyp install --fallback-to-build)
I can easily install<EMAIL_ADDRESS>is there a problem with this one?
Can someone simply remove unneeded stuff and make this relatively simple solution work?
PS: It is not about amount of commits, more about their quality!

Please read this https://ghost.org/about/guidelines before posting here again.

Now I know why there is not much going on in this repository. It seems like ErisDS is busy closing issues instead of solving the problems :-)
If you have a problem, better ask for help instead of pointing me to your "Guidelines".


feat(codec): PPT-996 Add DNS and Message codec

@grkek could you please use bindata to define these structures, it makes the protocol much easier to reason with and reduces the possibility of errors
require "bindata"

enum SessionType : UInt8
  Unicast = 0
  Group = 1
end

class MessageHeader < BinData
  endian little

  # Message flags
  bit_field do
    bits 4, :version
    bits 1, :message_flag_reserved
    bool source_node_set, value: ->{ source_node_id != 0 }
    bool destination_group_id, value: ->{ destination_group_id != 0 }
    bool destination_node_id, value: ->{ destination_node_id != 0 }
  end

  uint16 :session_id

  # Security flags
  bit_field do
    bool privacy
    bool control
    bool message_extensions, value: ->{ extensions.ext_payload.size > 0 }
    bits 3, :security_flag_reserved
    enum_bits 2, session_type : SessionType = SessionType::Unicast
  end

  uint32 :message_counter

  uint64 :source_node_id, onlyif: ->{ source_node_set }
  uint16 :destination_group_id, onlyif: ->{ destination_group_id }
  uint64 :destination_node_id, onlyif: ->{ destination_node_id }

  group :extensions, onlyif: ->{ message_extensions } do
    uint8 :ext_length, value: ->{ ext_payload.size.to_u8 }
    bytes :ext_payload, size: ->{ ext_length }
  end
end

# ...

header = io.read_bytes(MessageHeader)

I am following line by line to the implementation present in the official TypeScript repository, using BinData for this is interesting but debugging this and searching for the issues will be a lot of headache. IMO it is better to stick with line by line comparison and trust me I tried BinData and when something went wrong I got horribly lost that is why I opted to use direct no extra layer byte shenanigans.

I am happy for you to get it working using line-by-line, write a spec that passes and then convert it BinData
flags = (HEADER_VERSION << 4) | \
            (packet_header.destination_group_id.nil? ? 0 : PacketHeaderFlag::HasDestGroupId.value) | \
            (packet_header.destination_node_id.nil? ? 0 : PacketHeaderFlag::HasDestNodeId.value) | \
            (packet_header.source_node_id.nil? ? 0 : PacketHeaderFlag::HasSourceNodeId.value)

byte_format.encode(UInt8.new(flags), io)

vs
header.to_slice
# or
header.write io

that bindata took me 10min looking at the matter docs, I didn't look at your code or the typescript code to build it
but I would look at the typescript code for specs and logic


Javadoc link to array no preserved

OpenRewrite does not properly preserve Javadoc links to arrays:
/**
 * Foo {@link javax.jcr.Value[] values} bar.
 */

is incorrectly converted to
/**
 * Foo {@link javax.jcr.Valuevaluesbar. bar.
 */

when running mvn rewrite:run -Drewrite.activeRecipes=org.openrewrite.java.AddLicenseHeader_

Sorry to hear! That's a bug indeed, and annoying that it won't let you run recipes without producing such unwanted changes. Feel free to open a pull request to replicate the issue in a test, such that we can more easily pick this up when we have time.

https://github.com/openrewrite/rewrite/pull/3213

Thank you for adding a test! As also noted in https://github.com/openrewrite/rewrite/pull/3213#issuecomment-1538033667 I've merge the test already, and briefly explored what might cause this issue. It's either a problem printing the results back out, or a problem with how we parse the int[] in the code snippet (or both). Either way having the test helps to pick this up once we have time, or notify you here if it's resolved as part of other work.


Continue Plugin throws an UnsupportedOperationException while streaming response when context provided is 32.5 KB or more

Before submitting your bug report

[X] I believe this is a bug. I'll try to join the Continue Discord for questions
[X] I'm not able to find an open issue that reports the same bug
[X] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info
- OS: Windows
- Continue: 0.0.27
- IDE : IntelliJ IDEA 2023.2.4 (Community Edition)
- LLM : CodeLama

Description
Continue plugin when used with  IntelliJ IDEA ,throws an UnsupportedOperationException when the Context provided is of size 32.5 KB or more.
continue_stacktrace.txt
To reproduce
Pre-Requisites:
A LLM available to process your prompts.

Install the aforementioned Continue plugin version on IntelliJ.
Select an LLM of your choice, in this case CodeLlama-34b-Instruct-hf.
Provide a Context that is of size 32.5 KB or more. In this case a function written in Java 17.
Provide a prompt to refactor the function .

Log output
No response

@swati-git Thanks for sharing the log. I've found the problem and have a fix, but we're working on a more roundabout method of solving this and many other long-awaited updates for JetBrains, so I'm going to ship them all at once this weekend. I will share a new version as soon as I have it ready, potentially even before it gets accepted to the store if you'd like early access

I'm just getting around to looking through older issues and found that this one has been solved, so I'm going to close the issue. Please let me know if for some reason the problem is still happening!