toolkit.telemetry.cachedClientID keeps repopulating since Firefox 67

On Firefox 66 and older versions, toolkit.telemetry.cachedClientID would not show up with telemetry disabled (by policies.json.).
However, after upgrading to 67, Firefox keeps setting toolkit.telemetry.cachedClientID to a UUID-like string. Resetting or setting it to an empty string does not help. It just repopulate the next day.
I have also tried modifying other telemetry-related entries, but cannot find the way to stop it.
Any idea?

Apparently, Firefox now resets the pref if the value is invalid.
https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/app/ClientID.jsm#232-240

If you're not sending any telemetry data back then it doesn't matter

then it doesn't matter

Is there any point in keeping that pref around then? I'm asking more out of curiosity than anything else.

Oh, I didn't realize it was in the user.js - got confused with some other id pref someone else mentioned several weeks ago

FWIW, my toolkit.telemetry.cachedClientID is blank. Been on 67, now 67.0.1, for, IDK, 6 days or so. Loads of restarts.
Where is it getting set from? A system add-on?

Where is it getting set from? A system add-on?

A function in the ClientID module itself is resetting the pref. Are there any errors in your console when you launch Firefox that may be related to that? Something in your setup must be preventing that code from running somehow... I can try to dig a bit more but it will take a while

fuk, just did a big edit in my last post

This is what Nightly does - it's a nilla profile, with just the user.js overwriting the pref

I think what's going on is simply that you already had that empty clientID cached, and the function was simply retrieving it from disk, see here
https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/app/ClientID.jsm#220-229
If you reset the pref in your FF67 profile and restart, Firefox will most likely end up resetting the pref again over and over afterwards.

 Because nightly keeps resetting the option to send telemetry. I disabled that and the id got removed. But now I can't replicate that and instead got trumpy's cofffeeeeeeeefeeee
c0ffeec0-ffee-c0ff-eec0-ffeec0ffeec0

Actually c0ffeec0-ffee-c0ff-eec0-ffeec0ffeec0 seems to be a generic string they use

Jesus, what a mess
Nightly sometimes resets the UI to send telemetry, the one in Privacy & Security> Data Collection and Use > Allow Nightly to send techincal....
With the option unchecked on startup, the pref doesn't exist (despite the user.js) but then manifests after about a minute: and gets set consistently to c0ffeec0-ffee-c0ff-eec0-ffeec0ffeec0, turn the UI telemetry option on, and it gets set to a unique string, uncheck it and you get Trumps cofefe again.
If anyone cares to dig deeper, then test it in 67 or 68, not nightly. BTW, nightly is my only installed version: all the others are portable. I've tried various things,. such as removing all telemetry traces (saved pings), clearing the startupcache, wiping the permanent chrome idbs (which get recreated) - it has nothing to with them

and instead got trumpy's cofffeeeeeeeefeeee

You only complain because you're getting ☕ instead of :beer:
FWIW, the cached ID is stored in profile_dir/datareporting/state.json. Restricting write access to that file does not prevent Firefox from generating a new ID on restart, but it prevents it from writing it to disk, meaning your client gets a new ID on every restart.

OK, so here's some MOAR stuff.
The pref does not exist, and the toolkit.telemetry does not set it
Pic1: immediately after starting

but after about a minute, it gets "shows" as reset at the exact same time the info appears -> view-source:resource://services-settings/remote-settings.js
Pic 2: about a minute later

Of course that might just be when the pref change is picked up to display to about:config - but nah, cuz I see pref changes happen in real time, so I don't think that's it.
End of the day, go play in a non nightly, I think

all yours

I can't even reproduce in 68. In a nilla profile, I added the entire user.js. Restarted, checked, waited, checked the UI options for telemetry were all unchecked .. waited, checked the pref - closed. Redid it three times. The pref remains blanks
OP says he gets it in 67 - I don't. I can't even get it in a new 68.

Telemetry is not optional on Nightly. Maybe it can be disabled with policies.json, but I wouldn't bet on that.
https://blog.nightly.mozilla.org/2018/06/27/protecting-your-privacy-in-firefox-pre-release/
You say the pref doesn't reset for you, but you are getting the same error as I, so the code for resetting the pref is running on your end too.
I'll look into this later.

I have a few minutes for this... My first link above:
https://dxr.mozilla.org/mozilla-central/source/toolkit/components/telemetry/app/ClientID.jsm#232-240
That is meant to make sure the value is a string, and only reset the pref if not. That is outright weird, because "" is a string (and empty one, but a string). Why the hell is this condition...
    if (Services.prefs.prefHasUserValue(PREF_CACHED_CLIENTID) &&
        Services.prefs.getPrefType(PREF_CACHED_CLIENTID) != Ci.nsIPrefBranch.PREF_STRING)

returning true on launch?... I'm gonna test a few things...

OK...  I mean, I did, but I only tested ONE thing, and it wasn't all that important. I kept digging in the source code though, and AFAICT this pref is only used as a cache presumably to avoid repeat reads from disk, but also apparently for some comparisons. When FF launches it looks for the file I mentioned above, reads the Client ID property there, and sets the value of this pref afterwards. The delay you mentioned is intentional, and explained here.
I can keep digging later, but TBH, it's already looking like a waste of time, because the pref ends up in two places: prefs.js (and I still don't know why they keep saving this pref in that file - maybe they're in the transition to stop doing that, or they don't care) and state.json (which is beyond the reach of this project). So far I'm not seeing any reason to keep this pref in the user.js.

i'm using
pref("browser.newtabpage.activity-stream.impressionId", "");
in my firefox.cfg and it's alway clean.

FWIW, the cached ID is stored in profile_dir/datareporting/state.json.

I didn't have a datareporting folder in my old profile (I made a backup before upgrading). Yet somehow there is a datareporting/state.json in my current profile and the creation date is exactly the date I upgraded to Firefox 67.
I'm not sure why it got created after upgrading. I will delete that folder and see if it will be recreated after some time.

I will delete that folder and see if it will be recreated after some time.

It will be recreated the next time you restart Firefox.

@openffchrome pref() doesn't do the trick on my end, but lockPref() does. At least that's better than messing with datareporting/state.js...

Actually, it doesn't matter if the value of toolkit.telemetry.cachedClientID is "" or not, because the ClientID module still has the ID it reads from state.js stored in the _clientID property at runtime, and accesses it from there. The most that can be done is to prevent Firefox from saving the ID to disk, which causes it to generate a new different ID for each session. Now the question is, is this worth documenting?

Not sure why nobody seems to understand that my FF67 (portable) is not setting a new value on any restarts. So there is clearly a way to block it entirely. I've usually use my browser in 4 or 5 hrs lots at a minimum. I left it running for since I was last here. Checked it (blank), closed, restarted, checked (still blank) and so on.  I wonder what's so different about my setup.

And now FF reset it - you guys put a pox on me. I was fine until the whole saga was brought up and I experimented :sigh:

Some reading for :cat2:

FF44 - diff

PS: This is from 2 years ago

This cached clientId gets created when Telemetry initializes....

I'm not sure what they changed in 67 - I've looked at all 67 fixed Telemetry bugs, I've searched, I used mercurial. But I find it strange that I don;t seem to trigger this, except now that its been brought to my attention, it changed once in "24" hrs, and never on a restart. Know what else checked once every 24 hrs? That intermediate cert check for extensions - totally jumping the gun here - but any bugs stemming from that, e.g to strengthen how they can push a rapid fix, might not be public yet.
Anyway, I've set my state.json id to a blank string and will see what happens in the next 24 hrs. But I think this is the wrong approach. Telemetry needs to initiate in order to do it, and I don't seem to trigger that (at least not on a start)

You are right. It's back again.
I also tried deleting state.json, locking the datareporting folder, resetting every pref with a timestamp as its value, and restarting Firefox.
Then I got this error.
Unix error 1 during operation open on file /path/to/profile/datareporting/state.json (Operation not permitted) RemoteSettingsComponents.jsm:23
    notify resource://services-settings/RemoteSettingsComponents.jsm:23

And a new ID was generated.

The log.jsm 679 line is never fired

That's not as important as I first thought. It's just meant to ensure the value of the pref is a string, and if it's not a string it clears the pref (to nothing). The check for actual validity is the isValidClientID() function, that is called from getCachedClientID() and updateClientID(), which is in turn called from _doLoadClientID().

It seems to happen when app.update.lastUpdateTime.services-settings-poll-changes is updated.

I'd say that's a coincidence. services.settings.poll_interval is used for remote settings. RemoteSettings.srt
Let me summarize to you what I've gathered, in english (or something close to english):

The client id (the string itself) is only generated/rebuilt around 1 minute after Firefox starts. The delay is intentional to allow the client to load fully (briefly explained here).
Once generated, it is saved to disk (in state.json) and the pref is set to the same value.
The pref exists solely in case the ID needs to be read anytime before telemetry fully initializes (which happens after around 1 min, as previously stated). I wasn't sure of this, but I am now after reading this (thanks :jeans: for the link). The pref is read immediately on launch from prefs.js. This is why the pref is called cachedClientID.

I'm sorry to spoil the fun, but AFAIK this pref has always been relevant only during that minute after startup. It exists to fulfill that specific role. Setting it to "" in earlier versions only prevented Firefox from sending a unique ID during that first minute of runtime. Firefox still had a unique ID stored in state.json back then.
The key difference with versions prior to 67 is that Firefox now checks the ID for validity, and generates a new ID if invalid (empty string is now considered invalid), but this is done after that 1-min delay. Before then, Firefox merely clears the pref if its value is invalid (but doesn't repopulate it until telemetry fully initializes). This explains the console error (it's logged by the check that clears the pref) and why the pref is set to a unique ID after the delay.
The pref alone should be nearly useless nowadays. I still didn't get around to testing how different clients behave though, I gathered all of this reading and doing a few tests in my main profile. I don't have a clue why the pref does not or did not get set to a new ID for you guys after full telemetry initialization, but as I explained here, the pref itself is not that important because it is only relevant for that first min of runtime.

I don't think it's a coincidence.
In resource://services-settings/RemoteSettingsComponents.jsm:
ChromeUtils.defineModuleGetter(this, "RemoteSettings",
  "resource://services-settings/remote-settings.js");

In resource://services-settings/remote-settings.js:
ChromeUtils.defineModuleGetter(this, "UptakeTelemetry",
                               "resource://services-common/uptake-telemetry.js");

In resource://services-common/uptake-telemetry.js:
ChromeUtils.defineModuleGetter(this, "ClientID",
                               "resource://gre/modules/ClientID.jsm");

Finally, in resource://gre/modules/ClientID.jsm:
XPCOMUtils.defineLazyGetter(this, "gDatareportingPath", () => {
  return OS.Path.join(OS.Constants.Path.profileDir, "datareporting");
});

XPCOMUtils.defineLazyGetter(this, "gStateFilePath", () => {
  return OS.Path.join(gDatareportingPath, "state.json");
});

const PREF_CACHED_CLIENTID = "toolkit.telemetry.cachedClientID";

Slightly OT:
:jeans:, where you aware of this...? (emphasis mine)

toolkit.telemetry.enabled
If unified is off, this controls whether the Telemetry module is enabled. It can be set or unset via the Preferences dialog in Firefox for Android (Fennec). If unified is on, this is locked to true if MOZ_UPDATE_CHANNEL is nightly or aurora or beta or default (which is the default value of MOZ_UPDATE_CHANNEL for developer builds). Otherwise it is locked to false. This controls a diminishing number of things and is intended to be deprecated, and then removed.

https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/telemetry/internals/preferences.html

I don't think it's a coincidence.

Coincidence is not the right word. I meant to say that the fact that those things seem to correlate by observation does not mean that the code for generating/storing/reading the ID depends on or is affected by those prefs you mentioned.
BTW, the lazy getters gDatareportingPath and gStateFilePath in resource://gre/modules/ClientID.jsm in that code you pasted are used to get the path to the datareporting/state.json file.

was I aware of that? Nope? All greek to me (that's slang for WTF does that mean). As long as the all telemetry can be disabled (despite the growing number of prefs) then I'm happy.
So, 24 hrs was a good guess, since the default is 86400 seconds. FWIW, I wouldn't mess with that, for all I know it's used for other purposes: and not worth while investigating. I for one do not like messing with timers in FF.
https://github.com/ghacksuserjs/ghacks-user.js/issues/739#issuecomment-499508615

If you're not sending any telemetry data back then it doesn't matter

So I guess we can remove the pref from the js, since it's 1) redundant and 2) useless. Right?

As long as the all telemetry can be disabled (despite the growing number of prefs) then I'm happy.

I was pointing out that they intend to deprecate and eventually remove toolkit.telemetry.enabled, which sucks, because I imagine the number of prefs needed to fully disable telemetry will skyrocket when that happens.

So I guess we can remove the pref from the js, since it's 1) redundant and 2) useless. Right?

I leaned toward removing it, at first, but personally, I'd just leave it there for now. Maybe we should just point out that it is only relevant before telemetry initializes fully (and link to sources), as a FYI. IDK, up to you.

Pros

one less pref is always good

Cons

people will cry and earthlng will have a hernia

Thanks for reporting this, @roviavas


mvn install on project is giving error

Im getting test failures on mvn install. It absolutely seems this repo is not maintained anymore


Combobox should toggle on clicking anywhere on the field, not just the carat

Click on fields should show list of options. In the previous release, click on a field in the sidebar after selecting something showed list of options, now it doesn't work. We have to click on the arrow to show list of options. It would be great we can have the old behavior.

Click on fields should show list of options. In the previous release, click on a field in the sidebar after selecting something showed list of options, now it doesn't work. We have to click on the arrow to show list of options. It would be great we can have the old behavior.

Users can still press the up/down keys, click the carat, or start typing in order to get the menu to pop up.
I think the new behavior is a lot more in line with how other comboboxes/dropdowns work on other sites.  Can we just try it out this way for a little while?

I use ID every day since three years so this change is a little confusing for me. But I will maybe accustom with this new behavior, even if I find the old behavior more convenient. Please let the ticket opened in order to see who agree with this. (sorry for my bad english, I'm french)

I actual prefer the new behavior. I don't always want to have the dropdown open obtrusively when I click the field to edit directly. Not that I have yet encountered a case where immediately opened dropdown was a problem.

Maybe it would be a compromise to increase & clear separation (add a vertical line) of the carat area...

I'm planning to make it so that you can click anywhere on the field to toggle the combo (not just on the carat area)

@maxgrossman  you can look into this one too..
I think it's just that this block of code needs to move from the carat to the input and then the carat should get CSS pointer-events: none so the clicks don't go to it.
https://github.com/openstreetmap/iD/blob/f478fdbfbd3f9cb4f8ddd0b232c78d523dfefc3e/modules/ui/combobox.js#L69-L83


[Feature][Zeta] Support slf4j mdc tracing job id output into logs

Purpose of this pull request
[Feature][Zeta] Support slf4j mdc tracing job id output into logs
reference
https://www.slf4j.org/manual.html#mdc
https://logging.apache.org/log4j/2.x/manual/thread-context.html#configuration
https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout
subtask of https://github.com/apache/seatunnel/issues/2725
Does this PR introduce any user-facing change?
No
How was this patch tested?
Added
Check list

[ ] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[ ] If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs
[ ] If you are contributing the connector code, please check that the following files are updated:

Update plugin-mapping.properties and add new connector information in it
Update the pom file of seatunnel-dist
Add ci label in label-scope-conf
Add e2e testcase in seatunnel-e2e
Update connector plugin_config

[ ] Update the release-note.

Good feature, Thanks @hailin0 for working on this.
related to this feature, is there anyway to get all the logs corresponding to job id ?

Good feature, Thanks @hailin0 for working on this. related to this feature, is there anyway to get all the logs corresponding to job id, using API or command ?

@arshadmohammad
The logs of distributed programs(job) are scattered on different machines. What are your thoughts?

I was thinking of functionality similar to mapreduce and yarn, all mapreduce jobs have separate logs.

I will do some verification later


net/reconnect: Client: add SetReadDeadline() and SetWriteDeadline()

methods used when we want to set one without touching the other

<EMAIL_ADDRESS>tagged


IndexIgnore to .htaccess and /fancy-index, so they do not show to users

I personally like seeing the .htaccess and /fancy-index. Maybe instead of hiding them, add a section the bottom of the readme for customizing hidden files and directories?

Good. I will do it.

Added in #6, thanks!


Retry whole batch of deletes on 429.

Because Bucket.delete inside a batch context manager is deferred, we cannot retry it directly.  We also need to check for bucket existence, as the bucket may have been deleted successfully in the previous batch before the 429 was raised.
Closes #3761.

CircleCI failures are unrelated vision flakiness (#4035).

Rebased after merge of #4050.  Fingers crossed.

@tseaver ISTM we should just drop the batch.

Superseded by #4102.


Ferret v6.7 crashes when appending to open file

Reported by andrew wittenberg on 13 Apr 2011 23:04 UTC
Discovered this when testing the new v6.7 executable on some of our standard analysis scripts, which append wavelet-related variables to a NetCDF file that provides a time series.
This worked fine up through v6.7beta:
    NOAA/PMEL TMAP
    FERRET v6.7 (beta)
    Linux rh5 (gfortran) 2.6.18-238.1.1.el5P - 02/16/11
    13-Apr-11 18:58

yes? use coads_climatology
yes? save/clob/file=a.nc sst
LISTing to file a.nc
yes? use a.nc
yes? save/append/file=a.nc airt[LISTing to file a.nc
But in v6.7 we get a crash:
    NOAA/PMEL TMAP
    FERRET v6.7
    Linux rh5 (gfortran) 2.6.18-238.1.1.el5P - 04/04/11
    13-Apr-11 18:56

yes? use coads_climatology
yes? save/clob/file=a.nc sst
LISTing to file a.nc
yes? use a.nc
yes? save/append/file=a.nc airtd=1
LISTing to file a.nc
*** Unknown error code:       899 ***
Expected: could not open CDF output file: Found: a.nc
At line 309 of file tm_errmsg.F
Fortran runtime error: End of record
(By the way, we need a v6.7 version tag in Trac -- leaving this as an "unspecified" version for the moment.)
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/1832

Modified by ansley.b.manke on 14 Apr 2011 03:29 UTC

Comment by steven.c.hankin on 14 Apr 2011 15:41 UTC
Just adding that there are two distinct errors evident here:

"Unknown error code: 899" from the netCDF library when attempting to write into a file that is also open for reading
Fortran runtime error: End of record   at line 309 of file tm_errmsg.F

Comment by steven.c.hankin on 14 Apr 2011 15:48 UTC
P.S. We have seen several "Unknown error code" messages from netCDF, since the switch to version 4.  Could it be that there is a trove of new-to-netCDF error conditions that is arriving from the HDF side of the family?

Comment by ansley.b.manke on 14 Apr 2011 18:13 UTC
The error code here is outside the range of "netcdf error codes" that we look for in the error-handling routines, and which trigger sending the code to the netCDF error translation function.  When I explicitly feed the error generated by this script into the translator, the result is
NetCDF: HDF error (OPeNDAP/netCDF Error code -101)
Not very helpful. I'll see if there are any HDF error-translation calls that could be made.
The error occurs on the call to open-for-writing on the dataset that's already open. I can make some tests to see if I find a workaround.

Comment by ansley.b.manke on 14 Apr 2011 18:20 UTC
As to the error itself, I think this is an essential change with NetCDF 4.1.2. We can't open a dataset for reading, and then leave it open but turn around and open it for writing, as in the "save/append".
In testing beta versions of netCDF4.1.2, I had run into a couple of cases where our benchmarks tried to clobber datasets that were open, and when I asked Unidata about that I was told that the code had been re-factored so it wouldn't allow that, and I shouldn't be trying to do it anyway.  That seemed to me fair enough.  We didn't happen to have any examples where we tried to append to an open dataset.
My first thought is that I could work around this within Ferret by checking whether the file to be appended is already open, and close it; then re-open for writing.  That wouldn't affect any definitions of variables based on the open dataset, but would wipe out any data in memory. Andrew, what do you think?  Are your scripts doing things that would be disrupted by this solution?
Can't locate any old documentation on netcdf or opendap-implemented/netcdf that would tell me whether changing the read-mode to write-mode of files using the NF_OPEN call was previously explicitly allowed, or whether we were just able to do it somewhat accidentally.

Comment by steven.c.hankin on 14 Apr 2011 23:36 UTC
Documentation at http://www.unidata.ucar.edu/software/netcdf/docs/netcdf-f77.html#NF_005fOPEN implies that the problem might be fixed by setting the open state as NF_SHARE:
"The NF_SHARE flag is appropriate when one process may be writing the dataset and one or more other processes reading the dataset concurrently; it means that dataset accesses are not buffered and caching is limited. Since the buffering scheme is optimized for sequential access, programs that do not access data sequentially may see some performance improvement by setting the NF_SHARE flag."
(It is not altogether clear that the '''same process''' can be both reading and writing.)
However, the performance loss to using this is a serious concern.  If one were to use NF_SHARE in order to allow simultaneous reading and writing, you'd probably want to provide it by special request.  E.g.  USE/READWRITE filename.nc

Comment by andrew.wittenberg on 15 Apr 2011 23:00 UTC
If a user attempts to write to a file that is already open in Ferret, I'd suggest issuing a warning, saving the dataset number, closing the file, doing the write, and then re-opening the file with the same dataset number.  That should allow previous scripts to work, while letting people know what's going on.
I think the result of this action would then simply be the import of the new variable(s), right?  Would any unmodified axes come in under the same (perhaps Ferret-modified) names as before the write?
I'd suggest making the warning optional somehow, either through a "mode," or a qualifier on the SAVE.  But the warning should be on by default, to inform users of the performance hit of having to re-use the file -- and perhaps the message could suggest that the user refactor their code to close the file before writing to it.

Comment by steven.c.hankin on 15 Apr 2011 23:33 UTC
"''...saving the dataset number, closing the file, doing the write, and then re-opening the file with the same dataset number ...''"
Indeed, this does sound like the ideal behavior.  A variation on this approach is for Ferret to recognize when an attempt is made to write to an already-open file, and if so, to enter netCDF define mode on that same dataset id without closing it.  Then return to data mode, when the write operation is done.
Closing the dataset may be an approach that opens a very large can of wiggling worms.  Datasets own variables, which own grids, which own axes.  Python variables own parent-child (subset) relationships to axes.  "Native stride" datasets have similar parent-child relationships.  When a dataset is closed all kinds of dependencies are checked and objects cleared away if no longer used.  When a dataset is re-opened the axes and grids do not necessarily have the same names that they previously had.  Memory holds cached values of variables from datasets.  These will be wiped clear, when the dataset is closed, and potentially slow to reread.  These are only the problems that immediately come to mind.
Yet another approach:  we are checking into the possibility that one can tell the netCDF4 libraries to open a dataset in a manner that allows both reading and writing ("NF_SHARE") at a penalty in performance.  In which case we could offer a new Ferret qualifier USE/READWRITE (or whatever) to open a Ferret dataset in this mode.
It's tough when the underlying libraries change basic operating modes.  Basic assumptions get violated.  Makes you wanna say "goddamit".

Comment by ansley.b.manke on 16 Apr 2011 00:08 UTC
I have not had success with experiments using the "NF_SHARE" option. All attempts to open the file for writing when it's already open are failing with the same error code; whether it was originally opened with NF_SHARE or not; whether the second open is with NF_SHARE or not. The documentation does say it is intended for cases of different processes accessing the same file.
When opening datasets to APPEND, we've always just done a call to NF_OPEN with write mode turned on and the library apparently either opened it or changed to write mode if already open. As Steve says we can explore whether we can just detect that the file is open and change its mode.
It might be a good idea to contact Unidata.  If we can explain the use cases and argue that behavior that's been allowed through generations of NetCDF and OPeNDAP should be continued, then maybe they can change the behavior of the library. That would be ideal (for us).  It may be that they're accommodating changes in other libraries, or it may be that they were just "cleaning up" a combination they didn't think should be allowed and didn't realize there are reasons to allow for this particular sequence.
My just reporting that "we've been able to do xyz in the past and cannot now do it" is a weaker argument than knowing what scenarios are used in practice.

Comment by andrew.wittenberg on 16 Apr 2011 01:06 UTC
Thanks very much for your efforts -- sounds like this is a tough one
The actual scenario is "appending a variable derived from a previous variable in the file", e.g. appending an average, or in my case a wavelet analysis.  So here's a more relevant example:
        NOAA/PMEL TMAP
        FERRET v6.7
        Linux rh5 (gfortran) 2.6.18-238.1.1.el5P - 04/04/11
        15-Apr-11 20:55

yes? use coads_climatology
yes? save/clob/file=a.nc sst
 LISTing to file a.nc
yes? use a.nc
yes? let my_ave = sst[save/append/file=a.nc my_ave

(Note that in v6.7beta and prior, the "my_ave" variable wouldn't actually show up in Ferret unless we re-USEd the file.)
A workaround, for our scripts that are failing, would be to do something like this:
        NOAA/PMEL TMAP
        FERRET v6.7
        Linux rh5 (gfortran) 2.6.18-238.1.1.el5P - 04/04/11
        15-Apr-11 20:59

yes? use coads_climatology
yes? save/clob/file=a.nc sst
 LISTing to file a.nc
yes? use a.nc
yes? let my_ave = sst[t=@ave](t=@ave]
yes?)
yes? sp cp -f a.nc b.nc
yes? save/append/file=b.nc my_ave
 LISTing to file b.nc
yes? can dat a.nc
yes? sp mv -f b.nc a.nc
yes? use a.nc

Comment by steven.c.hankin on 25 Apr 2011 16:13 UTC
(I guess I forgot to hit SUBMIT last Thursday after entering detailed notes about the following topics.  dumb. dumb. dumb.   So here is a quick repeat of the ideas from memory.)
It isn't hard for Ferret to work around the problem identified in this trac ticket with reasonable reliability.  Ferret can realize when at attempt is being made to /APPEND into a file that is already open for reading.  When it detects this situation, then with some small changes to the code, it can make things work by reading and writing to the same open netCDF id.  Here's a sketch of how:
o in CD_OPEN_OUT there is already logic to detect the existence of the target file.
o If it exists, then also check to see if this filename is already open in Ferret.  There is code to do this under the SET DATA command, where it similarly checks to see if SET DATA refers to an already open file.
o If the target file is already open, then in CD_OPEN_OUT, instead of attempting to open it again, simply grab the netCDF ID of the open dataset.  It is stored in sf_lunit.
o The complicating factor is to have the code remember that it has borrowed this netCDF ID, so that when the output operations are finished, it will remember to restore the netCDF mode (not leave the file in DEFINE mode) and not close the file.
o note: keep in mind the possibility of an error happening during output.  The error trapping logic must similarly leave the output file open and not in DEFINE mode.

Comment by ansley.b.manke on 27 Apr 2011 20:15 UTC
If a file has been opened for reading, and on a call to append we try to just leave it open inside CD_OPEN_OUT, we cannot change its mode.  Here for testing I just skip the NF_OPEN calls when appending to a file I know is open:
yes? use coads_climatology
yes? save/clob/file=a.nc sst
 LISTing to file a.nc
yes? use a.nc

yes? save/append/file=a.nc airt[LISTing to file a.nc
NetCDF: Write to read only (OPeNDAP/netCDF Error code -37)
 could not change CDF mode
LIST/FORMAT=CDF/append/file=a.nc airt[d=1](d=1]
)

Instead, in the case where the file is already open, I think I can just issue a NF_CLOSE using that cdfid, and immediately a NF_OPEN with the NF_WRITE parameter; checking that the cdfid remains the same. In NetCDF4, the cdfid is a hash-type number, not 1,2,3 and so I think it's generated from the file and so I believe does remain the same.  Regardless, the code should be sure.
About the last two bullets in the above comment, previously when we did a SAVE/APPEND to the already-open file, the call to re-open the file changed its cdfid.
And after writing to the file, we have always left it closed. At the end of CDF_LIST, we issue a call to close the file, just with a call to the netCDF routine NCCLOS.  That call does not cancel the memory, variables, and other definitions associated with the dataset. So it looks to Ferret as if the file is still open with the contents it had before the append.
It looks to me as if this means that we can get the previous behavior quite easily as long as we make sure that we have the correct cdfid for the file when it's open or reopened.

Comment by ansley.b.manke on 29 Apr 2011 18:55 UTC
This one is my doing. In a conversation about the flags for opening files (clobber or not, netcdf4 or classic) with Ed Hartnett, where he had fixed something, and I needed to make a change as well, I seem to have misunderstood the right way to combine the flags.
This is fixed and works as it always has, with no need for all the above machinations.  I've created Ferret executables for us to test with the current NetCDF 4.1.3 snapshot release.


BasicAsyncOperationsTest.testAsyncNonNativeBasic7 test fails intermittently

Description:

$title
https://scans.gradle.com/s/x5imfkhsmuoyk/tests/:jballerina-unit-test:test/org.ballerinalang.test.expressions.async.BasicAsyncOperationsTest/testAsyncNonNativeBasic7?expanded-stacktrace=WyIwIiwiMC0xIl0
Even though the cancellation flag in the strand is set by the code, it does not behave as such.
Steps to reproduce:
public function main() {
    foo();
}

function foo() {
    foreach int i in 0...9 { // sometimes can be reproduced with one iteration
        error? unionResult = trap testAsyncFuncCancelled();
    }
}

function testAsyncFuncCancelled() returns error? {
    future<()> f1 = start func();
    f1.cancel();
    check wait f1;
}

function func() {
    while true {}
}

Affected Versions:
Seen in the master branch and update 2 branch
But not in the 2201.1.x branch
OS, DB, other environment details and versions:
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

For the above code when hanging the strand dump is as follows.
Ballerina Strand Dump [2022/07/27 16:49:31]
===========================================

Current no. of strand groups    :       2
Current no. of strands          :       2

group 4 [QUEUED]: [1]
        strand 2 "main" [$anon...0:main] [WAITING]:
                at      $anon...0.0.0:testAsyncFuncCancelled(issue.bal:15)
                        $anon...0.0.0:foo(issue.bal:8)
                        $anon...0.0.0:main(issue.bal:3)

group 5 [RUNNABLE]: [1]
        strand 3 "f1" [$anon...0:testAsyncFuncCancelled][2] [RUNNABLE]

===========================================

Due to the work done in https://github.com/ballerina-platform/ballerina-lang/pull/36395, now for the above function func the strand annotation any gets added as it can be safely run on a separate thread. Since the cancellation flag in the strand set by cancel is only checked when the strand yields, need to make the function yield inside the infinite loop.


Unable to find SDL on Ubuntu 22.04

I tried running https://github.com/littledivy/flappybird on Ubuntu 22.04 with the following result:
18:28 ~/Sc+/flappybird (main) $ ls /usr/lib/x86_64-linux-gnu/libSDL2*
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.18.2
/usr/lib/x86_64-linux-gnu/libSDL2_image-2.0.so.0
/usr/lib/x86_64-linux-gnu/libSDL2_image-2.0.so.0.2.3
/usr/lib/x86_64-linux-gnu/libSDL2_mixer-2.0.so.0
/usr/lib/x86_64-linux-gnu/libSDL2_mixer-2.0.so.0.2.2
/usr/lib/x86_64-linux-gnu/libSDL2_net-2.0.so.0
/usr/lib/x86_64-linux-gnu/libSDL2_net-2.0.so.0.0.1
/usr/lib/x86_64-linux-gnu/libSDL2_ttf-2.0.so.0
/usr/lib/x86_64-linux-gnu/libSDL2_ttf-2.0.so.0.18.0
18:28 ~/Sc+/flappybird (main) $ uname -a
Linux oz 5.15.0-119-generic #129-Ubuntu SMP Fri Aug 2 19:25:20 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
18:28 ~/Sc+/flappybird (main) $ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 22.04.4 LTS
Release:	22.04
Codename:	jammy
18:28 ~/Sc+/flappybird (main) $ ./flappybird
error: Uncaught (in promise) Error: Could not open library: Could not open library: libSDL2.so: cannot open shared object file: No such file or directory
    at new DynamicLibrary (ext:deno_ffi/00_ffi.js:454:42)
    at Object.dlopen (ext:deno_ffi/00_ffi.js:558:10)
    at https://jsr.io/@divy/sdl2/0.12.0/mod.ts:28:19

The deno people suggested in https://fosstodon.org/@deno_land/113108106611366244 that this looks like a bug in this library, and I should file it here, so here it is.

I'm using NixOS but, I think that solution could may be the same so I don't want to open another request.
I have a nix shell file like below,
{ pkgs ? import <nixpkgs> {} }:    pkgs.mkShell {      buildInputs = [  pkgs.deno        pkgs.SDL2        pkgs.rustc        pkgs.cargo         pkgs.SDL2_image         pkgs.gcc         pkgs.SDL2_ttf         pkgs.mlocate         pkgs.findutils         pkgs.nix-index      ];    }
After shell init here is my libraries about SDL2
[nix-shell:~/projeler/deno/flappybird]$ sudo find / -type d -name SDL2 [sudo] password for interroo:  find: ‘/run/user/1000/gvfs’: Permission denied find: ‘/run/user/1000/doc’: Permission denied /nix/store/jc13yn8zh855il4bkbybpnpisds70mkx-SDL2-2.30.6-dev/include/SDL2 /nix/store/jc13yn8zh855il4bkbybpnpisds70mkx-SDL2-2.30.6-dev/lib/cmake/SDL2 /nix/store/g3dyaid12r0cjq5sqcfjxd3dckbkz63w-nixos/nixos/pkgs/development/libraries/SDL2 /nix/store/lsy6c2f9alj2gkjj36h754kk63x6701l-source/pkgs/development/libraries/SDL2 /nix/store/f9s5ppf6ay05wsviyrn8jb44lbbkb04q-SDL2_sound-2.0.1/include/SDL2 /nix/store/dbp40ny9x8svygk01769g6d12zsj7jq9-nixos/nixos/pkgs/development/libraries/SDL2 /nix/store/vih8vdck628mm1xxnhi1d3rzy68h1yi6-nixos/nixos/pkgs/development/libraries/SDL2 /nix/store/ghg5yhiv547s10rjgiajk60vmavza70w-nixos/nixos/pkgs/development/libraries/SDL2 /nix/store/4yg6mlimzrjcg11jvqv5yb1xdj67c216-SDL2_ttf-2.22.0/include/SDL2 /nix/store/p01c6lmcijvjb3yfnqb8x3hkzxmc4jhz-SDL2_image-2.8.2/include/SDL2 /nix/store/f88l5vi0ms8v52qknpxzdqcs47mc79b0-home-manager-path/include/SDL2 /nix/store/1k4ilbly8y28yja0clq2gm1y0gaji6z9-SDL2_ttf-2.22.0/include/SDL2 /nix/store/yqrq1h81sc6bdz6jlxxipi3qvcld5190-jetbrains-toolbox-<IP_ADDRESS>573-fhs/usr/include/SDL2 /nix/store/9j29lw4g9vxlsd0pkz3bw6vf50v48pp0-jetbrains-toolbox-<IP_ADDRESS>573-fhs/usr/include/SDL2 /nix/store/qxxg4678zm816k1r3i144gn54z2dw3h3-jetbrains-toolbox-<IP_ADDRESS>573-usr-target/include/SDL2 /nix/store/4nrdmbi5gbmlfdsh2mxm74amlk3id3yb-jetbrains-toolbox-<IP_ADDRESS>573-fhs/usr/include/SDL2 /nix/store/xfxshsfh47fbqlmymaxzvprgh03fjp1b-SDL2_image-2.8.2/include/SDL2 /nix/store/zqfqxi9zxids52cglw4qqb4rfmj2b914-jetbrains-toolbox-<IP_ADDRESS>573-usr-target/include/SDL2 /nix/store/6bklv1fayjcy8bzl63782rzsg73hrz6b-jetbrains-toolbox-<IP_ADDRESS>573-usr-target/include/SDL2
And here is sdl2-config output
[nix-shell:~/projeler/deno/flappybird]$ sdl2-config --cflags --libs -I/nix/store/jc13yn8zh855il4bkbybpnpisds70mkx-SDL2-2.30.6-dev/include/SDL2 -I/nix/store/jc13yn8zh855il4bkbybpnpisds70mkx-SDL2-2.30.6-dev/include/SDL2 -I/nix/store/xfxshsfh47fbqlmymaxzvprgh03fjp1b-SDL2_image-2.8.2/include/SDL2 -I/nix/store/4yg6mlimzrjcg11jvqv5yb1xdj67c216-SDL2_ttf-2.22.0/include/SDL2 -I/nix/store/jc13yn8zh855il4bkbybpnpisds70mkx-SDL2-2.30.6-dev/include/SDL2 -I/nix/store/xfxshsfh47fbqlmymaxzvprgh03fjp1b-SDL2_image-2.8.2/include/SDL2 -I/nix/store/4yg6mlimzrjcg11jvqv5yb1xdj67c216-SDL2_ttf-2.22.0/include/SDL2 -D_REENTRANT -L/nix/store/z9mxzhabjab303ffgpg6szc85rmxc3nx-SDL2-2.30.6/lib -Wl,-rpath,/nix/store/z9mxzhabjab303ffgpg6szc85rmxc3nx-SDL2-2.30.6/lib -Wl,--enable-new-dtags -lSDL2
Btw, I couldn't run demos... And here is my error message
[nix-shell:~/projeler/deno/flappybird]$ deno run --allow-env --allow-ffi<EMAIL_ADDRESS>error: Uncaught (in promise) Error: Could not open library: Could not open library: libSDL2.so: cannot open shared object file: No such file or directory const sdl2 = Deno.dlopen(getLibraryPath("SDL2"), {                   ^     at new DynamicLibrary (ext:deno_ffi/00_ffi.js:456:42)     at Object.dlopen (ext:deno_ffi/00_ffi.js:562:10)     at https://jsr.io/@divy/sdl2/0.14.0/mod.ts:48:19
Thanks in advance...

Well... I just rewrite my shell.nix through README today and sharing
{ pkgs ? import <nixpkgs> {} }:
   pkgs.mkShell {
     buildInputs = [
       	pkgs.deno
       	pkgs.SDL2
	pkgs.SDL2_image
	pkgs.SDL2_ttf
       	pkgs.rustc
       	pkgs.cargo
	pkgs.gcc
	pkgs.mlocate
	pkgs.findutils
	pkgs.nix-index
     ];
     shellHook = ''
	mkdir /tmp/denosdl
	export DENO_SDL2_PATH=/tmp/denosdl
	ln -s $(nix eval nixpkgs#SDL2.outPath --raw)/lib/libSDL2.so /tmp/denosdl/
	ln -s $(nix eval nixpkgs#SDL2_ttf.outPath --raw)/lib/libSDL2_ttf.so /tmp/denosdl/
	ln -s $(nix eval nixpkgs#SDL2_image.outPath --raw)/lib/libSDL2_image.so /tmp/denosdl/
     '';
   }

Hope this helps somebody....


zustand/shallow and zustand/middleware are not transpiled to cjs

I'm getting errors because zustand/middleware.js and zustand/shallow.js have non-supported syntax in them.
There is a .cjs.js file for each but then I have to import from 'zustand/middleware.cjs' which feels a bit weird, but it's a successful workaround.
It seems with additional non-main entries like these, they do not have the convenience of specifying main and module in the package.json like the main entry has. So the safest bet would probably be to have their .js file be the lowest common demoninator, commonjs.
I'm not sure these two entries need to be exported as anything but commonjs.

that makes sense, i'll reconfigure rollup

Can confirm that the rollup changes for this were completed in #65 and build outputs work as expected

Great! Thank you for the feedback.


Integrate https://github.com/eastriverlee/LLM.swift

What's the process on this like? I'd be happy to contribute if this isn't getting worked on :)

thanks


NullPointerException on Google Play disable

If Google Play is disable,
java.lang.NullPointerException: Attempt to invoke virtual method 'void com.google.android.gms.maps.model.Marker.setTitle(java.lang.String)' on a null object reference
at com.google.android.apps.location.gps.gnsslogger.MapFragment$1.run(MapFragment.java:160)
So
if (mLastLocationMarkerRaw == null && mLastLocationMarkerDevice == null) {
...
mLastLocationMarkerRaw.setTitle("time: " + formattedDate);
should be
if (mLastLocationMarkerRaw ！= null && mLastLocationMarkerDevice ！= null) {
...
mLastLocationMarkerRaw.setTitle("time: " + formattedDate);

Thanks guanrc. I do not think the changed proposed by you is correct. We want to create the objects new only if they were null and update them only after that.
Regarding the no GMS-Core devices, you can stop the map view from being initiated and that will solve the issue.


Bot doesn't respond in Mattermost 3.5

Bot seems to log in fine, but doesn't seem to recognize message posts. I'm using hubot-matteruser v3.5.0. I added a console.log message to the onMessage event in mattermost-client/src/client.coffee to see if I could figure anything out. Here's what I get when logging in and doing a @hubot ping on 3.4 where everything works fine:
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] INFO Logging in...
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] DEBUG POST /users/login
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] INFO Websocket URL: wss://$HOST:443/api/v3/users/websocket
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] INFO Logged in as user "$BOTNAME" but not connected yet.
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] DEBUG GET /users/initial_load
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] DEBUG Found 2 teams.
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] DEBUG Testing $TEAMNAME == $TEAMNAME
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] DEBUG Found team! $TEAM
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] DEBUG GET /teams/$TEAM/users/0/1000
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] DEBUG GET /teams/$TEAM/channels/
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] INFO Connecting...
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] ERROR Failed to load profiles from server.
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] INFO Error: [object Object]
[Thu Nov 17 2016 16:50:16 GMT-0700 (MST)] INFO Connected to Mattermost.
[Thu Nov 17 2016 16:50:17 GMT-0700 (MST)] INFO Starting pinger...
{ team_id: '',
  channel_id: '',
  user_id: '$USERID',
  event: 'status_change',
  data: { status: 'online' } }
{ team_id: '',
  channel_id: '',
  user_id: '$USERID',
  event: 'hello',
  data: { server_version: '<IP_ADDRESS>.4.0.5f09928bad05fdc89cd815300a0e12c0' } }
[Thu Nov 17 2016 16:50:17 GMT-0700 (MST)] DEBUG Received unhandled message type: hello
[Thu Nov 17 2016 16:50:17 GMT-0700 (MST)] DEBUG { team_id: '',
  channel_id: '',
  user_id: '$USERID',
  event: 'hello',
  data: { server_version: '<IP_ADDRESS>.4.0.5f09928bad05fdc89cd815300a0e12c0' } }
[Thu Nov 17 2016 16:50:18 GMT-0700 (MST)] INFO hubot-redis-brain: Using default redis on localhost:6379
{ team_id: '',
  channel_id: '$CHANNELID',
  user_id: '$USERID',
  event: 'typing',
  data: { parent_id: '' } }
{ team_id: '$TEAM',
  channel_id: '$CHANNELID',
  user_id: '$USERID',
  event: 'posted',
  data:
   { channel_display_name: '$CHANNELNAME',
     channel_type: 'O',
     mentions: '["$USERID"]',
     post: '{"id":"$POSTID","create_at":1479426624236,"update_at":1479426624236,"delete_at":0,"user_id":"$USERID","channel_id":"$CHANNELID","root_id":"","parent_id":"","original_id":"","message":"@$BOTNAME ping","type":"","props":{},"hashtags":"","filenames":[],"pending_post_id":"$USERID:1479426624226"}',
     sender_name: 'wernicke.lanl',
     team_id: '$TEAM' } }
[Thu Nov 17 2016 16:50:24 GMT-0700 (MST)] DEBUG POST /teams/$TEAM/channels/$CHANNELID/posts/create
[Thu Nov 17 2016 16:50:24 GMT-0700 (MST)] DEBUG Posted message.
{ team_id: '$TEAM',
  channel_id: '$CHANNELID',
  user_id: '$USERID',
  event: 'posted',
  data:
   { channel_display_name: '$CHANNELNAME',
     channel_type: 'O',
     post: '{"id":"$POSTID","create_at":1479426624270,"update_at":1479426624270,"delete_at":0,"user_id":"$USERID","channel_id":"$CHANNELID","root_id":"","parent_id":"","original_id":"","message":"PONG","type":"","props":{},"hashtags":"","filenames":[],"pending_post_id":""}',
     sender_name: '$BOTNAME',
     team_id: '$TEAM' } }
[Thu Nov 17 2016 16:50:47 GMT-0700 (MST)] INFO ping
{ status: 'OK',
  seq_reply: 1,
  data:
   { node_id: '',
     server_time:<PHONE_NUMBER>486,
     text: 'pong',
     version: '3.4.0' } }
[Thu Nov 17 2016 16:50:47 GMT-0700 (MST)] INFO ACK ping

Here's what I get when doing a @hubot ping on 3.5:
[Thu Nov 17 2016 16:51:29 GMT-0700 (MST)] INFO Logging in...
[Thu Nov 17 2016 16:51:29 GMT-0700 (MST)] DEBUG POST /users/login
[Thu Nov 17 2016 16:51:29 GMT-0700 (MST)] INFO Websocket URL: wss://$HOST:443/api/v3/users/websocket
[Thu Nov 17 2016 16:51:29 GMT-0700 (MST)] INFO Logged in as user "$BOTNAME" but not connected yet.
[Thu Nov 17 2016 16:51:29 GMT-0700 (MST)] DEBUG GET /users/initial_load
[Thu Nov 17 2016 16:51:30 GMT-0700 (MST)] DEBUG Found 2 teams.
[Thu Nov 17 2016 16:51:30 GMT-0700 (MST)] DEBUG Testing $TEAMNAME == $TEAMNAME
[Thu Nov 17 2016 16:51:30 GMT-0700 (MST)] DEBUG Found team! $TEAM
[Thu Nov 17 2016 16:51:30 GMT-0700 (MST)] DEBUG GET /teams/$TEAM/users/0/1000
[Thu Nov 17 2016 16:51:30 GMT-0700 (MST)] DEBUG GET /teams/$TEAM/channels/
[Thu Nov 17 2016 16:51:30 GMT-0700 (MST)] INFO Connecting...
[Thu Nov 17 2016 16:51:30 GMT-0700 (MST)] INFO Connected to Mattermost.
[Thu Nov 17 2016 16:51:30 GMT-0700 (MST)] INFO Starting pinger...
{ event: 'hello',
  data: { server_version: '<IP_ADDRESS>.5.0.977864ec83b61ac2f656306d140e5909' },
  broadcast:
   { omit_users: null,
     user_id: '$USERID',
     channel_id: '',
     team_id: '' } }
[Thu Nov 17 2016 16:51:30 GMT-0700 (MST)] DEBUG Received unhandled message type: hello
[Thu Nov 17 2016 16:51:30 GMT-0700 (MST)] DEBUG { event: 'hello',
  data: { server_version: '<IP_ADDRESS>.5.0.977864ec83b61ac2f656306d140e5909' },
  broadcast:
   { omit_users: null,
     user_id: '$USERID',
     channel_id: '',
     team_id: '' } }
{ event: 'status_change',
  data: { status: 'online', user_id: '$USERID' },
  broadcast:
   { omit_users: null,
     user_id: '$USERID',
     channel_id: '',
     team_id: '' } }
[Thu Nov 17 2016 16:51:30 GMT-0700 (MST)] DEBUG Found 223 profiles.
[Thu Nov 17 2016 16:51:31 GMT-0700 (MST)] INFO hubot-redis-brain: Using default redis on localhost:6379
[Thu Nov 17 2016 16:52:00 GMT-0700 (MST)] INFO ping
{ status: 'OK',
  seq_reply: 1,
  data:
   { node_id: '',
     server_time:<PHONE_NUMBER>670,
     text: 'pong',
     version: '3.5.0' } }
[Thu Nov 17 2016 16:52:00 GMT-0700 (MST)] INFO ACK ping

@jwernicke Make sure you update your bot to use version 3.5.0 of hubot-matteruser i.e. you need to modify your package.json to point to the latest version. Unfortunately Mattermost 3.5.0 introduced breaking API changes.

Turns out problem was with server configuration routing to the wrong server. Everything is working fine now. :blush:


MSFT: 46989616 - Use WIL's TraceLogging helpers for tracing

Why is this change being made?
We want to improve tracing to get better diagnostics for future bug investigations.
What changed?

Update packages
Update to C++ 20
Switch to using WIL's TraceLogging helpers for tracing now that they're public
Add a custom trace macro that wraps wil::TraceLoggingProvider::TraceLoggingInfo() to provide printf-style logging with a prefix that includes file, line, function, and "this" (if it exists)

How was the change tested?
I validated Ogg playback in:

MediaPlayerCPP
MediaPlayerCS
Media Player with WME

I verified that trace logging and FFmpegInteropLogging work as expected.

my comments are all small nits. feel free to resolve won't fix.


Use repl.send-signal to interrupt stdio REPLs

This is a minor nit but I noticed that the stdio-based clients use two equivalent implementations of the interrupt function. This PR makes the implementation the same for these clients:

Hy
Julia
Python
Racket

by using the:

send-signal function defined in remote/stdio.fnl
vim.loop.constants.SIGINT constant instead of the number 2
comment-prefix of the client's language

Hopefully, this provides consistency and emphasizes the use of the base client functionality of remote/stdio.fnl.
I didn't include the Scheme client because there is https://github.com/Olical/conjure/pull/498 which adds the ability to interrupt the REPL.

Okay, I think that's all of your changes merged to develop fairly cleanly. Please let me know if something seems off! I'm going through myself too.

All seems in order. Thanks!


[BACKLOG-12856] Create a first-pass plugin for the execution engine

Plumbing OSGi plugin for the execution engine.

@mkambol Could you review please?


not working with IPv6 address

Failed with:
diagnose couchbase://2620:100:10:2024:10:20:30:40/default -u
See more at https://forums.couchbase.com/t/couchbase-5-5-with-ipv6-protocol-family-unavailable/17756/9
 ./sdk-doctor diagnose couchbase://2620:100:10
:2024:10:20:30:40/default
Note: Diagnostics can only provide accurate results when your cluster
 is in a stable state.  Active rebalancing and other cluster configuration
 changes can cause the output of the doctor to be inconsistent or in the
 worst cases, completely incorrect.

18:13:05.443 INFO ▶ Parsing connection string `couchbase://2620:100:10:2024:10:20:30:40/default`
18:13:05.443 INFO ▶ Connection string identifies the following CCCP endpoints:
18:13:05.443 INFO ▶   1. 2620:100
18:13:05.443 INFO ▶   2. 10:2024
18:13:05.443 INFO ▶   3. 10:20
18:13:05.443 INFO ▶   4. 30:40
18:13:05.443 INFO ▶ Connection string identifies the following HTTP endpoints:
18:13:05.443 INFO ▶ Connection string specifies bucket `default`
18:13:05.443 INFO ▶ Performing DNS lookup for host `2620`
18:13:05.443 INFO ▶ Bootstrap host `2620` refers to a server with the address `<IP_ADDRESS>`
18:13:05.443 INFO ▶ Performing DNS lookup for host `10`
18:13:05.443 INFO ▶ Bootstrap host `10` refers to a server with the address `<IP_ADDRESS>`
18:13:05.443 INFO ▶ Performing DNS lookup for host `10`
18:13:05.443 INFO ▶ Bootstrap host `10` refers to a server with the address `<IP_ADDRESS>`
18:13:05.443 INFO ▶ Performing DNS lookup for host `30`
18:13:05.443 INFO ▶ Bootstrap host `30` refers to a server with the address `<IP_ADDRESS>`
18:13:05.443 INFO ▶ Attempting to connect to cluster via CCCP
18:13:05.443 INFO ▶ Attempting to fetch config via cccp from `2620:100`
18:13:05.444 ERRO ▶ Failed to fetch configuration via cccp from `2620:100` (error: dial tcp <IP_ADDRESS>:100: connect: no route to host)
18:13:05.444 INFO ▶ Attempting to fetch config via cccp from `10:2024`
18:13:05.444 ERRO ▶ Failed to fetch configuration via cccp from `10:2024` (error: dial tcp <IP_ADDRESS>:2024: connect: no route to host)
18:13:05.444 INFO ▶ Attempting to fetch config via cccp from `10:20`
18:13:05.444 ERRO ▶ Failed to fetch configuration via cccp from `10:20` (error: dial tcp <IP_ADDRESS>:20: connect: no route to host)
18:13:05.444 INFO ▶ Attempting to fetch config via cccp from `30:40`
18:13:05.444 ERRO ▶ Failed to fetch configuration via cccp from `30:40` (error: dial tcp <IP_ADDRESS>:40: connect: no route to host)
18:13:05.444 INFO ▶ Not attempting HTTP (Terse), as the connection string does not support it
18:13:05.444 INFO ▶ Not attempting HTTP (Full), as the connection string does not support it
18:13:05.444 ERRO ▶ All endpoints specified by your connection string were unreachable, further cluster diagnostics are not possible
18:13:05.444 INFO ▶ Diagnostics completed

Summary:
[ERRO] Failed to fetch configuration via cccp from `2620:100` (error: dial tcp <IP_ADDRESS>:100: connect: no route to host)
[ERRO] Failed to fetch configuration via cccp from `10:2024` (error: dial tcp <IP_ADDRESS>:2024: connect: no route to host)
[ERRO] Failed to fetch configuration via cccp from `10:20` (error: dial tcp <IP_ADDRESS>:20: connect: no route to host)
[ERRO] Failed to fetch configuration via cccp from `30:40` (error: dial tcp <IP_ADDRESS>:40: connect: no route to host)
[ERRO] All endpoints specified by your connection string were unreachable, further cluster diagnostics are not possible

Should be fixed by #20


docs(queryCache): fix subscribe callback argument: event instead of query

queryCache.subscribe callback documentation does not reflect the actual callback implementation:
Current doc:
const callback = query => {
  console.log(query)

It should be:
const callback = event => {
  console.log(event.type, event.query)
}

:tada: This PR is included in version 3.32.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Copy value please specify the context.

https://github.com/Microsoft/debug-adapter-protocol/blob/gh-pages/debugAdapterProtocol.json#L1964-L1973
The copy value is implemented using EvaluateRequest. But now context is null. If VSCode can provide an enum for the copy value, the DA will be able to optimize it.

I've created protocol change request to address this issue.

@actboy168 looking at the code Copy Value shuold pass the variables context. Is that not enough for what you are looking for?
@weinand If this is not enough we should look into this so debug authors could distungish between copy value and other evaluations potentially needed for https://github.com/microsoft/vscode/issues/73845

Thank you, Copy Value has its own context, but still a few problems.

In watch view, click Copy Value does not send EvaluateRequest.
In watch view, variables without variableReference do not display the UI of Copy Value. In the variables view, it just depends on whether there is an evaluateName.I think the variable view is the correct behavior.
The variables context is not documented.

We can fix it, so it is consistent. Currently it does not send EvaluateRequest because the watch is already evaluated
This is correct behavior, watch variables require the evaluateName property, without it we do not know what we need to evaluate. We will not change this
We can document it

For the second point, I mean that currently in the watch view, only the variable without variableReference will show Copy Value.

@actboy168 that is probably because the other variable do not have the evaluateName. Please provide the evaluateName and the Copy will be shown

Each item is provided with evaluateName, which is the json of the DA response.
{
    "command":"variables",
    "request_seq":20,
    "type":"response",
    "seq":27,
    "body":{
        "variables":[
            {
                "namedVariables":64,
                "evaluateName":"_G._G",
                "name":"_G",
                "type":"table",
                "variablesReference":19,
                "value":"{_G=...,_VERSION='Lua 5.4',arg=...,...}",
                "indexedVariables":1
            },
            {
                "evaluateName":"_G._VERSION",
                "name":"_VERSION",
                "type":"string",
                "variablesReference":0,
                "value":"'Lua 5.4'"
            },
            {
                "namedVariables":4,
                "evaluateName":"_G.arg",
                "name":"arg",
                "type":"table",
                "variablesReference":20,
                "value":"{'4711',-1='local path=[[c:/...',-2='-e',...}",
                "indexedVariables":2
            },
            {
                "evaluateName":"_G.assert",
                "name":"assert",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.collectgarbage",
                "name":"collectgarbage",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "namedVariables":8,
                "evaluateName":"_G.coroutine",
                "name":"coroutine",
                "type":"table",
                "variablesReference":23,
                "value":"{close=func,create=func,isyieldable=func,...}",
                "indexedVariables":1
            },
            {
                "namedVariables":32,
                "evaluateName":"_G.debug",
                "name":"debug",
                "type":"table",
                "variablesReference":11,
                "value":"{debug=func,gethook=func,getinfo=func,...}",
                "indexedVariables":1
            },
            {
                "evaluateName":"_G.dofile",
                "name":"dofile",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.error",
                "name":"error",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.getmetatable",
                "name":"getmetatable",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "namedVariables":16,
                "evaluateName":"_G.io",
                "name":"io",
                "type":"table",
                "variablesReference":12,
                "value":"{close=func,flush=func,input=func,...}",
                "indexedVariables":1
            },
            {
                "evaluateName":"_G.ipairs",
                "name":"ipairs",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.load",
                "name":"load",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.loadfile",
                "name":"loadfile",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "namedVariables":32,
                "evaluateName":"_G.math",
                "name":"math",
                "type":"table",
                "variablesReference":21,
                "value":"{abs=func,acos=func,asin=func,atan=func,...}",
                "indexedVariables":1
            },
            {
                "evaluateName":"_G.next",
                "name":"next",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "namedVariables":16,
                "evaluateName":"_G.os",
                "name":"os",
                "type":"table",
                "variablesReference":17,
                "value":"{clock=func,date=func,difftime=func,...}",
                "indexedVariables":1
            },
            {
                "namedVariables":8,
                "evaluateName":"_G.package",
                "name":"package",
                "type":"table",
                "variablesReference":14,
                "value":"{config='\\\n;\n?\n!\n-\n',cpath='D:\work\vscode-l...',...}",
                "indexedVariables":1
            },
            {
                "evaluateName":"_G.pairs",
                "name":"pairs",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.pcall",
                "name":"pcall",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.print",
                "name":"print",
                "type":"c function",
                "variablesReference":18,
                "value":"C function"
            },
            {
                "evaluateName":"_G.rawequal",
                "name":"rawequal",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.rawget",
                "name":"rawget",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.rawlen",
                "name":"rawlen",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.rawset",
                "name":"rawset",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.require",
                "name":"require",
                "type":"c function",
                "variablesReference":22,
                "value":"C function"
            },
            {
                "evaluateName":"_G.select",
                "name":"select",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.setmetatable",
                "name":"setmetatable",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "namedVariables":32,
                "evaluateName":"_G.string",
                "name":"string",
                "type":"table",
                "variablesReference":15,
                "value":"{byte=func,char=func,dump=func,find=func,...}",
                "indexedVariables":1
            },
            {
                "namedVariables":8,
                "evaluateName":"_G.table",
                "name":"table",
                "type":"table",
                "variablesReference":16,
                "value":"{concat=func,insert=func,move=func,...}",
                "indexedVariables":1
            },
            {
                "evaluateName":"_G.tonumber",
                "name":"tonumber",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.tostring",
                "name":"tostring",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.type",
                "name":"type",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "namedVariables":8,
                "evaluateName":"_G.utf8",
                "name":"utf8",
                "type":"table",
                "variablesReference":13,
                "value":"{char=func,charpattern='[-�-�][�-�]*',...}",
                "indexedVariables":1
            },
            {
                "evaluateName":"_G.warn",
                "name":"warn",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            },
            {
                "evaluateName":"_G.xpcall",
                "name":"xpcall",
                "type":"c function",
                "variablesReference":0,
                "value":"C function"
            }
        ]
    },
    "success":true
}

In addition, the value of the root node comes from EvaluateResponse, not VariablesResponse. And EvaluateResponse cannot provide evaluateName, it also does not have Copy Value. Whether the root node has Copy Value also depends on variableReference.

We have changed the wath view to be consisntent now wer will always have the copy value, you can try it with vscode insiders
@weinand will push a change to the protocol such that we can set a different contenxt when doing a copy value.

I've created another AP feature request to document the variables context value.

@isidorn I've added a new value clipboard to the context enum passed to the evaluate request.
Here is the TypeScript commit with the changes.

VSCode is now respecting the capabilities.supportsClipboardContext. If this is set to true the context passed will be clipboard

In the WATCH view, Copy Value did not send an EvaluateRequest. It appears to be the result of using Add to Watch.

@actboy168 correct that is still how we behave. We can change this though, @weinand thoughts?

@isidorn Since "Copy to clipboard" must result in the same value in REPL, VARIABLES and WATCHES view we should use the same EvaluateRequest in all cases.

@weinand makes sense.
I have pushed a commit which tackles this behavior. Thank you

@actboy168 is this now behaving better for you. Asking because we would like to add a verified label here if possible.

Yes, it works fine now.

Great, thanks for letting us know. Adding verified label.


Sending create_historical_record() to celery tasks

Problem Statement
To minimize performance concerns, I want to send create_historical_record() as a celery task.
I was reading up on this thread, which suggests that we can override the create_historical_record and create a custom method that is sent to celery. How would we go about overriding this method?
Describe the solution you'd like
A relatively straightforward solution to overriding the create_historical_record so we can send it as a job, instead of writing to the db at runtime
Describe alternatives you've considered
I've read about monkey patching, which would be instantiating the customized create_historical_record() at runtime and overriding the original method.

I have no experience with Celery, but simply overriding HistoricalRecords.create_historical_record() can be done using standard class extension + method overriding:
from django.db import models
from simple_history.models import HistoricalRecords

class HistoricalRecordsWithCelery(HistoricalRecords):
    def create_historical_record(self, instance, history_type, using=None):
        # custom code (invoking Celery?)

class YourHistoryTrackedModel(models.Model):
    ...

    history = HistoricalRecordsWithCelery()

Does that work for you? 🙂

@ddabble thank you for the speedy response! My project is currently on Python 3.10, so I'm not sure if @override will work for me. Is that just an annotation? I also tested out the class extension suggestion, but I'm noticing two issues:

I don't want to make HistoricalRecordsWithCelery a new model, which would happen with this approach
I have a few attributes I'm passing into the HistoricalRecords class (ex: use_base_model_db=False), which doesn't seem to work if I'm using the class as a parent class. I'm getting a TypeError: 'HistoricalRecords' object is not callable err

I tested out something similar to this solution in my apps.py, which worked for me when testing:
HistoricalRecords.create_historical_record = MethodType(self.create_historical_record, HistoricalRecords)
This overrides the create_historical_record() method at runtime

Yeah, @override is just an annotation that simply helps your IDE/editor analyze your code and give feedback on it; it has no effect when actually running the code 🙂

I don't want to make HistoricalRecordsWithCelery a new model, which would happen with this approach

Could you help me understand how that would happen? 🤔 Because I would instead describe HistoricalRecords (and, by extension, HistoricalRecordsWithCelery) as a manager, since you can use it pretty much the same way as you would use the default manager objects. E.g. both YourModel.objects.filter(...) and YourModel.history.filter(...) (where history is an instance of HistoricalRecords) work in the way you would expect 🙂

I have a few attributes I'm passing into the HistoricalRecords class (ex: use_base_model_db=False), which doesn't seem to work if I'm using the class as a parent class. I'm getting a TypeError: 'HistoricalRecords' object is not callable err

I'm not sure I understand how you're getting that error; could you provide a minimally reproducible example?

HistoricalRecords.create_historical_record = MethodType(self.create_historical_record, HistoricalRecords)
This overrides the create_historical_record() method at runtime

Sure, that could also work :) Though there are reasons monkey-patching is generally regarded as a last resort, some of which include that it might produce unexpected side effects (to developers who are not aware that it was monkey-patched) and hard-to-trace errors, and that it's often much less flexible compared to "proper" solutions - which I think would be class inheritance, in this case.

yes for sure! Here's what I tried doing, which resulted in TypeError: 'HistoricalRecords' object is not callable when running ./manage.py makemigrations:
class ExtraHistoricalClaimFieldsModel(models.Model):
    backend_path = models.CharField(
        max_length=200, blank=True, null=True, default=None
    )

    class Meta:
        abstract = True

class HistoricalBaseModel(HistoricalRecords(use_base_model_db=False, history_user_id_field=models.IntegerField(null=True), bases=[ExtraHistoricalClaimFieldsModel, ])):
    def create_historical_record(self, instance, history_type, using=None):
        # call create_historical_record.delay()
        return "saved"

class YourHistoryTrackedModel(models.Model):
    ...

    history = HistoricalBaseModel()

But I think your right, monkey patching should be used as a last resort since it would definitely be harder to debug

Ah, I think I see what you're trying to do 😅 The class list inside the parentheses after a class name (i.e. class ClassName(class list)) should only contain references to other classes (e.g. HistoricalRecords or models.Model), not constructor calls (e.g. HistoricalRecords(args...)). And the arguments that you want to pass to HistoricalRecords should be passed in the same place you would normally pass them, but with HistoricalRecords replaced by the child class. So I think doing this should fix the error:
class ExtraHistoricalClaimFieldsModel(models.Model):
    backend_path = models.CharField(
        max_length=200, blank=True, null=True, default=None
    )

    class Meta:
        abstract = True

class CustomHistoricalRecords(HistoricalRecords):
    def create_historical_record(self, instance, history_type, using=None):
        # call create_historical_record.delay()
        return "saved"

class YourHistoryTrackedModel(models.Model):
    ...

    history = CustomHistoricalRecords(use_base_model_db=False, history_user_id_field=models.IntegerField(null=True), bases=[ExtraHistoricalClaimFieldsModel, ])

ahhh yay that worked! 🥳 makes sense that I should be putting the constructors in the constructor method instead of where the class is being inherited. thanks for the help :)

Alright nice, no problem :)
Closing, now that the issue seems resolved.


corrected _getSharedMediaTypes to enable methods like retrieveStudy w…

…hich check for commonMediaType === MEDIATYPES.DICOM
Problem description:
Some functions like "retrieveStudy(options)" check for commonMediaType === MEDIATYPES.DICOM and throw "Media type ${commonMediaType} is not supported for retrieval of study." when the condition is not met.
Current implementation of _getSharedMediaTypes returns "application/" for "application/dicom" which will not meet the condition above.
With the modification that I have introduced, "application/dicom" will stay intact.
Please note: There was something similar in previous versions of this code.

@Christian-e-S is this still valid?  I'm not familiar with the issue myself.

I pass below param to retrieveStudy(options)
{
studyInstanceUID,
mediaTypes: [{
transferSyntaxUID: '1.2.840.10<IP_ADDRESS>.90',
mediaType: 'image/jp2'
}
],
}
I got an error:
Media type image/ is not supported for retrieval of study.

Okay, this sounds reasonable, but I'm wary to change this code since it's very hard to test for any side effects.
Can you create an issue and reference it here that describes the scenario in which this happens?  I.e. what types of data is involved (SM? US? MR?) and what servers?


Fixing typo in docs for relation table models

While trying to create a relation table with Prisma, I found what I believe to be a typo in the docs.
We are referring to the actual models and not the relation model in the example, this PR fixes that.

Good catch, thanks for raising a PR! 💚


Error: Device did not appear with the intermediate firmware - Bakibo TP22Y

I am getting following error:
Device did not appear with the intermediate firmware
The Device is switching from EZ config mode automatically to "normal" mode (static blue light).
Bakibo TP22Y
Version:
WI-FI Module: 1.1.4
MCU-Module 1.1.4
According to 2 different sources it should work with tuya-convert.
I have tried it on the latest buster and the last "latest" stretch version.
They are fresh Installs.
I tried it several times.
logs have been added and I also added a file that shows what i am getting:
Commands.txt
smarthack-web.log
smarthack-wifi.log
smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log

Unfortunately you have a patched firmware using a new PSK, see #483. You will not be able to use tuya-convert on these devices at this time.


Developement section with hello-world tutorial

Awesome, even I've been looking for something like this!


Remove task bar from non query editor languages

This PR fixes https://github.com/microsoft/azuredatastudio/issues/16791

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

2 of 9 (22.22%)  changed or added relevant lines in 3 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.003%) to 41.68%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/sql/workbench/common/editor/query/queryEditorInput.ts
1
2
50.0%

src/sql/workbench/contrib/query/browser/queryEditor.ts
0
6
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/sql/workbench/contrib/query/browser/queryEditor.ts
1
4.29%

Totals

Change from base Build<PHONE_NUMBER>:
-0.003%

Covered Lines:
26571

Relevant Lines:
57769

💛  - Coveralls

I am afraid hiding the task bar is not enough, we also need to remove the results/messages panel, basically we need to treat it as a normal text editor. but we are still using the QueryEditor as the editor type which might cause other problems, also, if we support SQL->other language mode change, we should also properly support the other language -> SQL mode change, I gave it a try and it is not working, I opened an issue for it: https://github.com/microsoft/azuredatastudio/issues/17135
we are also treating the saved and untiled files differently, we don't allow changing language mode for untitled query editor. while you are working on this area, it would be nice if you can figure out whether it is possible to implement the ideal experience: user can switch language mode freely (saved or new) and when sql mode is selected, they user should be able to connect to a server and execute the query.

@alanrenmsft I had already opened an issue for it when I was working on this, but this issue is even in main right now, so I decided to treat it as a separate issue

I wonder if we should just block switching the language mode for SQL editors again?  I don't remember any design discussion to change this behavior and it seems to have introduced the problems that the block was intended to prevent.

+1 - I don't know of anything useful language modes bring to the query editor and given the problems we've seen it seems easiest to just hide that.

currently, we allow user to change language mode to SQL and the QE toolbar will show up, it will be weird if we only support other language-> sql, not sql-> other language

@abist are you still doing anything with this PR?  if not, could you please close it to clean-up the stale PR list?


[WIP] Fix project bugs

This pr addresses
Issue rancherio/rancher#607
Issue rancherio/rancher#606
Issue rancherio/rancher#605
Issue rancherio/rancher#595
Add integration test to verify rancherio/rancher#596 works in the api.

Note: https://github.com/rancherio/ui/pull/146 needs to be merged to coincide with this

LGTM

LGTM if the changes I pointed out were intentional.  Otherwise, I don't mind tackling the minor things later.  I don't want to block people.


Facebook hashtag link not working iOS

Seems that the scheme has changed to: fb://hashtag/%s?name=%s&id=%s according to this stackoverflow thread.

Sorry it took me so long to get to this. I agree that the current link isn't working, however, I just tried the new scheme you provided and that didn't seem to work either. Maybe I'm doing something wrong. Have you tested out the new scheme?

Yeah I can't get it to work either. I'm having trouble finding any documentation on this.

Same here. None of it is officially supported so it's not surprising that there's little info. When I have some time, I might go through some of the other options (fb://search ?) to see if I can get something to work but I'm not optimistic.

Yeah, makes sense. Thanks anyways man.


Add a Custom Resource details view

Current situation
We list the custom resources for each definition but when clicking on one of them, the YAML viewer is used, instead of a dedicated view, which would allow the user to edit/remove the resource, besides viewing it in a simpler way.
Impact
Users cannot remove/edit custom resources.
Ideal future situation
There is a custom resource details view which shows the custom resource objects' details, showing an edit and remove buttons.

This is done now.


Commission rate change indicators

Purpose
Add commission rate change indicators.
https://github.com/Concordium/concordium-scan/assets/132270889/30314377-2525-42d3-a3b7-77e321dac669
https://concordium.atlassian.net/browse/CBW-1485
https://concordium.atlassian.net/browse/CBW-1484
Changes

Add commission rate change indicators to overview and details page
Fix two wrong usage of “Baker"

Checklist

[x] My code follows the style of this project.
[ ] The code compiles without warnings.
[x] I have performed a self-review of the changes.
[x] I have documented my code, in particular the intent of the
hard-to-understand areas.

Only one issue I found, when commission is 0%:

And when I change commission to 0%, the indicator/changes doesn't appear.

And when I change commission to 0%, the indicator/changes doesn't appear.

Had wrong condition check which captured 0. Replaced with check on undefined and null and validates it correctly renders 0 and the indicator.


Question about document Repository.free()

After cloned a Repository i would to close folder and file use.
Can I do that with: https://www.nodegit.org/api/repository/#free
Why I want to do that ?
I made a Software with plugin support, so I can download a Plugin and load it in run time ( I use NodeGit to clone a plugin)
When a user logout I would like to delete all plugins, so on Linux and MacOS it work fine, but on Windows 2 file continues to be used by NodeGit .pack and .idk located in .git/objects/pack
Can you help me 😄 ?

Have you ever managed to figure this out?
I'm wondering if it's okay to have two Repository objects pointing to the same folder at the same time. And if it's not then how do I make sure that a Repository is free'd as soon as I'm done using it?

I'm experiencing same issue here. Seems like cleanup should be done based on js context - but even trying to manually run global.gc() ends up with EPERM for .idx at windows.

Try using NodeGit.Repository.prototype.cleanup when you're done with a repository object.


SNOW-900602: Cannot put "folder/*.py" to a stage because it's not a valid Path

Python version
Python 3.8.12
Platform
macOS-13.5-arm64-arm-64bit
What happened
I should be able to put folder/*.py to a stage, and have it only upload all the .py files from that folder to a stage.
snow stage put "shared_modules/*.py" snow://streamlit/streamlit.sis_apps.test_app_recursive/default_checkout/shared_modules

This should be perfectly valid https://docs.snowflake.com/en/sql-reference/sql/put#examples, but it fails because Typer is checking to see that the path is valid.
If you put exists=False it works fine, and uploads all of the .py files in that folder to the stage. If you put an invalid folder, you still get a File doesn't exist message, just from SQL rather than Typer.
Console output
╭─ Error ───────────────────────────────────────────────────────────────────────────────────────────╮
│ Invalid value for 'PATH': Path 'shared_modules/*.py' does not exist.                              │
╰───────────────────────────────────────────────────────────────────────────────────────────────────╯

### How to reproduce

Try to `snow put` a path with `*` in it

We have a discussion in the linked PR but I'd like to write here that IMO it should be considered as a new feature, not a bug. If I'm wrong we should probably state what exactly was working wrong before (other way than documented).
I'll try to provide as much support as possible in the PR but if the changes start require too much work from us, then they will probably have to wait a bit (I mean mainly Windows tests case mentioned in the discussion in the PR).


textDocument/signatureHelp received after LSP exit

With lsp_signature enabled with clangd, I frequently get these error messages printed on the console:
RPC[Error] code_name = UnknownErrorCode, message = “Failed to parse includes”

After some investigations it seems to be related to LSP existing before the signature query reply is sent back. Sample steps:

Open a file with LSP is enabled and wait for parsing to start
Exit the editor
Some RPC[Error] messages are printed on the console. From the lsp.log, these seems to be received (or sent?) after the LSP has exited.

For example in the log below, you can see LSP has finished then next line the RPC error is received and printed on stderr
[ERROR][2023-02-20 20:19:36] .../vim/lsp/rpc.lua:733	"rpc"	"clangd"	"stderr"	'V[20:19:36.934] <<< {"jsonrpc":"2.0","method":"exit"}\n\nI[20:19:36.934] <-- exit\nI[20:19:36.934] LSP finished, exiting with status 0\n'
[ERROR][2023-02-20 20:19:36] .../vim/lsp/rpc.lua:733	"rpc"	"clangd"	"stderr"	'I[20:19:36.934] --> reply:textDocument/signatureHelp(4) 3165 ms, error: Failed to parse includes\nV[20:19:36.934] >>> {"error":{"code":-32001,"message":"Failed to parse includes"},"id":4,"jsonrpc":"2.0"}\n\n'
[DEBUG][2023-02-20 20:19:36] .../vim/lsp/rpc.lua:388	"rpc.receive"	{  error = {    code = -32001,    message = "Failed to parse includes"  },  id = 4,  jsonrpc = "2.0"}
[ERROR][2023-02-20 20:19:36] .../vim/lsp/rpc.lua:733	"rpc"	"clangd"	"stderr"	"V[20:19:36.936] ASTWorker rebuilding evicted AST to run DocumentSymbols: <--redacted path to file--> version 0\n"

This is a minor issue as the message are only printed on exit but it's quite annoying.  Anyway  to supress?

btw I don't seem to see the same issue with other signature help plugins such as
cmp-nvim-lsp-signature-help. Is this related to the "async" signature requests this plugin is design to do? I.e. LSP is stopped while there are outstanding queries?

Do you mean when you quit nvim you saw RPC[Error] code_name = UnknownErrorCode, message = “Failed to parse includes” ?

Do you mean when you quit nvim you saw RPC[Error] code_name = UnknownErrorCode, message = “Failed to parse includes” ?

Yup. It's not consistent but for larger files I see multiple lines of these. Does not happen if I waited long enough after opening a file; probably after all queries are made?

Ok, I think it is related to the async request I sent. But I have not seen the same issue so far. Might be also because the clangd is slow or your project is large.
How you exit your nvim? Do you have a keybind or you do :wq from cmdline?

Yea the project is plenty large. It takes 10 seconds to index from scratch
and a few more for diagnostics to be loaded in plugins like Trouble.
I have only tried  :q , not from insert, was just inspecting the files. If
I stay in the file for a while the chance of seeing these are less.
On Mon, Feb 20, 2023, 11:07 PM rayx @.***> wrote:

Ok, I think it is related to the async request I sent. But I have not seen
the same issue so far. Might be also because the clangd is slow or your
project is large.
How you exit your nvim? Do you have a keybind or you do :wq from cmdline?

—
Reply to this email directly, view it on GitHub
https://github.com/ray-x/lsp_signature.nvim/issues/258#issuecomment-1437955832,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AF2RAXA6DQLYTLP3HUSGAO3WYRSRVANCNFSM6AAAAAAVCSOFCE
.
You are receiving this because you authored the thread.Message ID:
@.***>


cannot read property theme of undefined

Hi I'm trying to use the withDocs and withReadme But for some reasons it's given be this error.

I'm using the following version of "storybook-readme": "^5.0.8",
Here is my sample code
storiesOf('Avatar', module)
  .addDecorator(withKnobs)
  .addDecorator(withDocs(AvatarDocs))
  .addDecorator(withReadme(AvatarReadme))
  .add('Avatar Usage',() => (
    <AvatarStory
      img={text('img', 'https://greatindiantours.com/wp-content/themes/travel-log/images/dummy-user.jpg')}
      height={number('height', 60)}
      width={number('width', 60)}
      circle={boolean('circle', false)}
      altText={text('altText', 'User Icon')}
    />
  ))

As soon as I add .addDecorator(withDocs(AvatarDocs)) and
 .addDecorator(withReadme(AvatarReadme)) It gives me above error.
Am I missing something?

This is happening for me too.  Seems related to upgrading storybook from 5 to 6 for me

Solution:  https://github.com/tuchk4/storybook-readme/issues/221


stb framework

it may be interesting for you to take a look at this project - https://github.com/DarkPark/stb
and the demo - https://www.npmjs.org/package/stb-demo

Ok, i will submit my questions in your repository

@DarkPark , broken link

thanks
correct link - https://github.com/DarkPark/stb-demo


Implement PresenceEvent and EphemeralEvent

Add derive for PresenceEventContent and create struct AnyPreseenceEventContent since there is only one content type.
Add derive for EphemeralEvent and create enum AnyEphemeralEventContent, convert receipt, and typing to use derive(EphemeralEventContent) over ruma_api!.

Do you want PresenceEvent in it's own file?

It should be part of the presence module, like it is now.


Run pgagent in an automated way

I extended the official postgres image with additional extensions. One of those is the pgagent extension.
Now after the postgres has started I have to run the pgagent job manually  pgagent hostaddr=xxx port=xxx ...
I tried to put it in an sh file and mount the script in the /docker-entrypoint-initdb.d directory but if I well understood these scripts are executed before starting the service. But here I have to execute the pgagent job after the postgres has been started...
Which options I have ? Override the entrypoint.sh ?
I run this container in kubernetes so I tried also with postStart lifecycle.. but this hook is running just after container creation and so postgres service is not running yet...

Yes, that's essentially what I'm suggesting (if pgagent doesn't have a way to natively wait for PostgreSQL to be available).
In the future, these sorts of questions/requests would be more appropriately posted to a dedicated support forum, such as the Docker Community Forums, the Docker Community Slack, or Stack Overflow.


⚠ Bofrost.be has degraded performance

In 90843bc, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1212 ms

Resolved: Bofrost.be performance has improved in dbdb6ec.