text:
Runtime error due to forgotten name normalization, probably in tail call optimization

While this program works:
import Html

go n = if n > 0 then go (n-1) else 1

main = Html.text (toString (go 5))

this one doesn't:
import Html

go n' = if n' > 0 then go (n'-1) else 1

main = Html.text (toString (go 5))

(Check at http://elm-lang.org/try)
It appears that somewhere during tail call optimization, the name n' is not properly escaped, so the ' is interpreted as start of a string literal.
@evancz or @JoeyEremondi, does this ring a bell with you?

Can you paste the relevant JS in here as well?
Should be a pretty easy fix.

Elm.Main = Elm.Main || {};
Elm.Main.make = function (_elm) {
   "use strict";
   _elm.Main = _elm.Main || {};
   if (_elm.Main.values) return _elm.Main.values;
   var _U = Elm.Native.Utils.make(_elm),
   $Basics = Elm.Basics.make(_elm),
   $Debug = Elm.Debug.make(_elm),
   $Html = Elm.Html.make(_elm),
   $List = Elm.List.make(_elm),
   $Maybe = Elm.Maybe.make(_elm),
   $Result = Elm.Result.make(_elm),
   $Signal = Elm.Signal.make(_elm);
   var _op = {};
   var go = function (n$) {
      go: while (true) if (_U.cmp(n$,0) > 0) {
            var _v0 = n$ - 1;
            n' = _v0;
            continue go;
         } else return 1;
   };
   var main = $Html.text($Basics.toString(go(5)));
   return _elm.Main.values = {_op: _op,go: go,main: main};
};

Most likely, one or more calls of Generate.JavaScript.Variable.safe need to be added somewhere in the tail call optimization code.

Please add an expected js test for it and send a PR. It will make fixing it
much quicker.
On Wednesday, January 6, 2016, Janis Voigtländer notifications@github.com
wrote:

Most likely, one or more calls of Generate.JavaScript.Variable.safe
https://github.com/elm-lang/elm-compiler/blob/2521c5e9c03c89354bb0773bdd0bfb3e197b9d32/src/Generate/JavaScript/Variable.hs#L87-L92
need to be added somewhere in the tail call optimization code.
—
Reply to this email directly or view it on GitHub
https://github.com/elm-lang/elm-compiler/issues/1226#issuecomment-169284077
.

Sorry, but I have to ask: Is there any evidence that bugs are fixed sooner if tests exist for them?

https://github.com/elm-lang/elm-compiler/pull/1250

@jvoigtlaender No there is not. But I believe it's better to break the task into smaller pieces and involve more people. Otherwise Evan gets stuck doing everything.

Yes, yes. I was being a bit snarky, sorry about that. I added a test case above.
About breaking the task into smaller pieces, though: That means that there are now two tickets vying for Evan's attention, namely the bug report ticket and the test case PR. So that might actually not help at all with speeding things up. See, for example, the test case PR https://github.com/elm-lang/elm-compiler/pull/1201 for another bug. That PR remains unmerged, even though it is "just" a test case. I wouldn't be surprised if at some point the underlying bug https://github.com/elm-lang/elm-compiler/issues/1200 gets fixed sooner than the test case is merged. Some procedure is not working here, I'm afraid.

Maybe this is turning into too much meta, but:

But I believe it's better to break the task into smaller pieces and involve more people. Otherwise Evan gets stuck doing everything.

My impression by now is that involving more people in submitting pull requests is not enough, as long as not more people are getting involved in merging pull requests as well.

Okay, I have found the place where the normalization was missing. Fixed in https://github.com/elm-lang/elm-compiler/pull/1251.

You are right about too many issues. Now that you have a fix, you should merge your fix with your test case and close this bug. Then there will be only one PR for Evan to review.

authors: evancz jvoigtlaender laszlopandy

repo: elm-lang/elm-compiler


text:
Add experimental stack-based build system

This adds support for building elm-platform version 0.15.1 from source using stack. All that's needed is the latest stack (via stack upgrade --git) and the 0.15.1 stack.yaml file. Then the user simply needs to run stack install and everything should just work. If they don't have the requisite GHC installed (in this case, 7.10), then stack will install the binary for them and use it for the build.
Pinging @jvoigtlaender

I have no experience with the stack tool (so far have used Stackage only through cabal). It would of course be good to have this install path tested by a few people. Meanwhile, a few questions about what I see in the .yaml file:

Why is it "#0.5" for elm-package? Shouldn't it be "#0.5.1" (and then maybe also a different commit)?
Will the extra-deps setting fsnotify-0.1.0.3 work even though it contradicts what the resolver setting lts-3.2 implicitly declares for fsnotify?

The 0.5 was a bad typo, now fixed. I double checked the SHA1 hash and it's correct.
As for fsnotify, stack appears to honor the versions in extra-deps over what's in the resolver's setting.

Actually, it appears stack does support tags (instead of SHA1 hashes) even though the docs explicitly states it does not.

Okay. Another question: How does this ensure that elm-reactor is built only after elm-make has been built and installed in a place where the build of elm-reactor can already call it? Is the order in which the packages are listed in the .yaml file relevant for this? (And a contraposited question: Does stack use parallel building, i.e., like cabal install -j does?)

Those are excellent points. Yes, stack builds things in parallel, so this won't work if elm-reactor is built first (which is unfortunately a very common occurrence on my machine). The following does work, however:
stack build elm-compiler elm-package elm-make elm-repl
stack build elm-reactor

Or stack install instead of build.

I believe elm-make is listed as a dependency of elm-reactor so shouldn't that ensure that the order is correct?

@evancz, no, there is no such dependency listed for elm-reactor (in the .cabal file). That's also why special care was needed in BuildFromSource.hs to make sure "by hand" that elm-reactor is built last.
I now wonder though: Shouldn't we be able to actually say in elm-reactor.cabal that it needs elm-make to be previously installed? Then both in BuildFromSource.hs and in the stack approach here, things should be more straightforward.
The .cabal file format has a field build-tools. Have you ever tried to use that in some way? Also, for Build-type: Custom, which elm-reactor is, there is a new Cabal feature, mentioned in here that allows declarations like (from an example in that post):
build-type: Custom

custom-setup
  setup-depends: base >= 4.6,
                 directory >= 1.0,
                 Cabal >= 1.18 && < 1.22,
                 acme-setup-tools == 0.2.*

Maybe that could be used to good effect.

Unfortunately, stack seems to not respect dependencies in build-tools, mentioned here. I also tried using it and it didn't work.

I think it makes sense to have docs about stack if core development switches to using stack. Until then, I do not want to "support" two different build paths. One is hard enough!

source: gharchive/pull-request

authors: evancz ianbollinger jvoigtlaender

repo: elm-lang/elm-platform

license_type: permissive

license_source: github-api


text:
new index page can't handle directories that don't have an elm-package.json

You get this in the browser:
A web handler threw an exception. Details:
elm-package.json: openBinaryFile: does not exist (No such file or directory)

Should turn off the special stuff based on elm-package.json and just list the files.

cc @evancz

source: gharchive/issue

repo: elm-lang/elm-reactor


text:
Implement str:join

This presumes PR #928 has been merged; thus, only the last commit is relevant.

It seems that this should somehow be coalesced with the existing joins function, which is implemented here: https://github.com/elves/elvish/blob/master/pkg/eval/builtin_fn_str.go#L286
I'm not sure how I feel about Go library functions that duplicate functionality of existing builtins. Maybe one should just be an alias for the other? @xiaq any thoughts about this?

Note that joins is considerably more limited and annoying, IMHO:
~/projects/3rd-party/elvish> joins : x (float64 111.222333444555666777888999) y [a '' b] '' c [] d
Exception: want 1 or 2 arguments, got 9
[tty], line 1: joins : x (float64 111.222333444555666777888999) y [a '' b] '' c [] d
~/projects/3rd-party/elvish> put x (float64 111.222333444555666777888999) y [a '' b] '' c [] d | joins :
Exception: join wants string input, got !!float64
~/projects/3rd-party/elvish> e = ?(joins : (float64 2))
~/projects/3rd-party/elvish> joins : [x $e]
Exception: join wants string input, got exception

My version handles float64 as well as any other type that implements the elvish Stringer interface:
~/projects/3rd-party/elvish> str:join : x (float64 111.222333444555666777888999) y [a '' b] '' c [] d
▶ x:111.22233344455567:y:a::b::c:d
~/projects/3rd-party/elvish> e = ?(joins : (float64 2))
~/projects/3rd-party/elvish> str:join : x (float64 111.222333444555666777888999) y [a '' b] '' c [] d $e
▶ 'x:111.22233344455567:y:a::b::c:d:?(fail ''!!float64 cannot be iterated'')'

It doesn't, however, read the args from a pipe at the moment --- I'll add that capability:
~/projects/3rd-party/elvish> put x y | str:join :
▶ ''

I've modified the str:join implementation to read from stdin if only a separator string is provided as an argument so you can now do put a b | str:join : or str:join : a b.

BTW, @xiaq, I recognize that my choice of signature for this function is controversial. I won't be hurt if you argue it should use type Inputs and behave like  the joins command with regard to how arguments are specified. I actually wrote a version of this function which works that way. Ultimately I think the idiom this establishes is preferable. It can even be applied to count in a backward compatible fashion by special casing one argument, if it isn't a list, as a string whose char count should be returned.

@xiaq You should ignore this PR until PR #928 is merged. At which point I'll rebase and open a new PR. I'm going to leave this open for the moment in case anyone wants to comment about the API divergence from established builtins like joins.
@zzamboni Note that the str: namespace has other functions that mirror existing builtins. For example, str:has-prefix mirrors has-prefix. Yet they are not explicitly documented as analogs. They are also implemented identically implicitly rather than explicitly. That is, they both directly delegate to the Go strings.HasPrefix() function but neither is defined in terms of the other which is a source of potential confusion and bugs.

@zzamboni See also #576 where @xiaq documents the intent to replace builtins such as joins with a str:join. How best to do so while minimizing transition pain is an open question.

@krader1961 fair enough - thanks for the pointer! I agree it would be best to have the functions within the corresponding namespace eventually.

A week has gone by and there haven't been any comments. So close this until PR #928 is merged at which time I'll open a new PR.

repo: elves/elvish

license_source: bigquery


text:
embark build --contracts doesn't write json files to dist/contracts

Bug Report
Summary

If I run embark build, the files are written, but not if I include the --contracts flag, the files are not written

Nice find. Will add this to our bug dashboard.

it appears embark test doesn't generate these files either. Seems like anytime the contracts are compiled, it would be useful to generate these files

authors: jrainville perissology

repo: embark-framework/embark

license: MIT


text:
Add spi v3 & Full-duplex support to the I2S driver.

I added PoC support to the I2S driver for the spi_v3. This is not fully tested yet, it works for interfacing with the tlv320aic32x4 codec, and it seems to be working fine from my limited testing. I took care to not change much from the configuration other than the necessary changes to make it work with the v3 versions. I also needed to add Full-Duplex support, so I changed the API, I expect that this will be iterated upon, so I see it mostly as a chance to talk about the interface. Not sure about the typestate pattern here, we could also do panicking read/write, but this seems safer.

This breaks Rx-only mode because it internally uses the Tx dma stream in master mode.

I reverted the type-state design to make the review of the spi_v3 changes easier to audit. I removed the Function parameter from the Config since it seems error-prone to expose, especially since we are going to use the Transmitter mode to implement the Rx-only mode. Better to express this through the constructors. I cannot currently test on the spi_v1, the configuration works for the spi_v3 if not for the SPI driver issues regarding the DMA. I will tackle that in another commit.
I also think we should completely change the i2s API so that it uses the DMA circular mode similar to the RingBufferedUsart variant. Probably worth discussing on a separate issue as well.

repo: embassy-rs/embassy


text:
"hostAddon.cacheKeyForTree is not a function

We're getting this error when building our project with v5.5 - v5.8 version 5.4 builds fine.
hostAddon.cacheKeyForTree is not a function
TypeError: hostAddon.cacheKeyForTree is not a function
at .../node_modules/ember-engines/lib/engine-addon.js:382:49
at Array.map (native)
at Class.options.nonDuplicatedAddonInvoke (.../ember-deployment/node_modules/ember-engines/lib/engine-addon.js:372:26)
at Class.buildVendorTree (.../node_modules/ember-engines/lib/engine-addon.js:129:36)
at Class._memoize (.../node_modules/ember-engines/lib/utils/memoize.js:10:38)
at Class.buildCompleteJSTree (.../node_modules/ember-engines/lib/engine-addon.js:255:36)
at Class._memoize (.../node_modules/ember-engines/lib/utils/memoize.js:10:38)
at Class.treeForEngine (.../node_modules/ember-engines/lib/engine-addon.js:540:50)
at Class.treeFor (.../node_modules/ember-engines/lib/engine-addon.js:928:25)
here is our NPM dependencies
"devDependencies": {
"broccoli-asset-rev": "^2.4.5",
"ember-ajax": "^2.4.1",
"ember-cli": "2.12.1",
"ember-cli-app-version": "^2.0.0",
"ember-cli-babel": "^5.1.7",
"ember-cli-cdn": "2.1.0",
"ember-cli-content-security-policy": "0.6.1",
"ember-cli-dependency-checker": "^1.3.0",
"ember-cli-deploy": "^1.0.0",
"ember-cli-deploy-build": "^1.0.0",
"ember-cli-deploy-display-revisions": "^1.0.0",
"ember-cli-deploy-gzip": "^1.0.0",
"ember-cli-deploy-revision-data": "^1.0.0",
"ember-cli-deploy-s3": "^1.0.0",
"ember-cli-deploy-s3-index": "^1.0.0",
"ember-cli-deploy-slack": "^1.0.0",
"ember-cli-document-title": "0.3.3",
"ember-cli-eslint": "^3.0.0",
"ember-cli-g-maps": "0.5.10",
"ember-cli-htmlbars": "^1.1.1",
"ember-cli-htmlbars-inline-precompile": "^0.3.6",
"ember-cli-inject-live-reload": "^1.4.1",
"ember-cli-mirage": "0.1.13",
"ember-cli-qunit": "^3.1.0",
"ember-cli-sass": "~6.1.1",
"ember-cli-selectize": "enderlabs/ember-cli-selectize.git#v0.4.5",
"ember-cli-sentry": "2.4.3",
"ember-cli-shims": "^1.0.2",
"ember-cli-sri": "^2.1.0",
"ember-cli-sticky": "0.6.2",
"ember-cli-uglify": "^1.2.0",
"ember-concurrency": "~0.8.1",
"ember-data": "2.12.1",
"ember-data-model-fragments": "2.11.2",
"ember-engines": "^0.5.0",
"ember-export-application-global": "^1.0.5",
"ember-inflector": "1.11.0",
"ember-load-initializers": "^0.6.0",
"ember-local-storage": "~1.3.6",
"ember-metrics": "0.10.0",
"ember-modal-dialog": "v2.0.0-beta.0",
"ember-power-select": "~1.7.0",
"ember-power-select-with-create": "~0.4.3",
"ember-resolver": "^2.0.3",
"ember-source": "~2.12.0",
"ember-tether": "0.4.1",
"ember-toastr": "~1.5.0",
"ember-tooltips": "2.9.0-beta.0",
"ember-truth-helpers": "^1.3.0",
"ember-validations": "2.0.0-alpha.5",
"ember-wormhole": "~0.5.1",
"liquid-fire": "~0.27.0",
"loader.js": "^4.2.3"
},
"dependencies": {
[... removed internal addons ]
"ember-engines": "^0.5.0",
picker.git#~v1.0.0"
}
p.s. Thank you very much for all your contributions. The effort we are able to leverage and use is amazing. It empowers and employs us.

I should add that this happening with a lazy loaded engine

I believe that the issue is thatcacheKeyForTree is only added in ember-cli@2.13+.

@rwjblue This also happens in our case with a lazy loading engine and ember-cli 2.12.0.

Yep, we need to guard the invocation of cacheKeyForTree (if not present on an addon we would default to no caching).

@rwjblue I did dig a little bit into  the calculate-cache-key-for-tree Addon - if I got the concept right it makes total sense to avoid redundancies. I just have no clue how to utilize the Addon - documentation is sparse...

Fixed by #469

@peStoney may be you start with how it's been used here: https://github.com/ember-engines/ember-engines/blob/master/lib/engine-addon.js#L319

@akashdsouza Thanks! I think I'm getting it - actually every addon used in an engine needs to implement cachKeyForTree(). Is this correct?

@peStoney the EmberAddon base class implements cacheKeyForTree by default. So as long as you're on a version of Ember-CLI that has cacheKeyForTree, all addons will have it by default. That said, addons that customize any of the treeFor hooks would want to reimplement the cacheKeyForTree hook to opt back in to caching.
For more details and background, check out the RFC for that hook: https://github.com/ember-cli/rfcs/blob/master/complete/0090-addon-tree-caching.md

authors: akashdsouza bbtb1982 peStoney rwjblue tomoguisuru trentmwillis

repo: ember-engines/ember-engines

license: mit


text:
When choosing teams to copy, all options should be DESELCTED by default

Right now they're all selected, leading to confusion since the prompt tells you to select what you want. Also, it's more likely you're only adding one or two teams, not all, so that's a quicker way anyway.

For context, the Ember org has 100 teams, so having to deselect all teams is a nuisance

Inquirer seems to be having the "select/deselect all" feature in the works, SBoudrias/Inquirer.js#347. Once that lands there, we can probably add those two options and deselect all by default.

Inquirer now supports 'deselect all' which I've upgraded to in a patch release. So by default we still select all teams but users can now press i and proceed to select ones they're interested in.

If we need to leave all unselected by default, do reopen this issue and I'll make it the default behavior.

@sivakumar-kailasam leaving all unselected by default sounded like the ideal use case, let's shift to doing things that way ...

Fixed in v6.0.3.

authors: acorncom sivakumar-kailasam wifelette

repo: ember-learn/gh-team-copy


text:
Question about 3D point cloud feature extraction

Hello Jiangyong,
Thanks for your work LEO. Its object-centric 3D representation impresses me deeply.
When I try to extract object point cloud by Mask3D as your paper described, I find Mask3D's performance is not very convincing (missing / wrong predictions). I use the "scannet200_benchmark.ckpt" as Mask3D checkpoint and set the confidence_threshold to 0.7.
However, I further test Mask3D web demo (https://francisengelmann.github.io/mask3d/) . Its performance is extremely good.
Therefore, I am wondering how you extract object-centric 3D representation by Mask3D. Can you achieve the same performance as their web demo?

Resolved in personal communication. The performance of running script is comparable to web demo when using the right script (scannet200_val.sh).

repo: embodied-generalist/embodied-generalist


text:
Remove default ciProvider in appOptions

fix #289
We should avoid to set travis as default value for ciProvider, because in this case the test-app has in ember-cli-update.json as option --ci-provider=travis.
Travis was deprecated in v5 see https://deprecations.emberjs.com/ember-cli/v5.x/#toc_travis-ci-support

Thank you!

authors: mkszepp simonihmig

repo: embroider-build/addon-blueprint


text:
Add support for npm and pnpm

The current released version of the addon-blueprint only provides yarn.
This PR:

adds the ability to use npm workspaces
adds the ability to pnpm workspaces
adds tests for npm, pnpm, and yarn
keeps scripts commands/behavior between the 3 package managers the same

Closes: https://github.com/embroider-build/addon-blueprint/issues/35

I agree with @simonihmig that the pnpm error handling should change before this can merge.
Instead of ignoring exceptions there is a precise way to disable the strict peer dep checking.

except we don't want to disable strict peer dep checking, so that's not exactly a solution. We want strict peer dep checking. The only problem is the @babel/core thing, which I have a PR here (from 3 weeks ago): https://github.com/babel/ember-cli-babel/pull/452
Once the @babel/core issue is resolved in ember-cli-babel, the will be no issue for pnpm to throw an error for, and the exception handling can be removed.

I agree. But the current exception-trapping approach already ignores strict peer dep failures.
My suggestion is to only ignore strict peer dep failures while allowing any other pnpm error to propagate.
When the underlying blueprint is corrected we would remove the setting, same as what you're suggesting with removing the exception trap.

I've updated the PR to do specific error-catching, rather than over-error catching.
ready for re-review, @simonihmig and @ef4 <3


text:
invalid arguments for zwlr_output_configuration_v1@5.enable_head

Not sure what happened. Logs:
applying profile '<anonymous at line 1, col 1>'
applying profile output 'LVDS-1' on connected head 'LVDS-1'
applying profile output 'VGA-1' on connected head 'VGA-1'
applying profile output 'HDMI-A-3' on connected head 'HDMI-A-3'
running commands for configuration '<anonymous at line 1, col 1>'
configuration for profile '<anonymous at line 1, col 1>' applied
applying profile '<anonymous at line 15, col 1>'
applying profile output 'LVDS-1' on connected head 'LVDS-1'
applying profile output '*' on connected head 'HDMI-A-3'
applying profile '<anonymous at line 7, col 1>'
applying profile output 'LVDS-1' on connected head 'LVDS-1'
wl_display@1: error 1: invalid arguments for zwlr_output_configuration_v1@5.enable_head

Config:
{
	output LVDS-1 disable
	output HDMI-A-3 position 0,0 mode 1680x1050
	output VGA-1 position 1680,0 mode 1680x1050
}

{
	output LVDS-1 position 0,0
}

{
	output * position 0,0 scale 1
}

{
	output LVDS-1
	output *
}

Actually this is a race that happens when undocking. Kanshi is fine, this is a wlroots bug.
[624616.229] zwlr_output_mode_v1@4278190117.finished()
[624616.250] zwlr_output_mode_v1@4278190116.finished()
[624616.264] zwlr_output_mode_v1@4278190115.finished()
[624616.276] zwlr_output_mode_v1@4278190114.finished()
[624616.288] zwlr_output_mode_v1@4278190113.finished()
[624616.300] zwlr_output_mode_v1@4278190112.finished()
[624616.312] zwlr_output_mode_v1@4278190111.finished()
[624616.324] zwlr_output_mode_v1@4278190110.finished()
[624616.337] zwlr_output_mode_v1@4278190109.finished()
[624616.349] zwlr_output_mode_v1@4278190108.finished()
[624616.361] zwlr_output_mode_v1@4278190107.finished()
[624616.373] zwlr_output_mode_v1@4278190106.finished()
[624616.385] zwlr_output_mode_v1@4278190105.finished()
[624616.397] zwlr_output_mode_v1@4278190104.finished()
[624616.409] zwlr_output_mode_v1@4278190103.finished()
[624616.421] zwlr_output_mode_v1@4278190102.finished()
[624616.433] zwlr_output_mode_v1@4278190101.finished()
[624616.446] zwlr_output_mode_v1@4278190100.finished()
[624616.458] zwlr_output_head_v1@4278190099.finished()
[624616.480] zwlr_output_manager_v1@3.done(100)
applying profile '<anonymous at line 15, col 1>'
[624616.517]  -> zwlr_output_manager_v1@3.create_configuration(new id zwlr_output_configuration_v1@5, 100)
applying profile output 'LVDS-1' on connected head 'LVDS-1'
[624616.564]  -> zwlr_output_configuration_v1@5.disable_head(zwlr_output_head_v1@4278190118)
applying profile output '*' on connected head 'HDMI-A-3'
[624616.605]  -> zwlr_output_configuration_v1@5.enable_head(new id zwlr_output_configuration_head_v1@4, zwlr_output_head_v1@4278190080)
[624616.643]  -> zwlr_output_configuration_v1@5.apply()
[624616.661] wl_registry@2.global_remove(28)
[624616.683] zwlr_output_mode_v1@4278190098.finished()
[624616.700] zwlr_output_mode_v1@4278190097.finished()
[624616.717] zwlr_output_mode_v1@4278190096.finished()
[624616.733] zwlr_output_mode_v1@4278190095.finished()
[624616.750] zwlr_output_mode_v1@4278190094.finished()
[624616.768] zwlr_output_mode_v1@4278190093.finished()
[624616.786] zwlr_output_mode_v1@4278190092.finished()
[624616.803] zwlr_output_mode_v1@4278190091.finished()
[624616.829] zwlr_output_mode_v1@4278190090.finished()
[624616.844] zwlr_output_mode_v1@4278190089.finished()
[624616.858] zwlr_output_mode_v1@4278190088.finished()
[624616.872] zwlr_output_mode_v1@4278190087.finished()
[624616.885] zwlr_output_mode_v1@4278190086.finished()
[624616.900] zwlr_output_mode_v1@4278190085.finished()
[624616.915] zwlr_output_mode_v1@4278190084.finished()
[624616.929] zwlr_output_mode_v1@4278190083.finished()
[624616.942] zwlr_output_mode_v1@4278190082.finished()
[624616.956] zwlr_output_mode_v1@4278190081.finished()
[624616.968] zwlr_output_head_v1@4278190080.finished()
[624616.980] zwlr_output_manager_v1@3.done(101)
applying profile '<anonymous at line 7, col 1>'
[624617.005]  -> zwlr_output_manager_v1@3.create_configuration(new id zwlr_output_configuration_v1@8, 101)
applying profile output 'LVDS-1' on connected head 'LVDS-1'
[624617.038]  -> zwlr_output_configuration_v1@8.enable_head(new id zwlr_output_configuration_head_v1@9, zwlr_output_head_v1@4278190118)
[624617.064]  -> zwlr_output_configuration_head_v1@9.set_position(0, 0)
[624617.085]  -> zwlr_output_configuration_v1@8.apply()
[624617.097] wl_registry@2.global_remove(29)
[624891.586] zwlr_output_head_v1@4278190118.enabled(1)
[624891.695] zwlr_output_head_v1@4278190118.current_mode(zwlr_output_mode_v1@4278190120)
[624891.769] zwlr_output_manager_v1@3.done(102)
applying profile '<anonymous at line 7, col 1>'
[624891.801]  -> zwlr_output_manager_v1@3.create_configuration(new id zwlr_output_configuration_v1@10, 102)
applying profile output 'LVDS-1' on connected head 'LVDS-1'
[624891.854]  -> zwlr_output_configuration_v1@10.enable_head(new id zwlr_output_configuration_head_v1@11, zwlr_output_head_v1@4278190118)
[624891.895]  -> zwlr_output_configuration_head_v1@11.set_position(0, 0)
[624891.923]  -> zwlr_output_configuration_v1@10.apply()
[624891.941] wl_registry@2.global(30, "wl_output", 3)
[624892.155] wl_display@1.error(wl_display@1, 1, "invalid arguments for zwlr_output_configuration_v1@5.enable_head")
wl_display@1: error 1: invalid arguments for zwlr_output_configuration_v1@5.enable_head

https://github.com/swaywm/wlr-protocols/issues/62

repo: emersion/kanshi


text:
Toggling a CollapsingHeader in a ComboBox closes the whole ComboBox

Describe the bug
Putting a CollapsingHeader inside a ComboBox closes the ComboBox whenever you try to toggle the CollapsingHeader
To Reproduce
Steps to reproduce the behavior:

Create a ComboBox
Put a CollapsingHeader inside
Toggle the CollapsingHeader

egui::ComboBox::from_label("Version")
    .width(150.0)
    .selected_text(selected_version)
    .show_ui(ui, |ui| {
        egui::CollapsingHeader::new("Dev")
            .default_open(true)
            .show(ui, |ui| {
                for version in versions.iter() {
                    ui.selectable_value(&mut selected_version, &version, *version);
                }
            });
    });

Expected behavior
The CollapsingHeader should be able to open/close without the ComboBox closing
Screenshots

System
OS: Windows10 20H2

This also happens in menu bars, which is quite annoying to say the least.

Instead of "significant", what about a "used" flag set when some widget "uses" the event? The following widgets could read that used flag and act or not anyway. In this case, the click would close the combobox only if the click was not used by some inner widget.

After scouring for a while through the source code, I have a concrete proposal that expands on @msklywenn's idea. We could add a used attribute to the Ui type itself. We would add a chaining operator .used(self, bool) so that a user can manually set this attribute. And to avoid issues like this propping up, we could figure out reasonable defaults for every Widget (buttons are used, menus are not, etc.).
The value of this attribute would then be propagated through Response, and would be read by a ComboBox or a Menu to determine whether to close due to the Response returned by its controls.
If this seems like a reasonable proposal, then I'd be happy to help implement it.

So... what about this? Is my proposal a good idea? Are there any other ways we could get around this?

Perhaps this could be solved by re-implementing comboboxes using https://github.com/emilk/egui/pull/543

Just tried it, seems like it works :+1:

Should be very easy to use this for the ComboBox menu.. but that would mean we need to manually call ui.close_menu() to close the menu. Maybe this kind of defeats the purpose of ComboBox as opposed to a regular egui::menu? Maybe except for the arrow icon?

@vihdzp @msklywenn I also used a propagation system like this to cascade the close command through the menu hierarchy. You have to call a function though when you want the menu to close. But I could imagine widgets triggering this internally when some flag is set. you just need a Ui from the menu hierarchy, which can close all parent menus.

authors: LeagueRaINi OfficialURL emilk mankinskin msklywenn

repo: emilk/egui


text:
Drying temperature range / obsolete barrel removal ver. 2

Same as before, except I changed the minimum temperature to 1C so the "Freezing" string from UF makes sense.

Thanks for the help, been on my list of things to fix for a while!


text:
What is IC task?🫶

Hi bro, i read your papaer, and there is a sentence "Table I summarizes the deployment results on the NUCLEO-H743ZI2 for the IC and VWW benchmarks. ", i know what is VWW, but what is IC benchmarks? thanks!

Dear Wenhao, IC stands for Image Classification. In particular, you can refer to the generic code as it is implemented in our pytorch-benchmarks library.
Best,
Matteo

authors: callmewenhao matteorisso

repo: eml-eda/multi-constraint-nas


text:
Installation error [v1.9]

Hello,
I attempted to install Emmet but Brackets said me that an error has occured.
NOTE: I'm using an old version of Brackets because I'm on a school computer.
Brackets version: 1.9 édition 1.9.0-17312 (release 189f6d39a)

Hi @ghost!
I had the same issue yesterday. Please, make sure you disabled every other extension, removed the faild Emmet installation, and restarted Brackets before attempting to install Emmet again.
Worked for me.
Hope you'll find this helpful :)

repo: emmetio/brackets-emmet


text:
Strange error with starlette / fastapi

Hi there
I've been trying to use startlette on some app of mine, and it worked well locally. In production however I get this strange error:
2024-06-07T11:34:36.7225565Z [ERROR] Application callable raised an exception
2024-06-07T11:34:36.7225739Z Traceback (most recent call last):
2024-06-07T11:34:36.7225904Z   File "/tmp/8dc86c846d0f82f/antenv/lib/python3.12/site-packages/granian/_futures.py", line 4, in future_watcher
2024-06-07T11:34:36.7226079Z     await inner(watcher.scope, watcher.proto)
2024-06-07T11:34:36.7226217Z   File "/tmp/8dc86c846d0f82f/antenv/lib/python3.12/site-packages/fastapi/applications.py", line 1054, in __call__
2024-06-07T11:34:36.7226374Z     await super().__call__(scope, receive, send)
2024-06-07T11:34:36.7226523Z   File "/tmp/8dc86c846d0f82f/antenv/lib/python3.12/site-packages/starlette/applications.py", line 123, in __call__
2024-06-07T11:34:36.7226660Z     await self.middleware_stack(scope, receive, send)
2024-06-07T11:34:36.7226814Z   File "/tmp/8dc86c846d0f82f/antenv/lib/python3.12/site-packages/starlette/middleware/errors.py", line 186, in __call__
2024-06-07T11:34:36.7226968Z     raise exc
2024-06-07T11:34:36.7227101Z   File "/tmp/8dc86c846d0f82f/antenv/lib/python3.12/site-packages/starlette/middleware/errors.py", line 164, in __call__
2024-06-07T11:34:36.7227252Z     await self.app(scope, receive, _send)
2024-06-07T11:34:36.7227387Z   File "/tmp/8dc86c846d0f82f/antenv/lib/python3.12/site-packages/starlette/middleware/base.py", line 189, in __call__
2024-06-07T11:34:36.7227541Z     with collapse_excgroups():
2024-06-07T11:34:36.7227683Z   File "/opt/python/3.12.2/lib/python3.12/contextlib.py", line 158, in __exit__
2024-06-07T11:34:36.7228228Z     self.gen.throw(value)
2024-06-07T11:34:36.7228459Z   File "/tmp/8dc86c846d0f82f/antenv/lib/python3.12/site-packages/starlette/_utils.py", line 93, in collapse_excgroups
2024-06-07T11:34:36.7228673Z     raise exc
2024-06-07T11:34:36.7228908Z   File "/tmp/8dc86c846d0f82f/antenv/lib/python3.12/site-packages/starlette/responses.py", line 261, in wrap
2024-06-07T11:34:36.7229135Z     await func()
2024-06-07T11:34:36.7229335Z   File "/tmp/8dc86c846d0f82f/antenv/lib/python3.12/site-packages/starlette/middleware/base.py", line 217, in stream_response
2024-06-07T11:34:36.7229559Z     return await super().stream_response(send)
2024-06-07T11:34:36.7229770Z            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2024-06-07T11:34:36.7229969Z   File "/tmp/8dc86c846d0f82f/antenv/lib/python3.12/site-packages/starlette/responses.py", line 250, in stream_response
2024-06-07T11:34:36.7230213Z     async for chunk in self.body_iterator:
2024-06-07T11:34:36.7230411Z   File "/tmp/8dc86c846d0f82f/antenv/lib/python3.12/site-packages/starlette/middleware/base.py", line 173, in body_stream
2024-06-07T11:34:36.7230571Z     assert message["type"] == "http.response.body"

My startup command is granian application:app --host 0.0.0.0 --port 8000 --workers 2 --interface asgi --loop asyncio
The route producing the error is very simple (starlette/fastapi)

rr = RedirectResponse(flow["auth_uri"])
rr.set_cookie("flow", json.dumps(flow, default=str), max_age=180)  # Temp cookie during auth flow
rr.headers.append("Cache-Control", "no-cache, max-age=0")

return rr

Any idea what could cause such an error?

This looks like #216.
Even after the long discussions and debugging, it's still unclear to me why Starlette fails in using its own response stream code (that assertion checks a ASGI message sent by starlette, not Granian).
I don't have any quick solution for this, I might spend some time trying to debug Starlette internals with Granian in the following weeks, but I'm not sure it will lead to any result.
Just a quick thing: any specific reason you're explicitly avoiding uvloop on a Unix OS? My gut tells me this is some concurrency issue with Starlette, uvloop might just automagically solve it.

The --loop was just an attempt to fix it, it's the same behavior. FYI: My Production Environment uses Linux and Python 3.12, it's an azure website

@aersam can you please provide a MRE including (but not limited to) the list of middlewares you're using?

The MRE is hard since I could not reproduce this, not on Windows nor on WSL. But I monkey-patched Starlette and have a better error message now :)
AssertionError: Unexpected message of type http.response.pathsend from class <class 'starlette.middleware.base.BaseHTTPMiddleware'>: {'type': 'http.response.pathsend', 'path': 'frontend_app/output/index.html'}

The MRE is hard since I could not reproduce this, not on Windows nor on WSL. But I monkey-patched Starlette and have a better error message now :)
AssertionError: Unexpected message of type http.response.pathsend from class <class 'starlette.middleware.base.BaseHTTPMiddleware'>: {'type': 'http.response.pathsend', 'path': 'frontend_app/output/index.html'}

Oh, that's actually a Starlette bug then!
Can you please open an issue in the Starlette repo mentioning this as the starting point?
cc @Kludex

I'm closing this since we now have https://github.com/encode/starlette/issues/2613 and https://github.com/encode/starlette/pull/2616

repo: emmett-framework/granian


text:
Menus not working on GNOME Shell 3.36.2 + Mutter WM 3.36.2

Here's a screenshot of the menu.rs example running on GNOME Shell 3.36.2 + Mutter WM 3.36.2 (as part of a stock Pop!_OS 20.04 install).

Interestingly enough, get_unix_menus() still returns a value (as shown in the console output in the screenshot).
Let me know if you need any more info, or if you'd like me to test out any patches.
And thanks for making such a great little library!

You know what, I'm totally blind, and I completely misread the docs.

Linux/BSD/etc:
Menus aren't supported as they depend on each WindowManager and is outside of the
scope for this library to support. Use [get_unix_menus] to get a structure

Sorry for the issue spam!


text:
Vulkan testing

Latest commit added hooks that should let Vulkan titles work with it (eg. RDR2), I don't currently have any VK games to try with myself though, would appreciate anyone trying it out.
Build can be found here:
dlsstweaks-0.123.8.zip
If you try it out let me know how it goes, either here or on the reddit post: https://www.reddit.com/r/nvidia/comments/111e0xi/dlsstweaks_dll_hook_that_can_force_dlaa_onto/

Can confirm it works.

Nice, I've pushed that as a release then.
Not really sure how complete the VK hooks are though, could still be some VK titles that have issues, if anyone finds one feel free to shout at me here.

Also works in Doom Eternal for me.

Seems to be stable enough, I'll close this now then, if anyone does run into any issues with a vulkan game feel free to make a post about it.

authors: aufkrawall doktorsleepelss emoose

repo: emoose/DLSSTweaks


text:
WRO-697: Use babel-preset-enact-app's babel config

Checklist

[x] I have read and understand the contribution guide
[x] A CHANGELOG entry is included
[ ] At least one test case is included for this feature or bug fix
[x] Documentation was added or is not needed
[ ] This is an API breaking change

Issue Resolved / Feature Added
There are three repos (cli, storybook-utils, eslint-config-enact) that set the babel config.
It is necessary to change the structure so that this babel config is integrated into one preset and used in three repos.
This makes maintenance and management easier.
Resolution
Use babel-preset-enact-app's babel config
Additional Considerations
Links
WRO-697
Comments
Enact-DCO-1.0-Signed-off-by: Taeyoung Hong (taeyoung.hong@lge.com)

I'm sorry but would you please update the branch with the recent develop branch?

repo: enactjs/storybook-utils


text:
Re-issue command line args

This will be a breaking change

Re-issued and cleaned up CLI args

repo: enckse/lwvmm


text:
Changeable value of variable TEST_CREATE_EXPECTED_OUTPUT

if 'TEST_CREATE_EXPECTED_OUTPUT' in os.environ:

With this condition we just check if variable with that name exists. There is no any behavior changes in tests, when we set value of variable to zero

It would be great to document TEST_CREATE_EXPECTED_OUTPUT in the README as well.

authors: encukou nappex

repo: encukou/freezeyt


text:
Sorting of releases with multi digit version parts

The minor version of Elasticsearch can be double digit, e.g. 7.10 and 7.11. The sorting by releaseCycle is wrong in this case, e.g. 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.3, 7.2, 7.1, 7.11, 7.10.
In #195 I did a workaround with a virtual number in cycleShortHand and sorted by this. I think this could be a problem also in other tools.
The idea is to extend the sorting of such version numbers in _layouts/post.html.

The sort_natural filter doesn't work, so perhaps we need a sort_version filter of our own.

@usta @captn3m0 Um, I may be missing something obvious at the moment, but why exactly are we letting the stupid machine reorder our releases (and often screw it up) in the first place?
I see that the sorting was introduced in https://github.com/endoflife-date/endoflife.date/pull/42, which references issue https://github.com/endoflife-date/endoflife.date/issues/25. And @captn3m0 writes this in the initial issue comment https://github.com/endoflife-date/endoflife.date/issues/25#issue-449980583:

It makes sense to sort by release date (in desc order
so newer releases are at the top).
(...)
Since releases are a map currently, it is hard to sort them.

This is no longer relevant, because releases are lists now, not maps. See just about any product page source:
https://github.com/endoflife-date/endoflife.date/blob/383f38456a839d8772b96105726ccf431797fb8d/products/python.md?plain=1#L16-L27
Lists in YAML are guaranteed to preserve order, so the sorting is not needed - if you don't sort it, it will always have exactly the same order in which you specify individual releases.
So I really think we should drop this |sort here:
https://github.com/endoflife-date/endoflife.date/blob/383f38456a839d8772b96105726ccf431797fb8d/_layouts/product.html#L30-L31
and just {% for r in page.releases %}. By doing this, we finally put trust into humans that they know in what order they want releases to be displayed.

I like this idea, would clean up the code as well.

authors: BiNZGi captn3m0 generalmimon


text:
Add Java 17

Adds Java 17 using info from https://www.oracle.com/news/announcement/oracle-releases-java-17-2021-09-14/.

Oracle JDK 17 and future JDK releases are provided under a free-to-use license until a full year after the next LTS release.

Doesn't this mean that JDK 17 will be supported for likely much longer than just six months? Where did the March 2022 EOL date come from? The article referenced says this:

Oracle JDK 17 gives customers security, performance, and bug-fix updates through September 2029

True, I didn't pay enough attention putting this PR together and missed the LTS. But I've been reading up more on what LTS means for OpenJDK lately and I think many people are under the impression that using LTS releases provides some sort of "extended support" for free. I was reading that this isn't actually the case.
https://www.oracle.com/java/technologies/java-se-support-roadmap.html

Java SE 11 however is an LTS release, and therefore Oracle Customers will receive Oracle Premier Support and periodic update releases, even though Java SE 12 was released.

So it sounds like the only way to get this "Oracle Premier Support" that is available for LTS releases is to be an "Oracle Customer".
I was also reading more about this from a post on Reddit I saved:
https://www.reddit.com/r/java/comments/ho4wxe/what_is_the_importance_of_java_lts/fxfxkd0

Unlike in other ecosystems, Java does not have LTS versions. Rather, LTS is a paid service of extended support offered by various companies to arbitrarily-selected Java versions.
...
Most LTS services are derived from OpenJDK Updates projects, that backport fixes from the current JDK mainline to some old version. There are free builds of the Updates projects that some mistake for a "free LTS", but they are not. Unlike the LTS services derived from Updates, the Updates themselves are only partly supported
...
If a component has been removed from the mainline, there is nothing to backport, and so those components (like CMS and Nashorn and some core library packages) are unmaintained in Updates
I think that some companies deploy on the free Updates releases, which increases both their cost and their risk (as those builds are not as well maintained as the current version or the LTS services), but I think that is mostly due to a misunderstanding of the options.
...
only a skeleton crew maintains the Updates projects.

This user states that the way to get the most support for free is to run the latest Java version, not the latest "LTS" version. Perhaps before this is corrected and merged in, we should clarify that the "supported until" on the Java page for this site refers to Oracle paid support and best effort attempts to get fixes backported, and that it isn't recommended to choose an LTS version when a more recent version is available.

This user states that the way to get the most support for free is to run the latest Java version, not the latest "LTS" version. Perhaps before this is corrected and merged in, we should clarify that the "supported until" on the Java page for this site refers to Oracle paid support and best effort attempts to get fixes backported, and that it isn't recommended to choose an LTS version when a more recent version is available.

This is rather annoying. Honestly this issue is pragmatic of the entire Java entry. We have for example OpenJDK which does offer free LTS (such as OpenJDK 11 LTS), Microsoft's own OpenJDK branches, then RedHat also providing LTS for free, and for a different amount of time.
This is such a nightmare. Honestly my recommendation would be to create a separate entry for each and every different project that is maintaining their own Java build. I think this current approach of having all of them together is not a good idea.

This is such a nightmare. Honestly my recommendation would be to create a separate entry for each and every different project that is maintaining their own Java build. I think this current approach of having all of them together is not a good idea.

I was thinking the same thing after trying my best to sort through this stuff tonight. I like Java, but holy shit do they make this more complicated than it needs to be. Because there's no authoritative source for built releases, instead having many vendors which each appear to have a different commitment to backporting fixes, we should split this page up. For example, the link in my previous comment already shows two different "public fixes available until" date for Azul's and Microsoft's releases.

Can this PR be merged? We can continue the "Java versioning" here: https://github.com/endoflife-date/endoflife.date/discussions/364

Sure. I used 2026-09-30 for "support" and "eol" in the data in this PR, which can be used as a placeholder until the Java community understands more what subset of the patches in the paid Oracle support packages ends up in the free LTS builds provided by projects such as Eclipse Adoptium.
Note how Oracle has two dates listed on their site. One is "September 2026 Or later" and one is "September 2029 Or later", depending on the Oracle support package you purchase. I chose the earlier of the two dates to play safe while things get figured out:

https://www.oracle.com/java/technologies/java-se-support-roadmap.html

Netlify hooks appear to be failing because the build won't complete. It complains about an invalid date in an error message from the Jekyll library but doesn't say what date value was invalid or for which language in this repo an invalid date was provided.
I do see, in the logs:
5:29:37 PM: ────────────────────────────────────────────────────────────────
5:29:37 PM:   "build.command" failed
5:29:37 PM: ────────────────────────────────────────────────────────────────
5:29:37 PM:
5:29:37 PM:   Error message
5:29:37 PM:   Command failed with exit code 1:   rake gke
5:29:37 PM:     jekyll build
5:29:37 PM:
5:29:37 PM:   Error location
5:29:37 PM:   In build.command from netlify.toml:
5:29:37 PM:     rake gke
5:29:37 PM:     jekyll build
5:29:37 PM:
5:29:37 PM:   Resolved config
5:29:37 PM:   build:
5:29:37 PM:     command: |2-
5:29:37 PM:         rake gke
5:29:37 PM:         jekyll build
5:29:37 PM:
5:29:37 PM:     commandOrigin: config
5:29:37 PM:     environment:
5:29:37 PM:       - GOOGLE_CLOUD_SERVICE_ACCOUNT
5:29:37 PM:       - REVIEW_ID
5:29:37 PM:     publish: /opt/build/repo/_site
5:29:37 PM:     publishOrigin: config
5:29:37 PM:   headers:
5:29:37 PM:     - for: /*

But I'm not sure if "gke" here refers to information related to Google Kubernetes Engine that contributors may have submitted or if it refers to the fact that this website is deployed to a GKE cluster.

Ah. Perhaps I should RTFM.
The instructions in HACKING.md clearly state that the "gke" rake task is about fetching information about GKE dynamically at build time.
So the site's build process appears to have broken recently. We'll have to get that fixed before this can be merged in.

One more note. I see that so far, the community maintaining this information source has been using Oracle's "Premier Support Until" date for the "support" value here, and Oracle's "Extended Support Until" date for the "eol" value here for some Java version, like 11:
- releaseCycle: "10"
  release: 2018-03-20
  support: 2018-09-25
  eol: 2018-09-25
  latest: "10.0.2"

That's already inconsistent with the information for Java 8 now that Oracle has decided to offer paid services to maintain Java 8 even longer, to 2030:
- releaseCycle: "8"
  lts: true
  release: 2014-03-18
  support: 2022-03-31
  eol: 2025-03-31
  latest: "8u301"

However, for this PR, I should probably make it as consistent as possible. I changed the PR to use the two Oracle dates as our "support" and "eol" values for Java 11. However, I didn't change the old Java 8 information. It's still set to 2025-03-31 for "eol".

@mattwelke There a prior discussion here on Java8 that might help a bit: https://github.com/endoflife-date/endoflife.date/pull/355 (Not much, because Java versioning (╯°□°）╯︵ ┻━┻)

Thanks a lot @mattwelke for your contribution 🥇

authors: Evernow captn3m0 mattwelke


text:
PHP For Loop Variable Increment Bug

Running the following test code over the API:
<?php

$myArray = ["My", "Pretty", "Array"];

for($x = 0; $x < count($myArray); $x++){
  echo $myArray[$x];
}

should result in this:
MyPrettyArray

but instead results in this:
MyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMyMy [...]

Now, I don't know what the issue is exactly... It seems $x does not increment as it should. Very weird. If I write a "manual" for-loop it still does the same thing. When I do not echo $myArray[$x]; it just says "Killed", so apparently the Code execution gets cut off after a certain amount of time.
I used POST to send the code via PHP cURL to the API.
Running the same code in any other service (or locally in a php server) results in the correct, wanted result.
And this behaviour has only appeared for me with this example.

I'd be happy to be corrected if the problem lies on my end.

im not sure, I just tried it and it worked as expected. are you positive you are sending that exact code? can you supply the exact php code you used to send the above code to the piston api?

Okay, here is the exact code:
    public function calculate(){
        $data = $this->data;
        $language = $this->language;
        $return = json_decode($this->apicall("https://emkc.org/api/v1/piston/execute", "source=$data&language=$language"), true);
        $this->return = $return;
        return $return["output"];
    }

    private function apicall($url, $postvars){
        $ch = curl_init();
        $config['useragent'] = 'dev@myocto.de';
        curl_setopt($ch, CURLOPT_URL, $url);
        curl_setopt($ch, CURLOPT_POST, 1);
        curl_setopt($ch, CURLOPT_POSTFIELDS, $postvars);
        curl_setopt($ch, CURLOPT_FAILONERROR, 1);
        curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
        curl_setopt($ch, CURLOPT_TIMEOUT, 15);
        $retValue = (string)curl_exec($ch);
        curl_close($ch);
        return $retValue;
    }

Setting the $data variable to
<?php

$myArray = ["My", "Pretty", "Array"];

$x = (int)0;

while($x < count($myArray)){
  $x = $x++;
  echo $myArray[$x];
}

via POST. $language variable obviously has no relevance here, since that works.

Maybe I can setup a test API that outputs what exactly is received via this code to see if the code is exactly what I am trying to send. It seems some part of the $x variable part seems not to be what it should be. Not sure though.

the code you supplied the first time doesn't match the code you supplied just now. this code does indeed result in an infinite loop. $x = $x++ doesn't do what you think it does. it returns the value of x, increments the original value of x, then assigns the original value back to x. you're basically doing $x = $x.
change $x = $x++ to $x++

Well I did setup a test API that shows me what it receives on that exact cURL Call:
<?php

$myArray = ["My", "Pretty", "Array"];

for($x = 0; $x < count($myArray); $x  ){

  echo $myArray[$x];

}

Very weird. The ++ gets lost. Might be cURL then?

the code you supplied the first time doesn't match the code you supplied just now. this code does indeed result in an infinite loop. $x = $x++ doesn't do what you think it does. it returns the value of x, increments the original value of x, then assigns the original value back to x. you're basically doing $x = $x.
change $x = $x++ to $x++

Well I inserted the wrong code here. The first code is what was actually run.

you need to send it as json. + has a special meaning in url encoded parameters

That seems to be the issue. Thank you for resolving it.

no problem, good luck

authors: TimAnthonyAlexander realtux

repo: engineer-man/piston


text:
Can we get how much a program took to execute in Piston?

Is there a way to record the time took for a program to execute in piston?

Not as of right now, but it would be trivial to implement. I suppose you can check how long it takes for the request to finish, but that includes the network latency. Though, a pull request would be appreciated.

the problem with this is the resulting execution time wouldn't be overly useful right now. piston by default is optimized for safety and availability. execution speed is directly related to the resources involved in the execution, which vary greatly between machines and is limited in the piston execution environment (for safety). to get consistent execution numbers that are unbound by limits would require piston supporting a sort of unsafe environment that has unlimited resources and no time limits. this is something piston doesn't currently support but may in the future, although there's no plans to do so at the moment.

even though resources are limited (for safety), aren't they limited consistently across multiple runs on the same machine?
if so, then having the runtime information on the response would be useful.

#683 adds to the execution response the cpu_time, wall_time, and memory

More info here: https://github.com/engineer-man/piston?tab=readme-ov-file#execute-endpoint

authors: Brikaa Vrganj crbonilha gouseferoz realtux smark-1


text:
HTTP Mirrors are not working

Recently I had issues with download.qt.io not working as expected, so I wanted to switch to the mirror https://qt-mirror.dannhauer.de/official_releases/qt/
However, this doesn't work as expected since https is only allowed for download.qt.io and not for mirrors. The intermediate fix was to replace download.qt.io with qt-mirror.dannhauer.de in qt-downloader.
This is the suspicious part  in the code:
def discover_dirs(url):
  parsed_url = urllib.parse.urlparse(url)
  if parsed_url.netloc == MasterDomain: # should be parsed_url.netloc.startswith("http") or something similar
    reply = requests.get(url)
    if reply.status_code != requests.codes.ok:
      print(reply.content, file=sys.stderr)
      return []

    page = html.fromstring(reply.content)
    items = page.xpath('//table//tr[position()>2]//a[not(starts-with(@href, "/"))]/@href')
    return [item[:-1] for item in items if item.endswith('/')]
  else:
    with FTP(parsed_url.netloc) as ftp:
      ftp.login()
      ftp.cwd(parsed_url.path)
      return ftp.nlst()

@cwiede As far as I can remember, all mirrors, but download.qt.io, are FTP-based storages. That is why I opted for if parsed_url.netloc == MasterDomain check. Because, I had already written parser for download.qt.io and just wanted to add support for mirrors. Otherwise, I had to ensure that FTP-based approach works for download.qt.io as well.
Now I confirm the reproducibility of your issue. Apparently, all mirrors are good for the default HTTP-based parser. Although, this is not ideal solution, as to me, still it does the job.
See the fix in #24

authors: cwiede dvolosnykh

repo: engnr/qt-downloader


text:
No longer possible to hide Dashboard (Craft 2.5)

In Craft 2.4, it was possible to hide the Dashboard.
In Craft 2.5, even if you hide the Dashboard, you'll still be taken there upon login.

@lindseydiloreto A temporary workaround is to use 'postCpLoginRedirect' => 'myaccount#profile' general setting. Not ideal, would be nice to hide this from certain groups altogther (I don't know why this isn't built into Craft?!).

I'm not quite sure how I want to handle this. On the one hand, I can certainly disable access to section that are hidden, but I'd honestly rather not.
For example, say you want to hide the Settings page - a handy one to hide so even if your client has an Admin account (for whatever reason), but its still accessible because you know you can enter /admin/settings to access it.
I actually have the same setup for all client sites using @badlydrawnrob's suggestion of using postCpLoginRedirect to Entries - but thats another story.
What do you think about this one? Should this be a special case for the Dashboard?

@badlydrawnrob: I actually didn't even know about postCpLoginRedirect, thanks! I'll give that a shot and see if it helps.
@engram-design: If Rob's solution does the trick, then perhaps it's not necessary to lock the Dashboard down any further. I find that page useless on 90% of my sites, so it's nice when I can make it disappear. :)

@lindseydiloreto There you go! FYI, for our clients, we always set the postCpLoginRedirect to entries - mostly because we figure clients want to get in there and edit their content, rather than look at pretty Analytics widgets (although, they certainly can, and its useful info).
I'm going to close this one, purely on the basis that its expected behaviour to be able to be able to still access hidden pages, and there is a config setting to alter your case.
Let me know if you need it reopened, or if you need to have another crack at this!

Sounds perfect, thanks @engram-design!

repo: engram-design/CPNav


text:
Backend for managing User IDs

This PR includes:

Docker-compose to run MongoDB+NodeJS
API rest endpoints
Signup, login, user info
Support for login with Google sign up
Report test result

Found a bug. I will fix it and create a new PR

repo: enigmampc/SafeTrace


text:
[bug] Image thumbnails are not loading on homepage

I installed latentscope this week. The initial run seemed to work (I have a directory full of JSON and parquet). Unfortunately, the plot thumbnails are not loading when I return to the landing page.
I would appreciate any pointers on how to debug this.
Steps
I launched latentscope 0.3.0
ls-serve latent-scope-data --port 5001

Then when I visit: http://127.0.0.1:5001/

Displayed
The picture exists on filesystem

I'm not sure if this picture should be copied elsewhere in the file directory, or if the image URL is pointing to the wrong place.

can you check the Settings in the top right of the app? It should show you where your data directory is on your system. Also there is an Export link for the dataset that you can follow to see all the files.
Ideally the paths match what you expect. it could be you did something like ls-serve ~/latent-scope/data the first time and without the ~/ the second time?

Thanks @enjalot - that is helpful!  It suggested this might be a relative vs absolute paths misunderstanding on my part.
It looks like most of the app works if DATA_DIR is a relative path (like ./my-local-directory ), but the thumbnails (and for that matter, serving any of the static files via send_file in app.py) don't work. From adding some app logs, the app was checking the directory where latentscope was installed, instead of in the directory where I was running ls-serve .
The thumbnails worked as long as DATA_DIR (whether set in .env or CLI) is a full path ( like ~/my-scopes-directory ).
Going forward, what do you think about the options of

Rejecting data dirs that are provided as relative instead of full paths, vs
Updating the app to make DATA_DIR be generated relative to where  ls-serve was called instead vs
Some other option?

yeah I'm not happy with the env file stuff. another option might be to
default to ~/latent-scope-data and just allow override of that. then the
env config could also live there.
maybe there is a ~/.latent-scope config that has all your env stuff and the
data directory path?
On Tue, Jun 25, 2024, 6:20 PM Cameron Yick @.***> wrote:

Thanks @enjalot https://github.com/enjalot - that is helpful! It
suggested this might be a relative vs absolute paths misunderstanding on my
part.
It looks like most of the app works if DATA_DIR is a relative path (like
./my-local-directory ), but the thumbnails (and for that matter, serving
any of the static files via send_file in app.py) don't work. From adding
some app logs, the app was checking the directory where latentscope was
installed, instead of in the directory where I was running ls-serve .
The thumbnails worked as long as DATA_DIR (whether set in .env or CLI) is
a full path ( like ~/my-scopes-directory ).
Going forward, what do you think about the options of

Rejecting data dirs that are provided as relative instead of full
paths, vs
Updating the app to make DATA_DIR be generated relative to where
ls-serve was called instead vs
Some other option?

—
Reply to this email directly, view it on GitHub
https://github.com/enjalot/latent-scope/issues/45#issuecomment-2190084336,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAXPPPW3HYCGQRULLYJTT3ZJHULVAVCNFSM6AAAAABJ4KZYDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJQGA4DIMZTGY
.
You are receiving this because you were mentioned.Message ID:
@.***>

Personally I like having latent-scope-data not sitting directly under ~, so that I can version my outputs in different Git repos independently. I also keep different env files for projects that are in different contexts (e.g. staging vs production). Not sure if I am an outlier user though.
The root level latent-scope config could be an interesting quiet fallback for people who didn't want to store multiple copies of their config though!
In the immediate term, my use-case is unblocked because I can just do the long filepaths - the discussion about the path forward here is more to smooth the experience for people who didn't know relative file paths for the DATA_DIR may cause some features (thumbnails and export buttons) to be unavailable.

ah good points.
for your usecase could we expand the relative path to the current execution
path + relative path for the user?
On Tue, Jun 25, 2024 at 7:38 PM Cameron Yick @.***>
wrote:

Personally I like having latent-scope-data not sitting directly under ~,
so that I can version my outputs in different Git repos independently. I
also keep different env files for projects that are in different contexts
(e.g. staging vs production). Not sure if I am an outlier user though.
The root level latent-scope config could be an interesting quiet fallback
for people who didn't want to store multiple copies of their config though!
In the immediate term, my use-case is unblocked because I can just do the
long filepaths - the discussion about the path forward here is more to
smooth the experience for people who didn't know relative file paths for
the DATA_DIR may cause some features (thumbnails and export buttons) to be
unavailable.
—
Reply to this email directly, view it on GitHub
https://github.com/enjalot/latent-scope/issues/45#issuecomment-2190206720,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAXPPK6RP62IEIDMZGPYMLZJH5NPAVCNFSM6AAAAABJ4KZYDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJQGIYDMNZSGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Ian Johnson - 周彦
http://enjalot.github.io/ http://enja.org

Ah good point I noticed ~ gets expanded . Expanding relative path ( ./ )
seems like it should serve that purpose too.
On Tue, Jun 25, 2024 at 11:00 PM Ian Johnson @.***>
wrote:

ah good points.
for your usecase could we expand the relative path to the current
execution
path + relative path for the user?
On Tue, Jun 25, 2024 at 7:38 PM Cameron Yick @.***>
wrote:

Personally I like having latent-scope-data not sitting directly under ~,
so that I can version my outputs in different Git repos independently. I
also keep different env files for projects that are in different
contexts
(e.g. staging vs production). Not sure if I am an outlier user though.
The root level latent-scope config could be an interesting quiet
fallback
for people who didn't want to store multiple copies of their config
though!
In the immediate term, my use-case is unblocked because I can just do
the
long filepaths - the discussion about the path forward here is more to
smooth the experience for people who didn't know relative file paths for
the DATA_DIR may cause some features (thumbnails and export buttons) to
be
unavailable.
—
Reply to this email directly, view it on GitHub
<
https://github.com/enjalot/latent-scope/issues/45#issuecomment-2190206720>,

or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AAAXPPK6RP62IEIDMZGPYMLZJH5NPAVCNFSM6AAAAABJ4KZYDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJQGIYDMNZSGA>

.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Ian Johnson - 周彦
http://enjalot.github.io/ http://enja.org
—
Reply to this email directly, view it on GitHub
https://github.com/enjalot/latent-scope/issues/45#issuecomment-2190451855,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACE2MM4TUSIH5EIEFRXTJZDZJIVERAVCNFSM6AAAAABJ4KZYDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJQGQ2TCOBVGU
.
You are receiving this because you authored the thread.Message ID:
@.***>

@hydrosquall i just pushed what i hope is a fix to main, expanding relative paths like:
 if directory.startswith("./") or directory.startswith("../") or not directory.startswith("/"):
        directory = os.path.abspath(directory)

might be naive but also might work?

Thanks for looking into it. I tried to see if that might fix it by pip installing the current head of main, but ran into a different issue ( https://github.com/enjalot/latent-scope/issues/ ).
Regarding the actual directory expansion: I think this will work out ok for me on Mac, but python Pathlib might handle this for other platforms if you can assume the python version is at least 3.11. A thing to look out for users is that this updated path will be written back to the .env file, so that if you run latent-scope once using a relative path, then relocate the folder to a new location, the env file will the expanded path to the old location.
directoryObj = pathlib.path(directory)
directory = str(directoryObj.absolute())

Confirmed that https://github.com/enjalot/latent-scope/commit/2e786da85c4b13fc0b3d09ddcd8f1e0da0d4701d fixed it when installing the latest main and running the local web build instructions (cd web/ && npm install && npm run dev
I ran ls-serve my-custom-folder-name , where my-custom-folder-name is a folder in the directory where I ran this command. In .env, that folder name was expanded into a full absolute path. I think we can close this issue, thanks for the patch @enjalot !

authors: enjalot hydrosquall

repo: enjalot/latent-scope


text:
redesign events

do not use .enketo namespace, but use _underscore if the events if the events are not meant for external consumption?
create nicer API? (though not sure what it should look like)

[ ] remove all jquery.trigger refs and create missing custom events in event.js

just brainstorming for a nicer API
import {Change, PageFlip, addHandler, addDescendantHandler, trigger} from './events';

addHandler(el, Change, ev => {} );
addDescendantHandler(el, descendantSelector, ev => {} ); // like 'delegated' jQuery events
trigger(el, Change);

events.js
function addHandler(el, Ev, fn){
   el.addEventListener(Ev().type, fn)
  // todo: this in fn scope should be this of addHandler call context
}

probably no need to add handler to multiple elements at once

repo: enketo/enketo-core


text:
added: backslash as an escape character in markdown mode for * and _

Initial proposal for #36
I have opted for escaping only * and _ for now. I'd like to include # in there, and use typical &#NN; html escape syntax, but that will require some adjustments in regexes for current markdown rules for headers.
Changes so far impact two previous tests - one in markdown, where <span>a</span> by old logic is replaced by 'a', and with above changes the result is <span>a</span>. I'm not sure if the old behavior should be preserved in this case, since with new result the input is properly escaped.
Similarly, second failing test case is in transformer tests and portrays the same issue.

This looks great. Thanks!
I need to have another look but I think the 2 failing tests might be important, because we don't actually want those '' elements to be escaped. Sanitized span elements are the only elements that should be rendered as html. It's looks a little weird which I believe it's related to XLSForm that escapes them.

Ok then - I will be waiting for further feedback and try to make appropriate changes once it's clear if escaped  should be also converted or not.

I have confirmed this odd support is required unfortunately. It is indeed related to the XLSForm form that (I estimate) 99% of the Enketo users are using to create forms. Pyxform escapes all HTML and we then unescape only the (sanitized) span element.
I think it should be considered a bug in pyxform, but it's one we want to keep working around for now in Enketo (and even after it would be fixed due to backwards compatibility of old XForms).

Ok - I made an adjustment. Moving regexes I introduced after escaped span handling does the job.

Perfect. Thank you!

authors: MartijnR ajarocki

repo: enketo/enketo-transformer


text:
Fixes may 2017

The "got" and "expected" were reversed in equality tests - fixed that.
The histograms should have newlines at the end. The example in the problem description shows a newline at the end. It's also easy to write that way with 'unlines'.

Thanks Lyle!

authors: enolan lylek


text:
detect: Adding more serial id fallbacks

As per issue 206 in edeploy, we have systems where serial numbers are .... weird.
We have system that are even much more evil like DMI not providing any
unique ID at all...
This patch is trying to solve all that different cases.
If the serial is known to be buggy then we search for a possible
fallback in the following order :

system uuid
motherboard serial
MAC address of the first nic

Note that the system uuid will be used unless it is known to be buggy or empty.
If a system doesn't provide any valid 'product SN' or 'product uuid' or
'motherboard serial' (yes this does exist), then we fallback on the last
unique ID we have on a system which is the mac address of one nic : this
is not optimal but at least that makes the installation process staying
alive. That's really a workaround.

Related to https://github.com/enovance/edeploy/issues/206

Travis failed, I'm trying to trigger a new build.

repo: enovance/hardware


text:
Benchmark results website 2.0

Current solution (bad)
The current website with plots of all the benchmarks is a static website generated from a Jinja template by website_regen.py script hosted with GitHub pages on https://enso-org.github.io/engine-benchmark-results/.
This has many disadvantages:

Hard to maintain. Especially with some Javascript code in the HTML template.
The resulting web pages are huge and very slow to load, because they contain all the data inside Javascript embedded in the HTML.
The Google charts JS library used by the template is ugly and difficult to work with and with insufficient documentation.
It is very difficult to add any dynamic behavior like loading data on demand or comparing results of two branches.

Motivation
There are requests for new features in the current website:

Plot also Enterprise edition benchmarks along with Community edition.
Compare results from a custom branch to the results of the develop branch.

Currently handled only by the bench_download.py cmd line script.

Display standard deviation.

It is easier to implement the current features along with the requested ones from scratch using VueJS than to add them to the current template solution.
VueJS proposal
Let's implement a single page application with VueJS and use some more responsive, sophisticated and better documented plotting library, like ChartJS. The data will be fetched from the cache directory in the same repo. We only need some index.json file that maps names of the files to their timestamps. There is no need for any sophisticated backend or a database yet. Just build static single page application with VueJS and host it on GitHub pages. Access to the cache directory in the same repo should be straightforward. The application won't be needed to regenerate on a daily basis, just when new features are added.
A prototype is being developed in https://github.com/enso-org/engine-benchmark-results/tree/vue
Benchmark data upload
The data for the benchmarks are uploaded daily by the Benchmarks Upload GH Action into the directory https://github.com/enso-org/engine-benchmark-results/tree/main/cache as JSON files. Note that this task does not need any change to the data uploading functionality.
Related

https://github.com/enso-org/enso/issues/5714

Priority is high because the results of Oracle GraalVM (Enterprise Edition) benchmarks, implemented on 2024-03-12 in https://github.com/enso-org/enso/pull/9322 are stored only as GH artifacts so far that are dropped after 3 months without any recovery or backup. The initial results are already dropped. Let's make sure they are stored permanently in engine-benchmark-results repo.

Let's finish integration of this new, cool, Vue.js based SPA!

Added three essential tasks to finish this issue.

authors: Akirathan JaroslavTulach

repo: enso-org/enso


text:
Improve delimited format in the Data Link Modal in the Dashboard

I've got 2 problems with the delimited format modal:

We cannot easily set the delimiter to a 'tab' value, because pressing tab in the field just changes focus. Maybe we should actually provide a drop-down with some suggested values and then allow to switch to 'custom' which only then would open a text field? I guess we could achieve that within the JSON schema by using the examples keyword to provide the values for the dropdown.

The Headers setting is extremely un-intuitive.

^ This state means that the headers will be inferred.
If I want to change it to true/false, I first click the title and then I can select one of the options:

However, for basically anyone without a deep knowledge of Enso, it is not at all clear that the 'greyed-out headers' state means the headers will be Inferred.
I think we should change the widget to be a dropdown containing 3 options: true / false / infer. This way it should be much clearer.
I assume we could achieve that by modifying the schema in the following way:
         "headers": {
           "title": "Headers",
           "description": "Whether a header row containing column names is present.",
-          "type": "boolean"
+          "enum": [true, false, "infer"],
+          "default": "infer"
         }

and then modifying the Modal renderer accordingly.
i. Making the field an enum could be a way to tell the renderer that the widget should be rendered as a drop-down showing the possible options.
ii. Adding the default value could be a way to deal with the case of the field not being required. While the field is not required, we know that missing field is equivalent to the default - which is equivalent to the "infer" setting in that case. So we could avoid displaying the 'greyed-out' field and instead just display the field with the "infer" option selected by default.

i assume issue 2 is now fixed?
re: issue 1.

we can use the tried-and-true solution of using Just Another anyOf. or...
we could use examples to generate autocomplete ui. we already do have an Autocomplete component so it's not like it'd be super hard... i suppose one thing we might need to think about is consistency - since it's not like the anyOf can't output any shape we want anyway. (we might just have to make sure the string one is the last option, otherwise it matches against any valid string (= always) when editing a Data Link.)

@jdunkerley do we want to support tab as delimiter value?

authors: PabloBuchu radeusgd somebody1234


text:
All Enso objects are hasheable

Pull Request Description
Implement hash_code for all Enso objects. Map is now a builtin type with a proper hash map implementation. This PR is a follow-up of Convert Any.== to a builtin PR.
Important Notes

Replaces binary tree Map implementation with proper hash map implementation.
There are almost no modifications to the API of Map, except for:

to_vector no longer returns vector sorted by keys
keys returns unsorted vector
first and last methods are removed

Map supports any object as keys - primitives, atoms, polyglot values, another maps, ...
Foreign maps (Python dictionary, JavaScript Map, java.util.Map, etc.) are treated as Enso maps seamlessly, just how foreign arrays are treated.
Add tests that ensure that the following holds:

For all objects o1, o2: if o1 == o2 then hash(o1) == hash(o2) and if hash(o1) != hash(o2) then o1 != o2.

Added many values to ValueGenerator.

Checklist
Please include the following checklist in your PR:

[X] The documentation has been updated if necessary.
[X] All code conforms to the
Scala,
Java,
and
Rust
style guides.
All code has been tested:

[X] Unit tests have been written where possible.
[X] If GUI codebase was changed: Enso GUI was tested when built using BOTH
./run ide build and ./run ide watch.

Based on the feedback in this PR I prepared an inception review document please take a look and modify it/add comments here, etc. My current feeling is that we could split the work into three (or even more) independent PRs and deliver this piece by piece.

@JaroslavTulach FYI: I modified the PR so that it is more in line with the current idea of hashing - added Hash_Map type and improved hash code caching. It is still very much work in progress, but the following simple snippet already kind of works:
from Standard.Base.Data.Hash_Map import Hash_Map, Builder

main =
    builder = Builder.new
    builder.append "A" 1
    hash_map = builder.build
    IO.println (hash_map.get "A")

I'm not sure if the snapshot-based approach can work at all with immutable maps.

In case there is a key replaced by a new key, let's just clone the map without altering the previous one.
Please note that the "cloning" approach isn't going to affect Vector.distinct implementation, as that one should check contains_key before inserting new one - e.g. there is never going to be a replacement of a key with new.

I'm not sure if the snapshot-based approach can work at all with immutable maps.

In case there is a key replaced by a new key, let's just clone the map without altering the previous one.
Please note that the "cloning" approach isn't going to affect Vector.distinct implementation, as that one should check contains_key before inserting new one - e.g. there is never going to be a replacement of an old key with a new one.

I think this could be OK for a temporary solution, but longer-term I think Enso should provide an efficient functional map. I think all functional languages provide one in their standard library (e.g. Haskell, Scala).
If we cannot have the immutable Map provide fast insert, for the time being, can we at least get a mutable Map Builder that would? I'm right now working on code that is relying on updating the same key often (I'm counting how many times a name was encountered in an input, so I'm updating the key each time its encountered with an incremented amount). Here is my code. I'm currently worried that this PR will make this piece of code much slower (as each insert will do a full copy). It is not the most performance critical piece of code, but if the Map cannot give me good guarantees, I may just as well use Vector there as it will not be that much slower then.
IMHO a functional Map with fast insert is something more or less expected in a functional language, and while I really like that our distinct operations will be now significantly faster, I'm worried that losing performance of insert is a regression in comparison to the current state.
Also, what about keeping both maps - one more suitable for build-once query-more approach using hashing and a treemap that will have the more standard performance guarantees? (Although we could modify the treemap to use hashing too, to become effectively a hash-trie like Scala's immutable.HashMap).

I think this could be OK for a temporary solution

Thank you. In such case, let's integrate this PR and plan additional work later. It is already taking too much time to integrate this PR anyway.

I see failure in scatter plot visualization:
[FAILED] limit the number of squared elements [56ms]
 INFO ide_ci::program::command: bashℹ         Reason:
   [{"x":0,"y":225}, {"x":29,"y":196}, {"x":15,"y":0}] did not equal
   [{"x":0,"y":225}, {"x":15,"y":0}, {"x":29,"y":196}] (at
   /runner/_work/enso/enso/test/Visualization_Tests/src/Scatter_Plot_Spec.enso:113:13-110).

probably the new map doesn't respect ordering - I think it is fine to fix the test to compare while ignoring the ordering.

Do hash maps work with pattern matching? Can we have some interop tests for maps coming from JS, Python and R?

Not yet, just a simple type check. So interop tests with pattern matching will not work.

The snapshot based approach was viable for an 'incremental' map builder, but it will not work with freely modifiable immutable maps which can form a treelike structure.

Fixed with some workarounds. Now, the time complexity of insert is linear if the key is already in the map, or if another insert was already called on that map. We still have linear hash map builders, but duplicate them in certain situations, and remove some keys from the newly created ones, if necessary.
Performance of Vector.distinct benchmark
Measured by running test/Benchmarks/src/Vector/Distinct.enso

bench name
old (iter ms)
new (iter ms)

Random int vector
8.37
8.29

Uniform int vector
12.84
5.28

Random text vector
36.34
15.94

Uniform text vector
35.4
15.43

There is a windows engine failure probably related to ordering of keys in a map:
- should allow converting a GeoJSON object into a table with provided fields [106ms]
- [FAILED] should allow converting a GeoJSON object into a table containing all available fields [137ms]
    Reason:
    [longitude, latitude, foo, bar, elevation, baz]
    did not equal
    [bar, baz, elevation, foo, latitude, longitude]
(at C:\runner\_work\enso\enso\test\Geo_Tests\src\Geo_Spec.enso:53:13-53).

There is a failure in Visualization tests - probably we can modify the test to accept the values in any order.

Failures in Table tests:
Reason: An unexpected dataflow error (There was an SQL error: FATAL: role "mwu" does not exist.)
has been matched (at /runner/_work/enso/enso/test/Table_Tests/src/Database/Common_Spec.enso:37:13-49).

Probably not related to Pavel's code, but to some infrastructure problem. CCing @mwu-tow.

Failures in Table tests:
Reason: An unexpected dataflow error (There was an SQL error: FATAL: role "mwu" does not exist.)
has been matched (at /runner/_work/enso/enso/test/Table_Tests/src/Database/Common_Spec.enso:37:13-49).

Probably not related to Pavel's code, but to some infrastructure problem. CCing @mwu-tow.

It could be related to maps. It is failing in Postgres_Spec.enso, where, I think, java.util.Properties are used for the configurations, and they are treated as Maps. Not only that, but it is possible that wrong Properties are passed because of changes in this PR. Right now, I am trying to reproduce this locally, but I haven't even installed Docker, so it will take a while. Besides, I have already quickly checked whether this is an infra issue and other Engine CI jobs are not failing with this.

@JaroslavTulach @Akirathan
Strange but I don't think it is CI-caused. I don't know where the mwu comes from, it should not be used in the postgresql server configuration. It is however the username, so if you get it anywhere from the environment, it might show up. Are the test now respecting the ENSO_DATABASE_TEST_DB_USER variable?

@JaroslavTulach @Akirathan Strange but I don't think it is CI-caused. I don't know where the mwu comes from, it should not be used in the postgresql server configuration. It is however the username, so if you get it anywhere from the environment, it might show up. Are the test now respecting the ENSO_DATABASE_TEST_DB_USER variable?

Turns out that this issue is, indeed, caused by my changes. I tried logging how I manipulate with java.util.Properties that are used to initialize the connection here https://github.com/enso-org/enso/actions/runs/3951865906/jobs/6766255048#step:10:11400 which clearly proves that the transformation is wrong. I will try to debug that locally. Luckily, I don't need to initialize Postgres for that.

Last(?) failure on windows:
- [FAILED] should insert entries to a polyglot map [23ms]
Reason: An unexpected panic was thrown: ForeignParsingException:
'Cannot parse foreign python method. Only available languages are [enso, js]'

you need to shield the python tests by a check for a presence of that language.

authors: Akirathan JaroslavTulach mwu-tow radeusgd


text:
Vector.map & State

Pull Request Description
Fixes #6656 by invoking the function with InvokeFunctionNode and not InteropLibrary.
Important Notes
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] All code follows the
Java,
All code has been tested:

[ ] Unit tests have been written where possible.

With a24134d I can see

I hope that's correct. Now we need to "just" write some tests and polish the implementation.

@kustosz : Why is select_into_database_table a Text and not an UnresolvedSymbol:
Meta.get_annotation object .annotation_name

There is an API to evaluate any expression in any module.

This PR has been simplified to fix just the Vector.map & State. Fix for annotations on extension functions is now part of #7115.

I've just found a slightly related issue #7117 showing that while definitely a step in the right direction, this may still not be enough.

authors: JaroslavTulach radeusgd


text:
Fix typo

Fixed the behvaior from {{ $e.TableConstant }} is the table the holds the {{ $e.Name }} relation/edge. to {{ $e.TableConstant }} is the table that holds the {{ $e.Name }} relation/edge.

Can you please run go generate ./entc/gen/... and go generate ./... go generate the assets?

Okay

@all-contributors please add @neel229 as a contributor for code

repo: ent/ent


text:
Extend the help command (Descriptions, help texts, highlighting)

Add a JSON file for the help texts
Add descriptions to the help command
Enable highlighting in output (mark the to-be-highlighted text with starting & enclosing |c)

Thanks for the PR! I think we want to keep the help files in text documents alongside the commands and lazy load them (credit to @toddself for the excellent suggestion). This helps keep the help docs in easily-findable, editable form and has the benefit of lazy loading so the (minor for now) cost of loading help isn’t incurred until it’s used.

ah, makes sense. So there's no need for this PR?

The help texts are super useful! perhaps save them to the individual help-${command}.txt file names?
I realize #115 might change how some of this is stored (although help-${command}-${locale}.txt is also a decent pattern for this)

Alright so shall I change this to read the help files?

I think we can implement highlighting as a transform stream that we can pipe the fs.createReadStream data into before it gets out to process.stdout
This way we don't have to maintain a parser in the help system but still support highlighting with color for commands (and possibly more easily support localization).
I hope to wrap up an initial implementation this weekend, using the data from your help files @flxwu

@toddself chalk have a format for formatting text that can be used with template literals: https://github.com/chalk/chalk#tagged-template-literal
Maybe we can follow it?

#225 has merged with chalk in it, so you should be able to rebase master over this branch

authors: chrisdickinson flxwu gribnoysup olingern toddself

repo: entropic-dev/entropic


text:
User data and iam instance profile arn

This change is helpful for testing boot time events such as cloud-init scripts and/or talking to aws services at boot time.

@patrobinson I pushed changes. Anything else you would like to see?

Thanks, I fixed your last comments.

This has been released in version 1.0
Thanks for your contribution!

authors: patrobinson sherzberg

repo: envato/ami-spec


text:
🛑 905 (Managed - Web) - HTTPS is down

In 6ec5c0c, 905 (Managed - Web) - HTTPS ($URL_905) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 905 (Managed - Web) - HTTPS is back up in 849afea.

repo: envesko/status


text:
Lua Envoy Filter , parsing of response_body is not working in lua

I am trying to implement lua filter to communicate with OPA ( open policy agent ) [ other authorization server has some issue , not working ], hence trying to implement lua filter.
I am able to configure lua filter to communicate with OPA. and getting the response back in response_body.
response_body output is as below
{"decision_id":"b4867d1a-2316-4e83-ab5e-20300e4ad57e","result":false}

I am looking some way to extract the value from response_body. but do not get any way to do the same.
I need to do some processing on the result value here.
I have tried to import json also, but it fails with error.
any suggestion will make my day.
my code is as below
inlineCode: |

           function envoy_on_request(request_handle)

              request_handle:headers():add("Content-Type","application/json")

              local response_headers, response_body = request_handle:httpCall(
              "outbound|8181||auth.local",
              {
                [":method"] = "POST",
                [":path"] = "/v1/data/opa/meddetails/allow",
                ["Authorization"] = request_handle:headers():get("Authorization"),
                ["Content-Type"] = "application/json",
                [":authority"] = "auth.local"
              },
              "",
              5000)

              for key, value in pairs(response_headers) do
                request_handle:logCritical(key .. " " .. value)
              end

              request_handle:logCritical(response_body)

              request_handle:logCritical("------------------")

            end
            function envoy_on_response(response_handle)
              response_handle:headers():add("x-this","works")
            end

Can anybody help me on this ..

@ajoysinha it seems like your request is successful, but you can't log the body?
I'm not sure if the following example could help you: https://github.com/dio/envoy-lua-opa

authors: ajoysinha dio

repo: envoyproxy/envoy


text:
[Question] connection termination

Greetings!
My settings are based on Failover setup.
I've two nodes behind the proxy. The primary node (in active mode) and secondary one (in passive mode).
  clusters:
  - name: intranet
    connect_timeout: 5s
    lb_policy: CLUSTER_PROVIDED
    cluster_type:
      name: envoy.clusters.aggregate
      typed_config:
        "@type": type.googleapis.com/envoy.extensions.clusters.aggregate.v3.ClusterConfig
        clusters:
          - active
          - passive
    circuit_breakers:
      thresholds:
        - priority: DEFAULT
          max_connections: 500000
          max_requests: 500000
        - priority: HIGH
          max_connections: 500000
          max_requests: 500000

with
  - name: XYZ
    connect_timeout: 5s
    per_connection_buffer_limit_bytes: 32768
    type: STRICT_DNS
    dns_lookup_family: V4_ONLY
    lb_policy: LEAST_REQUEST
    load_assignment:
      cluster_name: XYZ
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: XYZ
                port_value: 808
            health_check_config:
              port_value: 80
    health_checks:
      timeout: 5s
      unhealthy_threshold: 1
      healthy_threshold: 2
      interval: 15s
      http_health_check: { path: "/", expected_statuses: { start: 200, end: 304 } }

The upstream nodes are IIS web servers.
The problem is: sometimes I got unknown problems. I don't know why it returns:
upstream connect error or disconnect/reset before headers. reset reason: connection termination
Yes. I found there's some downstream member down in order of seconds.
My listener has
          common_http_protocol_options:
            idle_timeout: 3600s
          stream_idle_timeout: 0s
          request_timeout: 0s

cluster
connect_timeout: 5s

and their healthcheck
timeout: 5s

What's the problem?
My timeout is too short?
The primary upstream node has been DOWN for sure?
I need to understand how to overcome this
upstream connect error or disconnect/reset before headers. reset reason: connection termination
Thanks in advance!

BTW what's the difference between "eject_unhealthy_event":{"failure_type":"NETWORK"} and "eject_unhealthy_event":{"failure_type":"ACTIVE"} ?

Ps. I can't find in the web server log file any bad request on time range.

I see no interaction. Thanks in somehow.


text:
uhv: oghttp2: disable header validations based on compile flag

Title: uhv: oghttp2: disable header validations based on compile flag
Description:
oghttp2 is being adopted in Envoy and has recently add a method of disabling header validations through a configuration setting. Using a compile time ifdef, disable H2 header validation within the parsing library when building UHV. This will be very similar to H1. We plan on using the new validate_http_headers exposed by the external_quiche_http2::adapter::OgHttp2Adapter::Options class, most likely within the Http2Options constructor.
Refs #19751

CC @alessandrogario

cc @birenroy @yanavlasov

The QUICHE work is done, and my understanding was that @yanavlasov  would handle or delegate the task of hooking up the compile time flag.

authors: KBaichoo ameily birenroy


text:
listener filter chain match doesn't work for incoming request using proxy protocol

Title: listener filter chain match doesn't work for incoming request using proxy protocol
Description:
I have two envoy proxy chained together: client -> envoy1 -> envoy2 -> server.
envoy1 just does the tcp forward and will use upstream proxy protocol to save the information about client ip.
envoy2 will handle the proxy protocol and route the traffic based on server name. However, envoy2's listener filter chain match won't work(it behaviors like server name match failed though it's the correct server name).
If proxy protocol is not used or envoy2 filter chain match is not used, then everything works fine.
envoy1 cluster snippet:
      clusters:
      - name: cluster1
        ...
        transport_socket:
          name: envoy.transport_sockets.upstream_proxy_protocol
          typed_config:
            "@type": type.googleapis.com/envoy.extensions.transport_sockets.proxy_protocol.v3.ProxyProtocolUpstreamTransport
            config:
              version: V1
            transport_socket:
              name: envoy.transport_sockets.raw_buffer
        load_assignment:
          ...

envoy2 listener snippet:
        listeners:
        - name: listener1
          address:
            socket_address: { address: 0.0.0.0, port_value: 8080 }
          listener_filters:
            - name: envoy.filters.listener.tls_inspector
            - name: envoy.filters.listener.proxy_protocol
            - name: envoy.listener.original_src
          filter_chains:
            - filter_chain_match:
                server_names:
                  - hello1.com
               filters:
               ...
            - filter_chain_match:
                server_names:
                  - hello2.com
               filters:
               ...
            - filters: # request all ends up here

[optional Relevant Links:]

Any extra documentation required to understand the issue.

seems like you should run the proxy_protocol listener filter before the tls_inspector filter.

thanks @soulxu you're right, it's working now after i move proxy_protocol ahead.
Btw, since I followed this doc example, I created a pr to fix the doc, could you help review it? https://github.com/envoyproxy/envoy/pull/23217

authors: levimm soulxu


text:
Missed upstream disconnect (503) not retried with 5xx or retriable-status-codes and "503"

Title: Missed upstream disconnect (503) not retried with 5xx or retriable-status-codes set to "503"
Description:

Upstream disconnects as described in https://github.com/envoyproxy/envoy/issues/6190 are not retried with retriable-status-codes (set to 503) or even with 5xx.

Looks like this is related to https://github.com/envoyproxy/envoy/issues/5876, which went stale. Feel free to reopen that if it makes more sense instead.

@jaygorrell reopened https://github.com/envoyproxy/envoy/issues/5876, let's continue discussion there, thanks.

authors: htuch jaygorrell