Fix/transporters

Main improvements in this PR:
Try to be as clear as possible: Is it fixing/adding something in the model? Is it an additional test/function/dataset?
We evalueated, refined and updated transporter data in the model. Based on the genome annotation of Streptomyces coelicolor, all of the integral membrane transport proteins were extracted from the Transport Classification Database(TCDB).  Gene association for some of the existing transport reactions were changed/updated. There were also new transport reactions with existing and new metabolites integrated into the scoGEM model (three tables with these transporters: existing transporters with updated gene association, new transporters with existing and new metabolites ere uploaded intothe branch fix/transporters). When integrating transporter rxns into scoGEM model, rxnID, rxn formula, gene association, reversibility (lower and upper bound) were integrated into scoGEM model . In addition directionality from reversible to irreversible of the rxns with rxnID: VALTA, LEUTA, ILETA have been intoduced into the model.
Gene association was defined based on  BLAST search of protein FASTA sequence (similarity score >= 90%). Substrates, taken by the transporters were either extracetd from TCDB, literature data (experimentally defined) or defined my the homology SMART BLAST search with the similarity score of >=90%. The scoGEM model after the transpoter updated, have been tested on growth for all the carbon and nitrogen sources, available in the scoGEM model as well as the evaluation has been done on mutant growth for specific mutants. All the growth data have benn compared to in vivo growth, iKS1317 GEM model growth and iMK1208 model growth (wild type growth table for C, N-sources and mutant growth rate table were uplodaed into the branch fix/transporters as well).
I hereby confirm that I have:

[x] Tested my code with all requirements for running the model
[X] Selected devel as a target branch (top left drop-down menu)
[x] If needed, asked first in the Gitter chat room about this PR

Note: replace [ ] with [X] to check the box.

I have uploaded script for integration transporters into scoGEM model. I have deleted some of the data and left just the tables, including data pulled by script. Uploaded is scoGEM model fule in xml format, that inludes added transporters. Note:  yml file has not been created for the latest scoGEM.xml.

working on the branch-will try to finish today.

I have now gone through the requested changes and updated scoGEM.xml and correspondant scoGEM.yml on fix/transporters/ModelFiles and updated fix/transporters/ComplementaryScripts. Let me know if there are any additional comments before the merging can proceed.

I have now applied all the requested changes and accordingly updates scoGEM.xml and correspondant scoGEM.yml on fix transporters/ModelFiles and updated fix/transporters/ComplementaryScripts. Therefore I am sending a pool request to merge the model scoGEM.xml(yml), updated with transporters from the brench fix/transporters into master.

I have now updated scoGEM model for transport .
Sink reactions for new metabolites of new transport rxns were extracted from the model
Double reactions were removed
Tables for EXTransportRxns.xcsv, newTransportRxns.csv, updated_grRules.csv, newTransport_newMets.csv, were updated on fix/transporters/ComplementaryData/curration/trasnport_reactions
Table for the annotation of new metabolies in new transport reactions was uploaded
aresnite efflux rxns and its annotation was resolved
gamma-actinorhodin was resolved.
I have integrated changes inot scoGEM model on fix/transporters/ModelFiles/xml/scoGEM

Tables for transporters have been updated (doubles have been extracted) and additional column (H) on annotation of transporters and gene annotation for updated grRules have been added. As well as table for new metabolites with various annotations (\KEGG, BioCyc, MetaNetx).

I think I messed it up slightly when fixing merge conflicts on my desktop. This pull request is now merged, although it doesn't show up here.
See commit:
https://github.com/SysBioChalmers/Sco-GEM/commit/9353c49eeb99ee5e6ea53463db3bdb17b9be8a45


Server ignores pre-sent messages

When a client sends a message immediately following the initial handshake, in anticipation of getting a successful reply, the server will drop the message. This is because HttpSocket throws out any bytes after the '\r\n\r\n' instead of passing the remainder along to the socket.
This issue is not part of the websocket protocol, and I think clients are supposed to wait for the reply before sending their first message. I only found this because I tried running an old client I wrote awhile ago when I needed something quick. However, you might want to at least throw an error when there are extra bytes instead of silently ignoring the data.

I haven't had any issue with any browser but yes, it should push any pre-sent data to the parser.

I went back and looked at the websocket standard, and it explicitly states that clients should not send data before receiving the handshake reply.

That's nice, I guess we just close this then.


cocoapods: 1.13.0 -> 1.14.3

Description of changes
https://github.com/CocoaPods/CocoaPods/releases/tag/1.14.3

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Priorities
Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 268885 run on aarch64-darwin 1

2 packages built:

cocoapods
cocoapods-beta


test(image-stream): move extraction timeout to a shared constant

The image stream tests that extract images all have a 20s timeout, which
is manually set in all the suites related to extraction.
This commit extracts that number as a constant called DEFAULT_TIMEOUT.
See: https://github.com/resin-io/etcher/pull/1595
Signed-off-by: Juan Cruz Viotti<EMAIL_ADDRESS>

@jhermsmeier Feel free to go through a bunch of recent Appveyor and Travis build logs (for all arches & OSes) to work out what a more reasonable default is, that won't cause the CI tests to fail ;-)

@lurch yeah, it's not that important to me – and I can also totally imagine the fs on a CI box being real slow at times, so 20s is okay, where 10s would do as well, I reckon.


[<IP_ADDRESS>] CPU 100%

I have a 3 node cluster. Each are m4.Large on Amazon. the CPU is 100%.
Each request I batch write all analytics when the request closes. There are usually 2-3 types of analytics I log.
tags := map[string]string{
		"id":    imp.ID,
		"country":   imp.IPAddress.Country,
		"ipaddress": imp.IPAddress.Address,
		"os": imp.OS,
	}

	fields := map[string]interface{}{
		"value": 1,
	}

	batchPoints.AddPoint(client.NewPoint(
		"impressions",
		tags,
		fields,
		time.Now().UTC(),
	))

Query times are ~1 second (through the web interface). To load balance the requests, I've hooked up elastic load balancer to all the nodes and allow them to rotate that way (not sure if this causes issues?).
I'm running influx 0.9.4.

How many batches are you writing per second?
How many points per batch?
What queries are running and how many?

I'm running no queries. Only writing.
A batch consists of either 1 or two points. Initially a flood of two points.
I can't tell how many I'm writing per second. We see an average of 2M requests a day. It's spread out pretty evenly (from the CDN). This does NOT mean all these hit the web server. At this moment, I can't tell because the latency is causing timeouts. I'll be removing the influx stats recording to see if I can track requests via ELB and go from there.
If I can provide anymore data, please let me know.

@ClanStyles What volume are you using to back the m4.large? A SSD?

Took influxdb out of rotation, no requests, still 100% CPU.

@ClanStyles if you are writing a million points per day in batches of 1 or 2 points each, that's tens of thousands of http requests per second to InfluxDB. That's too much HTTP overhead for the server.
Batch the writes into 100+ points per batch, ideally 5k points or so, for best performance. Alternately use UDP for the writes.
The high CPU load is likely because the system is trying to drain the WAL (write ahead log), which can accept points faster than the database can persist them to the permanent storage engine.

@beckettsean at this moment, there are no writes happening the CPU is still idle at 100%. The current issue with batching points is the need to write a batch writer.
Since Influx's client doesn't support multiple go-routines, this instantly limits us to a "per context" write. In the event that the server is shutting down, you'll need to gracefully write any remaining logs. There are various steps that will have to be implemented that I felt the influx client should do, and doesn't.
I monitored the influx disk IO on the drives, and it's next to nothing.
Watching the logs, I don't understand how this is even possible:
[monitor] 2015/11/03 01:33:59 failed to store statistics: timeout
[wal] 2015/11/03 01:33:59 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:34:02 write to index of partition 1 took 3.197536498s
[wal] 2015/11/03 01:34:10 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:34:10 write to index of partition 1 took 5.159944ms
[wal] 2015/11/03 01:34:19 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:34:19 write to index of partition 1 took 3.162219ms
[wal] 2015/11/03 01:34:27 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:34:27 write to index of partition 1 took 2.518651ms
[wal] 2015/11/03 01:34:39 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:34:40 write to index of partition 1 took 1.605196271s
[wal] 2015/11/03 01:34:54 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:34:56 write to index of partition 1 took 747.790113ms
[monitor] 2015/11/03 01:35:01 failed to store statistics: timeout
[wal] 2015/11/03 01:35:02 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:35:04 write to index of partition 1 took 1.579186636s
[wal] 2015/11/03 01:35:09 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:35:10 write to index of partition 1 took 1.566484512s
[wal] 2015/11/03 01:35:19 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:35:22 write to index of partition 1 took 1.638281477s
[wal] 2015/11/03 01:35:30 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:35:30 write to index of partition 1 took 2.431985ms
[wal] 2015/11/03 01:35:41 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:35:41 write to index of partition 1 took 2.17642ms
[wal] 2015/11/03 01:35:48 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:35:51 write to index of partition 1 took 2.540024959s
[wal] 2015/11/03 01:35:59 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:36:01 write to index of partition 1 took 1.58264594s
[wal] 2015/11/03 01:36:06 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:36:11 write to index of partition 1 took 5.009611341s
[wal] 2015/11/03 01:36:18 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:36:19 write to index of partition 1 took 1.557241405s
[wal] 2015/11/03 01:36:30 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:36:30 write to index of partition 1 took 2.475459ms
[wal] 2015/11/03 01:36:36 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:36:40 write to index of partition 1 took 3.262602201s
[wal] 2015/11/03 01:36:48 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:36:53 write to index of partition 1 took 5.099431167s
[wal] 2015/11/03 01:36:59 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1
[wal] 2015/11/03 01:37:02 write to index of partition 1 took 3.122957098s
[monitor] 2015/11/03 01:37:07 failed to store statistics: timeout
[wal] 2015/11/03 01:37:07 Flush due to idle. Flushing 3 series with 3 points and 195 bytes from partition 1

That looks like the internal stats being written to storage.
We need to surpress those log messages as they are too verbose in default mode.
Are you running InfluxDB as a service?

Yes on the standard AMI from Amazon following your guide.

At this stage it's pretty difficult to work out why, so a restart is probably best. However, we can run with profiling enabled to see if it re-occurs.
https://github.com/influxdb/influxdb/blob/master/CONTRIBUTING.md#profiling
Add -cpuprofile /tmp/influxd.prof to /etc/default/influxdb, which will enable profiling data to that file. So if it hits 100% we'd like that file, plus you need to tell us exactly which version you are running.

I'll do that.
Just to update, we're seeing about 1200 /requests a second we want to record stats for.

Any continuous queries in effect?

No, at the time it started to write, I didn't see more than 6 requests through ELB before the system went 100% CPU and died.

So after the restart, it seems like influx isn't spiking anymore on any of the 3 nodes.

OK, thanks @ClanStyles -- if you are up for it, we can run with profiling enabled in case it re-occurs.

Ah I think I figured out a trigger. Try to delete a large amount of data -> CPU spikes -> http times out.

Can you show use your query?

DELETE FROM foo WHERE time > '2014-06-30'
since drop series doesn't seem to work.
I'm trying to truncate data from the table.

Now the daemon is crashing. How do I upload the prof file?

DELETE is not a valid query. You're hitting a combination of that not being valid https://github.com/influxdb/influxdb/issues/1647 and the error not being thrown https://github.com/influxdb/influxdb/issues/4404.
I will escalate #4404 for the next release, I honestly forgot we hadn't fixed that.
DROP SERIES is a valid command and will cause high load for a while. InfluxDB assumes deletes are infrequent and usually in bulk, e.g. DROP MEASUREMENT or retention policy expiration. DROP SERIES is not as performant.

Closing this since it's related to the b1 storage engine which has been replaced by the tsm engine in 0.10.


⚠ Bofrost.at has degraded performance

In e8a236b, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1084 ms

Resolved: Bofrost.at performance has improved in 969b0ca after 13 minutes.


Do not log an error if a JSON field is missing

The switch statement here would previously hit the default branch which would log an error (on the background context). This causes FireFLy Core to log things like this when it starts up:
[2024-02-22T17:53:58.799Z] DEBUG Log level: debug pid=1
[2024-02-22T17:53:58.802Z]  INFO Hyperledger FireFly pid=1
[2024-02-22T17:53:58.802Z]  INFO © Copyright 2022 Kaleido, Inc. pid=1
[2024-02-22T17:53:58.803Z]  INFO Starting up pid=1
[2024-02-22T17:53:58.806Z] DEBUG Debug HTTP endpoint listening on localhost:6060 pid=1
[2024-02-22T17:53:58.835Z] ERROR Invalid object value '<nil>' for key 'identity'
[2024-02-22T17:53:58.844Z] ERROR Invalid object value '<nil>' for key 'auth'

Even though these fields are optional, the error logs make it look like something is wrong with the config which is confusing to people. I believe we can omit this log entirely in the case that the desired fields is nil, as the ok value will indicate to the calling code whether the field was found or not.

Switching this to a draft while I'm still working on testing it. It's still logging that error for some reason.


api.tx.utility.batchAll() error occurrence

Issue:
Encountering an error "The DID operation nonce does not match the current DID nonce + 1" when using api.tx.utility.batchAll().
Requirement:
For bulk uploads or revocations of records in the studio.

@Vikastc @vatsa287 we need to revert above PR, and instead consider using authorizeBatch instead of 'authorizeTx' of Did in dispatch methods. We need to experiment and plan to use it properly.

@amarts Ack.

Got it


Handling with 'application/octet-stream'

Hi guys,
I want to fetch files from a REST api which returns a stream ('application/octet-stream'). I tried the following:
    var request = rc.Request(
        method: rc.RequestMethod.get,
        url: 'https://localhost:44324/api/someFileResource',
        headers: {
          'accept': 'application/octet-stream',
          'data': 'application/octet-stream',
          'content-type': 'application/octet-stream'
        });

    try {
      var response = await client.execute(
          request: request, authorizer: rc.TokenAuthorizer(token: token));
    } catch (e) {
      print(e.toString());
    }

Whenever I execute this, I get always the Restexception "Error from server: FormatException: Invalid UTF-8 byte (at offset 0)"
The REST API works with other applications, but not with my flutter.
Do you have any suggestions or any idea?
Many thanks in advance!
BR,
Sandj

Thanks for the report.  Previously this was not possible.  I just released 2.1.0 which allows the functionality you're looking for.  Just do this:
    try {
      var response = await client.execute(
          jsonBody: false, // add this line
          request: request, authorizer: rc.TokenAuthorizer(token: token));
    } catch (e) {
      print(e.toString());
    }


What does wai-middleware-static-embedded do?

Why is there a custom wai-middleware-static-embedded? What does it do?

Nevermind, I figured it out.


Very sporadic framerate with demo

@rec - This could be pretty serious. I'm still testing so I'm not sure if this is SimPixel only or everything, but the framerates are crazy wonky:
FRAME - animation - 54ms/18fps / Frame: 51ms / Update: 2ms
FRAME - animation - 5ms/175fps / Frame: 2ms / Update: 2ms
FRAME - animation - 55ms/18fps / Frame: 52ms / Update: 3ms
FRAME - animation - 7ms/141fps / Frame: 3ms / Update: 3ms
FRAME - animation - 55ms/17fps / Frame: 51ms / Update: 4ms
FRAME - animation - 6ms/162fps / Frame: 2ms / Update: 3ms
FRAME - animation - 54ms/18fps / Frame: 50ms / Update: 3ms
FRAME - animation - 7ms/136fps / Frame: 3ms / Update: 3ms
FRAME - animation - 56ms/17fps / Frame: 52ms / Update: 3ms
FRAME - animation - 6ms/158fps / Frame: 3ms / Update: 3ms
FRAME - animation - 53ms/18fps / Frame: 50ms / Update: 2ms
FRAME - animation - 3ms/261fps / Frame: 1ms / Update: 2ms
FRAME - animation - 53ms/18fps / Frame: 51ms / Update: 2ms
FRAME - animation - 4ms/249fps / Frame: 1ms / Update: 2ms
FRAME - animation - 53ms/18fps / Frame: 51ms / Update: 2ms
FRAME - animation - 4ms/223fps / Frame: 2ms / Update: 2ms
FRAME - animation - 54ms/18fps / Frame: 51ms / Update: 3ms
FRAME - animation - 5ms/175fps / Frame: 2ms / Update: 2ms
FRAME - animation - 54ms/18fps / Frame: 51ms / Update: 2ms
FRAME - animation - 7ms/131fps / Frame: 2ms / Update: 4ms
FRAME - animation - 53ms/18fps / Frame: 52ms / Update: 0ms
FRAME - animation - 2ms/362fps / Frame: 1ms / Update: 0ms
FRAME - animation - 52ms/19fps / Frame: 50ms / Update: 1ms
FRAME - animation - 1ms/541fps / Frame: 0ms / Update: 0ms
FRAME - animation - 52ms/19fps / Frame: 50ms / Update: 1ms
FRAME - animation - 3ms/326fps / Frame: 1ms / Update: 1ms

So where are we with this?  If I could get a reproducible example...

Just run bibliopixel demo. Happens on both my systems. Or anything with
simpixel.
On Wed, Mar 28, 2018 at 7:31 AM, Tom Swirly<EMAIL_ADDRESS>wrote:

So where are we with this? If I could get a reproducible example...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/issues/662#issuecomment-376854237,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6a6l7xcth-rJza-ysP_8_5qjylSNAUks5ti3R2gaJpZM4Snw6t
.

Weird... ok. Ignore for now, but keep this open. I'll check on a few more
systems. May be OS dependent or something.
On Wed, Mar 28, 2018 at 7:36 AM, Tom Swirly<EMAIL_ADDRESS>wrote:

bp -v demo works fine for me, modulo unrelated bug #706
https://github.com/ManiacalLabs/BiblioPixel/issues/706.
I would have noticed this a long time ago if I were seeing this.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/issues/662#issuecomment-376855624,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6a6nzQY1-uR6F5qJMW2Gun_04ylpJbks5ti3XKgaJpZM4Snw6t
.

This is a Big Deal, so let's keep on this.
In particular, those 1ms frames seem dodgy to me.
On Wed, Mar 28, 2018 at 1:42 PM, Adam Haile<EMAIL_ADDRESS>wrote:

Weird... ok. Ignore for now, but keep this open. I'll check on a few more
systems. May be OS dependent or something.
On Wed, Mar 28, 2018 at 7:36 AM, Tom Swirly<EMAIL_ADDRESS>wrote:

bp -v demo works fine for me, modulo unrelated bug #706
https://github.com/ManiacalLabs/BiblioPixel/issues/706.
I would have noticed this a long time ago if I were seeing this.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/ManiacalLabs/BiblioPixel/issues/662#issuecomment-
376855624>,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/AA6a6nzQY1-uR6F5qJMW2Gun_04ylpJbks5ti3XKgaJpZM4Snw6t>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/issues/662#issuecomment-376857026,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPdssqrOTWUgCi2h8DfXtnYJjL3GnjQks5ti3dBgaJpZM4Snw6t
.

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com

BTW... still a problem with 3.4.18

:-(
Any more solid information would help.  I keep being on the lookout for this.
Interestingly enough, Adam2 was doing some fairly consumptive animations on the RPI and I didn't see any errors like yours.  I do fairly commonly see that the frame time is 2ms off or so, but that doesn't bother me (nor can I see it).

Not really... it just does that on all my systems.
I don't think it's right though... I think it's actually a reporting
error.
What does your frame logging look like for bp demo ?
On Mon, May 14, 2018 at 4:41 PM Tom Swirly<EMAIL_ADDRESS>wrote:

:-(
Any more solid information would help. I keep being on the lookout for
this.
Interestingly enough, Adam2 was doing some fairly consumptive animations
on the RPI and I didn't see any errors like yours. I do fairly commonly
see that the frame time is 2ms off or so, but that doesn't bother me (nor
can I see it).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/issues/662#issuecomment-388955580,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6a6ocB9CZ3VXjTSnPYy-a1lAJCRV7Mks5tyevmgaJpZM4Snw6t
.

Works like butter.  I'm not even seeing the 2ms errors!  (Running with -v -
should I run with --loglevel=frame ?)
On Mon, May 14, 2018 at 10:43 PM, Adam Haile<EMAIL_ADDRESS>wrote:

Not really... it just does that on all my systems.
I don't think it's right though... I think it's actually a reporting
error.
What does your frame logging look like for bp demo ?
On Mon, May 14, 2018 at 4:41 PM Tom Swirly<EMAIL_ADDRESS>wrote:

:-(
Any more solid information would help. I keep being on the lookout for
this.
Interestingly enough, Adam2 was doing some fairly consumptive animations
on the RPI and I didn't see any errors like yours. I do fairly commonly
see that the frame time is 2ms off or so, but that doesn't bother me (nor
can I see it).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/ManiacalLabs/BiblioPixel/issues/662#issuecomment-
388955580>,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/AA6a6ocB9CZ3VXjTSnPYy-a1lAJCRV7Mks5tyevmgaJpZM4Snw6t>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/issues/662#issuecomment-388956181,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPdsjS5wMUtXzy2wkbYUnwH1RxG7kWIks5tyexkgaJpZM4Snw6t
.

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com

Ah, when I do it with --loglevel=frame, I do see alternate frames taking
different times!
Funny, the animations look fine.
On Mon, May 14, 2018 at 10:50 PM, Tom Swirly<EMAIL_ADDRESS>wrote:

Works like butter.  I'm not even seeing the 2ms errors!  (Running with -v

should I run with --loglevel=frame ?)

On Mon, May 14, 2018 at 10:43 PM, Adam Haile<EMAIL_ADDRESS>wrote:

Not really... it just does that on all my systems.
I don't think it's right though... I think it's actually a reporting
error.
What does your frame logging look like for bp demo ?
On Mon, May 14, 2018 at 4:41 PM Tom Swirly<EMAIL_ADDRESS>wrote:

:-(
Any more solid information would help. I keep being on the lookout for
this.
Interestingly enough, Adam2 was doing some fairly consumptive animations
on the RPI and I didn't see any errors like yours. I do fairly
commonly
see that the frame time is 2ms off or so, but that doesn't bother me
(nor
can I see it).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/ManiacalLabs/BiblioPixel/issues/662#
issuecomment-388955580>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AA6a6ocB9CZ3VXjTSnPYy-a1lAJCRV7Mks5tyevmgaJpZM4Snw6t>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/issues/662#issuecomment-388956181,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPdsjS5wMUtXzy2wkbYUnwH1RxG7kWIks5tyexkgaJpZM4Snw6t
.

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com

Yes... always --loglevel=frame :)
On Mon, May 14, 2018 at 4:51 PM Tom Swirly<EMAIL_ADDRESS>wrote:

Works like butter. I'm not even seeing the 2ms errors! (Running with -v -
should I run with --loglevel=frame ?)
On Mon, May 14, 2018 at 10:43 PM, Adam Haile<EMAIL_ADDRESS>wrote:

Not really... it just does that on all my systems.
I don't think it's right though... I think it's actually a reporting
error.
What does your frame logging look like for bp demo ?
On Mon, May 14, 2018 at 4:41 PM Tom Swirly<EMAIL_ADDRESS>wrote:

:-(
Any more solid information would help. I keep being on the lookout for
this.
Interestingly enough, Adam2 was doing some fairly consumptive
animations
on the RPI and I didn't see any errors like yours. I do fairly
commonly
see that the frame time is 2ms off or so, but that doesn't bother me
(nor
can I see it).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/ManiacalLabs/BiblioPixel/issues/662#issuecomment-
388955580>,
or mute the thread
<https://github.com/notifications/unsubscribe-
auth/AA6a6ocB9CZ3VXjTSnPYy-a1lAJCRV7Mks5tyevmgaJpZM4Snw6t>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/ManiacalLabs/BiblioPixel/issues/662#issuecomment-388956181
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAPdsjS5wMUtXzy2wkbYUnwH1RxG7kWIks5tyexkgaJpZM4Snw6t
.

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/issues/662#issuecomment-388958532,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6a6v2TeJG5a_t-On3I864J66IVHS23ks5tye5KgaJpZM4Snw6t
.

Hence why I wonder if it's a reporting issue. Animation also looks fine for
me.
But if the reporting is doing that it's useless.... note: I use frame
loglevel constantly. Personally I want a way to default it to on.
On Mon, May 14, 2018 at 4:52 PM Tom Swirly<EMAIL_ADDRESS>wrote:

Ah, when I do it with --loglevel=frame, I do see alternate frames taking
different times!
Funny, the animations look fine.
On Mon, May 14, 2018 at 10:50 PM, Tom Swirly<EMAIL_ADDRESS>wrote:

Works like butter. I'm not even seeing the 2ms errors! (Running with -v

should I run with --loglevel=frame ?)

On Mon, May 14, 2018 at 10:43 PM, Adam Haile<EMAIL_ADDRESS>wrote:

Not really... it just does that on all my systems.
I don't think it's right though... I think it's actually a reporting
error.
What does your frame logging look like for bp demo ?
On Mon, May 14, 2018 at 4:41 PM Tom Swirly<EMAIL_ADDRESS>wrote:

:-(
Any more solid information would help. I keep being on the lookout for
this.
Interestingly enough, Adam2 was doing some fairly consumptive
animations
on the RPI and I didn't see any errors like yours. I do fairly
commonly
see that the frame time is 2ms off or so, but that doesn't bother me
(nor
can I see it).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/ManiacalLabs/BiblioPixel/issues/662#
issuecomment-388955580>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AA6a6ocB9CZ3VXjTSnPYy-a1lAJCRV7Mks5tyevmgaJpZM4Snw6t>
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/ManiacalLabs/BiblioPixel/issues/662#issuecomment-388956181
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/AAPdsjS5wMUtXzy2wkbYUnwH1RxG7kWIks5tyexkgaJpZM4Snw6t

.

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/BiblioPixel/issues/662#issuecomment-388958969,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6a6t4dc2zp91aIU02DOEaOY7_EDMU_ks5tye6kgaJpZM4Snw6t
.

I don't see how the reporting can be inaccurate from reading it!  But clearly something askew...
Filed this issue:  https://github.com/ManiacalLabs/BiblioPixel/issues/801

I'm moving this to 4.x.  I need to get out of doing new development or bugfixes unless they are urgent.


[bug] Z2M scales values by 255 -> 99, for the first dimmer in a node

Version
Build/Run method

[x] Docker
[ ] PKG
[ ] Manually built (git clone - npm install - npm run build )

Zwave2Mqtt version: 3.1.0
Openzwave Version: 1.6.1115
Describe the bug
I was tracing why Z2M was changing my "set" value from 255 to 99. I'd prefer if Z2M did not scale my desired value, as I think this is what makes it hard for me to create proper integrations in HASS.
In these lines, I saw that Z2M scales the value, only if the object_id of the device is rgb_dimmer. This gave me a way out - simply change the object id in the discovery doc, so Z2M doesn't hit that branch.
The bug here is that this only applies to the first dimmer. I have multiple nodes with multiple dimmers, where the object ids are named like this. I tested it, and surely enough, if I send a 255 to any of the rgb_dimmer_N devices, the value isn't scaled. This means that the first dimmer works very differently from all other dimmers.

To Reproduce
N/A
Expected behavior

That Z2M does not scale my values in any way.
Is it possible to avoid scaling - is changing the object_id a supported scenario?

I changed my object_id, but it didn't immediately have an effect - maybe I need to restart Z2M?
EDIT: I restarted Z2M, and now the scaling is completely gone. So another bug perhaps?

Additional context
N/A

The lines above also apply to the first dimmer only. So, sending on will work differently on the first dimmer vs. the others.

@jshridha I think we added those line to support lights dimmer. Do you remember this?

Also ... the discussion we had in another issue reg. this, you mentioned, I think, that the 255 was sent to the device to go to its last state. But the code I'm seeing, never sends a 255.
I think a way to get the "go to last state with HASS" would be like this:

Inform HASS the scale goes from 0..99
Let HASS turn the node on by sending on
In Z2M, when receiving on, send 255

Z2M will get back a value update from the node which it forwards to HASS, so HASS can place its brightness slider correctly

In Z2M, when receiving 0..99, send that value to the node

Than you can ditch all scaling code :)

@LordMike The code certainly does send a 255. I just tested it out and hass sent z2m a 255 just like it should for an ON command. Below is what my discovery json looks like:
{
  "type": "light",
  "object_id": "dimmer",
  "discovery_payload": {
    "schema": "template",
    "brightness_template": "{{ (value_json.value / 99 * 255) | round(0) }}",
    "state_topic": "zwave/lr_ceiling/38/1/0",
    "state_template": "{{ \"off\" if value_json.value == 0 else \"on\" }}",
    "command_topic": "zwave/lr_ceiling/38/1/0/set",
    "command_on_template": "{{ ((brightness / 255 * 99) | round(0)) if brightness is defined else 255 }}",
    "command_off_template": "0",
    "device": {
      "identifiers": [
        "zwave2mqtt_0xe6ebd3e1_node10"
      ],
      "manufacturer": "GE (Jasco Products)",
      "model": "14294 In-Wall Smart Dimmer (0x3038)",
      "name": "lr_ceiling",
      "sw_version": "5.26"
    },
    "name": "lr_ceiling_dimmer",
    "unique_id": "zwave2mqtt_0xe6ebd3e1_10-38-1-0"
  },
  "discoveryTopic": "light/lr_ceiling/dimmer/config",
  "values": [
    "38-1-0"
  ],
  "persistent": false,
  "id": "light_dimmer"
}

It certainly sounds like a bug if this scaling template only gets applied to the first dimmer. That certainly should be fixed. Otherwise I think that Z2M is working correctly in that it takes the value it sends and forwards it to the node. I think that adding in a translation layer in there would be putting the responsibility of translating "on" is correctly done in the template and if you need to modify the template for your specific device, that can be done in the hass/devices.json file.

Sure, HASS sends a 255 - but the code I linked to is within Z2M. My claim is that Z2M doesn't send the z-wave node a 255 value. Whenever it receives a value, the code linked will scale it from 0..255 to 0..99. :)
You can see in the Z2M debug log, what it actually sends out - that's where I found this to begin with :)
My suggestion was, to make this all simpler, and still send the potential 255 value (if I missed something), was to take the approach I outlined. It would simplify the process (no scaling needed), and send the special values (255) in special cases. :)

@LordMike Thanks for that further explanation. I see the scaling that you're talking about now and sorry I missed what you were saying before. I actually don't have any rgb_dimmers, which is probably why I never noticed that. I'm not sure why that scaling is there to begin with. It doesn't exist for normal dimmers, so perhaps the payload processing should just match what is done for normal dimmers?

Aha!.. That explains the difference in what we're seeing in the other chat, too.. :)

@LordMike In poor words you are suggesting to remove this lines of code https://github.com/OpenZWave/Zwave2Mqtt/blob/master/lib/Gateway.js#L485-L488

In any case, there is the bug that the second (and other) dimmers, won't benefit from the same scaling. That should be solved no matter what.
But yea, I'd remove those lines, to remove scaling - in addition to that, my changes would include:

Tweaking any HASS docs as necessary (the value/brightness templates)
If you want the 255 value sent to indicate "last brightness used", handle that using the "on" value from HASS

Tweaking any HASS docs as necessary (the value/brightness templates)

Do you mean hass configurations? How should I tweak them?

If you want the 255 value sent to indicate "last brightness used", handle that using the "on" value from HASS

I don't understand sorry.
Would you mind to open a PR that explains this points, I will give you my support and my opinion once I see your idea in the code. The problem with such things is to break existing instances and I don't have any dimmer to test with hass, so we have to be careful

It would break existing setups. Perhaps removing scaling is better left for a 4.0 release.
To fix the immediate bug though, the lines should be changed to something like "begins with 'rgb_dimmer'".. :)

You mean here
      if (this.discovered[valueId.value_id].object_id === 'rgb_dimmer') {

to
      if (this.discovered[valueId.value_id].object_id.startsWith('rgb_dimmer')) {

I suppose, also here:

if ((valueId.type === 'bool' || this.discovered[valueId.value_id].object_id === 'rgb_dimmer') && typeof payload === 'string') {

To

if ((valueId.type === 'bool' || this.discovered[valueId.value_id].object_id.startsWith('rgb_dimmer')) && typeof payload === 'string') {

Just those lines so?

That will solve the immediate bug reg. scaling only applying to the first rgb_dimmer.

Check the open PR please @LordMike

Looks fine.


Ability to create a file with that uses a custom editor without needing to have an open workspace

A file that has an extension type that uses a custom editor currently requires a workspace to be open in order to create new files of that custom editor type. This is evidenced by the PawDraw sample project:

It would be great if users would be able to create new files that use custom editors without needing a workspace to be open. I'm imagining the flow would be like this:

Provide (via the extension) the template string text that would be the MVP to have your custom editor properly render.
User issues command to create new file type that uses the custom editor.
Code writes the template text to a virtual document, and sets the file as dirty.
Code opens that virtual document in the custom editor.

I'm running into issues with this with my custom editor extension already (https://github.com/kkukshtel/Depot/issues/15), and my current "fix" is to just gracefully handle the edge case in the same way PawDraw does.

Duplicate of #93441


orangefs: pull upstream fix for -fno-common toolchains

Without the change upstream gcc-10 fails to build as:
ld: src/common/mgmt/pint-worker-external.po:(.data.rel.local+0x0): multiple definition of
  `PINT_worker_external_impl'; src/common/mgmt/pint-mgmt.po:(.bss+0x20): first defined here

Description of changes

Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

With the recent gcc-11 it builds on master: https://hydra.nixos.org/eval/1763290?filter=orangefs&compare=1763212&full=

To trigger build failure one needs to remove a nixpkgs-specific -fcommon hack. One of the way to do it is to pass -fno-common flag:
$ nix build -L --impure --expr 'with import <nixpkgs> {}; orangefs.overrideAttrs (oa: {   NIX_CFLAGS_COMPILE = (["-fno-common"] ++ [oa.NIX_CFLAGS_COMPILE or ""]); })'
...
orangefs> /nix/store/3fqi6nigj8dkbvjnw8y4dy59gkq8vsj4-binutils-2.38/bin/ld: src/common/mgmt/pint-worker-external.po:(.bss+0x80): multiple definition of `PINT_worker_threaded_queues_impl'; src/common/mgmt/pint-mgmt.po:(.bss+0xe0): first defined here
orangefs> /nix/store/3fqi6nigj8dkbvjnw8y4dy59gkq8vsj4-binutils-2.38/bin/ld: src/common/mgmt/pint-worker-external.po:(.bss+0xc0): multiple definition of `PINT_worker_queues_impl'; src/common/mgmt/pint-mgmt.po:(.bss+0x120): first defined here
orangefs> /nix/store/3fqi6nigj8dkbvjnw8y4dy59gkq8vsj4-binutils-2.38/bin/ld: src/common/mgmt/pint-worker-external.po:(.data.rel.local+0x0): multiple definition of `PINT_worker_external_impl'; src/common/mgmt/pint-mgmt.po:(.bss+0x20): first defined here
orangefs> src/apps/kernel/linux/pvfs2-client-core.c: In function 'remove_op_from_ops_in_progress_table':
orangefs> src/apps/kernel/linux/pvfs2-client-core.c:556:20: warning: variable 'tmp_vfs_request' set but not used [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-but-set-variable-Wunused-but-set-variable8;;]
orangefs>   556 |     vfs_request_t *tmp_vfs_request = NULL;
orangefs>       |                    ^~~~~~~~~~~~~~~
orangefs> src/apps/kernel/linux/pvfs2-client-core.c: In function 'main':
orangefs> src/apps/kernel/linux/pvfs2-client-core.c:5053:16: warning: variable 'local_time' set but not used [8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wunused-but-set-variable-Wunused-but-set-variable8;;]
orangefs>  5053 |     struct tm *local_time = NULL;
orangefs>       |                ^~~~~~~~~~
orangefs> collect2: error: ld returned 1 exit status
orangefs> make: *** [Makefile:976: lib/libpvfs2.so] Error 1
orangefs> make: *** Waiting for unfinished jobs....
orangefs> collect2: error: ld returned 1 exit status
orangefs> make: *** [Makefile:929: src/server/pvfs2-server] Error 1


The game now allows you to connect an account using a referral link if this has not been done before in the friends tab.

The game now allows you to connect an account using a referral link if this has not been done before in the friends tab. Is it possible to implement the functionality of inserting the referral link of the main account into config.py so that all other uninvited people can connect themselves?

Good Idea


Spring Boot 2.4.x / Spring Cloud 3.0.0 support?

Hi,
I tried using 2.0.25 with Spring Boot 2.4.x and Spring Cloud 3.0.0 and it is no longer compatible as the Spring Cloud team made a lot of changes. Any ETA on when the support will be available?
Thanks!

Any comments?

Any comments?

Any comments?

@Komdosh I can't speak for the team, but the project seems abruptly abandoned? Hasn't been touched in over a month now. Unfortunately, Open Feign proper doesn't support reactive yet, Would be nice to hear from somebody with an update though.
I'm giving it a few more weeks and then I guess I'll rip it out and move on if there is no activity.

Any comments?

@Komdosh I can't speak for the team, but the project seems abruptly abandoned? Hasn't been touched in over a month now. Unfortunately, Open Feign proper doesn't support reactive yet, Would be nice to hear from somebody with an update though.
I'm giving it a few more weeks and then I guess I'll rip it out and move on if there is no activity.

any other alternative for this?

The project is alive and running, as for this particular issue, support of the latest boot\cloud is not in a focus right now (but it can be changed at any moment, unfortunately, I cannot give you an exact ETA)
If you feel a huge need for this particular feature, please do not hesitate to contribute compatibility PR, we would be glad to review it.

any other alternative for this?

The project is alive and running, as for this particular issue, support of the latest boot\cloud is not in a focus right now (but it can be changed at any moment, unfortunately, I cannot give you an exact ETA)
If you feel a huge need for this particular feature, please do not hesitate to contribute compatibility PR, we would be glad to review it.

any other alternative for this? and why spring is not coming up with reactive feign?

Spring just wraps Open Feign proper which doesn't support reactive yet.

any other alternative for this? and why spring is not coming up with reactive feign?

Spring just wraps Open Feign proper which doesn't support reactive yet.

The project is alive and running, as for this particular issue, support of the latest boot\cloud is not in a focus right now (but it can be changed at any moment, unfortunately, I cannot give you an exact ETA)
If you feel a huge need for this particular feature, please do not hesitate to contribute compatibility PR, we would be glad to review it.

Thanks for the update. I'd think its important, but hopefully soon :).

The project is alive and running, as for this particular issue, support of the latest boot\cloud is not in a focus right now (but it can be changed at any moment, unfortunately, I cannot give you an exact ETA)
If you feel a huge need for this particular feature, please do not hesitate to contribute compatibility PR, we would be glad to review it.

Thanks for the update. I'd think its important, but hopefully soon :).

The Spring Cloud 3.0 has been upgraded in my fork.
my versions:
<spring-cloud-bom.version>2020.0.0</spring-cloud-bom.version>
<spring-boot-dependencies-bom.version>2.4.1</spring-boot-dependencies-bom.version>
The feign-reactor-cloud2 module building is ok, but the unit tests are blocked because it is dependent from the feign-reactor-cloud module.  While the derived jar works well!
The feign-reactor-cloud could not build because Spring Cloud 3.0.0 removed the Netflix components excluding Eureka.
Would you rename the feign-reactor-cloud2 module to feign-reactor-cloud3 or just keep it?
The attachment is the product I built with the feign-reactor-cloud2 artifact id.   Just change the file name.
feign-reactor-cloud3-2.0.26-SNAPSHOT.jar.zip

The Spring Cloud 3.0 has been upgraded in my fork.
my versions:
<spring-cloud-bom.version>2020.0.0</spring-cloud-bom.version>
<spring-boot-dependencies-bom.version>2.4.1</spring-boot-dependencies-bom.version>
The feign-reactor-cloud2 module building is ok, but the unit tests are blocked because it is dependent from the feign-reactor-cloud module.  While the derived jar works well!
The feign-reactor-cloud could not build because Spring Cloud 3.0.0 removed the Netflix components excluding Eureka.
Would you rename the feign-reactor-cloud2 module to feign-reactor-cloud3 or just keep it?
The attachment is the product I built with the feign-reactor-cloud2 artifact id.   Just change the file name.
feign-reactor-cloud3-2.0.26-SNAPSHOT.jar.zip

Upgrade to Spring Boot 2.4.x / Spring Cloud 3.0.0 is a breaking change that will not allow to support feign-reactor-cloud module that is still widely used by Playtika. It will take some time to migrate

Upgrade to Spring Boot 2.4.x / Spring Cloud 3.0.0 is a breaking change that will not allow to support feign-reactor-cloud module that is still widely used by Playtika. It will take some time to migrate

We are also facing issues with Spring Boot 2.4.x.
At start up Spring fails with the following exception:
An attempt was made to call a method that does not exist. The attempt was made from the following location:

    org.springframework.boot.web.embedded.netty.NettyReactiveWebServerFactory.createHttpServer(NettyReactiveWebServerFactory.java:163)

The following method did not exist:

    reactor.netty.http.server.HttpServer.runOn(Lreactor/netty/resources/LoopResources;)Lreactor/netty/transport/Transport;

The method's class, reactor.netty.http.server.HttpServer, is available from the following locations:

    jar:file:/**/.gradle/caches/modules-2/files-2.1/io.projectreactor.netty/reactor-netty/0.9.13.RELEASE/1c29a782629ef71ff7c7b7332c9fc66860ea062a/reactor-netty-0.9.13.RELEASE.jar!/reactor/netty/http/server/HttpServer.class
    jar:file:/**.gradle/caches/modules-2/files-2.1/io.projectreactor.netty/reactor-netty-http/1.0.3/b5b8facfd4bb03f97c88d396eed69770b3a9e088/reactor-netty-http-1.0.3.jar!/reactor/netty/http/server/HttpServer.class

The class hierarchy was loaded from the following locations:

    reactor.netty.http.server.HttpServer: file:/**/.gradle/caches/modules-2/files-2.1/io.projectreactor.netty/reactor-netty/0.9.13.RELEASE/1c29a782629ef71ff7c7b7332c9fc66860ea062a/reactor-netty-0.9.13.RELEASE.jar

Action:

Correct the classpath of your application so that it contains a single, compatible version of reactor.netty.http.server.HttpServer

From what I can see the problem may be related to the Feign dependency on
io.projectreactor.netty:reactor-netty:0.9.13.RELEASE

which breaks when Spring now depends on
io.projectreactor.netty:reactor-netty-http:1.0.3

We are also facing issues with Spring Boot 2.4.x.
At start up Spring fails with the following exception:
An attempt was made to call a method that does not exist. The attempt was made from the following location:

    org.springframework.boot.web.embedded.netty.NettyReactiveWebServerFactory.createHttpServer(NettyReactiveWebServerFactory.java:163)

The following method did not exist:

    reactor.netty.http.server.HttpServer.runOn(Lreactor/netty/resources/LoopResources;)Lreactor/netty/transport/Transport;

The method's class, reactor.netty.http.server.HttpServer, is available from the following locations:

    jar:file:/**/.gradle/caches/modules-2/files-2.1/io.projectreactor.netty/reactor-netty/0.9.13.RELEASE/1c29a782629ef71ff7c7b7332c9fc66860ea062a/reactor-netty-0.9.13.RELEASE.jar!/reactor/netty/http/server/HttpServer.class
    jar:file:/**.gradle/caches/modules-2/files-2.1/io.projectreactor.netty/reactor-netty-http/1.0.3/b5b8facfd4bb03f97c88d396eed69770b3a9e088/reactor-netty-http-1.0.3.jar!/reactor/netty/http/server/HttpServer.class

The class hierarchy was loaded from the following locations:

    reactor.netty.http.server.HttpServer: file:/**/.gradle/caches/modules-2/files-2.1/io.projectreactor.netty/reactor-netty/0.9.13.RELEASE/1c29a782629ef71ff7c7b7332c9fc66860ea062a/reactor-netty-0.9.13.RELEASE.jar

Action:

Correct the classpath of your application so that it contains a single, compatible version of reactor.netty.http.server.HttpServer

From what I can see the problem may be related to the Feign dependency on
io.projectreactor.netty:reactor-netty:0.9.13.RELEASE

which breaks when Spring now depends on
io.projectreactor.netty:reactor-netty-http:1.0.3

@kptfh  any update on this please?

we use spring boot 2.4.3 and springcloud 2020.0.1
throw exception
Caused by: java.lang.ClassNotFoundException: org.springframework.cloud.client.loadbalancer.reactive.Response

i use cloud2 module, does this project would support this version.

@kptfh looks like some classes (Response/Request) were moved to another package, could u please take a look? (One level upper - loadbalancer)

will feign-reactive ever end up in openfeign? any news on that?
also is there a plan to upgrade this or is this project hit EOL?

The project is planned to be upgraded to be compatible with the latest spring cloud, just a bit later this year.
Contributions are highly appreciated.

As im currently short on time(read: no time at all) i cant do an update now, but here are the fixes:
locally define these two(they have dependency issues as of spring-cloud update, they can easily be just updated(imports))
note this is a fix for kubernetes load balanced where the pods are being pinged directly a more sturdy solution is required(but i would see this as part of spring and not here)
ReactiveFeignCircuitBreakerConfigurator
public class ReactiveFeignCircuitBreakerConfigurator extends reactivefeign.spring.config.ReactiveFeignCircuitBreakerConfigurator {

}

ReactiveFeignLoadBalancerConfigurator
public class ReactiveFeignLoadBalancerConfigurator extends reactivefeign.spring.config.ReactiveFeignLoadBalancerConfigurator {

}

LoadBalancerPublisherClient need some love
@Slf4j
public class LoadBalancerPublisherClient implements PublisherHttpClient {

    private final ReactiveLoadBalancer<ServiceInstance> reactiveLoadBalancer;
    private final PublisherHttpClient publisherClient;

    public LoadBalancerPublisherClient(
            ReactiveLoadBalancer<ServiceInstance> reactiveLoadBalancer,
            PublisherHttpClient publisherClient
    ) {
        this.reactiveLoadBalancer = reactiveLoadBalancer;
        this.publisherClient = publisherClient;
    }

    @Override
    public Publisher<Object> executeRequest(ReactiveHttpRequest request) {
        return Mono
                .from(reactiveLoadBalancer.choose())
                .map(choice -> {
                    log.debug("Chose server: {}", choice.getServer());

                    return choice;
                })
                .flatMapMany(serviceInstanceResponse -> {
//                    URI lbUrl = reconstructURI(serviceInstanceResponse.getServer(), request.uri());
//                    ReactiveHttpRequest lbRequest = new ReactiveHttpRequest(request, lbUrl);
                    return publisherClient.executeRequest(request);
                });
    }
}

ReactiveFeignCloudBuilder note: this is only to override the builder to use the LoadBalancerPublisherClient (internally the check is made for it - very ugly) would love to see an interface here
public class ReactiveFeignCloudBuilder {

    private static final Logger logger = LoggerFactory.getLogger(ReactiveFeignCloudBuilder.class);

    public static <T> ReactiveFeignCloudBuilder.Builder<T> builder(ReactiveFeignBuilder<T> builder) {
        return new ReactiveFeignCloudBuilder.Builder<>(builder);
    }

    public static class Builder<T> extends reactivefeign.cloud2.CloudReactiveFeign.Builder<T> {

        private ReactiveFeignBuilder<T> builder;
        private ReactiveFeignCircuitBreakerFactory circuitBreakerFactory;
        private FallbackFactory<T> fallbackFactory;
        private ReactiveLoadBalancer.Factory<ServiceInstance> loadBalancerFactory;
        private ReactiveRetryPolicy retryOnNextPolicy;

        protected Builder(ReactiveFeignBuilder<T> builder) {
            super(builder);
            this.builder = builder;
        }

        public ReactiveFeignCloudBuilder.Builder<T> enableCircuitBreaker(ReactiveFeignCircuitBreakerFactory circuitBreakerFactory) {
            this.circuitBreakerFactory = circuitBreakerFactory;
            return this;
        }

        public ReactiveFeignCloudBuilder.Builder<T> enableLoadBalancer(
                ReactiveLoadBalancer.Factory<ServiceInstance> loadBalancerFactory) {
            this.loadBalancerFactory = loadBalancerFactory;
            return this;
        }

        public ReactiveFeignCloudBuilder.Builder<T> retryOnSame(ReactiveRetryPolicy retryOnSamePolicy) {
            if (this.loadBalancerFactory == null) {
                throw new IllegalArgumentException("loadBalancerFactory should be specified");
            }
            retryWhen(retryOnSamePolicy);
            return this;
        }

        public ReactiveFeignCloudBuilder.Builder<T> retryOnNext(ReactiveRetryPolicy retryOnNextPolicy) {
            if (this.loadBalancerFactory == null) {
                throw new IllegalArgumentException("loadBalancerFactory should be specified");
            }
            this.retryOnNextPolicy = retryOnNextPolicy;
            return this;
        }

        @Override
        public ReactiveFeignCloudBuilder.Builder<T> fallback(T fallback) {
            return fallbackFactory(throwable -> fallback);
        }

        @Override
        public ReactiveFeignCloudBuilder.Builder<T> fallbackFactory(FallbackFactory<T> fallbackFactory) {
            this.fallbackFactory = fallbackFactory;
            return this;
        }

        @Override
        public ReactiveFeignCloudBuilder.Builder<T> contract(Contract contract) {
            builder = builder.contract(contract);
            return this;
        }

        @Override
        public ReactiveFeignBuilder<T> addExchangeFilterFunction(ReactiveHttpExchangeFilterFunction exchangeFilterFunction) {
            builder = builder.addExchangeFilterFunction(exchangeFilterFunction);
            return this;
        }

        @Override
        public ReactiveFeignCloudBuilder.Builder<T> options(ReactiveOptions options) {
            builder = builder.options(options);
            return this;
        }

        @Override
        public ReactiveFeignCloudBuilder.Builder<T> addRequestInterceptor(ReactiveHttpRequestInterceptor requestInterceptor) {
            builder = builder.addRequestInterceptor(requestInterceptor);
            return this;
        }

        @Override
        public ReactiveFeignCloudBuilder.Builder<T> addLoggerListener(ReactiveLoggerListener loggerListener) {
            builder = builder.addLoggerListener(loggerListener);
            return this;
        }

        @Override
        public ReactiveFeignCloudBuilder.Builder<T> decode404() {
            builder = builder.decode404();
            return this;
        }

        @Override
        public ReactiveFeignCloudBuilder.Builder<T> statusHandler(ReactiveStatusHandler statusHandler) {
            builder = builder.statusHandler(statusHandler);
            return this;
        }

        @Override
        public ReactiveFeignCloudBuilder.Builder<T> responseMapper(ReactiveHttpResponseMapper responseMapper) {
            builder = builder.responseMapper(responseMapper);
            return this;
        }

        @Override
        public ReactiveFeignCloudBuilder.Builder<T> retryWhen(ReactiveRetryPolicy retryPolicy) {
            builder = builder.retryWhen(retryPolicy);
            return this;
        }

        @Override
        public Contract contract() {
            return builder.contract();
        }

        @Override
        public MethodHandlerFactory buildReactiveMethodHandlerFactory(PublisherClientFactory reactiveClientFactory) {
            if (circuitBreakerFactory == null) {
                builder.fallbackFactory(fallbackFactory);
                return builder.buildReactiveMethodHandlerFactory(reactiveClientFactory);
            } else {
                return new CircuitBreakerMethodHandlerFactory(
                        builder.buildReactiveMethodHandlerFactory(reactiveClientFactory),
                        circuitBreakerFactory,
                        (Function<Throwable, Object>) fallbackFactory);
            }
        }

        @Override
        public PublisherClientFactory buildReactiveClientFactory() {
            PublisherClientFactory publisherClientFactory = builder.buildReactiveClientFactory();
            return new PublisherClientFactory() {

                private Target target;

                @Override
                public void target(Target target) {
                    this.target = target;
                    publisherClientFactory.target(target);
                }

                @Override
                public PublisherHttpClient create(MethodMetadata methodMetadata) {
                    PublisherHttpClient publisherClient = publisherClientFactory.create(methodMetadata);
                    if (!target.name().equals(target.url()) && loadBalancerFactory != null) {
                        publisherClient = new LoadBalancerPublisherClient(loadBalancerFactory.getInstance(target.name()), publisherClient);
                        if (retryOnNextPolicy != null) {
                            publisherClient = retry(publisherClient, methodMetadata, retryOnNextPolicy.toRetryFunction());
                        }
                        return publisherClient;
                    } else {
                        if (retryOnNextPolicy != null) {
                            logger.warn("retryOnNextPolicy will be ignored " +
                                    "as loadBalancerFactory is not configured for {} reactive feign client", target.name());
                        }
                        return publisherClient;
                    }

                }
            };
        }
    }

}

as said this is for this use case:
     <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-kubernetes-fabric8</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-kubernetes-fabric8-all</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-kubernetes-fabric8-loadbalancer</artifactId>
        </dependency>

        <dependency>
            <groupId>com.playtika.reactivefeign</groupId>
            <artifactId>feign-reactor-webclient</artifactId>
        </dependency>
        <dependency>
            <groupId>com.playtika.reactivefeign</groupId>
            <artifactId>feign-reactor-cloud2</artifactId>
        </dependency>
        <dependency>
            <groupId>com.playtika.reactivefeign</groupId>
            <artifactId>feign-reactor-spring-configuration</artifactId>
        </dependency>

Hooray


Consolidate event collectors

Fix issues with event collectors for container events. Consolidate all collection to main handlers.

Current coverage is 57.47% (diff: 35.71%)

Merging #138 into master will increase coverage by 0.21%

@@             master       #138   diff @@
==========================================
  Files            30         30
  Lines          3755       3765    +10
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           2150       2164    +14
+ Misses         1464       1458     -6
- Partials        141        143     +2

Powered by Codecov. Last update 95c246a...5721444


chore(deps): lock file maintenance

looks like renovate still fails to update flake.lock

do you see the logs somewhere ? We don't have a renovate configuration file in this repo.

From the dashboard issue

These problems occurred while renovating this repository.

WARN: Error updating flake.lock

I think there website shows a more comprehensive log.


Several Issues with bukkit

Bukkit commands aren't working for me, and whenever I type something into the server console using the say command, no one sees it. Actually, nothing bukkit related is working come to think of it; they work in the console, however (I only tried it with a few of them that can even logically work in the console).
In addition, when I use the /give command on anything with a damage value, it doesn't give me the item and it says in the console "connection reset".
Anyways, here is my config:
http://pastebin.com/8aPqV6Fc

Try adding forwardUnknownCommands="true" to your group tags, that fixed it (mostly) for me. If that doesn't work, it is probably a permissions thing, or Bukkit is trying to use one of the essentials commands. Bukkit's permissions are, well, terrible. I found a magic way to use SimpleServer's groups and config to control Bukkit commands, but it requires that you change the plugin's source. If you know how to code in Java, it isn't too hard to find. Basically you change the command name that the plugin is listening for to something else, for example "money" to "cmoney" and then you add that command to SimpleServer's config with an alias. That way, SS get's a command of "/money", and sends the command to Bukkit as "/cmoney", allowing the plugin to do what it needs to without interference from other Bukkit stuff. It also allows you to use the clean and organized SS config instead of those horrible YAML files, and also save you having to move all of your groups and settings to Bukkit. If you are using the "/", you might want to disable chat forwarding as Bukkit will end up reading the commands twice. I like to use the "!" because that way I know that SS is reading it and not Bukkit, but it should (no promises) work either way. Hope I wasn't too confusing, I am terrible at explaining things like this XD.

I don't have essentials.

He doesn't have essentials. I know this because he's my friend; but you most likely aren't familiar with that word :D

well, "Bukkit is trying to use one of the essentials commands" sounds like essentials to me. You should be able to set if it sends it to bukkit via config files...
Also, for someone that advanced, I would recommend just bukkit, many incompatibilities with SS and bukkit.  Bukkit permissions is good, but I agree that YAML is not exactly user-friendly.

Sarcasm is apparently lost on you though :D

I get WAY to much sarcasm in my daily life, so it usually is.
On Nov 21, 2011, at 10:46 AM, BigBrick wrote:

Sarcasm is apparently lost on you though :D

Reply to this email directly or view it on GitHub:
https://github.com/SimpleServer/SimpleServer/issues/177#issuecomment-2809979


Material UI v6 + Remix + Vite running with “Prop className did not match” error

Steps to reproduce
Execute the following repository,

https://github.com/onozaty/remix-prisma/tree/mui-v6

Steps:

Open with DevContainer
npm run dev
Open http://<IP_ADDRESS>:5173/ in your browser

Current behavior
The following will appear in your browser's console
chunk-NUMECXU6.js?v=cbdf64e9:521 Warning: Prop `className` did not match. Server: "MuiPaper-root MuiPaper-elevation MuiPaper-elevation4 MuiAppBar-root MuiAppBar-colorPrimary MuiAppBar-positionStatic css-5iifl-MuiPaper-root-MuiAppBar-root" Client: "MuiPaper-root MuiPaper-elevation MuiPaper-elevation4 MuiAppBar-root MuiAppBar-colorPrimary MuiAppBar-positionStatic css-nt0iva-MuiPaper-root-MuiAppBar-root"
    at header
    at http://<IP_ADDRESS>:5173/node_modules/.vite/deps/chunk-56J7IAOU.js?v=cbdf64e9:528:45
    at Paper2 (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/@mui_material.js?v=cbdf64e9:1478:17)
    at http://<IP_ADDRESS>:5173/node_modules/.vite/deps/chunk-56J7IAOU.js?v=cbdf64e9:528:45
    at AppBar2 (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/@mui_material.js?v=cbdf64e9:4366:17)
    at div
    at http://<IP_ADDRESS>:5173/node_modules/.vite/deps/chunk-56J7IAOU.js?v=cbdf64e9:528:45
    at Box3 (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/chunk-POD3YRTN.js?v=cbdf64e9:3025:19)
    at div
    at http://<IP_ADDRESS>:5173/node_modules/.vite/deps/chunk-56J7IAOU.js?v=cbdf64e9:528:45
    at Container3 (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/chunk-POD3YRTN.js?v=cbdf64e9:4495:19)
    at App
    at body
    at html
    at Layout (http://<IP_ADDRESS>:5173/app/root.tsx:9:3)
    at RenderedRoute (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/@remix-run_react.js?v=cbdf64e9:4279:5)
    at RenderErrorBoundary (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/@remix-run_react.js?v=cbdf64e9:4239:5)
    at DataRoutes (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/@remix-run_react.js?v=cbdf64e9:5270:5)
    at Router (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/@remix-run_react.js?v=cbdf64e9:4624:15)
    at RouterProvider (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/@remix-run_react.js?v=cbdf64e9:5085:5)
    at RemixErrorBoundary (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/@remix-run_react.js?v=cbdf64e9:7146:5)
    at RemixBrowser (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/@remix-run_react.js?v=cbdf64e9:8692:46)
    at DefaultPropsProvider (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/chunk-POD3YRTN.js?v=cbdf64e9:3404:3)
    at RtlProvider (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/chunk-POD3YRTN.js?v=cbdf64e9:3380:3)
    at ThemeProvider (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/chunk-POD3YRTN.js?v=cbdf64e9:3336:5)
    at ThemeProvider2 (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/chunk-POD3YRTN.js?v=cbdf64e9:3487:5)
    at ThemeProviderNoVars (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/@mui_material.js?v=cbdf64e9:858:10)
    at ThemeProvider (http://<IP_ADDRESS>:5173/node_modules/.vite/deps/@mui_material.js?v=cbdf64e9:940:3)
    at MuiProvider (http://<IP_ADDRESS>:5173/app/mui.provider.tsx:12:3)

Expected behavior
Expect no errors in the browser console.
Context
This did not occur with Material UI v5.
The code for v5 is as follows.

https://github.com/onozaty/remix-prisma/tree/mui-v5

When I upgraded from Material UI v5 to v6, I initially got the following error with npm run dev.
3:39:56 PM [vite] Error when evaluating SSR module virtual:remix/server-build: failed to import "@mui/icons-material"
|- /workspaces/remix-prisma/node_modules/@mui/icons-material/esm/index.js:1
export { default as Abc } from './Abc';
^^^^^^

SyntaxError: Unexpected token 'export'
    at wrapSafe (node:internal/modules/cjs/loader:1281:20)
    at Module._compile (node:internal/modules/cjs/loader:1321:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1416:10)
    at Module.load (node:internal/modules/cjs/loader:1208:32)
    at Module._load (node:internal/modules/cjs/loader:1024:12)
    at cjsLoader (node:internal/modules/esm/translators:348:17)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:297:7)
    at ModuleJob.run (node:internal/modules/esm/module_job:222:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:316:24)
    at async nodeImport (file:///workspaces/remix-prisma/node_modules/vite/dist/node/chunks/dep-CzJTQ5q7.js:53536:15)
    at async ssrImport (file:///workspaces/remix-prisma/node_modules/vite/dist/node/chunks/dep-CzJTQ5q7.js:53392:16)
    at async eval (/workspaces/remix-prisma/app/routes/customers+/index.tsx:5:31)
    at async instantiateModule (file:///workspaces/remix-prisma/node_modules/vite/dist/node/chunks/dep-CzJTQ5q7.js:53451:5)

To avoid this, the following settings are added in vite.config.ts.
  ssr: {
    noExternal: [/^@mui\//],
  },

Now the screen itself can be displayed, but there is an error in the browser console.
Your environment

npx @mui/envinfo
  System:
    OS: Linux 5.15 Debian GNU/Linux 12 (bookworm) 12 (bookworm)
  Binaries:
    Node: 20.15.1 - /usr/local/bin/node
    npm: 10.7.0 - /usr/local/bin/npm
    pnpm: Not Found
  Browsers:
    Chrome: Not Found
  npmPackages:
    @emotion/react: ^11.13.3 => 11.13.3
    @emotion/styled: ^11.13.0 => 11.13.0
    @mui/core-downloads-tracker:  6.1.2
    @mui/icons-material: ^6.1.2 => 6.1.2
    @mui/material: ^6.1.2 => 6.1.2
    @mui/private-theming:  6.1.2
    @mui/styled-engine:  6.1.2
    @mui/system:  6.1.2
    @mui/types:  7.2.17
    @mui/utils:  6.1.2
    @types/react: ^18.2.20 => 18.3.3
    react: ^18.3.1 => 18.3.1
    react-dom: ^18.3.1 => 18.3.1
    typescript: ^5.1.6 => 5.5.3

Search keywords: Remix Vite

Same here.
v6.0.2 works like v5 without any vite.config.ts updates.
My workaround (only works for v6.1.2, not for v6.1.1) is to update vite.config.ts as below:
  ssr: {
    noExternal: [process.env.NODE_ENV === 'development' ? '@mui/icons-material' : /^@mui\//],
  },

In my case, remix vite:dev needs @mui/icons-material, and remix vite:build needs /^@mui\//. 🤯

Hey @onozaty, thanks for the report, and sorry for the late reply.
I'm unable to run your repro. May I ask you to provide further details (maybe a video) on how to run it? I'm stuck so far as I'm unclear where I should run npm run dev. Running it on remix-prisma doesn't work. I've never used DevContainer before so I'm not familiar with it.
Thanks @s-hashimo for chiming in, about your investigation:

"v6.0.2 works like v5 without any vite.config.ts updates."

This checks out as some minor ESM changes were introduced in 6.1.0 for the icons package

"My workaround (only works for v6.1.2, not for v6.1.1)"

This doesn't make sense as no changes to the icons package were introduced in 6.1.2, could it be a caching issue on your side that's installing stale packages?

could you provide a minimal repro of the behavior you're experiencing? This would help debug whatever is happening.

Thanks for replying. 😃
Here is my minimal? repro: https://github.com/s-hashimo/remix-vite-mui
And here are the commands to reproduce:
npm i
npm run dev

Warning: Prop className did not match. Server: "MuiTypography-root MuiTypography-h4 css-11pxkfa-MuiTypography-root" Client: "MuiTypography-root MuiTypography-h4 css-ys13zx-MuiTypography-root" Error Component Stack

It's based on the following two packages:

https://github.com/mui/material-ui/tree/f56770186cef04959ef733fffddd1b86683cecda/examples/material-ui-remix-ts
https://github.com/remix-run/remix/tree/9f06bfb7397daa8a3719552e2cbda7c4c8d06a38/templates/express

I suppose that the type=module in package.json causes "SyntaxError: Unexpected token 'export'".

Hey @onozaty, thanks for the repro.
I spent some time debugging this, but unfortunately, I still haven't figured out what's happening. I checked that the className mismatch warning also happens when using v5.16.6 (the latest v5 version) with the app you shared. Do you know of a v5 version in which this didn't happen?
We've had similar issues with next: https://github.com/mui/material-ui/issues/29428
I'm not seeing this error in our Remix example: https://github.com/mui/material-ui/tree/master/examples/material-ui-remix-ts, so if it's a possibility for you to start using that, then it might help. It might also help to compare with your current setup.
If you confirm that this is also happening in v5, I think we can accept the issue as a remix integration improvement.

Thank you for working on this issue.

I spent some time debugging this, but unfortunately, I still haven't figured out what's happening. I checked that the className mismatch warning also happens when using v5.16.6 (the latest v5 version) with the app you shared. Do you know of a v5 version in which this didn't happen?

This did not occur in v5.16.7.
Below is the branch that confirmed it.

https://github.com/onozaty/remix-prisma/tree/mui-v5

We've had similar issues with next: #29428
I'm not seeing this error in our Remix example: https://github.com/mui/material-ui/tree/master/examples/material-ui-remix-ts, so if it's a possibility for you to start using that, then it might help. It might also help to compare with your current setup.

This example provided by MUI does not use Vite.
The templates provided by Remix use Vite, and it is common practice to use Vite.
I think it will be easier for Remix users to use MUI if it becomes Vite-compatible as a template for MUI.
Thanks.

I get the SyntaxError: Unexpected token 'export' error here as well: node 20.17.0, remix 2.14.0, vite 5.4.10 and upgrading from mui 5.16.7 to 6.1.7. With node 22.11.0, the error changes to the below. Looks like in node 20 it's trying the import as cjs, but on node 22 it tries it as esm, and it's failing in either case:

Directory import '/Users/samir/Projects/client-portal/node_modules/.pnpm/@mui+icons-material@6.1.7_@mui+material@6.1.7_@emotion+react@11.13.3_@types+react@18.3.12_rea_fjnihmbedo2nhrt4stuurnmvmi/node_modules/@mui/material/utils' is not supported resolving ES modules imported from /Users/samir/Projects/client-portal/node_modules/.pnpm/@mui+icons-material@6.1.7_@mui+material@6.1.7_@emotion+react@11.13.3_@types+react<EMAIL_ADDRESS>Did you mean to import<EMAIL_ADDRESS>at finalizeResolution (node:internal/modules/esm/resolve:251:11)
at moduleResolve (node:internal/modules/esm/resolve:913:10)
at defaultResolve (node:internal/modules/esm/resolve:1037:11)
at ModuleLoader.defaultResolve (node:internal/modules/esm/loader:650:12)
at ModuleLoader.#cachedDefaultResolve (node:internal/modules/esm/loader:599:25)
at ModuleLoader.resolve (node:internal/modules/esm/loader:582:38)
at ModuleLoader.getModuleJobForImport (node:internal/modules/esm/loader:241:38)
at ModuleJob._link (node:internal/modules/esm/module_job:132:49

Hmm I tried this and the errors changed a little:
-    "@mui/icons-material": "5.16.7",
-    "@mui/material": "5.16.7",
-    "@mui/system": "6.1.7",
+    "@mui/icons-material": "https://pkg.csb.dev/mui/material-ui/commit/32a26054/@mui/icons-material",
+    "@mui/material": "https://pkg.csb.dev/mui/material-ui/commit/32a26054/@mui/material",
+    "@mui/system": "https://pkg.csb.dev/mui/material-ui/commit/32a26054/@mui/system",

Node 20:

Unexpected token 'export'
at wrapSafe (node:internal/modules/cjs/loader:1378:20)
at Module._compile (node:internal/modules/cjs/loader:1428:41)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1548:10)
at Module.load (node:internal/modules/cjs/loader:1288:32)
at Function.Module._load (node:internal/modules/cjs/loader:1104:12)
at cjsLoader (node:internal/modules/esm/translators:346:17)
at ModuleWrap. (node:internal/modules/esm/translators:286:7)
at ModuleJob.run (node:internal/modules/esm/module_job:234:25)
at ModuleLoader.import (node:internal/modules/esm/loader:473:24)
at nodeImport<EMAIL_ADDRESS>

Node 22:

Cannot find module '/Users/samir/Projects/client-portal/node_modules/.pnpm/@mui+icons-material@https+++pkg.csb.dev+mui+material-ui+commit+32a26054+@mui+icons-material_@cgxqzfntsowwhxpfsrw3v3vtae/node_modules/@mui/icons-material/esm/Abc' imported from /Users/samir/Projects/client-portal/node_modules/.pnpm/@mui+icons-material@https+++pkg.csb.dev+mui+material-ui+commit+32a26054+@mui+icons-material<EMAIL_ADDRESS>

it looks like we have to do both of those for the icons package as well to get rid of this issue.

👍 yes, full esm support for node.js is planned for v8.

To clarify, does this mean it won't be usable until v7, or is there an earlier patch coming?

@mikezx6r may I ask you which package manager are you using?
@Janpot can you think of a way to workaround this in the meantime?
I tried patching, but couldn't get it working with npm (and couldn't repro with yarn or pnpm)
In the meantime, if anyone wants to give it a try, I think following a similar approach as this comment might work, let us know.

I am using npm. Will take a look at link to see if it helps.On Dec 3, 2024, at 14:32, Diego Andai @.***> wrote:
@mikezx6r may I ask you which package manager are you using?
@Janpot can you think of a way to workaround this in the meantime?
I tried patching, but couldn't get it working with npm (and couldn't repro with yarn or pnpm)
In the meantime, if anyone wants to give it a try, I think following a similar approach as this comment might work, let us know.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

@DiegoAndai  I've read the comment, but it claims that icons-material has already been fixed.
In my case, that's the ONLY package that is giving me issues. Here's a link to a small project that demonstrates the issue.
https://github.com/mikezx6r/react-router-mui-icon-issue
Let me know if there's anything else I can do for this, or if I didn't understand the suggestions in the comment correctly

@Janpot can you think of a way to workaround this in the meantime?

I haven't tested this, but since you're already patching, you could try to patch the icons package and remove its exports field in the package.json. Then add this alias to your vite config.
I'm sorry, I'll still be out a bit longer (paternity leave). Should be back by January.

In my case, that's the ONLY package that is giving me issues.

If the icons package is the only one giving issues, have you tried pinning it to a previous version? That might work, and you can unpin it once v7 is released. This package won't receive significant updates in v6, so I don't expect you missing anything if you pin it to a previous version that works.
Let me know.

@DiegoAndai pinning icons-material to v5 solved my problem 👍
Thanks for the suggestion!

I'm glad to hear that @samausir. I think you should also be able to use v6.0.2.
When v7 comes out, you should be able to migrate to it and not have this issue.

Can confirm v6.0.2 works too 👍

@DiegoAndai
Hi mate,
We have the same issue with jest (ESM).
Details:

/Users/chengjia/Projects/apra-amcos-portals-frontend/node_modules/@mui/icons-material/esm/index.js:1
({"Object.<anonymous>":function(module,exports,require,__dirname,__filename,jest){export { default as Abc } from "./Abc.js";
                                                                                ^^^^^^

SyntaxError: Unexpected token 'export'

It happens after upgraded to v6.0.2
Thanks

Still happening. I just tested it with a clean project. See the issue: #44822


LookaheadScope Breaks remeasure on window change

Describe the bug
All content contained inside a LookahedScope seems to not react to parent element size changes. If for example i change the window size with a single Box inside of a LookahedScope that has Modifier.fillMaxSize(), the size of the Box will not change. Without the LookahedScope the Box will however change size accordingly.
Affected platforms
Select one of the platforms below:

All (maybe?)
Desktop (tested occurring)

Versions

Kotlin version*: 1.9.10
Compose Multiplatform version*: 1.5.3 & 1.5.11
OS version(s)* (required for Desktop and iOS issues): Ubuntu latest
OS architecture (x86 or arm64): x86
JDK (for desktop issues): OpenJDK 11

To Reproduce

Put the code in a empty Window.
Code:

LookaheadScope{
  Box(Modifier.fillMaxSize().background(Colors.Red))
}

Try and resize the window

Expected behavior
Box should change size with the window
Screenshots
Will add if needed.
Additional context

Rechecked with Box as in the Example and it works as expected. The problem seems to only occur with a Surface contained in LookaheadScope. This code instead of the above has the described issue:
LookaheadScope{
    Surface(modifier = Modifier.fillMaxSize(), color = Color.Red){
    }
}

The simple workaround for anyone wondering seems to be:
LookaheadScope{
    Box(Modifier.fillMaxSize()){
        Surface(modifier = Modifier.fillMaxSize(), color = Color.Red){
        }
    }
}

The Surface will then change size accordingly.
Still wierd behaviour.

In my testing Box and Surface worked the same (no resizing).
However, this looks like a bug in Jetpack Compose, which has already been fixed but we haven't pulled the fix in yet. It does behave slightly differently on Android - it does resize sporadically, whereas it doesn't resize at all on the Desktop, so there's a small chance there's an extra bug on the desktop. But I would wait until we merge Google's fix before investigating further.

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.


WALK not merging non-date queries correctly

Saw it with default channel grouping via Simon

If a walked data fetch is over 10000 not all data is fetched. Need to have batch within walked data as well as out.

This is now handled in the v4 data fetches, which will unsample very large batches now problem.  It is also implemented in a manner which sends less API hits so should be a lot quicker.
> library(googleAnalyticsR)
> ga_auth()
> unsampled_data_fetch <- google_analytics_4(id,
                                             date_range = c(“2015-01-01”,”2015-06-21"),
                                             metrics = c("users","sessions","bounceRate"),
                                             dimensions = c("date","landingPagePath","source"),
                                             anti_sample = TRUE)

anti_sample set to TRUE. Mitigating sampling via multiple API calls.
Finding how much sampling in data request...
Data is sampled, based on 39.75% of visits.
Downloaded [10] rows from a total of [59235].
Finding number of sessions for anti-sample calculations...
Downloaded [172] rows from a total of [172].
Calculated [3] batches are needed to download [59235] rows unsampled.
Anti-sample call covering 128 days: 2015-01-01, 2015-05-08
Looping over [2] batches.
Fetching data...
Fetching data...
Downloaded [59235] rows from a total of [59235].
Anti-sample call covering 23 days: 2015-05-09, 2015-05-31
Looping over [2] batches.
Fetching data...
Fetching data...
Downloaded [20239] rows from a total of [20239].
Anti-sample call covering 21 days: 2015-06-01, 2015-06-21
Looping over [2] batches.
Fetching data...
Fetching data...
Downloaded [21340] rows from a total of [21340].
Finished unsampled data request, total rows [100814]
Successfully avoided sampling


Support for anko layout.

Are you going to support anko layout?

Nope, it's dead. Google have annouced something this year to replace it.


Update index.html

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Trigger event


Fix shader compiler asan out of bounds

Fixes #68623
ShaderLanguage::get_scalar_type and ShaderLanguage::get_cardinality index into an array, but as new elements were added to enum DataType these arrays have not been updated.
An UB out of bounds read occurs if any type > TYPE_SAMPLER2DARRAY is passed as arguments to a function, including *Sampler2DArray, *Sampler3D, SamplerCube(Array), and Struct.
Examples of shaders producing this bug (4.0 and 3.x):
shader_type spatial;

uniform sampler3D tex;

void fragment() {
    ALBEDO = texture(tex, vec3(0.0)).rgb;
}

shader_type spatial;

struct Foo {
        float bar;
};

float get_bar(Foo foo) {
        return foo.bar;
}

void fragment() {
        Foo foo = Foo(0.5);
        ALBEDO = vec3(get_bar(foo));
}

The fix is to add the missing values, and add a check to ensure that the length of the array matches the number of types. I tried to match the values, but as far as I can tell from how get_scalar_type and get_cardinality are used, if the type doesn't have a constructor then the exact values don't matter, as long as get_scalar_type(type) != type.
This PR is compatible with 3.x, once TYPE_MAX is added to enum DataType.

An UB out of bounds read occurs if any type > TYPE_SAMPLER2DARRAY is passed as arguments to a function

Why not simply detect where it's doing in the fog pipeline and fix that? Or simply limit it by adding ERR_FAIL_INDEX to the beginning of get_scalar_type and get_cardinality?

This bug is not in the fog pipeline, it is a bug in ShaderLanguage that occurs while parsing any gdshader that calls a function with a Sampler or Struct argument.
I suppose this could be fixed with a CLAMP, but then get_scalar_type(TYPE_USAMPLER3D) would return TYPE_FLOAT while get_scalar_type(TYPE_USAMPLER2D) would return TYPE_UINT. The commit that introduced get_scalar_type, 850eaf7e, makes it clear to me that there is intended to be a 1:1 mapping of DataType to get_scalar_type.

This bug is not in the fog pipeline, it is a bug in ShaderLanguage that occurs while parsing any gdshader that calls a function with a Sampler or Struct argument.

I suppose this could be fixed with a CLAMP, but then get_scalar_type(TYPE_USAMPLER3D) would return TYPE_FLOAT while get_scalar_type(TYPE_USAMPLER2D) would return TYPE_UINT. The commit that introduced get_scalar_type, https://github.com/godotengine/godot/commit/850eaf7ed796d2f2d9a35c6bc4ba9a4e69f5ca1d, makes it clear to me that there is intended to be a 1:1 mapping of DataType to get_scalar_type.

You are right, never mind, I just not completely awakened

Thanks!

Do we still want to set all the sampler types to TYPE_VOID? I tested an asan build and it appears to work.


Elastic agents are broken in gocd 18.1.0

With gocd 18.1.0 released, one of the changes made was to move the elastic profiles out of the server config. This breaking the elastic profiles being created with gomatic against gocd 18.1. The error I get trying to update my elastic profile:
File "/usr/lib/python3.6/site-packages/gomatic/go_cd_configurator.py", line 296, in save_updated_config
    self.__host_rest_client.post('/go/admin/restful/configuration/file/POST/xml', data, headers)
  File "/usr/lib/python3.6/site-packages/gomatic/go_cd_configurator.py", line 335, in post
    raise RuntimeError("Could not post config to Go server (%s) [status code=%s]:\n%s" % (url, result.status_code, message))
RuntimeError: Could not post config to Go server (http://localhost:8153/go/admin/restful/configuration/file/POST/xml) [status code=409]:
Invalid content was found starting with element 'elastic'. One of '{mailhost}' is expected.

I could move the elastic config to be out of the <server> tag but it would break for all the older gocd versions.

What about checking against the version to decide what to do? You can get the current gocd version from the configurator object now:
https://github.com/gocd-contrib/gomatic/blob/8de4878c28f2d6103ad74a635f620c134efccac9/gomatic/go_cd_configurator.py#L65

Nice, will do that and create a PR :)


not working

please sopport for xcode 8.2.1 , many thank for you.

You have to sign all the targets.

Doesn't seem to work even if I sign all targets. Can you be more specific?
I'm running Xcode 9


Best way to store UUIDs as _id?

Hi! Normally I store UUIDs using Mongo's UUID function, which is more performant than storing the hexadecimal string representation. However, I'm unsure how to properly achieve this in Papr.
Could anyone point me in the right direction? Thanks.

I think you can use the exported UUID class from the bson library.

I think you can use the exported UUID class from the bson library.

Unfortunately the UUID class is not compatible with any of the types Papr accepts for _id.


Error message by klayout as it does not find the .lyp file

Expected Behavior
klayout starts w/o error message.
Actual Behavior
When klayout is started with klayout -e -nn $PDKPATH/libs.tech/klayout/tech/$PDK.lyt -l $PDKPATH/libs.tech/klayout/tech/$PDK.lyp example.gds then the following error message is shown:
Warning: Initialization of layers failed: Unable to open file: /headless/.klayout/tech/sky130/sky130.lyp (errno=2)
When looking into the .lyt file, the following can be seen:
<base-path>$(appdata_path)/tech/sky130</base-path>
 <original-base-path>$(appdata_path)/tech/sky130</original-base-path>
 <layer-properties_file>sky130.lyp</layer-properties_file>

Question:

Why the reference here to appdata_path? The agreed quasi-standard is to use $PDK_ROOT and $PDK.
Why the reference to sky130.lyp and not to sky130A.lyp or sky130B.lyp?

Steps to Reproduce the Problem
Install our Docker (https://github.com/iic-jku/iic-osic-tools) and try it. See also https://github.com/iic-jku/iic-osic-tools/issues/6
Specifications
See Docker VM.

@hpretl for the sky130.lyp vs sky130A.lyp error I think this is related to https://github.com/RTimothyEdwards/open_pdks/issues/332#issuecomment-1632079484


pageRangeDisplayed set to 1, disables the First_Page link

FirstPage link is always disabled if I set pageRangeDisplayed={1}. Is there any workaround for this?

Hey there!
Unfortunately that's currently not possible.
If you find that very important, we can add a new prop (e.g. enableFirstPage) and use it in this line: https://github.com/vayser/react-js-pagination/blob/master/src/components/Pagination.js#L114
Could you create the PR?

fixed in 3.0.0 version


Pretty print leaves extra space at end of many lines

This one demonstrates far easier.  At end of most lines, there is an extra whitespace being added.  This should be trimmed so there is no extra whitespace at end of tags.
Saved https://try.jsoup.org/~pWWgM1Tq8l3YM1WTm8Fftq5ziv4

A fix can either be added to the code, or if you're doing in yourself you could add "String".stripTrailing() to remove the trailing whitespace from a string.

we have it fixed on our end but prefer its fixed in the source of the issue.
Here is how.
/** The Constant REMOVE_TRAILING_PATTERN. */
private static final Pattern REMOVE_TRAILING_PATTERN = Pattern.compile("\\p{Blank}+$", Pattern.MULTILINE);
...
// Fixing trailing space issue caused by jsoup
formattedCode = REMOVE_TRAILING_PATTERN.matcher(formattedCode).replaceAll("");

I'll plug this in and see if I can get my first commit accepted.

Thanks! Have fixed this by checking in TextNode if the node is just a newline + empties, which can be safely whitespace normalized away. Effectively, this means if the parent element created an indent, if this TextNode (on re-parse) is the content of that indent, we should skip it.
This is a relatively new issue - in earlier versions of jsoup, these TextNodes (\n\s+) would have been dropped during parsing. We changed that to better preserve content when pretty printing was disabled, but that caused this knock-on impact.

@hazendaz, can you please verify these pretty print issues are fixed (with a snapshot install)? LMK if there are outstanding issues. Thanks!

This one is not fixed based on lastest master.  Have tested multiple times in last hour or so.  To fix this, the snippet of code I showed earlier is still needed to patch externally after formatting is done.

@jhy Is it possible you can release out a release candidate or if you are ready just cut a release?  We are significantly behind on the formatter plugin with fixes in this release with tabbing limits so unable to at least push up a test there that is coherent with latest codebase.  A release candidate or full release will help.  My outstanding issues are far less important even if a release were to occur as they already existed for some time.  Our tests are running 2 passes on all file types to ensure both times formatting processes that it is the same result.  The extra space issue here I have a patch on our end for it which I can use to get around this one.  The other two PRs I have outstanding while ideal to have fixed they don't harm processing (just not perfect).  I'm fine with the other issues moving to subsequent release given my main issue was the

@hazendaz sure - I'm not ready with a release yet, but I deployed a snapshot RC. You should be able to grab it with
<dependency>
  <groupId>org.jsoup</groupId>
  <artifactId>jsoup</artifactId>
  <version>1.15.1-SNAPSHOT</version>
</dependency>

It may take a moment to sync to the Central Maven Repo after publishing. Delivery repo is at https://oss.sonatype.org/content/repositories/snapshots/org/jsoup/jsoup/1.15.1-SNAPSHOT/jsoup-1.15.1-20220103.051042-1.jar
I plan to do a full release shortly (next week or so).

This one is not fixed based on lastest master. Have tested multiple times in last hour or so. To fix this, the snippet of code I showed earlier is still needed to patch externally after formatting is done.

Hmm - there must be another instance of it coming from somewhere. I certainly fixed a set of issues where on repeat serialize -> parse -> serialize, extra spaces were added after closing tags (coming from a "\n  " getting normalized to a " " text output. Examples are in the changed testcases, was appearing on head, body etc.
Will take another pass at your testcase.

Can you reopen this one?  This is now in our 'main' at https://github.com/revelc/formatter-maven-plugin, just run 'mvn clean install', then go to target/testoutput/someFile.html.  Look at trailing spaces left throughout.  While we have code that has expanded our ability to trim whitespace that now entirely resolves this for end users, it would be nice to fix in proper location.

@jhy Even though not all fixed, is it possible we can get a release out as-is?  Its at least a good improvement for us and we need to get ours released soon and I'd prefer not to drop back off the current snapshot as that requires us go back multiple versions.

@jhy Or if not 100% with what you wanted, can you release a milestone?

I'm interested in a stable version containing this fix too. My tests failed because of this issue.

I'd be interested in a stable version containing this fix too. My tests failed because of this issue.

@jhy  I just bumped into this issue as well and I was baffled to find out that the resulting document contains "random?" spaces added to the closing tags of elements etc. There doesn't seem to be a logical pattern. I also noticed that with another input file, which literally contains the same HTML content, this didn't happen. There must be something going on with the parsing of linefeed / carriage returns / ... I was also able to somehow let Jsoup output (literally) \r in the resulting document (instead of a carriage return, so probably somewhere the \ was escaped?
Would be nice to get some fixes for this. :)


Overwriting repr for str subclasses results in ValueError: malformed node or string raised within the ast module

Description of the problem
Weird output in the internal console when trying to overwrite the special method __repr__ for subclasses of str.
Minimal test case
For reproducing the problem, the following test class should be sufficient:
class Test(str):
    def __repr__(self):
        return 'something'

Writing...
Test()

...returns (as expected):
something

But when I write...
test = Test()

...the following error message is returned:
raise ValueError('malformed node or string: ' + repr(node))
ValueError: malformed node or string: <_ast.Name object at 0x000000005FD5B550>

So far, I could reproduce this problem only when using the IPython console in Spyder.
Versions and main components

Spyder Version: 3.2.3
Python Version: 3.6.3
Qt Version: 5.6.2
PyQt Version: 5.6.0
Operating system: Windows

Dependencies
IPython >=4.0    :  6.1.0 (OK)
cython >=0.21    :  0.25.2 (OK)
jedi >=0.9.0     :  0.10.2 (OK)
nbconvert >=4.0  :  5.1.1 (OK)
numpy >=1.7      :  1.13.3 (OK)
pandas >=0.13.1  :  0.20.1 (OK)
pycodestyle >=2.3:  2.3.1 (OK)
pyflakes >=0.6.0 :  1.5.0 (OK)
pygments >=2.0   :  2.2.0 (OK)
pylint >=0.25    :  1.6.4 (OK)
qtconsole >=4.2.0:  4.3.1 (OK)
rope >=0.9.4     :  0.9.4-1 (OK)
sphinx >=0.6.6   :  1.5.1 (OK)
sympy >=0.7.3    :  1.0 (OK)

Thanks for reporting @tyralla. I think this is related with #5636, PR #5746 implements a fix. Would you like to help us testing the PR I mention to see if that fixes this issue?

Closing as a duplicate of issue #5636. Feel free to keep posting about this on PR #5746.