Add Spanish translation

The match! and They don't match! lines are missing in .pot file, also I'm not really sure why Accesibility / build is failing.

Thanks!
Currently Crystal is missing the required tools to parse and use translations, therefore the They (don't) match! strings are missing for now until that's implemented.
(Action - Accessibility encountered an error, nothing to do with the PR :) )


use the url-field whenever it is available

only generate it, when it is not provided.
this closes EventFahrplan/EventFahrplan#150
I've also modified the tests because I think there is no reason that the composed url should be preferred over the original stated one.

Thank you! Merged here b14f6c36037edc9d458ae5138b3d3d9f13827767.


HDDS-11052. HttpFS fails to start when compiled for Java 17

What changes were proposed in this pull request?
HttpFS fails to start when compiled by and for Java 17:
JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 \
  ./hadoop-ozone/dev-support/checks/build.sh -Djavac.version=17

Excerpt from HttpFS log:
java.lang.IllegalArgumentException
	at jersey.repackaged.org.objectweb.asm.ClassReader.<init>(ClassReader.java:170)
	...
	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:577)
	...
	at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:774)
	...
	at org.apache.hadoop.http.HttpServer2.start(HttpServer2.java:1301)
	at org.apache.ozone.fs.http.server.HttpFSServerWebServer.start(HttpFSServerWebServer.java:153)
	at org.apache.ozone.fs.http.server.HttpFSServerWebServer.main(HttpFSServerWebServer.java:185)

Change HttpFS to use HttpServer2 from HDDS instead of Hadoop.
Migrate HttpServer2 and HttpFS to Jersey 2, which Ozone already uses in S3 Gateway.  Parts of this change are taken from https://github.com/apache/hadoop/pull/763, thanks @aajisaka, since these components were originally adapted from Hadoop.

https://issues.apache.org/jira/browse/HDDS-11052
How was this patch tested?
Compiled with and for Java 17:
https://github.com/adoroszlai/ozone/actions/runs/9741132878/job/26879699266#step:7:1
and ran HA-unsecure acceptance test, including HttpFS tests, with Java 17:
https://github.com/adoroszlai/ozone/actions/runs/9741132878/job/26880396757#step:6:1084
Regular CI:
https://github.com/adoroszlai/ozone/actions/runs/9746424125

@dombizita @fapifta would you like to take a look?

Thanks @dombizita, @smengcl for the review.


[Bug]: Error: Resolve error: Can't resolve './locale' , but it is a warning in webpack.

System Info

Details

Reproduce link
https://github.com/huhuaaa/rspack-demo.git
Reproduce Steps

cd ./projects/import-bug
pnpm install
pnpm run rspack  /  pnpm run webpack

this is a bug, rspack does not handle optional context dependency in try-catch correctly


const keyword not working on android

Hi
I am developing on linux and running app on android simulator.
when I use 'const' keyword in code the simulator goes blank, with var everything works.
when I try to debug I can see the ui displayed properly and app works normally.

I've seen this reported before. I use var. @ide Do you know if we support const? What determines if we do? Is it the version of Node or Babel we're using? I think Babel supports const?

@marek- Try adding {"whitelist": ["es6.constants"]} to .babelrc in your project root.
@mkonicek This might have quietly worked on newer iOS versions that support const but the keyword was not transformed by Babel.

:+1: Thanks for the explanation @ide!
Would it make sense to create a default .babelrc file for all new projects?

The packager should ship with good defaults. We could create an empty babelrc so people would know where to make changes, though.


how to use GitHub.search() ?

from the api docs
search() needs a string, but it needs an object?! is the docs wrong? or i am wrong?
my code :
import GitHub from 'github-api'

var gh = new GitHub();

gh.search().forRepositories({q:'react'})
.then(({data: repos}) => {
  console.log(repos)
}).catch((error) => {
  console.log('forRepositories error:', error)
})
// or
gh.search({q:'react'}).forRepositories()
.then(({data: repos}) => {
  console.log(repos)
}).catch((error) => {
  console.log('forRepositories error:', error)
})

env:
node -v
v5.1.1

npm -v
3.3.12

but nothing print out....
and there is no example for search? can i have an example for function search ?
thanks :)

sorry, i was wrong.
it worked very slow, but because of the network and search method will get all pages.


Increase coverage for adapters package

Increase unit test coverage of adapters package to 80%

Closing this issue for now as unit tests have been deprioritized for R10.


Additional checking

Additional checking to skip tests that can’t be run without the proper credentials.

This is great! If you can sign the CLA and comment for the @googlebot, I'll go ahead and merge this.

@DavidPrevot can you sign the CLA (and now also this requires a rebase) so that we can get this merged?
thanks!

can you sign the CLA

Just signed it (recorded at Dec 28, 2015 10:01 PST), sorry for the delay.

This needs a rebase, otherwise it cannot be merged.  Please do the following:
git remote add google git@github.com:google/google-api-php-client.git
git checkout tests
git rebase google/master

Resolve the merge conflicts and force-push back to this branch.

after further review, none of these tests actually require the check being suggested.


query count of vertices is wrong using DICTIONARY Index

I insert the following dataset into OrientDB (graph DB / plocal )
running the following query from the studio:
select count(*) from Person where ID >= 100

With no index on ID property:
the result will be 10 (CORRECT)
With DICTIONARY_HASH_INDEX Index on ID property:
the result will be 10 (CORRECT)
With DICTIONARY Index on ID property:
the result will be 5 (which is WRONG)

N.E:  ID is Long and name is String
@rid @version @class    ID   Name
#11:10	1	Person	100	name-000000
#11:0	1	Person	0	name-000000
#11:2	1	Person	2	name-000002
#11:3	1	Person	3	name-000003
#11:4	1	Person	4	name-000004
#11:5	1	Person	0	name-000000
#11:6	1	Person	1	name-000001
#11:7	1	Person	2	name-000002
#11:8	1	Person	3	name-000003
#11:9	1	Person	4	name-000004
#11:1	1	Person	1	name-000001
#11:11	1	Person	101	name-000001
#11:12	1	Person	102	name-000002
#11:13	1	Person	103	name-000003
#11:14	1	Person	104	name-000004
#11:15	1	Person	100	name-000000
#11:16	1	Person	101	name-000001
#11:17	1	Person	102	name-000002
#11:18	1	Person	103	name-000003
#11:19	1	Person	104	name-000004

Since DICTIONARY and DICTIONARY_HASH_INDEX  are supposed to be unique indices, seems like DICTIONARY_HASH_INDEX   is the one giving the wrong result as there are 5 unique IDs >= 100

hi @egyMaak
i'm closing this.
This is the normal behaviour
If you see here
http://orientdb.com/docs/2.1/Indexes.html#index-types
are unique but case of duplicate key  they replace the record id
So to better explain your case

Correct as it does not use the index
Correct as it does not use index since HASH index type does not support range query
Correct as it uses the DICTIONARY index and for the same key only one get indexed with the last record id

Example
#11:12 1 Person 102 name-000002
#11:17 1 Person 102 name-000002
only the latest one gets indexed


Unlock CID on Seat navi MIB2

hello. i have the problem with my Seat Navi and trying to unlock CID.Type of my software is:MST2_EU_SE_ZR_P0363T. I have installed toolbox version V1.3.3 and seems everything is ok. when i finish the complete procedure for unlocking CID i got message:mibstd2_nav_target.ni is already patched.aborting. i don't what is next step to solve this situation

i try to use new sd card with maps but i again have message that navigation database is not available

MHI2 does not have CID lock.
You have MST2 unit, and you are using MST2 Toolbox. This is different project.


Trigger Builder-Base update for Go 1.19.10 and 1.20.5

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve


Update wxWidgets

Torsion last shipped using wxWidgets v2.6.3 which is from 2006.... 10 years old.
We need to update to the latest stable release of wxWidgets:
https://www.wxwidgets.org/downloads/
While the code is now on GitHub (https://github.com/wxWidgets/wxWidgets) we probably should remove the existing code from the repository and only include headers and libs from now on.

Hi!
I just made a 1:1 copy-replace in Torsion/code directory. wxWidgets-3.1.0 dir is renamed to wxWidgets.
Now I can the UpdateBuildNumber program rebuild ( with some modification).

Following this old guide:
http://wxwidgets.blogspot.com/2012/08/how-to-use-294-wxmsw-binaries.html
If you got a newer one let me know :)

Givin up... When I correct an error 200 rises up... This is  indeed a lost cause... The whole program should be rebuilt upon the newer version and I alone cannot afford to rebuild the whole program alone in my spare time ... I see also that there is not any more interest nor help by anyone so ... I think that this project is dead and will remain so.. Sorry

Ok ok , I have a pull request about this, I need help on linker erros, please read pull request notes


add support for go workspaces

Add a go.work file listing all modules in this monorepo and remove local replace directives from all go.mod files
Fixes #400
Signed-off-by: Sanskar Jaiswal<EMAIL_ADDRESS>

I've done some testing with this, and having a single workspace makes all packages share the same dep , which is bad...  also this PR contains un-synced  deps, @aryan9600 have you've run go work sync?

Closing this as it does not seem a viable solution for now (and it has been stale for a long time).


Using TCK Tested JDK builds of OpenJDK

The AdoptOpenJDK has been discontinued since July 2021 (https://adoptopenjdk.net). Switching the distribution to Azul Zulu. When using Zulu you get all the latest updated (TCK Tested) builds for all versions of OpenJDK.
Also added are fixed (major) release version(s) such as JDK 11.0.3. This is often a good practice whenever a build/test triggers (push/pull events) to help determine if the latest (JDK 11) had failed the from the latest build vs something in your code caused (or introduced).
For example, when building with JDK 11.0.3 (fixed version) the build/tests passes (Green) and JDK 11 fails (Red) will mean that the latest JDK 11 was the cause and not your code.
Note: Other distributions such as Temurin do not support archived fixed releases prior to Sept. 2021 and many non LTS (long term support) releases if you plan to try out newer features in the language.

Full disclosure, I work for Azul and here are my opinions:
Paid support
I believe both are fine (both distros are derived from OpenJDK and TCK tested), the only real difference is AWS customers using Corretto may later want Amazon paid support  for apps running in production environments from scaling, tuning, monitoring services, etc. Zulu is also free and if a customer or ISV(independent software vendor) later want paid support they’d choose Azul.
As mentioned earlier about build distro differences:
Corretto doesn’t support every OpenJDK version (non-LTS or fixed versions). Azul Zulu does🙂.
Zulu offers Java 7-18ea (latest) and archived versions (fixed major releases).
Repo owner’s perspective:
As a project/repo that is a library or framework it is a good idea to stick with a JDK distribution such as Zulu because it’s free, up to date, TCK tested (unlike AdoptOpenJDK), consistent track record & has every version of OpenJDK.
Originally GitHub action setup-java@v1 only used zulu as a distro. With v2 it’s now a requirement to choose a distro. That’s when lots of builds broke or weren’t getting the latest (patched) builds. The GH Action template continues to have adopt.
I hope that makes sense.
-Carl

👍

Thank you. Glad to help contribute!


Fixed #29444 -- Allowed returning multiple fields from INSERT statements on Oracle.

@felixxm this is that bit fixed can_return_multiple_columns_from_insert for Oracle.

buildbot, test on oracle.

buildbot, test on oracle.

Test failure is not related with this PR.

@codingjoe Thanks!


use client directive must be placed before other expressions

Using latest next 13.4.1-canary.0 and latest swc-plugin-coverage-instrument 0.0.18 and when running next dev get the following error
The "use client" directive must be placed before other expressions. Move it to the top of the file to resolve this issue.

   ,-[/nextjs-app-repro/node_modules/.pnpm/next@13.4.1-canary.0_@babel+core@7.20.7_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/client/script.js:1:1]
 1 | "use client";
   : ^^^^^^^^^^^^^
 2 | "use strict";
 3 | Object.defineProperty(exports, "__esModule", {
 4 |     value: true
   `----

The error was caused by importing 'next/dist/client/next-dev.js' in 'undefined'.

Here is a minimal repro https://github.com/hect1c/nextjs-app-repro install dependencies and run dev. When I remove the swc plugin it runs fine but when I add it then the issue appears.
Oddly enough this happens in another project using same latest version but I don't use the App directory and am using pages and thus not utilizing any of the RSC features.

Plugin may able to do this by their own, but in my opinion this should be handled in upstream swc itself.
https://github.com/swc-project/swc/issues/7315

We are still seeing this issue, or it's potentially cropped up again with current version of Next.JS. Our team is just getting familiar with Next.js as we are migrating some projects from CRA and have run into this issue while getting our coverage setup working with CypressJS.
swc-plugin-coverage-instrument version: 0.0.24
Next.js Version: 14.2.7
Cypress.js: 13.13.3


KeyError when generating CDs collaborative indexing method dataset

Hi,
I got the following error when generating the CDs collaborative indexing method dataset using
sh generate_dataset_1.sh

Error:
Traceback (most recent call last):
File "/usr/local/google/home/lyliyang/OpenP5/./src/src_llama/generate_dataset.py", line 133, in
main(args)
File "/usr/local/google/home/lyliyang/OpenP5/./src/src_llama/generate_dataset.py", line 36, in main
reindex_user_seq_dict, item_map = indexing.collaborative_indexing(args.data_path, args.dataset, user_sequence_dict,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/google/home/lyliyang/OpenP5/src/src_llama/utils/indexing.py", line 145, in collaborative_indexing
reindex_user_sequence_dict = reindex(user_sequence_dict, user_map, item_map)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/google/home/lyliyang/OpenP5/src/src_llama/utils/indexing.py", line 319, in reindex
reindex_user_sequence_dict[uid] = [item_map[i] for i in items]

Hello, could you provide more details? I tried running the code with provided data but didn't encounter the same error.

It looks like it maybe due to some data corruption issue, I re-downloaded the CDs data, and now there is no error now.
Thanks!


don't return early for empty string

Cheerio results often return empty strings when no matches occur, so it seems best to not match on that instead and keep going down the fallbacks array

Fixed in 0.2.0


Ianoc/move to scala test211

Killing all unused targets to make my life easier and then updating everything else

So, what was the pain in keeping the summingbird-java and spark?
This is quite a big diff with a lot going on. For instance, the sbt script update could have been done independently, also, I think the version updates. Is there any way we could break this into 3-4 PRs? It looks like you have most of the diffs as idependent changes above.

They are unused with questionable if its worth any effort what-so-ever to keep alive. We've deleted all references to summingbird-java internally so twitter at least doesn't even use this code at all. No one has ever used summingbird-spark.
Can split it into multiple PR's tho

LGTM


support heroes self healing inaccuracies

Created by: MaxwellJung
Currently, Zenyatta, Mercy, and Brig are excluded from the remove passive rule. However, this isn't completely accurate since all three heroes seem to be healing more than they should.

Resolved using array based self healing rule


Upgrading from nMigen and cannot get amaranth-boards installed

I have a little project I'm trying to get up-to-date and I've run into a weird issue. This repo is very clearly full of board definitions including the one I was using with nMigen, but when I try to install it with pip in my virtualenv, I get... nothing?
(venv) $ pip install amaranth-boards
Collecting amaranth-boards
  Downloading amaranth_boards-0-py3-none-any.whl (1.1 kB)
Installing collected packages: amaranth-boards
Successfully installed amaranth-boards-0

(venv) $ ls venv/lib/python3.9/site-packages/
total 4
drwxr-xr-x  5 me staff  160 Nov 26 17:04 _distutils_hack
drwxr-xr-x 20 me staff  640 Nov 26 17:11 amaranth
drwxr-xr-x  7 me staff  224 Nov 26 17:11 amaranth_yosys
drwxr-xr-x 30 me staff  960 Nov 26 17:11 jinja2
...
drwxr-xr-x  8 me staff  256 Nov 26 17:35 amaranth_boards-0.dist-info
...

There is a amaranth_boards-0.dist-info directory in site-packages but there is no amaranth_boards directory.
Am I missing something? I know this section of the docs is still a TODO: https://amaranth-lang.org/docs/amaranth/latest/install.html#installing-board-definitions so I don't know what else I'm missing here.

I was able to get it manually installed from the git repo:
pip install git+https://github.com/amaranth-lang/amaranth-boards.git#egg=amaranth-boards

but idk if that's what I'm supposed to do.

Yup, at the moment this is appropriate. Releasing amaranth-boards is tracked at #128.


Fixed ParallelDQNAgent and added dqn_example.py

This should work as specified in the issue.
Tested on python 3.6 win10 64bit
Fixes #164

dqn_example.py raises IndexError: list index out of range.
I know that cryptodatadownload returns timestamp instead of date now but I get this.
Any clue how to fix it?
Traceback (most recent call last):
  File "./dqn_example.py", line 105, in <module>
    env = create_env()
  File "./dqn_example.py", line 65, in create_env
    window_size=20
  File "c:\temp\RL\tensortrade_bbrundev\tensortrade\environments\trading_environment.py", line 114, in __init__
    self.compile()
  File "c:\temp\RL\tensortrade_bbrundev\tensortrade\environments\trading_environment.py", line 152, in compile
    initial_obs = self.feed.next()
  File "c:\temp\RL\tensortrade_bbrundev\tensortrade\data\stream\feed.py", line 91, in next
    self.run()
  File "c:\temp\RL\tensortrade_bbrundev\tensortrade\data\stream\feed.py", line 83, in run
    node.run()
  File "c:\temp\RL\tensortrade_bbrundev\tensortrade\data\stream\node.py", line 100, in run
    self.value = self.forward()
  File "c:\temp\RL\tensortrade_bbrundev\tensortrade\data\stream\node.py", line 458, in forward
    self._node = list(filter(self.selector, self.inputs))[0]
IndexError: list index out of range


Nuxt3 Tailwind Viewer don't work

nuxt3  use "@nuxtjs/tailwindcss": "^5.0.2"
Tailwind Viewer don't work
Canvas.vue:120          GET http://localhost:3000/_tailwind/config.json 404 (Not Found)

I'm facing the same issue

It works on my end, do you have a reproduction?

It works on my end, do you have a reproduction?

https://codesandbox.io/s/smoosh-moon-oloppv
Navigate to https://oloppv.sse.codesandbox.io/_tailwind/
See network tab

On fresh install
[Vue Router warn]: No match found for location with path "/_tailwind/" [Vue Router warn]: No match found for location with path "/_tailwind/" [Vue Router warn]: No match found for location with path "/_tailwind/" [Vue Router warn]: No match found for location with path "/_tailwind/" [Vue Router warn]: No match found for location with path "/_tailwind/css/app.aac7915f.css" [Vue Router warn]: No match found for location with path "/_tailwind/css/app.aac7915f.css" [Vue Router warn]: No match found for location with path "/_tailwind/css/app.aac7915f.css" [Vue Router warn]: No match found for location with path "/_tailwind/css/app.aac7915f.css" [Vue Router warn]: No match found for location with path "/_tailwind/js/app.eb7ca967.js" [Vue Router warn]: No match found for location with path "/_tailwind/js/app.eb7ca967.js" [Vue Router warn]: No match found for location with path "/_tailwind/js/app.eb7ca967.js" [Vue Router warn]: No match found for location with path "/_tailwind/js/app.eb7ca967.js" [Vue Router warn]: No match found for location with path "/_tailwind/js/chunk-vendors.d4b2e20c.js" [Vue Router warn]: No match found for location with path "/_tailwind/js/chunk-vendors.d4b2e20c.js" [Vue Router warn]: No match found for location with path "/_tailwind/js/chunk-vendors.d4b2e20c.js" [Vue Router warn]: No match found for location with path "/_tailwind/js/chunk-vendors.d4b2e20c.js" [Vue Router warn]: No match found for location with path "/_tailwind/js/chunk-vendors.d4b2e20c.js.map" [Vue Router warn]: No match found for location with path "/_tailwind/js/chunk-vendors.d4b2e20c.js.map" [Vue Router warn]: No match found for location with path "/_tailwind/js/chunk-vendors.d4b2e20c.js.map" [Vue Router warn]: No match found for location with path "/_tailwind/js/chunk-vendors.d4b2e20c.js.map" [Vue Router warn]: No match found for location with path "/_tailwind/config.json" [Vue Router warn]: No match found for location with path "/_tailwind/config.json" [Vue Router warn]: No match found for location with path "/_tailwind/js/app.eb7ca967.js.map" [Vue Router warn]: No match found for location with path "/_tailwind/js/app.eb7ca967.js.map" [Vue Router warn]: No match found for location with path "/_tailwind/js/app.eb7ca967.js.map" [Vue Router warn]: No match found for location with path "/_tailwind/js/app.eb7ca967.js.map" [Vue Router warn]: No match found for location with path "/_tailwind/favicon.ico" [Vue Router warn]: No match found for location with path "/_tailwind/favicon.ico" [Vue Router warn]: No match found for location with path "/_tailwind/favicon.ico" [Vue Router warn]: No match found for location with path "/_tailwind/favicon.ico"

Same for me on the fresh Nuxt v3.0.0-rc1 app.
No match found for location with path... and the errors in console.

There is a problem in here, the viewer isn't working with Nuxt v3.0.0-rc1

I'm getting the same errors..

If you run tailwind viewer with this command:
npx tailwind-config-viewer
It will work but It will take over the http://localhost:3000 port

Same error here, on fresh install.

Same here

Same here, can't open /_tailwind
/_tailwind/...css 404 not found
maybe config.json not found
sometime only show github logo,
somtime only show toggle switch for darkmode
sometime white screen

Any updates on this?

There's a pull request for it

There's a pull request for it

Could you please link it here?

NVM i've seen it #460

Great that there's a fix for this :) Any estimates for when this will be merged?

I just tried to install tailwind with nuxt3 but the viewer did not work and out of the box no config was loaded etc. So it does not seem to work with nuxt3 without manual installation. The documentation is also still showing videos with nuxt2 ...

Issue has been fixed here issue Just we wait for merge it and then, redownload files

Issue has been fixed with the versión 1.7.1 for tailwind-config-viewer
It has been merged and publish 3 days ago.
https://github.com/rogden/tailwind-config-viewer/pull/58#issuecomment-1142127655
We need open a new PR for nuxt with the new version package.
If you need to know what version of tailwind-config-view you have, you must run the next command.
yarn list | grep tailwind-config-viewer in my case: I have 1.7.0

404 again on http://localhost:3000/_tailwind/
"nuxt": "3.0.0-rc.8",
"@nuxtjs/tailwindcss": "^5.3.2",

Same here.
"nuxt": "3.0.0-rc.8",
"@nuxtjs/tailwindcss": "^5.3.2",
"tailwindcss": "^3.1.8"

I was able to make this work with this config.
// nuxt.config.ts
export default defineNuxtConfig({
    css: ['~/assets/css/tailwind.css'],
    build: {
        postcss: {
            postcssOptions: {
                plugins: {
                    tailwindcss: {},
                    autoprefixer: {},
                },
            },
        },
    },
    modules: [
        '@nuxtjs/tailwindcss'
    ]
})

And in my app.vue
<script lang="ts" setup>
    import './assets/css/tailwind.css'
</script>

But my extended color is not being read by tailwind viewer:

At this point I can ditch out @nuxtjs/tailwindcss and have minimal config in nuxt.config.ts:
export default defineNuxtConfig({
    build: {
        postcss: {
            postcssOptions: {
                plugins: {
                    tailwindcss: {},
                    autoprefixer: {},
                },
            },
        },
    },
})

While still keeping the import './assets/css/tailwind.css' in app.vue.

Looks like a version bump broke it. 1.7.2 fails, but 1.71 works. per @DesKevinMendez
$ npm install --save-dev<EMAIL_ADDRESS>

Same here, I'm getting this warns when tryinto to access http:localhost:3000/_tailwind
This path works, and displays all tailwind viewer data, but the warn is annoying.

This problem persists in the latest version of nuxt 3 and tailwind module. Please open this again.

This problem persists in the latest version of nuxt 3 and tailwind module. Please open this again.

Do you have ssr: false? If yes, it could be #651, and if no, could you provide a reproduction please?

I have same issue with fresh install.  Just shows a blank page, no viewer
`Nuxt 3.7.0 with Nitro 2.6.2                                                                                10:57:54 AM
10:57:54 AM
➜ Local:    http://localhost:3000/
➜ Network:  use --host to expose
ℹ Using Tailwind CSS from ~/assets/css/tailwind.css                                                                 nuxt:tailwindcss 10:57:54 AM
✔ Nuxt DevTools is enabled v0.8.2 (experimental)                                                                                10:57:55 AM
ℹ Tailwind Viewer: http://localhost:3000/_tailwind/                                                                 nuxt:tailwindcss 10:57:55 AM
WARN  [@vue/compiler-sfc] defineProps is a compiler macro and no longer needs to be imported.                                        10:57:55 AM
WARN                                                                                10:57:56 AM
[10:57:56 AM]  WARN  warn - No utility classes were detected in your source files. If this is unexpected, double-check the content option in your Tailwind CSS configuration.
WARN  warn - https://tailwindcss.com/docs/content-configuration                                                                      10:57:56 AM
ℹ Vite client warmed up in 611ms                                                                                10:57:56 AM
✔ Nitro built in 291 ms                                                                                nitro 10:57:56 AM
ℹ Restarting nuxt...                                                                                10:58:33 AM
ℹ Using Tailwind CSS from ~/assets/css/tailwind.css                                                                 nuxt:tailwindcss 10:58:33 AM
✔ Nuxt DevTools is enabled v0.8.2 (experimental)                                                                                10:58:33 AM
ℹ Tailwind Viewer: http://localhost:3000/_tailwind/                                                                 nuxt:tailwindcss 10:58:33 AM
ℹ Vite client warmed up in 395ms                                                                                10:58:34 AM
✔ Nitro built in 216 ms                                                                                nitro 10:58:34 AM
[Vue Router warn]: No match found for location with path "/_tailwind"
[Vue Router warn]: No match found for location with path "/_tailwind"
[Vue Router warn]: No match found for location with path "/css/app.aac7915f.css"
[Vue Router warn]: No match found for location with path "/css/app.aac7915f.css"
[Vue Router warn]: No match found for location with path "/js/app.487587de.js"
[Vue Router warn]: No match found for location with path "/js/app.487587de.js"
[Vue Router warn]: No match found for location with path "/js/chunk-vendors.d4b2e20c.js"
[Vue Router warn]: No match found for location with path "/js/chunk-vendors.d4b2e20c.js"
[Vue Router warn]: No match found for location with path "/_tailwind"
[Vue Router warn]: No match found for location with path "/_tailwind"
[Vue Router warn]: No match found for location with path "/css/app.aac7915f.css"
[Vue Router warn]: No match found for location with path "/css/app.aac7915f.css"
[Vue Router warn]: No match found for location with path "/js/app.487587de.js"
[Vue Router warn]: No match found for location with path "/js/app.487587de.js"
[Vue Router warn]: No match found for location with path "/js/chunk-vendors.d4b2e20c.js"
[Vue Router warn]: No match found for location with path "/js/chunk-vendors.d4b2e20c.js"
[Vue Router warn]: No match found for location with path "/_tailwind"
[Vue Router warn]: No match found for location with path "/_tailwind"
[Vue Router warn]: No match found for location with path "/_tailwind"
[Vue Router warn]: No match found for location with path "/_tailwind"`

@rob-kristie-mach Did you actually open /_tailwind or /_tailwind/? There's been a weird bug for a while where if you don't add that trailing slash, it's just gonna show a blank page

I'm facing the same issue
"@nuxtjs/tailwindcss": "^6.8.0",

Same issue with latest packages
  "dependencies": {
    "@pinia/nuxt": "^0.5.1",
    "@vueuse/nuxt": "^10.5.0"
  },
  "devDependencies": {
    "@nuxt/devtools": "latest",
    "@nuxtjs/tailwindcss": "^6.8.0",
    "@pinia-plugin-persistedstate/nuxt": "^1.1.2",
    "nuxt": "^3.8.0",
    "vue": "^3.3.6",
    "vue-router": "^4.2.5"
  }

Same issue with latest packages
  "dependencies": {
    "@pinia/nuxt": "^0.5.1",
    "@vueuse/nuxt": "^10.5.0"
  },
  "devDependencies": {
    "@nuxt/devtools": "latest",
    "@nuxtjs/tailwindcss": "^6.8.0",
    "@pinia-plugin-persistedstate/nuxt": "^1.1.2",
    "nuxt": "^3.8.0",
    "vue": "^3.3.6",
    "vue-router": "^4.2.5"
  }

"devDependencies": {
"@nuxt/devtools": "latest",
"@nuxtjs/color-mode": "^3.3.0",
"@nuxtjs/tailwindcss": "^6.8.0",
"@pinia-plugin-persistedstate/nuxt": "^1.1.2",
"@pinia/nuxt": "^0.5.1",
"nuxt": "^3.8.0",
"sass": "^1.69.4",
"vue": "^3.3.6",
"vue-router": "^4.2.5"
}
I have the same setup and it is working for me .... ¯_(ツ)_/¯ what is your OS?

Same issue on a fresh install

  "devDependencies": {
    "@nuxt/devtools": "^1.0.0",
    "@nuxtjs/tailwindcss": "^6.9.4",
    "nuxt": "^3.8.0",
    "vue": "^3.3.7",
    "vue-router": "^4.2.5"
  }

The viewer works fine when launched from http://localhost:3000/_tailwind/ but it won't work in the devtool itself
@Atinux could it be an issue with the devtool ?
Btw I'm using WSL in case that changes anything

Same issue on a fresh install

  "devDependencies": {
    "@nuxt/devtools": "^1.0.0",
    "@nuxtjs/tailwindcss": "^6.9.4",
    "nuxt": "^3.8.0",
    "vue": "^3.3.7",
    "vue-router": "^4.2.5"
  }

The viewer works fine when launched from http://localhost:3000/_tailwind/ but it won't work in the devtool itself
could it be an issue with the devtool ?
I created a reproduction on stackblitz to make sure it wasn't coming from WSL or my setup
https://stackblitz.com/edit/nuxt-starter-jwoekj?file=nuxt.config.ts

You navigated to /modules/_tailwind. Please go to /_tailwind and it should work.

Can I please get a confirmation if this is only happening in ssr: false? (thumbs up or down)

@ineshbose I don't get to choose what I navigate to within the devtool.
I just click on the tailwind viewer button and that's what I'm redirected to.
Feel free to have a look at the stackblitz I shared and tell me if you see anything I've done wrong in nuxt.config.ts

@fabis94 Solution above worked for me -- you NEED the trailing slash.   This was on a fresh install.

I'm able to see the issues with the viewer..

You need a trailing slash, but it shouldn't be (we put the redirect in the middleware)
When you do have the trailing slash, tailwind-config-viewer gets 404 while fetching /_tailwind/config.json
(I'm still investigating what happens in ssr: false)

Please lets continue discussing this issue in #561


Get 'from' from envelope

This would fix #318 by checking for a 'from' in envelope before returning MissingFrom. It also adds the found 'from' to the message headers. The latter might be undesired behavior; I'm not sure. If this is undesired, it is easy to fix.
Also added two test cases to show that 1) Building with 'from' only in the envelope works, and 2) Building without a 'from', either in the envelope or otherwise, still fails.

Codecov Report

Merging #320 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #320   +/-   ##
=======================================
  Coverage   90.68%   90.68%
=======================================
  Files           8        8
  Lines         794      794
=======================================
  Hits          720      720
  Misses         74       74

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 c988b17...058fa69. Read the comment docs.


Liberating pair programming research from the oppressive Driver/Observer regime

http://dl.acm.org/citation.cfm?id=2486962

No data


Strategy: simple trailing stopp loss

I'm missing a very simple but basic strategy: a trailing stopp loss
What the strategy should to:
monitor the selected market, and as soon as the price drops below (the highest price since starting the bot - defined %) all or a defined percentage of my coins will be sold.
For example:
Sell 100% at -10%
in my account I have 100 NEO
Current price is: 0.010000 btc
current stopp loss is: (0.010000 - 10%) 0.009
if price drops below  0.009 > sell ; end
if price goes up to 200 > new stopp loss is: (200 - 10%) 180
if then price goes back to 150 > all coins will be sold at 180; end     :-)
so if I set this up for all my trades (that i started manually) I have a max loss of 10% but endless up side, as long as the coin keeps mooning and never dips more than 10 %

sounds like a nice idea. when does gekko should make a new "buy in"?


fix(docs): ReadTheDocs flyout menu and more

Closing as fixed by https://github.com/readthedocs/readthedocs.org/issues/11136


Kcl argocd zombie workaround

1. Does this PR affect any open issues?(Y/N) and add issue references (e.g. "fix #123", "re #123".):

[ ] N
[X] Y

Fix: https://github.com/kcl-lang/kcl-lang.io/issues/350
2. What is the scope of this PR (e.g. component or file name):
Add new docker image for kcl-cmp argocd plugin with tini util.
3. Provide a description of the PR(e.g. more details, effects, motivations or doc link):

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[X] Other

4. Are there any breaking changes?(Y/N) and describe the breaking changes(e.g. more details, motivations or doc link):

[X] N
[ ] Y

5. Are there test cases for these changes?(Y/N) select and add more details, references or doc links:

[ ] Unit test
[ ] Integration test
[ ] Benchmark (add benchmark stats below)
[X] Manual test (add detailed scripts or steps below)
[ ] Other

The steps to test are described here https://github.com/kcl-lang/kcl-lang.io/issues/350

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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 71.44%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
52748

Relevant Lines:
73835

💛  - Coveralls


Support 'patient unhoused' in patient bulk upload

Why should we do this?

A new checkbox was added to the frontend user experience for the Patient Profile to denote "Address unknown" or "patient unhoused"
We want to achieve feature parity for the Patient Profile frontend user experience and the fields in the Patient Bulk Upload.

User story

As a SimpleReport user uploading CSV files using the Patient Bulk Upload feature I want to have the same fields available on the CSV as are available on the Patient Profile so that I can denote "Address unknown" or "patient unhoused."

Action Requested

Enable the user to include the same information on the Patient Bulk Upload CSV file for "Address unknown or patient unhoused" as is available on the frontend.
update patient bulk upload guide to indicate that if address unknown set the following fields and to either set all of them or provide valid actual values for all of them (all or nothing)

state = "NA"
zip = "00000"
street = "** Unknown / Not Given **"

update patient bulk upload guide validation to allow the unknown values only if they're all unknown. otherwise require valid values
error for incomplete unknown address can be same error as any other kind of invalid address

Acceptance Criteria

user can set state, zip, street to unknown if patient is unhoused
bulk patient upload validation will throw an error and not persist patient unless it's all or nothing (all 3 values are unknown or all 3 values are valid)
bulk upload guide is updated with guidance on how to indicate that a patient is unhoused

Additional Context

Screenshot of the Patient Profile screen frontend user experience is attached.
This functionality can be viewed on the training site by viewing the Patient Profile screen [Example]

Jayna to reach out to @lauraykerr about copy for bulk upload guide copy

@emyl3 Here's some copy for the three fields, all in the format column (you can see it in the static site Google doc if that's helpful):
Street

500 characters or fewer.
If address is unknown or patient is unhoused, write ** Unknown / not given ** in this field.

State

Any 2-character state or US/Canada territory code.
If address is unknown or patient is unhoused, write NA in this field.

Zip

Use format 00000 or 00000-0000.
If address is unknown or patient is unhoused, write 00000 in this field.

Note: The ticket says Unknown / Not Given for the street field, but would prefer to stay sentence case like the other field values (e.g. Not applicable) if it's not case sensitive.


DropdownV2 - itemToElement not taken into account when selectedItem is used

I would like to have icon next to selected dropdown option and next to list options.
DropdownV2 has itemToElement prop to allow this:

Unfortunately this prop is not taken into account for selected dropdown item (selectedItem prop), itemToString is used there:
.
Result looks like below, there is a missing icon next to selected value (itemToString using only label value):

Currently this is blocking issue for SPSS Statistics, so I'm asking for quick fix.

@joshblack Example in sandbox https://5zxm9yp4nx.codesandbox.io/
I've used just paths instead of icons

Hi! I have kind of the same issue, I need a label next to the selectedItem as well as for the displayed ItemToElement list.
I solved this issue creating this function:
const itemToElement = ({ text, label }) => (
  <h5>
    { text }
    <Label className="dropdown-label">
      { label }
    </Label>
  </h5>
)

And using the Dropdown like this:
      <Dropdown
        initialSelectedItem={items[0]}
        label={itemToElement(items[0])}
        tabIndex={-1}
        ariaLabel="dropdown menu label"
        items={items}
        itemToString={itemToElement}
        itemToElement={itemToElement}
      />

Basically I'm using the same function in itemToString and itemToElement, but I'm getting the following warning in React:
Warning: Encountered two children with the same key, '[object Object]'. Keys should be unique so that components maintain their identity across updates.
Which I guess make sense due to the way the list is being mapped ?:
<ListBox.Menu>
                  {items.map((item, index) => (
                    <ListBox.MenuItem
                      **key={itemToString(item)**}
                      isActive={selectedItem === item}
                      isHighlighted={
                        highlightedIndex === index || selectedItem === item
                      }
                      {...getItemProps({ item, index })}>
                      {itemToElement ? (
                        <**ItemToElement key={itemToString(item)}** {...item} />
                      ) : (
                        itemToString(item)
                      )}
                    </ListBox.MenuItem>
                  ))}
                </ListBox.Menu>

Thank you very much!

Seems like a bug in the library: <ListBox.MenuItem /> requires a key because it's in a list with sibling elements being returned from items.map. The child of each <ListBox.MenuItem /> does not require a key though, because it has no siblings – I think that's the cause of the "duplicate key" warning


TypeError: value.split is not a function

I have 2 files that I'm trying to read and get the diff:
cNew = './htmlLog/clog'
oldhtmlPlus ='./htmlLog/log'
contentOld = fs.readFileSync(oldhtmlPlus)
contentNew = fs.readFileSync(cNew)
diff = jsdiff.diffTrimmedLines(contentOld, contentNew)
However I keep getting the error TypeError: value.split is not a function?

contentOld and contentNew are Buffers. You need to toString them or pass an
encoding to the read functions to ensure that they are a string.
On Thu, Jun 16, 2016 at 3:39 PM Nibor808<EMAIL_ADDRESS>wrote:

I have 2 files that I'm trying to read and get the diff:
cNew = './htmlLog/clog'
oldhtmlPlus ='./htmlLog/log'
contentOld = fs.readFileSync(oldhtmlPlus)
contentNew = fs.readFileSync(cNew)
diff = jsdiff.diffTrimmedLines(contentOld, contentNew)
However I keep getting the error TypeError: value.split is not a function?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kpdecker/jsdiff/issues/122, or mute the thread
https://github.com/notifications/unsubscribe/AAL_JtYbpuiuDMa8q-bXTUfXGeZsWV9lks5qMbRkgaJpZM4I3yW-
.

That got it thank you.


Is there a plan to support coc.nvim?

@cstsunfu in the mean time you can use https://github.com/matze/beancount-language-server. I got it working with nvim-lspconfig so I guess it would be easy to integrate it with coc.nvim.


Vertical scroll of table content

How to add a vertical scroll to a table content by keeping columns header and table footer intact? I was able to put a div around table with overflow-y but this scrolls the whole table and navigation to header/footer becomes unusable.

Looks like 'fixedHeader' option solves the issue.

set responsive: scroll  plugin option and add style .MUIDataTable-responsiveScroll { max-height: auto;}

As of V2.10.0 it is now possible to use the prop responsive="scrollFullHeight" to make the table full height and a scroll behavior at the same time. That should fix the issue.
See https://github.com/gregnb/mui-datatables/pull/867


Remove record_header_indices split loop for ARM

A rustc/LLVM bug was preventing compilation on ARMv7, due to some legal Rust code in proto::h1::role::record_header_indices. A workaround splitting the loop into 2 loops was added in https://github.com/hyperium/hyper/pull/1671.
The bug in rustc is tracked here: https://github.com/rust-lang/rust/issues/55105. Once it is fixed (and available on stable), this workaround should be removed.

I'd prefer to remove this soon-ish, though it seems there's been no progress on the upstream bug. Either others who need it can chime in there, or I'll assume the need is no longer there.


WAL: Wallet implementation

Implementation of the Wallet for neo-sharp  currently @lock9 is working on this.

@lock9 I'll leave you to split this issue into the appropriate issues.  in the meantime, I'll close this.


[WIP][SPARK-33574][CORE] Improve locality for push-based shuffle especially for join-like operations

What changes were proposed in this pull request?

Reuse merger locations in the case where multiple stages output is consumed by a single stage (e.g.: Joins).
Why are the changes needed?

For sibling shuffle map stages, i.e. ones that share common child stages, reusing merger locations between them can help to further increase shuffle locality ratio when push based shuffle is enabled. Examples include Joins where the reduce stage needs to fetch shuffle data from multiple parent shuffle map stages.
Does this PR introduce any user-facing change?

Yes. This PR introduces a client-side config for push-based shuffle spark.shuffle.push.reuse.merger.locations. If push-based shuffle is turned-off then users will not see any change.
How was this patch tested?

Passed the added UTs.

Can one of the admins verify this patch?

@Victsm @mridulm @otterc @venkata91 @zhouyejoe @Ngone51 Please take a look

Also @akpatnam25

Let us also add a test case to validate that a SQL query, with AQE on, does benefit from this optimization when there are joins.

Is this still WIP @rmcyang ?
Also, can you please add tests for the sql aqe codepath ? Essentially will this optimization help sql join when AQE is enabled.

Is this still WIP @rmcyang ? Also, can you please add tests for the sql aqe codepath ? Essentially will this optimization help sql join when AQE is enabled.

Did some tests in out internal branch, merger locations could be reused as expected with AQE disabled; however, every sibling stage could unfortunately use a different set of merger locations when AQE enabled. When findCoPartitionedSiblingMapStages got called with AQE enabled, the shuffle map stage is not able to figure out its sibling map stages, which to me is caused by every shuffle map stage now becomes a job and thus the DAG got sliced into many parts. Thus this improvement is now only valid when AQE disabled.
@mridulm, any thoughts on whether we should figure out a better mechanism to track the sibling stages info, in order to take advantage of this improvement, when AQE is enabled?

Let us try to figure a way for this PR to work with AQE enabled. That is the default in spark right now, and if the feature does not work with AQE, it is not going to be useful for most spark applications.


Option to resize only bottom right corner

Description
Flag to act like resizing is always clicked on the bottom right corner would be very helpful.  Helps reduce mouse movement a lot & associated strain.  E.g., if you mod+right-click the top left corner, it'll just start resizing at the bottom right.

Me investigating the same issue 7 months later :(

https://github.com/hyprwm/Hyprland/issues/4440

A configuration option could be injected here:
https://github.com/hyprwm/Hyprland/blob/6c53d4d82fd81aaa8aeb8c89ece1b88455a1f2a1/src/layout/IHyprLayout.cpp#L220
to just always enforce m_eGrabbedCorner = CORNER_BOTTOMRIGHT (or an arbitrary corner).  Would someone be so kind as to add that.

feel free to make a mr

https://github.com/hyprwm/Hyprland/pull/5090

Booyah achieved


File's classification exists on the device's cache prior to the allow or block action

Can you clarify what is meant with:
"The allow or block function cannot be done on files if the file's classification exists on the device's cache prior to the allow or block action" in the important section.
As far as I understand from the sentence is, that if a file already run on a system it can not be blocked in the future via indicators. So only system, where the file has never run before, are protected.
Also important for investigation:
Which cache is meant here? Can the cache be cleared? How do i know that the file is already in the cache?

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

ID: 50f2be10-41a0-67ae-222b-1b073bef537b
Version Independent ID: 3f186b13-aad0-4ba4-e239-d9bb24ff2ebe
Content: Manage indicators - Windows security
Content Source: windows/security/threat-protection/microsoft-defender-atp/manage-indicators.md
Product: w10
Technology: windows
GitHub Login: @mjcaparas
Microsoft Alias: macapara

@muellni6 I think your understanding is correct. If Windows Defender malware engine already classified a file as malicious/safe you won't be able to use the allow or block function of the indicator.
My understanding is that the device cache refers to Windows Defender Cache. You have a few options here to check it / clear it:

Task Scheduler (Local) - Task Scheduler Library - Microsoft - Windows - Windows Defender -> you will see some relevant tasks:

Windows Defender Cache Maintenance -> running this will clear the Cache.
Windows Defender Cleanup
Windows Defender Verification

If you look under the Actions tab, you will see that it runs cmdlet based on mpcmdrun.exe -> more details here
If you want to check what's in the Cache, you could have a look under:
"C:\ProgramData\Microsoft\Windows Defender\Scans\History"
"C:\ProgramData\Microsoft\Windows Defender\Scans\Scans\History"
I don't see any results, but maybe you will. Hope this helps.


<EMAIL_ADDRESS>depends on typescript 2.9.1 (was 2.7.2 in 0.6.7)

Bug Report or Feature Request (mark with an x)
- [x] bug report -> please search issues before submitting
- [ ] feature request

Area
- [x] devkit
- [ ] schematics

Repro steps
update @angular/cli  in existing project from 6.0.7 to 6.0.8
notice the additional dependency on typescript 2.9.1 in yarn.lock

Desired functionality
stick with main typescript version of angular

That change was intentional.  The build optimizer’s use of typescript is independent of the rest of the system.  2.9.1 brought an important bug fix for the build optimizer’s use case.


Module parse failed: Unexpected token when running with Storybook

Checks

[X] Not a duplicate.
[X] Not a question, feature request, or anything other than a bug report directly related to Svelte Splide. Use Discussions for these topics: https://github.com/Splidejs/splide/discussions

Version
0.1.18
Description
Pretty much the exact same issue from react-splide but this is showing up when I run Storybook.
https://github.com/Splidejs/react-splide/issues/30
ERROR in<EMAIL_ADDRESS>574:9
Module parse failed: Unexpected token (574:9)
File was processed with these loaders:
 *<EMAIL_ADDRESS> * ./node_modules/svelte-loader/index.js
You may need an additional loader to handle the result of these loaders.
|
|       function go(control) {
>               splide?.go(control);
|       }

Reproduction Link
No response
Steps to Reproduce

Install current svelte-splide version
Install storybook
Run storybook pointing to component using svelte-splide (storybook is using Webpack 4)

Expected Behaviour
Would not error.

As you see the solution in the thread, use webpack 5 instead.
Stroybook officially supports it.
https://storybook.js.org/blog/storybook-for-webpack-5/


Set stdin to null when starting a wasmcloud host with wash-lib

By default tokio::process::Command inherits stdin from the running process, which means that if you're trying to start a wasmcloud host with wash-lib it will capture stdin and make that particular terminal unusable until you kill the wasmcloud process.
This fixes the issue by setting stdin to null when starting the process.

@brooksmtownsend probably, yeah. Let me add that too


Postfix

username: kashish-219
aim: want to get used to github through hacktoberfest
date: 14/10/23
I have added an evaluation of postfix expression file in C folder.
I have added my name in contributers.md file  and also added my name in the file of postfix along with date and aim as well as starred the repo.
If the code is okay,then can you merge the request and add hactoberfest-accepted label to the request.

@kashish-219 remove credits from code

Can you please tell what credit is?
On Sat, 14 Oct 2023 at 3:54 PM, Harshwardhan Patil @.***>
wrote:

@kashish-219 https://github.com/kashish-219 remove credits from code
—
Reply to this email directly, view it on GitHub
https://github.com/HarshwardhanPatil07/HactoberFest2023/pull/81#issuecomment-1762794669,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BAOCOYPB2OCLGMW3VXA7UDTX7JR6JAVCNFSM6AAAAAA6AEQNOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRSG44TINRWHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@kashish-219 and also add more commits more code!

changed done in my file.

If the changes are okay,then can you merge the request and add hactoberfest-accepted label to the request.

line of code perform should be more try adding something new


Added Cocoapods podspec

Added from Specs-master/Specs/MMMarkdown/0.3/MMMarkdown.podspec.json.
This allows those of us using cocoapods to manage dependencies to pull in the latest master commit of MMMarkdown.  In order to to do that, the pod spec needs to be in the root of the repo as per http://guides.cocoapods.org/using/the-podfile.html#from-a-podspec-in-the-root-of-a-library-repo
All I did was copy the existing pod spec from the Cocoapods master spec repo and put it in the root of the MMMarkdown repo.  This allows me to use MMMarkdown in my project in one of two ways:
# Use the latest GM release from cocoapods (currently version 0.3)
pod 'MMMarkdown'

# or use the latest commit to master
pod 'MMMarkdown', :git => 'https://github.com/mdiep/MMMarkdown.git'

I have tested both after the change and they both work so this is a low-risk merge.
Thanks for MMMarkdown - I'm really enjoying using it!  :-)

I just created a 0.4 release.

Thanks!  I really appreciate the updated.
I'll update the cocoa pods pod spec in the master cocoa pods repo.  :-)
Were there any major changes to the project builds or just new source files and some altered Xcode project settings?  I looked over the commits and didn't see any major changes to how the project is built.

I don't recall there being any major changes.

Thanks.
I just pushed the 0.4 pod spec to cocoa pods.
Best wishes.


Not working with JSF

Checkout js library cannot load - page creation breaks.

I get:
javax.faces.view.facelets.FaceletException: Error Parsing /index.xhtml: Error Traced[line: 218] Attribute name "data-version-4" associated with an element type "script" must be followed by the ' = ' character.
at com.sun.faces.facelets.compiler.SAXCompiler.doCompile(SAXCompiler.java:487)

You can safely remove data-version-4


⚠ GitHub has degraded performance

In 6ede583, GitHub (https://www.githubstatus.com/api/v2/status.json) experienced degraded performance:

HTTP code: 200
Response time: 149 ms

Resolved: GitHub performance has improved in cd141ca after 56 minutes.


pq_capabilites_ini_changes

Added Index for dimming mode, backlightcontrol, DVmode, Aspect Ration and updated hal_spec documentation

merged to develop


Remove Migrate type necessary for stable storage

Right now, if you want to add a variable to your Stable type, you have to first wrap the type in Migrate, deploy, then remove the type. It would be nice to remove the need for this.

We have rearchitected stable storage and there isn't any need for the Migrate type anymore.


Migrate Omega zip packager jobs to new Jenkins and overhaul user-displayed version details everywhere

Overview
This is the engine-side part of finally migrating the omega dist packaging jobs from the old Jenkins (jenkins.terasology.org) to the new Jenkins (jenkins.terasology.io), so we can switch over the launcher to source builds from the new location and eventually decommission the old Jenkins entirely.
There's a fair bit more to unpack here than the relatively few changes suggest, but for the main part here it is really just triggering a second job to do the Omega zip after the engine job has published. If not interested in the gory technical details can skip most the below.
The second change is reworking the pattern of what we display to an end user when it comes to release/version details, which has historically been all over the place. Now it is fairly consistent and should be possible to link between different places more easily
After this is merged alongside maybe two more PRs then the launcher should then be able to pick up two new package lines with nice clean names.

TODO: InfraPlayground PR with the new Omega job for Terasology (the Nanoware one is here as DSL and here as an actual job
TODO: Index PR with a Jenkinsfile that the Omega job will actually run. This is the old Omega freestyle job converted into a simple Jenkinsfile

Gory details - version numbers
This slowly turned into a bit of a wasps' nest over the years, as few things have really been in sync / map well to each other.

The jobs in Jenkins come in two sets, release ("stable") builds and dev ("unstable") builds with the engine alone jobs containing no modules and the omega jobs come with full modules, each of them with their own build number, based on the job in Jenkins. So for instance "1103" is the latest "dev build" with the extra modules in Omega, and there are three others (the engine build number for dev Omega 1103 for instance is actually 2317). These numbers reset if the jobs in Jenkins are ever remade and in the grand scheme should not be meaningful on their own. Additional which builds are stable vs unstable actually varies widely, names or lines aside.
The engine itself has a version number, currently 4.1.0-SNAPSHOT, using SemVer just like modules and every other actual individual software component. The engine tests, PC facade, etc also have such numbers, but luckily those aren't really used anywhere. During the engine build a versionInfo.properties file is generated if we're building within Jenkins.
On GitHub when we do a release we're really releasing the game not the engine even though that's really all that's left in this repo (we moved out the remaining modules here). So engine 4.1.0 isn't the same as "The game package with some modules and the 4.1.0 engine" - it needs its own name/number. So years ago, probably around when we went from pre-alpha to alpha I just arbitrarily threw a number after "Alpha" meaning our most recent release on GitHub is "Alpha 16" and this is used exactly nowhere else (other than occasional announcements that said release is out)
The launcher loads numbers from Jenkins, grouped on some package lines we define that map with the job lines in Jenkins. This is another spot where we've pretty much just made up names, that then pair with the build numbers from Jenkins that shouldn't be meaningful. Right now for instance we've got "Nightly" and "Lite" in there which again doesn't match anything else anywhere. All 4 job lines are represented (dev builds are "nightly", non-omega are "lite")
When you actually load the game there's a version string on the main menu, which loads some details originally determined during the Gradle build and stored in a versionInfo.properties file we cram into the engine jar file and also attach in Jenkins. However, this again barely matches with everything and isn't clear at all.

Jenkins
On the surface Jenkins remains roughly the same as before

URLs naturally vary, both from the base URL and from mostly everything being multi-branch pipeline jobs now. In theory we could have just gone with more plain pipeline builds for the omega packager, but this is nice and easy plus consistent. This does mean there'll be both a master and develop branch in the Index repo now as well, when we've only ever had the one master branch before. Seems like we should be following that workflow anyway so if we ever need to rebuild a release omega it won't fetch modules added in develop since last (it will however still grab the very latest version of every module, but that's a fight for another day and I have thoughts on it)
The latest versions of Jenkins abstract away the SCM systems, so Git is no longer a natural default exposed via env variables. This seems OK and we can still get at that data if we really need it, but I don't think it is really in use. Technically the VERSION file is meant to contain the branch, but I'm not sure that ever gets looked at, and while it is referenced in both the engine and PC build files I think it is only used in the facade. Got one more commit to clean up and maybe look at this just a little more.
The versionInfo.properties file is now also attached to the Omega job (it wasn't previously, just living inside the engine jar), so ideally the launcher could get at it there (more easily?) and not need the bare engine jobs at all.

Engine
Several changes here, whole diff in fact since this is the engine repo after all!

Assorted bits of cleanup / outdated stuff, like removing the two Git vars no longer exposed by default in Jenkins, and swapping in the jobName fully instead. Also for some reason the SNAPSHOT vs not deduction was in the engine plus engine-tests even though it is explicit in there, so in some cases we could get -SNAPSHOT-SNAPSHOT in the version stuff nobody reads
Added the informal alpha increment number to the weird old templates/version.txt which previously just held "alpha" - we need to start maintaining this now but that isn't exactly a huge effort yet should make a huge difference visually in places. Not really sure why that was ever considered a "template" but this is truly ancient stuff.
Updating the version detail calculating logic that'll be used in the game UI (see its own section below)
Updating the version details that'll be used in MANIFEST.MF not that anybody ever looks at it (did you know: it actually held the build number twice for some reason?)
The Jenkinsfile now will trigger the Omega job to run on the publish stage otherwise succeeding (no real need to wait for analytics as we don't use them to gate anything yet, that may change in the future). This is hard-wired between master + develop and the corresponding Omega jobs, including Terasology vs Nanoware which needs to be adjusted before this is merged. That can be deduced but tired and getting late :-)
Keying off JOB_NAME now instead of BUILD_URL for calculating fancy version details for later user display - both set by Jenkins, no idea why I picked the URL in the past, job name seems more useful

GitHub
When we do a manual release (until we finally fully automate that somehow) we need to be sure to also update the templates/version.txt file as part of the prep for the next release (akin to version bumping and re-attaching -SNAPSHOT) so that we call the releases on GitHub the same thing as we've codified it to be in the engine repo. This probably should go on some wiki page I've got at the top of my tongue but late + tired. So: TODO
Launcher
These are the current package lines in the launcher:

I don't remember exactly what the launcher pulls and has access to, I can dig around some if needed. But I do remember we attached the versionInfo.properties file in Jenkins so it would be publicly accessible, so hopefully the launcher can use it to parse out further details.
My suggestion would then be the following (if we can easily add package lines without them all using the same base URL, so we can have both new and old entries for a while):

Add two new lines that solely represent the Omega packages in the new Jenkins (the engine zip alone has no modules so it isn't very useful anymore). Call them "Terasology Release" and "Terasology Preview" - do away entirely with "stable" and "unstable" and "dev build" and "nightly" and "lite" - just those two things. I nearly went with "snapshot" since I'm a dev before I remembered to think like a player who wouldn't necessarily know and shouldn't care what a "snapshot" is, the dev builds are previews of the next release, simple as that.
Grab the displayVersion field from the versionInfo.properties file attached in Jenkins for every build, use that as the primary meaningful name for the entries associated with the package line, paired with the actual job build number, which may reset over time, but will never repeat when paired with the display name of the build (we'd aim to tie any future resets with game releases or something if needed). Instead of "Terasology (nightly)" + "1103" You'd have "Terasology Preview" + "Alpha 17 build 1103" (actually it'd be 2317 but ... bear with me the answer to that is elsewhere, and really the idea is to make these numbers meaningless to where it doesn't matter which is there, just that higher number for a given alpha version is newer)
Useful URLs:

http://jenkins.terasology.io/teraorg/job/Nanoware/job/Omega/job/develop/lastSuccessfulBuild/buildNumber - automatically shows the most recent build number, the package line in the launcher would start here then go backwards x numbers until it either has a nice list of entries or runs out (id goes below 1). Naturally needs to be adjusted from "Nanoware" to "Terasology" when the change is live. I believe this is how it works as-is, just need the updated URL

Note that this should always be "lastSuccessful" as the Omega packager has no unit tests. It either succeeds or fails, there's no unstable to worry about like with the engine job

http://jenkins.terasology.io/teraorg/job/Nanoware/job/Omega/job/develop/2/artifact/distros/omega/build/distributions/TerasologyOmega.zip - game zip for a given build
http://jenkins.terasology.io/teraorg/job/Nanoware/job/Omega/job/develop/2/artifact/distros/omega/versionInfo.properties - info prop file for a given build
For the Release line instead of the Preview line swap develop to master (no example as the master build for Nanoware fails for some inexplicable reason, I might blow it up and let it recreate)

It should be possible to test this against the Nanoware develop job + develop Omega right now in the launcher, assuming we can add such a new package line entry for testing.
Game UI
Here's what the current main menu looks like when it comes to the version label:

This is not very useful. The "2317" is really the only thing that ties it to something and that's the engine build number from Jenkins for the dev build line. Wha? This isn't even what you get if you use the "nightly" Omega line in the launcher, since that's a different build number, namely 1103 from the Omega dev job.
Here's what you'd get with the changes, although the null would be replaced by the engine job's build number if built in Jenkins (you get this by setting the JOB_NAME env var to Terasology/engine/develop locally then running gradlew createVersionInfoFile game - I skip setting the build number when testing locally)

That's a little better. The highlight is you've got an Alpha 17 preview build. Alright, that's a good baseline. If we pretend this was built in place of the current dev build + Omega it would list "engine v4.1.0-SNAPSHOT, dev build 2317..."
Still not quite perfect as the launcher would still list the build number as 1103. We could in theory update that during the Omega packaging job by going in and updating the versionInfo.properties file inside the engine jar. But the engine doesn't really know or (should?) care whether it was built standalone or repackaged via Omega? Dunno.
If it was built from the master branch / release Omega it would just be "ALPHA 17" with a similar detail string (minus the snapshot and "dev" bits). Still would have the engine build number instead of the omega build number though.
For other cases we get stuff like this:

Anything that isn't either the main master or develop branch builds yet is still built out of Jenkins (or faked locally via JOB_NAME) gets that "Special:" decoration with the exact job path it came out of.
Finally if you don't have JOB_NAME set you're likely running from source, or you ran a manual build for some odd reason. You get a simplified label since we can't really be sure what's going on so we just call it "Custom"

For the absolute vast majority of time a regular player should only ever see the "ALPHA 17" or "ALPHA 17 Preview" examples on a single line, with a second line of details just in case (that should probably be shrunk and made less prominent, maybe even get moved somewhere else). All the other cases are for devs.
Extras
Likely future change: We should probably move the concept of the game package naming/versioning entirely out of the engine repo into the Index repo or whatever it becomes. For right now it is just easier to keep it in the engine since it works and gets shoved into the engine jar which then gets used by the omega packager. This would likely pair well with a better definition of the module / game distribution lines than prop files in a folder somewhere. As part of the GooeyCLI work I started looking at this, including module lines that don't get built but form useful groupings (like "all tutorials"), but that needs more work, and might go to a different format than poor old .properties (JSON or YAML)
Potential subtle complication: if an omega packaging job is executed manually it'll copy engine artifacts from the last successful build - as in, no broken unit tests. If we have unstable builds (flakey engine tests) the packager would grab the most recent fully successful engine build. In theory this should be a very rare occurrence since that would only ever happen if we manually wanted to rebuild an omega zip alone, rather than just run a fully new engine build. Full build is more the recommended approach, and historically I've tried to find a quick simple PR to merge just to retrigger a proper Omega (or just manually executed the engine build itself). But there might be a rare time when we're trying to test a replacement module real quick, where we in that perfect storm of conditions could end up with a slightly older engine build than expected.
Here be dragons: This PR will likely fail or do really weird things when tested in Jenkins
Good First Issue: If this approach looks reasonable then we could make it a little prettier by splitting the version label and putting the fine details of the version on line two into a separate label with a smaller font size. Easy GFI. TODO.

The versionInfo.properties file is now also attached to the Omega job (it wasn't previously, just living inside the engine jar), so ideally the launcher could get at it there (more easily?) and not need the bare engine jobs at all

I don't remember exactly what the launcher pulls and has access to, I can dig around some if needed. But I do remember we attached the versionInfo.properties file in Jenkins so it would be publicly accessible, so hopefully the launcher can use it to parse out further details.

That's pretty neat. I was just playing around with collecting the SemVer for our releases across different Jenkins jobs, this would make it a lot easier! It currently doesn't use that information, but that's a simple change indeed.

My suggestion would then be the following (if we can easily add package lines without them all using the same base URL, so we can have both new and old entries for a while):

I'm working on a refactoring that will allow to easily consume game releases from several places. Having a unique way (SemVer) of identifying things would help a lot. I'm looking for an identifying tuple of (semver, profile) where the profile is the "codeline" or "release type", i.e., whether we're talking about Omega, the bare engine, or whatever in-between there might be in the future.

automatically shows the most recent build number, the package line in the launcher would start here then go backwards x numbers until it either has a nice list of entries or runs out (id goes below 1). Naturally needs to be adjusted from "Nanoware" to "Terasology" when the change is live. I believe this is how it works as-is, just need the updated URL

We currently just use the REST API for the job to get the list of builds in one batch and scan that for successful builds which also have artifacts attached. I'd like to keep it that way, instead of grabbing one build at a time and counting backwards manually.
Here's what I get with my local testing setup in mid-refactoring land:
19:37:20.964 [Launcher init thread] INFO  o.t.launcher.LauncherInitTask - Fetching game releases ...
19:37:20.979 [Launcher init thread] DEBUG o.t.l.r.NanowareJenkinsRepositoryAdapter - fetching releases from 'http://jenkins.terasology.io/teraorg/job/Nanoware/job/Omega/job/develop//api/json?tree=builds[actions[causes[upstreamBuild]]{0},number,result,artifacts[fileName,relativePath],url,changeSet[items[msg]]],upstreamProjects[name]'
19:37:21.865 [Launcher init thread] DEBUG o.t.l.r.NanowareJenkinsRepositoryAdapter - Derived SemVer for OMEGA@2+NIGHTLY: 	4.1.0-SNAPSHOT+2
19:37:21.867 [Launcher init thread] DEBUG o.t.l.r.NanowareJenkinsRepositoryAdapter - Derived SemVer for OMEGA@1+NIGHTLY: 	null
19:37:21.867 [Launcher init thread] DEBUG o.t.l.r.NanowareJenkinsRepositoryAdapter - fetching releases from 'http://jenkins.terasology.io/teraorg/job/Nanoware/job/Terasology/job/develop//api/json?tree=builds[actions[causes[upstreamBuild]]{0},number,result,artifacts[fileName,relativePath],url,changeSet[items[msg]]],upstreamProjects[name]'
19:37:22.974 [Launcher init thread] DEBUG o.t.l.r.NanowareJenkinsRepositoryAdapter - Derived SemVer for ENGINE@4+NIGHTLY: 	4.1.0-SNAPSHOT+4
19:37:23.417 [Launcher init thread] DEBUG o.t.l.r.NanowareJenkinsRepositoryAdapter - Derived SemVer for ENGINE@3+NIGHTLY: 	4.1.0-SNAPSHOT+3
19:37:23.552 [Launcher init thread] DEBUG o.t.l.r.NanowareJenkinsRepositoryAdapter - Derived SemVer for ENGINE@2+NIGHTLY: 	4.1.0-SNAPSHOT+2
19:37:23.675 [Launcher init thread] DEBUG o.t.l.r.NanowareJenkinsRepositoryAdapter - Derived SemVer for ENGINE@1+NIGHTLY: 	3.3.0-SNAPSHOT+1
19:37:23.675 [Launcher init thread] DEBUG o.t.l.r.NanowareJenkinsRepositoryAdapter - fetching releases from 'http://jenkins.terasology.io/teraorg/job/Nanoware/job/Omega/job/master//api/json?tree=builds[actions[causes[upstreamBuild]]{0},number,result,artifacts[fileName,relativePath],url,changeSet[items[msg]]],upstreamProjects[name]'
19:37:23.948 [Launcher init thread] DEBUG o.t.l.r.NanowareJenkinsRepositoryAdapter - Derived SemVer for OMEGA@1+STABLE: 	null
19:37:23.948 [Launcher init thread] DEBUG o.t.l.r.NanowareJenkinsRepositoryAdapter - fetching releases from 'http://jenkins.terasology.io/teraorg/job/Nanoware/job/Terasology/job/master//api/json?tree=builds[actions[causes[upstreamBuild]]{0},number,result,artifacts[fileName,relativePath],url,changeSet[items[msg]]],upstreamProjects[name]'
19:37:24.226 [Launcher init thread] INFO  o.t.launcher.LauncherInitTask - ENGINE@1+NIGHTLY

Questions

Why do you want to display the user a version such as "Alpha 17" instead of a Semver? I'd like to understand why we try to maintain an additional version here, instead of just carrying over the engine version to the Omega release? Is it important that we are still "alhpa"? Do you think a Semver is too complicated?
I'd prefer to display a Semver in the launcher, for instance 3.5.1 or 4.1.0 for "stable" releases, and (a slightly modified) Semver for previews, e.g., 4.2.0 Preview<PHONE_NUMBER>47) (which would be 4.2.0-SNAPSHOT+202011081947 under the hood). That way we would get the order of releases from semver semantics.
Also, I'd like to change the way we display the releases in the launcher. Instead of the having 4 entries in the dropdown I'd like to only have two for the main release lines (Omega, Lite (engine)) and just list all releases for the respective code line in order. (plus adding an option to only show stable versions/hide preview versions).

In the old Jenkins we also had the changelog to collect and display in the launcher. Is that still available in the new setup?

Why do you want to display the user a version such as "Alpha 17" instead of a Semver

A few reasons, but neither of them particularly deep or permanent :-)

Players don't care about SemVer, or necessarily understand it. Sure, they can just compare numbers and see what's newer (especially a small little corner tag in the app showing the "technical version"). But "Alpha 16" vs "Alpha 17" is probably a more meaningful human comparison than "engine v3.1.0" vs "engine v3.2.1": "Oh, okay, Alpha 17 is 'one newer'"
Engine version may theoretically not change at all for a new release, if for some reason we need to just change some modules (most likely case: a quick re-release due to some bad modules)
Omega != engine - it really should have its own release number IMHO, probably tracked in the Index repo, which in turn explicitly points out what engine version, module versions, etc, are dependencies for that Omega release. That could itself be a SemVer number, but then the point about player meaningfulness still stands. That seems like a future discussion, wasn't something I wanted to try throwing code at right now.

I'm not particularly attached to any of those points, they're just my arguments in favor of why it is the way it is right now.
Launcher listings: I don't think "Lite" makes any sense anymore. You literally can't enter a world that way, without yourself adding modules, possibly via the semi-broken in-game module downloader. It just serves as a point of potential confusion to the user now. Additionally I'm not sure what actual player would want that - it seems more like a modder/dev thing.
Unless "Lite" turns into the Iota module set or something instead. But then that just may get into more naming confusion, plus size-wise there isn't that much of a difference - 70mb vs 150mb). I think merely having the two entries to start with (Release vs Preview) would be ideal, possibly with different lines hidden by default (Iota if it makes sense to distribute it via launcher, kinda skeptical, experimental branches, etc)

Changelog

Yep: http://jenkins.terasology.io/teraorg/job/Nanoware/job/Terasology/job/develop/changes for instance (different path of course for the live game's release and preview tracks)
Great to see the progress and options, and I'm sure we'll have more of them, just the sooner we can get past this point the sooner we can destroy the old Jenkins in a maelstrom of fire 😁

Thanks for taking your time to explain this.

Players don't care about SemVer, or necessarily understand it. Sure, they can just compare numbers and see what's newer (especially a small little corner tag in the app showing the "technical version"). But "Alpha 16" vs "Alpha 17" is probably a more meaningful human comparison than "engine v3.1.0" vs "engine v3.2.1": "Oh, okay, Alpha 17 is 'one newer'"

I think AAA games conditioned players quite well to understand semver by now. Nearly all patch notes I'm aware of refer to (more or less) a semver, for instance Minecraft 1.16.2, Valorant 1.11, or Witcher 3 1.30. However, major releases (not necessarily in the sense of semver, though) often come with catchy names or titles like "The Aquatic Update" or "The Cave Update".
Preview releases of the next major update can often be found as "release candidates" which can be expressed in semver as 2.0.0-rc.1. These release candidates count up from 1 to n regardless of the underlying build number.

Engine version may theoretically not change at all for a new release, if for some reason we need to just change some modules (most likely case: a quick re-release due to some bad modules)

Yep, totally agreed. I take back my suggestions to completely bind the Omega release version to the engine version. Especially the case of "re-release" should IMHO be a patch release (4.0.1 is fixing a broken 4.0.1 build), so this version part should be available for exactly this use case.

Omega != engine - it really should have its own release number IMHO, probably tracked in the Index repo, which in turn explicitly points out what engine version, module versions, etc, are dependencies for that Omega release. That could itself be a SemVer number, but then the point about player meaningfulness still stands. That seems like a future discussion, wasn't something I wanted to try throwing code at right now.

I like the idea of having dedicated versions for the release distributions we provide. Where these numbers should start and how they may look like is a completely different topic - and probably quite complicated 🙈 First thing to keep in mind is that we have "press coverage" that we released Terasology v4, so changing the version scheme should take this into account somehow. The v4 comes from the engine version, so we can probably keep that in some way.
Technically the Index repo could define an aribitrary semver for the released distributions, e.g., 0.17.0 for Omega "alpha 17", but this does not contain any information on engine or modules. We could derive a module lineup version from the included modules (or rather, the version bumps of the included modules) in some way, but that leaves us with two semvers to identify the release (engine and module lineup) - meh.
I'd like to propose a version scheme that takes both into account, but melts it into a single Semver:
<engine.major>.<# of module changes>.<patch>

<engine.major> - Simply the major version of the engine. We don't care about the exact version in the distribution (at least in the displayed version), but still couple our omega release to the engine release.
<# of module changes> - The first release with a new major engine version would start at 0, and every major or minor module version bump would increase this number by one (where "every version bump" is every bump within release builds, i.e., the next release build could contain multiple updated modules but still only bump this version by one).
Not sure about minor engine changes that don't require any module updates (new features) - they would also have to increase this number in case nothing else changed...
<patch> - Any patches or fixes applied to the distribution. Both engine patches and module patches contribute to this version.

So 4.1.0 would be the second "stable" release with engine v4, and 5.42.3 would be the 3rd attempt to get the 42nd release with engine v5 to work properly. The same version scheme would work for other distributions/line-ups.

Launcher listings: I don't think "Lite" makes any sense anymore. You literally can't enter a world that way, without yourself adding modules, possibly via the semi-broken in-game module downloader. It just serves as a point of potential confusion to the user now. Additionally I'm not sure what actual player would want that - it seems more like a modder/dev thing.

We can remove the "Lite" option from the launcher easily, no problem with that. However, if we ever fix the "semi-broken in-game module downloader" I think it would be a viable option to still offer it for players to just grab what they want (instead of pre-bundling everything). At some point, the whole update/upgrade topics will come up again (update single modules, update the engine, ...). Let's postpone that...

@Cervator is there a way to get the version info into Jenkins metadata instead of attaching it as a file (or in addition to)? Fetching the builds overview via the REST API is quite fast, but doing round trips for fetching the version file for every build slows down the launcher startup noticably. The more info we can get with a single request the better (we can use some way of filtering directly in the request to even reduce to only the stuff we actually want).
I'll see whether I can get the changes directly, but doing one more request sounds fine, too.

get the version info into Jenkins metadata instead of attaching

Well, maybe somehow, I'm not sure. We probably don't want to tie build packages more to Jenkins, if our longer term goal is to support build packages somewhere else? In fact, maybe what we should do is go in a different direction and make the meta server also store an index for launcher packages? It has an API, stores stuff in a database, is tool agnostic, etc ... skip ever having the launcher calculate anything, make the meta server worry about it and just pull a catalog. That'd be a step toward arbitrary build packages hosted elsewhere too.
That'd be more work so maybe it would be worth just accepting a bit of a performance drag right now to be able to move forward and iterate more on speedier more rich launcher metadata later?

I think AAA games conditioned players quite well to understand semver by now.

I suspect this might be a hard call. Veteran gamers like us? Sure - you don't need to be a developer to sort out numbers. But school kids? We might be biased due to our immersion in the topic. Minecraft is a bit of a special case due to the intense focus on modding - admittedly also a goal of ours, we're more similar to that than the polished AAA games that likely next to nobody pays attention to numbers for.

catchy names or titles like "The Aquatic Update" or "The Cave Update".

I like these and would love to get there, but they're probably too far away from numbers right now, until we have a more cohesive game and update pattern. I figured maybe by the time we go Beta (or even release) we'd call the overall game v1.0.0 and reassess naming by then.

derive a module lineup version from the included modules

That one makes me itch a little, since suddenly we're using a non-SemVer approach in the SemVer pattern. So some places are SemVer, while others look like it but mean something else :-)
Maybe we could use a game-level SemVer but use the decorators after x.y.z to indicate the game line / module updates? That could potentially be the best of both worlds. A meaningful number that both respects SemVer but tells a bit more of a story. Although I think it'd be nice to still have a more "human" name for the main releases.

x - breaks save compatibility with past worlds (backwards incompatible)
y - there are new things (one or more in any component)
x - bug fixes only (literally every changed component only incremented at the patch level)

We can remove the "Lite" option from the launcher

I do think that for now we should remove it, that doesn't mean we couldn't bring it back later, or perhaps more likely Iota? Along with Omega or the other letters for a few predefined lines. Or better names yet (Iota -> Lite or what not). Just so long as we can default to something very clear that a user can just click a button for, get, and play. Consistency is key and right now we need a bunch of that until we can doc and display our things better.
Everything above is just quick opinions, honestly as long as we're moving forward I'm fine with whatever approach as long as it gets the attention it needs 👍
On a somewhat related note: If we end up writing an outright "Omega book of materials" style thing for a given release rather than just a list of module names in a prop file that would be helpful in parsing out actual changes in modules since a previous point (even multiple releases). At that point rather than just a vague number meaning "42 modules changed for this release!" you could give it whatever number and provide collapsible change notes for the exact diff. Kinda like writing out a pinned version/dependency file for some languages.

Notes from today's org meeting:
snapshots are overwritten
-> content changes, not useful for reproducible builds
-> for reproducible builds we’ll need release management for all modules
default version resolution: always use latest (including snapshots)
gradle can “pin” (lock) versions
checked-in lock file
idea 1: have module builds update pin lock file
idea 2: only pin released modules, use gradle dependency resolution

whoops sorry. accidentally closed this while trying to test the release process. the changes that were on Nanoware:develop now live in topic/packaging-and-versions


A built release?

I know this hasn't been updated in 2 years but a release would be nice instead of having to build it ourselves. Is it possible to get someone to create a release on github for this?

Agreed.
Also, does this work only on Windows, or is it able to build on other OS'es too?


give more styling to the the tic tak toe game

more presentable and dynamic look to the game which give better user interaction

Can you assign this work to me? And I will always contribute to any issue, cause it makes me think and grow further

I would like to enhance the styling , customize it to look more attractive and appealing.

I am really good in html would your assgn this to me

you can assign that task to me under gssoc-ext and hacktoberfest label..


[PE-D][Tester B] Color changes doesn't persist in timetable

We can click on the time periods to change colors in the timetable, however, the changes doesn't persist once we move screens.

Labels: severity.Low type.FunctionalityBug
original: Berted/ped#7

This is one of the features of ProNUS. We want the timetable to be more colorful.

Not a bug


suggestion: inform units on receiving hit

I was toying this idea as an alternative to handle https://github.com/lampe-games/godot-open-rts/issues/95 & make the actors more responsive to each other.
I was not sold on, units auto attacking in sight range, seems a bit too offensive to me, so here is the idea for a Defend Your Friend doctrine.
To be honest I am not sure if this does anything right now, I will try to test it out soon ™
Right now it should act as a defensive reaction, where units support each other, but could also be added to the offensive stances.
If you like it, the do adjust would be the following:

[ ] adjust the signal for offensive stance
[ ] don't set auxiliary target on workers
[ ] possibly filter signals by team

The idea looks interesting - I've been thinking about a similar thing, but simplified.
As for implementation, that's a secondary thing.
Anyway, for starters, I think it would be nice to review how well-known RTSes handle that. I'll try checking Warcraft, Starcraft, and AoE.

I also like a defensive stance more than an aggressive tbh :D Aggressive just seemed easier to implement, hence #95. In Age of Empires at least you can choose the stance of each unit (Aggressive = #95, Passive = how it was before, and defensive). Having the option to switch between different stances would be perfect obviously


Community integration - Truffle

"truffle unbox tokenscript"
Create a truffle box for TokenScript.
This box could include / but not required for this first configuration:

Demo Dapp
Contract to deploy an ERC-721 token
CLI generate TokenScript file
Utilise Token via token negotiator within Dapp
Full Attestation of ownership flow

@nicktaras , for example, I use hardhat rather then truffle, I have more experience with hardhat, but truffle is similar

Demo Dapp

it should install sample browser Dapp, corect? what that test app should do? what simple tasks?

Contract to deploy an ERC-721 token

maybe you mean "install package with example ERC721 contract + script to deploy"?

CLI generate TokenScript file

do you mean to generate TokenScript file for ERC721 token for contract from previous step?

This task has not been required / requested to develop. Removing.


Use kubicorn to deploy a cluster to existing hosts

Is kubicorn able to provision a cluster if I have existing machines? How would I go about implementing a provider to be able to accomplish this?

Currently not. We have plans for the adopt command for existing clusters, but it's on hold. We'll have more information about the command as we get kubicorn/controller more stable and fully-switch to the new cluster API.

Thanks for the update! I'd like to contribute. Please point me in the right direction.

Hi @apobbati! I'm happy to hear you'd like to contribute to the project! Sorry for my late response, it has been a very busy week.
This is a large issue, so we want to make sure we plan it right. Before I give you some directions on how to do it and where to look into, I would love @kris-nova to let us know what does she thinks about the problem and is it good time to solve it now, or after we fully-implement cluster API.
If you have any idea how to solve the problem, let us know. You can also join our open developer calls to discuss it with us (calls are held biweekly, 1pm PST. For calendar invite, join our mailing list).

@xmudrii @kris-nova Sounds like a plan! I'm a little new to Golang but I've provisioned Kubernetes clusters with other installers, so at this point i'm wondering what is the Kubicorn way to solve this problem.

Has there been any progress on this?

@adrianog As far as I know there's still no progress on this issue.


fix #57 by changing href for GitHub corner in index.html

This pull request should fix #57. I just changed the href for the GitHub corner in index.html so that it points to freesound-player instead of freesound-player's current address.
I made some weird errors in #58 so we can just look at this pull request in regard to fixing #57.

🥳


Register a webhook dynamically

I can't find an information, on wether there is a way to programmatically register webhooks.
Is there a way to register a webhook through an API request? This would be very useful, in cases where we have oAuth users and wish to setup webhooks for them, currently to make it work each user would have to go through the console and do it manually. Maybe this is something that is coming shortly in the future?

Dropbox does not offer the ability to register webhook URIs programmatically, but I'll pass this along as a feature request. I can't promise if or when that might be implemented though.
Note though that the end-users of your app shouldn't each be registering their own app and webhook URI(s). You as the developer would register your app and webhook URI(s) once, and then you would recieve webhook notifications to the webhook URI(s) for any changes in any of the user accounts connected to your app.
Please refer to the following resources for more information:

https://developers.dropbox.com/oauth-guide
https://www.dropbox.com/developers/reference/webhooks

Hey @greg-db
Thanks for the reply!
I understand, did not think of it that way. Usually when it comes to webhooks, you register specific urls for users (maybe even multiple). But yes, your answer solves my quest!
Best wishes!


Added blobs support for Static LLM pipeline

Added support of importing blobs for StaticLLMPipeline

@ilya-lavrenov @Wovchena Could you have a look, please?


add TServerEventHandler to clean threadlocal  token in TokenWrappingHMSHandler

:pencil: Description
In this issue https://github.com/ExpediaGroup/waggle-dance/pull/266 , we support kerberos and delegation tokne via TokenWrappingHMSHandler. We found that some time threadload of TokenWrappingHMSHandler not be clean when the concurrency is high. So using TServerEventHandler to trigger threadlocal remove.
Reference:https://github.com/apache/hive/blob/7bfc54ffc8baf5f3e7de326b750fe9355b11132b/standalone-metastore/metastore-server/src/main/java/org/apache/hadoop/hive/metastore/HiveMetaStore.java#L651
test：Manual testing
:link: Related Issues
no

Hi @zzzzming95 – thanks for submitting another PR.
Please send me a private message via LinkedIn. I'd like to get more details about your Waggle Dance usage and future use cases. Thanks.


Refactor params

[ ] Support namedtuples
[ ] Find new names for mandatory params
[ ] Find a neat way to supply them

Not needed


Use yahoo finance CSV to retrieve stock info

This is the same underlying API that YQL uses.  While
YQL is a great abstractiong, it seems that many of the
YQL nodes do not work as expected - and either return
no results, very old results, or fail with various errors.
Using the CSV directly saves us from having to
blacklist "bad" YQL nodes.

@imnotjames does this still work? I read that the quotes.csv was shut down last week.

Seems like it.  Real bummer, the YQL returns really weird data most of the time and is very unreliable.

Actually, doesn't seem like the YQL one works either because it relied on the CSV..


Navigation/Notification Bar crops off

This happens with the Forum embedded in Wordpress.
When an user is logged-in and goes to an already visited discussion, the navigation bar gets cropped off.
What could it be?

Explicit support for embedding won't be provided (it was a nightmare to support in the first iteration of the theme).


Generating keyword file for javascript.

Is there a way to generate keyword file for javascript. Or in any way, can I use platform specific keyword files generated by optimizer inside js?

No. There are a few keywords files available for JS in the resources/keyword_files directory. I will add a few more in the next few days so that all platforms have the same number of freely available files.


LightGBM package targets don't apply when package is referenced transitively.

Description
The LightGBM package includes targets to warn the user when referencing on an unsupported architecture.  Those targets will not be applied when the package is referenced transitively.
https://github.com/microsoft/LightGBM/blob/dd31208ab7a7aea86762830697b00666f843ded9/.nuget/create_nuget.py#L80
Reproducible example
lightGbmSample.zip
I would expect a warning here since this sample references LightGBM in an x86 app, but there is none since the targets only apply to the project that directly references LightGBM.
Environment info
LightGBM version or commit hash: 3.3.5
Additional Comments
I believe the fix here is to simply copy the props/targets into the buildTransitive folder.  See https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#controlling-dependency-assets.

@ericstj sorry for the delayed response.
We don't have much .NET experience here. Are you interested in submitting a fix?


explore use of environment as the data structure for nimblePointerList contentsList

In looking at slow mcmc build times for a user example (260,000 nodes), taking 80-90 minutes for buildMCMC, I noticed that assignment into the contentsList of samplerFunctions and initFunctionList seemed slow because contentsList was a list.
Initial testing suggested that making contentsList be an environment might speed the buildMCMC time in this example 2.5-fold. Needs more experimentation to verify this is a robust result.

This has not been done; is this moot given nimbleCompiler work?