text:
Avoid context propagation from agent threads and Executors

Disabling context propagation from agent threads and when submitting tasks/runnables/callables to agent executors.
This started by investigation of CI flakiness at CommonsExecAsyncInstrumentationTest (example: https://apm-ci.elastic.co/job/apm-agent-java/job/apm-agent-java-mbp/job/main/313/) that is apparently related to our test causing metadata to start threads on which they execute processes for metadata discovery (eg uname -n), which invokes our process instrumentation and so forth.
But besides eliminating test issues, IIANM such exclusion of context propagation on agent threads is the right thing to do anyway.

:green_heart: Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2022-07-25T13:14:12.772+0000

Duration: 54 min 42 sec

Test stats :test_tube:

Test
Results

Failed
0

Passed
3054

Skipped
36

Total
3090

:green_heart: Flaky test report
Tests succeeded.
:robot: GitHub comments
To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.

run benchmark tests : Run the benchmark tests.

run jdk compatibility tests : Run the JDK Compatibility tests.

run integration tests : Run the Agent Integration tests.

run end-to-end tests : Run the APM-ITs.

run windows tests : Build & tests on windows.

run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

authors: apmmachine eyalkoren

repo: elastic/apm-agent-java


text:
Fixed custom_metrics_histogram_boundaries config to not be dynamic.

What does this PR do?
The newly added custom_metrics_histogram_boundaries option should not be dynamic, see this spec comment.
No need to update the changelog IMO because the feature has not been part of any release yet.
Checklist

[x] This is something else

[ ] I have updated CHANGELOG.asciidoc

:grey_exclamation: Build Aborted

There is a new build on-going so the previous on-going builds have been aborted.

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2023-03-21T09:37:40.539+0000

Duration: 9 min 16 sec

:robot: GitHub comments
Expand to view the GitHub comments

To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.

run benchmark tests : Run the benchmark tests.

run jdk compatibility tests : Run the JDK Compatibility tests.

run integration tests : Run the Agent Integration tests.

run end-to-end tests : Run the APM-ITs.

run windows tests : Build & tests on windows.

run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

source: gharchive/pull-request

authors: JonasKunz apmmachine

license_type: permissive

license_source: github-api


text:
Update CLOUD_PROVIDER for new valid options

Ref https://github.com/elastic/apm/issues/289

Also refs #822

:green_heart: Build Succeeded

Expand to view the summary

Build stats

Build Cause: [Pull request #878 opened]

Start Time: 2020-07-01T15:27:53.900+0000

Duration: 27 min 40 sec

Test stats :test_tube:

Test
Results

Failed
0

Passed
10672

Skipped
7953

Total
18625

authors: apmmachine basepi

repo: elastic/apm-agent-python


text:
IHttpContextAccessor not available in netstandard

ECS integration/library project(s) (e.g. Elastic.CommonSchema.Serilog): Elastic.CommonSchema.Serilog
ECS schema version (e.g. 1.4.0): 8.6.1 (but also older ones)
ECS .NET assembly version (e.g. 1.4.2):  8.6.1 (but also older ones)
Elasticsearch version (if applicable): n/a
.NET framework / OS: net6.0
Description of the problem, including expected versus actual behavior:
Elastic.CommonSchema.Serilog contains a couple extension methods that add HTTP context to the Serilog structured log properties. It uses the IHttpContextAccessor interface to do this for .net standard and .net core. However, the IHttpContextAccessor interface is only available in the aspnetcore framework, not in dotnet standard, and not available in a nuget package. In the distant past, there actually WAS a nuget package for this: https://www.nuget.org/packages/Microsoft.AspNetCore.Http.Abstractions. However, these packages have long since been deprecated, and they pull in transitive dependencies that are full of vulnerabilities, such as System.Text.Encodings.Web (version 4.5).
In today's modern development, many organizations have nuget proxies that scan for vulnerabilities and prevent packages with severe vulnerabilities from being pulled by package managers. Nexus-IQ is one such tool.
Our workaround is to explicitly reference a newer version of System.Text.Encodings.Web, and causes the nuget dependency resolver to only pull the newer version.
Steps to reproduce:
Assumption: There is a mechanism in place that prevents pulling the System.Text.Encodings.Web (version 4.5) nuget package.

Create a simple dotnet 6 application
Add a reference to Elastic.CommonSchema.Serilog
Run dotnet restore. You will see in the logs that it tries to pull System.Text.Encodings.Web.4.5, which is prevented by the above assumption.

In our minds, because the Elastic.CommonSchema.Serilog project references deprecated nuget package, it is not truly netstandard compatible. However, we realize targeting only net6.0, etc... would be problematic for netstandard libraries. Our proposal is the following:
Split the classes referencing IHttpContextAccessor into another project (called Elastic.CommonSchema.Serilog.AspNetCore?), and this new project would only target .net FW and .net core. Any assembly consuming this new package would be inherently an aspnetcore project, so it should cause no problems. Only the correct version of the System.Text.Encodings.Web package will be pulled.

I'm surprised this issue hasn't even been addressed.
We too wanted to upgrade from the Serilog.Formatting.Elasticsearch NuGet to the new Elastic.CommonSchema.Serilog but can't because these deprecated dependencies fail the vulnerability scan.

source: gharchive/issue

repo: elastic/ecs-dotnet


text:
Unable to install js plugin in ES 2.0

I get this error when installing
NOTE: Unable to verify checksum for downloaded plugin (unable to find .sha1 or .md5 file to verify)
ERROR: Could not find plugin descriptor 'plugin-descriptor.properties' in plugin zip
checked the jar, it has es-plugin.properties file instead of plugin-descriptor.properties, is there some way to get it working

This plugin has moved to the core Elasticsearch repo in 2.0. You can install it with:
bin/plugin install lang-javascript

authors: clintongormley sumitjainn

repo: elastic/elasticsearch-lang-javascript

license_source: bigquery


text:
Serialization / Deserialization performance problems on .Index operation

I've downloaded "elasticsearch-net-example-master" and when I run NuSearch.Indexer project every insert runs more than 500ms, but if I execute same request from postman it runs around 20ms.
I've run performance analysis on var result = Client.Index(package); method and from what I see, 90% of time is taken by serialization / deserialization.
Can this be improved?
Please find in the attachment performance report.
NuSearch.Indexer160331.zip

If you profile its hard to distinguish between first request and subsequent requests, its true that the very first call carries a significant overhead, JSON.NET (and to be fair certain bits of NEST too) rely heavily on cached reflection which need to be warmed once per app domain.
If I hack nusearch from elasticsearch-net-example
by adding this class:
public class Timings
{
	public TimeSpan CLientTime { get; set; }
	public TimeSpan SerializationTime { get; set; }

	public override string ToString() => $"{(long)(CLientTime.TotalMilliseconds)}ms => {(long)(SerializationTime.TotalMilliseconds)}ms";
}

Setting CallMetrics() on ConnectionSettings and adding some stopwatches around the call:
var sw = new Stopwatch();
foreach (var package in packages)
{
	sw.Restart();
	var result = Client.Index(package);
	sw.Stop();
	var metrics = result.ConnectionStatus.Metrics;
	var serializationTime = TimeSpan.FromMilliseconds(metrics.SerializationTime + metrics.DeserializationTime);
	var timing = new Timings { CLientTime = sw.Elapsed, SerializationTime = serializationTime };
	Console.WriteLine(timing);

I'm seeing the following pattern:
239ms => 130ms
9ms => 0ms
6ms => 0ms
8ms => 0ms
6ms => 0ms
7ms => 0ms
6ms => 0ms
6ms => 0ms
6ms => 0ms
6ms => 0ms
6ms => 0ms
6ms => 0ms
7ms => 0ms
9ms => 0ms
6ms => 0ms
6ms => 0ms
7ms => 0ms
6ms => 0ms
6ms => 0ms
7ms => 0ms
...etc....

Which I think are acceptable numbers. Here its 240ms but i've seen them in the range 500ms-1s depending on the machine.
Long term we are working on generating the (de)serialization of known bits of the API to minimize allocations and squeeze more performance and hopefully keep that first hit to a minimum,

That's totally acceptable.
Maybe, this is because of configuration or something else.
This is what I get:
714 --first request
511
512
511
510
511
511
501
510
501
511
511
511
511
507
510
510
510
511
etc

Mind sharing your code and connectionsettings? If you run nusearch with fiddler open, its configured to automatically route requests through fiddler, does that surface anything?

This is the connection:
public static class NuSearchConfiguration
{
private static readonly ConnectionSettings _connectionSettings;
	public static string LiveIndexAlias { get { return "nusearch"; } }
	public static string OldIndexAlias { get { return "nusearch-old"; } }

	public static Uri CreateUri(int port)
	{
		var host = "localhost";
		if (Process.GetProcessesByName("fiddler").Any())
			host = "ipv4.fiddler";

		return new Uri("http://" + host + ":" + port);
	}

	static NuSearchConfiguration()
	{
		_connectionSettings = new ConnectionSettings(CreateUri(9200)).SetDefaultIndex("nusearch");
	}

	public static ElasticClient GetClient()
	{
		return new ElasticClient(_connectionSettings);
	}

	public static string CreateIndexName()
	{
		return string.Format("{0}-{1:dd-MM-yyyy-HH-mm-ss}", LiveIndexAlias, DateTime.UtcNow);
	}
}

Rest is same as in example.

I've tried this on another server. Everything works OK. Same code.

Try specifying DisableAutomaticProxyDetection on ConnectionSettings on the server thats misbehaving.
Thanks for reporting back!

Thnx. Great

authors: Mpdreamz amelmusic

repo: elastic/elasticsearch-net


text:
Possible socket starvation due to non-static HttpClient

I have a long running .NET core 2.2 application running in a container in AWS. It received a lot of requests and indexes stuff in elasticsearch via the Client.Index(...) method.
The container has rising memory usage and in the end, restarts because heartbeats from external services are not received.
After debugging this for days, I narrowed it down to the nest client, specifically the usage of HttpClient in HttpConnection.cs.
In HttpConnection.cs, the method GetClient(...) maintains a dictionary of HttpCliens which is reused. This is not as per Microsoft guidelines and is causing socket starvation. A few reads on the topic:

https://docs.microsoft.com/en-us/aspnet/web-api/overview/advanced/calling-a-web-api-from-a-net-client#create-and-initialize-httpclient
https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

So I forked this repo, and did a simple test where I'm reusing a static HttpClient across all calls. This fixed the problem and the service is now completely stable.
What are your thoughts on this?

Firstly, thanks for opening @ThomasVestergaard.
Could you provide some more information about the .NET core application:

Runtime version
OS platform host - you mention container, so sounds like a Linux distro. Would you also be able to provide details about the container environment, version, etc. too?

The dictionary of HTTP clients should be caching HttpClient instances for the lifetime of the HttpConnection, which should be a singleton tied to a singleton ConnectionSettings and ElasticClient
https://github.com/elastic/elasticsearch-net/blob/01047d93faf31e2f31cca811999a8337ca368a93/src/Elasticsearch.Net/Connection/HttpConnection.cs#L130-L151
The key for the dictionary is determined from:
https://github.com/elastic/elasticsearch-net/blob/01047d93faf31e2f31cca811999a8337ca368a93/src/Elasticsearch.Net/Connection/HttpConnection.cs#L274-L286
A few initial thoughts come to mind:

Are you varying any of the components of RequestData with each request that would constitute multiple HttpClient instances to be created?
Are you using custom TCP Keep Alive values on ConnectionSettings.EnableTcpKeepAlive(...)?
Are you configuring a higher connection limit using ConnectionSettings.ConnectionLimit(...)? The default connection limit is set to the processor count when the underlying HttpClientHandler is System.Net.Http.CurlHandler, and 80 for all others. We have experienced System.Net.Http.CurlHandler not reusing TCP connections previously (#2784) so set a very conservative connection limit.

Any additional detail that you can provide will be super useful. If you have a repro that clearly replicates what you're seeing, that would be even more awesome!

Hi @russcam
Thanks for the rapid reply on this.
I will try to make a repo where I replicate the issue where all of your questions are answered. Will get back to that later.
Meanwhile, it seems a HttpClientFactory has been introduced in .net core 2.1 which is addressing this exact issue.
https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/implement-resilient-applications/use-httpclientfactory-to-implement-resilient-http-requests
I will try to do a test with the HttpClientFactory as well.

Thank you! We have full intentions of moving over to HttpClientFactory where possible 😃

I have the same issue it seems using ElasticClient within durable functions in Azure. I am getting SocketExceptions after a few successful requests. @ThomasVestergaard, please let me know the solution if you find one.

@russcam Sorry for the very late reply on this.
Today i experienced this with the fix from earlier:

So maybe my issue is not tied to elasticsearch after all.
I think it might be best to close this issue until I get to the bottom of this. Right now I can't rule out anything.

@ThomasVestergaard Did you send an email reply saying to close this for now?

@russcam Sorry for the very late reply. Yes I did - It was a comment on this thread which I deleted again. I have been debugging this on and off for a while and I'm getting inconsistent results, so no conclusion yet. I think it's best to close this for now. I'll reopen if I get something concrete to look at.

Thanks @ThomasVestergaard. Feel free to reopen if you get to something concrete 👍

Just a thought: could this be connected to https://github.com/dotnet/corefx/pull/32793? Socket starvation and a memory leak could perhaps be related. More information: https://github.com/dotnet/corefx/issues/37044#issuecomment-500660152 and https://github.com/dotnet/corefx/issues/31262 .

authors: StephaneBischoff ThomasVestergaard roelandvh russcam


text:
Remove generic on async search status response

As titled, this removes the generic type on the status response for async search which is not used in the body.
Also, completion_status should be optional as it's only returned for non-running searches.
@swallez Should we backport to 7.17?

@swallez Should we backport to 7.17?

No, as this changes the type signature, which impacts endpoint generation. If users raise issues about it, we'll have to tell them to use a dumb type (like Void in Java).

authors: stevejgordon swallez

repo: elastic/elasticsearch-specification


text:
Revert Long apt key to short one

using the long key causes several issues on older Puppet Enterprise versions which don't handle the long key very well.
Since i guarantee it to work with those versions i'll have to revert to the short key.
For puppetlabs-apt 1.8 users it will just moan about it but will continue to work.
When I can drop support for those PE versions and use newer versions of the apt module in those i can move back to the long key.

This was reverted.

repo: elastic/puppet-elasticsearch


text:
Add --rich-metadata flag to enable all rich metrics

We currently have a number of flags that are used by heartbeat in conjunction with the – – json output, such as --screenshots and --network. As we add new flags we are creating a compatibility issue between heartbeat and the synthetics agent. Newer versions of heartbeat must add additional flags to gain from their functionality, thus breaking compatibility with older suites using older versions of the synthetics agent which do not support that flag.
This issue proposes adding a new meta-tag --rich-metrics that can stably be used by heartbeat which turns on the relevant flags in the synthetics agent. An additional benefit here is that adding new flags to the synthetics agent won't require adding them to the beats code base.

++ to this approach, We need to investigate a bit on our CLI param and options on how we can make use of commander for these grouping. I feel like --rich-events makes more sense as we already discussed screenshot does not belong much in metrics.

authors: andrewvc vigneshshanmugam

repo: elastic/synthetics

license: MIT


text:
Salesforce BULK API Support

Saleforce has a Bulk API that we could potentially use in the connector. Here is the enhancement request to discuss the advantages, drawbacks and implementation strategies of it's support in elastic.io

I believe the best way to handle this is to:

Create a "Batching" component (which is the inverse of the spliter component)
Create a framework with the sailor SDK where one step can instead of accepting and emitting a single message, the step can accept or emit a batch of messages

There is a similar problem addressed in the CSV write action of the CSV component and I believe that this is a generic problem which should be solved at the platform level as opposed to the component level.

@jhorbulyk good idea with batching component, however the goal of Salesforce Batch API is to work with GBs of data, so batch of such suze is highly unpractical (and think about the passthough content too) and will explode the all components with standard memory allocation.
I believe we should use the same tacitcs like in CSV component - accumulate the data elswhere via streaming (e.g. steward) and then based on the time or "number-of-records" trigger de-stream the data from the location into the Salesforce Batch API.

I also believe that putting an entire batch in an AMQP message passed through RabbitMQ would be infeasible and that the engineering solution would be different.  However, I am suggesting something like the following:
An action can be configured (in component.json) to either receive a single message or a batch of messages. If a batch of messages is selected then the following will happen:
Consider the following flow:
Component A -> Component B
where Component B wants to write a batch.
A developer and/or integrator would be able to configure (in either the component.json or in the UI) for Component B either/both the max batch size and the max time between batches.
I suggest that the above flow would implicitly be constructed:
Component A -> Mapper A->B -> Batcher -> Component B Batch Action
A message in the above flow would have the following lifecycle:

It would be emitted from Component A
The mapping from A->B would be applied.
The message would arrive at the Batcher.

If no open batch exists, the Batcher will open a batch by creating a new file on steward that it can append to.
The Batcher will write the message to the batch
The Batcher will determine if the batch should be closed.  The batch should be closed if

The number of messages in the batch = the max batch size
The time since the last batch published > max time between batches

If the batch is to be closed, the batcher will publish a message to the batch to AMQP

The Batch action will recieve the message.  The sailor logic will convert the batch URL to a Generator or Iterator of messages which would then be passed to user code instead of a message parameter.  As the generator/iterator is traversed, messages would be read from Steward.

I suppose it would also make sense if there was some background process that monitored open batches and closed them when the time since the last batch published > max time between batches.

Interesting idea @jhorbulyk, especially the way how you suggest to handle batches in sailor however there are following drawbacks:
Mapping propagation drawback
As you have noted in your sample Batcher has no metadata by itself but should passthough metadata from the next component to the mapper, we don't have this concept rigth now and can't easily do it (in user-space).
Batch semantic is lost
Idea of creating reusable pieces  / components is in the very core of e.io value however when creating a batcher component as suggested above actual batch semantic will be lost. For example if underlying component will not know that it works on the batch then it may not benifit from the 3rd party batch API (e.g. Salesforce Batch API), think about retries in case of failures or ack/nok semantic consuming incoming messages.
Based on the discussion above I don't believe we could create encapsulate batching functionality as part of dedicated component (at least at the momen) therefore we should build a reusable batching functionality on a different level (e.g. library level) and reuse it in the batch-oriented actions accordingly.

I don't believe we could create encapsulate batching functionality as part of dedicated component (at least at the momen) therefore we should build a reusable batching functionality on a different level (e.g. library level) and reuse it in the batch-oriented actions accordingly.

@zubairov The more I think about it, the more I agree.

Is this blocked by https://github.com/elasticio/projects/issues/140 ?

As the task is of a high complex, it should be investigated

authors: A3a3e1 jhorbulyk zubairov

repo: elasticio/salesforce-component


text:
Add alerts for dropped packets from/to workloads

What this PR does / why we need it:
Which issue this PR fixes (use the format fixes #<issue number>(, fixes #<issue_number>, ...) to automatically close the issue when PR gets merged): fixes #1307
Public facing documentation PR (if applicable)

Special notes for reviewer:
Add a screenshot or an example to illustrate the proposed solution:
Checklist:

[x] Added relevant notes to WIP-CHANGELOG.md
[ ] Proper commit message prefix on all commits
[ ] Updated the public facing documentation
Is this changeset backwards compatible for existing clusters? Applying:

[x] is completely transparent, will not impact the workload in any way.
[ ] requires running a migration script.
[ ] will create noticeable cluster degradation.
E.g. logs or metrics are not being collected or Kubernetes API server
will not be responding while upgrading.
[ ] requires draining and/or replacing nodes.
[ ] will change any APIs.
E.g. removes or changes any CK8S config options or Kubernetes APIs.
[ ] will break the cluster.
I.e. full cluster migration is required.

Chart checklist (pick exactly one):

[x] I upgraded no Chart.
[ ] I upgraded a Chart and determined that no migration steps are needed.
[ ] I upgraded a Chart and added migration steps.

Pipeline config (if applicable)
If you change some config options (e.g. add/rename variable or change the default value) you may need to update the config used by the pipeline in pipeline/config.

I didn't find a way to preserve the identifier of the netpol, as the exported metric ( no_policy_drop_counter ) doesn't provide that
Exported metrics:
var dropDesc = prometheus.NewDesc("no_policy_drop_counter", "Number of packets dropped to/from a workload because no policies matched them", []string{
	"pod", // the name of the Kubernetes pod, if any
	"app", // the value of the "app" label of the pod, if any
	"ip", // a comma separated list of ips or subnets associated with the workload
	"type", // fw = from workload, tw = to workload
}, nil)
var acceptDesc = prometheus.NewDesc("policy_accept_counter", "Number of packets accepted by a policy on a workload", []string{
	"pod",
	"app",
	"ip",
	"type",
	"policy", // full name of the accepting calico policy, eg default/knp.default.foo
}, nil)

repo: elastisys/compliantkubernetes-apps


text:
Add simultaneous Travis/Local Test support

Related to #22, but thought I'd add it as a specific issue.
Right now, it's hard-coded in a jimmy-rigged way.
(As a side note to whomever fixes this: I've added non-public environment variables of "FSUSERNAME" and "FSPASSWORD". I think you'll know what they're for: Sandbox login information.)

Also, added "FSDEVKEY".

Never mind on the FS environment variables; it seems that Travis isn't the place to test that....


text:
🛑 Instagram is down

In 9050bde, Instagram (https://www.instagram.com) was down:

HTTP code: 429
Response time: 334 ms

Resolved: Instagram is back up in cccffd5.

repo: eldikra/monitoreo


text:
Show more data in the UI

Ackee tracks more data (optionally) than it currently shows in the UI. The following data should be available via API endpoints and as visualised cards in the UI.

[x] siteLocation (page views)
[x] siteLanguage (languages)
[x] screenWidth and screenHeight (screens -> dimensions)
[ ] screenColorDepth (screens -> colors)
[x] deviceName and deviceManufacturer (devices -> _)
[x] osName and osVersion (devices -> operating systems)
[x] browserName and browserVersion (browsers -> _)
[x] browserWidth and browserHeight (browser -> dimensions)
[x] Visit duration

The initial version of Ackee only shows site visits and referrers.

Visit duration would be a nice feature. Do you have an Idea on how to do this?

Visit duration will be the next data to show in the UI: https://twitter.com/electerious/status/1175403264805941248

On 24. Sep 2019, at 17:01, Christian Kaatz notifications@github.com wrote:
Visit duration would be a nice feature. Do you have an Idea on how to do this?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Sizes (browser width/height, screen width/height) will be the next data to show in the UI: https://twitter.com/getackee/status/1229021084399345664

@RomainCscn added browsers, devices and operating systems to the UI 👏 They will be part of the next version.

Closing this issue. "screenColorDepth (screens -> colors)" won't make it into the UI as I don't think it's useful for anyone. Everything else is finally implemented.

authors: chrkaatz electerious

repo: electerious/Ackee

license: mit


text:
photo titles up to 100 Characters

photo titles up to 100 Characters
https://github.com/electerious/Lychee/issues/144

This PR has been merged in a bulk merge.

authors: fly-man- steinbrueckri

repo: electerious/Lychee


text:
App installs but won't start

Pre-flight checklist

[X] I have read the contribution documentation for this project.
[X] I agree to follow the code of conduct that this project uses.
[X] I have searched the issue tracker for a bug that matches the one I want to file, without success.

Electron Forge version
5.2.4
Electron version
8.2.0
Operating system
Raspbian BNU/Linux 11 (bullseye)
Last known working Electron Forge version
5.2.4 on Raspbian BNU/Linux 11 (buster)
Expected behavior
Expect the app the start and run.
Actual behavior
Crashes with the following output:
$ npm start

> electron-forge-raspi@1.0.0 start
> electron-forge start

✔ Checking your system
✔ Locating Application
✔ Preparing native dependencies
✔ Launching Application
(electron) 'setName function' is deprecated and will be removed. Please use 'name property' instead.
(electron) The default value of app.allowRendererProcessReuse is deprecated, it is currently "false".  It will change to be "true" in Electron 9.  For more information please check https://github.com/electron/electron/issues/18397
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0403
[700:0829/141650.297847:FATAL:gpu_data_manager_impl_private.cc(1034)] The display compositor is frequently crashing. Goodbye.

Steps to reproduce
electron-forge init . or clone this test repo
Additional information
No response

I had a related issue in a project running on Raspberry Pi (it crashed with GPU process isn't usable. Goodbye.) which was solved by updating Electron from v11 to v16, which was the latest version at the time. So your issue probably has to do with Electron itself rather than electron-forge.

☝ As mentioned above, Electron 8 is no longer supported and it is likely that this issue. Please feel free to post an update if you can narrow this down to a Forge issue.

authors: erickzhao erikian fingerskier

repo: electron-userland/electron-forge


text:
tsc failed to check: Property 'electronApp' does not exist on type 'Process'

node_modules/vite-electron-plugin/src/config.ts:123:21 - error TS2551: Property 'electronApp' does not exist on type 'Process'. Did you mean 'electron'?

123         if (process.electronApp) {
                        ~~~~~~~~~~~

(And 4 more similar issues about process.electronApp)
Seems like missing type definition

tsconfig.json
{
+ "exclude": ["node_modules"]
}

tsconfig.json
{
+ "exclude": ["node_modules"]
}

It has been excluded, since “vite-electron-plugin” or “vite-plugin-electron” is imported in vite.config.ts, the source files in the package is treated as explicitly included.

Consider explicitly declare them?
https://github.com/electron-vite/vite-electron-plugin/blob/1cac66fa011e346c17cf9f71c65323f83790b2a2/electron-env.d.ts#L2-L12

Comparing vite-plugin-electron@0.9.3 (Passed tsc checking) and vite-electron-plugin@0.5.0 (Failed on checking), I found that types in package.json of vite-electron-plugin is set to src, That might caused tsc not checking electron-env.d.ts in the package root. So I tried to import "../electron-env" in src/index.ts of vite-electron-plugin, and that solved the issue.

Thanks for your feedback!
Possibly generating additional .d.ts is better :)

authors: Nyaacinth caoxiemeihao

repo: electron-vite/vite-electron-plugin


text:
Add devRant app

Pull request to add unofficial devRant desktop app to app list.
Official Site: https://www.devrant.io/

Thanks!

authors: Meadowcottage jlord


text:
对 KVO 对象 Hook 必现 crash

crash 栈
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x00007fff513f778b libobjc.A.dylib`objc_msgSend + 11
    frame #1: 0x00007fff2572290d Foundation`_NSSetLongLongValueAndNotify + 81
    frame #2: 0x00000001013ca58d Stinger_Example`ffi_call_unix64 + 85
  * frame #3: 0x00000001013c7804 Stinger_Example`ffi_call_int(cif=<unavailable>, fn=<unavailable>, rvalue=<unavailable>, avalue=<unavailable>, closure=<unavailable>) at ffi64_x86_64.c:660:3 [opt]
    frame #4: 0x00000001013bb956 Stinger_Example`_st_ffi_function(cif=0x00006000002b82a8, ret=0x00007ffeee853920, args=0x00007ffeee8537b0, userdata=0x00006000002b82a0) at STHookInfoPool.m:338:7
    frame #5: 0x00000001013c7a7d Stinger_Example`ffi_closure_unix64_inner(cif=0x00006000002b82a8, fun=(Stinger_Example`_st_ffi_function at STHookInfoPool.m:292), user_data=0x00006000002b82a0, rvalue=0x00007ffeee853920, reg_args=<unavailable>, argp=<unavailable>) at ffi64_x86_64.c:810:3 [opt]
    frame #6: 0x00000001013ca732 Stinger_Example`ffi_closure_unix64 + 72
    frame #7: 0x00000001013acdf2 Stinger_Example`-[ASViewController test:](self=0x00007fdcd1104c70, _cmd="test:", sender=0x00007fdccef023d0) at ASViewController.m:80:10
    frame #8: 0x00007fff48093fff UIKitCore`-[UIApplication sendAction:to:from:forEvent:] + 83
    frame #9: 0x00007fff47a6c00e UIKitCore`-[UIControl sendAction:to:forEvent:] + 223
    frame #10: 0x00007fff47a6c358 UIKitCore`-[UIControl _sendActionsForEvents:withEvent:] + 398
    frame #11: 0x00007fff47a6b2b7 UIKitCore`-[UIControl touchesEnded:withEvent:] + 481
    frame #12: 0x00007fff480cebbf UIKitCore`-[UIWindow _sendTouchesForEvent:] + 2604
    frame #13: 0x00007fff480d04c6 UIKitCore`-[UIWindow sendEvent:] + 4596
    frame #14: 0x00007fff480ab53b UIKitCore`-[UIApplication sendEvent:] + 356
    frame #15: 0x00007fff4812c71a UIKitCore`__dispatchPreprocessedEventFromEventQueue + 6847
    frame #16: 0x00007fff4812f1e0 UIKitCore`__handleEventQueueInternal + 5980
    frame #17: 0x00007fff23bd4471 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
    frame #18: 0x00007fff23bd439c CoreFoundation`__CFRunLoopDoSource0 + 76
    frame #19: 0x00007fff23bd3b74 CoreFoundation`__CFRunLoopDoSources0 + 180
    frame #20: 0x00007fff23bce87f CoreFoundation`__CFRunLoopRun + 1263
    frame #21: 0x00007fff23bce066 CoreFoundation`CFRunLoopRunSpecific + 438
    frame #22: 0x00007fff384c0bb0 GraphicsServices`GSEventRunModal + 65
    frame #23: 0x00007fff48092d4d UIKitCore`UIApplicationMain + 1621
    frame #24: 0x00000001013acfa2 Stinger_Example`main(argc=1, argv=0x00007ffeee855cf0) at main.m:15:16
    frame #25: 0x00007fff5227ec25 libdyld.dylib`start + 1

测试代码：
//
//  ASViewController.m
//  Stinger
//
//  Created by Assuner on 12/05/2017.
//  Copyright (c) 2017 Assuner. All rights reserved.
//

#import "ASViewController.h"
#import <Stinger/Stinger.h>
#import <Aspects/Aspects.h>

@interface ASViewController ()

- (IBAction)test:(id)sender;
@property (nonatomic) NSInteger index;

@property (nonatomic) BOOL didAddKVO;
@property (nonatomic) BOOL didHook;

@end

@implementation ASViewController

- (void)methodA {

}

- (void)setFrame:(CGRect)rect {

}

- (void)viewDidLoad {
  [super viewDidLoad];
  [self.class st_hookInstanceMethod:@selector(methodA) option:STOptionBefore usingIdentifier:@"hook methodA before" withBlock:^(id<StingerParams> params) {

  }];
  [self.class st_hookInstanceMethod:@selector(methodA) option:STOptionAfter usingIdentifier:@"hook methodA after" withBlock:^(id<StingerParams> params) {

  }];

//  [self.class aspect_hookSelector:@selector(methodA) withOptions:AspectPositionBefore usingBlock:^(id<AspectInfo> params) {
//
//  } error:nil];
//
//  [self.class aspect_hookSelector:@selector(methodA) withOptions:AspectPositionBefore usingBlock:^(id<AspectInfo> params) {
//
//  } error:nil];
}

- (void)addKVO {
    if (_didAddKVO) {
        return;
    }
    [self addObserver:self forKeyPath:@"index" options:NSKeyValueObservingOptionOld|NSKeyValueObservingOptionNew context:nil];
    _didAddKVO = YES;
}

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSKeyValueChangeKey,id> *)change context:(void *)context {
    NSLog(@"KVO: %@", change);
}

- (void)hook_set_index {
    if (_didHook) {
        return;
    }
    [self st_hookInstanceMethod:@selector(setIndex:) option:STOptionBefore usingIdentifier:@"setIndex" withBlock:^(id<StingerParams> params, NSInteger index) {
        NSLog(@"HOOK: %@", @(index));
    }];
    _didHook = YES;
}

- (IBAction)test:(id)sender {
//  for (NSInteger i = 0; i < 1000000; i++) {
//    [self methodA];
//  }
  NSLog(@"clicked!!");
    [self addKVO];
    [self hook_set_index];
    self.index += 1;
}
@end

这个问题已经有PR #8 ，麻烦大佬看下是不是能合入？

这个问题已经有PR #8 ，麻烦大佬看下是不是能合入？

这个pr我早都看过，kvo这个问题我之前也知道，这个pr会引发其他的问题

aspects KVO为什么不行是因为selector改了，原方法找不到。stinger我记得hook时 替换 Foundation_NSSetLongLongValueAndNotify类似这样的实现是不对的。Foundation_NSSetLongLongValueAndNotify更像是objc_msgForward，调到时会再调用原set实现，这时候会再调到stinger自己的Imp，形成循环

authors: Assuner-Lee FinnChen

repo: eleme/Stinger


text:
🛑 MCU - Owncloud is down

In c0b3409, MCU - Owncloud (https://cloud.cdeluruguay.gob.ar/login?redirect_url=/apps/dashboard/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MCU - Owncloud is back up in 8994783 after 557 days, 8 hours, 1 minute.

repo: elfoche/monitoreo


text:
Not Running on Android 11

Elementum not running on Shield TV Android 11. “Elementum still starting..” issue. Anyone knows how to correct the issue?

Please, search before creating an issue.

authors: elgatito thiagomgarcia


text:
Elementum still starting up, daemon permission error

Error message at the top of screen any time I run this stupid Plugin, complains about permission error and some ugly broken syntax in the message.  Then complains "Elementum is still starting up!"
What kind of clown show is this?>

Closing as rude.


text:
Use separate logger for JustPy (name and level customizable)

Add JustPy.log logger with LOGGING_LOGGER name (JustPy by default) and LOGGING_LEVEL level, both may be set in justpy.env. (no clue how the min/max branch got in here... :/ )

Excellent, thank you very much! I accept these changes and they will be in the next version. I have not merged the pull request because I am not a git expert and am having issues syncing my local repositories and the one on GitHub.

Hi,
would be great if one could configure the location of a log file but also the complete formatting.
Maybe it would be a good idea to add a jp.get_logger(name=None) method along with a jp.custom_log_handler(handler).
So everybody could leave it alone or just change the location of the log file via justpy.env or use it just with a customer handler.

def get_my_file_handler():
    formatter = logging.Formatter('{asctime}|{levelname:8}|{name:50}|{filename:30}|{funcName:30}|{lineno:6}|{message}', datefmt='%Y-%m-%dT%H:%M:%S', style='{')
    file_handler = logging.FileHandler(sys.path[0] + '/log/mylogfile.log')
    file_handler.setLevel(logging.ERROR)        # Logging Level for file logging
    file_handler.setFormatter(formatter)
    return file_handler

# Completely custom logging
jp.custom_log_handler(get_my_file_handler())
logger = jp.get_logger(__name__)

Maybe an idea to take into account.
regards
Chris

I don't see a need for jp.get_logger: standard logging.getLogger('justpy') gets the justpy (internal) logger object from anywhere, along with the ability to set handlers, formatting etc.

You are right. If justpy is just taking the standard logger then the entire issue/pull is somehow obsolete at all.

please close this if it's not used any more and invite more people so that the project can make progress.

authors: WolfgangFahl cheak1974 elimintz eudoxos

repo: elimintz/justpy


text:
Explain how to download the software

Add /download page.

Relates to https://github.com/elimu-ai/wiki/blob/main/SOFTWARE_ARCHITECTURE.md#distribution-

repo: elimu-ai/website


text:
Use non_neg_integer in *_all functions

from discussion https://github.com/elixir-ecto/ecto/pull/3794#discussion_r767166509

Thanks! 💚

repo: elixir-ecto/ecto


text:
Added batching to regression metrics

Following up on #144 issue:
I've added batching to the Regression metrics, similar to the batching implemented in the Distances metrics. However, I'm not entirely sure if I fully understood the issue, so I would greatly appreciate any feedback.
I did not make changes to the following metrics:

mean_pinball_loss
d2_absolute_error_score
d2_pinball_score

These metrics appear to already support batching through the :multioutput argument. If that's the case, perhaps we should consider standardizing the argument to :axes for consistency across similar functions.
Please let me know if I’m mistaken about anything.

Yes, that's exactly what I meant. Originally, I added option multioutput to mimic sklearn, but now maybe it'll be more beneficial to remove it and support it as you do it @norm4nn, what do you think?

Sounds good, I’ll go with your suggestion!

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:

authors: josevalim msluszniak norm4nn

repo: elixir-nx/scholar


text:
Create a discussions page

I (and maybe others) would like to occasionally ask a question about using Tableau, and issues aren't the right place for that.
Suggestion: create a discussions page like in the Temple repository

Another option: enable Github's 'discussion' feature for this repo.

I think that's what they were saying.
I have an umbrella one for all elixir tools projects but that's more for the related editor/LSP projects.
I'll enable discussions for tableau once I'm back at a computer.

authors: andyl mhanberg sylvester-roos

repo: elixir-tools/tableau


text:
docs: remove example project

elixir-tools.dev is the real example

Current dependencies on/for this PR:

main

PR #31

PR #32   👈

This comment was auto-generated by Graphite.


text:
Improve the way drafts are auto purged from the system

http://www.elkarte.net/community/index.php?topic=2567
Placed it on 1.0.4, may be a better 1.1 item though ...

Move this to 1.1?, I don't see us adding a new column for 1.0.4?

:+1:

First pass was done, probably more needed.

repo: elkarte/Elkarte


text:
SMTP Password no longer being base64 encoded

Which naturally causes all sorts of shenanigans.
The culprit seems to be Spud's commit here:
https://github.com/elkarte/Elkarte/commit/ebf3b243408e3b4b76687af583d040447d62f87c
Moving away from abuse of $_POST is good, but it doesn't matter since Settings_Form::save_db still refers to $_POST.
The 'clean' solution here seems to be to make use of the 'post object' parameter in save_db, which is nearly as bad but should at least not cause regressions after a proper update.

Sorry about that.  I know that some of the subs are still dependent on $POST stuffing :sob:  On the brig's side at least it was POST and not the abomination REQUEST.
I tried to do just about was you did in the PR.  In some cases I actually fully re-stuffed post (yes its awful) since the subs were so bad and noted the mess with @ todo so I would remember to try and fix the subs as well which gets dicey due to backwards compatibility with addons
Anyway step at a time, we will get them!

authors: Spuds Vekseid


text:
Add a way to test email settings

I think there should be a link on the managemail page to send a test email to ensure you've set it up correctly. I'm kind of concerned that I might not have it setup correctly.

I was looking at that one, though it's a bit tricky I think, more because of the expected behaviour.
What I was thinking to do was a link (along the lines of "clean hives") with (maybe) an AJAX call to send the email in background.
Though, I feel it would look odd: in this condition I would expect the setting I just entered (either saved or not) to be the ones used for the sending. But, using unsaved setting would be... confusing, because then it could lead to people not saving the settings (forgetful people like me for example :angel: ).
Could the solution be to save the settings while sending the test email? Informing the admin, of course.

Probably save on send ... actually I think we have the same condition on the Sphinx search settings .. if you try to connect to the search daemon without first hitting save, it will fail.  This even though the fields are populated with some defaults, those defaults are not in the DB yet.

I'm tempted to move it to 2.0

I think there are a few things that would have to be done .. new test template, testing all of the replacement fields, including pbe,  etc etc ... moving it to 2.0 as I don't see us doing this

Added a basic email form in the ACP that an admin can use to send ... pretty basic implementation for a start.


text:
[FEATURE] Allow users to manually specify the polling rate for magic variables

Description of the requested feature
It would be nice if users could set a custom polling rate for the magic variables we use. The syntax for this is not yet clear, however, and I don't have any good ideas (any proposals are very welcome!).
Proposed configuration syntax
None yet :(

I'm thinking in other languages these would actually be function calls, something like EWW_NET(interval). How to achieve that in a lisp language, I don't know. Maybe having those be so-called "Magic Variables" isn't the best solution? Could they be anything else?
Or... functions in yuck when ?

Oh you do have functions! I've just realised round() and replace() were a thing.
Couldn't those magic variables be replaced with function calls then?

I just started configuring my status bar with Eww the other day, and this is a feature I'd really like to see. The default 2 second polling rate definitely feels sluggish sometimes.
Since we already have variables via defvar, maybe they can be reused for configuration, e.g. (defvar EWW_NET_INTERVAL "1s"). Using the builtin variable machinery would also allow modifying configuration variables during runtime with shell commands ($ eww update EWW_NET_INTERVAL=1s), which could enable some cool stuff like increasing the polling rate when network or hard disk activity is high. I haven't looked at the code, though, so I don't know if dynamic polling rates like that are reasonable to implement.
Alternatively, we could add something like a configure call if we want to keep the variable namespace clear of configuration. I'm thinking something to the effect of:
(configure EWW_NET
           :interval "1s")

which would be evaluated once at the beginning of the program and applied to the runtime.

authors: Vermoot elkowar robwhitaker

repo: elkowar/eww


text:
Getting "invalid peer certificate: UnsupportedCertVersion" when trying "atuin server start"

Greetings folks!
Have to embarrass myself here admitting, that I cannot successfully setup an atuin sync server on my own.
When starting atuin server start on my sever machine, I see this in /var/log/postgresql/postgresql-12-main.log (with verbose error-logging enabled):

2023-02-10 15:43:18.089 CET [31044] [unknown]@[unknown] LOG:  08P01: could not accept SSL connection: sslv3 alert bad certificate
2023-02-10 15:43:18.089 CET [31044] [unknown]@[unknown] LOCATION:  be_tls_open_server, be-secure-openssl.c:466

And atuin spits out this on stdout:

Caused by:
0: error communicating with database: invalid peer certificate contents: invalid peer certificate: UnsupportedCertVersion
1: invalid peer certificate contents: invalid peer certificate: UnsupportedCertVersion

The version of atuin used is atuin_12.0.0_amd64.deb provided by the install.sh script listed in the installation documentation. According to the conversation and remarks from ellie and conradludgate in issue https://github.com/ellie/atuin/issues/570, release 12 of atuin has this fix regarding rustls-tls-native-roots. So my guess is, that the error I see is something new.
What irritates me is this [unknown]@[unknown] in the PostgreSQL-log. I would assume to see the credentials there I stated in ~/.config/atuin/server.toml. That file on the server currently looks like this (and no, that not my real password... don't worry :):
host = "127.0.0.1"
port = 5432
open_registration = true
db_uri="postgres://macslow:youneverguesswhatmypasswordis@localhost/atuin"
path=""

I can successfully connect remotely to PostgreSQL using the psql frontend using a dedicated database-user, thus configuration-wise I guess everything is fine on the PostgreSQL-side of things. This is what I see when I use psql from a remote client machine:
1> psql -h macslow.org -U macslow -p 5432 -d atuin
Password for user macslow:
psql (12.13 (Ubuntu 12.13-0ubuntu0.20.04.1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

atuin=>

The same success I have, when I do locally on the server:
1> psql -h 127.0.0.1 -U macslow -p 5432 -d atuin
Password for user macslow:
psql (12.13 (Ubuntu 12.13-0ubuntu0.20.04.1))
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

atuin=>

It all boils down to what is happening in lines 22-24 in <atuin_root>/atuin-server/src/lib.rs, but I really cannot dig into a new language right now to sort it out. Not that rust isn't compelling.
Thanks in advance for your help and advice!
Best regards...
MacSlow

Hey!
Are you connecting to your postgres over the public internet? Do you have SSL certificates configured on your database server?
If not, try adding ?sslmode=disable to the end of your postgres connection string.

also - nice supermoto!

First of all... yeah, the Husky is the best... with my Hypermotard being a close second! :)
I added that suggested snipped to the db_uri-entry. That at least changed to error reported from atuin to:

thread 'main' panicked at 'error binding to 127.0.0.1:5432: error creating server listener: Address already in use (os error 98)', /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.14.20/src/server/server.rs:77:13

Then I changed the port to use 8888 and I got rid of the above error, but there is no response from atuin server start. Should it return to the shell prompt or do I have to detach it manually from the current shell-process?
Trying to connect from the client-side with atuin I get this:
1> atuin login
Please enter username: macslow (this is the database-user I created in PostgreSQL)
Please enter encryption key: <put the stuff here I get from 'atuin key'>
Please enter password: <put the corresponding password for the database-user here>
Error: error decoding response body: expected value at line 1 column 1

Caused by:
    expected value at line 1 column 1

Location:
    /home/runner/work/atuin/atuin/atuin-client/src/api_client.rs:82:21

Sorry, if I might be missing something obvious... can you tell I hate database-stuff? :)

Should I figure it out, I'll promise to write a summary on my blog for future reference. All this started with writing an output-rotation patch, mouse-selection cut&paste and some bug-fixes for kmscon. The rabbit-hole always goes deeper than you initially anticipate :)

In the meantime I have figured out how to setup PostgreSQL to use my "Let's Encrypt"-certificate, which I use for my web-server.
To verify the basic operation of the working certificat I used the command:
openssl s_client -starttls postgres -connect macslow.org:5432 </dev/null
which generates the ouput:
CONNECTED(00000003)
---
Certificate chain
 0 s:CN = macslow.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFLTCCBBWgAwIBAgISA7fdx63SblaICJ+NLGKTSlx4MA0GCSqGSIb3DQEBCwUA
... bla bla bla and so on ...
58G4smTZiKYMamPkLVujqaYpMaHshix4SskffQ60DCbb
-----END CERTIFICATE-----
subject=CN = macslow.org

issuer=C = US, O = Let's Encrypt, CN = R3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4708 bytes and written 727 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Local and remote connections to PostgreSQL are now using the proper SSL-certificate, if I can believe this select-statement I issued on my server hosting the PostgreSQL-database (using the psql frontend):
postgres=# select ssl.pid, usename, datname, ssl, ssl.version, ssl.cipher, ssl.bits, ssl.compression, client_addr from pg_catalog.pg_stat_ssl ssl, pg_catalog.pg_stat_activity activity where ssl.pid = activity.pid and client_addr is not null;
  pid  | usename  | datname  | ssl | version |         cipher         | bits | compression |  client_addr
-------+----------+----------+-----+---------+------------------------+------+-------------+---------------
 36892 | postgres | postgres | t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | 127.0.0.1
 36909 | macslow  | atuin    | t   | TLSv1.3 | TLS_AES_256_GCM_SHA384 |  256 | f           | 91.57.254.111

Again, with all that in place executing atuin server start on the PostgreSQL-server machine still does not seem to work. It does not return to the shell-promt, I don't see anything in the PostgreSQL-log and also nothing shows up in the select-statement about an additional connection.
I guess the ball in back in atuin-land to figure out what's still wrong or missing.

authors: MacSlow ellie

repo: ellie/atuin


text:
AST in detail. Fixes #249

For  #249
Feel free for reject that PR and closed issue, if it is not important for you.

This change is

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

program/program.go, line 245 at r1 (raw file):

		// error is coming from; by looking at the parents of the bad lines.
		goast.Fprint(os.Stdout, p.FileSet, p.File, func(string, reflect.Value) bool {
			return true

I don't understand this change from the original ticket. Is this just to print out more attributes that would be nil?

Comments from Reviewable

Review status: all files reviewed at latest revision, 1 unresolved discussion.

program/program.go, line 245 at r1 (raw file):
Previously, elliotchance (Elliot Chance) wrote…
I don't understand this change from the original ticket. Is this just to print out more attributes that would be nil?

Yes. Feel free to reject.

Comments from Reviewable

Review status: all files reviewed at latest revision, 1 unresolved discussion.

program/program.go, line 245 at r1 (raw file):
Previously, Konstantin8105 (Konstantin) wrote…
Yes. Feel free to reject.

There is already a lot of output when this runs. This would just create more noice if there is no legitimate reason for it to be here.

Comments from Reviewable


text:
Refactored ast nodes into separate package

All the ast nodes seemed like a good candidate for separating out into a separate package so the root folder is cleaner.
I also merged Render() and RenderLine() into one Render() function since having both seemed redundant, this should also cover #38. This means we can get rid of all the slow reflection since all nodes now implement the ast.Node interface.
TODO

[x] Remove reflection code from buildTree
[ ] Fix issue with the following variable declarations not working after the first test: _LIB_VERSION, _IO_2_1_stdin_, _IO_2_1_stdout_, _IO_2_1_stderr_, stdin, stdout, stderr
[x] Fix incorrect coverage

If this is not how you want the project structured feel free to discard this PR.

This change is

Hi @bongo227 - interestingly I did actually have all of these files in an ast package in earlier versions. I moved them out to the root package to get the code coverage working with the integration tests. I would much rather have several small packages that one massive main package.
For each TODO:

Nothing needs to be said on this, sounds good!
I ran in a similar issue on #30 . Global state is evil and now that the integration tests are working (thanks for that!) we should really refactor out the global state, or at least move all the initialisation to a single method that we can repeatedly call cleanly for now.
Either my laziness or haste I did not check if code coverage works across packages, but it looks like it can with the -coverpkg.

Reviewed 66 of 125 files at r1.
Review status: 36 of 66 files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

main.go, line 15 at r1 (raw file):

	"go/format"

	"github.com/bongo227/c2go/ast"

Can we use a relative package name here?

ast/function_decl.go, line 57 at r1 (raw file):

	out := bytes.NewBuffer([]byte{})

	ast.functionName = strings.TrimSpace(n.Name)

This trim is not necessary anymore. It was ported from the original Python.

Comments from Reviewable

Reviewed 59 of 125 files at r1.
Review status: all files reviewed at latest revision, 5 unresolved discussions, some commit checks failed.

ast/common.go, line 51 at r1 (raw file):

}

// func Render(out *bytes.Buffer, node interface{}, functionName string, indent int, returnType string) {

You can remove this now.

ast/compound_stmt.go, line 35 at r1 (raw file):

}

func (n *CompoundStmt) RenderLine(out *bytes.Buffer, functionName string, indent int, returnType string) {

Is this supposed to be here?

ast/resolve.go, line 77 at r1 (raw file):

}

func resolveType(ast *Ast, s string) string {

Not for this PR. But I would like to make the whole type resolving system a separate package (resolve?) with its own unit tests. This should also make it easier to handle more complex and state-oriented type resolutions like function pointers.

Comments from Reviewable

Review status: all files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

main.go, line 15 at r1 (raw file):
Previously, elliotchance (Elliot Chance) wrote…
Can we use a relative package name here?

Relative import paths are highly discouraged, I was going to switch these out at the end with the correct path.

Comments from Reviewable

Review status: all files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

main.go, line 15 at r1 (raw file):
Previously, bongo227 (Ben Sheffield) wrote…
Relative import paths are highly discouraged, I was going to switch these out at the end with the correct path.

That's fair enough. Or maybe it would be easier to rename your directory path to be the same when this pops up in the future.

Comments from Reviewable

Reviewed 55 of 125 files at r1, 59 of 59 files at r2.
Review status: all files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

ast/ast.go, line 52 at r2 (raw file):

type Node interface {
	render(ast *Ast) (string, string)
	AddChild(node Node)

It occurs to me that not all node types will have children, like a StringLiteral. For now it's easier to assume they all do, but maybe something like this?
type NodeWithChildren interface {
    *Node
    AddChild(node Node)
}

However, this might be a bit too pedantic and maybe more appropriate for a separate PR where each node can be checked if it can indeed have children.

ast/common.go, line 51 at r1 (raw file):
Previously, elliotchance (Elliot Chance) wrote…
You can remove this now.

I'm not sure if you have used reviewable before or if you simply haven't responded to these yet. Discussions stay open until you respond (notice the handy "Done" button).

Comments from Reviewable

Review status: all files reviewed at latest revision, 5 unresolved discussions, some commit checks failed.

main.go, line 15 at r1 (raw file):
Previously, elliotchance (Elliot Chance) wrote…
That's fair enough. Or maybe it would be easier to rename your directory path to be the same when this pops up in the future.

Done.

ast/ast.go, line 52 at r2 (raw file):
Previously, elliotchance (Elliot Chance) wrote…
It occurs to me that not all node types will have children, like a StringLiteral. For now it's easier to assume they all do, but maybe something like this?
type NodeWithChildren interface {
    *Node
    AddChild(node Node)
}

However, this might be a bit too pedantic and maybe more appropriate for a separate PR where each node can be checked if it can indeed have children.

Is their a spec for the clang AST anywhere? I haven't managed to find one. I agree that a separate PR is probably best for this one.

ast/common.go, line 51 at r1 (raw file):
Previously, elliotchance (Elliot Chance) wrote…
I'm not sure if you have used reviewable before or if you simply haven't responded to these yet. Discussions stay open until you respond (notice the handy "Done" button).

Done.

ast/compound_stmt.go, line 35 at r1 (raw file):
Previously, elliotchance (Elliot Chance) wrote…
Is this supposed to be here?

Done.

ast/function_decl.go, line 57 at r1 (raw file):
Previously, elliotchance (Elliot Chance) wrote…
This trim is not necessary anymore. It was ported from the original Python.

Done.

ast/resolve.go, line 77 at r1 (raw file):
Previously, elliotchance (Elliot Chance) wrote…
Not for this PR. But I would like to make the whole type resolving system a separate package (resolve?) with its own unit tests. This should also make it easier to handle more complex and state-oriented type resolutions like function pointers.

Done. I created an issue.

Comments from Reviewable

@bongo227 this is a really great change. I'm happy to merge this in if your ready?
Codecov is failing because of the drop in coverage, that's understandable since all the new code. That will be cleaned up over time.

Their is still a problem with those variable declarations (I just ignore them to parse the tests). This can probably be fixed when resolve is refactored out so I would say merging now would be fine.

Cheers: https://github.com/elliotchance/c2go/releases/tag/v0.8.7


text:
ignore tex files starting with a .

Emacs at least will make savepoint files of the form .#foo.ext. zo's filesystem crawl will pick up these tex files. They should probably be ignored.

closed via e83d2a8e1bdf

authors: elliottbiondo gidden

repo: elliottbiondo/zo


text:
Inconcistency between Debugger and the Navigation App

I am not sure this is a real issue or if it can be addressed, but I wanted to point this out.
I have navigation application with several pages. Clicking on navigation link changes the browser's location and this causes the correct page to be shown.
I open the debugger and go back and forth application states.
While the pages are shown correctly, the browser's location is not affected and always stays the same.
Thank you.

The debugger cannot change anything when you go back into the past. It only lets you see old views.
A similar case would be if you have HTTP requests. The debugger does not resend them when you go back. Another case would be putting things in your database. The debugger does not redo that. Navigation is the same as these cases. It is an effect, meaning it is a change to state outside the Elm program. This category of changes are not safe to rerun on replay.

authors: evancz mickeyvip


text:
Whitespace before module definition - confusing error message

What's happening
Calling elm-make on a program that  imports a module with whitespace before the module definition prints error that suggest's the declared module name is Main. E.g.:
The module name is messed up for ././View.elm

    According to the file's name it should be View
    According to the source code it should be Main

Which is it?

Steps to reproduce
In Bash compatible shell type / paste:
#! /usr/bin/env bash

echo "
module Main exposing (main)

import View
" > Main.elm

echo "
 module View -- note space at the beggining
" > View.elm

elm-make ./Main.elm

Expected result
There should be at least a hint about a whitespace in a fashion similar to #21. Or maybe it should be a syntax error to have whitespace at the beginning of first non-empty line of the program? Or error not to have module name declared - that would fit with Elm's apparent preference for explicitness. Just some quick ideas :)
Side notes
Interestingly running elm-make on the offending module itself:
elm make View.elm

gives a much better message:
-- SYNTAX PROBLEM ----------------------------------------------------- View.elm

I need a fresh line to start a new declaration. This means a new line that
starts with stuff, not with spaces or comments.

2|  module View
    ^
I am looking for one of the following things:

    whitespace

Detected errors in 1 module.

Note that the same happens not with just the whitespace, but with any syntax error that happens during the module declaration. Writing
Module View
-- Note the uppercase 'M'

or even
anything that goes here is basically ignored View exposing(..)

Gives the same vague error message

repo: elm-lang/error-message-catalog


text:
establish company, factory and element context for paths

picking up from #83
this has to do w/ where the command is invoked. I think we need to ensure that a "factory context" of sorts can be established. If there is no factory context it needs to complain about needing to be in something.
If the command is invokved from a company (to add a new element that is), then it needs to require a factory context (so then it should ask to pick one). Same for a factory, it has to have a company context in order to work.
Build if invokved from inside of a factory context could skip that question.

[ ] make commands detail which contexts they require (company -> factory -> element)
[ ] work the prompt for input into those that don't have it
[ ] ensure paths are then relative to the closest context possible (so if I require a company, this has to be run from the company or at least move commands to the company before executing them, same for factory and element)

@heyMP lets talk about this today, I dont think it's that hard just need to plan how to activate it

I'll start with the fallback prompt.

commands can now be executed from anywhere on your computer and they'll resolve correctly

authors: btopro heyMP

repo: elmsln/wcfactory


text:
Change Resolution

Hi,
I am not able to change the window size as mentioned in the documentation
<Unity unityContext={unityContext} height="100%" width="950px" />
I tried changing the values to percentage pixels my layout is still kinda landscape
like this
<Unity unityContent={unityContent} height="730px" width="480px" />

here are Unity3D settings

here is when I run the build as standalone on browser

as you can see it is running in the desired resolution
Am I missing something?
regards,
Nipun Davod

Hi! Thanks for opening an issue.
There is a little bit of misunderstanding about the WebGL width and height properties in Unity. As you can see below these options, you can choose a template which Unity will use when building your application. Some template provide some variables which Unity detects and allows the developer to enter from the enter. Height and width are such values, these do not change anything about your build, except they alter the HTML files that comes with your build and sets the height and width value. (TL;D'R Width and Height in Unity don't do anything, no need to use).
You can use percentages in as the Height and Width properties inside of React and then go with regular responsive styling in order to scale your application.

hi @jeffreylanters , so I am not able to follow you completely. I also tried the height and width in %age but they didn't change the resolution the view. Can you please share the exact steps or documentation which I can refer to?
regards,
Nipun David

Hi @nipundavid , I encountered the same issue with the 7.x version and the width/height props having no effects. My solution was to override the style with the !important rule, for example :
<Unity unityContent={this.unityContent} className="unity-content"/>

// CSS
.unity-content {
    height: 640px !important;
    width: 480px !important;
}

In my case, the main problem was actually what seemed like a fixed 2:1 aspect ratio (i.e. the height of the canvas being always equals to 50% of its width), so I'll let my somehow responsive solution here if anyone needs it.
componentDidMount() {
    window.addEventListener('resize', this.resize);

    this.resize();
}

componentWillUnmount() {
    window.removeEventListener('resize', this.resize);
}

resize = () => {
    const unityElement = document.getElementById("unity") as HTMLInputElement;
    const width = parseFloat(window.getComputedStyle(unityElement).width);

    unityElement.setAttribute("style", "height: " + (width / 16 * 9) + "px !important");
}

render() {
    return (

            <Unity unityContent={this.unityContent} />

    );
}

I had luck with this:
In my case I have a header which is why I'm subtracting 64px

        <Unity height='100%' width='100%' unityContext={context} />

authors: Slympp jeffreylanters nipundavid zmays

repo: elraccoone/react-unity-webgl


text:
AudioContext should not be closed

https://github.com/eliasmeire/mp3-mediarecorder/blob/c154ddcbf94f19cddd7187b5bfe993176cc34ae4/src/recorder/index.ts#L75
Closing the AudioContext here makes it impossible to re-use the context on subsequent recordings.
Removing this line fixes the issue.

Hm I think I added this to limit the amount of open AudioContexts, if you don't pass in your own AudioContext (to fix #59). I shouldn't close it if you pass in your own AudioContext. I'll make a fix!

:tada: This issue has been resolved in version 4.0.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: alexthewilde elsmr


text:
where can i get the eye model?

or how i can create a model.  Thanks!

Closing

repo: elucideye/drishti


text:
Hang trying to read bytes from a pipe filled with values

Run the following code:
echo $pid; range 40 | slurp
Result: The shell hangs, and does not respond to SIGINT. If you send a SIGSEGV (this is why we recorded the shell's pid), a backtrace is printed. It is probably informative, but I don't include it here, since it is rather big (and elvish users can reproduce it themselves). Not tried on Windows.
(Possibly, you may need to replace 40 by a bigger number.)
Edited: Much simpler code to reproduce, thanks to @krader1961 in chat.

The limit is defined by this constant: const pipelineChanBufferSize = 32. There's no comment in pkg/eval/compile_effect.go for why 32 and not some other value. In any case, it should be obvious it isn't sufficient to simply use a larger value. This hangs: elvish -c 'echo $pid; range 33 | slurp'. Sending SIGUSR1 to the process results in these backtraces:
goroutine 5 [running]:
src.elv.sh/pkg/sys.DumpStack()
	/Users/krader/projects/3rd-party/elvish/pkg/sys/dumpstack.go:10 +0x66
src.elv.sh/pkg/shell.handleSignal({0x43e2bd0?, 0x45bc810?}, {0x43e0948, 0xc0000a4010})
	/Users/krader/projects/3rd-party/elvish/pkg/shell/signal_unix.go:20 +0x8d
src.elv.sh/pkg/shell.initSignal.func1()
	/Users/krader/projects/3rd-party/elvish/pkg/shell/shell.go:140 +0x75
created by src.elv.sh/pkg/shell.initSignal
	/Users/krader/projects/3rd-party/elvish/pkg/shell/shell.go:137 +0x91

goroutine 1 [IO wait]:
internal/poll.runtime_pollWait(0x4e83158, 0x72)
	/usr/local/go/src/runtime/netpoll.go:302 +0x89
internal/poll.(*pollDesc).wait(0xc00007c420?, 0xc00024a000?, 0x1)
	/usr/local/go/src/internal/poll/fd_poll_runtime.go:83 +0x32
internal/poll.(*pollDesc).waitRead(...)
	/usr/local/go/src/internal/poll/fd_poll_runtime.go:88
internal/poll.(*FD).Read(0xc00007c420, {0xc00024a000, 0x200, 0x200})
	/usr/local/go/src/internal/poll/fd_unix.go:167 +0x25a
os.(*File).read(...)
	/usr/local/go/src/os/file_posix.go:31
os.(*File).Read(0xc000010098, {0xc00024a000?, 0x4068eb9?, 0x4281bfe?})
	/usr/local/go/src/os/file.go:119 +0x5e
io.ReadAll({0x43e0928, 0xc000010098})
	/usr/local/go/src/io/io.go:645 +0xfe
src.elv.sh/pkg/eval.slurp(0x2?)
	/Users/krader/projects/3rd-party/elvish/pkg/eval/builtin_fn_io.go:637 +0x37
reflect.Value.call({0x43094e0?, 0x438a778?, 0x18?}, {0x4371a35, 0x4}, {0xc00000e348, 0x1, 0x0?})
	/usr/local/go/src/reflect/value.go:556 +0x845
reflect.Value.Call({0x43094e0?, 0x438a778?, 0x42ed5a0?}, {0xc00000e348, 0x1, 0x1})
	/usr/local/go/src/reflect/value.go:339 +0xbf
src.elv.sh/pkg/eval.(*goFn).Call(0xc0000d3810, 0xc000234180, {0x0, 0x0, 0x7?}, 0xc000020960)
	/Users/krader/projects/3rd-party/elvish/pkg/eval/go_fn.go:247 +0xb46
src.elv.sh/pkg/eval.(*formOp).exec(0xc0002144d0, 0xc000234180)
	/Users/krader/projects/3rd-party/elvish/pkg/eval/compile_effect.go:366 +0x45d
src.elv.sh/pkg/eval.(*pipelineOp).exec.func1({0x43e0c28?, 0xc0002144d0?}, 0xc0000361b0)
	/Users/krader/projects/3rd-party/elvish/pkg/eval/compile_effect.go:120 +0x5a
src.elv.sh/pkg/eval.(*pipelineOp).exec(0xc00007a380, 0xc000234000)
	/Users/krader/projects/3rd-party/elvish/pkg/eval/compile_effect.go:134 +0xa8f
src.elv.sh/pkg/eval.chunkOp.exec({{0x0, 0x1b}, {0xc000036100, 0x2, 0x2}}, 0xc00000e0c0?)
	/Users/krader/projects/3rd-party/elvish/pkg/eval/compile_effect.go:32 +0x110
src.elv.sh/pkg/eval.nsOp.prepare.func1()
	/Users/krader/projects/3rd-party/elvish/pkg/eval/compiler.go:81 +0x26
src.elv.sh/pkg/eval.(*Evaler).Eval(0xc00020e000, {{0x43744bc, 0xc}, {0x7ffeefbff5bb, 0x1b}, 0x1}, {{0xc00000e0c0, 0x3, 0x3}, 0x438a390, ...})
	/Users/krader/projects/3rd-party/elvish/pkg/eval/eval.go:411 +0x5a4
src.elv.sh/pkg/shell.evalInTTY({0xc0000a4000, 0xc0000a4008, 0xc0000a4010}, 0x4371cbd?, {0x0, 0x0}, {{0x43744bc, 0xc}, {0x7ffeefbff5bb, 0x1b}, ...})
	/Users/krader/projects/3rd-party/elvish/pkg/shell/shell.go:153 +0x1c5
src.elv.sh/pkg/shell.script(0x4316700?, {0xc0000a4000, 0xc0000a4008, 0xc0000a4010}, {0xc00009e0b0?, 0x7ffeefbff5b9?, 0x1?}, 0xc0000ddd65)
	/Users/krader/projects/3rd-party/elvish/pkg/shell/script.go:64 +0x39a
src.elv.sh/pkg/shell.(*Program).Run(0xc00009fb00, {0xc0000a4000, 0xc0000a4008, 0xc0000a4010}, {0xc00009e0b0, 0x1, 0x1})
	/Users/krader/projects/3rd-party/elvish/pkg/shell/shell.go:66 +0x385
src.elv.sh/pkg/prog.composite.Run(...)
	/Users/krader/projects/3rd-party/elvish/pkg/prog/prog.go:118
src.elv.sh/pkg/prog.Run({0xc0000a4000, 0xc0000a4008, 0xc0000a4010}, {0xc00009e090, 0x3, 0x3}, {0x43e2ba8, 0xc0000b0750})
	/Users/krader/projects/3rd-party/elvish/pkg/prog/prog.go:83 +0x3d4
main.main()
	/Users/krader/projects/3rd-party/elvish/cmd/elvish/main.go:18 +0x17f

goroutine 19 [chan receive]:
src.elv.sh/pkg/eval.getBlackholeChan.func1()
	/Users/krader/projects/3rd-party/elvish/pkg/eval/port.go:96 +0x3a
created by src.elv.sh/pkg/eval.getBlackholeChan
	/Users/krader/projects/3rd-party/elvish/pkg/eval/port.go:95 +0x6a

goroutine 20 [syscall]:
os/signal.signal_recv()
	/usr/local/go/src/runtime/sigqueue.go:148 +0x28
os/signal.loop()
	/usr/local/go/src/os/signal/signal_unix.go:23 +0x19
created by os/signal.Notify.func1.1
	/usr/local/go/src/os/signal/signal.go:151 +0x2a

goroutine 6 [chan receive]:
src.elv.sh/pkg/eval.FilePort.func1()
	/Users/krader/projects/3rd-party/elvish/pkg/eval/port.go:233 +0xca
created by src.elv.sh/pkg/eval.FilePort
	/Users/krader/projects/3rd-party/elvish/pkg/eval/port.go:232 +0xea

goroutine 7 [chan receive]:
src.elv.sh/pkg/eval.FilePort.func1()
	/Users/krader/projects/3rd-party/elvish/pkg/eval/port.go:233 +0xca
created by src.elv.sh/pkg/eval.FilePort
	/Users/krader/projects/3rd-party/elvish/pkg/eval/port.go:232 +0xea

goroutine 8 [select]:
src.elv.sh/pkg/eval.ListenInterrupts.func1()
	/Users/krader/projects/3rd-party/elvish/pkg/eval/interrupts.go:46 +0x95
created by src.elv.sh/pkg/eval.ListenInterrupts
	/Users/krader/projects/3rd-party/elvish/pkg/eval/interrupts.go:42 +0x138

goroutine 9 [select]:
src.elv.sh/pkg/eval.valueOutput.Put({0xc00007c4e0?, 0xc00022a2a0?, 0xc0000603c0?}, {0x42fc200?, 0x45bc820?})
	/Users/krader/projects/3rd-party/elvish/pkg/eval/port.go:280 +0x8e
src.elv.sh/pkg/eval.rangeInt({0xc0000a91a0?, 0x2?, 0x0?}, {0x43e1ac8, 0xc0000b07e0})
	/Users/krader/projects/3rd-party/elvish/pkg/eval/builtin_fn_num.go:805 +0x2b8
src.elv.sh/pkg/eval.rangeFn(0xc000234100, {{0x0?, 0x0?}}, {0xc000121d00?, 0x2?, 0xc0000a9190?})
	/Users/krader/projects/3rd-party/elvish/pkg/eval/builtin_fn_num.go:779 +0x28b
reflect.Value.call({0x43132e0?, 0x438a710?, 0x60?}, {0x4371a35, 0x4}, {0xc0000a63c0, 0x3, 0x30?})
	/usr/local/go/src/reflect/value.go:556 +0x845
reflect.Value.Call({0x43132e0?, 0x438a710?, 0x42f2260?}, {0xc0000a63c0, 0x3, 0x4})
	/usr/local/go/src/reflect/value.go:339 +0xbf
src.elv.sh/pkg/eval.(*goFn).Call(0xc000132770, 0xc000234100, {0xc000121c70, 0x1, 0x7?}, 0xc00009fbc0)
	/Users/krader/projects/3rd-party/elvish/pkg/eval/go_fn.go:247 +0xb46
src.elv.sh/pkg/eval.(*formOp).exec(0xc000214420, 0xc000234100)
	/Users/krader/projects/3rd-party/elvish/pkg/eval/compile_effect.go:366 +0x45d
src.elv.sh/pkg/eval.(*pipelineOp).exec.func1({0x43e0c28?, 0xc000214420?}, 0xc0000361a0)
	/Users/krader/projects/3rd-party/elvish/pkg/eval/compile_effect.go:120 +0x5a
created by src.elv.sh/pkg/eval.(*pipelineOp).exec
	/Users/krader/projects/3rd-party/elvish/pkg/eval/compile_effect.go:136 +0xb4a

I've been pondering this problem and don't see any practical solution. The simple example in the problem statement (and similar examples) could, in theory, be detected when compiling the program. However, there is no way in general to detect this problem at compile time. It's not even practical to do so at run time since the the LHS could fill the value pipe faster than it is drained by the RHS. Thus, it isn't enough to simply detect that the pipe (Go channel) is full when trying to inject another value. The only practical solution today is to rely on the user to use only-bytes or only-values.

Note that there are two, closely related, pipeline problems:

The LHS produces byte/value output that is not consumed by the RHS and exceeds the buffering capacity of the stream (this is the issue in the original problem statement). This results in a "hang"; i.e., deadlock.

The LHS produces byte/value output that is not consumed by the RHS and fits within the buffering capacity of the stream. In this case that output is silently discarded.

Note that a byte stream can buffer anywhere from 512 bytes (the original UNIX implementation) to 128 KB (a AT&T SysVR4 STREAMS fifo). The most common buffer size today is 8 KB. The value stream can buffer 32 items as defined by const pipelineChanBufferSize = 32 in pkg/eval/compile_effect.go.
Both of these examples "succeed" and silently discard either the byte or value output of the LHS:
# This silently discards the byte stream output of the LHS.
elvish> { put yes; echo (for _ [(range 8192)] { print x } ) } | take 1
▶ yes
# This silently discards the value stream output of the LHS.
elvish> { put yes; echo (for _ [(range 8)] { print x } ) } | slurp
▶ "xxxxxxxx\n"

Both of these examples "fail" by hanging because either the byte or value output of the LHS exceeds the buffer of the respective pipe:
elvish> { echo yes; range 33 } | slurp
elvish> { put yes; for _ [(range (math:pow 2 22))] { print x } } | take 1

The scare-quotes around "fail" and "succeed" are intentional because it is not clear that either condition should be considered a success or failure. Also, the last example, involving byte stream output, actually "succeeds" but only after a very long time. And that is a subtlety that has to do with out byte stream output is handled.

repo: elves/elvish


text:
changelog: Add auto-changelog action step to gh-actions

We should add this to automatically populate our change log file.
Acceptance Criteria
Add gh-action step for updating our existing CHANGELOG.md file to contain release notes between previously published tag and latest published tag.
See example/potential-candidate gh-action here:
https://github.com/requarks/changelog-action

No longer required - Detailed Change log is kept by github (via tags and releases logs).

repo: elycruz/rollup-plugin-sass


text:
#849 Testing bottonPanel and rightPanel

Fixes: #849
Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated

in the file; or
   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

Closing this PR since it is now superseded by a different PR.

authors: nabilIbm tomlyn

repo: elyra-ai/canvas


text:
Conda env export fails due to incorrect PyPI spec parsing

Describe the issue
conda export will fail if elyra >3.3 is installed via pip in a conda enviornment
Known Conda issue when setup.py cannot be parsed - in this case the cause seems to be version spec for kfp
https://github.com/conda/conda/issues/9624
Appears it can be solved by adding a comma for kfp specs between 1.6.3 and <2.0
https://github.com/elyra-ai/elyra/blob/master/setup.py#L104
'kfp>=1.6.3<2.0,!=1.7.2',
to
'kfp>=1.6.3,<2.0,!=1.7.2',
To Reproduce
Steps to reproduce the behavior:

conda create -n elyra python=3.8.12 jupyterlab
conda activate elyra
pip3 install --upgrade --upgrade-strategy only-if-needed --use-deprecated legacy-resolver --no-cache-dir elyra-pipeline-editor-extension==3.3.0rc2
conda export -n elyra
Error will be KeyError: '!=1.7.2,>=1.6.3<2.0'

This can be manually fixed by editing the METADATA of elyra server in site packages vi <CONDA_PREFIX>/envs/elyra/lib/python3.8/site-packages/elyra_server-3.3.0rc2.dist-info/METADATA
Requires-Dist: kfp (!=1.7.2,>=1.6.3<2.0) to Requires-Dist: kfp (!=1.7.2,>=1.6.3,<2.0)
Screenshots or log output
If applicable, add screenshots or log output to help explain your problem.
Log Output

/Projects$ conda export -n elyra
Traceback (most recent call last):
  File "/lib/python3.8/site-packages/conda/models/version.py", line 38, in __call__
    return cls._cache_[arg]
KeyError: '!=1.7.2,>=1.6.3<2.0'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/version.py", line 38, in call
return cls.cache[arg]
KeyError: '>=1.6.3<2.0'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/version.py", line 38, in call
return cls.cache[arg]
KeyError: '1.6.3<2.0'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<CONDA_PREFIX>/bin/conda-export", line 10, in
sys.exit(main())
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda_export.py", line 86, in main
env_all = from_environment(args.name, prefix, no_builds=True)
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda_env/env.py", line 109, in from_environment
precs = tuple(PrefixGraph(pd.iter_records()).graph)
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/prefix_graph.py", line 39, in init
parent_match_specs = tuple(MatchSpec(d) for d in node.depends)
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/prefix_graph.py", line 39, in
parent_match_specs = tuple(MatchSpec(d) for d in node.depends)
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/match_spec.py", line 55, in call
return super(MatchSpecType, cls).call(**parsed)
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/match_spec.py", line 177, in init
self._match_components = self._build_components(**kwargs)
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/match_spec.py", line 403, in _build_components
return frozendict(_make_component(key, value) for key, value in iteritems(kwargs))
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/match_spec.py", line 403, in
return frozendict(_make_component(key, value) for key, value in iteritems(kwargs))
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/match_spec.py", line 417, in _make_component
matcher = _implementorsfield_name
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/version.py", line 40, in call
val = cls.cache[arg] = super(SingleStrArgCachingType, cls).call(arg)
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/version.py", line 497, in init
vspec_str, matcher, is_exact = self.get_matcher(vspec)
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/version.py", line 508, in get_matcher
tup = tuple(VersionSpec(s) for s in vspec_tree[1:])
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/version.py", line 508, in
tup = tuple(VersionSpec(s) for s in vspec_tree[1:])
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/version.py", line 40, in call
val = cls.cache[arg] = super(SingleStrArgCachingType, cls).call(arg)
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/version.py", line 497, in init
vspec_str, matcher, is_exact = self.get_matcher(vspec)
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/version.py", line 546, in get_matcher
self.matcher_vo = VersionOrder(vo_str)
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/version.py", line 40, in call
val = cls.cache[arg] = super(SingleStrArgCachingType, cls).call(arg)
File "<CONDA_PREFIX>/lib/python3.8/site-packages/conda/models/version.py", line 172, in init
raise InvalidVersionSpec(vstr, "invalid character(s)")
conda.exceptions.InvalidVersionSpec: Invalid version '1.6.3<2.0': invalid character(s)

Expected behavior
A clear and concise description of what you expected to happen.
$ conda export -n elyra
channels:

conda-forge
dependencies:
jupyterlab
python=3.8.12
pip:

elyra-pipeline-editor-extension
flake8
pydocstyle
pylint
rope
yapf
name: elyra

Deployment information
Describe what you've deployed and how:

Elyra version: [3.3.0rc2]
Installation source: [conda environment with pip to install elyra]
Deployment type: [local installation]
Operating system: [linux - WSL on windows]

How was this issue resolved?

How was this issue resolved?

https://github.com/elyra-ai/elyra/pull/2342/commits/5bf7d09e89649bc1d247aea707c2d665d1775615
as described in the issue detail, by fixing the setup.py - just adding a comma between versions
'kfp>=1.6.3<2.0,!=1.7.2',
'kfp>=1.6.3,<2.0,!=1.7.2',

repo: elyra-ai/elyra


text:
Regression with CNNs ?

Hey :)
Weird thing: as I actually had equivalent scores between CNN and RNN embeddings, my experiments with Optuna for now have yielded consistently lower result (by a big margin) on CNNs (I assume this change is in cause https://github.com/emanjavacas/pie/commit/bca9516938a4a8bc5f4d385949eeff5a14a4b67b#diff-4853226f237bf1b0a17a302fbfa3e997 )
I cannot say if it's a regression before I actually retrain the same config as before but this might be something to look at in the next weeks.

Current scores:
| Id | Param | Type (1=RNN, 0=CNN) | Status |
| -- | -- | -- | -- | -- |
| 64 | cemb_type | 1.0 |   | RUNNING |
| 18 | cemb_type | 0.0 |   | RUNNING |
| 5 | cemb_type | 1.0 | 0.0 | COMPLETE |
| 9 | cemb_type | 1.0 | 0.0 | COMPLETE |
| 72 | cemb_type | 1.0 | 0.0 | COMPLETE |
| 7 | cemb_type | 0.0 | 0.7219 | COMPLETE |
| 9 | cemb_type | 0.0 | 0.842 | PRUNED |
| 50 | cemb_type | 0.0 | 0.8423 | PRUNED |
| 4 | cemb_type | 0.0 | 0.8585 | PRUNED |
| 13 | cemb_type | 0.0 | 0.8606 | PRUNED |
| 14 | cemb_type | 0.0 | 0.8635 | PRUNED |
| 15 | cemb_type | 0.0 | 0.8645 | PRUNED |
| 16 | cemb_type | 0.0 | 0.8668 | PRUNED |
| 10 | cemb_type | 0.0 | 0.8677 | PRUNED |
| 6 | cemb_type | 0.0 | 0.8698 | PRUNED |
| 6 | cemb_type | 0.0 | 0.881 | PRUNED |
| 38 | cemb_type | 0.0 | 0.8815 | PRUNED |
| 26 | cemb_type | 1.0 | 0.8883 | PRUNED |
| 8 | cemb_type | 0.0 | 0.8899 | PRUNED |
| 35 | cemb_type | 0.0 | 0.901 | PRUNED |
| 40 | cemb_type | 0.0 | 0.9029 | PRUNED |
| 81 | cemb_type | 0.0 | 0.9032 | PRUNED |
| 0 | cemb_type | 0.0 | 0.9127 | COMPLETE |
| 0 | cemb_type | 0.0 | 0.9193 | COMPLETE |
| 1 | cemb_type | 0.0 | 0.9196 | COMPLETE |
| 36 | cemb_type | 1.0 | 0.9343 | PRUNED |
| 1 | cemb_type | 0.0 | 0.9372 | COMPLETE |
| 34 | cemb_type | 1.0 | 0.947 | PRUNED |
| 3 | cemb_type | 0.0 | 0.9496 | COMPLETE |
| 12 | cemb_type | 1.0 | 0.9555 | PRUNED |
| 39 | cemb_type | 1.0 | 0.959 | PRUNED |
| 79 | cemb_type | 1.0 | 0.959 | PRUNED |
| 47 | cemb_type | 1.0 | 0.9606 | PRUNED |
| 30 | cemb_type | 1.0 | 0.9609 | PRUNED |
| 20 | cemb_type | 1.0 | 0.9619 | PRUNED |
| 29 | cemb_type | 1.0 | 0.9636 | PRUNED |
| 12 | cemb_type | 1.0 | 0.9642 | PRUNED |
| 22 | cemb_type | 1.0 | 0.9644 | PRUNED |
| 49 | cemb_type | 1.0 | 0.9646 | PRUNED |
| 63 | cemb_type | 1.0 | 0.9647 | PRUNED |
| 59 | cemb_type | 1.0 | 0.9652 | PRUNED |
| 66 | cemb_type | 1.0 | 0.9652 | PRUNED |
| 97 | cemb_type | 1.0 | 0.9653 | PRUNED |
| 37 | cemb_type | 1.0 | 0.9656 | PRUNED |
| 94 | cemb_type | 1.0 | 0.9656 | PRUNED |
| 48 | cemb_type | 1.0 | 0.966 | PRUNED |
| 75 | cemb_type | 1.0 | 0.9661 | PRUNED |
| 84 | cemb_type | 1.0 | 0.9661 | PRUNED |
| 33 | cemb_type | 1.0 | 0.9664 | PRUNED |
| 46 | cemb_type | 1.0 | 0.9665 | PRUNED |
| 82 | cemb_type | 1.0 | 0.967 | PRUNED |
| 78 | cemb_type | 1.0 | 0.9671 | PRUNED |
| 83 | cemb_type | 1.0 | 0.9671 | PRUNED |
| 98 | cemb_type | 1.0 | 0.9674 | PRUNED |
| 85 | cemb_type | 1.0 | 0.9676 | PRUNED |
| 44 | cemb_type | 1.0 | 0.9678 | PRUNED |
| 74 | cemb_type | 1.0 | 0.9678 | PRUNED |
| 62 | cemb_type | 1.0 | 0.968 | PRUNED |
| 68 | cemb_type | 1.0 | 0.9683 | PRUNED |
| 71 | cemb_type | 1.0 | 0.9683 | PRUNED |
| 92 | cemb_type | 1.0 | 0.9683 | PRUNED |
| 27 | cemb_type | 1.0 | 0.9684 | PRUNED |
| 99 | cemb_type | 1.0 | 0.9696 | PRUNED |
| 56 | cemb_type | 1.0 | 0.9706 | PRUNED |
| 3 | cemb_type | 1.0 | 0.9719 | COMPLETE |
| 16 | cemb_type | 1.0 | 0.973 | COMPLETE |
| 80 | cemb_type | 1.0 | 0.9733 | PRUNED |
| 2 | cemb_type | 1.0 | 0.9739 | COMPLETE |
| 13 | cemb_type | 1.0 | 0.9742 | COMPLETE |
| 19 | cemb_type | 1.0 | 0.9743 | PRUNED |
| 73 | cemb_type | 1.0 | 0.9744 | COMPLETE |
| 11 | cemb_type | 1.0 | 0.9745 | COMPLETE |
| 10 | cemb_type | 1.0 | 0.9747 | COMPLETE |
| 7 | cemb_type | 1.0 | 0.9748 | COMPLETE |
| 89 | cemb_type | 1.0 | 0.9751 | PRUNED |
| 96 | cemb_type | 1.0 | 0.9751 | PRUNED |
| 70 | cemb_type | 1.0 | 0.9752 | COMPLETE |
| 2 | cemb_type | 1.0 | 0.9752 | COMPLETE |
| 5 | cemb_type | 1.0 | 0.9753 | COMPLETE |
| 17 | cemb_type | 1.0 | 0.9754 | COMPLETE |
| 95 | cemb_type | 1.0 | 0.9756 | PRUNED |
| 11 | cemb_type | 1.0 | 0.9757 | COMPLETE |
| 54 | cemb_type | 1.0 | 0.9757 | COMPLETE |
| 8 | cemb_type | 1.0 | 0.9757 | COMPLETE |
| 45 | cemb_type | 1.0 | 0.9758 | COMPLETE |
| 25 | cemb_type | 1.0 | 0.976 | COMPLETE |
| 51 | cemb_type | 1.0 | 0.976 | COMPLETE |
| 17 | cemb_type | 1.0 | 0.976 | COMPLETE |
| 41 | cemb_type | 1.0 | 0.9761 | COMPLETE |
| 87 | cemb_type | 1.0 | 0.9769 | COMPLETE |
| 60 | cemb_type | 1.0 | 0.977 | COMPLETE |
| 18 | cemb_type | 1.0 | 0.9772 | COMPLETE |
| 21 | cemb_type | 1.0 | 0.9772 | COMPLETE |
| 28 | cemb_type | 1.0 | 0.9773 | COMPLETE |
| 42 | cemb_type | 1.0 | 0.9773 | COMPLETE |
| 77 | cemb_type | 1.0 | 0.9774 | COMPLETE |
| 86 | cemb_type | 1.0 | 0.9775 | COMPLETE |
| 32 | cemb_type | 1.0 | 0.9776 | COMPLETE |
| 91 | cemb_type | 1.0 | 0.9776 | COMPLETE |
| 61 | cemb_type | 1.0 | 0.9778 | COMPLETE |
| 23 | cemb_type | 1.0 | 0.9779 | COMPLETE |
| 24 | cemb_type | 1.0 | 0.978 | COMPLETE |
| 14 | cemb_type | 1.0 | 0.9781 | COMPLETE |
| 31 | cemb_type | 1.0 | 0.9781 | COMPLETE |
| 4 | cemb_type | 1.0 | 0.9782 | COMPLETE |
| 76 | cemb_type | 1.0 | 0.9783 | COMPLETE |
| 43 | cemb_type | 1.0 | 0.9784 | COMPLETE |
| 58 | cemb_type | 1.0 | 0.9784 | COMPLETE |
| 53 | cemb_type | 1.0 | 0.9785 | COMPLETE |
| 67 | cemb_type | 1.0 | 0.9785 | COMPLETE |
| 88 | cemb_type | 1.0 | 0.9785 | COMPLETE |
| 52 | cemb_type | 1.0 | 0.9787 | COMPLETE |
| 69 | cemb_type | 1.0 | 0.9787 | COMPLETE |
| 90 | cemb_type | 1.0 | 0.9787 | COMPLETE |
| 15 | cemb_type | 1.0 | 0.9788 | COMPLETE |
| 55 | cemb_type | 1.0 | 0.9788 | COMPLETE |
| 57 | cemb_type | 1.0 | 0.979 | COMPLETE |
| 93 | cemb_type | 1.0 | 0.9794 | COMPLETE |
| 65 | cemb_type | 1.0 | 0.9796 | COMPLETE |

It seems it has been a while that I did not train on CNN. I leave that open for the future, when comparing with the models we have for Old French.

Hey, I believe bca9516 fixed some previous hacks with the CNNs, it's an old commit I had lying around. I am surprised I hadn't pushed it before. I haven't used cnn embeddings very extensively, so I am cannot rule out a bug for sure. It would need some experimenting to make clear what's going on. Same architecture trained with previous and current implementation and comparison.

authors: PonteIneptique emanjavacas

repo: emanjavacas/pie


text:
feat: add slither plugins

Add slither plugin

Closing in favour of dedicated repo

repo: embark-framework/embark


text:
fix: Add the_ugly_duckling.txt for speedtask to Python wheel

This PR adds the file the_ugly_duckling.txt to the Python wheel. Currently when installing mteb with pip install mteb and then running a SpeedTask you get the error below. This PR fixes that.
  File ".../venv/lib/python3.12/site-packages/mteb/abstasks/AbsTaskSpeedTask.py", line 35, in load_data
    with file_path.open("r") as f:
         ^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/pathlib.py", line 1013, in open
    return io.open(self, mode, buffering, encoding, errors, newline)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '.../venv/lib/python3.12/site-packages/mteb/abstasks/the_ugly_duckling.txt'

Thanks @helena-intel - Assuming test pass this will auto merge and a new mteb will be pushed to pypi

authors: KennethEnevoldsen helena-intel

repo: embeddings-benchmark/mteb


text:
Does the library support autodiscovery or do I need to manually list all of nodes?

I'm referring to this:
https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/AutoDiscovery.AddingToYourClientLibrary.html
It looks like Java version and few others do have support.

my bad, I didn't look carefully enough

repo: emcache/emcache


text:
No. More. Semaphores.

Much like Wanda Maximoff and her infamous "No. More. Mutants.", so too hath the whisper of "No. More. Semaphores." been carried into the wind by @vladimirvivien. This patch removes the semaphores from libStorage so that the client no longer has any dependency on Cgo.

[Current coverage][cc-pull] is 32.95%

Merging [#158][cc-pull] into [master][cc-base-branch] will decrease coverage by 1.39%

File ...utils/paths/paths.go was modified. more

Misses -10
Partials 0
Hits +10

@@             master       #158   diff @@
==========================================
  Files            36         33     -3
  Lines          1919       1824    -95
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits            659        601    -58
+ Misses         1195       1158    -37
  Partials         65         65

Powered by Codecov. Last updated by [3d857c0...cdc8c00][cc-compare]
[cc-base-branch]: https://codecov.io/gh/emccode/libstorage/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/emccode/libstorage/compare/3d857c01e5a7f2bddb37f4cde31f092a89ec1bb1...cdc8c0023e3d0a702575eec16763202b449106f4
[cc-pull]: https://codecov.io/gh/emccode/libstorage/pull/158?src=pr

authors: akutz codecov-io

repo: emccode/libstorage


text:
FEED RSS

Creare un FEED RSS a partire dal JSON dei nostri opendata pubblicati qui https://ukrainehelp.emergenzehack.info/en/opendata/

Priorità: bassa
Richiesta

Risolto?

[ ] Ho verificato che il problema è stato risolto

@iltempe penso si possa chiudere

authors: abonte iltempe


text:
ImageButton rounding fix

Updated ImageButton to use rounding from the corresponding image via self.image.image_options().rounding
Closes https://github.com/emilk/egui/issues/3486 if we agree the addition of a rounding() method on the ImageButton itself, which the issue also mentions, can be discussed and handled separately.

One thing I noticed with the current approach in this PR is that when using e.g., rounding(50.0), the border bumps up against the available space and the edge of the circle flattens out ever so slightly (see bottom circle in below screenshot). Is there a way to auto-scale this to account for that? Maybe that is one reason rounding was called out separately to begin with?

I'm fine with this although I'd also like to see the rounding() method. I have no clue why the original code separated out rounding....

I actually agree we need the rounding() method at the same time or else there's no quick way to override if the user chooses. I went ahead and added it in this same PR.
So, now this fully closes #3486
@v-kat let me know what you think and then I'll open for review.

I haven't tried it but it looks okay

You're welcome! Happy to contribute.

authors: chriscate v-kat

repo: emilk/egui


text:
Ustyled prop and close button

Despite setting closeButton: '-right-1 top-2 left-auto text-teal-500 border-none hover:bg-teal-500'
<SonnerToaster
  toastOptions={{
    unstyled: true,
    duration: 100_000,
    closeButton: true,
    classNames: {
      toast: 'group toast rounded-lg flex items-center gap-5 px-4 py-2 pr-6',
      content: ' flex items-center',
      closeButton:
        '-right-1 top-2 left-auto text-teal-500 border-none hover:bg-teal-500',
      success: 'bg-teal-100 border border-teal-200 text-teal-800 text-lg',
    },
  }}
/>

I still get hover style for close button. I dont want this

I encountered the same issue. I believe it makes more sense for the closeButton to have no styles when {unstyled: true} is applied.

authors: cleytoncarvalho rlesniak

repo: emilkowalski/sonner


text:
meta charSet

With react, use charSet instead of charset in meta to set utf-8.

thanks! 👍

authors: emilyaviva millette


text:
Allow dependencies using terminal_size to compile even on non-supported platforms

(Looking at wasm32-wasi here.)

LGTM, thanks!

LGTM, thanks!

This is now published as v0.1.16

This is now published as v0.1.16

authors: eminence jcaesar

repo: eminence/terminal-size