Clean up database systems

Fixes #1023
Changes

renames cache to intersystems_cache (cache is too broad)
removes cloudscape in favor of derby "The Apache Derby project is based upon Cloudscape version 10, which IBM contributed to Apache in 2004."  (see https://en.wikipedia.org/wiki/Apache_Derby, https://db.apache.org/ddlutils/databases/derby.html)
removed coldfusion - it's a web-development platform, not a database. It can work with different databases.
firstsql - no longer exists
mssqlcompact - discontinued, last released in 2011, end-of-support in 2021

Merge requirement checklist

[x] CONTRIBUTING.md guidelines followed.
[x] Change log entry added, according to the guidelines in When to add a changelog entry.

If your PR does not need a change log, start the PR title with [chore]

[x] schema-next.yaml updated with changes to existing conventions.

I did not find any usage of cloudscape, coldfusion or firstsql in OpenTelemetry repositories.
Checked cache in java, python and JS instrumentations - no mentions.
mssqlcompact is still used by .NET OpenTelemetry.Instrumentation.EntityFrameworkCore, but the corresponding packages for mssqlcompact are deprecated EntityFrameworkCore.SqlServerCompact40, SqlServerCompact35, and have <50 downloads per day.
The other_sql can be used as a fallback option.


Autoenrollment in pbis-open not available ?

Version: 9.0.1
OS/Distro: Ubuntu desktop 18.04 - unity desktop
Issue/Impact:
Hi all,
I try to configure auto enrollment, but in my version it seems i can't configure it. I tried to install older version but still the same.
In the wiki : https://github.com/BeyondTrust/pbis-open/wiki/Release-Notes PowerBroker Identity Services Open <IP_ADDRESS>87 there is a point about it :

Autoenrollment can now just enroll certificates

Does Autoenrollment still available in pbis-open ? If yes how can i use it ?

Actually that information is incorrect. Certificate autoenrollment in only available in Enterprise as we need to have a GPO in place to configure which templates we pull down. Information on it can be found in the GPO reference guide.


Add TLS 1.3 ciphersuite and key exchange identifiers and API

Summary: This PR fixes #4328 on the introduction of TLS 1.3 ciphersuite and key exchange identifiers.
API design considerations: The concept of TLS 1.2 and TLS 1.3 ciphersuites are different. TLS 1.2 ciphersuites combine symmetric algorithms and key exchange, while TLS 1.3 ciphersuites only fix symmetric algorithms. TLS 1.3 key exchanges are configured differently. It has been considered whether we want to unify the 1.2+1.3 APIs by allowing to always configure symmetric algorithms and key exchanges separately, and have Mbed TLS infer what "TLS 1.2 ciphersuites" are suitable for that -- however, this is likely resulting in an API break and requires significant design discussion. I therefore propose to go with the simpler solution implemented in this PR, which keeps mbedtls_ssl_conf_ciphersuites() for TLS 1.2 + 1.3 ciphersuites, and adds mbedtls_ssl_conf_tls13_key_exchange_modes() for TLS 1.3 key exchange modes. We can still consider unification of the API in Mbed TLS 4.0, when we've had a bit of experience with the TLS 1.3 implementation.
TLS 1.3 Ciphersuites:
The PR adds IANA identifiers for TLS 1.3 cipher suites:
#define MBEDTLS_TLS1_3_AES_128_GCM_SHA256                     0x1301 /**< TLS 1.3 */
#define MBEDTLS_TLS1_3_AES_256_GCM_SHA384                     0x1302 /**< TLS 1.3 */
#define MBEDTLS_TLS1_3_CHACHA20_POLY1305_SHA256               0x1303 /**< TLS 1.3 */
#define MBEDTLS_TLS1_3_AES_128_CCM_SHA256                     0x1304 /**< TLS 1.3 */
#define MBEDTLS_TLS1_3_AES_128_CCM_8_SHA256                   0x1305 /**< TLS 1.3 */

It also adds corresponding internal ciphersuite definitions to ssl_ciphersuites.c. Since the concept of TLS 1.3 ciphersuites does not imply a key exchange, the corresponding field in mbedtls_ssl_ciphersuite_t is defined as MBEDTLS_KEY_EXCHANGE_NONE.
TLS 1.3 ciphersuites have been added at the top of the default ciphersuite list if MBEDTLS_TLS1_3_EXPERIMENTAL is enabled. Note that this does not break TLS 1.2 compatibility because unknown ciphersuites MUST be ignored.
The PR also expands the documentation of mbedtls_ssl_conf_ciphersuites() and explains that the function will not need to be modified to accommodate TLS 1.3, incl. downgradable TLS 1.3 / TLS 1.2 dual-builds, despite the different ciphersuite concepts. The only thing that will change for TLS 1.3 is that there needs to be a separate key exchange configuration API, which is not necessary in TLS 1.2. This will be added in the future.
TLS 1.3 key exchanges:
The PR adds identifiers MBEDTLS_SSL_TLS13_KEY_EXCHANGE_MODE_XXX for TLS 1.3 key exchange modes and a new API mbedtls_ssl_conf_tls13_key_exchange_modes() to configure them. It allows all key exchanges by default. ssl_client2 and ssl_server2 receive a new command line argument tls13_kex_modes to configure TLS 1.3 key exchange modes. Tests to ssl-opt.sh are added which exercise that those parameters are recognized, but nothing more yet.

Thank you @mpg for your review! I believe to have addressed your comments. Could you please re-review?

Rebased to resolve trivial merge conflicts. @mpg Can you please re-review?

@bensze01 are you planning to review this soon? Otherwise, please remove yourself from the list and label "needs: reviewer". Thanks.


Swype Mobile Keyboard

What's the Product's Name?
Swype
Describe the product in a single sentence.
Mobile phone keyboard that allowed you to enter whole words by squiggling over the letters without lifting your finger.
When was the product launched? Provide a specific date, if possible.
December 2009
When was the product discontinued? Provide a specific date, if possible.
February 2018 for new installations, though existing installations could still download new languages until October 2021.
What type of product was it? App, Service, OS, or Hardware?
Mobile App
Swype was bought by Nuance. Nuance was bought by Microsoft. The final shutdown happened after the Microsoft acquisition.

Hi Martin, thanks for the suggestion!
I think that Nuance has killed Swype in 2018, so Microsoft has just followed what Nuance scheduled in 2018. What do you think?

Reading from Wiki, Nuance killed Swype in 2018, and only in 2021/2022 Microsoft acquired Nuance. So the killer was Nuance and not Microsoft.

Having worked on the launch team of Swype, this is correct. Nuance bought Swype, killed off Swype, then Microsoft bought Nuance.


Cut columns from a table -> Cut columns from a table (cut)

This is something where for sure trainees will make mistake... at least with this tool and the concatenate one.... Maybe only keep one "version" of each tools ? ITM be sure we can make the same operations, it seems to me this is not the case so "we" have to work on it carefully

thanks @yvanlebras
I agree, some of these tool names are very similar and confusing for new users, but not so easy to solve. That was part of the reason we made the GTN webhook, then when you click the toolname in the tutorial it automatically opens the correct tool, which could be a nice feature to show new users!

thanks @yvanlebras
I agree, some of these tool names are very similar and confusing for new users, but not so easy to solve. That was part of the reason we made the GTN webhook, then when you click the toolname in the tutorial it automatically opens the correct tool, which could be a nice feature to show new users!

+100 an issue here was that the tutorial creator made the mistake, so propagating the wrong tool name and version ;) And this is due to the original issue of such very similar tools with so similar names... Thank you !!


self-signed cert error

The certificates still give an error that they are not trusted because they are self-signed, anyone trying this article coming into this from a background of developing locally over http will likely need additional instructions on how to get around the certificate error. Is it worth linking out to somewhere in the docs where a list of instructions can be found on how to install a self signed certificate in browsers so that they consider the certificate to be trusted?

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

ID: 0dd2991d-c22d-ad0f-80b6-bd1b503db8f3
Version Independent ID: 5e3fbe1d-c97f-9940-4f0c-067d4b2112b1
Content: Get started with ASP.NET Core SignalR
Content Source: aspnetcore/tutorials/signalr.md
Product: aspnet-core
Technology: aspnetcore-tutorials
GitHub Login: @bradygaster
Microsoft Alias: bradyg

I guess this is somewhat related to https://github.com/aspnet/AspNetCore.Docs/issues/14756 rather than just saying it isn't supported, linking out to some instructions on how to fix will help.

It's addressed, but not necessarily fully covered (e.g., Firefox explicitly), in ...
https://docs.microsoft.com/aspnet/core/security/enforcing-ssl

Duplication, too, of https://github.com/aspnet/AspNetCore.Docs/issues/13005.
Might need to move your remark here for the SignalR doc over to a comment on that issue and then close this one.

Closing because dup.


Fix issue 14

I've modified the search param, so now it can find it in newly created devise views.

Thanks!


integration with endless-commerce

What is the motivation for adding / enhancing this feature?

I don't know.  Is it possible?

If you want to make this integration by yourself please check this repo: https://github.com/DivanteLtd/vue-storefront-integration-boilerplate

I will return when I have a contribution to this effect, thank you.


Make DS params in XML optional

I would like to see a setting to turn on and off the parameter output to XML in class.frontendpage.php starting on line 444.
Use case: when outputting a $ds-datasource-parameter such as IDs to be used as a filter in another data source, there can be unnecessary overhead when the number of IDs is significant.
What do you guys think?

This is an old thread, but I also experienced a massive performance issue just because one data source was outputting around 1000 IDs (which were added to the parameter XML node). I hacked a solution, but I would like to share some thoughts on this. Please close this issue again if you feel that I am on the wrong track.
The decision to add parameters to page XML was absolutely right (and we should completely drop passing "parameters as arguments" to the XSL processor in a future release). But at that time, we did not see that DS parameters play a special role. Their main task is to allow DS filtering/chaining. Keeping them in the param pool is not strictly necessary (because you can always add field output to XML if you need these values for templating).
Given the performance issues that may arise I suggest to add a configuration option to Symphony which allows to omit data source parameters from page XML (which was the original intention of this thread).
We might, of course, open new issues to discuss more elaborate solutions. Maybe we should have a new  page in the debugger extension to show these parameters (no matter if they are kept in the param pool or not). Maybe we should remove DS params completely (from what we currently think is "normal params")? Maybe we think about deciding this on a per-data-source basis (which would probbly get rather complicated)? I don't know, but I think that this should be discussed separately.
BTW, currently my solution is to use the FrontendParamsResolve delegate with a callback like this:
public function frontendParamsPostResolve($context)
{
    if (Symphony::Configuration()->get('add_ds_params_to_xml', 'custom_config') === 'no') {
        foreach ($context['params'] as $key => $value) {
            if (substr($key, 0, 3) === 'ds-') {
                unset($context['params'][$key]);
            }
        }
    }
}

If somebody has a better idea, I am all ears!

I do not think that the setting should be on a site basis, but more on the data source level...
Ever went on that path Micheal ?

Datasource level seems to make most sense to me. I do have datasources
where I don't need this and others where having it would be nice.
On Tue, 16 Feb 2016 at 17:23 Nicolas Brassard<EMAIL_ADDRESS>wrote:

I do not think that the setting should be on a site basis, but more on the
data source level...
Ever went on that path Micheal ?
—
Reply to this email directly or view it on GitHub
https://github.com/symphonycms/symphony-2/issues/784#issuecomment-184753269
.

Let's assume that a developer must make a decision for every data source.  You will answer: "It makes your site faster, and you don't really need those parameters, they are intended for internal use." What would the developer say then? "Why do I have to decide this for every data source then?" or maybe: "Why do I have to decide this at all?" He probably wouldn't say "It's cool to have an option in every DS to slow down the site."
The proper long term solution, in my eyes, is to remove these parameters completely from the param pool and use them for DS chaining exclusively. Separate "params" from "DS params". Of course the debugger would need a new page then to show those DS params.
The simplest short term solution is to add a global config option. Honestly, in my "big system" I have not found more than 6 occurences in the templating layer making use of DS parameters. And it was pretty simple to remove them.

Your arguments are indeed right, but I fear that a single on/off switch might not be flexible enough.

Separate "params" from "DS params". Of course the debugger would need a new page then to show those DS params.

The more I think about it, the more I see to separate concerns: XML output params (which I use quite often) and "filtering values" for chaining and filtering.
But now the question is: how to change this ? Are current output parameters only for filtering (and we add the xml param) or the other way around ?

a single on/off switch might not be flexible enough

DS params don't provide any additional functionality for XSLT templating. Everything can be done with DS output. So we wouldn't compromise flexibility at all.

The more I think about it, the more I see to separate concerns: XML output params (which I use quite often) and "filtering values" for chaining and filtering.

Exactly! And that is why we should aim to completely remove the "filtering values" from XML on the long run.

Are current output parameters only for filtering (and we add the xml param) or the other way around ?

I see output parameters as useful for templating. Think of the "standard" parameters like the sitename, for example. The filtering values on the other hand could live in a new array, internally, and exposed by a special debugging page. But that is the long term solution (and it's potentially breaking sites). Short term, pretty close to this (but non-breaking), is my suggestion to have a global config option to unset the DS params immediately before the are:

added to XML
added as arguments to the processor call (deprecated, but still alive)

The downside of my described "hack" is the fact that I can never be sure that a leading ds- identifies a datasource parameter. It might as well be some custom parameter (e.g. the "DS Double Super Param", ds-double-super-param) provided by an extension. If we tend to say that ds- is a reserved string (for Symphony DS params), I don't see any issues. :-)

remove the "filtering values" from XML on the long run.

Agreed.

The filtering values on the other hand could live in a new array, internally,

Agreed.

and exposed by a special debugging page

I do not agree. It should be output if the DS wants it so. There should also be a dedicated xml node for them (instead of ds- prefix)

It should be output if the DS wants it so.

Why? As I said, it can't do anything for templating that can not be done with standard DS output. Or am I missing something?

Hmm can't think of a usecase which uses the ds param in xslt that can't be
done with standard output.
On Tue, 16 Feb 2016 at 18:49 michael-e<EMAIL_ADDRESS>wrote:

It should be output if the DS wants it so.
Why? As I said, it can't do anything for templating that can not be done
with standard DS output. Or am I missing something?
—
Reply to this email directly or view it on GitHub
https://github.com/symphonycms/symphony-2/issues/784#issuecomment-184797258
.

As I said, it can't do anything for templating that can not be done with standard DS output. Or am I missing something?

I was thinking about a list of ids. But yeah, I could create an empty DS returning only entry ids so I guess you are right!

No, you are indeed right. At the moment Symphony outputs an empty DS node (without entry nodes, which means without IDs) if nothing is seleted for output. If you need entry nodes, you have to select a field, or at least the system:pagination element:
<test cache-age="fresh">
	<pagination total-entries="22254" total-pages="1113" entries-per-page="20" current-page="1"/>

News

	<entry id="307462"/>
	<entry id="307460"/>
	<entry id="307457"/>
	...
</test>

(Which is fine for me.)

you have to select a field,

Would system:id work ?

Wait, let me test...

Oh no, it's not selectable at all in "included elements". There's system: pagination and system: date…
It feels like something's missing. :-(

I actually have one scenario where I use the /data/params information, and I'm not too sure how else I can achieve the same result... maybe someone here will know!
When using the Association Field with multiple options, the author is allowed to drag and drop the entries around to form a sort order. As I don't want to incur the performance overhead of including this data inside the datasource, I output the parameters and create another datasource that filters off those parameters.
Unfortunately the custom sort order is lost on that chained datasource, so the only way I can output the data in the same sort order as the author defined is to loop over the parameters and then call the entry individually:
<xsl:template match='my-ds'>
    <xsl:variable name='ds' select='.' />

    <xsl:for-each select='/data/params/my-ds.association-field/item'>
        <xsl:apply-templates select='$ds/entry[@id = current()]' />
    </xsl:for-each>
</xsl:template>

I originally thought the fix could be applied to the chained DS, but that breaks the concept of DS which have filters from multiple DS.
Ideas?

I'm also curious why & where the performance bottleneck occurred. Outputting 1000 nodes shouldn't bring the system to a halt :(

@brendo Nils once told me there'd be a lot of overhead if you drill down without using a separate DS but I didn't know why. I switched to entry_relationship_field instead because it doesn't seem to have that problem.

Hi @brendo, I see your point. It would be great to know how big the performance overhead would be if your data currently outputted as (data source) parameters is also included in the standard XML output. I have no idea. Could you maybe test this?
I do have numbers for my situation: I am talking about my "big system" (you may remember that); in the past months I have tuned it with Zend Opcache and a data source caching layer. Now when all data sources are read from the cache, building the page in question took 0.30 seconds total (which was indeed slow compared to other pages, hence my profiling/debugging). After removing remove those 1000 parameters from the param pool, the page takes 0.15 seconds, which is half the time! I have tested this several times—on my machine it obviously takes 150ms to build 1000 param values.

I did a short test with my setup. I had to include the entry titles in the output in order to get the entry IDs, and this took an extra 0.20 seconds in my case. (Unfortunately, it is not possible to output the IDs only, see above.)
If we fix this (allow to output system:id only in data sources), I would assume that the standard output XML wouldn't take any longer than the DS param XML. So you wouldn't lose anything in your scenario. But every site would gain to a certain extend.

If somebody can tell my how to hack the section data source to include system:id only in the output, I can try and verify my above assumption. It would be interesting, because DS output would be <entry id="123"/> instead of <item>123</item> — shouldn't the first one take longer (which would prove me wrong)?

@brendo is right: The sort order is lost. I knew I also had something that would need this kind of behavior.
@michael-e can you try to edit the php file of the DS to set it to system:id ?

@munki-boy

I switched to entry_relationship_field instead because it doesn't seem to have that problem.

it has other problems tho ;)

This gets better every day.

including 1000 entry IDs in the XML params node takes 150ms (as posted above)
including 1000 entry IDs () in standard XML output takes no time. At least not notable.

How can that be?

Wow I seriously do not know...

The biggest performance hickup in the params in building handles using:
$item->setAttribute('handle', Lang::createHandle($value));
```

I have sent a pull request to integration concerning this which has been pulled: https://github.com/symphonycms/symphony-2/pull/2377. But it has not been changed in 2.6.x because it is might be a breaking change if people *would* use the parameter handle in XSLT templates.

Now I have:

* including 1000 entry IDs in the XML params node (as `<item handle="123">123</item>`) takes 150ms (as posted above)
* including 1000 entry IDs in the XML params node **without handles** (as `<item>123</item>`) takes 150ms (as posted above)
* including 1000 entry IDs in standard XML output (as `<entry id="123"/>`) takes no time. At least not notable. Maybe 2ms…

Wow ! I did not knew that creating handles was such long!

It might be the language stuff?

Regexp... ?

That would explain it.
Now I will try and find the remaining 25ms.

;) Thanks Michael!

I am already down to <10ms difference. :-)) The remaining difference might be caused by a testing hack. I will be back at the keyboard a bit later (2 hours or so).

:+1:

@nitriques They both have problems, you have to pick the one with the least for the project you're working on :)

@munki-boy Exactly!

Still Symphony's speed shouldn't be compromised without need. That's why I make all those tests.

That's why I make all those tests.

And I am gracefull you do ;)

It's hard to test page generation differences below 20ms reliably, but I would say:

it's fastest to not output anything from a datasource (haha)
it's no big deal (plus 2ms or so) to output 1000 IDs to standard XML (as <entry id="123"/>) — currently Symphony is missing the possibility to output IDs only, so this should definitely be added
it's a bit slower (around 15ms, I couldn't find out why this is slower) to ouput 1000 IDs to the param pool (as <item>123</item>) if you omit the "legacy style" param output (ds-datasource-handle); removing that legacy style is on the list, AFAIK — unfortunately it's a breaking change
it's again a bit slower (plus 15ms) to additionally output legacy style parameters — Symphony does this at the moment; at this point we are nearly 30ms behind ouputting those IDs to standard XML only, but it will get much worse!
it's terribly slow (plus 150ms, approx.) to ouput handles for those 1000 IDs to the params XML as well, like Symphony does it it at the moment — unfortunately removing the handles is a breaking change as well

All this has been tested on my production server, which is very fast. So with vServers or even shared hosting, you should await bigger numbers.
I will try and post suggestions how to fix this (short-term and long-term) tomorrow. I don't want to spoil a party, so I better think twice. :-)

Thanks a lot Michael.

I was looking for a logical explanation, and I found it.
The difference between adding nodes to standard XML output and adding nodes to the param pool is caused by the way DS caching works. (Of course I used DS caching in my tests to get rid of database performance jitter, I think I mentioned that. It would be very hard or even impossible to benchmark these differences if you rely on thousands of database queries.)
Here it is: If you use DS caching, the output XML will be cached as a whole. But cached params will just be added to the param array again, which means that their XML elements will have to be built from scratch even for a cached data source. This in turn means that:

it doesn't matter if you build 1000 elements for the params node or for the standard XML output, but
DS caching will circumvent building new XML objects for XML output only, so if you use DS caching it actually does matter—if you use caching, you better use standard output, not params! :-)

Here are the simplified numbers:

it's fastest to not output anything from a datasource (haha)
if you use DS caching, it's no big deal (maybe plus 2ms or so) to output 1000 IDs to standard XML (as <entry id="123"/>) — currently Symphony is missing the possibility to output IDs only, so this should definitely be added
if you do not use caching, the same will probably take around 15ms (untested, but "high probability")
no matter if you use DS caching or not, it takes around 15ms to ouput 1000 IDs to the param pool (as <item>123</item>) if you omit the "legacy style" param output (ds-datasource-handle); removing that legacy style is on the list, AFAIK — unfortunately it's a breaking change
no matter if you use DS caching or not, it adds another 15ms to additionally output legacy style parameters — Symphony does this at the moment; at this point we are nearly 30ms behind ouputting those IDs to standard XML only, but it will get much worse!
no matter if you use DS caching or not, it's terribly slow (plus 150ms, approx.) to ouput handles for those 1000 IDs to the params XML as well, like Symphony does it it at the moment — unfortunately removing the handles is a breaking change as well

Still I am thinking about the right way to deal with this. Two of those "optimizing but breaking" changes are already in the integration branch, and so I wonder if this would be a good time to talk about what we want Symphony 3 to be. Theoretically, if we took these breaking changes from integration and released Sym 3.0.0… There would one big advantage: The number of breaking changes would be small, and people could indeed update their installations (with a bit of work, of course, but we could provide instructions). In this case Symphony 3.0.0 wouldn't have many bugs either—we have a very good codebase in this respect at the moment, IMHO. And finally we would get rid of the "Sym 3 hoax nightmare" by just releasing it with a handful of breaking changes. (We embraced semantic versioning, but still Symphony 3 scares us. Why?)
(There are other changes in the integration branch which are much more frightening to me, especially PDO and the cookie/session rewrite. So I would not suggest to include these in Symphony 3.0.0 without excessive testing. They shouldn't be "breaking", should they? So they might as well be introduced in 3.1.0.)

good time to talk about what we want Symphony 3 to be.

I've rebased the branch this morning BTW :) I hope to get it out this summer...

We embraced semantic versioning, but still Symphony 3 scares us. Why?

I really do not know why. Here's a good read
We should also consider renaming the repo to symphonycms

They shouldn't be "breaking", should they? So they might as well be introduced in 3.1.0.)

Those are breaking changes, so it would be 4! Breaking.Features.Fixes.
But I would very like to include them in 3.0.0. Brendan's new logger too.

But I would very like to include them in 3.0.0. Brendan's new logger too.

I have never really understood the PDO stuff. Will it mean that upgrading will become more difficult if you use a lot of custom queries in your extensions?

Breaking.Feature.Fix.

Nice explanation!
Still, may I suggest that the last "feature version" of Symphony 2 should get some sort of long term support (e.g. "Sym 2.7 LTS") for those who don't dare to upgrade?
BTW, stopping at 2.7 would be a nice coincidence, because Symphony 1 stopped at version 1.7.01, as far as I remember.

Will it mean that upgrading will become more difficult if you use a lot of custom queries in your extensions?

I do not think it will. Maybe only a problems with backticks...

Still, may I suggest that the last "feature version" of Symphony 2 should get some sort of long term support

I'd like to call it with a cooler name :) Polls are open!

BTW, stopping at 2.7 would be a nice coincidence

This will depend on the code itself!

"Symphony Classic"

Hum I am more searching for a set of names. Like famous scientists or astral bodies....

I think that Symphony 2.7 LTS sounds pretty cool.
We might add a nickname, like Debian does it. Symphony 2.7 LTS "Lulu", for example.
:-)

We might add a nickname,

That's what I am looking for. But dropping the version in the name. LTS version can get more feature so we can go to 2.8, 2.9...

Ah, you mean s.th. like Symphony 2 LTS "Albert Einstein"! :-)

But wouldn't it mean less hassle to "feature-freeze" an LTS version?

Hmm might - I think the problem was mainly that up till 2.4 or something
like that each update was breaking. Though I think at some point we need to
start looking at features of 3.0 and start looking for that move.
On Fri, 19 Feb 2016 at 16:34 michael-e<EMAIL_ADDRESS>wrote:

But wouldn't it mean less hassle to "feature-freeze" an LTS version?
—
Reply to this email directly or view it on GitHub
https://github.com/symphonycms/symphony-2/issues/784#issuecomment-186262037
.

We might add a nickname, like Debian does it. Symphony 2.7 LTS "Lulu", for example.

Symphony LTS "Brendan" sounds quite nice to me ;)

LTS version can get more feature so we can go to 2.8, 2.9...

Just a noob-question: Facing the fact that Symphony switched to semantic versioning with 2.5 I would have expected the last release of the 2.X-branch to become the LTS-version - wouldn't it get confusing if features were added to 2.7 (LTS) while other (non-breaking?) changes were only added to 2.8 or 2.9...?

I think he said without the version number though? So 2.8... would be sort if internal name.

Not "Heisenberg" people think Breaking Bad on TV

I would have expected the last release of the 2.X-branch to become the LTS-version

That was my thought as well. No new features anymore. "LTS" meaning "don't be afraid to use this and build cool stuff, we will care for bugs (especially security) for quite a while". (I'd say 3 years or so.)

I think he said without the version number though? So 2.8... would be sort if internal name.

Ah, so 2.8 and 2.9 would be "inofficial" version numbers for updates to Symphony LTS (which would drop the "offical" version numbers) - that would make sense... am I getting this right?

That's what I thought - doesn't make it right :)

@twiro: In this case what does LTS stand for? "It might as well break, because we are still fiddling with the codebase."???

Long Term Support - someone will be around to fix it.

In this case what does LTS stand for? "It might as well break, because we are still fiddling with the codebase."???

I was just trying to understand/interpret what Nicolas wrote:

"LTS version can get more feature so we can go to 2.8, 2.9..."

I have no idea what LTS usually stands for in software development - does it imply "no more features" or simply "non-breaking changes/features might be added but if something breaks it will be fixed asap!"

But wouldn't it mean less hassle to "feature-freeze" an LTS version?

Yeah maybe, but I really want the codename to not refer to a particular version. One could want to port some feature to the LTS version. LTS only means we will fix bugs and continue to release new versions of that particular codebase.

I have no idea what LTS usually stands for in software development

It means that version will be maintain for a "long" period of time. I would like to see something in the 2-3 years mark.

wouldn't it get confusing if features were added to 2.7 (LTS) while other (non-breaking?) changes were only added to 2.8 or 2.9...?

No since it will share the same code name. Versions are for computers, names are for humans.

Also, maybe or second LTS version would be 3.2 or even 4.1.

LTS only means we will fix bugs and continue to release new versions of that particular codebase.

Would that work? It feels like a workaround, invalidating semantic versioning. @nitriques, maybe I just don't get your idea? I thought:

Release 2.7 as final Symphony 2 version, with LTS support (fixes only)
Release 3.0 as fast as possible, with just a handful of breaking changes but high code quality from the start (so people can move their projects forward).
(Personally I'd rather push some of the breaking changes to Symphony 4 than again risk to have a wonky major release; the PDO implementation seems incomplete and buggy currently, session/cookie stuff requires solid testing)
Look forward to Symphony 4

second LTS version would be 3.2 or even 4.1

Yes, that would probably be the case then, depending on how difficult it is to upgrade between versions. If it is difficult, an LTS version makes sense.

An LTS version provides a stable option for use in less heavy environments while freeing people to innovate more with the big version. Without forcing everyone to have the fast private server with ability to install the latest PHP/SQL etc.
Doing these things with semantic versioning all in one "family" of Symphony might mean selecting an older version of Symphony due to server/hosting requirements and possibly selecting a version with flawed security or other problems.
LTS version can fill that gap and people who select it won't be requesting bleeding edge features or need support with the problems of bleeding edge features. Less features but stable and reliable.
I am guessing.

If it is difficult, an LTS version makes sense.

Yup totally.

Release 2.7 as final Symphony 2 version, with LTS support (fixes only)

That would be the plan, but I do not want to lock that down. LTS release could go to 2.8 if needed.

An LTS version provides a stable option for use in less heavy environments while freeing people to innovate more with the big version. Without forcing everyone to have the fast private server with ability to install the latest PHP/SQL etc.

Also true! But again, it does not lock anything.

invalidating semantic versioning

It's not! It's even letting us manage versions without regards on what are considered to be LTS versions (which have codenames).

Less features but stable and reliable.

Exactly. But we still allow people to backport new features in LTS releases.

No, it doesn't lock anything.  It's like Symphony Lite but we must not say that for it implies the other to be heavy, which it isn't. :)

Dupe, tracking #2338 instead

I editied the title of this thread in order to better avoid this misunderstanding. This thread is about data source parameters, which are typically used for data source filtering, so including them in XML output is considered unnecessary overhead. #2338 is about generally removing "parameters as arguments" (for the XSLT processor), while keeping them in the XML.

Thanks @michael-e


path BUG in expectModuleToBeCalledWith

As mentioned in Docs, we must use expectModuleToBeCalledWith to test our modules.
  test('should inject plugin', () => {
    expectModuleToBeCalledWith('addPlugin', {
      src: expect.stringContaining('templates/plugin.js'),
      fileName: 'myPlugin.js',
      options: getNuxt().options.myModule
    })
  })

But there is a problem: The given src or even fileName in this format leads the testing to failure.
Here is my code:
expectModuleToBeCalledWith('addPlugin', {
  src: expect.stringContaining('store/index.js'),
  fileName: 'console/store/index.js',
  options: defaultConfig
})

I get this error:
  Object {
    -   "fileName": "logs/store/index.js",
    +  "fileName": "logs\\store\\index.js",
         "options": Object {
            "namespace": "logs",
          },
     -  "src": StringContaining "store/index.js",
    +  "src": "C:\\Users\\xxxx\Desktop\\nuxt\\modules\\nuxt-logs\\lib\\store\\index.js",
    },

Here is some information:
OS: Windows 10
Node: v12.16.1
@nuxt/test-utils: 0.2.2
nuxt-edge: 2.16.0

I still get the error
Object {
  - "fileName": "logs/store/index.js",
  + "fileName": "logs\\store\\index.js",
      "options": Object {
        "namespace": "logs",
      },
  - "src": StringMatching /store[\\/]\\?index\.js/,
  + "src": "C:\\Users\\SaLeH\\Desktop\\My Projects\\modules\\nuxt-browser-console\\lib\\store\\index.js",
},

My code:
expectModuleToBeCalledWith('addPlugin', {
  src: expect.stringMatching(/store[\\/]\\?index\.js/),
  fileName: 'console/store/index.js',
  options: defaultConfig
})

The reason I mentioned this as a BUG is that in my opinion, the UNIX path should be export no matter of OS.

@ms-fadaei You have added an extra backslash compared to the example I gave.

@ms-fadaei You are targeting src rather than filename which will also likely need a matcher.

Thanks...I was thinking they are two separate things to evaluate


Fix: Camelize the default value of psr4_namespace

Description
The users don't need to input the namespace in most cases if Vendor\PackageName is used as the default value.
Although the PSR did not make a recommendation, it was a de facto standard.
PSR survey result on class_names:
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md#a3-survey-results
Motivation and context
If some people input vendor foo and package name hello-world, then the default namespace was foo\hello-world, indeed a invalid namespace, he had to input the namespace Foo\HelloWorld again.
How has this been tested?
Tested by running prefill.php from the command line like this:
...
Package vendor (<vendor> in https://github.com/vendor/package) [foo]:
Package name (<package> in https://github.com/vendor/package): hello-world
Package very short description:
PSR-4 namespace (usually, Vendor\Package) [Foo\HelloWorld]:
...

Screenshots (if appropriate)
Types of changes
What types of changes does your code introduce? Put an x in all the boxes that apply:

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:
Go over all the following points, and put an x in all the boxes that apply.
Please, please, please, don't send your pull request until all of the boxes are ticked. Once your pull request is created, it will trigger a build on our continuous integration server to make sure your tests and code style pass.

[x] I have read the CONTRIBUTING document.
[x] My pull request addresses exactly one patch/feature.
[x] I have created a branch for this patch/feature.
[x] Each individual commit in the pull request is meaningful.
[x] I have added tests to cover my changes.
[x] If my change requires a change to the documentation, I have updated it accordingly.

If you're unsure about any of these, don't hesitate to ask. We're here to help!

Nobody response to this, I think you don't like this pull request, disappointed and goodbye.

Well, not speaking for the owners of this sub, but I think assuming no response equals "this is shit" is probably not the best way to contribute in my opinion :) Why not just ask for feedback and leave your PR open even if it lasts 2 months? Just my 2 unsolicited cents.

Thank you for your encouragement, I will reopen the PR and wait for another response.


library "libsqlitejdbc.so" not found on Android

Describe the bug
Run on android platform will issue this bug
To Reproduce
public void processSqlite() {
Connection connection = null;
try
{
AssetsDatabaseManager mg = AssetsDatabaseManager.getManager();
String dbPath = mg.getDatabasePath("20220908_R0777777.db");
//            getResources().openRawResource();
//            Resources    resources.openRawResource(resourceRawFilename)
SQLiteMCWxAES128Config config =   new SQLiteMCWxAES128Config();
//connection=config.withKey("123456").build().createConnection("jdbc:sqlite:file:20220908_R0777777.db");
connection=config.withKey("123456").build().createConnection("jdbc:sqlite:file:" + dbPath);
        Statement statement = connection.createStatement();
        statement.setQueryTimeout(10);  // set timeout to 10 sec.

        ResultSet rs = statement.executeQuery("select * from data");
        while(rs.next())
        {
            // read the result set
            System.out.println("serial = " + rs.getString("serial"));
            System.out.println("id = " + rs.getInt("id"));
        }
    }
    catch(SQLException e)
    {
        // if the error message is "out of memory",
        // it probably means no database file is found
        System.err.println(e.getMessage());
        e.printStackTrace();
    }
    catch(Exception e) {
        e.printStackTrace();
    }
    finally
    {
        try
        {
            if(connection != null)
                connection.close();
        }
        catch(SQLException e)
        {
            // connection close failed.
            System.err.println(e.getMessage());
        }
    }
}

Expected behavior
A clear and concise description of what you expected to happen.
Logs
2022-10-12 11:27:01.122 16877-16877/com.somnics.sqlite E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.somnics.sqlite, PID: 16877
java.lang.UnsatisfiedLinkError: dlopen failed: library "libsqlitejdbc.so" not found
at java.lang.Runtime.loadLibrary0(Runtime.java:1077)
at java.lang.Runtime.loadLibrary0(Runtime.java:998)
at java.lang.System.loadLibrary(System.java:1656)
at org.sqlite.core.NativeDB.(NativeDB.java:40)
at org.sqlite.core.NativeDB.load(NativeDB.java:60)
at org.sqlite.SQLiteConnection.open(SQLiteConnection.java:281)
at org.sqlite.SQLiteConnection.(SQLiteConnection.java:68)
at org.sqlite.jdbc3.JDBC3Connection.(JDBC3Connection.java:28)
at org.sqlite.jdbc4.JDBC4Connection.(JDBC4Connection.java:19)
at org.sqlite.JDBC.createConnection(JDBC.java:104)
at org.sqlite.SQLiteConfig.createConnection(SQLiteConfig.java:108)
Environment (please complete the following information):

OS: [Android 12]
CPU architecture: [armeabi]
sqlite-jdbc version [<IP_ADDRESS>]

Additional context
Add any other context about the problem here.
thanks.

About Android ABI description:
https://developer.android.com/ndk/guides/abis

The native library directory needs to be corrected.
/org/sqlite/native/Linux-Android
aarch64 -> arm64-v8a
arm -> armeabi-v7a
x86
x86_64
I have tested it, It's working now on Android.

Thanks for all information.
I'm glad you solved your issue.
As this repository is a fork, I would advise you to create an issue at https://github.com/xerial/sqlite-jdbc so that the original author can fix it.


Reformatting logs for multi threading

Moved over to zerolog, and merged the various PRs together to attempt to clean up.

make test is passing locally - for some reason I can't get an action to trigger to check that CI is also passing so let's merge and see


This theme seems to break the basic editor functions

Hello MeghnaAJ,
I used your theme on my instance, it looks very good, however, it seems to break the basic editor functions.

There are no markdown and emoji tools
No preview (tried to click the arrows a few times)
Drafts don’t seem to be auto-saved anymore
There are no javascript errors in the browser console
I tested on both chrome and edge
The text editor is broken in the same way for creating new topics and post replies.

I switched back to the default theme and everything went back to normal. I've tested a few times and pretty sure it's this theme breaking the editor.

Maybe there's a plugin which could overwrite the theme in order to restore a full editor?


Add conversations.list method to WebAPI

https://api.slack.com/methods/conversations.list

This looks great, thanks for the PR!


Libpostal 1.0

A whole lot of issues are about to get closed. Libpostal 1.0 features a better-than-ever international address parser which achieves 99.45% full-parse accuracy on held-out addresses. Here's a sample of what it can do in a GIF:

Breaking API Changes

Every function, struct, constant, etc. defined in the public header (libpostal.h) now uses a "libpostal_" prefix . This affects all bindings that call the C API. The bindings that are part of this Github org all have 1.0 branches.

New tags
Sub-building tags

unit: an apartment, unit, office, lot, or other secondary unit designator
level: expressions indicating a floor number e.g. "3rd Floor", "Ground Floor", etc.
staircase: numbered/lettered staircase
entrance: numbered/lettered entrance
po_box: post office box: typically found in non-physical (mail-only) addresses

Category tags

category: for category queries like "restaurants", etc.
near: phrases like "in", "near", etc. used after a category phrase to help with parsing queries like "restaurants in Brooklyn"

New admin tags

island: named islands e.g. "Maui"
country_region: informal subdivision of a country without any political status
world_region: currently only used for appending “West Indies” after the country name, a pattern frequently used in the English-speaking Caribbean e.g. “Jamaica, West Indies”

No more accent-stripping/transliteration of input
There's a new transliterator which only makes simple modifications to the input (HTML entity normalization, NFC unicode normalization). Latin-ASCII transliteration is no longer used at runtime. Instead, addresses are transliterated to multiple forms during training so the parser has to deal with all the variants rather than normalizing to a single variant (which previously was not even correct in cases like Finnish, Turkish, etc.) in both places.
Trained on > 1 billion examples in inhabited country on Earth
The training data for libpostal's parser has been greatly expanded to include every country and dependency in OpenStreetMap. We also train on a places-only data set where every city name from OSM gets some representation even if there are no addresses (higher-population cities get examples proportional to their population). A similar training set is constructed for streets, so even places which have very few addresses but do have a road network in OSM can be included.
1.0 also moves beyond OSM, training on most of the data sets in OpenAddresses, and postal codes + associated admins from Yahoo's GeoPlanet, which includes virtually every postcode in the UK, Canada, etc.
Almost 100GB of public training data
All files can be found under s3://libpostal/training_data/YYYY-MM-DD/parser/ as gzip'd tab-separated values (TSV) files formatted like:language\tcountry\taddress.

formatted_addresses_tagged.random.tsv.gz (ODBL): OSM addresses. Apartments, PO boxes, categories, etc. are added primarily to these examples
formatted_places_tagged.random.tsv.gz (ODBL): every toponym in OSM (even cities represented as points, etc.), reverse-geocoded to its parent admins, possibly including postal codes if they're listed on the point/polygon. Every place gets a base level of representation and places with higher populations get proportionally more.
formatted_ways_tagged.random.tsv.gz (ODBL): every street in OSM (ways with highway=*, with a few conditions), reverse-geocoded to its admins
geoplanet_formatted_addresses_tagged.random.tsv.gz (CC-BY): every postal code in Yahoo GeoPlanet (includes almost every postcode in the UK, Canada, etc.) and their parent admins. The GeoPlanet admins have been cleaned up and mapped to libpostal's tagset
openaddresses_formatted_addresses_tagged.random.tsv.gz (various licenses, mostly CC-BY): most of the address data sets from OpenAddresses, which in turn come directly from government sources
uk_openaddresses_formatted_addresses_tagged.random.tsv.gz (CC-BY): addresses from OpenAddresses UK

If the parser doesn't perform as well as you'd hoped on a particular type of address, the best recourse is to use grep/awk to look through the training data and try to determine if there's some pattern/style of address that's not being captured.
Better feature extraction

n-grams for the "unknown" words (occurred fewer than n times in the training set)
for unknown words that are hyphenated, each of the individual subwords if frequent enough, and their ngrams otherwise
an index of postcodes and their admin contexts built from the training data (the intuition is that something like "10001" could be a postcode or a house number, but if words like "New York", "NY", "United States", etc. are to its right or left, it's more likely to be a postcode).
for first words that are unknown (could be part of a venue/business name, could be a rare/misspelled street), a feature which finds the relative position of the next number and the next address phrase if present. Usually if the parser gets the first word in the string correct it will get the entire string correct.

More powerful machine learning model (CRF)
libpostal 1.0 uses a Conditional Random Field (CRF) instead of the greedy averaged perceptron. This more powerful machine learning method scores sequences rather than individual decisions, and can revise its previous decision if that would help a subsequent token score higher (Viterbi inference).
Improves upon the CRFsuite implementation in terms of:

performance: Viterbi inference sped up by 2x
scalability: training set doesn't need to fit in memory
model expressiveness: libpostal's CRF adds state-transition features which can make use of both the state of the current token and the previous tag. These act just like normal features except their weights are LxL matrices (tags we could have transitioned from by tags we could transition to) instead of L vectors.

Very excited to run some regressions and see the improvements!
Btw, I think the heading: "Trained on > 1 billion examples in inhabited country on Earth" is missing the word "every".


Adding controlplane or etcd node with --label resets labels on other nodes

What kind of request is this (question/bug/enhancement/feature request):
bug
Steps to reproduce (least amount of steps as possible):

Provision a three node custer cluster (k8s v1.15.9), 1 worker, 1 controlplane, and 1 etcd node. For each node use --label color=red in the docker run command to label each node with the color red.
In the UI, edit each node of the three nodes and change the color label to blue.
Add a fourth controlplane node to the cluster and use --label color=red.

Result:
After adding the fourth controlplane node, the original controlplane node and etcd node labels are changed back to their original labels of color=red. This is not expected behavior, the labels should not have changed.
Other details that may be helpful:
The label on the worker node does not change. Adding more workers does not reset labels. Adding more etcd or controlplane nodes does reset labels on both etcd and controlplane nodes. Deletion of an etcd or controlplane node also resets labels of the remaining etcd and controlplane nodes.
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI):
v2.3.5

Installation option (single install/HA):
single install

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported):
custom
Machine type (cloud/VM/metal) and specifications (CPU/memory):
t3a.medium in aws
Kubernetes version (use kubectl version):

> kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.1", GitCommit:"d647ddbd755faf07169599a625faf302ffc34458", GitTreeState:"clean", BuildDate:"2019-10-02T17:01:15Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.9", GitCommit:"2e808b7cb054ee242b68e62455323aa783991f03", GitTreeState:"clean", BuildDate:"2020-01-18T23:24:23Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

Docker version (use docker version):

$ docker version
Client: Docker Engine - Community
 Version:           19.03.5
 API version:       1.40
 Go version:        go1.12.12
 Git commit:        633a0ea838
 Built:             Wed Nov 13 07:22:05 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.5
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.12
  Git commit:       633a0ea838
  Built:            Wed Nov 13 07:28:45 2019
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.2.10
  GitCommit:        b34a5c8af56e510852c35414db4c1f4fa6172339
 runc:
  Version:          1.0.0-rc8+dev
  GitCommit:        3e425f80a8c931f88e6d94a8c831b9d5aa481657
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

This is working as intended. The label being added through the docker command is saved as part of the plan for the node which is then applied by RKE and used as the source of truth for any additional updates. Editing a label that was set on the docker call will eventually be overwritten on a normal sync for the node even without adding a new node to trigger this. The logic for controlplane/etcd vs worker nodes are also slightly different as seen by the fact the worker does not get updated.

This is technically a regression based on https://github.com/rancher/rancher/issues/15709. The edit use case should work but delete is still not supported.

@StrongMonkey We ran into something similar to this issue last week, new nodes are started by
passing the  label --label example.com/node-pool=gpu but then end up with the label --label example.com/node-pool=default .  Logs on the node show that correct label is passed on node startup.

Reproduced the issue on v 2.3.5
Steps:

Deploy a three node cluster cluster (k8s v1.15.9), 1 worker, 1 controlplane, and 1 etcd node. For each node use --label test=value in the docker run command to label each node with the color red.
In the UI, edit each node of the three nodes and change the test label to value2.
Add a fourth controlplane node to the cluster and use --label test=value.
After adding the fourth controlplane node, the original controlplane node and etcd node labels are changed back to their original labels of test=value.

verified on master-head - commit id: 3623201ad issue still exists
Steps:

Deploy a three node cluster cluster (k8s v1.15.9), 1 worker, 1 controlplane, and 1 etcd node. For each node use --label test=value in the docker run command to label each node with the color red.
In the UI, edit each node of the three nodes and change the test label to value2.
Add a fourth controlplane node to the cluster and use --label test=value.
After adding the fourth controlplane node, the original controlplane node and etcd node labels are changed back to their original labels of test=value.

 For each node use --label color=red in the docker run command to label each node with the color red.

In the UI, edit each node of the three nodes and change the test color=blue

During edit of labels on the node

Editing labels that are part of the original plan on the etcd and control plane nodes - causes a reconcile --> Cluster goes into Updating state --> reconcile happens and cluster comes back to Active state

Editing labels that are part of the original plan on the worker node, does NOT cause a reconcile, but the cluster state does change to Updating for few seconds before it comes back to Active.

Add a fourth controlplane node to the cluster and use --label color=red

After adding the fourth controlplane node, the original controlplane node and etcd node labels do not change.

The newly added control plane node has label - color=red

The issue mentioned here - https://github.com/rancher/rancher/issues/25144#issue-556675916 is fixed.

But on adding a new label (not part of the original plane) on the control plane node -- A reconcile happens which is not expected. Hence reopening the issue.

 For each node use --label color=red in the docker run command to label each node with the color red.

In the UI, edit each node of the three nodes and change the test color=blue

During edit of labels on the node

Editing labels that are part of the original plan on the etcd and control plane nodes - causes a reconcile --> Cluster goes into Updating state --> reconcile happens and cluster comes back to Active state

Editing labels that are part of the original plan on the worker node, does NOT cause a reconcile, but the cluster state does change to Updating for few seconds before it comes back to Active.

Add a fourth controlplane node to the cluster and use --label color=red

After adding the fourth controlplane node, the original controlplane node and etcd node labels do not change.

The newly added control plane node has label - color=red

The label is seen set via kubectl get nodes  -o yaml

On adding a new label (not part of the original plane) on the control plane node/ etcd or worker nodes -- A reconcile does NOT happen

Could the fix(es) for this issue be backported to the 2.3 line?

This is backported into 2.3. Available to test on 2.3 head

@StrongMonkey Could you add the PR that was merged in  2.3 release to the issue ?

Validated backport on v2.3-head Rancher version 351ef07c6
Initial State after label edit:

Add cp, etcd and worker nodes (added one at a time):

Verified new labels do not reconcile. No screenshot here, but validated via server logs
Verified deleting nodes does not update labels

Not able to add the node using control plane context with etcd-controlplane not responding when label is given.
k label pod color=red  etcd-controlplane -n kube-system
error: all resources must be specified before label changes: etcd-controlplane


Reset Transport before Tests

Updates the InteractsWithMessenger trait to clear the TestTransport before each test, instead of after.
Previously, the transport was reset after each test in a TestCase using this trait. If other tests run first though which send messages, but do not make messenger assertions (as the transport is overridden for the entire test environment), then the transport isn't cleared at all, so the first test to run in a test case with this trait will have the state from the previous tests.
I don't know if there's currently a reason for having it specifically after, is this a BC break? Is there a better solution? Is there a test I can add or update to verify this behaviour?
(Also, I'm not sure if the test failures are related? I get them on the 1.x branch as well locally, #39 ?).

I believe #24 would also solve this issue but let's go with this PR for now.

Resetting before makes sense for the reason you describe. We should keep the @after though.
BTW, I merged #39, so if you rebase - the tests should pass.

Updated and rebased, thanks.


Add annotation to ignore code

As suggested by @RichardBradley add an annotation to ignore sections of code.

It might be worth adding a note to https://github.com/sksamuel/sbt-scapegoat#ignoring-files that you can ignore individual lines, so it's a bit more publicised.

I'm not seeing where ignoring individual lines is working.  I've got this:
@SuppressWarnings(Array("AsInstanceOf"))
val contentAssembly = Flow[CRec].map { crec =>
  (crec, expression.render(crec.value).asInstanceOf[Message[OutputWrapper]])
}

This compiles but still warns on .asInstanceOf.  Am I doing it wrong?

Without trying anything, the example above doesn't have a capital A: "asInstanceOf".
Does that fix your issue?

I'm afraid it didn't.  Tried cap and non-cap.  Compile worked but scapegoat still flagged the warning on .asInstanceOf


PetaLinux build process

Where can I find PetaLinux BSPs or configuration to build PetaLinux for platforms provided in this repository? At least I would expect a custom device-tree config to be provided for each platform.

@zohourih
petalinux build instructions are here: https://xilinx.github.io/kria-apps-docs/master/docs/build_petalinux.html
device tree overlay fragments are available here for each platform: https://github.com/Xilinx/kv260-firmware

@chkohn Thank you for the reply, I will check the documentation. Might be a good idea to put those links in the README of this repo, as well.


Spyder does not launch on windows 8 (Anaconda3-5.0.1-Windows-x86_64)

i tried to open syder using anaconda prompt
C:\Users\rahul>spyder --show-console
Assertion failed: Socket operation on non-socket (bundled\zeromq\src\select.cpp:185)
and i get the window popping showing "python stopped working"
i got the above error , i also tried reinstalling the anaconda and excluded Anaconda3 folder from virus scanning

Please deactivate your firewall/antivirus and try again.

Also, I am currently on Windows 8 x64 with Anaconda3 5.0.1 and Spyder 3.2.4 and 3.2.5, and have seen no similar issues. Accordingly, if we don't hear from you after a week (7 days), we'll assume the issue is resolved or unrelated to Spyder, and thus it will be closed. Thanks, and best of luck.

It works fine after after manupulating firewall and antivirus settings. Thanks....

My Spyder also does not open and crashes on startup (With the popup indicated python stopped working)
Error Message on running spyder from Anaconda Console:
(base) C:\Users\Dhiman>spyder
Assertion failed: Protocol wrong type for socket [10041] (C:\ci\zeromq_154902559
4292\work\src\ip.cpp:417)
[10040:2208:0421/105302.935:ERROR:broker_win.cc(59)] Error reading broker pipe:
The pipe has been ended. (0x6D)
I am using Spyder 3.3.3 and Windows 7 (64 bit). Please Help resolve the issue.

@ashish1610dhiman This issue has been resolved, closed and marked unrelated to Spyder for well over a year; and your error message is different from that in the original issue report. Therefore, you should not be posting that here.
Did you even try disabling any firewall, antivirus and any other security software you may have installed and trying to start Spyder again, which is exactly what the fixed the OP's issue? Other than that, the error Error reading broker pipe: The pipe has been ended.  has been reported many times before, with a variety of solutions which you should try (testing Spyder after each one):

conda update spyder spyder-kernels qtconsole
Uninstalling spyder-autopep8 or any other Spyder plugins
conda update pyzmq zeromq ipykernel jupyter_client ipython
conda install pyzmq=17
conda install pyopengl
conda update qt pyqt qtpy
Update your graphics drivers
Switch graphics cards
conda install pyqt=5.6

If none of that works, please open a new issue about your problem with all the requested information, and we'll try to help. Thanks, and best of luck.


run cat without anything

when run cat without any file
then ctrl + c
it return like this:

minishell>minishell>

if we run cat then Enter
the minishell would wait for user to type some thing
but each time user press enter
the out put will print
like this:
minishell>cat + Enter
mina + Enter
mina


fix 825

thank you - then it is ready.

the PR is out for that already

Sorry I missed, that thanks!


add techdocs.yml and update links

add techdocs.yml and update links
I have updated links for all the components, which fixes #404
I wrote the actions as well for publishing into techdocs which fixes #399, based on our discussion I have updated it to AWS S3 bucket. The techdocs will be published to s3
name: Publish TechDocs Site

on:
  push:
    paths:
      - 'docs/**'
      - 'mkdocs.yml'
    # branches:
    #   - main

jobs:
  publish-techdocs-site:
    runs-on: ubuntu-latest

    env:
      TECHDOCS_S3_BUCKET_NAME: ${{ vars.TECHDOCS_S3_BUCKET_NAME }}
      AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
      AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      AWS_REGION: ${{ secrets.AWS_REGION }}
      ENTITY_NAMESPACE: 'default'
      ENTITY_KIND: 'Component'
      ENTITY_NAME: 'argocd'

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - uses: actions/setup-node@v3
      - uses: actions/setup-python@v4
        with:
          python-version: '3.9'

      - name: Install techdocs-cli
        run: sudo npm install -g @techdocs/cli

      - name: Install mkdocs and mkdocs plugins
        run: python -m pip install mkdocs-techdocs-core==1.*

      - name: Generate docs site
        run: techdocs-cli generate --no-docker --verbose

      - name: Publish docs site
        run: techdocs-cli publish --publisher-type awsS3 --storage-name $TECHDOCS_S3_BUCKET_NAME --entity $ENTITY_NAMESPACE/$ENTITY_KIND/$ENTITY_NAME

Done please check


Specify the name for container port 8181

Container port does not have an associated name to it. It's used for prometheus scrapping jobs and traditionally is metrics

Thanks for reporting, we have automatically scraped metrics for EaseProbe by adding extraScrapeConfigs , and you can see them in Prometheus like

Does it meet your needs?

Not quite, my prometheus instance is deployed to another cluster and as a scrapper I use opentelemetry-collector. Either way, I'd prefer setting a scrapping job in collector's context via monitoring.coreos.com/v1 ServiceMonitor CRD, but it looks like it works with port names only


Added Vitruvian Man entry on the Art category

Please make a new PR using the naming convention described in the contributing doc. Also please pull and resolve conflicts with the latest updates


update changelog for 0.49

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (d70e570) 53.04% compared to head (81e19d6) 35.17%.

Additional details and impacted files
@@             Coverage Diff             @@
##             main     #394       +/-   ##
===========================================
- Coverage   53.04%   35.17%   -17.88%
===========================================
  Files          69       69
  Lines        5243     5243
===========================================
- Hits         2781     1844      -937
- Misses       1876     3091     +1215
+ Partials      586      308      -278

Flag
Coverage Δ

2.1
?

2.2
?

2.3
?

2.4
?

2.5
?

2.6
?

2.7
?

2.8
?

3.0
?

3.1
?

3.2
?

3.3
?

3.4
?

community
35.17% <ø> (-3.17%)
:arrow_down:

enterprise
?

enterprise-nightly
?

integration
35.17% <ø> (-17.88%)
:arrow_down:

nightly
35.17% <ø> (-2.47%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


python311Packages.aiocomelit: 0.3.0 -> 0.3.1

Diff: https://github.com/chemelli74/aiocomelit/compare/refs/tags/v0.3.0...v0.3.1
Changelog: https://github.com/chemelli74/aiocomelit/blob/0.3.1/CHANGELOG.md
Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 265794 run on x86_64-linux 1

5 packages built:

home-assistant-component-tests.comelit
python310Packages.aiocomelit
python310Packages.aiocomelit.dist
python311Packages.aiocomelit
python311Packages.aiocomelit.dist


Can you add binary builds for FreeBSD?

FreeBSD will force me to install a big llvm package which will cost me about 2 to 3 GB of disk space when installed only to have clangd. The lite flavor of the llvm package doesn't include clangd.

Duplicate of #1265.


Modal Submission not sending field data

Hello, I'm having issues propagating field data from a modal into the InteractionModalSubmit event. For some reason, only the custom_id is being passed through, with none of the data from the TextInputs that I included in the modal.
My modal code:
&discordgo.InteractionResponse{
	Type: discordgo.InteractionResponseModal,
	Data: &discordgo.InteractionResponseData{
		CustomID: "time-txt",
		Title:    "Change Time",
		Components: []discordgo.MessageComponent{
			discordgo.ActionsRow{
				Components: []discordgo.MessageComponent{
					discordgo.TextInput{
						CustomID:    "txt-date",
						Style:       discordgo.TextInputShort,
						Required:    true,
						Label:       "Date",
						Value:       opts.Date,
						Placeholder: "YYYYMMDD",
						MinLength:   8,
						MaxLength:   10,
					},
				},
			},
			discordgo.ActionsRow{
				Components: []discordgo.MessageComponent{
					discordgo.TextInput{
						CustomID:    "txt-time",
						Style:       discordgo.TextInputShort,
						Required:    true,
						Label:       "Time",
						Value:       opts.Time,
						Placeholder: "HH:MM:SS",
						MinLength:   5,
						MaxLength:   8,
					},
				},
			},
		},
	},
}

And the part of the JSON-encoded InteractionModalSubmit message where I would have expected the components to be included in the response:
{
    "id": "1216086183621427310",
    "application_id": "927342248117538816",
    "type": 5,
    "data": {
        "custom_id": "time-txt"
    },

    ...
}

Shouldn't this include a components field containing the components that were submitted? Or am I looking in the wrong place?

Ah, it appears as though components is just excluded from all JSON encoding. Actually trying to retrieve the components from the Components array shows that they are in fact there!


Where can this app be deployed

Hi,
Sorry for my ignorance here
The image is 6.6 gb which is huge.
Because of the size I am unable to push the image to our Nexus repo
So my questions are
Any idea if the size can be reduced?
Where can I deploy the app?

Hi. The image produced by the Dockerfile is huge since it installs an enormous amount of stuff, which makes it unsuitable as a deployment target.
This weekend I changed the process to use Bazel to produce the images. If you look at my latest Jenkinsfile you'll see the update: https://github.com/thelgevold/angular-samples/blob/master/Jenkinsfile
There are now two images created, one for the node app, and one for the Java api. Both are considerably smaller.  The container_push  rules in the BUILD files can be updated to point to different registries.
I deployed both images to azure here: http://angular-samples.azurewebsites.net/#/demo/react

Closing as this is solved through the new approach.


Not auto focusing to the required Input inside Workspace page

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Go to the workspace
Click on the invite button
Email or Phone Input will not be focused

Expected Result:
It should be focused
https://user-images.githubusercontent.com/28243942/127534906-e4ec39da-2884-4674-925e-a43e172d2d72.mp4
Actual Result:
https://user-images.githubusercontent.com/28243942/127533413-db938110-c69f-4f91-b396-5272796b2269.mp4
Workaround:
Visual/UX
Platform:
Where is this issue occurring?

[x] Web
[ ] iOS
[ ] Android
[ ] Desktop App
[ ] Mobile Web

Version Number:
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
View all open jobs on Upwork

Triggered auto assignment to @alexpensify (AutoAssignerTriage), see https://stackoverflow.com/c/expensify/questions/4749 for more details.

Proposal

We can create a ref element for Phone or Email Input and then add focus using the below code after line 89 (With some other required changes on other places)

            <ScreenWrapper onTransitionEnd={() => {
                if (this.emailOrPhoneInputRef) {
                    this.emailOrPhoneInputRef.focus();
                }
            }}
            >

https://github.com/Expensify/App/blob/d26de0563905d6b5fb4a8d2a6696030ba15a9678/src/pages/workspace/WorkspaceInvitePage.js#L89

The workspace feature is still in beta. There would be more pages coming to Workspaces. If you like to fix this, it's good if you can check other pages and fix them all.

@parasharrajat let me know if it's happening on any other page.
Currently I can see this behaviour only on this page

Triggered auto assignment to @stitesExpensify (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

@aman-atg your proposal sounds good to me. @alexpensify can we get an upwork job spun up for this?

Triggered auto assignment to @marklouisdeshaun (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

Job posted to Upwork

Triggered auto assignment to @marcaaron (Exported), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

Sorry for the delay here. I have left an initial review @aman-atg. Let me know when updates are made, thanks.

Paid in Upwork because it's been over 7 days since merge yet before our 7 days after production update for payment.  Added bonus for reporting the issue

Forgot to close....


Store additional by-iteration information for reuse in plots and subsequent analysis

@cbayly13 has been monitoring a variety of information and is thinking about plotting this type of info in various ways. He would at least like to have access to, at each iteration:

number of parameters (patterns)
score

He wants to end up with these in a pandas data frame to be able to do things like plot the number of patterns versus score, number of patterns versus iteration, score versus iteration, and so on. This has some overlap with issues raised in #3 and would implement one of the ideas in #15 .
The end goal is for him to end up with this in a pandas data frame, but I'm ambivalent at this point as to what the intermediate format would be. Currently he's running awk on log files (as output to the screen) which doesn't seem like the best longer-term solution.

@davidlmobley
I think this has been sufficiently addressed with store typenames and parents in the trajectory files so we could use them to rebuild scores for individual types, the total score, parent trees, etc.
I'm closing for now.


NPM packages containing ".js" in the name are not supported

Steps to reproduce
Add import * as BN from "bn.js"; console.log(BN); to a file and try to build it
What is expected?
The build command should work
What is actually happening?
Potential Causes:
1.This kind of module is not supported, you may need plugins to support it.
, Can not load `./node_modules/bn.js`. Original error:
Some(GenericError("Os { code: 21, kind: IsADirectory, message: \"Is a directory\" }")).

System Info
System:
    OS: macOS 14.2.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 1.05 GB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.18.2 - ~/Library/Caches/fnm_multishells/5714_1707992194832/bin/node
    Yarn: 4.0.2 - ~/Library/Caches/fnm_multishells/5714_1707992194832/bin/yarn
    npm: 10.2.4 - ~/Library/Caches/fnm_multishells/5714_1707992194832/bin/npm
    pnpm: 8.15.3 - ~/Library/Caches/fnm_multishells/5714_1707992194832/bin/pnpm
    bun: 1.0.26 - ~/.bun/bin/bun
  Browsers:
    Chrome: 117.0.5938.149
    Safari: 17.2.1

Any additional comments?
I'm including this in my config as a workaround for now
export default defineConfig({
  compilation: {
    resolve: {
      alias: {
        "bn.js$": "bn.js/lib/bn.js",
      },
    },
  },
});

hi @johnrees I tried to reproduce your problem, but I didn't reproduce it. Could you provide your configuration file?
After I tried to configure it on my windows and macos, I could build it successfully.
import { defineConfig } from "@farmfe/core";

export default defineConfig({
  compilation: {
    input: {
      entry: "test.js",
    },
    output: {
      targetEnv: "node-next"
    },
    resolve: {
      alias: {
        "bn.js$": "bn.js/lib/bn.js",
      },
    },
  },
})

That's may be a issuee related to resolve. I'll take a look.

fixed in<EMAIL_ADDRESS>


Why is the image not in the center of the qr ? It is one pixel to big :|

Answer : It was actually covered by a QR code common pattern on top and left.
So it's ok, I just changed the padding size to fit right inside these patterns. Great.


Minor warning clean-up

Warnings were occurring due to:

VECTOR_PTR being deprecated and thus invoking never-type !, so it is removed
Various places where unreachable is called, but now we can just use ! instead.

This is meant to be a quick PR that relaxes some of the nuisance that comes up..

R-devel changed things, so this is why this is failing.
If anyone has ideas for this, we can try it out? Otherwise, we can close it for now.

See an overview of Rf_Errors to see why all devel versions return () instead of !.
https://github.com/extendr/libR-sys/issues/144#issuecomment-1455256822

Hmm, no idea, sorry. I need to figure out what causes this difference first.
https://github.com/extendr/libR-sys/issues/144#issuecomment-1455256822

My number one suspect is which clang version is being used to generate the bindings.
If I look at the bindings:
bindings\bindings-windows-x86_64-R4.2.rs:
  340  extern "C" {
  341:     pub fn Rf_error(arg1: *const ::std::os::raw::c_char, ...) -> !;
  342  }

Alright, my PC is on this platform, so when I generate bindings using the --features use-bindgen, I produce a file named mybindings\bindings-windows-x86_64-R4.2.rs and this file contains:
extern "C" {
  pub fn Rf_error(arg1: *const ::std::os::raw::c_char, ...);
}

My number one suspect is which clang version is being used to generate the bindings.

What's curious is that even on a same platform it generates different signature. Windows might be affected by the change on Rtools, so let's focus on Linux for example.
bindings/bindings-linux-x86_64-R3.6.rs:    pub fn Rf_error(arg1: *const ::std::os::raw::c_char, ...);
bindings/bindings-linux-x86_64-R4.0.rs:    pub fn Rf_error(arg1: *const ::std::os::raw::c_char, ...);
bindings/bindings-linux-x86_64-R4.1.rs:    pub fn Rf_error(arg1: *const ::std::os::raw::c_char, ...) -> !;
bindings/bindings-linux-x86_64-R4.2.rs:    pub fn Rf_error(arg1: *const ::std::os::raw::c_char, ...) -> !;
bindings/bindings-linux-x86_64-R4.3-devel.rs:    pub fn Rf_error(arg1: *const ::std::os::raw::c_char, ...);

The bindings for R 3.6 and R 4.0 were generated with an older version before I bumped the version of bindgen, so it should matter (actually, bindgen started to support no return attributes only half a year ago). But, it's weird that the signature of R 4.3 is different than the ones of R 4.1 and R 4.2. All of these three versions keep updated by our CI.
I suspect this might be related to the update of C++ standards that R 4.2 supports. As I'm not a C/C++ person, I'm not very confident, of course.

This might matter, maybe?
https://github.com/r-devel/r-svn/commit/1831a08c4848475a4554a80d4352d1016a548b98

It seems bindgen cannot handle _Noreturn?
__attribute__((noreturn)) void foo1();
_Noreturn                 void foo2();

❯ bindgen tmp.h
/* automatically generated by rust-bindgen 0.64.0 */

extern "C" {
    pub fn foo1() -> !;
}
extern "C" {
    pub fn foo2();
}

❯ bindgen tmp.h --enable-function-attribute-detection
/* automatically generated by rust-bindgen 0.64.0 */

extern "C" {
    pub fn foo1() -> !;
}
extern "C" {
    pub fn foo2() -> !;
}

Using .enable_function_attribute_detection() fixes some of the signatures,
https://github.com/extendr/libR-sys/compare/master...yutannihilation:tmp1
but it's still less than when I manually define NORET.
https://github.com/extendr/libR-sys/compare/master...yutannihilation:tmp2
No idea which is better (and even what the first option does)...

I now feel defining NORET by ourselves because okay as we only use it for generating the bindings anyway.
https://github.com/extendr/libR-sys/pull/148

This can now be merged, as extendr/libR-sys#148 has been merged and this PR passes CI.


Beta testing support

Saw this mentioned previously but only response was saying to just try.  I haven't had any success with the desktop app recognizing the build when it is archived.  It works when I use the native crashlytics beta code not with the plugin.   Is this supported and I am doing it wrong?

Unless I'm misunderstanding you, what you are describing is a function of the Fabric desktop app and XCode, not of the plugin.
To distribute an app on Crashlytics Beta:

ionic prepare ios
open platforms/ios/YourApp.xcodeproj
Run app from XCode and verify that it shows up in the Fabric web console
Product > Archive
The archive will show up in the Organizer (Window > Organizer in XCode)
Open Fabric desktop app
Click the Active drop down on the Beta/Distribute tab and switch it to Archives
Click the Distribute button next to the archive to upload to Crashlytics Beta

Those are the exact steps i've been following.. Only difference is my app never shows up in the web console and after i attempt to archive it don't give the option to distribute.   If I use the native plugin It works no problem.


Quick fix for issue #22

Thanks a lot @malcolm-brooks ! I've tagged v1.0.9 with this change and pushed it to PyPI.


Editor crashes at opening the project

Godot version:
268f32bad
OS/device including version:
Windows 10 / Nvidia GeForce GTX 1080 Ti (457.30) / Vulkan
Issue description:
Editor crashes after opening any project, even empty one.

Error:

ERROR: Condition "p_ptr == nullptr" is true.
at: free_static (core\os\memory.cpp:149)

Crash appeared somewhere after commit ad0f1c6.
Steps to reproduce:
Compile the editor with MinGW and open any project.
Compile parameters: scons -j24 platform=windows bits=64 use_mingw=yes debug_symbols=no use_lto=yes tools=yes target=release_debug
Minimal reproduction project:
N/A, crashes even on empty project.

This also happens to me in mono occasionally. To solve it I must delete the folder ".mono".
Although perhaps his version is not mono.

This also happens to me in mono occasionally. To solve it I must delete the folder ".mono".
Although perhaps his version is not mono.

@Torguen no, this is classic version, mono version even fails to compile on MinGW for me.
Also, tried these three (1, 2, 3) versions, got the same result.

@Torguen no, this is classic version, mono version even fails to compile on MinGW for me.
Also, tried these three (1, 2, 3) versions, got the same result.

Can you check if still happens?
I'm almost sure that https://github.com/godotengine/godot/pull/45646 fixes it.

Can you check if still happens?
I'm almost sure that #45646 fixes it.

Currently i can't even compile the engine with GCC (crashes at linking stage) at all, so i'm using LLVM-MinGW instead, which compiles and runs everything OK.

Does it still happen in 4.0 alpha7?

Kinda, can compile with MinGW from MSYS2 with parameters from first post, but editor closes instantly without any error, here's link with compiled (commit d38d05c) editor.

And what about official alpha?
Did you try using a debugger?

Latest official alpha works fine.
And no, i didn't tried to use a debugger.

If the official alpha works then it's some build-specific issue.

Tried making a build with almost same parameters but with llvm-mingw.
Failed with an error:
> scons platform=windows bits=64 use_mingw=yes debug_symbols=no use_lto=yes tools=yes target=release_debug
scons: Reading SConscript files ...
Auto-detected 24 CPU cores available for build parallelism. Using 23 cores by default. You can override it with the -j argument.
Using MinGW, arch x86_64
Building for platform "windows", architecture "x86_64", editor, target "release_debug".
Checking for C header file mntent.h... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
[ 96%] Linking Program bin\godot.windows.opt.tools.x86_64.exe ...
[ 98%] =====
[ 98%] clang-14: error: unsupported argument '23' to option 'flto='

=====
[100%] progress_finish(["progress_finish"], [])
[100%] scons: *** [bin\godot.windows.opt.tools.x86_64.exe] Error 1
scons: building terminated because of errors.
[Time elapsed: 00:00:14.757]

The above might be unrelated bug.
So after checking code, I tried replacing use_mingw=yes with use_llvm=yes.
Failed with another error:
> scons platform=windows bits=64 use_llvm=yes debug_symbols=no use_lto=yes tools=yes target=release_debug
scons: Reading SConscript files ...
Auto-detected 24 CPU cores available for build parallelism. Using 23 cores by default. You can override it with the -j argument.
Using MinGW, arch x86_64
Building for platform "windows", architecture "x86_64", editor, target "release_debug".
Checking for C header file mntent.h... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
[ 96%] Linking Program bin\godot.windows.opt.tools.x86_64.llvm.exe ...
[100%] progress_finish(["progress_finish"], [])
[100%] =====
ld.lld: error: undefined symbol: thread-local initialization routine for Thread::caller_id
>>> referenced by servers\rendering\rendering_server_default.cpp
>>>               libservers.windows.opt.tools.x86_64.llvm.a(rendering_server_default.windows.opt.tools.x86_64.llvm.o)
>>> referenced by core\io\resource_loader.cpp
>>>               libcore.windows.opt.tools.x86_64.llvm.a(resource_loader.windows.opt.tools.x86_64.llvm.o)
>>> referenced by core\debugger\remote_debugger.cpp
>>>               libcore.windows.opt.tools.x86_64.llvm.a(remote_debugger.windows.opt.tools.x86_64.llvm.o)
>>> referenced 10 more times
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)

=====
scons: *** [bin\godot.windows.opt.tools.x86_64.llvm.exe] Error 1
scons: building terminated because of errors.
[Time elapsed: 00:00:14.716]

Works perfectly without use_lto=yes.

If possible, please submit at a backtrace of the crash so we can take a look.

@Anutrix For your build issue, you did need use_llvm=yes so that the right LTO config is passed. Then the second build likely fails due to pre-existing build objects being invalid. A build from scratch might work.
Official builds do use LTO, albeit from GCC.

I tried it on Windows 11 with llvm-mingw with same command as in issue description: scons -j24 platform=windows bits=64 use_mingw=yes debug_symbols=no use_lto=yes tools=yes target=editor on master build. Only target changed and it compiled fine.
I started and ran a project and it worked too.
Is this still valid in master?

This issue is a bit too old and broad to be actionable nowadays, it's quite likely that the problem has been fixed long ago.


Cursor is missing when window focus is changed

I'm using Atom version: 0.121.0 for Linux(Manjaro), this problem wasn't happening on the previous version.
I tried to run atom --safe but the problem persist.
The cursor is gone but I still have the line highlighted.
These are the steps I follow to reproduce the error:

Change windows with ALT+TAB and set the focus to this other window, also using ALT+TAB go back to Atom, the cursor is gone.

If I make this process but instead of ALT+TAB I click on the window button on my panel, it works because on each click I'm also setting the focus to the window.

Well I'm still experiencing this issue when I switching windows with Alt+Tab. Well I can still type, but I don't see the blinking cursor. Have to reach out for my mouse and click in text every time to get it back.
Atom ver: v0.169
System: Linux Mint 13 (Maya, Ubuntu 12.4 based distro)

Atom ver: v0.177.0
I experimented with this in XMonad.

(Broke) Cursor disappears when

Switching windows in "full mode" cursor also does not resumes blinking.
Switching workspaces and come back, cursor does not resume blinking.

Perhaps this is a bug related to when the window is gone (like minimized, other workspace, etc...)

Atom ver: v0.177.0
System :  ArchLinux
Desktop Env : KDE 14.12 with Plasma5
I have the same issue when doing , the cursor disappears.

Issue appears on Xubuntu when switching windows using ALT TAB.
Distribution info:
Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.2 LTS
Release:	14.04
Codename:	trusty

Atom version:
Atom 0.190.0

Would be great if this could be fixed. It's mainly just really annoying...

+1
Den 09/04/2015 8.41 AM skrev "Ruben Thijssen (@rubenthijssen)" <
<EMAIL_ADDRESS>
Issue appears on Xubuntu when switching windows using ALT TAB.
Distribution info:
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:    14.04
Codename:   trusty
Atom version:
Atom 0.190.0
Would be great if this could be fixed. It's mainly just really annoying...
—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/3278#issuecomment-91128354.

This issue still occurs in Atom 0.196.0 running on Debian 8 with Gnome 3.14.
The cursor disappears when switching workspaces, regardless of the tree view state. Alternating between windows in the same workspace (alt+tab) makes it appear again.

I think this issue is being ignored since it's closed.

Issue appears for me on Mac OS X 10.10 running Atom 0.201.0. Only happens when simply clicking from one tab to another. Cursor disappears and editor doesn't seem to be focused. However, switching tabs using Alt+Tab or keybindings (Cmd+Shift+[ or ]) works fine.

Then it has something to do with focus events.

Still the problem on plasma-desktop 5.3.1 :/
Even with CTRL TAB, Atom dont get back the focus.
Yes @rustedwolf I think it's related to focus event.

This issue just started occurring for me after a recent update. Same version and env as @seanCodes.

I have the same problem on OSX 10.10, atom version 0.211, but only when Atom is fullscreen.
Steps to reproduce:

make atom window fullscreen
cmd+tab to another open app
cmd+tab back to atom
typing works, but cursor is not on screen

Workaround:

make atom window fullscreen
cmd+tab to another open app
cmd+tab back to atom, but hold alt before releasing cmd and tab
cursor is now appearing on screen.

I have this problem on Ubuntu 14.04 (xfce4) and Atom 1.0.0
Steps to reproduce:
Use CTRL+ALT+Left to switch to another workspace.
Use CTRL+ALT+Right to switch to workspace with Atom
Typing works but cursor is invisible.
Hiding the tree view reveals the cursor, unhiding the tree hides the cursor.
Workaround
Use CTRL+TAB or ALT+# to switch to another tab, cursor is revealed.
Workaround
Click anywhere in the editor window, cursor appears at that position

I also have this issue. I'm on XFCE. After switching desktops back to the atom editor, I can interact with atom via my keyboard, but the cursor has disappeared. Doesn't reappear until I click it with my mouse.

Somebody knows how to fix it? the editor is really good but that little error make the coding really annoying.
Thanks

When I add this to ~/.atom/styles.less, I can work normally
atom-text-editor:not(.mini)::shadow .cursor {
opacity: 1;
}
atom-text-editor:not(.mini)::shadow .blink-off .cursor {
opacity: 0;
}

@apowers

Press ALT+TAB twice to switch to another application in the same workspace and switch back to Atom. This isn't a reliable fix, sometimes it works and sometimes it doesn't work unless you press F11 to toggle full screen first.

For me, if my mouse is over atom when switching back to it, the cursor disappears -- if my mouse is outside the atom window when switching back to it, the cursor appears.
Kubuntu 14.04
Atom 1.0.3

This looks like the same issue as https://github.com/atom/atom/issues/3622 – closing in favor of that issue because it has more comments and helpful GIFs.


GH-39-44: Template Changes

Resolves #39
Resolves #44
Remove convert from method names.
Add missing methods - no key.
Also remove log4j.properties from test jar.

LGTM, but the Reference Manual should be addressed as well.

Oops - yes, of course :smile:

Pushed - I'd appreciate this being merged ASAP - I have an s-i-k PR in the wings, waiting for this :smile: Thanks.

Can you just add the flush() and fix the two typos?
Thanks

Merged as https://github.com/spring-projects/spring-kafka/commit/dc19f0cd89d114b747c451280c530e1af474a563


chore: update release branch with latest master

we need changes in release pipeline there in release branch

Not included in release 2.1 yet, 2.1 was mistakenly triggered by our automation.


Implement PageVisibility API

I need this for a project I'm working on, so I implemented it. The code is pretty straightforward.
Quick example:
module Main where

import Graphics.Element exposing (show)
import PageVisibility as PV

main : Signal Graphics.Element.Element
main =
  Signal.map show <| Signal.foldp (::) [] PV.state

I'm not to crazy about keeping this as I've implemented it, because it's done somewhat specifically to my needs, so feel free to make whatever changes you like :)

This library is not released. I am working on a few things for 0.17 that are a work in progress. So this is not how this library is going to look in the end. Folks gotta be patient!

I knew this was not released. I wasn't being impatient, actually, I'm just using this code right now in production, so I wanted to share it with you in case it saved you some work. I'm sorry.