[Mod Update]CParts

Mod info

Mod name: CParts
Description: CParts: CFYL's Chinese style parts pack. CParts introduces new textures, new parts, and new ways of going to space!
Author(s): CFYL, AtomicTech
License: CC-BY-NC-SA-4.0
Homepage: https://forum.kerbalspaceprogram.com/index.php?/topic/200222-112xcparts-cfyls-chinese-style-parts-pack-now-with-cz-1/
Download: https://github.com/CFYL/CParts/releases/download/v1.1.0/CParts_v1.1.0.zip
Require: Waterfall
Require: Module Manager
Recommend: Persistent Rotation
Suggest: Stock Waterfall Effects
Suggest: SRB Waterfall Effects
Spacedock probably has sent an automatic issue to you. But I personally think that this manual issue would be more accurate. Thank you!

I read  that adding a CParts.version file would make it easier for you to update. I don't update my mod very often so... I might include it in my next update, which is planned for 2023... Thank you all the same.

I read  that adding a CParts.version file would make it easier for you to update. I don't update my mod very often so... I might include it in my next update, which is planned for 2023... Thank you all the same.

I read (https://github.com/Industrial-Pigeon-and-Magic/KerwisChineseAerospacePack/pull/1) that adding a CParts.version file would make it easier for you to update. I don't update my mod very often so... I might include it in my next update, which is planned for 2023... Thank you all the same.

I believe this was added in #8361 in response to the "Add to CKAN" checkbox being checked on SpaceDock.

Thanks for contacting us! These changes should be live for users in about 35 minutes or sooner.
Regarding a .version file, the difficulty in the case of Industrial-Pigeon-and-Magic/KerwisChineseAerospacePack#1 was specifically that the ksp_version_min property was contained within the .netkan file, which required regular manual updates to keep it up to date. For CParts we don't have that; we simply use the compatibility that you choose on https://spacedock.info/mod/2638/CParts :

The advantage of a .version file would be that you could choose a wider range of compatible versions.


GCM sink is too slow in flushing data

GCM sink takes a long time to flush metrics. The delay is more pronounced under scale (100 node cluster or running a lot of containers). Is it possible to alter the flushing model for GCM sink and make it perform lesser number of GCM requests?

Will take a look

I can take a look.

FWIW, we've tested it on larger cluster and it has been okay. Since we only scrape data every few mins.

Ok. Thanks for the update. Did you test it with many pods (i.e. 100 nodes, 10 pods/node)?

IIRC we tested on a 100node cluster but more likely with 5 pods/node

Sounds reasonable. Should this issue be closed?

GCM sink was rewritten.


PIL Image

Does it make sense to have a PIL Image traittype in here? If so, it would add a dependency. Or it could be an optional dependency.

Most of these types have now been set up to have optional dependencies (i.e. if you use the ndarray one, it assumes you have numpy). As such, I have no strong opinions either way.

I think that it makes sense.


KeyError: 'message'

When implementing your provided code for summarization, I encountered an error in response. The error message was as follows:
KeyError: 'message'
I have attempted various solutions to rectify this issue, but I have not been successful in resolving it. I kindly request your assistance in addressing this matter.
Here is the code that I have utilized:
llm = G4FLLM(
model=models.gpt_35_turbo,
provider=Provider.Aichat,
)
def summarize_pdf(pdf_file_path):
loader = PyPDFLoader(pdf_file_path)
docs = loader.load_and_split()
chain = load_summarize_chain(llm, chain_type="map_reduce")
summary = chain.run(docs)
return summary
summarize = summarize_pdf("war_update.pdf")
print(summarize)

@muhammadhasnain100
Thanks for the report.
Could you share all error messages?
Also, could you share the pdf file if possible?

@muhammadhasnain100
My guess is that the Aichat rate limit is the cause of the error.
Please try another provider.
Based on your code, I have added a sample using "load_summarize_chain".
Please refer to it.
ca9c9aef0529464093f4ebf2524b75985b8b64fb

Thank You very much


back off sass-rails specificity

Is there a way to test this against the newer versions of sass-rails?

I imagine this will work straight with me merging it and pushing a new release right now but I'm tired, which means it's probably a really bad thing to do right this minute.
I'll get to this first thing in the morning.

If I'm reading this correctly this will allow bootstrap-sass to use sass-rails 3.2, correct?

Just ran into this myself. Rails v3.1rc1 has sass-rails v3.2.2 as a dep.

@rjackson That's my understanding of it, I had to look up the exact definition myself. ~> 3.1.0 locks to 3.1.x, while ~> 3.1 locks to 3.x, where x > 1.


Android build failure with 0.0.1-beta.12, Expo

Describe the bug
When attempting to build in an Expo app on Android, the following error occurs:
Execution failed for task ':app:mergeDebugJavaResource'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.MergeJavaResWorkAction
   > 2 files found with path 'org/bouncycastle/x509/CertPathReviewerMessages_de.properties' from inputs:
      - /Users/nprail/.gradle/caches/transforms-3/9314ebc5fafe4a65de1c36cd8bab2f4d/transformed/jetified-stripeterminal-localmobile-2.20.1/jars/classes.jar
      - /Users/nprail/.gradle/caches/transforms-3/d67656dc5217008b8b17f4eb57d4d252/transformed/jetified-bcprov-jdk15to18-1.69.jar
     Adding a packagingOptions block may help, please refer to
     https://developer.android.com/reference/tools/gradle-api/7.4/com/android/build/api/dsl/ResourcesPackagingOptions
     for more information

To Reproduce
Steps to reproduce the behavior:

Create an Expo project (specifically<EMAIL_ADDRESS>Install<EMAIL_ADDRESS>Run npx expo prebuild -p android
Run Android with npx expo run:android
Build fails with the above error

Expected behavior
The build should succeed :)
Stripe Terminal React Native SDK version

0.0.1-beta.12

Smartphone (please complete the following information):
N/A, build failure
Additional context
Other dependencies in the project:
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>

Hi @nprail,
I ran into the same issue with expo, and have found a solution. This issue will cause all builds(local and eas) to fail, and can not be easily fixed for expo managed mobile apps. This is a big issue for Production apps, and is disappointing that a fix has not been added to the library, or given actual direction for the specific framework. This issue and solution should be added to the readme since eas builds do not work, and makes this library not usable for expo applications without ejecting.
Solution:

Add expo-build-properties library to project.
Add the code below to your app.json inside the "expo" object.

"plugins": [
  [
     "expo-build-properties",
     {
	  "android": {
		  "packagingOptions": {
			  "exclude": ["org/bouncycastle/x509/CertPathReviewerMessages*"]
		  }
	  }
     }
  ]
]

delete android folder and rebuild.

Note: I have had many issues along these lines with this library. I understand that this is a beta library and have worked with many beta libraries in the past. I do not expect this library to be perfect, but the documentation and communication from the developers has been frustrating and not very helpful. If you are looking into using terminals with an expo application, I would recommend looking into different solutions. I hope solution helps other developers

Another option is to use the pickFirst strategy for the packagingOptions, which ensures that the first matching result is included in the resulting apk:
"plugins": [
  [
     "expo-build-properties",
     {
	  "android": {
		  "packagingOptions": {
			  "pickFirst": ["org/bouncycastle/x509/CertPathReviewerMessages*"]
		  }
	  }
     }
  ]
]


[BUG] Some photos have large frames

Describe the bug
Some photos have large frames, unlike normal ones

To Reproduce
Steps to reproduce the behavior:

Download this photo (maybe)

Open gallery

Expected behavior

Smartphone (please complete the following information):

Device: Nothing Phone 1
OS: Android 14 / nothingOS 2.5.5
Version 2.1.2

Fixed, will be available in the nightly soon


One ways are confusing, can we make it more obvious

Browsing around I've found that many one-ways are incorrect -- people mark them properly as a one-way street, but the direction is incorrect. Marking it as yes is easy, but then you have to look at the direction of the way, and I think doing oneway = -1 is confusing to people who aren't expert street editors, you have to go down to all tags, change "yes" to -1.
Maybe when you select one way it says "which direction is it?" Or some other way to make it more apparent.
This seems to be very common from some analysis I've seen, like ~40% being wrong.

I haven't really heard that oneways are confusing before.  Can you elaborate?  iD provides a button to easily switch the direction of a way.

Ah, I wasn't aware of that and I've been using iD for a long time. When you click the one way checkbox on the tag box on the left it just makes it go the same direction as you drew it, then you either have to know to go down to All tags and type "-1" or know to go over to the side and fix it with the big above -- like I said I think it's a bit tricky and not intuitive unless you already know what to do.

Is there anything actionable here or can this be closed?  It might be worth adding some more text to the builtin help, or adding a task involving oneways in the walkthrough.

I sent a mockup idea to @mikelmaron for a way to make it more straightforward. The walkthrough idea would be good as well. I just think it's too easy to click "yes" and not realize the direction is wrong.

Attached are the mockups from @aawiseman
One way mockup (1).pdf
I think there's something here -- thought much to be thought through in UI. The idea of bringing the oneway directionality choices here more obviously into the editing panel, and styling less subtlely, seems solid.

~40% being wrong.

@aawiseman it would really be helpful to see details on this research, say for one city, to get a clearer idea of the connection of the problem to the UI

Echoing what @mikelmaron said, I'd like to see some details about where you see this mistagging occurring.. 40% seems kind of high to me.
I've always considered the real value of the oneway tag to be an implementation detail - new mappers shouldn't need to know whether it says yes, 1, -1, no, or care too much about which direction the way is drawn, as long as iD renders the oneway arrows correctly and clearly and provides a button to change the direction of the way.
Looping in @samanpwbb, @tmcw because they probably have some insight into the original design of this iD feature.

💭 It's been a while so I may not have this 100%, but:

It's true that most tag properties are in the left pane
But oneway is entirely dependent on the line's draw direction, so its value on the left panel doesn't mean anything outside of the draw direction.
So showing the value in the left panel doesn't really help editing, because it doesn't mean anything by itself
But I can imagine someone who both knows OSM and knows it's a tag and thinks properties will be all on the left side and assumes oneway will be
In that case, the fix, I think, would be to show some nice helptext on the left side that explains how to use the map UI.
But overall the 40% number needs a citation. My distrust of anecdotal iD damage is, as always, high.

But oneway is entirely dependent on the line's draw direction, so its value on the left panel doesn't mean anything outside of the draw direction.
So showing the value in the left panel doesn't really help editing, because it doesn't mean anything by itself

Yeah, the mockup I did that Mikel posted above gets to that. I think that's the issue, you have to know to both click one way and then go over and change direction on the line as well, which is not obvious or self-evident. I think the way it does it now is good but too subtle, and sometimes even hidden by the semi-circle of buttons.

Oneway (and any other direction/side dependent tag) should have an additional button in its preset field. This button should change the direction of the oneway property:

In case of oneway=-1 change to oneway=yes
In case of oneway=yes iD might change the direction of the way in order to avoid oneway=-1

The radial menu action to change way direction should be limited to not changinmg the meaning of the data. In case of oneway=yes it needs to be disabled or oneway=-1 needs to be generated.
A radial menu action to change the way direction with change of all directional meanings might be offered too, but this should use a modifier key or a different icon. Please be aware that a way might have multiple direction independent tags. For example #1762 would add some.
Similar handling of other direction or side dependent tags could solve #1475 .

By the way bicycles are often exempted from the oneway restriction. Therefore the oneway preset should have a checkbox to specify this. Do we need a separate issue for this?

Updating per a chat at SOTM-US, sounds like @bhousel was going to add some functionality to make it more clear. Thanks!

Yes, I was definitely thinking about this the wrong way...
To summarize our discussion, users tag oneways using the checkbox in the left pane, and they might even realize the oneway direction is wrong, but the step to fix it is hidden under the confusing "<<" icon which is not where they are looking (and maybe not even visible if the radial menu is not currently shown).  A quick fix would be to add a small "reverse direction" link / button / something near the oneway checkbox.

Awesome! The mockup I posted above also had something like making the arrows within the line flash or something so it's super clear, think that's necessary? https://github.com/openstreetmap/iD/issues/3060#issuecomment-210211710

making the arrows within the line flash or something so it's super clear, think that's necessary?

Yeah I'll see if we can do something with the arrows to make them more visible.  I haven't looked at this much since we changed the colors last year, and in your screen shot the one way arrows on the narrow service road are definitely not showing clearly.

@bhousel , the "Put something here" position is ok, but I thing placing it one line above in the titelbar of the oneway preset field might be better for the following reason:
The "Put something here" position would be the ideal position if it were just a change of the tag like toggling oneway=yes and oneway=-1. But changing the direction of the way is a very specicial behavior, and placing the button in the title bar would indicate that it is a special preset field.

Going to work on this today.. This issue gets a bump in priority now that we don't show the radial menu all the time.

I added a "change direction" button that will appear only when oneway is yes (or assumed yes)
I made the markers slightly more opaque

Closing for now...

In general that is fine, but it is still somewhat confusing for the following reasons:

Oneway arrow rendering doen't work for short ways, e.g on two-node ways there might be no visible arrow, even if there is plenty of space to place it, and even if the feature is selected.
Zooming in would show the arrows, but it isn't intuitive to do so because there is already sufficient space to place the arrows. In addition oneway arrows might be hidden by rendering nodes or way direction triangles on top. In case of short ways there is a significant chance that all oneway arrows are hidden.
I think we should increase oneway arrow density for short ways, and maybe we can hide the way direction triangeles in case of oneway=yes. In case of oneway=-1 we could use an alternating sequence of oneway arrow and way direction triangle.
The arrows of the "Change Direction" button are potentially misleading because they might point in the reverse direction of the oneway on the map by chance. Maybe we can omit the visual feedback of the button, which would let user search for the visual feedbeck on the map. In case a visual feedback of the button is desired we could toggle button text "Change direction" and "Direction changed", and/or we can toggle button grey-scaling.
Users knowing OSM tagging might get the impression that the "Change Direction" button is toggling between onewy=yes and oneway=-1. In order to avoid this wron impression, the following means might help:

Place the button one line above in the field header next to undo and delete bottons.
Show the message which would be shown if the user were changing the way direction using the "V" shortcut.
Avoid any changes of the botton due to toggling, except of the change to "Direction changed".

Undo of the field doesn't undo the direction change.

Awesome, thanks @bhousel !

Hey @slhh, sorry I didn't respond to your points above, but after editing a bunch with the field this past week, I'm pretty happy with how it works currently and don't plan to change it anytime soon.

Users can always zoom in if the features are too small to see them in detail
The button originally did not have visual feedback, but I felt it was necessary, so that's why I added the icon.  The left-right direction of the icon does not have any connection to the way direction on the map, it's just a stable indicator that will flip when the user clicks the button.
Not really concerned about what a user thinks about the underlying tag change.  They can just look at the tags if they are curious about this.
I agree it would be better for undo to work.  But this is hard because that undo button resets the tags, and switching the direction is not really a tag change, it's an action, so it would require extensive changes to how the undo button works.


2 clicks required to resume video in mobile browsers after clicking "Learn More" button

Hello,
I'm playing the video as inline using, playsinline. So in this case, when the user clicks the "Learn More" button, the user will be redirected to click URL and the player will be paused by default.
If the user wants to resume the video again, the user has to click 2 times on the play button.
If he clicks on the player,  the video resumes immediately.
I found this issue only with "play" button and this is applicable for both iOS and Android browsers.
You can replicate the issue by adding "playsinline" attribute in the below example:
https://googleads.github.io/videojs-ima/examples/simple/
<video id="content_video" class="video-js vjs-default-skin"
            poster = "../posters/bbb_poster.jpg" controls preload="auto"
            width="640" height="360" playsinline muted="muted">
          <source src="//commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4"
              type="video/mp4" ></source>
        </video>

It would be great if anyone can help to fix this issue

Hi @tonyjose009 ,
Thanks for finding this bug. I have a fix for the issue in this https://github.com/googleads/videojs-ima/pull/866
Once it is merged we can confirm it is a fix for your build.

Thanks, @Kiro705 , Anyhow I have managed to resolve this issue in "onAdPlayPauseClick" function.
Anyways it would be great if you can confirm it

This ""?
Controller.prototype.onAdPlayPauseClick = function () {
  if (this.sdkImpl.isAdPlaying()) {
    this.adUi.onAdsPaused();
    this.sdkImpl.pauseAds();
  } else {
    this.adUi.onAdsPlaying();
    this.sdkImpl.resumeAds();
  }
};

I found the issue was in the pause from the clickthru not properly updating this.sdkImpl.isAdPlaying(). The change should fix that. I will update here when the change is live.

Issue should be fixed in the new release v1.7.3
Closing the issue, but feel free to reopen if it persists.

Cool, it's working.
Thank you @Kiro705 for the fix.


scripts: use util/parseopts.sh for option parsing

Pacman 5.1 provides a util script for option parsing that supports short
and long options.
In addition to provide easier to read options, this will also benefit
completion scripts that rely on parsing the output of --help.
--- 8< ---
I didn't have time to test this today, but wanted to put this out so we can have a dedicated place to discuss this.
134264b just converts existing use of getopts to parseopts without adding any extra functionality. Thus, aur-{srcver,jobs,graph,depends}1 scripts remain without long option support.
I tried to follow the loop style used upstream where it uses a common shift for all options and the same line for the pattern) and list ;;. Saves a bunch of vertical space which makes it a bit nicer to read. But long patterns) kind mess up with the style2. (more evident on aur-sync for now)
Also kept just one space before the last command and ;;. I always had mixed feelings about aligned ;;, it looks prettier but adds noise to the history every time we need to adjust alignment.
Writing this I also noticed I have small inconsistencies on style. How strongly do you feel about this?
resolve before merging:

[ ] inconsistent quoting of $1
[ ] add parseopts to scripts not covered by 134264b [1] (?)
[ ] split long cases over multiple lines. [2] (?)

split over multiple conditions and use cascading;&
other or leave it as-is

I agree that aligned ;; isn't worth it. About the loop style, it's fine by me as long as we stick to lower-case for variables that are not exported. I don't feel too strongly about the vertical style, it used to be like this then I changed it for some reason.
Note that aur-jobs has the same options as parallel, so aur jobs --help should have the desired effect. The other candidates have no options to begin with I believe.

About the inconsistency of quoting; I typically don't quote variables when quotes would make no differences (such as assignments to other variables). If this is confusing I don't mind if these quotes are added back.

If you're ok with it, I don't mind it either way.

Looks like the points on style were solved, so I'll go ahead and merge this. Thanks for your work!
If more scripts need option support this can be covered in a separate PR.

Thanks.


Version 4.5.3 pulls in the class DataUtilities twice

After updating to 4.5.3 the class DataUtilities is added twice. One time in this library and one time in the transitive dependency com.github.peteroupc:datautilties:1.1.0. This causes problems in android builds. Are the two classes identical? In this case the class in this library should be deleted in favor of the version through the dependency.

Solved by releasing version 4.5.4, using the datautilities dependency.


Add styles

Steps

Added global styling
Added general style for the main section
Included the result section styles
Included the add section styles
Included styling for the modal
Added styling for the loading spinner
Added footer styles
Included styling for media query of small screens
Updated README.md file

Screenshots
Before

After

Thanks @EricMbouwe


Enhance NoEmptyRule

PR checklist

[ ] Addresses an existing issue: #0000
[x] New feature, bugfix, or enhancement

[x] Includes tests

[ ] Documentation update
[x] Enable CircleCI for your fork (https://circleci.com/add-projects)

What changes did you make?
Simplify checking for comment in empty block.
Don't add a failure for private or protected constructor.
Is there anything you'd like reviewers to focus on?
Does this need to be added to the docs? The exception for parameter properties isn't in documented either.

please rebase


[LIVY-570] Replace test archives with auto-generated files.

Codecov Report

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

@@             Coverage Diff              @@
##             master     #159      +/-   ##
============================================
+ Coverage     68.65%   68.73%   +0.08%
+ Complexity      906      904       -2
============================================
  Files           100      100
  Lines          5662     5662
  Branches        848      848
============================================
+ Hits           3887     3892       +5
+ Misses         1224     1216       -8
- Partials        551      554       +3

Impacted Files
Coverage Δ
Complexity Δ

...in/java/org/apache/livy/rsc/driver/JobWrapper.java
82.85% <0%> (-5.72%)
8% <0%> (-1%)

...cala/org/apache/livy/scalaapi/ScalaJobHandle.scala
50% <0%> (-2.95%)
7% <0%> (ø)

...c/main/scala/org/apache/livy/repl/ReplDriver.scala
30.76% <0%> (-2.57%)
7% <0%> (ø)

.../scala/org/apache/livy/sessions/SessionState.scala
61.11% <0%> (ø)
2% <0%> (ø)
:arrow_down:

...ain/java/org/apache/livy/rsc/driver/RSCDriver.java
77.96% <0%> (ø)
41% <0%> (ø)
:arrow_down:

...ain/scala/org/apache/livy/utils/SparkYarnApp.scala
79.57% <0%> (+6.33%)
33% <0%> (ø)
:arrow_down:

Continue to review full report at Codecov.

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

Merging to master / 0.6.


源码openai api_server.py报错

AttributeError: 'ChatCompletionRequest' object has no attribute 'stop_token_ids'

pip install 不报错

Support has been added in #1097, but not released yet. Please build vLLM from its main branch if you need it right now. How to build is described in https://github.com/vllm-project/vllm/blob/main/CONTRIBUTING.md

Closing as resolved.


Generic version of the GetOrAdd API?

It would be nice to have generic versions of the GetOrAdd API. Is there any technical reason for this or simply lack of time?

I've made an attempt, but for some reason I can't build the dev branch so I cannot test it:
https://github.com/trondd/CacheManager/tree/feature/genericGetOrAdd

Mh I don't know of how much use this API gives. The returned object basically just gets cast to another type, that's it.
And for that we would clutter the apis with more overloads ;)
Also, the casting back and forth is not something I'd like to promote too much as it can fail really easily at runtime, which is not really nice.
That being said, you could relatively easily write that as extension methods in your own project
Example:
That even lets you use the factory method with the out parameter and not the original T!
public static class CustomExtensions
{
    public static TOut GetOrAdd<T, TOut>(this ICacheManager<T> cache, string key, Func<string, TOut> addFactory)
    {
        Func<string, T> wrapper = (k) => Converter<T>(addFactory(k));

        var v = cache.GetOrAdd(key, wrapper);

        return Converter<TOut>(v);
    }

    public static TOut Converter<TOut>(object value)
    {
        if (value == null)
        {
            return default(TOut);
        }

        try
        {
            object changed = Convert.ChangeType(value, typeof(TOut), CultureInfo.InvariantCulture);
            return changed == null ? (TOut)value : (TOut)changed;
        }
        catch
        {
            return (TOut)value;
        }
    }
}

can be used like
var cacheA = new BaseCacheManager<string>(builder.Build());
var x = cacheA.GetOrAdd("key", (k) => 33);

this casts int to string and back to int.

Thanks MichaC, that is an excellent suggestion.


Analyze parallel contract execution projects

Created a github project task incorrectly as an issue. I close it because I don't need to manage it as an issue.


SQL: Create millisecond precision timestamp literals.

Fixes a bug where implicit casts of strings to timestamps would use seconds
precision rather than milliseconds. The new test case
testCountStarWithBetweenTimeFilterUsingMillisecondsInStringLiterals
exercises this.

@gianm There're some failed cases and looks like they're related to the changes in this PR.
[ERROR] org.apache.druid.sql.calcite.CalciteSelectQueryTest.testSelectCurrentTimeAndDateLosAngeles  Time elapsed: 0.064 s  <<< FAILURE!
java.lang.AssertionError:
Conversion to relational algebra failed to preserve datatypes:
validated type:
RecordType(TIMESTAMP(0) NOT NULL CURRENT_TIMESTAMP, DATE NOT NULL CURRENT_DATE, DATE NOT NULL EXPR$2) NOT NULL
converted type:
RecordType(TIMESTAMP(3) NOT NULL CURRENT_TIMESTAMP, DATE NOT NULL CURRENT_DATE, DATE NOT NULL EXPR$2) NOT NULL
rel:
LogicalProject(CURRENT_TIMESTAMP=[1999-12-31 16:00:00:TIMESTAMP(3)], CURRENT_DATE=[1999-12-31], EXPR$2=[+(1999-12-31, 86400000:INTERVAL DAY)])
  LogicalValues(tuples=[[{ 0 }]])
	at org.apache.calcite.sql2rel.SqlToRelConverter.checkConvertedType(SqlToRelConverter.java:458)
	at org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:575)
	at org.apache.calcite.prepare.PlannerImpl.rel(PlannerImpl.java:254)

@gianm There're some failed cases and looks like they're related to the changes in this PR.

Ah, thanks. I looked into these, and there were some places I missed when setting the default precision to millis. I think the latest patch gets them all. I also added some additional tests to make sure.


Launching either Brave, Chromium, or Kitty freezes the system with loud CPU fan on latest unstable

I just upgraded to latest unstable a few hours ago. After the upgrade, the system keeps freezing if I run any of the program mentioned in this issue title. When I did a rollback to the version before upgrade, the problem persist.
Also, an unrelated problem is that all of my passwords saved in Brave have been replaced with jumbled binary blob. Not sure if due to the incompatible version between the upgrade from Brave 1.17.73 to 1.19.88 or something else. I currently lost access to most of my accounts because my passwords were autogenerated. Obviously this is a throwaway account because I can't access github with my usual account (@rht). Ugh!

I managed to recover my passwords. All I did was to delete the Login Data file from ~/.config/BraveSoftware/Default.

When I did a rollback to the version before upgrade, the problem persist.

This is no longer true. The problem has gone when I did the rollback. I have tried doing an upgrade again though, with the same freezes problem.

does a reboot fix the problem?

The system was frozen, so I had to hard-reboot my laptop. And the problem still persisted.

This is different from #80936. I tried launching kitty from xterm (xterm worked), and didn't observe any error message.

More info: launching Firefox was fine.

Just tried upgrading. Still the same problem. My system is stuck at Dec 2020 nixos-unstable.

 Does this look like a Mesa problem?

Mesa could e.g. trigger GPU bugs but IMO it's always the kernel diver's fault.
In any case: This should be a kernel bug/issue but debugging those is often very difficult.
You could e.g. allow pinging your system and see if it still responds when this happens (in which case it's likely only the GPU module that's affected). And I'd also set kernel.sysctl."kernel.sysrq" = 1; (or similar) and try to regain control of the keyboard (https://en.wikipedia.org/wiki/Magic_SysRq_key - R for unraw and then switch to a different tty).
Anyway, this might help to get started but unfortunately I don't have time/motivation help with such issues. Good luck ;)

So it could be a kernel problem. I tried upgrading to Linux 5.10 instead of 5.11, and still encountered the problem. My system is a generic Thinkpad x280, which I'm sure a lot of people use. I wonder why I am the only one with this problem.

More info: I downgraded to 5.4 and encountered no problem at all. So it is a kernel problem, not some xorg video driver. I can only wait to test 5.12 later on, for now.

Tested on 5.10.36, it works. No longer an issue.


Resque data is being sent as Web data.

Update gem on two different Rails applications one update went fine, the other; all Resque data sent as "web" including the "non-web".
Description
I update the gem on the following two appications. App A had no issues and was a
success, but when I updated App B, all data sent to new relic was type Web.
Expected Behavior
Resque to be reported at Non-Web data.
Steps to Reproduce
N/A
Your Environment
updated apps to versions:
App A(no issue):

rails:     7.1.2
ruby:      3.2.4
new_relic: 9.11.0
resque:    2.5.0

App B(with issue):

rails:     <IP_ADDRESS>
ruby:      3.3.1
new_relic: 9.11
resque:    2.6.0

Additional context
I have a weird hunch that this might possibly be related to an issue on Resque
where ruby 3.3 results in stuck workers:
https://github.com/resque/resque/issues/1895
For Maintainers Only or Hero Triaging this bug
Suggested Priority (P1,P2,P3,P4,P5):
suggested t-shirt size (s, m, l, xl, unknown):

Hi @ChrisCPO, thanks for your report. We're looking into this issue and will be back in touch with more info soon.
Are there any differences in the way Resque is configured in the two apps?
Do both apps have similar jobs?

@kaylareopelle thanks for the quick reply.

Are there any differences in the way Resque is configured in the two apps?
There are no difference in our new relic configs.

Do both apps have similar jobs?

Yes

Hi @ChrisCPO, thanks for the follow-up. Unfortunately, we haven't been able to reproduce this issue.
Here's a link to a simple reproduction: https://gist.github.com/kaylareopelle/76079747c1a7528449670b8bd1c78893
With this gist, I was able to create Resque transactions correctly marked as 'Non-Web'. We also tested similar code within a Rails <IP_ADDRESS> / Ruby 3.3 app with jobs running outside of a web transaction and couldn't reproduce the behavior.
After taking a look at the diff between Resque 2.5.0 and 2.6.0, the changes shouldn't impact the agent. We also haven't made changes to our Resque instrumentation in recent versions of newrelic_rpm.
At this time, my best guess is the problem relates to the bug report you shared.
If there's something else you'd like us to test, please share a reproduction or update the provided gist to more closely match your situation. We're happy to take a look.


How to return result from .then() function

I try as below code, but don't work:
const Translate = require('google-translate-api');

var Tran = async (callback) => {
     return await Translate('test', {from: 'en', to: 'th'});
};
console.log("Before");
console.log(Tran());
console.log("After");

Result is:
Before
Promise { <pending> }
After

Have any idea?

You need to wait until Promise is solved. If you have an array of Promise, use Promise.all(your array).then() . If you have only one value, you'll probably go for a Promise.resolve(your value).
Read mozilla doc, it has several examples:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/resolve

Hi,
I just code like below:

Hi,
I just code like below, because I need to translate line by line.
var getTran = async (text, options) => {
    var _result = [];

    try {

        _result = await Translate(text, options);

    } catch(err) {
        console.log("" + err);
    }

    return _result;
}
var mainProcess = async (callback) => {

	var result = await getTran('text', {from: 'en', to: 'th'});
        // process result
	result = await getTran('text2', {from: 'en', to: 'th'});
	 // process result
	result = await getTran('text2', {from: 'en', to: 'th'});
	 // process result

}
mainProcess();

PS. Event I use Promise function It's not work as code below.
var result = new Promise( function(resolve , reject ) {
    Translate('text', {from: 'en', to: 'th'}).then(res => {
	    resolve(res);
	}).catch(err => {
	    reject(err);
	});
});
console.log("Before");
console.log(result);
console.log("After");

My advice put every line in a array. Then map the array to make promise for each line. Then use promise all to get your resolved array of Promise and manipulate it.
It will look like this:
var myListOfSentence = ["sentence1", "sentence2", "sentence3"];

var i = 0;
var leng = myListOfSentence.length;
var newList = [];

while (i<leng) {
	list.push(translateSentence(list[i], "en", "th")); //Return a promise
	i = i+1;
}

Promise.all(newList).then( () => {

	console.log(newList);
})

Use this for the translateSentence:
async function translateSentence(sentence, languebase, languagetranslation) {

var sentenceTranslated;
var traduction = {};
//Chercher le mot
sentenceTranslated = await translate(sentence, {from: languebase, to: languagetranslation});

return sentenceTranslated;

}

Thanks

Welcome !

Good morning to you. It is still not working for me o


Connector is not producing anything on AWS ECS

Hey everyone;
For a POC, we are trying to run the connector on an AWS ECS.
Connector is deployed and has a RUNNING state and is not printing any errors or exceptions; But it's not producing anything on Glue/S3 and it has a consumer lag of 3000 messages. Do you have any suggestions on how can we debug this? Thanks.
Deployed task configuration:
{
        "connector.class": "io.tabular.iceberg.connect.IcebergSinkConnector",
        "tasks.max": "1",
        "topics": "TOPIC_NAME",
        "iceberg.tables": "hvr_temp_investigation_database.oeheader",
        "iceberg.catalog.catalog-impl": "org.apache.iceberg.aws.glue.GlueCatalog",
        "iceberg.catalog.warehouse": "s3://S3_BUCKET",
        "iceberg.catalog.io-impl": "org.apache.iceberg.aws.s3.S3FileIO",
        "iceberg.catalog.client.region": "us-east-1",
        "iceberg.tables.default-id-columns": "PK1,PK2,PK3",
        "iceberg.tables.upsert-mode-enabled": "true",
        "iceberg.tables.auto-create-enabled": "true",
        "iceberg.tables.evolve-schema-enabled": "true",
        "iceberg.tables.schema-case-insensitive": "true"
}

Status of the connector:

Logs:
log-events-viewer-result(2).csv
Docker Image we have created to run the connector on ECS:
FROM confluentinc/cp-server-connect-base:7.6.1

ENV CONNECT_PLUGIN_PATH="/usr/share/java,/usr/share/confluent-hub-components"
# TODO is it sufficient?
ENV CONNECT_GROUP_ID="Commerce-Salesforce-kc-iceberg-connect"

ENV CONNECT_CONFIG_STORAGE_TOPIC="_kc-iceberg-connect-configs"
ENV CONNECT_OFFSET_STORAGE_TOPIC="_kc-iceberg-connect-offsets"
ENV CONNECT_STATUS_STORAGE_TOPIC="_kc-iceberg-connect-status"
ENV CONNECT_REPLICATION_FACTOR=3
ENV CONNECT_CONFIG_STORAGE_REPLICATION_FACTOR=3
ENV CONNECT_OFFSET_STORAGE_REPLICATION_FACTO=3
ENV CONNECT_STATUS_STORAGE_REPLICATION_FACTOR=3
ENV CONNECT_KEY_CONVERTER="org.apache.kafka.connect.storage.StringConverter"

# Schema Registry
ENV CONNECT_VALUE_CONVERTER="io.confluent.connect.avro.AvroConverter"
ENV CONNECT_VALUE_CONVERTER_SCHEMAS_ENABLE="true"

ENV CONNECT_VALUE_CONVERTER_BASIC_AUTH_CREDENTIALS_SOURCE="USER_INFO"
ENV CONNECT_REST_ADVERTISED_HOST_NAME="connect-1"

# Worker
ENV CONNECT_LOG4J_ROOT_LOGLEVEL="INFO"
ENV CONNECT_LOG4J_LOGGERS="org.apache.kafka.connect.runtime.rest=WARN,org.reflections=ERROR"
ENV CONNECT_REQUEST_TIMEOUT_MS="20000"
ENV CONNECT_RETRY_BACKOFF_MS="500"

# Connect
ENV CONNECT_SSL_ENDPOINT_IDENTIFICATION_ALGORITHM="https"
ENV CONNECT_SECURITY_PROTOCOL="SASL_SSL"
ENV CONNECT_SASL_MECHANISM="PLAIN"

# Producer
ENV CONNECT_PRODUCER_SECURITY_PROTOCOL="SASL_SSL"
ENV CONNECT_PRODUCER_SASL_MECHANISM="PLAIN"
ENV CONNECT_PRODUCER_SSL_ENDPOINT_IDENTIFICATION_ALGORITHM="https"
ENV CONNECT_PRODUCER_REQUEST_TIMEOUT_MS="20000"
ENV CONNECT_PRODUCER_RETRY_BACKOFF_MS="500"

# Consumer
ENV CONNECT_CONSUMER_SECURITY_PROTOCOL="SASL_SSL"
ENV CONNECT_CONSUMER_SASL_MECHANISM="PLAIN"
ENV CONNECT_CONSUMER_SSL_ENDPOINT_IDENTIFICATION_ALGORITHM="https"
ENV CONNECT_CONSUMER_REQUEST_TIMEOUT_MS="20000"
ENV CONNECT_CONSUMER_RETRY_BACKOFF_MS="500"

# Needed to install unzip and the plugin
USER root
RUN yum install -y unzip
RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
RUN unzip awscliv2.zip
RUN ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update

ENV SINK_PLUGIN=iceberg-kafka-connect-runtime-0.6.15.zip
ADD https://github.com/tabular-io/iceberg-kafka-connect/releases/download/v0.6.15/$SINK_PLUGIN /tmp/
RUN unzip /tmp/$SINK_PLUGIN -d /usr/share/java/
RUN rm /tmp/$SINK_PLUGIN

# To set REST advertised host name
COPY set_env.sh /etc/set_env.sh
COPY binaries/cli/jq /usr/bin/

USER root
RUN chmod +x /etc/set_env.sh
USER appuser

CMD ["/etc/confluent/docker/run"]

And we are setting these variables on runtime: CONNECT_VALUE_CONVERTER_SCHEMA_REGISTRY_URL, CONNECT_VALUE_CONVERTER_SCHEMA_REGISTRY_BASIC_AUTH_USER_INFO, CONNECT_SASL_JAAS_CONFIG, CONNECT_CONSUMER_SASL_JAAS_CONFIG, CONNECT_PRODUCER_SASL_JAAS_CONFIG, CONNECT_BOOTSTRAP_SERVERS.

To confirm:

you are not seeing the table being created
you are not seeing any files in GCS
are you seeing any ERROR level messages in the logs, if so: what
is the connector constantly rebalancing?

@tabmatfournier Thanks for the answer:

There aren't any tables created in Glue database.
Nothing is written into S3.
No there aren't any ERROR level logs; How ever there are some WARN level logs which I was getting those also when I was running that locally.
Yes, connector is constantly re-balancing (you can see that from the logs I exported from CloudWatch)

@tabmatfournier We found the issue; a firewall rule in the VPC which the ECS cluster was deployed to was blocking the route to Confluent Schema Registry.
However it was really difficult for us to find the error as there was nothing getting sinked nor producing any errors or warnings regarding the connection issue.
If you agree, I can work on this to first check the connection to both Kafka Broker and Schema Registry to avoid confusion and making debugging hard.
Please let me know what do you think, Thanks.

I'm surprised there were no ERROR level logs indicating this already.

It should be related to the underlying Kafka library which is used for connecting to Kafka.
It accepts different TIMEOUT_MS configs (like CONNECT_REQUEST_TIMEOUT_MS and CONNECT_RETRY_BACKOFF_MS) and it remains silent during the retrying phase.
I think that would make sense to easily first check if our execution environment has access to the broker and schema registry before directly initiating connection phase.
What do you think? If it makes sense for you I can add it.

hey @farbodahm can you please share your set_env.sh file?

Hey @shubhamsawantsjsu , It's just for running the image on ECS:
set -Eeuo pipefail

JSON=$(curl ${ECS_CONTAINER_METADATA_URI}/task)
echo $JSON
TASK=$(echo $JSON | jq -r '.Containers[0].Networks[0].IPv4Addresses[0]')
echo $TASK

CONNECT_REST_ADVERTISED_HOST_NAME=$TASK /etc/confluent/docker/run


Defining handlers inside a module

When I try to setup an API inside a module, it turns out that the handlers are not being registered. I have to define them outside the module to make it work.
Minimal example
Define inside a module
module BuildMyAPI

using Oxygen

function build_api(app=instance())
    app.get("/") do
        return "Hello World"
    end

    return app
end

end

using .BuildMyAPI: build_api

app = build_api()

# The route is not registered
app.serve(port=8010, async=true)

Define outside a module
using Oxygen

app = instance()

app.get("/") do
    return "Hello World"
end

# This works
app.serve(port=8010, async=true)

Hi @thevolatilebit,
Thanks for the code snippet, I'll have to take a look into that. In the meantime, I'd recommend using @oxidise macro to do the same for now (as long as the number of servers remains static).
https://github.com/OxygenFramework/Oxygen.jl/blob/master/demo/multiinstance.jl
The instance function has always been a bit hacky since it's dynamically creating a module at runtime in Julia which isn't encouraged (but still possible).

I see, thanks!


options.timeout in httpPromise.js

httpPromise.js contains the following line for setting a HTTP request timeout:
options.timeout = 10000; //TODO make adjustable
I am using your library with Node-RED and under certain conditions the Hue hub is unable to answer in under 10 sec. This causes the whole Node-RED server to crash since the thrown TIMEOUT exception is not catched. For now I have commented out this line and have no issues anymore.
Hence I would make this setting strongly optional.

@peter-murray: I have the timeouts very often. One second it reacts instantly, the next second the bridge take more than 10 sec to react on the pressed button on the hue remote. I tried to deactivate my integrations but nothing helps. Restating the bridge does not help. atm I have 4 LED blubs, 3 osram plugs and a RGBW Controller (FLS-PP3) from Dresden electronic.
Any idea?

@volkerrichert there can be a number of reasons for load on your bridge and slow responses, but mostly it is either down to excessive polling or posting to the bridge. The bridge is a fairly lightweight device and it does not take too much to overload them, something like 10 light state changes posted separately over a second could easily do it.
You do not mention, which bridge you have, the older ones, they are circular are slower than the new rounded square pucks, so that might be something to consider. There is also a few things internally to do with scenes and groups that can require a bit of a clean up from time to time, especially when developing against them. The hue app on iOS has some options for cleaning up some of those. Also make sure you are up to date with the updates, these usually make things better, except for a few early mess ups from Philips.
Ideally you want to work in batches for changing states, I.e put all the changes, on, Color, brightness for each light into a request rather than post them all separately, and avoid polling the bridge heavily to discover states. I think also there are some state retrieval endpoints that are fairly heavy as they return all values of all things, which should be avoid being queried heavily.
Then there is also the possibility that there might be something wrong with the bridge, but you would have to be able to prove that using no integrations before you could engage with Philips on that one.

I found the reason. Querying a bulb group cause this behavior. I don't know if this ist located in ths lib, in node-red-contrib-node-hue or the bridge (i have V2). After switching to one bulb from that group it runs like silk.

I doubt it will be this library, as I am merely a thin wrapper around the exposed api itself. I don’t do multiple queries except in extreme edge cases, and those are mainly for configuration.
It would probably be worthwhile raising an issue with node-red library developers so it can be resolved.


Document how to remove features

To be done on top of #39
Document how to remove

The ./docs directory and associated flake outs
treefmt (toml, nix, etc.)
Relude
... ?

Done in srid.ca & https://haskell.flake.page/ also helps.


Random Navigation and Freezing Issue with IndexedStack and Bottom Navigation Bar on Mobile Browsers (Android/iOS)

Steps to reproduce
1: Open this web app using this link on a mobile browser (Android/IOS)
2: Tap multiple times on the center or sides of the screen, focusing on the right and left areas.
Expected results
It should not randomly navigate when tapping multiple times on the IndexedStack area.
Actual results
Occasionally It navigates randomly when interacting with the IndexedStack area.
Code sample
Code sample
import 'package:flutter/material.dart';

void main() {
  runApp(const MyApp());
}

class MyApp extends StatelessWidget {
  const MyApp({super.key});

  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        colorScheme: ColorScheme.fromSeed(seedColor: Colors.deepPurple),
        useMaterial3: true,
      ),
      home:  HomePage(),
    );
  }
}

class HomePage extends StatefulWidget {
  @override
  _HomePageState createState() => _HomePageState();
}

class _HomePageState extends State<HomePage> {
  int _pageIndex = 0;

  Map<int, GlobalKey<NavigatorState>> navigatorKeys = {
    0: GlobalKey<NavigatorState>(),
    1: GlobalKey<NavigatorState>(),
    2: GlobalKey<NavigatorState>(),
    3: GlobalKey<NavigatorState>(),
  };

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: SafeArea(
        child: IndexedStack(
          index: _pageIndex,
          children: <Widget>[
            NavigatorPage(
              child: Text('Home'),
              navigatorKey: navigatorKeys[0]!,
            ),
            NavigatorPage(
              child: Text('Business'),
              navigatorKey: navigatorKeys[1]!,
            ),
            NavigatorPage(
              child: Text('Technology'),
              navigatorKey: navigatorKeys[2]!,
            ),
            NavigatorPage(
              child: Text('Education'),
              navigatorKey: navigatorKeys[3]!,
            ),
          ],
        ),
      ),
      bottomNavigationBar: BottomNavigationBar(
        type: BottomNavigationBarType.fixed,
        items: const <BottomNavigationBarItem>[
          BottomNavigationBarItem(
            icon: Icon(Icons.home),
            label:'Home',
          ),
          BottomNavigationBarItem(
            icon: Icon(Icons.business),
              label: 'Business',
          ),
          BottomNavigationBarItem(
            icon: Icon(Icons.computer),
              label: 'Technology',
          ),
          BottomNavigationBarItem(
            icon: Icon(Icons.book),
              label: 'Education',
          ),
        ],
        currentIndex: _pageIndex,
        onTap: (int index) {
          setState(
                () {
              _pageIndex = index;
            },
          );
        },
      ),
    );
  }
}

class NavigatorPage extends StatefulWidget {
  NavigatorPage({super.key, required this.navigatorKey, required this.child});

  final Widget child;
  final GlobalKey<NavigatorState> navigatorKey;

  @override
  _NavigatorPageState createState() => _NavigatorPageState();
}

class _NavigatorPageState extends State<NavigatorPage> {
  late TextEditingController _textEditingController;

  int _currentRoute = 0;

  @override
  void initState() {
    _textEditingController = TextEditingController();
    super.initState();
  }

  @override
  Widget build(BuildContext context) {
    return Navigator(
      key: widget.navigatorKey,
      onGenerateRoute: (RouteSettings settings) {
        return MaterialPageRoute(
          settings: settings,
          builder: (BuildContext context) {
            return Scaffold(
              appBar: AppBar(
                title: widget.child,
                centerTitle: true,
              ),
              body: Container(
                margin: EdgeInsets.symmetric(
                  vertical: 10.0,
                  horizontal: 20.0,
                ),
                child: ListView(
                  children: List.generate(
                    50,
                        (index) {
                      return Card(
                        child: ListTile(
                          leading: FlutterLogo(),
                          title: Text('${index + 1} Item'),
                          enabled: true,
                          onTap: () {
                            if (_currentRoute != index) {
                              _textEditingController = TextEditingController();
                            }
                            _currentRoute = index;
                            Navigator.of(context).push(
                              MaterialPageRoute(
                                builder: (BuildContext context) {
                                  return DetailRoute(
                                    textEditingController:
                                    _textEditingController,
                                    index: index,
                                  );
                                },
                              ),
                            );
                          },
                        ),
                      );
                    },
                  ),
                ),
              ),
            );
          },
        );
      },
    );
  }
}

class DetailRoute extends StatelessWidget {
  const DetailRoute({super.key, required this.textEditingController, required this.index});

  final TextEditingController textEditingController;
  final int index;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text('Route for $index Item'),
      ),
      body: Container(
        padding: const EdgeInsets.all(16.0),
        alignment: Alignment.center,
        child: TextField(controller: textEditingController),
      ),
    );
  }
}

Screenshots or Video

Screenshots / Video demonstration

Logs
Logs
[Paste your logs here]

Flutter Doctor output
Doctor output
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.16.9, on macOS 12.5 21G72 darwin-arm64, locale en-TN)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.1)
[✓] Xcode - develop for iOS and macOS (Xcode 14.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2021.3)
[✓] VS Code (version 1.87.2)
[✓] Connected device (2 available)
[✓] Network resources

• No issues found!

Thanks for the report @am1994
I tried the link on iPhone's safari browser in which I couldn't replicate the reported behavior.
https://github.com/flutter/flutter/assets/67046386/44f104c2-8c6c-4e46-9931-432d267add07
Can you provide short video that shows the freezing issue ? Also, provide the device details (both Android and iOS) along with replicable pattern / steps.

https://github.com/flutter/flutter/assets/17643446/a296bf0d-21df-4d85-8cb1-1f04a2aad9d2
Here is the attached video demonstrating the unwanted navigation and freezing. In this video, the initial state is the home screen. I've tapped multiple times on the right side of the screen, causing it to randomly navigate to the 'Education' screen.
IOS:  17.3.1 / iPhone 15
ANDROID: 11  / Samsung A20s

I tried to replicate again using Samsung S10 running Android 12 version but was unable to replicate it. Also, the steps you mentioned to replicate (ie, to randomly keep tapping on the right side of the screen) is not ideal to properly and consistently replicate it.
Are you able to consistenly replicate it only on mobile browser or also on other platforms (web, desktop, mobile) ?
If you are able to see any pattern that consistenly leads to freezing the app, then it will help us to make the issue actionable.

The issue doesn't appear on the web, and I figured out that it occurs only with the installed web app (PWA), when adding it to the mobile home screen.

Thanks for the update. When I tried it as a PWA and ran it on iOS safari, I was able to replicate the reported freeze behavior, but I couldn't see it on Android + chrome, so maybe you are hitting https://github.com/flutter/flutter/issues/115829 that you can check and confirm.

Thank you. Yes, indeed, I've encountered the same issue. After testing it twice on both Android (PWA) and iOS (PWA), I can confirm that I was only able to replicate it on iOS (PWA).
Has the issue been resolved?

It is still open. You may share your findings in that issue for better tracking.
Closing this as a duplicate.


Motodex

🏍motoDEX is a project that is developing by leaps and bounds. The game has made a splash in the NFT market due to the following obvious advantages:
Just select a character and start the easy-to-follow gameplay. A simple plot combined with the drive of high-speed racing and colorful locations will attract fans of the classic genre of racing simulators to their screens.
Protecting financial transactions using smart contacts. The algorithm automatically transmits, tracks and updates data on funds that are pending with players. Refusal of the human factor when using modern technologies guarantees honesty and transparency of payments. Fair discrimination. Automatic price increases for new characters provide innovative motoDEX buyers with smart benefits at the contract level. The project guarantees investors who entered the game at the start of the project an advantage in monetizing their game progress.
A gaming economy that stimulates rising prices for NFT objects. The algorithm’s condition for increasing the cost of tracks and characters after each new sale ensures a stable increase in the cost of in-game items.
High liquidity with the possibility of obtaining excess profits. At the start of the project, players have a chance to increase their investment in the gameplay.
https://openbisea.io/motodex.
https://motodex.openbisea.com/
https://www.youtube.com/watch?v=wA4iRXsjsIg.
email-<EMAIL_ADDRESS>

Hey @InnaKoliasnikova, If you want to open a proposal please do it via the GrantShares app.


fix: Updated to standard go structure, updated release to use correct…

… token, and CS action.

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


x11docker-gui /usr/bin/catatonit: invalid option -- 's'

Hello,
when I run x11docker-gui, I systematically get the error:
$ x11docker-gui
...
/usr/bin/catatonit: invalid option -- 's'
usage: catatonit [-ghLV] [--] <progname> [<arguments>...]

My file  x11docker.log
catatonit according to what I saw is a particularity of opensuse https://github.com/openSUSE/catatonit.
In the x11docker.log.
378  |69	Tini='/usr/bin/catatonit'
392  |83	storeinfo test tini && Tini="$(storeinfo dump tini) -s --" || Tini=''

but the catatonit process does not have the -s switch
How can I fix this?
Thank you.

Thank you for the report and already pointing on the relevant code parts!
I wasn't aware of catatonit on openSUSE, good to know.
I've fixed the bug, x11docker does not use the switch -s anymore. Instead it sets environment variabe TINI_SUBREAPER=1.
catatonit will run as a subreaper automatically and does not need a switch.
Please update x11docker. Aternatively you could just set Tini='' in the code, it is not really important at this point, it just serves to have a clean process tree.

Great. Great.

I'll test it at the end of the day, I'll make a comeback.
And thanks again for the work.


Switching to nvidia graphics breaks sddm and xorg

After running sudo envycontrol --switch nvidia and rebooting, sddm doesn't start and nor does xorg(By doesn't start I mean that the only thing that is displayed on the screen is a flashing white underscore)
Steps to reproduce:

Switch to nvidia graphics
Reboot

Steps to fix the problem :

Switching back to hybrid graphics worked for me. You might have to remove the package if that didn't fix the problem.

What distro are you using? thank you!

EndevourOs(based on arch linux)

EndevourOs(based on arch linux)

I have added an additional script that performs some necessary xrandr operations before the initialization of SDDM when on Nvidia mode (the same also applies to LightDM), EnvyControl should automatically detect your Display Manager and setup the script if applicable.
If the user doesn´t has systemd then the Display Manager should be specified manually using the --dm argument.
Can you give it a try? you can clone this repo and run git checkout sddm then execute EnvyControl with sudo python envycontrol.py --switch nvidia.
https://github.com/geminis3/EnvyControl/tree/sddm
Thank you!

I successfully tested the latest changes from a live Manjaro KDE session, Nvidia mode is working as expected after restarting the display manager.

Also working on Manjaro Xfce live session (it uses LightDM)

Yeah, my system booted perfectly with xorg and sddm working as expected. Thanks!

Yeah, my system booted perfectly with xorg and sddm working as expected. Thanks!

Thank you, tomorrow I will merge those changes into main and update the AUR package.


Tapability on iPad Safari

Small issue report:
On the toolbox it's sometimes hard to hit the left column (on Safari iPad). It will only work if I hit the right half of the button.
I see you're already anticipating something like this and buttons extend to the edge of the screen:

I made a small recording to show it via accessibility features on iPadOS
With that recording I wasn't able to hit the button, but IRL it will work when hitting the right half. Maybe iPadOS is doing something weird with edges (even though there are no actions on the left). 🤷 Just wanted to report...
https://www.dropbox.com/s/mahhm9k3yo93g61/RPReplay_Final1668719304.mov?dl=0

This should be fixed now. We were preventing touch events on the edge of the screen to avoid swipe navigation.
Could you try again?

I believe this should be fixed now. Thanks again for reporting this bug to us!


Improvement in auto-generated Markdown docs with MarkdownBuilder

Why are the changes needed?

Note:

No output changes to existed generated docs as in settings.md and functions.md.

Improvement:

readability in Scala code for doc auto-generation, and easy to maintain docs in group of sections
reline on markdown linting from flexmark, and reducing un-meaningful blank lines or alignment
declaration over operation by replacing repeated usages of newOutput itself by elegantly wrapped .line,.linesand etc.
less fragile and more handy for changing in a long single line, as now using auto margin stripping in .line() method
reusable extracted licence.md and auto-generation hints
more elegant and safer way to read and appending file content
possible less memory footprint by apply operators to Stream instead of to ArrayBuffer

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Codecov Report

Merging #4244 (8250a55) into master (f677848) will decrease coverage by 0.02%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #4244      +/-   ##
============================================
- Coverage     53.55%   53.53%   -0.02%
  Complexity       13       13
============================================
  Files           560      560
  Lines         30413    30413
  Branches       4082     4082
============================================
- Hits          16288    16283       -5
- Misses        12620    12623       +3
- Partials       1505     1507       +2

Impacted Files
Coverage Δ

...e/kyuubi/jdbc/hive/ClosedOrCancelledException.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...rg/apache/kyuubi/ctl/cmd/log/LogBatchCommand.scala
59.09% <0.00%> (-1.52%)
:arrow_down:

.../kyuubi/engine/spark/operation/ExecutePython.scala
81.46% <0.00%> (-0.87%)
:arrow_down:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Thanks, merged to master


Travis OSX build failing

Something changed with Travis, I tried some fixes in https://github.com/fireeye/flare-floss/tree/osx_build_fail, but had no success so far.
See https://travis-ci.org/fireeye/flare-floss/builds

closed via #294


Add "build-essential" application to web images for WingSuit support

Is your feature request related to a problem? Please describe.

The WingSuit Kickstarter project for Drupal 8+ leverages Storybook to house components that integrate with a custom theme using UI Patterns.  Included in the Storybook portion of WingSuit are some scripts that are used to generate components as well as create the static Styleguide and Drupal integration components.
Describe the solution you'd like

For Storybook startup scripting to complete initializing the Storybook application, "build-essential" is an additional web image package that has to be added.  While this can be added in the config.yaml file, that file is project specific, and the package needs to be added for every project using Storybook.
Describe alternatives you've considered

Please consider adding "build-essential" to the list of packages included in the DDEV web image.

Hi @lhridley - Thanks for the idea. Unfortunately, if everybody added everything they wanted to the web image it would just be unwieldy. I just tested, and adding build-essential makes the ddev-webserver image 20% bigger, going from 1.08GB to 1.26GB. Since people can easily add it to fix their own issues with webimage_extra_packages: ["build-essential"] and since most people don't need it, I think it's better to leave things where they are.
Happy to continue the conversation here or elsewhere, but closing this for now.

Just checking on something you might not know - When you use webimage_extra_packages: ["build-essential"] it only has to install that the first time you run ddev start, it doesn't do it every time. It gets built into your project's custom web image.


Not compatible with laravel11

Describe the bug
Http/Kernel.php does not exist in the newly created laravel11 project and cannot be installed
Reproduction
no need
Steps to reproduce
No response
System information
no need

Used package manager
npm
Logs
No response
Validations

[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Hybridly issue and not an issue related to something else (Vite, Vue...). For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A, join our Discord server.
[X] The provided reproduction is a minimal reproducible example of the bug.

I don't understand what you mean. I'm already running Hybridly in production right now on Laravel 11. Can you be more specific or provide a reproduction please?

I'm talking about create a new larval 11 project and install this package. You will know the error

I tried creating a new project:
composer create-project laravel/laravel laravel
cd laravel
npx @preset/cli apply hybridly/preset

Everything works. I'm assuming you encountered this issue? https://github.com/hybridly/hybridly/issues/126

No, I run this
composer require hybridly/laravel
php artisan hybridly:install

@innocenzi It still not fixed

Sorry, I thought my bug description said what the problem was.
So I did not post the error information
Next time I will post the error information.


Report bound top-level variables from EvalInteraction

I'm trying to reimplement some of the FSI functionality for Ionide based on the F# compiler service (see the FsInteractiveService project).
One thing that does not seem to be possible at the moment is to get top-level bindings that were produced by an EvalInteraction command. For example, say I use Deedle and call:
fsi.EvalInteraction("let myseries = series [ 1 => 3.14 ]")

I would like to be able to find know that this defined myseries value, so that I can display the series nicely in a grid. At the moment, I'm only able to do this if the evaluated text is an expression (I get the it value and see if that's a series), but not for bound variables.

Closing as duplicate of #280


[SMALLFIX] replace anonymous type with lambda

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/19585/
Test PASSed.

LGTM


Corrected periods at the end and some others minor changes. #1319

Minor Corrections #1319

OPS Build status updates of commit a78469b:
:clock10: Preparing: average preparing time is 1 min(s) 12 sec(s)

OPS Build status updates of commit a78469b:
:clock10: Incremental building: average incremental building time is 12 min(s) 24 sec(s)

OPS Build status updates of commit a78469b:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-online/Get-SPOGeoAdministrator.md
:white_check_mark:Succeeded
View (sharepoint-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

OPS Build status updates of commit e9b81d0:
:clock10: Preparing: average preparing time is 1 min(s) 12 sec(s)

OPS Build status updates of commit e9b81d0:
:clock10: Incremental building: average incremental building time is 12 min(s) 24 sec(s)

OPS Build status updates of commit e9b81d0:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-online/Get-SPOGeoAdministrator.md
:white_check_mark:Succeeded
View (sharepoint-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

OPS Build status updates of commit 2854b1e:
:clock10: Preparing: average preparing time is 1 min(s) 12 sec(s)

OPS Build status updates of commit 2854b1e:
:clock10: Incremental building: average incremental building time is 12 min(s) 24 sec(s)

OPS Build status updates of commit 2854b1e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-online/Get-SPOGeoAdministrator.md
:white_check_mark:Succeeded
View (sharepoint-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

OPS Build status updates of commit b097586:
:clock10: Preparing: average preparing time is 1 min(s) 12 sec(s)

OPS Build status updates of commit b097586:
:clock10: Incremental building: average incremental building time is 12 min(s) 24 sec(s)

OPS Build status updates of commit b097586:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-online/Get-SPOGeoAdministrator.md
:white_check_mark:Succeeded
View (sharepoint-ps)

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


appending \0 aka the null byte character to keys to prevent unintended prefix deletion

An entry w/ the key foobar, will get overridden by an entry with the key foo
However an entry w/ the key foobar will not get overridden by an entry with the key foo\0
to prevent our APIs from doing unexpected and unwanted behaviour we can either append the null byte to a key:

at the top level API in the iroh cli / console, append the null byte as expected
one layer down: have all api calls append and remove the null byte so that it is part of the iroh API and it is expected that we take care of this as a library
at the document level, and append the null byte for all set-ing and get-ing needs

Regardless of where this gets implemented, we need to add some kind of prefix flag on all set and get-like actions that will inform us that the user intends to do batch work on all entries with keys underneath that prefix.

Hm, what about not doing this and instead telling users about how prefix deletion works?
Prefix deletion/replacement is a very useful feature if you know how to use it, and always appending a 0 byte would close this down to the user.
If we do this at all, I would have it just as an option of the cli / console that you can opt out of with an extra arg --raw or whatever. So for me option 1 makes most sense.

Personally I think using an enum for rust APIs:
pub enum Key<'a> {
    Full(&'a [u8]),
    Prefix(&'a [u8]),
}

and a --prefix flag for CLI commands: iroh doc set <KEY> --prefix.
It looks like iroh doc get already has a --prefix flag, but set apparently doesn't.

We have path_to_key and key_to_path methods that take care of this now on the CLI


WIP - Revert getError removal from PR 45

Signed-off-by: TomSweeneyRedHat<EMAIL_ADDRESS>I'm adding back the error handling that was removed vrom #45 in order to hopefully address https://bugzilla.redhat.com/show_bug.cgi?id=1626228.
However the progress_test.go tests that should error out on error don't seem to be:
# go test
--- FAIL: TestReports (0.04s)
    --- FAIL: TestReports/detect_error (0.01s)
    	progress_test.go:95: detect error: did not get expected error
--- FAIL: TestErrorOnCopy (0.00s)
	progress_test.go:125: Did not get an error when copying to writer
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x513e20]

goroutine 19 [running]:
testing.tRunner.func1(0xc4200805a0)
	/usr/lib/golang/src/testing/testing.go:711 +0x2d2
panic(0x53cc60, 0x61fba0)
	/usr/lib/golang/src/runtime/panic.go:491 +0x283
github.com/openshift/imagebuilder/imageprogress.TestErrorOnCopy(0xc4200805a0)
	/root/tsweeney/workspaces/imagebuilder/src/github.com/openshift/imagebuilder/imageprogress/progress_test.go:127 +0x280
testing.tRunner(0xc4200805a0, 0x56f1c0)
	/usr/lib/golang/src/testing/testing.go:746 +0xd0
created by testing.(*T).Run
	/usr/lib/golang/src/testing/testing.go:789 +0x2de
exit status 2
FAIL	github.com/openshift/imagebuilder/imageprogress	0.053s

I'm not sure if they're failing as I've not set up the error condition in the test properly or if the change from #45 of io.Writer to io.Writer.Closer is causing the error not to be generated/caught.  As I've not looked at this code prior to this afternoon, any thoughts/suggestions welcomed.

@runcom @rhatdan @mtrmac PTAL

@bparees ptal

the error handling itself looks reasonable to me, can't speak to the unit test issue

I’ll take a detailed look in a bit, but I don’t think it’s quite this simple.
Consider the usual status flow, with an error arriving as the last update:

The writer calls `imageProgressWriter.Write("the error"})
w.internalWriter.Write() succeeds writing it to the pipe, simultaneously w.readProgress() succeeds reading it from the pipe, and decoding the error
The reading goroutine now has the err != nil value we want to record, and calls pipeIn.CloseWithError()
If, at this point, the writer sent another data chunk, it would probably receive the error and it would be propagated correctly. But because the error tends to be the last item, this is fairly unlikely (and depends on how exactly the data is chunked/buffered)
More likely, the writing side would call imageProgressWriter.Close, and the CloseWithError should cause imageProgressWriter.Close to return this error value…
… but nothing guarantees that imageProgressWriter.Close is only called after pipeIn.CloseWithError AFAICS; the two can race with each other.
… but, also, callers of imageProgressWriter just do defer pullWriter.Close and throw away the error value anyway.

It seems to me that we will need to use a channel to reliably get the error from the reading/decoding goroutine to the writer on imageProgressWriter.Close, and then all users will need to check the value.

It seems to me that we will need to use a channel to reliably get the error from the reading/decoding goroutine to the writer on imageProgressWriter.Close, and then all users will need to check the value.

https://github.com/openshift/imagebuilder/pull/97


Added iter methods to application, borehole, and log

Added the iter methods as discussed in #113 to the Application, Borehole, and Log class.

@janwillembuist, do you mind if I edit this PR a bit? I think it might be best if we add some intermediate containers so we're not directly iterating over the Application, Borehole and Log classes. Reason is, something like a Borehole for example can contain more than just logs. Headers, workspaces, etc could all be iterable.
There's also a bit more functionality available in a container. I could search by name, index, etc.

@m-schubert That's a good point! Feel free to edit the PR


Windowed mode & automatic reconnection

Does this library allows to send submit_sm messages with a window size greater than 1? For example, if the output window size is set to 10, I am allowed to send up to 10 submit_sm pdus before having the submit_sm_resp received. This mode can increase throughput to smsc substantially.
What about automatic reconnection of dropped smpp connections to smsc?

Many thanks!

Not currently. Would definitely be a great addition. Do you have any references to this handy? Otherwise I'll go back to looking at the spec later.

Default is to automatically reconnect, in background, with a back-off timer. You create the connection object (either Transmitter, Receiver or Transceiver) and use it for ever until you call Close.

As far as I know, there is nothing useful in smpp specs. I've missed to ask in previous post whether the library allows some kind of throughput control. Our (real) SMSC has hard limits on number of submit_sm per second which are allowed to be sent by ESMEs on a single connection. Yet it allows multiple simultaneous smpp connections. If you try to send faster or you ignore window size, you'll get ESME_RTHROTTLED for submit_sm above limits. If this happens, ESME needs to "calm down" for a while and then retry the submit_sm pdus which were throttled.
So for loadbalancing and failover, it is common to see large accounts (systemids) configured like this:

max n simultaneous ESME connections with y submits/seconds/connection
sending window size greater than 1
smsc sends periodic heartbeats to ESME for keep alive
it is a good performance practice for ESMEs to keep the connection alive.

Our ESME clients usually use a kind of round robin routing for sending submit_sm messages through the available (connected) smpp sessions for a large account. If any of the client smsc connections drops, the messages go through the remaining connected smpp sessions, while the dropped connection automatically re-connects and then binds to SMSC server.

Alright, so this Go package will provide you with:

Persistent client connection to SMSC, and you can create as many as you want
Each client connection handles heartbeats in background for you, automatic
Each client connection handles reconnection with back-off timer, and only stop when you want it

What it does not have for now is the ability to set window size, which I don't know how to do. If you can provide more information (is it a PDU or the value of a specific PDU that sets window size?) it shouldn't be too hard to implement.
Throttling can be easily implemented with buffered channels per connection. At this point I'm not entirely convinced it belongs to the library but due to the simplicity of doing this in Go it might be worth exploring a LimitedTransmitter which is an extension of the current Transmitter.

Related to throttling, I believe it should be a core feature - I haven't seen any real SMSCs which do not have very strict rules regarding throughput.
Also, please take into consideration that some more advanced platforms have dynamic throughput control (e.g. depending on internal load it can slow down ESMEs by rejecting submit_sm pdus with status=ESME_RTHROTTLED which is an indication that the client should reduce throughput for a while.
Regarding window size: window size is not a field in any smpp protocol pdu. It is the ability of a smpp session to send up to n smpp pdus (where n = window size) to SMSC without waiting for submit_sm_resp to come back from SMSC synchronously. As you have implemented the package, you are actually using a window size = 1 (meaning you wait for submit_sm_resp before sending another submit_sm)
An actual example:
Let's say you configure smsc account and your smpp session with a sending window = 5
In this scenario, you can send up to 5 submit_sm pdus from client before receiving a single submit_sm_resp pdu from SMSC.
When you've sent 5 pdus but you have not received any submit_sm_resp from SMSC, you should block the sending until you receive at least one submit_sm_resp. In that moment, you can send another submit_sm to fill the window again and you block again. If multiple submit_sm_resp are coming from SMSC quickly, you are allowed to submit again pdus in order to fill the window again to configured maximum (5 in our example). Sending should simultaneously respect both the throttle limit (the other limit mentioned above) and the sending window size.
Should you fail to respect the window size (e.g. you send the 6th submit_sm), the SMSC will start rejecting your submit_sm pdus by replying with a submit_sm_resp with status = ESME_RTHROTTLED and, in that case, the ESME should retry the submit after a while.
This windowed sending mechanism allows higher throughput over more latent connections (e.g. ESME and SMSC connect via Internet or using a VPN tunnel over Internet).

Answers inline

On Jan 24, 2016, at 9:28 PM, Robert Mircea<EMAIL_ADDRESS>wrote:
Related to throttling, I believe it should be a core feature - I haven't seen any real SMSCs which do not have very strict rules regarding throughput.
Also, please take into consideration that some more advanced platforms have dynamic throughput control (e.g. depending on internal load it can slow down ESMEs by rejecting submit_sm pdus with status=ESME_RTHROTTLED which is an indication that the client should reduce throughput for a while.

Right. As of now, this is expected to be handled by users of this library, it's not automatic.

Regarding window size: window size is not a field in any smpp protocol pdu. It is the ability of a smpp session to send up to n smpp pdus (where n = window size) to SMSC without waiting for submit_sm_resp to come back from SMSC synchronously. As you have implemented the package, you are actually using a window size = 1 (meaning you wait for submit_sm_resp before sending another submit_sm)
An actual example:
Let's say you configure smsc account and your smpp session with a sending window = 5
In this scenario, you can send up to 5 submit_sm pdus from client before receiving a single submit_sm_resp pdu from SMSC.
When you've sent 5 pdus but you have not received any submit_sm_resp from SMSC, you should block the sending until you receive at least one submit_sm_resp. In that moment, you can send another submit_sm to fill the window again and you block again. If multiple submit_sm_resp are coming from SMSC quickly, you are allowed to submit again pdus in order to fill the window again to configured maximum (5 in our example). Sending should simultaneously respect both the throttle limit (the other limit mentioned above) and the sending window size.
Should you fail to respect the window size (e.g. you send the 6th submit_sm), the SMSC will start rejecting your submit_sm pdus by replying with a submit_sm_resp with status = ESME_RTHROTTLED and, in that case, the ESME should retry the submit after a while.
This windowed sending mechanism allows higher throughput over more latent connections (e.g. ESME and SMSC connect via Internet or using a VPN tunnel over Internet).

The wire protocol implementation is asynchronous and would allow you to send as many submit_sm as you want before any submit_sm_resp arrives. This all happens amidst link enquiries and other commands. The Go API is blocking through, hiding implementation details to users of the package. That means calling Submit() will block until the corresponding response arrives, or a timeout (default 1s) occurs, but you can call Submit() multiple times in different goroutines and they'll all go through.
In other words we don't really have a window size today.

—
Reply to this email directly or view it on GitHub https://github.com/fiorix/go-smpp/issues/2#issuecomment-174338333.

Any word here @VDVsx ?

@fiorix What's the opinion what you are looking for from @VDVsx: whether or not to support these features or something else which requires clarification about the mechanism for throttling and window control?

Just an opinion from someone else that's been using this package as well, nothing specific.
I've been thinking about what would be the right way to implement this and will eventually come to a conclusion. If you have opinions I'm all ears.

I guess you would like the client connection should handle not only the submit throughput but also eventual "throttled" responses and slow down on its own as opposed to just returning an error from submit?

As a consumer of the library, I would like to know if my submit was successfully acked or not by SMSC. This is useful because I might want to retry for a number of times if I want my app to be robust against transient errors. I see ESME_RTHROTTLED the same way treated by library as any incoming enquire_link which unexpectedly comes from SMSC: automatically handled.
The automatic behaviour of the library in case  of the temporary errors (like ESME_RTHROTTLED) can be an option when you instantiate the transmitter. Ex. delayWhenThrottledMs = 0 (no delay) or 500 (wait 1/2 second before another submit_sm) etc

Was looking at the simulator I use for integration tests and it doesn't support throttling. This means I'd have to start by adding rate limit in the smpptest package, which is a server implementation, then move over to the client implementation.
On the client I'm unsure about how it can be correctly implemented. For example, the exported API (to consumers of the package) is currently a blocking API, and should remain that way. However, while the server is throttling these calls would potentially block for longer periods and would hit the max timeout.
Also, uncertain about handling ESME_RTHROTTLED automatically by retrying as opposed to just failing it and then internally slowing down the consumer channel that dispatch messages temporarily.

IMO both features would be nice to have, for mass sending current setup does not scale that well, since a lot of go routines need to be fired in parallel(+ same number of open connections to the SMSC), but I don't see a easy way to do this using a blocking API for the clients, but maybe introduce something new that would handle all this logic in the background ?

This package was designed to scale using goroutines like any other client/server in go, and integrating well with http servers and so on. For mass sending, you can have a pool of goroutines fed by a channel. Depending on your compiler version you can have 100 goroutines for roughly 400KB of ram.
As far as rate limiting, what I'm considering doing is adding a configuration attribute to the Transmitter struct that takes an optional RateLimiter type, defined as follows:
type RateLimiter interface {
    Wait(ctx context.Context) error
}

When present, the transmitter would call Wait internally before any Submit to pace the sending. This way you can either implement your own rate limiter or use the one from https://github.com/golang/time for example.
I might also have to add attributes to control the # of retries in case the SMSC returns ESME_RTHROTTLED, so we can unblock the call to Submit after N attempts.
Do any of you know if the SMSC allow bursts?

Also, I know it's common practice to limit the # of client connections per account, which in this case is how many concurrent Transmitters you can create to the same server.
Is there a case where the rate limit is applied per account, not per connection? If that's true we might have to share the Context used for the Wait amongst connections... hopefully not, to keep things simple.

No, rate limit is not applied per account! Only per connection.
SMSCs (Acision and Huawei - which I have experienced) are very strict and do not allow bursts (or at least they were configured not to allow)

I've uploaded the patch to the dev branch, please check it. It supports optional rate limiting but does not handle ESME_RTHROTTLED automatically. If that happens, your Submit will return an error although rate limiting still applies.
I'm still not convinced that rate limiting belongs to the package given its simplicity to implement. For example, if someone uses our rate limiter in an http server, it might slow down http requests making it harder to abort or cancel it on a per request basis. On the other hand, would be much easier to implement the rate limiter in the http server to control how fast Submit can be called per SMPP connection.
Anyway, check it out and let's take it from there.

Haven't been using this library yet (been reading through the source code though and have a good grasp of the functionality and features). Will give my opinion based on other SMPP libraries I've used (mainly Java ones).
Windowing should imo not be handled by the core library. As @fiorix mentioned, run multiple goroutines and you can make this happen, e.g. start 10 goroutines sharing the same input channel. They all do Submit() (which is blocking) meaning that you will at most have 10 outstanding Submit_SM PDU's.
Throttling should also be handled by the client using the go-smpp library. The core library needs to actively provide these errors back so that the user can decide how they want to handle the error.
I guess most of it boils down to: Is this a SMPP protocol library or a full SMPP server/client library. If the first then the users of the library should be implementing windowing/throttling etc themselves. I'd rather see one more project implementing a full server/client scenario, using this library, to solve the need for that.

That's valuable input, thanks @xintron. It seems to me we should just provide examples of how to use a rate limiter such as github.com/golang/time/rate together with this package rather than supporting it internally. Any word here @robertmircea? Also, have you looked at the patch?

+1
Would love to see / work on a full smpp server implementation but agree
this likely belongs in a separate project.
On Wednesday, February 10, 2016, Alexandre Fiori<EMAIL_ADDRESS>wrote:

That's valuable input, thanks @xintron https://github.com/xintron. It
seems to me we should just provide examples of how to use a rate limiter
such as github.com/golang/time/rate together with this package rather
than supporting it internally. Any word here @robertmircea
https://github.com/robertmircea? Also, have you looked at the patch?
—
Reply to this email directly or view it on GitHub
https://github.com/fiorix/go-smpp/issues/2#issuecomment-182385430.

For the server side, there's a rough implementation in the smpptest package that could be expanded. Since we support most of the wire protocol it's a matter of glueing things together.
Most of my effort in building this package was for the client side.

I'm happy to help further the server implementation.
On Wednesday, February 10, 2016, Alexandre Fiori<EMAIL_ADDRESS>wrote:

For the server side, there's a rough implementation in the smpptest
package that could be expanded. Since we support most of the wire protocol
it's a matter of glueing things together.
Most of my effort in building this package was for the client side.
—
Reply to this email directly or view it on GitHub
https://github.com/fiorix/go-smpp/issues/2#issuecomment-182422357.

@fiorix Still believe that the mechanism for handling windowing or throttling is an implementation detail of the library rather than a concern that the user of lib must take care of. I understand the need to keep the library pure, but both features are so basic that they need to be implemented by client almost 100% every time when used with real SMSC or commercial smpp gateway like mblox. I found this Java (cloudhopper-smpp) implementation https://github.com/fizzed/cloudhopper-smpp/blob/master/src/main/java/com/cloudhopper/smpp/impl/DefaultSmppSession.java#L493 which, in my opinion is a good, production quality code. It takes care of all error handling specific to protocol, windowing, timeouts, but yet it manages to publish towards the user all the events for decision or extension.The api exposed to the user enables both sync and async communication pattern. (yes, it's Java style verbose code :))
Giving the last "dilemma" from @xintron, I will surely go with the value provided by the full fledged client library rather for a pure protocol implementation. Of course, a client library can be a separate package which depends on this one, as last resort.
I will take a look at the patch and try it during the weekend.

I have successfully implemented this functionality using a circuit breaker. As I suspected, there's no reason to have such logic in this package's code.
The circuit breaker I'm using, for reference: https://github.com/sony/gobreaker/
Closing this ticket for now.

Added the option to set a max window size, and the client will refuse to send messages if you hit that. This helps with the circuit breaker.

I want to create a pool of connections let say 10 provided by SMSC and reuse them in goroutines. I see above that I can create as many connection objects as I want and use them but I don't know how to achieve this. Can I get a sample may be? or some steps.
Thanks in advance.

@mwangox you can simply create as many transmitters or transceivers as you need. Not sure what's the deal here.


No License

Could you add a license, please. I would love to use your awesome code :)

Yes! Please add a license

Yes! Please add a license

Please add a licence! :)


Mouse scrolling events are sent twice on GNOME

When scrolling with a mouse (not a laptop touchpad), the scroll events are sent twice. Reproduced on two different machines with two different mice using the events test. Couldn't reproduce on KDE Plasma.
Scrolling Up -> Down -> Up -> Down:
00000002 to 1 at 1.867: Scroll: 0.000 1.000
00000003 to 1 at 1.867: Scroll: 0.000 1.000
00000004 to 1 at 2.262: Scroll: 0.000 -1.000
00000005 to 1 at 2.262: Scroll: 0.000 -1.000
00000006 to 1 at 2.672: Scroll: 0.000 1.000
00000007 to 1 at 2.672: Scroll: 0.000 1.000
00000008 to 1 at 3.103: Scroll: 0.000 -1.000
00000009 to 1 at 3.103: Scroll: 0.000 -1.000

Here's WAYLAND_DEBUG=1 output if it helps: scrolling-wayland-debug.txt

I also noticed that way before 2024, but I "fixed" the problem myself.
https://github.com/BoyOrigin/glfw-wayland/blob/main/patches/0002-Fix-duplicate-pointer-scroll-events.patch

This seems likely to be caused by a bug in GNOME's implementation of version 4 of wl_seat, especially considering that #2499 resolves the issue without any of the additional logic a move to version 5 would require. This is great news because I was going to implement support for at least version 8 soon anyway, which should then also fix this bug.


Home directory is expanded incorrectly in different programs

Your Windows build number:  (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.17763.134]

What you're doing and what's happening:  (Copy&paste specific commands and their output, or include screen shots)

Trying to edit a config file in the home directory. But it turns out that VS code opens a different file.
Here is how I invoke the command in the console:
alexko@alexko-ds /m/e/C/a/p/d/A/N/SymmetricKeys> cat ~/.tmux.conf
alexko@alexko-ds /m/e/C/a/p/d/A/N/SymmetricKeys> code ~/.tmux.conf
And here are the paths that are actually being touched:

What's wrong / what should be happening instead:

Both paths should resolve in the same place, not edit two different unrelated files.
Right now I don't know how to use VS code to edit config files...

I assume you're talking about Windows code.exe via interop. Windows (win32) programs cannot access stuff in LxFS. #1524. If you want to edit with code.exe you need to be in /mnt/c/Users/you/somewhere.


CSP support

Add csp support and wiki article documenting required setup

closed via https://github.com/obartra/reflex/pull/328


How to perform 2D convolution with user defined kernel just like sobel filter?

How to perform 2D convolution with user defined kernel just like sobel filter? Kindly provide example

You can fix the weight of convolution.

With Gluon API you can set_data on a parameter. So for a convolutional layer you can select the weight (which will be the kernel) and call set_data on this with the kernel of your choosing. You must make sure you have the correct shape, with the dimensions being (filter, channel, height, width). So if we wanted a single sobel kernel applied to a single channel input we could for the following:
import mxnet as mx

# kernel of your choosing (e.g. a sobel filter)
kernel = mx.nd.array(((1,0,-1),
                      (2,0,-2),
                      (1,0,-1)))
# add dimensions for filters, and input channel
# both of which will have shape 1, since single filter and single input channel
weight = kernel.expand_dims(0).expand_dims(0)

conv = mx.gluon.nn.Conv2D(channels=1, kernel_size=(3,3), padding=(1,1))
conv._in_channels = 1
conv.initialize()
conv.weight.set_data(weight)

@marcoabreu can you close out this issue since the question has been answered with example by @thomelane