gradlew run issue

I'm trying to run the one of the examples inside morpheus on a spark cluster I have edited the creation of the morpheus session using the following lines of code:
 val conf = new SparkConf(true)
  conf.set("spark.sql.codegen.wholeStage", "true")
  conf.set("spark.sql.shuffle.partitions", "12")
  conf.set("spark.default.parallelism", "8")
  val spark = SparkSession
    .builder()
    .config(conf)
    .master("spark://<IP_ADDRESS>:7077")
    .appName(s"morpheus-local-${UUID.randomUUID()}")
    .enableHiveSupport()
    .getOrCreate()
  spark.sparkContext.setLogLevel("error")
  implicit val morpheus: MorpheusSession = MorpheusSession.create(spark)

 import spark.sqlContext.implicits._

  val nodesDF = spark.createDataset(Seq(
    (0L, "Alice", 42L),
    (1L, "Bob", 23L),
    (2L, "Eve", 84L)
  )).toDF("id", "name", "age")

  val relsDF = spark.createDataset(Seq(
    (0L, 0L, 1L, "23/01/1987"),
    (1L, 1L, 2L, "12/12/2009")
  )).toDF("id", "source", "target", "since")

  val personTable = MorpheusNodeTable(Set("Person"), nodesDF)
  val friendsTable = MorpheusRelationshipTable("KNOWS", relsDF)

  val graph = morpheus.readFrom(personTable, friendsTable)
  val result = graph.cypher("MATCH (n:Person) RETURN n.name")
  result.show

just by editing the sparksession with the master URL 'spark://<IP_ADDRESS>:7077' rather than 'local'
I have a problem while running the gradlew run example
./gradlew morpheus-examples:runApp   -PmainClass=org.opencypher.morpheus.examples.DataFrameInputExample
while debugging, The problem stated is with the result.show line:
Caused by: java.lang.NoSuchMethodError: scala.Predef$.refArrayOps([Ljava/lang/Object;)Lscala/collection/mutable/ArrayOps;
        at org.opencypher.okapi.trees.AbstractTreeNode.<init>(AbstractTreeNode.scala:69)
        at org.opencypher.okapi.ir.api.expr.Expr.<init>(Expr.scala:50)
        ... 88 more

But while I change the example to be with  'local'   it runs correctly, and no problems arise
When I searched, It seems the problem is with the Scala version:
although I have the following on my cluster of 3 machines:
OS: Centos 7
Spark: version 2.4.2
Scala: Version 2.12.8

and I have put the required morpheus jars in the Spark class path (spark/jars) directory on all the cluster machines Master and Workers, such as:

morpheus-spark-cypher-0.4.3-SNAPSHOT.jar

okapi-api-0.4.3-SNAPSHOT.jar

okapi-relational-0.4.3-SNAPSHOT.jar

Please help me figuring out the problem, because I take a lot of time trying to solve this issue!
Thanks in advance for your help and support!

Hi Mohamed,
Which version of Scala was your distribution of Spark compiled against?
Look in the jars directory at the spark jars e.g. spark-sql_2.11-2.4.3.jar
I ended up compiling Spark 3.0.0-SNAPSHOT against Scala 2.12 to get a working Morpheus install. This should also solve #932 for you.

Actually I have the version of Spark2.4.2 which is compiled against Scala 2.12.8  with this spark-sql_2.12-2.4.2.jar but the same problem occurs !! which version of spark do you have ?
Could you help please !!

Hi Mohamed,
the latest release of Morpheus uses Spark 2.4.3 with Scala 2.12.8. Could you try it with that version? You can download the correct Spark version here: https://archive.apache.org/dist/spark/spark-2.4.3/spark-2.4.3-bin-without-hadoop-scala-2.12.tgz
Unfortunately this build does not include hadoop so you have to add the missing packages yourself if you need them or build Spark directly from source.


Reopen - Filewatcher / Autoreloader AIR does not recognize changes

Describe the bug

I'm using AIR (https://github.com/air-verse/air) to watch file changes and rebuild the binary inside the container. This works with Docker Desktop, inside the container, and native Go,  but not with Orb. It seems like file changes are not visible inside the container.
https://github.com/orbstack/orbstack/issues/79

It seems you are fixed on this issue.
https://github.com/orbstack/orbstack/issues/58

Orbstack version I have tried but it doesn't work

v1.8.0
v1.7.5
v1.6.4

My system info

MacBook Pro M2
MacOS: 13.5.1 (22G90)

To Reproduce
https://drive.google.com/file/d/1Jqqq1dVGlea3HBk3FhyVrYQmEjUSMVpz/view?usp=sharing
Expected behavior

On every file change AIR should rebuild the binary and the change should be visible

I'm not sure but after I uninstalled Orbstack and re-install version OrbStack_v1.9.0_18721_arm64. it works now.

I'm not sure but after I uninstalled Orbstack and re-install version OrbStack_v1.9.0_18721_arm64. it works now.


Better definition for the route used for links.

Many ways to do this but as of right now the routes are only working some of the time.
Here is an example using model binding into route:
/****************   Model binding into route **************************/
Route::model('call', 'App\Models\Call');
Route::model('category', 'App\Models\Category');
Route::model('city', 'App\Models\City');
Route::model('company', 'App\Models\Company');
Route::model('email', 'App\Models\Email');

Route::pattern('slug', '[a-z0-9-]+');
Route::pattern('slug2', '[a-z_]+');
Route::pattern('id', '[0-9]+');

Add this right into the routes file or a seperate file and include it like you did with api_routes.php
/*
|--------------------------------------------------------------------------

route model binding

*/

require config('infyom.laravel_generator.path.route_model_binding_file');

Like that above shown, also following style:
/posts
/posts/comments
    /*
    * ----------------- Post Routes --------------
    */
    Route::resource("posts", "PostController");
    Route::group(['prefix' => 'posts'], function ()
    {
        /*
        * ----------------- Comment Routes --------------
        */
        Route::resource("comments", "CommentController");
        Route::group(['prefix' => 'comments'], function ()
        {

moving to the second milestone. Because we are going to implement some Exception handler stuff rather than just throwing 404 errors. #130


Channel locked logo everywhere

Plugin:
📜 BetterChannelList
Suggestion:
I don't know is this just with me or for everyone but there are locked channels logos showing to all channels, possible to hide it?

There will be no other way to tell if the channel is limited if this icon is disabled. However you're free to suggest an alternative.

By default there are no lock icons for channels just wanted to see channels as it is

The lock icon is embedded into the icon (on the left side), showing that the channel is restricted.

Ah, so it can't be hidden? i mean the lock icons

Not at the moment, but maybe we can add that as a toggle.

Gotcha Thank you

I may have forgotten about this, feel free to mention me or comment if I do again.

What's shown on the screenshot is expected behavior. Disabling the icons would leave no way of telling the channel properties without accessing its settings, which requires specific permissions on server.
I won't add the toggles to disable them since it will bloat the plugin's settings with no real benefit.
However, if you still want to disable the icons you can add this snippet to your Custom CSS in the BD settings:
/* Hide "Limited" Icon */
.BCL--channel-name-icon:has(path[d~="0v24H48a16"]) {
    display: none;
}

/* Hide "NSFW" Icon */
.BCL--channel-name-icon:has(path[d~="188.09L149.35"]) {
    display: none;
}


error-3

<urlopen error [Errno -3] Temporary failure in name resolution>

Hello,
The issue is lacking detail. Please could you provide more information on what you are doing and what is happening (and what should happen).
Please re-open the issue with it.


Mark the haproxy as critical pod

Flag the haproxy pods providing connectivity to the API server as critical ones.
This should force kubelet and the scheduler to never ever get rid of them. If these pods are killed to make more space for other ones, the node would not be able to talk with the API server making it useless.
More details inside upstream doc.

I tested the change locally and it works, meaning a kubectl describe pod returns all the expected fields.

@flavio Shouldn't we backport this to 2.0?

@inercia - yea, we probably should!


Reduce SQLA connection pool size to 5

Currently, the database is configured to have 25 max connections, with 3 reserved for superuser connections.
Closes #231.

⚠ GitGuardian has uncovered 1 secret following the scan of your pull request.
Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.
🔎 Detected hardcoded secret in your pull request
🛠 Guidelines to remediate hardcoded secrets
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.Our GitHub checks need improvements? Share your feedbacks!

Speaking this into existence just to hear myself say it and to go on record-- this is not a production password, and is associated with a test instance of PostgreSQL that is built locally during development.

Sounds reasonable to make configurable


hls_continuous causes big stream*.m3u8 file

Is there any way to "refresh" the m3u8 file, as it seems to keep growing.

To clarify more, if the stream runs for 10 days the m3u8 file will still have the stream*-0.ts segment. Is it possible the m3u8 file to be cut down to somehow active segments?
Also hls_continuous is off but I thought it was on as the operation is like to be on.


ScalaJS release with cats-effect 2?

Hi, I just wanted to try to use skunk in an scalajs project, running on AWS lambda.
The problem is, that my project is stuck on cats-effect 2, because of other libraries.
I noticed that there are cats-effect 2 versions, like 0.28 but these are not published for ScalaJS yet. Would it be possible to publish such an older version for ScalaJS, or is this version outdated and out of scope?

No, sorry, I'm not maintaining a CE2 branch. You may have better luck upgrading your other dependencies to CE3.

I understand.
Because a transitive dependency is using Monix, which is having it's own problems migrating to CE3:

https://github.com/monix/monix/issues/1502

As an intermediate solution, I'm thinking about forking the last Skunk version using CE2 and cross-compiling it to ScalaJS. Dou you think that's easy to do?

You can try but I think it will not be easy. You'll also have to downgrade fs2 and scodec. You should look at the PR that moved us to CE3 to see what was involved.


Different structures and their performance implications

It might be worthwhile to benchmark the difference in performance for these two structures:
Variation 1:
enum Node {
Leaf(Leaf),
Hashed(Hashed),
Internal(Box),
}
Variation2:
Box<[Option<Box>; YOUR_LEN]>
Variation 2 is closer to what the Golang impl is doing since interfaces are Boxed

This has now gone stale, the method chosen in the end was a sparse representation, which works well with permanent key-value stores


Adds relation fields to objects

fixes #1311
may fix #1112

Current coverage is 92.80%

Merging #1424 into master will not affect coverage as of 1d1122d

@@            master   #1424   diff @@
======================================
  Files           86      86
  Stmts         5449    5460    +11
  Branches      1005    1007     +2
  Methods          0       0
======================================
+ Hit           5057    5067    +10
  Partial         10      10
- Missed         382     383     +1

Review entire Coverage Diff as of 1d1122d

Powered by Codecov. Updated on successful CI builds.


docs: add a new option --hovered to the open command

Documentation for https://github.com/sxyazi/yazi/pull/687

Thanks!


remove pyenv-virtualenv initialization

This removes automatic initialization of pyenv-virtualenv from the zshrc file as it is different for M1 chips. This option will be handled by the Data Setup virtual environment section https://github.com/lewagon/data-setup/blob/m1/_partials/virtualenv.md

closed as we do not have issues with conda anymore


Added FluentUI Slider to chat settings panel for overriding temperature

Purpose

The Chat Settings panel does not provide a way to override the temperature value for requests to the Azure OpenAI completion endpoint. This PR adds a slider to the panel for customizing the temperature. Note that no other changes are required other than UI because the existing code already supports a temperature override value, and the various approaches (located in app/backend/approaches/*) already use it.

Does this introduce a breaking change?

[ ] Yes
[X] No

Pull Request Type
What kind of change does this Pull Request introduce?

[ ] Bugfix
[X] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Documentation content changes
[ ] Other... Please describe:

How to Test

Get the code

git clone [repo-address]
cd [repo-name]
git checkout [branch-name]
npm install

Test the code

What to Check
Verify that the following are valid

...

Other Information

Sorry for the very long delay! I'm going to review this shortly.

I've updated the temperature to 0.3 to match latest changes in main.

Thanks for all your work on this @pamelafox . Should I go ahead and complete this then?

I've approved the PR, just want @mattgotteiner to take a look to make sure he's on board.


Remove bitcount field of the mpf tuple?

Our docs says:

More technically, mpmath represents a floating-point number as a 4-tuple (sign, man, exp, bc) where sign is 0 or 1 (indicating positive vs negative) and the mantissa is nonnegative; bc (bitcount) is the size of the absolute value of the mantissa as measured in bits. Though redundant, keeping a separate sign field and explicitly keeping track of the bitcount significantly speeds up arithmetic (the bitcount, especially, is frequently needed but slow to compute from scratch due to the lack of a Python built-in function for the purpose).

Since CPython 3.1 there is a such function.  It's the int.bit_length() method.
Some timings:
$ python -m timeit -r11 -s 'from mpmath.libmp.libintmath import python_bitcount as bc' 'bc(1000)'
500000 loops, best of 11: 965 nsec per loop
$ python -m timeit -r11 -s 'from mpmath.libmp.libintmath import python_bitcount as bc' 'bc(10)'
500000 loops, best of 11: 930 nsec per loop
$ python -m timeit -r11 -s 'from mpmath.libmp.libintmath import python_bitcount as bc' \
  -s 'from math import factorial;n=factorial(100)' 'bc(n)'
100000 loops, best of 11: 3.18 usec per loop

vs
$ python -m timeit -r11 '(1000).bit_length()'
5000000 loops, best of 11: 75.6 nsec per loop
$ python -m timeit -r11 '(10).bit_length()'
5000000 loops, best of 11: 74.9 nsec per loop
$ python -m timeit -r11 -s 'from math import factorial;n=factorial(100)' 'n.bit_length()'
5000000 loops, best of 11: 97.2 nsec per loop

So, using the bit_length() is clearly better and it's available for all backends.  Does it make sense to keep now the bc field of the mpf tuple or it should be deprecated?

The tricky thing is that the mpf tuple is used as a conversion format in many places so there would still be a need to generate the 4-tuple with bit count often.
Otherwise though I agree that a 3 tuple is better and it can save a lot of wasted arithmetic (and bugs) trying to keep the bit count in sync.

The tricky thing is that the mpf tuple is used as a conversion format in many places so there would still be a need to generate the 4-tuple with bit count often.

The proposed change is obviously not a backward compatible, so we will accept 4-tuples for a while, e.g. in _mpf_ properties.

Otherwise though I agree that a 3 tuple is better and it can save a lot of wasted arithmetic (and bugs)

But maybe we miss some scenarios where "caching" the bitcount has some benefits?  (Same for the sign bit, BTW.)

BTW, simpler format (2-tuple) was planned in #178.  So, I guess Fredrik is ok with this idea.

Currently, we use bc for special numbers (nan, inf, etc), but this seems redundant as well.

It seems, some mpmath users (well, the SymPy of course!) actually do tuple unpacking of mpf's.  I think we should deprecate this in the next release.  from_man_exp/to_man_exp() functions should be used instead.

Ok.  The plan is to deprecate direct manipulations with _mpf_.  People should use from_man_exp()/to_man_exp() functions for finite numbers and dedicated imports for special forms like fnan, fnzero, finf and fninf.  Then, after a release, we could change internal format of the _mpf_.
Unfortunately, we can't emit a warning at runtime.
I'll make a patch for the Diofant to show how it's possible.  It seems, very few places are affected.  I think it's valid to the SymPy as well.

Ok, I guess, there are no fans of the bc field.  That's missing here is a warning in release notes for v1.4, that direct access to mpf tuple is deprecated.


[BUG] Failed to activate the julia-client package: TypeError: Cannot set property 'scrollback' of undefined

Hi,
Atom offered me two updates, which I installed (I think it was julia-cient and ink?). After restarting Atom, I got the error below. This makes Julia unusable with Atom.
Atom: 1.37.0 x64
Electron: 2.0.18
OS: Ubuntu 18.04.2
Thrown From: julia-client package 0.8.6
Stack Trace
Failed to activate the julia-client package
At Cannot set property 'scrollback' of undefined

TypeError: Cannot set property 'scrollback' of undefined
    at /packages/julia-client/lib/runtime/console2.js:191:37
    at /packages/julia-client/lib/runtime/console2.js:199:7
    at Array.forEach (<anonymous>)
    at forEachPane (/packages/julia-client/lib/runtime/console2.js:197:33)
    at updateTerminalSettings (/packages/julia-client/lib/runtime/console2.js:181:3)
    at Config.observeKeyPath (/usr/share/atom/resources/app/static/<embedded>:11:335098)
    at Config.observe (/usr/share/atom/resources/app/static/<embedded>:11:329580)
    at Object.activate (/packages/julia-client/lib/runtime/console2.js:44:24)
    at Object.consumeInk (/packages/julia-client/lib/runtime.coffee:27:15)
    at Object.consumeInk (/packages/julia-client/lib/julia-client.coffee:43:7)
    at Provider.t.exports.Provider.provide (/usr/share/atom/resources/app/static/<embedded>:14:1046092)
    at ServiceHub.t.exports.ServiceHub.consume (/usr/share/atom/resources/app/static/<embedded>:11:3381070)
    at Package.activateServices (/usr/share/atom/resources/app/static/<embedded>:11:3389202)
    at Package.activateNow (/usr/share/atom/resources/app/static/<embedded>:11:3386036)
    at measure (/usr/share/atom/resources/app/static/<embedded>:11:3385360)
    at Package.measure (/usr/share/atom/resources/app/static/<embedded>:11:3382991)
    at activationPromise.activationPromise.Promise (/usr/share/atom/resources/app/static/<embedded>:11:3385220)
    at new Promise (<anonymous>)
    at Package.activate (/usr/share/atom/resources/app/static/<embedded>:11:3385163)
    at PackageManager.activatePackage (/usr/share/atom/resources/app/static/<embedded>:11:382600)
    at config.transactAsync (/usr/share/atom/resources/app/static/<embedded>:11:382216)
    at Config.transactAsync (/usr/share/atom/resources/app/static/<embedded>:11:332386)
    at PackageManager.activatePackages (/usr/share/atom/resources/app/static/<embedded>:11:382166)
    at PackageManager.activate (/usr/share/atom/resources/app/static/<embedded>:11:381784)
    at t.loadState.then (/usr/share/atom/resources/app/static/<embedded>:1:707960)
    at <anonymous>

Commands

Non-Core Packages
indent-detective 0.3.2
ink 0.10.8
julia-client 0.8.6
language-julia 0.18.1
latex-completions 0.3.6
tool-bar 1.1.11
uber-juno 0.2.0

Can you try the installation instructions described here? Namely,
apm uninstall ink
apm uninstall julia-client
apm install ink
apm install julia-client

in a terminal.

Thanks for the quick help. The reinstallation did not help, but reverting to an older version did:
apm uninstall ink
apm uninstall julia-client
apm install ink
apm install<EMAIL_ADDRESS>

What OS and Atom version are you on? I can't reproduce the problem on Windows or Linux.

Nevermind, I think I know what's going on. Will have a fix momentarily.

Can you try again with julia-client 0.8.7 and report back? Thanks!

Ok, I got a report that 0.8.8 indeed fixes this. Closing this.


Question: On the new version 7, is it still supported to have context with World?

I do have this before and able to utilize the CustomWorld that I have created.

world.js

const { BddWorld } = require('playwright-bdd');

class CustomWorld extends BddWorld {
  constructor(options, page) {
    super(options);
    this._context = {};
  }

}

setWorldConstructor(CustomWorld);

Then in my steps, I can set and share the _context values  this._context = {};

When(
  "a valid search request",
  async function ({ page, request }) {
    const tests = new SearchText(page);
    this._context["order_search_response"] =
      await tests.searchAPI.callSearchRequest(
        request,
        this._context["valid_token"],
      );
  }
);

Then(
  "the API  returned all  the search criteria",
  async function ({ page }) {
     const tests = new SearchText(page);

    tests.cartSearchAsserts.assertValidResponseWithSchema(
      this._context["order_search_response"]
    );
  }
);

With the use of context, for each worker that I used, they are unique during run time.

I've noticed that you use mixed steps style: rely on this and pass fixtures as a first argument to step functions. In general, it's better to follow pure Playwright-style or pure Cucumber-style steps. There are more details here https://github.com/vitalets/playwright-bdd/issues/208#issuecomment-2275374050.
If using playwright-style, you can share context between steps by defining _context as a fixture:
import { test as base } from 'playwright-bdd';

export const test = base.extend({
  _context: async ({}, use) => {
    await use({}); // <- _context initialized with empty object
  }
});

Then in steps:
When(
  "a valid search request",
  async function ({ page, request, _context }) { // _context passed as argument
    const tests = new SearchText(page);
    _context["order_search_response"] =
      await tests.searchAPI.callSearchRequest(
        request,
        _context["valid_token"],
      );
  }
);

Or, you can set up full world via fixture, check out this guide.
Alternatively, you can use existing approach. Playwright-bdd provides a fallback for mixed steps style: it always initializes this as empty object, so you can attach _context to it:
When(
  "a valid search request",
  async function ({ page, request }) {
    const tests = new SearchText(page);
    this._context = this._context || {}; // ensure this._context is initialized, because by default `this` is empty object
    this._context["order_search_response"] =
      await tests.searchAPI.callSearchRequest(
        request,
        this._context["valid_token"],
      );
  }
);

In that case, you don't need to define CustomWorld at all.

Thank you @vitalets , I will try all these options. I am keen to have one entry, and initialize this._context = this._context || {}; this once.


[find-db] Invalid GemmBwd records

The issue manifests during test_conv_embed_db. It fails on gfx906/64 (but passes on gfx906/60). The reason is corrupted find-db for gfx906/64/HIP. There are invalid solver names GemmBwd1x1_0_1/2. Valid names are GemmBwd1x1_stride1/2. How this happens (only tips):

HYBRID_DYNAMIC Find mode
Invalid solver id GemmBwd1x1_0_1
Find() falls down to NORMAL Find process
ConvBinWinogradRxSF3x2 is encountered for which we do not have perf-db records

@JehandadKhan This is different issue related to Tuning; this Solver is tunable

The tests sees "perf db record not found" and fails

[Original comment] Both failures happened on ixt-rack-54. Let's just restart but keep an eye on that node.
Originally posted by @atamazov in https://github.com/ROCmSoftwarePlatform/MIOpen/issues/1004#issuecomment-866836255

Corrupted find-databases:

gfx803_36.HIP.fdb.txt
gfx803_36.OpenCL.fdb.txt
gfx803_64.HIP.fdb.txt
gfx803_64.OpenCL.fdb.txt
gfx900_56.OpenCL.fdb.txt
gfx900_64.HIP.fdb.txt
gfx900_64.OpenCL.fdb.txt
gfx906_60.OpenCL.fdb.txt
gfx906_64.HIP.fdb.txt
gfx906_64.OpenCL.fdb.txt
gfx90878.OpenCL.fdb.txt

The issue is originated from #800. I will provide a fix today.

/cc @DrizztDoUrden

@junliume @JehandadKhan Another, implicit reason of the issue is that #972 does not contain updates for all find-databases. The ones that updated by #972 does not have this issue. (I do understand that we didn't have enough time for regeneration of find-dbs for all targets).

@junliume @JehandadKhan Please note that this issue exists in 4.3 release branch as well.


Remove ethereum_ssz dependency

Motivation
Lighthouse is currently migrating our code base and relevant dependencies to alloy_primtives. During the migration we've come across some circular dependency issues between the ethereum_ssz and alloy_primitives crates.

Solution
This PR aims to remove the optional ethereum_ssz dependency as well as the ssz feature flag.
I have an open PR here that implements ssz Decode and Encode for the alloy generic types Bytes and FixedBytes<N> in ethereum_ssz

PR Checklist

[ ] Added Tests
[ ] Added Documentation
[ ] Breaking changes

How about this for a release strategy?

Release ethereum_ssz v0.6 which depends on alloy-primitives 0.7.7
Release alloy-primitives v0.8 which does not depend on ethereum_ssz at all
Release ethereum_ssz v0.7 which depends on alloy-primitives v0.8

We can try to make the timing quite tight between (2) and (3). I will try to get (1) out ASAP.

Sounds good, although I'm not sure if you need (1), but up to you


object not serializable

When I read the rdd from hbase, like
val rddRes = sc.hbase[String](table, columns)
rddRes.collect()

it seems that when I use collect operation, it will raise an org.apache.spark.SparkException.
the error message like this:
org.apache.spark.SparkException: Job aborted due to stage failure: Task 0.0 in stage 4.0 (TID 8) had a not serializable result: scala.collection.immutable.MapLike$$anon$2 Serialization stack:

I think this should be related to this fix. It is a known bug in Scala that a few operations on Map actually return a MapLike, and the latter is not serializable (mapValues being a typical example).
If I recalll correctly, toMap was added in that context exactly for the same issue. Will investigate, it should be more or less the same

It could be a missing toMap here (and in similar places)

Indeed, this issue was only for the case where you define a set of column families
sc.hbase[String](table, Set(...))

In this case we executed a mapValues transformation which returns a MapLike, which is not serializable, instead of a (serializable) Map.


Godot 4.4 throws errors when using await on EditorPlugin

Tested versions

Reproducible: 4.4-dev1 and 4.4-dev7
Not Reproducible: 4.3-stable

System information
Godot v4.4.dev7 - Windows 10 (build 19045) - Multi-window, 1 monitor - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1650 (NVIDIA; <IP_ADDRESS>03) - Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (8 threads)
Issue description
When the editor starts up, calling code from an Autoload to an EditorPlugin with a function that uses while and await will result in either:

Working fine.
Throwing a Bad Address Index error.
Throwing an Internal Script error with opcode 0, 1 or 99.
Crashing to desktop.

Steps to reproduce
The MRP will throw the error when opening the project. If it doesn't, use "Project > Reload Current Project" as sometimes it may simply work.
This problem seems to require a combination of a few situations to happen:

The EditorPlugin must be enabled. The issue vanishes when disabled, even if there are no changes in the script execution.
The function must be called from the Autoloader to the EditorPlugin, if called from inside the EditorPlugin, it works fine.
the EditorPlugin class must be loaded inside the function using load(). Works fine with a preloaded variable on the class scope.
The await must be inside the while loop.

Some background on why I'm running code like this:

To isolate editor access to only inside the EditorPlugin class.
My plugin checks for a resource file, if it doesn't exist, creates the file and updates the FileSystem if it's in editor mode.
After v4.2 or v4.3, the FileSystem takes a while to load and during that time any new files or requests to update are ignored.
I can't use preload() because EditorPlugin classes are not exported to runtime.

Minimal reproduction project (MRP)
project_bad_address.zip

I can reproduce this bug, i got the errors cited in this issue and this one too:
./modules/gdscript/gdscript_vm.cpp:723 - Condition ' op >= Variant::OP_MAX ' is true. Breaking..:
 res://addons/res_plugin/res_editor_plugin.gd:7 - Internal script error! Opcode: 0 (please report).

And when crashed i got this backtrace:
Backtrace
================================================================
CrashHandlerException: Program crashed with signal 11
Engine version: Godot Engine v4.4.dev.custom_build (97ef3c837263099faf02d8ebafd6c77c94d2aaba)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] _gnu_exception_handler (C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:213)
[2] StringName::hash() const (./core/string/string_name.h:140)
[3] HashMapHasherDefault::hash(StringName const&) (./core/templates/hashfuncs.h:314)
[4] HashMap<StringName, MethodBind*, HashMapHasherDefault, HashMapComparatorDefault<StringName>, DefaultTypedAllocator<HashMapElement<StringName, MethodBind*> > >::_hash(StringName const&) const (./core/templates/hash_map.h:85)
[5] HashMap<StringName, MethodBind*, HashMapHasherDefault, HashMapComparatorDefault<StringName>, DefaultTypedAllocator<HashMapElement<StringName, MethodBind*> > >::_lookup_pos(StringName const&, unsigned int&) const (./core/templates/hash_map.h:106)
[6] HashMap<StringName, MethodBind*, HashMapHasherDefault, HashMapComparatorDefault<StringName>, DefaultTypedAllocator<HashMapElement<StringName, MethodBind*> > >::getptr(StringName const&) (./core/templates/hash_map.h:300)
[7] ClassDB::get_method(StringName const&, StringName const&) (./core/object/class_db.cpp:1027)
[8] Object::callp(StringName const&, Variant const**, int, Callable::CallError&) (./core/object/object.cpp:808)
[9] Variant::callp(StringName const&, Variant const**, int, Variant&, Callable::CallError&) (./core/variant/variant_call.cpp:1211)
[10] GDScriptFunction::call(GDScriptInstance*, Variant const**, int, Callable::CallError&, GDScriptFunction::CallState*) (./modules/gdscript/gdscript_vm.cpp:1890)
[11] GDScriptFunctionState::resume(Variant const&) (./modules/gdscript/gdscript_function.cpp:216)
[12] GDScriptFunctionState::_signal_callback(Variant const**, int, Callable::CallError&) (./modules/gdscript/gdscript_function.cpp:166)
[13] MethodBindVarArgTR<GDScriptFunctionState, Variant>::call(Object*, Variant const**, int, Callable::CallError&) const (./core/object/method_bind.h:271)
[14] Object::callp(StringName const&, Variant const**, int, Callable::CallError&) (./core/object/object.cpp:811)
[15] Callable::callp(Variant const**, int, Variant&, Callable::CallError&) const (./core/variant/callable.cpp:69)
[16] CallableCustomBind::call(Variant const**, int, Variant&, Callable::CallError&) const (./core/variant/callable_bind.cpp:152)
[17] Callable::callp(Variant const**, int, Variant&, Callable::CallError&) const (./core/variant/callable.cpp:57)
[18] Object::emit_signalp(StringName const&, Variant const**, int) (./core/object/object.cpp:1198)
[19] Node::emit_signalp(StringName const&, Variant const**, int) (./scene/main/node.cpp:3926)
[20] Error Object::emit_signal<>(StringName const&) (./core/object/object.h:923)
[21] EditorFileSystem::_notification(int) (./editor/editor_file_system.cpp:1569)
[22] EditorFileSystem::_notificationv(int, bool) (./editor/editor_file_system.h:143)
[23] Object::notification(int, bool) (./core/object/object.cpp:873)
[24] SceneTree::_process_group(SceneTree::ProcessGroup*, bool) (./scene/main/scene_tree.cpp:1020)
[25] SceneTree::_process(bool) (./scene/main/scene_tree.cpp:1097)
[26] SceneTree::process(double) (./scene/main/scene_tree.cpp:580)
[27] Main::iteration() (main/main.cpp:4338)
[28] OS_Windows::run() (platform/windows/os_windows.cpp:1772)
[29] widechar_main(int, wchar_t**) (platform/windows/godot_windows.cpp:180)
[30] _main() (platform/windows/godot_windows.cpp:206)
[31] main (platform/windows/godot_windows.cpp:225)
[32] __tmainCRTStartup (C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:267)
[33] WinMainCRTStartup (C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crtexe.c:157)
-- END OF BACKTRACE --
================================================================

The errors are the same (expect for the one i cited) and the backtrace looks similar from this other issue, the way to trigger is different but both needs the await to happen. A difference between these two is the fact this one happens in 4.4 dev 1 too but the other issue only in 4.4 dev 2 too me (the issue author said that happens in 4.3 too but i was unable to reproduce in this version). I'll try to bisect it.

Bisected to #94802, @Hilderin

From the pr content and the fact of the other issue won't be able to trigger in 4.4 dev 1 i don't think this is the root cause, looks like this just make the problem more easier to trigger, but that is for the gd team to judge.
Also i got more errors and a slight different backtrace:
res://addons/res_plugin/res_editor_plugin.gd:7 - Internal script error! Opcode: 6881383 (please report).

res://addons/res_plugin/res_editor_plugin.gd:7 - Internal script error! Opcode: 7078000 (please report).

# With a bit more of effort i'll be able to get a negative opcode by making the int have a overflow :D
res://addons/res_plugin/res_editor_plugin.gd:7 - Internal script error! Opcode:<PHONE_NUMBER> (please report).

C:\Users\Matheus\Downloads\Godot Source\modules/gdscript/gdscript_vm.cpp:1628 - Condition ' constructor_idx < 0 || constructor_idx >= _constructors_count ' is true. Breaking..:
res://addons/res_plugin/res_editor_plugin.gd:7 - Internal script error! Opcode: 32 (please report).

C:\Users\Matheus\Downloads\Godot Source\modules/gdscript/gdscript_vm.cpp:1953 - Condition ' (ip + 3 + instr_arg_count) > _code_size ' is true. Breaking..:
res://addons/res_plugin/res_editor_plugin.gd:7 - Bad address index.

This backtrace was compiling with MSVC, the other from my first commentary was with MinGw, not sure if the compiler make difference because the other issue also has slight different backtraces with the same compiler.
Backtrace
================================================================
CrashHandlerException: Program crashed
Engine version: Godot Engine v4.3.rc.custom_build (b0a8b3a1ef4e2e5b070b89de047b00034bbab82b)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[0] strlen (minkernel\crts\ucrt\src\appcrt\string\amd64\strlen.asm:58)
[1] strlen (minkernel\crts\ucrt\src\appcrt\string\amd64\strlen.asm:58)
[2] String::copy_from (C:\Users\Matheus\Downloads\Godot Source\core\string\ustring.cpp:296)
[3] String::String (C:\Users\Matheus\Downloads\Godot Source\core\string\ustring.cpp:2444)
[4] StringName::operator String (C:\Users\Matheus\Downloads\Godot Source\core\string\string_name.h:144)
[5] GDScriptFunction::call (C:\Users\Matheus\Downloads\Godot Source\modules\gdscript\gdscript_vm.cpp:1794)
[6] GDScriptFunctionState::resume (C:\Users\Matheus\Downloads\Godot Source\modules\gdscript\gdscript_function.cpp:218)
[7] GDScriptFunctionState::_signal_callback (C:\Users\Matheus\Downloads\Godot Source\modules\gdscript\gdscript_function.cpp:166)
[8] MethodBindVarArgTR<GDScriptFunctionState,Variant>::call (C:\Users\Matheus\Downloads\Godot Source\core\object\method_bind.h:271)
[9] Object::callp (C:\Users\Matheus\Downloads\Godot Source\core\object\object.cpp:808)
[10] Callable::callp (C:\Users\Matheus\Downloads\Godot Source\core\variant\callable.cpp:69)
[11] CallableCustomBind::call (C:\Users\Matheus\Downloads\Godot Source\core\variant\callable_bind.cpp:153)
[12] Callable::callp (C:\Users\Matheus\Downloads\Godot Source\core\variant\callable.cpp:58)
[13] Object::emit_signalp (C:\Users\Matheus\Downloads\Godot Source\core\object\object.cpp:1188)
[14] Node::emit_signalp (C:\Users\Matheus\Downloads\Godot Source\scene\main\node.cpp:3896)
[15] Object::emit_signal<> (C:\Users\Matheus\Downloads\Godot Source\core\object\object.h:936)
[16] EditorFileSystem::_notification (C:\Users\Matheus\Downloads\Godot Source\editor\editor_file_system.cpp:1484)
[17] EditorFileSystem::_notificationv (C:\Users\Matheus\Downloads\Godot Source\editor\editor_file_system.h:141)
[18] Object::notification (C:\Users\Matheus\Downloads\Godot Source\core\object\object.cpp:873)
[19] SceneTree::_process_group (C:\Users\Matheus\Downloads\Godot Source\scene\main\scene_tree.cpp:965)
[20] SceneTree::_process (C:\Users\Matheus\Downloads\Godot Source\scene\main\scene_tree.cpp:1042)
[21] SceneTree::process (C:\Users\Matheus\Downloads\Godot Source\scene\main\scene_tree.cpp:528)
[22] Main::iteration (C:\Users\Matheus\Downloads\Godot Source\main\main.cpp:4108)
[23] OS_Windows::run (C:\Users\Matheus\Downloads\Godot Source\platform\windows\os_windows.cpp:1666)
[24] widechar_main (C:\Users\Matheus\Downloads\Godot Source\platform\windows\godot_windows.cpp:181)
[25] _main (C:\Users\Matheus\Downloads\Godot Source\platform\windows\godot_windows.cpp:206)
[26] main (C:\Users\Matheus\Downloads\Godot Source\platform\windows\godot_windows.cpp:220)
[27] WinMain (C:\Users\Matheus\Downloads\Godot Source\platform\windows\godot_windows.cpp:234)
[28] __scrt_common_main_seh (D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
[29] <couldn't map PC to fn name>
-- END OF BACKTRACE --
================================================================


New cast syntax idea

Use the same syntax as declarations, ie a: Foo as a general cast syntax. We could then add sugar to assignment as a: Foo = _. I think this would be nice because it would disambiguate casting from vcalls etc. It would make hashes more ambiguous though and I haven't thought that through yet.
This would mean that a cast in an ambiguous expression would look like (a: Foo), which I think is more readable than Foo(a). Particularly in chains of casts with calls, eg ((a: Foo).bar: Bar) as compared with Bar(Foo(a).bar).
Thoughts?

So foo(c:C) may mean

either "Call method foo(map:Map)." with a HashMap which contains one entry.
or "Call method foo(c:C)." with a parameter which is the value of c?

The optional type annotation on assignments is nice.
Is the space after the colon required?
Does chaining work, such as
b = [3,7,6]:int.map do |i|
  # do something
end

?
If we get the hash-ambiguity worked out and chaining works, then this may be a pretty nice syntax.
I'm not very sure whether type annotation "I expect expression X to have type Y" and type conversion "Whatever type expression X has, I want it to be of type Y" should have the same syntax or not. Maybe this should be kept separate, like the distinction between = and ==, maybe not.

Why replace an ambiguous expression with another? I also think this syntax gets difficult to read as soon as an expression gets more complicated than (a: Foo).
We could make the function call syntax unambiguous if we know the names of all types before inferring method bodies. Is that something worth doing?
Or what about adding a macro to use for all casts? Say 1.as!(float) or float.cast!(1)
(I'm using ! to make sure we don't steal java identifiers).

Why replace an ambiguous expression with another?

I agree.

We could make the function call syntax unambiguous if we know the names of all types before inferring method bodies.

IIRC, method bodies are currently allowed to contain class definitions. Some classes are also created by macros, and these in turn are executed by the typer. It could probably be done

Is that something worth doing?

I guess: no.

Or what about adding a macro to use for all casts? Say 1.as!(float) or float.cast!(1)

I think that's viable, it depends on how common casts are, whether that syntax is already too long. If it is not too long, then we could live with it.
If it is too long, we could provide a dedicated syntax for them, such as
a!String # cast local variable (or result of method call) 'a' as java.lang.String.

or
a~String # cast local variable (or result of method call) 'a' as java.lang.String.

It seems there are not much more characters available on a US keyboard.
Maybe we could also write
a@String # cast local variable (or result of method call) 'a' as java.lang.String.

because the '@' sign is currently only used as prefix operator, not as infix operator. The difference is possible, but thin, as
a @String # call method 'a' with 1 parameter, being the value of the instance variable 'String'

is valid syntax with a different meaning.

I also like postfix notation. What about # sign to use for casts or local variable type hints:
a#String = nil
b = 1#Integer
hash = foo(b#Number)#Cloneable.clone#Hashtable

Could replace # with any valid postfix sign mentioned above [~!].
I like the #.

Maybe we can put the genie back in the bottle regarding the hash entry syntax:
We define

"Identifier COLON WhiteSpace+ Identifier" as hash entry syntax while we define
"Identifier WhiteSpace* COLON Identifier" as type annotation syntax

To obtain a hash entry, write at least one whitespace character after the colon.
To obtain a type annotation, write no whitespace after the colon.
So
a:String = nil
b = 1:Integer
hash = foo(b:Number):Cloneable.clone:Hashtable

would be possible and thus

foo(c: C) means "Call method foo(map:Map)." with a HashMap which contains one entry, while
foo(c:C) means "Call method foo(c:C)." with a parameter which is the value of c, type-annotated (and thus casted to) type C.

Like it. Plan to implement this week.

Awesome! Looking forward to seeing the patch.

Stuck a bit with a couple of issues

The first is an attr_xxx issue.
attr_xxx macro expects Hash as a parameter, so one have to write additional space when new syntax implemented:

attr_accessor x: int, b: String

It raises the question "what to do with 'legacy' code"
I tend to reformat mirah compiler code to new syntax requirements. I guess there is not  that plenty of code written in mirah  so it's acceptable from my point.
I particular do not want to rewrite attr_xxx macro to accept NodeList<Cast,VCall>

the second issue is an  old cast notation via function call:

str = String(object)

I'd like to remove support for this from typer.mirah without any backward compatibility having the same rationale in mind - 'not that plenty of mirah code'.
I plan to go as described above unless there are better ideas.

Using spaces in attr_xxx seems inconsistent now.  Can we change attr_xxx to take a variadic list of Casts?

It have to accept both a hash and a nodellist of casts accept notations:
attr_accessor a:int, b:int # NodeList of Casts
attr_accessor a: int, b: int # Hash

If we select only one variant - why shouldn't it the Hash?

Created pull request with proposed feature. Please review.

Using spaces in attr_xxx seems inconsistent now.

I have to agree.
After some weeks, I do not like to require a space after the colon of attr_accessor and friends and any other instance of a Hash literal, as in:
-  attr_reader context:Context
+  attr_reader context: Context

This creates bloat, reduces Ruby syntax compatibility and creates visual ambiguity between casting and Hash syntax. Having an easily accessible Cast syntax is important, but having an easily accessible Hash syntax is more important.
I'm sorry for this being based on an idea I wrote.
Could we use another character for casts, such as ~ TILDE? This character is currently only used as unary prefix operation, not used as a binary infix operation currently, AFAIK, so introduction of a binary infix TILDE operation would be compatible with existing Mirah code and would not create any syntactic incompatibility with exiting Ruby code.
@uujava, I hope you still agree with a ~ TILDE character

Could replace # with any valid postfix sign mentioned above [~!@].

I still like the postfix notation.

Now I think that any sign would we take for cast it will have some issues. Colon was good idea as it's used in method declarations. Having space for hash is lesser evil than introducing new delimiter for type hints. There is not that much compatibility with ruby in mirah anyway.
Technically It's not the problem to use other delimiters, but semantically colon do looks nicer and typed on keyboard faster than other symbol.
I'd listen to the language designers -

Personally I like colon since that's what we use in method definitions. But
I think we should be consistent. If there's no space in casts there should
be no space in methods or attr calls.
Or maybe we should just ditch colons for maps and go back to =>
That would remove the ambiguity.
On Mon, Mar 28, 2016, 12:12 AM uujava<EMAIL_ADDRESS>wrote:

Now I think that any sign would we take for cast it will have some issues.
Colon was good idea as it's used in method declarations. Having space for
hash is lesser evil than introducing new delimiter for type hints. There is
not that much compatibility with ruby in mirah anyway.
Technically It's not the problem to use other delimiters, but semantically
colon do looks nicer and typed on keyboard faster than other symbol.
I'd listen to the language designers -
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/mirah/mirah/issues/428#issuecomment-202252635

Survey on casting operators
Here is a small survey on operators for casting to a subtype of a type of an expression in different languages.
Ruby, Python, JavaScript, R:

not applicable

C, Objective-C, C++, Java, C#:
(NewType) expression

Go:
NewType(expression)

Delphi:
expression AS NewType

Rust:
expression as NewType

Swift:
expression as! NewType

Scala:
expression.asInstanceOf[NewType]

Groovy:
(NewType) expression
expression as NewType
expression.asType(NewType)

Visual Basic:
CType(expression,NewType)

Matlab:
typecast(expression,NewType)

D:
cast(NewType)expression

PL/SQL:
CAST(expression AS NewType)

Mirah suggestion 1:
expression.as(NewType)
expression~NewType

Mirah suggestion 2 (see below):
expression.as(NewType)
expression:!NewType

Availability of a casting macro
Note that regardless of the outcome of the discussion of the casting operator, we can always have a casting macro, such as Object#as or Object#cast. So the question here is not whether we will have an alternative to the current casting syntax, but given we have an alternative to the current casting syntax, how can we have a shorthand notation in addition to an elaborate notation. Thus, the purpose of the discussion should be the resolution of the question "How can we have a language which allows for concise code?". Hence, the evaluation of the arguments should put weight on whether having one specific shorthand notation makes another specific shorthand notation unavailable, and thus possibly defeats its purpose.
Ambiguity with colons
Note that using colons as a casting operator may create another ambiguity:
a?foo:bar:baz

Is this
a ? foo.as(bar) : baz

or
a ? foo : bar.as(baz)

?
Difference between type annotation and casting
I'd like to point out that there is a difference between type annotation and casting:

A type annotation is a hint to the compiler. A type annotation cannot fail at runtime. Currently, no expression can have a type annotation, but method parameters can have a type annotation.
A cast is an instruction to the compiler to emit a checkcast bytecode instruction, not a mere hint. A cast can fail at runtime. Each expression can have a cast (yielding a new expression), but method parameters cannot have a cast.

So they are superficially similar (in both cases, they have something to do with types), but quite different under the hood.
Colon Bang
If type annotations are hints while casts are instructions, and the TILDE ~ is not liked, maybe we can have a compromise regarding the syntax of a casting operator: COLON BANG :!, as in
a:String = nil # variable is annotated
b = 1:!Integer # 1 is casted
hash = foo(b:!Number):!Cloneable.clone:!HashMap

The BANG ! character of COLON BANG :! symbolizes

that this is an instruction and not merely a hint,
that performing the instruction can fail (with a ClassCastException), and
that the programmer believes to know better than the compiler.

The COLON : character of COLON BANG :! symbolizes that it still has to do something with types.
Multi-character operators are not so uncommon, we already have some, such as ==, !=, <=, >=, =>, **, ||, &&, ===, <<, >>, ::.
Summary
So we have currently these options for a casting operator:

Casting with the TILDE ~     operator:

attr_accessor foo:Foo
attr_accessor bar:Bar
# ...
def baz(foo:Foo,bar:Bar):String; end
# ...
hash = foo(b~Number,c:d,e:f)~Cloneable.clone~HashMap`

Casting with the COLON BANG :! operator:

attr_accessor foo:Foo
attr_accessor bar:Bar
# ...
def baz(foo:Foo,bar:Bar):String; end
# ...
hash = foo(b:!Number,c:d,e:f):!Cloneable.clone:!HashMap`

Casting with the COLON :     operator but spaces are required at every attr_accessor and every other occurrence of HashEntry nodes:

attr_accessor foo: Foo
attr_accessor bar: Bar
# ...
def baz(foo: Foo,bar: Bar):String; end
# ...
hash = foo(b:Number,c: d,e: f):Cloneable.clone:HashMap`

I'd prefer 1 over 2, and 2 over 3.
Please state your preferences.

Prefer #3, with a bit of comments.

spaces are actually not required in method definitions. Parser handle it well:

def baz(foo:Foo, bar: Bar): String;end

Why should we forbid this flexibility?

attr_xxx are merely a macro, not the part of the language syntax. They could be enhanced to support colon without spaces, but mixed case:

attr_accessor x: int, y:String

is a bit awkward to implement.

code like:

foo(b:Number,c: d,e: f)

does look confusing.
Good style would be to write:
foo(b:Number, {c: d,e: f})

but if one like to have option above for some DSL, why not?

I guess colon hash notation with or without spaces could be implemented in parser for curly braces Hash (require some polishing in parser mmeta):

x = {a:B, x:value:String.getLength, c: 123}

So the only actual issue is the hash without curly braces
#2 actually clashes with:
foo a:!b # Hash with negate operator or cast?

#1 clashes with bitwize complement operator, note that it could be overridden:
class A
 def ~(foo:Object):int
    "#{@value}_#{foo}"
 end
end
a = A.new
b = "suffix"
puts a~b

After playing with it, I'm going with as! as a macro, and deprecating / removing the call cast. I might revisit after I get to generics syntax, since that will be touching the syntactical representation of types.

Yay! We have a decision and we can remove call-style casting syntax, fix a host of language ambiguities and thus also increase compiler speed. :-)
It is right to call this not 0.1 anymore but 0.2 due to the syntax change (and thus necessary syntax incompatibility).
If there was a lot of legacy Mirah code, we could make a special Mirah 0.1 compiler which determines which Call node was indeed a Cast node and emits a Mirah 0.2 compatible source code, to aid automatic transition to Mirah 0.2. However, given the current apparent popularity of Mirah, creating a transpiler might not be worthwhile due to the lack of a mount of legacy code (but I may be wrong).

Working on it. :)
as! is nice for a reason I'm just now feeling. It is a whole bunch easier
to search for.
On Aug 6, 2016 3:38 PM, "Felix von Ferey"<EMAIL_ADDRESS>wrote:
Yay! We have a decision and we can remove call-style casting syntax, fix a
host of language ambiguities and thus also increase compiler speed. :-)
It is right to call this not 0.1 anymore but 0.2 due to the syntax change
(and thus necessary syntax incompatibility).
If there was a lot of legacy Mirah code, we could make a special Mirah 0.1
compiler which determines which Call node was indeed a Cast node and emits
a Mirah 0.2 compatible source code, to aid automatic transition to Mirah
0.2. However, given the current apparent popularity of Mirah, creating a
transpiler might not be worthwhile due to the lack of a mount of legacy
code (but I may be wrong).
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/mirah/mirah/issues/428#issuecomment-238052716, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAc0tGoIV5AEO6dIh6ke2mi2HYHwcHGks5qdQz8gaJpZM4Hko8q
.

Also, I released 0.2 earlier today. I figured since we've got on the order
of ~500 commits in this release, bumping the minor version is reasonable.
I'm posting the announcement later this evening.
I'm working on some bugs that might lead to a 0.2.1 sooner than later. The
meta circular test didn't cover the parser, and it can't compile with 0.2.
shrugs
On Aug 6, 2016 4:08 PM, "Nick Howard"<EMAIL_ADDRESS>wrote:

Working on it. :)
as! is nice for a reason I'm just now feeling. It is a whole bunch easier
to search for.
On Aug 6, 2016 3:38 PM, "Felix von Ferey"<EMAIL_ADDRESS>wrote:
Yay! We have a decision and we can remove call-style casting syntax, fix a
host of language ambiguities and thus also increase compiler speed. :-)
It is right to call this not 0.1 anymore but 0.2 due to the syntax change
(and thus necessary syntax incompatibility).
If there was a lot of legacy Mirah code, we could make a special Mirah 0.1
compiler which determines which Call node was indeed a Cast node and emits
a Mirah 0.2 compatible source code, to aid automatic transition to Mirah
0.2. However, given the current apparent popularity of Mirah, creating a
transpiler might not be worthwhile due to the lack of a mount of legacy
code (but I may be wrong).
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/mirah/mirah/issues/428#issuecomment-238052716, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAc0tGoIV5AEO6dIh6ke2mi2HYHwcHGks5qdQz8gaJpZM4Hko8q
.

baroquebobcat,
As I could understand the decision for a.as!(Type) macro over a:Type approach wase mainly due to your vision for generic support  in mirah. Could you please shed some light on this a bit.
Thank you in advance.

How about a%b templetes syntax? AFAIK it never used yet.

Lets admit that mirah won't have great tooling any time soon. So it's better reuse those of ruby.
I think mirah should stick with ruby syntax.
Consider following code
	attr_reader a % Foo
	attr_reader b % Bar
	def foo(a, b)
		a % Foo; b % Bar

		[1,2].each do |it|
			it % MyClass
			it.my_method
		end

	end % Baz

Intellij IDEA does not highlight any line as error and allows to do many useful things such as rename vars, move vars and methods, etc
I believe the same would be in any other ruby IDE


How to add angularjs directive to the tree node

Hi Vakata,
I am trying to add angular directive to the tree nodes so that the node value should be validated against regular expression while adding or editing a node.
Thanks & Regards,
Pradip

I do not support any jstree angular directives - you can try and use any of the third party ones and check if they support what you need.


prometheus: add support for prometheus.io/scheme #22628

What does this PR do?
Resolve conflicts of the external contribution #22628
Motivation
Fixes DataDog/integrations-core#16751
Additional Notes
While this PR adds support for the prometheus.io/scheme: https annotation, I cannot see any mechanism to pass custom TLS certificates.
So, this may be useful only if either the scraped service uses certificates signed by well known CA or if the agent skips certificate validity check.
Possible Drawbacks / Trade-offs
Describe how to test/QA your changes
Prometheus auto-discovery is covered by e2e tests: https://github.com/DataDog/test-infra-definitions/blob/c757089e5a234e488358c0b7a140485e259e1dca/components/datadog/apps/prometheus/k8s.go#L56 & https://github.com/DataDog/datadog-agent/blob/ac52d6cd7b01739f4846da3fc7962ed0ad88f19f/test/new-e2e/tests/containers/k8s_test.go#L680

/merge


Only {snackF0,praatF0,shrF0,reaperF0,snackFormants,praatFormants,SHR} in opensauce

Excuses me,
It is so lucky that I can found this project,
But this is not finished?
Only support {snackF0,praatF0,shrF0,reaperF0,snackFormants,praatFormants,SHR} now?
And https://github.com/voicesauce/opensauce-python/tree/master/legacy is the old one with more function?
Thank you.

The legacy folder is old code that doesn't work. The project is still under development and not finished. If the function is listed in the command line help, then it is supported. If not, then it is not supported.


Use asserts to make a nicely readable test suite

Fixes #15.

Not worth proceeding on this now and the code has diverged quite a bit.


psubscribe patterns not working correctly?

I'm trying to publish status messages for each process that gets forked within a script. Each channel is named as status_ followed by some unique identifier, job_id. So I was hoping to use psubscribe to subscribe to all channels matching the pattern status_*, but I'm having trouble doing so. It seems to work OK if I replace the call to redis.psubscribe with a regular redis.subscribe and hard-code the correct channel name, but that defeats the purpose.
redis.psubscribe('status_*', function(error, count){})
redis.on('message', function (channel, message) {
  console.log('Received message \'%s\' from channel \'%s\'', message, channel);
});

Then, on another script, I publish a message to the channel
  var channel = 'status_' + job_id;
  redis.subscribe(channel, function(error, count){
    pub.publish(channel, someMessage);
  });

When you psubscribe, the messages are returned with three paterns - channel, pattern, and message.
redis.psubscribe('status_*', function(error, count){})
redis.on('message', function (channel, pattern, message) {
  console.log('Received message \'%s\' from channel \'%s\'', message, channel);
});

@klinquist, good catch! But alas, the 'message' event isn't even firing

@saschaishikawa  Oh yes, one more thing... when you psubscribe, you need to watch for pmessage instead of message.
redis.on('pmessage', function(channel, pattern, message) {});
:)

:facepalm: That takes care of it. Thank you very much for your help and contribution to ioredis. It's been very useful. :) Closing issue now.

if everyone comes after the order has changed: sub.on('pmessage', (pattern, channel, message) => {})


error when importing DaskGeoDataFrame

Due to the Dask release v2021.05.1, PR https://github.com/dask/dask/pull/7503, the DaskGeoDataFrame importing was broken.

Only the make_meta and meta_nonempty functions were moved to the dispatch module, make_array_nonempty were not being imported directly from the source module.
Probably the previous spatialpandas releases will have the same problem.

Please see this comment ( https://github.com/dask/dask/pull/7503#issuecomment-852084344 )

Might be relevant: This is how dask-geopandas has dealt with the change: https://github.com/geopandas/dask-geopandas/pull/47

Hey @philippjfr / @jonmmease, are you following the discussions on conda-envs repo and the new PR on the Dask repo?

Yes it would be great to have your feedback. Want to figure out the right way forward. PR ( https://github.com/dask/dask/pull/7743 ) is the relevant

Yeah, definitely let us know if you have any feedback on that PR. We're planning to release in the next couple of days and want to make sure we include fixes for any issues you're running into.

Just a heads up that https://github.com/dask/dask/pull/7743 has been merged into dask. This should hopefully resolve any issues that popped up with the 2021.05.1 release. We're planning a release tomorrow which will include the fix in https://github.com/dask/dask/pull/7743. Let us know if there are any lingering issues for spatialpandas

Thanks for all the updates here. I guess I'm somewhat unclear on any actions we should take? As far as I understand this will now be fixed in new versions of dask. So the only real actions we could take is update the repodata in defaults and conda-forge to exclude the affected versions. Am I misunderstanding and is that even worth doing?

You could definitely update package repodata (or just say "2021.05.1 was a bad release, don't use it"). Additionally, if you get a moment to run the spatialpandas test suite against the main branch of dask it would be great to see whether or not any changes need to be made in spatialpandas to add support the upcoming dask release (we moved a new objects around, so we may need to change some imports)

Thanks, everyone, for the suggestions. I'm trying to release Datashader but I'm stymied by SpatialPandas being broken, which breaks Datashader's tests. I've tried to follow the discussion and suggestions here and in https://github.com/dask/dask/pull/7503 and https://github.com/dask/dask/pull/7743, but it's a complete nightmare!
To simplify things, let's accept @jrbourbeau's suggestion that "dask 2021.05.1 was a bad release, don't use it", i.e., let's assume no support for 202105.1. Having done so, neither our original code nor the code in PR #69 will work, though, because the original one imports from utils, no longer valid in 5.x, while #69 imports from dispatch, which wasn't present in 5.x. The old code:
$ python -c 'import dask; print(dask.__version__); from dask.dataframe.utils import make_meta, meta_nonempty, make_array_nonempty'
2021.05.0
$ python -c 'import dask; print(dask.__version__); from dask.dataframe.utils import make_meta, meta_nonempty, make_array_nonempty'
2021.05.1
ImportError: cannot import name 'make_array_nonempty' from 'dask.dataframe.utils' (/Users/jbednar/dask/dask/dataframe/utils.py)
$ python -c 'import dask; print(dask.__version__); from dask.dataframe.utils import make_meta, meta_nonempty, make_array_nonempty'
2021.06.0
ImportError: cannot import name 'make_array_nonempty' from 'dask.dataframe.utils' (/Users/jbednar/dask/dask/dataframe/utils.py)

Code from PR #69:
$ python -c 'import dask; print(dask.__version__); from dask.dataframe.dispatch import make_meta, meta_nonempty ; from dask.dataframe.extensions import make_array_nonempty'
2021.05.0
ModuleNotFoundError: No module named 'dask.dataframe.dispatch'
$ python -c 'import dask; print(dask.__version__); from dask.dataframe.dispatch import make_meta, meta_nonempty ; from dask.dataframe.extensions import make_array_nonempty'
2021.05.1
$ python -c 'import dask; print(dask.__version__); from dask.dataframe.dispatch import make_meta, meta_nonempty ; from dask.dataframe.extensions import make_array_nonempty'
2021.06.0

I'm pretty sure there is no other place these utilities were available that is valid both for 5.0 and 6.0. Ok, fine, we can put in a try/except, first looking in dispatch, and falling back to utils, which will presumably fix the import issues on at least 5.0 and 6.0. It's ugly that that's the only apparent solution, but fine.
What I really can't tell is whether that is sufficient, from the discussion here and in PR https://github.com/geopandas/dask-geopandas/pull/50/files replacing make_meta with make_meta_dispatch, PR https://github.com/rapidsai/cudf/pull/8368/files replacing make_meta_obj with make_meta and make_meta_util with make_meta , and comment https://github.com/dask/dask/pull/7503#issuecomment-852084344 suggesting replacing make_meta with make_meta_util. How are any of these utilities meant to be used?
@jsignell, it looks like your changes in https://github.com/dask/dask/pull/7503 were the original stirring of this hornet's nest, so could you perhaps weigh in with what you think the downstream libraries like cudf, dask-geopandas, and spatialpandas are supposed to do for compatibility with dask<=5.0 and dask>=6.0?

Yeah there were two big shuffles centering on make_meta_* and it was definitely unfortunate that they landed in the same release. I see that @jrbourbeau has opened a compatibility PR - sorry for the pain.

Thanks! As long as you and he agree that his proposed changes are good, I'm happy! :-)


latest tag points to version 0.1.0

Currently the examples do use image eu.gcr.io/gardener-project/gardener/terraformer:latest. However the latest tag points to version 0.1.0:
$ docker pull eu.gcr.io/gardener-project/gardener/terraformer:latest
latest: Pulling from gardener-project/gardener/terraformer
2fdfe1cd78c2: Pull complete
64917b29220a: Pull complete
2efdbc9a8eb4: Pull complete
c128a0d07fe2: Pull complete
Digest: sha256:4a67f524447498c59cf48696362f2d271d29f7e469b83c77a561f2b1d149bb66
Status: Downloaded newer image for eu.gcr.io/gardener-project/gardener/terraformer:latest
eu.gcr.io/gardener-project/gardener/terraformer:latest

$ docker images | grep terraformer | grep latest
eu.gcr.io/gardener-project/gardener/terraformer   latest       18688c3ead10        21 months ago
   241MB

I would expect the latest tag to point to the latest release - 0.16.0 by the time of writing this.

@gardener/ci-maintainers, @rfranzke how we can fix this such as when a new release is cut, the latest tag to point to it?
Also can we move now the latest tag to point to 0.16.0?

Also manually edited the latest to be 0.16.0 in gcr.io.


GeoJson points in GeoJsonLayer over the 180th meridian doesn't show

In a GeoJson Feature collection of points, if you have points that cross the 180th meridian from the current viewport, they aren't shown.
Actual Result
For example, if you have a GeoJSON feature collection with two points, [170, -35] and [-170, -35], then you can only see one of them based on which side of the 180th meridian your viewport is on. In the example repo, this is the two maps on the left.
This can be mitigated by for each point adding another point that is +/- 360 (based on what side you need it on), so you end up with points: [170, -35], [-190, -35], [-170, -35], [190, -35]. Unfortunately with a real-time dataset of my size, this adds a lot of strain to the processing and memory of the app and is not feasible. In the example repo, this is the two maps on the right.
Expected Result
That all feature collection points are visible when inside the viewport, whether they are across the 180th meridian or not.
Reproduce Steps
Create a DeckGL GeoJsonLayer with a feature collection like so:
{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {},
      "geometry": {
        "type": "Point",
        "coordinates": [
          -170.5078125,
          -42.81152174509788
        ]
      }
    },
    {
      "type": "Feature",
      "properties": {},
      "geometry": {
        "type": "Point",
        "coordinates": [
          175.78125,
          -41.244772343082076
        ]
      }
    }
  ]
}

Pan the map from -35, 170 to -35, -170 and one of the points will disappear and one will appear. Pan back and they will swap.
Code Example
Running example: The Actual Result are the left two maps, the desired result (achieved via a means I can't use in production) are the right two
The GitHub repo for the code

+1, This is annoying when working with data around Australia / New Zealand


WIP - Kill any orphaned tests

Signed-off-by: Scott Hain<EMAIL_ADDRESS>Description
[Please describe what this change achieves]
Issues Resolved
[List any existing issues this PR resolves, or any Discourse or
StackOverflow discussion that's relevant]
Check List

[ ] New functionality includes tests
[ ] All tests pass
[ ] RELEASE_NOTES.md, has been updated if required (not required for bugfixes, required for API changes)
[ ] All commits have been signed-off for the Developer Certificate of Origin. See https://github.com/chef/chef/blob/master/CONTRIBUTING.md#developer-certification-of-origin-dco

@chef/jex-team

@scotthain sysv-vs-bsd ps options, or is that the point of the || true that its more important on linuxen and you don't care about slowaris?

@lamont-granquist the point of the || true is it will exit non-0 if there are no leftovers (and kill has nothing to kill). This is just to ensure that it continues on the happy path.

so....   ps -ef?

well okay then, everyone has gotten on the bsd ship...


chore: update rust toolchain

how's this only changing flake lock not the flake?

how's this only changing flake lock not the flake?

fenix input is not pinned to rev, so I just nix flake lock --update-input fenix and that updates the pinned version in the lock file, job done.


feat: add support for math code blocks

Merged in https://github.com/thde/hugo-profile/compare/gurusabarish%3Ahugo-profile%3Amaster...master


Draggable scrollbar "free mode"

Clear and concise description of the problem
I'm not sure if this is already possible, but I'm trying to find a way to make the scrollbar drag "freely", without having to lock to the position of the slides.
At the moment, you need to drag the scrollbar until it reaches a certain position, in order for it to snap to the next state.
Here is an example of a site doing what I need:
https://www.dwr.com (the slider under the "Take living to the next level" heading)
This example uses Swiper, but I'm not sure how they have done it.
Suggested solution
Is this already possible? If not, I think it would be a good feature.
Alternative
No response
Additional context
No response
Validations

[X] Follow our Code of Conduct
[x] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Would you like to open a PR for this feature?

[ ] I'm willing to open a PR

Hey @nolimits4web
Thanks for the quick response
Does this apply to dragging the scrollbar though?
I have tried lots of options and can't find anything for this


IlcDisableReflection = Connection Error

When compiling with MSBuild attribute <IlcDisableReflection>true</IlcDisableReflection>, RtspClient cannot connect to a stream. Otherwise it works great. I'm attaching a relevant portion of the stack trace but you know, it is very much crippled since IlcDisableReflection is true.
RtspClientSharp's version: 1.3.3

Stack trace
Unhandled Exception: MT140699988240528: Connection error
 ---> MT140699988350928: End of rtsp stream
   at RtspClientSharp.Rtsp.RtspTransportClient.<ReadUntilEndOfHeadersAsync>d__16.MoveNext() + 0xfd
--- End of stack trace from previous location ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
   at RtspClientSharp.Rtsp.RtspTransportClient.<GetResponseAsync>d__15.MoveNext() + 0xda
--- End of stack trace from previous location ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
   at RtspClientSharp.Rtsp.RtspTransportClient.<ExecuteRequest>d__9.MoveNext() + 0x20c
--- End of stack trace from previous location ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
   at RtspClientSharp.Rtsp.RtspClientInternal.<ConnectAsync>d__18.MoveNext() + 0x21f
--- End of stack trace from previous location ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
   at RtspClientSharp.RtspClient.<>c__DisplayClass13_0.<<ConnectAsync>b__0>d.MoveNext() + 0x479
   Exception_EndOfInnerExceptionStack
   at RtspClientSharp.RtspClient.<>c__DisplayClass13_0.<<ConnectAsync>b__0>d.MoveNext() + 0x6c5
--- End of stack trace from previous location ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
   at RtspClientSharp.RtspClient.<ConnectAsync>d__13.MoveNext() + 0x127

To Reproduce
If you want a repro, create a console application, add <IlcDisableReflection>true</IlcDisableReflection> to your .csproj file, make an async call to RtspClientSharp.ConnectAsync. Compile it then to native code (<PublishAot>true</PublishAot> and dotnet publish on .NET 8.0+ will do the trick) and run. Otherwise you won't be able to see this error.

IlcDisableReflection is not supported and it can cause many components not working as expected.

@hez2010 why do you think the reflection use is required within this library? Note that type checks like
if (e is RawH264IFrame intraFrame)
{
    //...
}

are still allowed in reflection-free mode. I would suggest a minor research and refactoring that will find and remove any reflection use. This can also lead to a minor performance increase.


Smart quotes not getting encoded properly

This seems to be happening since I updated to 1.4.10. I haven't made any changes to my feed or the blog engine that drives it. FeedMe seems to be creating duplicate copies of my entries with the smart quotes encoded improperly. (â instead of ’)
My feed is set to "Update Entries" on Duplicate Entry Action, and I have "Check for duplicate" checked on both title and link. So for now, entries with smart quotes are created as duplicates rather than updating the original.
Here's my feed if you need it for testing: http://uxcellence.com/rss/
And here's a screenshot showing the entries as they appear on my list.

If you could, would you be able to give the latest master a go? Just to be on the safe side.

I've just installed the latest master. I deleted the duplicates with the incorrect encoding and reran the task for that feed, and it seems to be working properly now.

Hello, I was facing the same problem since the last update. It also looks good to me with the latest master. Thank you.

@slelorrain Great, thanks for letting me know, and apologies for the issues to you both.


Skeleton added #353

Solves the Issue #353

It would be nice, if you added screenshots depicting the change

if updated the r description to link the issue

I have Attached the Screen recording Please have a look
https://user-images.githubusercontent.com/48324492/135596312-d475ce33-a762-44de-984e-30b93141cc95.mov

@krishguptadev I have made the changes that you suggested


feat(tutorial): complete step 1

Closes #
{{short description}}
Changelog
New

{{new thing}}

Changed

{{change thing}}

Removed

{{removed thing}}

There is no code to review in your PR.
Please see instructions and try again:
https://www.carbondesignsystem.com/tutorial/react-step-1


Stop war in Ukraine

While Ukraine is under missile attacks GitHub could be used by Russians to develop apps and platforms aiming to destabilize Ukrainian web resources.
Please, prevent these actions and don't stay on the same side with invaders! All information about war can be found at:  https://war.ukraine.ua/
We urge you to close GitHub for Russia and its developers! We value your support and we are in need for your actions!

Not speaking on behalf of GitHub itself here, but they've released a blog post explaining their stance. Others across GitHub's public repos have summarized this to you.
While my thoughts are with you in this difficult time, I'll be closing this issue as it isn't directly linked to the ViewComponent project, and I'd advise against opening similar issues of this kind in public GitHub repositories.


Some create_benchmark.py script enhancements.

This patch addresses some trials and tribulations I encountered in (#71786). It:

fixes the auto-registration regex
fixes the auto-generated array's name
generates the current year for the license header
generates some dashes for the license header

Short how-to per README.md
swift-source$ ./swift/benchmark/scripts/create_benchmark.py YourTestNameHere

@swift-ci please smoke test

Looks like Flake8 holds it at linterpoint. I've paid the ransom*.
*I downloaded PyCharm and asked it to refactor the parts I wrote.

@swift-ci please smoke test

@glessard can you ask @swift-ci to test it again? I doubt the failure on Windows has anything to do with this PR.

I didn't realize it hadn't gone through!

@swift-ci please test windows platform


Errors when car is sleeping

Howdy!
When the car is asleep, the exporter will error because it's trying to take action on None or NoneType
Example Error:
Traceback (most recent call last):
  File "/home/jstelmach/teslafi/teslafi_exporter/exporter.py", line 1029, in <module>
    TESLAFI_COLLECTOR = TeslaFiCollector(teslafi_api_token)
  File "/home/jstelmach/teslafi/teslafi_exporter/exporter.py", line 32, in __init__
    registry.register(self)
  File "/usr/local/lib/python3.8/dist-packages/prometheus_client/registry.py", line 40, in register
    names = self._get_names(collector)
  File "/usr/local/lib/python3.8/dist-packages/prometheus_client/registry.py", line 80, in _get_names
    for metric in desc_func():
  File "/home/jstelmach/teslafi/teslafi_exporter/exporter.py", line 158, in collect
    value=float(self.getSetData(teslafi_data, teslafi_data_old, "odometer"))*1609.344)
TypeError: float() argument must be a string or a number, not 'NoneType'

Is this expected or by design? If not, should we add error checking to see if the value exists then exit gracefully?
Thanks!

I noticed the TODO for error handling, my apologies.
Is there any preferred way to handle the error? I can take a shot at it if you'd like.


feat(planning_test_utils): add off-track test for path and trajectory

Description
Add util functions to check the node will not die when the ego-vehicle pose is located far from the target trajectory.
Related links
None
Tests performed
None. (tested in each package)
Notes for reviewers

Interface changes
None
Effects on system behavior

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR follows the pull request guidelines.
[ ] The PR has been properly tested.
[ ] The PR has been reviewed by the code owners.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

test success with following command
colcon test --event-handlers console_cohesion+ --packages-select behavior_path_planner planning_validator motion_velocity_smoother motion_velocity_smoother obstacle_stop_planner obstacle_stop_planner obstacle_stop_planner freespace_planner


Remove prompt to select a wallet when there's one wallet

During delegate-to-stake-pool wizard, there is a step where user is asked to pick a wallet - if there is only one wallet that is capable of delegation (Shelley currently), the UX is not particularly pleasant as the step should be redundant / skipped.

@hodlonaut that step is actually required as when you confirm that wallet's selection, the stake pools are refreshed to reflect the case of you delegating to that very wallet (and seeing corresponding potential rewards, rankings, etc.).
Even though I understand where you are coming from, I don't think skipping that step would be good. Especially since that dialog has all steps displayed on top. I believe it would confuse a lot of users if they would go directly to step 2 after being on the info step first.

Perhaps you can ask users about it during your next Daedalus survey.

Perhaps I was misunderstood...
Your feedback is welcome and valuable! 🙂
We have an established process for constant UI/UX improvements, led by Daedalus product & design team, which involves reaching out to Daedalus users too.
Your proposal has already been put on the list for discussion and I will keep you updated on the outcome.
Thank you for your patience!


Add docstring for Utf8Path::try_from

This docstring is modeled after Utf8Path::from_path. The example demonstrates the <&Utf8Path>::try_from syntax required to use this method.
Also added a link to the TryFrom impl in Utf8Path::from_path's docstring.

Thanks!


Add Player Images

Can you make an update to activate a function to put a player image to appear in the focused player set?
I don't know if that is possible to do but it would completely change the HUD in a positive way.
I've used your home page photo to make an example of what I'm talking.

not something you can do natively right now, but something I'd like to add eventually -- already tracked in #109

це не те, що ви можете зробити прямо зараз, але те, що я хочу додати зрештою - це вже відстежено в #109

Just a great idea to look forward to! As well as adding webcams if possible. Thanks for such a great hud


Hack Request - Add mini Logos to Game Play Score box

User story
In the GENS version of NHL Hockey (92) there are mini logos displayed during game play for the home and away team. These were removed in later version of the game. It would be a cool visual effect to add these mini logs into the game.

Possible Solution

[ ] Add Mini Logo Tiles to the rom
[ ] Load the tiles to the vram tilemap postion for home and away team text in background 1
[ ] Mesen Trace File

Actual Solution

Overwrite the EA Logo in vram with new min logo tiles. This displays the mini logs in the time box.
The starting vram position changes depending on what team logo is at center ice. Will need to keep a pointer table of the starting vram address of the ea logo based on what team is home.
Also the tiles are re-loaded after edit lines screen, so would need to re-load the tiles or find a way to edit the tile map for this.
Currently can't find the tile map in the rom, possibly compressed as well?

Acceptance criteria

[ ] Game Play Screen - Score box should show the home and away team mini logo instead of the team abbreviation letters.
[ ] Updated SNES NHL94 ROM-RAM Mapping Project with any new values.
[ ] DiztinGUIsh DizRaw file is up to date and has any necessary comments with changes.
[ ] Provided brief description of the actual changes (Solution) performed.

Sprint Ready Checklist

[ ] Acceptance criteria defined.
[ ] Identified solution / steps to satisfy acceptance criteria.
[ ] Acceptance criteria is verifiable / testable.

Have code that updates tiles using Force blank. Would like to tie into existing DMA transfer.
For now i might just ASM inject to new functions that are called before game pause menu to update tiles based on which teams are playing.


Investigate "not contributing valid epoch sigs" when reconnecting

Seems like there is a bug in the reconnecting peer logic where the peer will report

cargo-package> mint 3: 2022-12-02T18:36:14.377461Z  WARN fedimint_server: step.fault_log=FaultLog([Fault { node_id: PeerId(1), kind: UnexpectedHbMessageEpoch }])
cargo-package> mint 3: 2022-12-02T18:36:14.194975Z  INFO fedimint_server: Downloaded and processed epoch 9
...
cargo-package> mint 3: - Epoch: 16 [PeerId(0), PeerId(1), PeerId(2)] -
...
cargo-package> mint 3: 2022-12-02T18:36:14.457607Z  WARN process_consensus_outcome{epoch=16}: fedimint_server::consensus: Unable to sign epoch 15
cargo-package> mint 3: 2022-12-02T18:36:14.457682Z  WARN process_consensus_outcome{epoch=16}: fedimint_server::consensus: Dropping 0 for not contributing valid epoch sigs.
cargo-package> mint 3: 2022-12-02T18:36:14.457709Z  WARN process_consensus_outcome{epoch=16}: fedimint_server::consensus: Dropping 1 for not contributing valid epoch sigs.
cargo-package> mint 3: 2022-12-02T18:36:14.457733Z  WARN process_consensus_outcome{epoch=16}: fedimint_server::consensus: Dropping 2 for not contributing valid epoch sigs.

when reconnecting.  Error logs here https://github.com/fedimint/fedimint/actions/runs/3604198149/attempts/1

I believe this is happening because after downloading we might still be behind and some of the buffered epochs are getting thrown away.
So we end up downloading an epoch farther in the future, don't have the last epoch hash included in it, so the hash we try to sign is different than consensus.
I think I can fix this and also simplify the reconnecting logic.


Help for building an extraction

Hello
I have in one web page (https://fr.wikipedia.org/wiki/Meaulne-Vitray) the following items

		Cet article est une
		ébauche
                  concernant une
		 Commune
			de l’

			**Allier**

I need to extract Allier
I have tried with the following code
value.parseHtml().select('#div>strong>a[2]').htmlText()
But I get an error that the first item is not an html item.
I'm a newbe in html.
I hope some can help me
Thanks
Bernard

With Chrome and Firefox you can right click on an element on a webpage and
get lots of details on elements through an Inspector window.  The inspector
window highlights elements and you can move your mouse around in the
inspector window of the HTML code.
In Chrome or Firefox -

Right click on the element you are interested in in the page itself and
choose Inspect Element.
The inspector window appears with HTML code.
In the inspector window move your mouse around and hover over elements
to highlight them.
Right click on the  or whatever element that you are really
interested in extracting then choose Copy -> Copy Selector (or Css Selector)
You can then use that which is copied to the clipboard and paste into
the GREL select() itself, since that just uses Jsoup under the covers.

#mw-content-text > div.bandeau-article.bandeau-niveau-ebauche.plainlinks
becomes
value.parseHtml().select("
div.bandeau-article.bandeau-niveau-ebauche.plainlinks ")
More details here in these links and read the important tip about refering
to Jsoup's specific Selector command (which is what the GREL select()
actually exposes:
https://github.com/OpenRefine/OpenRefine/wiki/StrippingHTML
https://jsoup.org/apidocs/org/jsoup/select/Selector.html
-Thad
+ThadGuidry https://www.google.com/+ThadGuidry

Hello Thad
Thank you so much!
Regards
Bernard

Bernard Bourée

De : Thad Guidry<EMAIL_ADDRESS>Envoyé : mercredi 15 février 2017 15:59:57
À : OpenRefine/OpenRefine
Cc : BernardBoureee; Author
Objet : Re: [OpenRefine/OpenRefine] Help for building an extraction (#1171)
With Chrome and Firefox you can right click on an element on a webpage and
get lots of details on elements through an Inspector window. The inspector
window highlights elements and you can move your mouse around in the
inspector window of the HTML code.
In Chrome or Firefox -

Right click on the element you are interested in in the page itself and
choose Inspect Element.
The inspector window appears with HTML code.
In the inspector window move your mouse around and hover over elements
to highlight them.
Right click on the  or whatever element that you are really
interested in extracting then choose Copy -> Copy Selector (or Css Selector)
You can then use that which is copied to the clipboard and paste into
the GREL select() itself, since that just uses Jsoup under the covers.

#mw-content-text > div.bandeau-article.bandeau-niveau-ebauche.plainlinks
becomes
value.parseHtml().select("
div.bandeau-article.bandeau-niveau-ebauche.plainlinks ")
More details here in these links and read the important tip about refering
to Jsoup's specific Selector command (which is what the GREL select()
actually exposes:
https://github.com/OpenRefine/OpenRefine/wiki/StrippingHTML
https://jsoup.org/apidocs/org/jsoup/select/Selector.html
-Thad
+ThadGuidry https://www.google.com/+ThadGuidry
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/OpenRefine/OpenRefine/issues/1171#issuecomment-280033355, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ASse7W9UYVSwdk4UZMTvyHbd-bucqHp3ks5rcxLtgaJpZM4MByWp.

Please use the mailing list for support request regarding the usage of OpenRefine. Github ticket are to report bugs and request new feature.

OK thanks


Replace camelize with homegrown version

Type of PR (feature, enhancement, bug fix, etc.)
Enhancement.
Description
In the spirit of #181 I thought it would be a good idea to remove the dependency of inflected as well, as that will reduce the bundle with a few more bytes.
Compare with how it's done at inflected -> https://github.com/martinandert/inflected/blob/master/src/camelize.js
and rails -> https://apidock.com/rails/String/camelize
Why should this be added
Bundle size gets smaller and we rely and fewer dependencies.
Checklist

[x] My code follows the style guidelines of this project
[x] Checks (StandardRB & Prettier-Standard) are passing

Since when does camelCase ever capitalize the first letter by default?

camelCase and camelize are slightly different.
Loading development environment (Rails <IP_ADDRESS>)
2.7.0 :001 > 'string_me'.camelize()
 => "StringMe"
2.7.0 :002 >

You are, of course, completely correct.


[BUG] Duplicate Dead TV Remote still showing

I have just reinstalled windows and started my homebridge setup again. THe only thing I carried across was my config file. In the TV remote, I am still getting my old TV show up. I have removed the old bridge from my homekit stup and the old tv device is no longer there but I can still see the old TV remote. When I start homebridge, my config shows the following error:
TV accessory added in your bridge, if another plugin is exposing a TV accessory this one might not be visible in your remote widget
and I see two tvs in the remote app named the exact same, though one of them doesn't work (the old remote). How do I clear the old remote from showing on my device? I have tried deleting the accessories and homebridge-harmony folder and reinstalling homebridge-harmony but it is still the same. I am on the newest version of the plugin (only installed a couple of hours ago) as I had to reinstall all my plugins due to a new server.
Thanks

Hi, Did you check in ios13 if you have removed the old hub ? (and not only the device) . Hubs are now in home properties

Yes, Before I reinstalled Homebridge and reset it up, I deleted the old homebridge. None of my old homebridge devices show up in the home app, not even the TV. The only location I see a reference of the old TV is in the remote widget, as I now have two tv's to select from, both called "Suly's TV".
In my homebridge log, I can see the following message:
[Sulys TV] WARNING - configureAccessory - TV accessory added in your bridge from cache, if another plugin is exposing a TV accessory this one might not be visible in your remote widget

the warning is just in case you have oither plugins exposing a TV accessory. The one there is not exposed as an external one since you have only one from what I understand.
Did you simply try to restart your phone ? It is a cache problem on IOS side I think, if the TV is not in home app.

I've not tried that yet, I will give it a go when I am at home later. I also want to see if any of my other devices are showing mutiple TV's.

Ok, let's do that and come back to me !

I had a look when i got home and the duplicate remote had disappeared, without me even restarting anything. Looks like you are right and iOS was just caching it and got rid of it. All is showing ok now :)
Thanks!


Reduce build time

Fixes #468
Changes proposed in this PR:

Static dashboard files are added to the git repo, so that the don't have to be built by the user
Script has been added to check for changes in the dashboard. It is only rebuilt if there are changes.
npm run clean script has been modified so that it doesn't delete the dashboard build files.

Discussion point: We could also do the same thing for the node i.e. run a script that checks for changes, only build if something has changed.

i have a few doubts/questions on this PR
why can't we just have "build:dashboard" optional on the package.json
IMO, we could have simply 2 entries (for example):
"build": "npm run clean && npm run build:tsc",
"build-all": "npm run clean && npm run build:tsc && npm run build:dashboard",

we use the 1st as we usually do, also on CI ... and when we want the dashboard as well we use the other other one. Seems much simpler than committing tons of chunk files to github, than having scripts to detect changes. For the node itself we probably always want to build on CI, only exception would probably be when committing only documentation or code comments (that we don't do much anyway :-) )...
tkx

we could have simply 2 entries

We already have two commands build & build:no-dashboard. Your suggestion is to change the names and switch them around so that the default case is that the dashboard isn't built by default.
That doesn't solve the problem for people who want to use the dashboard. The problem is that the dashboard takes a long time to build. The solution proposed here is: we don't have to build it every time, only build it if there are changes, and if there are no changes then it doesn't need to be built the static files can be run straight out of the repo.

we could have simply 2 entries

We already have two commands build & build:no-dashboard. Your suggestion is to change the names and switch them around so that the default case is that the dashboard isn't built by default.
That doesn't solve the problem for people who want to use the dashboard. The problem is that the dashboard takes a long time to build. The solution proposed here is: we don't have to build it every time, only build it if there are changes, and if there are no changes then it doesn't need to be built - the static files can be run straight out of the repo.

"That doesn't solve the problem for people who want to use the dashboard. "
Why do you think  that?
If i want to use the dashboard i build it with "built-all" (or whatever name we choose), but that should be the exception not the rule... so IMO, the default build would be; without it
In any case, in my opinion it will never solve the problem, cause as long as we change something on the dashboard (regardless if i want to use it or not) it will always take some time to build, so we're not really reducing the dashboard build time... we're just either building or skipping the build... but with a very complex approach instead :-)
anyway, this is my opinion

Why do you think that?

If you consider some people want to run a node, with a dashboard, and want it to all start together quickly. The simplest solution is providing them with the static dashboard files, so they don't need to build it.

If i want to use the dashboard i build it with "build-all" (or whatever name we choose), but that should be the exception not the rule

Your solution amounts to telling people that if they want their node to start quickly they shouldn't run the dashboard. We can do better than this, simply by providing them with the static files.

@bogdanfazakas @mariacarmina @alexcos20 looking for a second review on this


Experimental function export with user-defined types for function arguments errors out

Bicep version
Bicep CLI version 0.23.1 (b02de2da48)
Describe the bug
I have activated the new experimental compile-time imports and user-defined functions. I export a function where one of the function arguments use a user-defined type. When I try to deploy a template that use this function it results in the following error:
{
  "code": "InvalidTemplate",
  "message": "Deployment template validation failed: 'Template language version must be specified in order to use feature 'AggregateTypeValidation'.'.",
  "additionalInfo": [
    {
      "type": "TemplateViolation",
      "info": {
        "lineNumber": 0,
        "linePosition": 0,
        "path": ""
      }
    }
  ]
}

To Reproduce
Create bicepconfig.json:
{
    "experimentalFeaturesEnabled": {
        "userDefinedFunctions": true,
        "compileTimeImports": true
    }
}

Export a function from function.bicep that takes an argument with a user-defined type:
// function.bicep
type myString = string

@export()
func capitalizer(in myString) string => toUpper(in)

Import and use the function in main.bicep:
// main.bicep
import { capitalizer } from 'function.bicep'

output test string = capitalizer('test')

Deploy the template:
$ az deployment group create -n dummy -f main.bicep -g <resource group name>

Note that this was a simplified example on how to reproduce the issue, in reality my function argument had a much more complex user-defined type.
Additional context

If I use a regular type (e.g. string) instead of a user-defined type, then the code works.
If I DON'T export the function, but instead declare it in main.bicep where I use it, then the code works with and without using user-defined types.

Thanks for reporting! User-defined types in ARM require a different compilation target, and the logic that was used to detect if that target is needed wasn't checking if imported functions used user-defined types.


Improvements PR

Hello @seratch,
Thank you for your work. I want to put my effort to this project for improvements. Here is my PR, please take a look and let me know if there is any concerns : https://github.com/seratch/ChatGPT-in-Slack/pull/34

Hey @quangnhut123, thanks for your interest! As I replied in the PR comments, I don't want to have the Bing dependencies in this repository. For the purpose, please feel free to fork this repo and maintain it as your own project. Some of the other changes may be valuable for other users too, so I am happy to merge them.
Let me close this issue now. If you won't work on the PR anymore, you can close the PR too. Thanks again for your interest and efforts here. I hope you and your team will enjoy using ChatGPT in Slack!