text:
Module names aren't highlighting

tree-sitter-elixir was pushed live on GitHub today 🎉  , but @the-mikedavis pointed out that module names aren't highlighting
Example: https://github.com/elixir-mint/mint/blob/1ea7731d921840ad75a47fa9415525c3d94b9980/mix.exs#L1-L2

Example 2: https://github.com/elixir-mint/mint/blob/1ea7731d921840ad75a47fa9415525c3d94b9980/lib/mint/http1.ex#L108-L113

CC @patrickt (who asked to be CC'd so he can push an updated grammar on GitHub's end when this is handled.)

Hey! Modules are highlighted correctly for me when running tree-sitter highlighter locally:

This is probably related to the theme GitHub uses? The modules get the type highlight token, should we be using something else?

From what I can tell it looks like these highlights aren't ending up syntax-highlighted to any color: https://github.com/elixir-lang/tree-sitter-elixir/blob/de3ec57591aebf451e710fc9c984cf601258baf5/queries/highlights.scm#L65-L69
which is curious because the java queries for example use @type as well: https://github.com/tree-sitter/tree-sitter-java/blob/ed3a87f750b1d1d533f15ab93fef3e1f5a46e234/queries/highlights.scm#L22-L23, and I assume java is tree-sitter highlighted in github, and I see class names highlighted as I would expect (e.g. here)
Maybe it's just a precedence issue? Or maybe github also needs a tags.scm to identify clasess/modules?

Without @type the module name doesn't get any highlighting token, so there should be no conflict either way :thinking:
The module name gets the pl-smi class instead of pl-en.

Ah good find: seems like the problem isn't with the grammar/queries here but something in how GitHub is mapping the tree-sitter scopes to class names. I'm not sure how to get the ball rolling with GitHub support on this. Maybe we can re-use the contact mentioned in #2 (comment) (cc: @josevalim)?

Yeah, I don’t think @type is quite right here. I’m trying to figure this out (and will assemble some docs, hopefully).

The tests for Java tree-sitter highlighting are in this file and it confuses me because tokens annotated as type are highlighted with three different colors. This would only make sense if for some reason tree-sitter is not used for highlighting Java files.
Looking at similar tests for JavaScript and Ruby, it looks like modules/classes use the constructor token, which doesn't seem suitable in our case.

@jonatanklosko Correct: I just found out that tree-sitter-java’s highlights aren’t hitting prod traffic, so a better comparison is Python or Ruby in their respective repositories. Apologies for the confusion.

Is the mapping/theme a part of some open source project or is it something you maintain internally?

Hang on a sec, I’m gonna write up a Markdown table.

It’s closed-source. I’m dotting my i’s properly and checking to make sure I can give you the whole list without running awry of lawyers. But yes, @type maps to the pl-smi class, which doesn’t appear to be used. I would try constructor for the time being; I know it doesn’t exactly match the semantics, but mapping @type to something colorable will be a more protracted process.

@jonatanklosko Actually, I think I can get that @module change in pretty fast. So change those @type to @module and I’ll coordinate on my backend.

Fantastic!

Okay, the changes required to recognize @module in syntax highlighting in our backend are coming in and should be deployed in the next fifteen minutes or so. Once #16 lands, I’ll bump the submodule in our backend, and deploy again. Thanks all for your patience.

Beautiful, thanks for all the help! I've just merged the change, so we should be good on this side :D

This is working now:

Awesome, thanks! :shipit:
The examples linked in the issue description are still the same, is that caching temporary?

@jonatanklosko Yeah, I think that’s memcached doing its thing. It’ll fall out of cache eventually, heh!

Perfect :D

authors: jonatanklosko maco patrickt the-mikedavis

repo: elixir-lang/tree-sitter-elixir


text:
Weird behaviour with progress status.

Trying to use a model with Bumblebee, and I'm getting this kind of log:
{:ok, #PID<0.769.0>}
|===================================================                                                 |  51% (25.76/50.78 KB)Failed to write log message to stdout, trying stderr
[error] GenServer #PID<0.65.0> terminating
** (FunctionClauseError) no function clause matching in :prim_tty.cols/2
    (kernel 9.0.1) prim_tty.erl:935: :prim_tty.cols([ansi: "\e[2K"], true)
    (kernel 9.0.1) prim_tty.erl:933: :prim_tty."-cols_multiline/4-lc$^0/1-0-"/3
    (kernel 9.0.1) prim_tty.erl:933: :prim_tty.cols_multiline/4
    (kernel 9.0.1) prim_tty.erl:628: :prim_tty.handle_request/2
    (kernel 9.0.1) prim_tty.erl:551: :prim_tty.handle_request/2
    (kernel 9.0.1) user_drv.erl:781: :user_drv.io_request/2
    (kernel 9.0.1) user_drv.erl:834: :user_drv.io_requests/2
    (kernel 9.0.1) user_drv.erl:777: :user_drv.io_request/2
    (kernel 9.0.1) user_drv.erl:887: :user_drv.handle_req/3
    (kernel 9.0.1) user_drv.erl:491: :user_drv.server/3
    (stdlib 5.0.1) gen_statem.erl:1377: :gen_statem.loop_state_callback/11
    (stdlib 5.0.1) proc_lib.erl:241: :proc_lib.init_p_do_apply/3
Last message: {:EXIT, #PID<0.70.0>, {:function_clause, [{:prim_tty, :cols, [[ansi: "\e[2K"], true], [file: ~c"prim_tty.erl", line: 935]}, {:prim_tty, :"-cols_multiline/4-lc$^0/1-0-", 3, [file: ~c"prim_tty.erl", line: 933]}, {:prim_tty, :cols_multiline, 4, [file: ~c"prim_tty.erl", line: 933]}, {:prim_tty, :handle_request, 2, [file: ~c"prim_tty.erl", line: 628]}, {:prim_tty, :handle_request, 2, [file: ~c"prim_tty.erl", line: 551]}, {:user_drv, :io_request, 2, [file: ~c"user_drv.erl", line: 781]}, {:user_drv, :io_requests, 2, [file: ~c"user_drv.erl", line: 834]}, {:user_drv, :io_request, 2, [file: ~c"user_drv.erl", line: 777]}, {:user_drv, :handle_req, 3, [file: ~c"user_drv.erl", line: 887]}, {:user_drv, :server, 3, [file: ~c"user_drv.erl", line: 491]}, {:gen_statem, :loop_state_callback, 11, [file: ~c"gen_statem.erl", line: 1377]}, {:proc_lib, :init_p_do_apply, 3, [file: ~c"proc_lib.erl", line: 241]}]}}
State: {:state, :user_sup, :undefined, #PID<0.70.0>, {#PID<0.65.0>, :user_sup}}
Failed to write log message to stdout, trying stderr
[error] Task #PID<0.771.0> started from EAIML.Bumblebee.FlanT5Test terminating
** (stop) :terminated
    (stdlib 5.0.1) io.erl:94: :io.put_chars(:standard_io, ["\e[2K\r", "|", ["=", "                                                         "], "|", ["   1%", " (0.02/2.42 MB)", ""]])
    (bumblebee 0.4.2) lib/bumblebee/utils/http.ex:100: Bumblebee.Utils.HTTP.download_receive/2
    (bumblebee 0.4.2) lib/bumblebee/utils/http.ex:52: Bumblebee.Utils.HTTP.download/3
    (bumblebee 0.4.2) lib/bumblebee/huggingface/hub.ex:96: Bumblebee.HuggingFace.Hub.cached_download/2
    (bumblebee 0.4.2) lib/bumblebee.ex:784: Bumblebee.load_tokenizer/2
    (eai_ml 0.1.0) lib/eai_ml/bumblebee/flant5_test.ex:54: anonymous fn/0 in EAIML.Bumblebee.FlanT5Test.init/1
    (elixir 1.16.0) lib/task/supervised.ex:101: Task.Supervised.invoke_mfa/2
    (elixir 1.16.0) lib/task/supervised.ex:36: Task.Supervised.reply/4
Function: #Function<1.36664021/0 in EAIML.Bumblebee.FlanT5Test.init/1>
    Args: []

Using Erlang/OTP 26 [erts-14.0.1] along with Elixir (1.16.0) - probably precompiled from ASDF using:
elixir 1.16
erlang 26.0.1

Can you please try a more recent Erlang version? Either 26.0.2 or 26.2? It looks like an Erlang bug to me.

Yep - thanks Jose! The problem goes away with 26.2.1, I was trying other versions as you were answering.
Closing issue!

source: gharchive/issue

authors: hickscorp josevalim

repo: elixir-nx/bumblebee

license_type: permissive

license_source: github-api


text:
Retain newlines in cell output markup for copy/paste

This is the simplest solution I thought of that addresses https://github.com/elixir-nx/livebook/issues/384. I tested expected copy/paste behavior in chrome and safari.
An alternative to this (or perhaps we should do it in addition to since this solution supports partial copying) is rendering a little icon on hover (maybe top right of output cell?) that, when clicked, copies the raw output text to the clipboard. This would be nice for lengthy output. Happy to make this change if ya'll feel it's the right direction.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

@benjreinhart won't this add newlines on the output too? Or are those newlines ignored because of CSS?

Unless I'm missing a case, the output content is not inside a pre tag, so html ignores them.

@josevalim each line gets rendered as a separate element with whitespace: pre, but the virtualization positions each of the elements absolutely so the newline is not visible. If we added \nsometext to a line, then sometext would overlap the line below.

I think this solution makes sense, but I'd rather modify this part:
https://github.com/elixir-nx/livebook/blob/7024d2225308e4e0eca801529c3a48f5c1c79c1f/lib/livebook_web/live/session_live/cell_component.ex#L343
to

<%= [line, "\n"] %>

as it doesn't really belong to ansi_to_html_lines.

Yeah that sounds better, @jonatanklosko, thanks!

Longer term, would it make sense to put all output* inside a tag with whitespace: pre, leave the text as is, and then use overflow: scroll? I am not sure I understand what the benefits of using hyperlist and wrapping the values in markup are here?

All textual output; we can do something different (syntax highlighting) for code output

@benjreinhart we support ANSI escape codes in the output and achieve this by wrapping the relevant text in  tags styled accordingly. When the output is large, there may be a lot of these elements and this poses performance issues to the browser as recomputing the layout becomes very slow. By virtualizing the output we only show the lines that are currently in the viewport.

@benjreinhart Thanks for looking into that!

source: gharchive/pull-request

authors: CLAassistant benjreinhart jonatanklosko josevalim

repo: elixir-nx/livebook


text:
Precompilation support

Hi @warmwaffles!
A couple months ago, the amazing @cocoa-xu added support for precompilation in elixir_make. Is this something of interest to you and the project? This can help specially with Windows users.
If you are, we would be happy to fund towards making this happen, or getting someone to make it happen. :)
Thank you.

Btw, once precompilation is operational, the workflow is for releasing new versions is slightly different. You would tag, push the tag, wait for GH Actions to precompile, and then run a command to download the precompiled artefacts, MD5 them, and publish the package.
There is an example with everything hooked up, including CI here: https://github.com/cocoa-xu/cc_precompiler_example

@josevalim I'll take a look at this. The only thing this would conflict with is https://github.com/elixir-sqlite/exqlite#advanced-configuration specifically the "Database Encryption" portion.

@warmwaffles you have full control over when to use the precompiled stuff. So if that env var is set, you disable precompiled download. If something is missing, we can add the missing features to make this possible. :)

Oh that's brilliant. I'll take a stab at this.

Hi @warmwaffles, also please feel free to ask me anything, I'll be very happy to help you! :)

I would like to also enable this for https://github.com/fire/elixir_mvsqlite. Rust complication is difficult

@fire for Rust there is https://github.com/philss/rustler_precompiled/

I am not using rustler, it is the build make system of exqlite + a library in c built by rust.

@cocoa-xu and @josevalim Just trying to figure out how precompiled binaries work. When you do a mix deps.get will that also pull the precompiled binaries from github, or when I invoke mix hex.publish locally, those are pulled down and pushed up to hex.pm?

Or you know, I could read https://github.com/cocoa-xu/cc_precompiler/blob/main/PRECOMPILATION_GUIDE.md 😆

Since I want to support as best as possible the last 3 versions of OTP (right now 25, 24, and 23), I'll need to build precompiled binaries for each version right? That shouldn't be difficult to do with a matrix, it just makes the precompiled binaries balloon.

support as best as possible the last 3 versions of OTP (right now 25, 24, and 23), I'll need to build precompiled binaries for each version right?

For these shared libraries (NIFs), as long as erlang:system_info(nif_version) stays the same then we don't have to build the precompiled binaries for each OTP version (instead we need to build for each nif_version that you'd like to support). ;)

Precompilation support added!

authors: cocoa-xu fire josevalim warmwaffles

repo: elixir-sqlite/exqlite

license: MIT


text:
rtl_light.css: ZOMFG and ROFL

.linkbutton:link, .linkbutton_right:link, .linkbutton_left:link,
.linkbutton:visited, .linkbutton_right:visited, .linkbutton_left:visited {
    border-left: 1px solid #afafaf;
    border-right: 1px solid #bfbfbf;
    box-shadow: -1px 1px 2px #e5e5e5;
}

/* Hover effects. */
.button_submit:hover, .right_submit:hover, .left_submit:hover,
.button_reset:hover,
.linkbutton:hover, .linkbutton_right:hover, .linkbutton_left:hover {
    border-left: 1px solid #ccc;
    border-right: 1px solid #afafaf;
    box-shadow: -2px 1px 1px rgba(0,0,0,0.07) inset;
}

Umm, what? Why is all this stuff in there? These are just button eye candy, As long as a button looks good, that's all that matters. There's absolutely no need to try and flip every damned style right to left just because the language changes. This applies to most elements.
This file should be almost empty. Rtl.css is just for positioning, and the vast majority of it should be done in the main rtl.css file.

Its April ... 10 years later :D

authors: Spuds StealthWombat

repo: elkarte/Elkarte

license_source: bigquery


text:
[BUG] Exclusive not taking effect

Describe the bug
I have been trying to debug this for a couple of hours but at a bit of a loss.
From what i can gather exclusive is meant to make the window take up space on the screen and not float above it.
eww is setting the window as exclusive at least in the code(I break pointed on it) but the window manager is not respecting it.
The bar i am creating is floating over windows.
Here is my configuration for the bar
(defwindow bar   :monitor 0   :exclusive true   :focusable false   :stacking "fg"   :geometry (geometry :x "0%"                       :y "0%"                       :width "20px"                       :height "100%"                       :anchor "left top")   (river-bar))
I fully believe i could just be misunderstanding how to make this work in wayland but from reading the documentation this seems to be the correct way.
I have tried the bar out in both river and sway both have the same issue.
Reproducing the issue
set exclusive to true in defwindow
Expected behaviour
The tiling window manager respects the exclusive space and doesn't allow it to overlap with windows.
Additional context
Image of window over lapping with bar:

Full configuration files used:
eww.scss.txt
eww.yuck.txt

Yeah it seems to be the same issue for top and bottom as well.
center is the only option that will reserve space.

@EuanFH Ok so after some further research and discussion:
this should work if you only had one window (i.e. you removed the clock window, and just showed the top left anchored bar.) That's obviously not the fix: If you want both, I'd recommend just going with making it one height 100% bar, and using something like centerbox to set the middle part as empty. That way you can avoid the weird case of having multiple exclusive windows attempt to be in the same place.
This might just work in other compositors, as far as it got explained to me river here simply chooses to not reserve any space because you have multiple clients be exclusive and anchored to the left

Is this then just a general issue with layershell? As in, is this something eww could avoid? How does sway handle this with other bars, for example?

zwlr_layer_surface_v1::set_exclusive_zone
"A positive value is only meaningful if the surface is anchored to one edge or an edge and both perpendicular edges. If the surface is not anchored, anchored to only two perpendicular edges (a corner), anchored to only two parallel edges or anchored to all edges, a positive value will be treated the same as zero."
If I'm reading this right it seems to be that any configurations that aren't center would be invalid and be considered non exclusive.
Since i am assuming center is anchoring to the left and right or to top and bottom which would allow for exclusive to work.

Any update on this?

Basically this is not a bug. The protocol is just built that way.

I had this same issue and ended up being able to fix my bar using :windowtype "dock".
According to the docks, this property is only supposed to do something on X11. However, on Hyprland no space is being reserved for my bar until I set it.

I had this same issue and ended up being able to fix my bar using :windowtype "dock". According to the docs, this property is only supposed to do something on X11. However, on Hyprland no space is being reserved for my bar until I set it.

Seems unlikely, given that the code only ever references WindowType::Dock in exactly one place, which is x11 specific ^^ I assume you also changed something else there?
Alternatively, you might be running eww using xwayland or something, lol

Anyways, given that this seems to be figured out (as per wayland-man snakedye <3), I'll close this issue for now!

Seems unlikely, given that the code only ever references WindowType::Dock in exactly one place, which is x11 specific ^^ I assume you also changed something else there?
Alternatively, you might be running eww using xwayland or something, lol

That's really weird indeed. The thing is, I've actually double-checked this, with changing just the one property. Additionally, I've checked that it is not running on xwayland. I'm using eww-wayland-git, and xwininfo doesn't detect the window.
Moreover, when I run it on an X11 Plasma session, it is detected by xwininfo (it is not on Plasma Wayland), but the bar appears in the center of the screen, presumably because I do not have any other X11 properties set:
(defwindow bar
  :monitor 0
  :exclusive true
  :geometry (geometry
    :height "1080px"
    :x "-4px" :y "0px"
    :width "52px"
    :anchor "left center"
  )
  :stacking "fg"
  :windowtype "dock"
(bar))

Maybe I should open a new issue for this, but I'm just playing around with eww for the first time, so there's too large a change I'm just doing something weird.

Can we get an error for this? i.e. for using :exclusive true without any of the valid anchors. Because while it seems to be the "expected" behavior of the protocol, it takes quite a while to figure out the solution.

@elkowar so having this how should i go about making a left or right window. I am very new to eww so i don't know any hacky way of doing this (if there is any).

Hello,
is there a solution for this yet? I'm having the same issue on Hyprland

I had this working a while ago, but now it seems broken. I have the top center tag in the geometry its not respecting the exclusion. I've tried changing to other anchor types including those that I wasn't expecting to work, but it still overlaps with the window titles
(defwindow bar0 :monitor 0                :geometry (geometry :x 0 :y 0 :height "15px" :width "80%" :anchor "top center")                :stacking "bg"          	:wm-ignore "true"                :exclusive "true"                :focusable "false"   (bar0 :monitor "eDP-1"))

I had an issue with some xwayland bug. I did
export GDK_BACKEND=wayland and export WAYLAND_DISPLAY=wayland-1 which fixed it.

authors: EuanFH ModProg Preetam-Das adsfibonacci bekaertruben elkowar sako-is snakedye tpkee

repo: elkowar/eww


text:
No way to get stuff like heredocs working

Would be really neat to have heredocs for different scripting things.

You can just use -r or --raw-mode to get pipr to not do weird processing to newlines 👍🏻

authors: buffet elkowar

repo: elkowar/pipr


text:
Fix input element drops characters

This is a fix for https://github.com/elm-community/elm-datepicker/issues/63.
This is a much simpler fix than https://github.com/elm-community/elm-datepicker/pull/58. It simply removes the onInput listener and uses the target value in on "change" instead. There wasn't anything I could find in the current set of functionality that required knowing about the state of the input field until the tab or return key has been pressed, or the input has been blurred. I'm not so sure there will be a reliable way to use onInput until the core virtual dom issue has been fixed.
I realise this would make https://github.com/elm-community/elm-datepicker/issues/31 impossible. Perhaps we can cross this bridge again when we come to it? Perhaps by then the vdom issue has been fixed (In 0.19 with any luck).
This builds on https://github.com/elm-community/elm-datepicker/pull/64, so if you're happy with this PR, you can close the other one, or if you're not happy with this one, you can close this one, and accept the other one (if you're happy with it).
I also added a more comprehensive test case. I'm happy to add more test scenarios that you can think of.

Thanks so much for jumping on this! The acceptance tests are a really nice throw-in.
I agree that live input doesn't actually seem to matter to the current application model, and I'd probably vote to merge this over #64. Pity about #31, but I'd rather have reliably passing tests and no feature regression than an unimplemented future feature 😄.
What do you think about removing model.inputText outright? It seems like it's always set to Nothing or itself, and so does nothing.

Good catch! I hadn't realised that. I've removed the inputText field, and the behaviour appears to be identical.

authors: bbqbaron mbylstra

repo: elm-community/elm-datepicker


text:
How to handle Server-side redirects?

When a user is unauthenticated, I'd like to use the server to redirect to a login page.
On remote http requests, the login page is returned in the response instead.
Is there a way to handle this?
Thanks!

Can you ask around on the Elm slack and see what folks say? If it seems to be an issue with the library, please open a new issue that outlines the technical requirements more clearly.

authors: evancz skinnyjames

repo: elm-lang/http


text:
Debugger click-to-resume overlay broken on 0.19

There's a regression in the Elm 0.19 debugger's "click-to-resume" feature. In Elm 0.18, when you time-travel into the past, a big "click-to-resume" overlay covers your app and clicking it time travels to the present. But in 0.19, the overlay is not shown. Clicking anywhere in your app while in this state will do nothing. It's especially bad if the user closes the debugger popup window while in this state, as they will be unable to reopen the debugger in order to resume.
Steps to reproduce
First, compile Main.elm using --debug
module Main exposing (..)

import Browser
import Html exposing (button, div, text)
import Html.Attributes exposing (id)
import Html.Events exposing (onClick)

main = Browser.sandbox { init = 0 , view = view , update = update }

type Msg = Increment

update _ n = n + 1

view n =
    div []
        [ text (String.fromInt n)
        , button [ onClick Increment ] [ text "+" ]
        ]

open the resulting index.html
click the "+" button a few times
open the Elm debugger popup
select a msg from the past
observe that inputs are blocked, but no overlay is shown

Here's a video demonstrating the bug in Safari (Chrome looks similar)
Notice that after time-travelling, clicking the "+" button in the Elm app does nothing, and the user has no way to know why it's not working.
I would expect an overlay to be shown like how Elm 0.18 does it:

But in 0.19, the overlay is not shown.

It is shown outside of the window. I could make it shown by adding position: fixed to the overlay (from devtool), but the "Resume" event was still not handled.
I think this is the event handler but seems like not working.
https://github.com/elm/browser/blob/813607120cad18bae101c9ec502733d9d940c612/src/Debugger/Overlay.elm#L147

Can we get some action on this issue? I want to demonstrate the awesomeness of Elm and use 0.19, but this regression would make me look silly if I try to show off the debugger.
Sounds like you know what to do, @jinjor

@Pilatch
I tried debugging hard, but it was really hard (against my expectation) and finally gave up. I think something is wrong in handling virtual DOM in the kernel logic. If you want to debug, you can do something like this.

That's pretty cool. I'm seeing a runtime error getting tossed.
Uncaught TypeError: domNode.replaceData is not a function
`function _VirtualDom_applyPatch(domNode, patch)
{
switch (patch.$)
{
case 0:
return _VirtualDom_applyPatchRedraw(domNode, patch.s, patch.u);
	case 4:
		_VirtualDom_applyFacts(domNode, patch.u, patch.s);
		return domNode;

	case 3:
		domNode.replaceData(0, domNode.length, patch.s);
		return domNode;`

But... it looks like this should have been resolved a while back. Maybe it's a regression. https://github.com/elm/virtual-dom/pull/20

Sorry, I get a very different behavior because I have a page with two Elm apps in it, and it barfs in special ways when I open both debuggers.

@evancz How do I debug codez in here so I can contribute? I tried jinjor's suggestion of using elm-kernel-debug, but that didn't honor the changes I made in the Browser module and compile them into index.html.
How do you do it when working on stuff?

@Pilatch Did you understand what the shell script does? It is just a dirty hack, not a library.

Yea, I understand what it's doing. I wanted to test the browser library, so I made changes in there, put it in the base of the project alongside virtual-dom, changed the package variable in the shell script and re-built. The script puts my changes into the 0.19.0 folder, but the generated index.html file doesn't have those changes in it.

OK, I think I see what's up. Thanks to a helpful person in slack, I discovered that you can negate the cache by deleting .dat files, and by putting stuff in your ~/.elm folder, which would mean the build script would change line 23 to
target_dir=~/elm/0.19.0/package/$author/$package/$version

Nope. Finally found it. There was a version conflict with virtual-dom. The one I was modifying was 1.0.2, but elm was building 1.0.0. Will update your readme and send pull request... among other things. :)

Update. Now that I have that running smoothly I can debug enough to confidently say:

The overlay can display properly by adding styles in Overlay.elm as @jinjor suggested.

                    , style "position" "fixed"
                    , style "top" "0"
                    , style "left" "0"

Clicking to resume is bugged not because of Elm code, but because of Debugger.js. I was reminded by the adage, "When you find a bug, it's probably in JS." We also know the Elm code is not at fault because the Resume button on the little popout thingy works as expected, and that just sends a simple Resume message.

We can prove this by allowing click events through. in the _Debugger_blocker function in Debugger.js we can add this check against click events, which will make the overlay's click event work as intended.
	if (event.type !== 'click')
	{
		event.stopPropagation();
		event.preventDefault();
	}

Of course that lets all click events through, which will have undesirable consequences and will probably corrupt the program's state in some cases. So my task is now to only allow click events on the overlay. How to do that is not immediately obvious because hoo-boy this code is funky!

Derp. Looks like I just needed to add id "elm-debugger-overlay" to the overlay in Elm. Incoming merge request.

Created. https://github.com/elm/browser/pull/40

The fix in #40 ended up in some debugger improvements that @Skinney worked on recently. The plan is to release that in a PATCH change by Monday, so it should be possible to get the fixed version by just changing from 1.0.1 to 1.0.2 once it is out!

authors: Pilatch evancz jinjor klazuka

repo: elm/browser


text:
Fix Sign-in Issues

This could be related to services protecting the site. @btopro and I will look into how to make sure these services don't interfere with sign-in and permissions for openulmus.org and its subsequent domains.

I made some /etc/hosts things, give it a shot and see if it helps

Testing ATM

Still Running into Access Denied Errors. Ran leafy 6 to clean up permissions and no changes.


text:
Upgrade Jest to fix "Interface 'JestImportMeta' incorrectly extends interface 'ImportMeta'."

Example error: https://github.com/eloquent/austenite/actions/runs/4936718660/jobs/8824596203#step:5:39
yarn exec --silent -- tsc --noEmit
Error: node_modules/@jest/environment/build/index.d.ts(401,26): error TS2430: Interface 'JestImportMeta' incorrectly extends interface 'ImportMeta'.
  The types of 'jest.replaceProperty' are incompatible between these types.
    Type '<T extends object, K extends Exclude<keyof T, keyof { [K in keyof T as Required<T>[K] extends ClassLike ? K : never]: T[K]; } | keyof { [K in keyof T as Required<T>[K] extends FunctionLike ? K : never]: T[K]; }>, V extends T[K]>(object: T, propertyKey: K, value: V) => Replaced<...>' is not assignable to type '<T extends object, K extends keyof T>(obj: T, key: K, value: T[K]) => ReplaceProperty<T[K]>'.
      Types of parameters 'propertyKey' and 'key' are incompatible.
        Type 'K' is not assignable to type 'Exclude<keyof T, keyof { [K in keyof T as Required<T>[K] extends ClassLike ? K : never]: T[K]; } | keyof { [K in keyof T as Required<T>[K] extends FunctionLike ? K : never]: T[K]; }>'.
          Type 'keyof T' is not assignable to type 'Exclude<keyof T, keyof { [K in keyof T as Required<T>[K] extends ClassLike ? K : never]: T[K]; } | keyof { [K in keyof T as Required<T>[K] extends FunctionLike ? K : never]: T[K]; }>'.
            Type 'string | number | symbol' is not assignable to type 'Exclude<keyof T, keyof { [K in keyof T as Required<T>[K] extends ClassLike ? K : never]: T[K]; } | keyof { [K in keyof T as Required<T>[K] extends FunctionLike ? K : never]: T[K]; }>'.
              Type 'string' is not assignable to type 'Exclude<keyof T, keyof { [K in keyof T as Required<T>[K] extends ClassLike ? K : never]: T[K]; } | keyof { [K in keyof T as Required<T>[K] extends FunctionLike ? K : never]: T[K]; }>'.
make: *** [.makefiles/pkg/js/v1/with-tsc.mk:4: tsc-typecheck] Error 2

Should be fixed in https://github.com/jestjs/jest/pull/14008 - just waiting on a new Jest release.

This is now fixed.

repo: eloquent/austenite


text:
Homework 6 - Robert Mkrtchyan, 10 V,  № 27th

From: TUES, Class 10 V, Robert Mkrtchyan, № 27th
All 3 programs for the 6th homework
I couldn't make "task3" to use a separate function, so everything is in main();

На task 2 не минават тестовете:

	task2 error (1 != Enter Number: 1)
	task2 error (0 != Enter Number: 0)

Това е защото имате 'Enter Number', в час Ви е казано, а също и в условието на домашното, че няма нужда от такива неща, тъй като тестовете не минават. Скриптът няма нужда от подсещащи съобщения. Направете нов pull request, за да оправите задачата

repo: elsys/po-homework

license: mit


text:
Build container images from released artifacts when building non dev tags

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

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

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

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

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

This works fine for make (with 2.2.1 as hard-wired default) but fails for make (with dev as hard-wired default) and make TAG=2.0.1 (to override the hard-wired default to build an older version).

There is also an issue with releases (e.g 2.2.1) where if you want to start the docker image as in the readme, you get two work dirs, one with some extra char at the name and it is messing things up. I didn't have much time to get to the bottom of it.

make elyra-image TAG=2.2.1 OK (sample pipeline runs fine locally)
make elyra-image TAG=2.1.0 OK (sample pipeline runs fine locally)
make elyra-image TAG=2.0.1 FAIL (Build errors with The Jupyter Server requires tornado >=6.1.0)

Looks like there are limits to how far back we can go version wise with a generic build approach. Sooner or later the referenced base image does require a package version that conflicts with what Elyra needs.

 make elyra-image TAG=dev fails because make isn't available during build

This is ready for review now, there seems to be an existing issue that has not been introduced by these changes and I created https://github.com/elyra-ai/elyra/issues/1550 to track it.

Also, this seems to have reduced the image name in about 1GB when building it from released artifacts
REPOSITORY                  TAG       IMAGE ID       CREATED             SIZE
elyra/elyra                 dev       758d3bbe9bd3   31 minutes ago      3.95GB
elyra/elyra                 2.2.1     0e162c701944   2 days ago          2.83GB

One thing I didn't realize is that make elyra-image TAG=dev builds the container image from the official dev repository's master branch, not the user's local file system. So as is, this can't handle these types of builds without requiring changes by the user.

make elyra-image TAG=dev builds the container image from the official dev repository's master branch, not the user's local file system.

Hmm - that seems like an issue.  The dev build should install whatever wheel file is in the local dist or build directories.

make elyra-image TAG=dev builds the container image from the official dev repository's master branch, not the user's local file system.

Hmm - that seems like an issue. The dev build should install whatever wheel file is in the local dist or build directories.

We tried that in the past, and there were a few issues related to how lab handles dependencies around extensions and no extensions. One way it would be to copy the user-cloned contents to the docker build directory and "COPY/ADD" that... but this is one thing that should be changed across all images and I would take that as another issue/pr.

but this is one thing that should be changed across all images

The other images pull from PyPI. This is currently the only Dockerfile with support to build from the local file system.

One way it would be to copy the user-cloned contents to the docker build directory and "COPY/ADD" that... but this is one thing that should be changed across all images and I would take that as another issue/pr.

Seems like the Developer Guide should include the necessary steps to build a custom image (that can include changes to both front and back ends) since that's probably a typical use case these days. (And just asked about on gitter. :smile:  )

Seems like the Developer Guide should include the necessary steps

The topic is right here: https://elyra.readthedocs.io/en/latest/developer_guide/development-workflow.html#building-the-elyra-container-image. Ideally the instructions are as simple as make elyra-image TAG=dev to build from local source and make elyra-image TAG=X.Y.Z to create an image from a published version on PyPI.

but this is one thing that should be changed across all images

The other images pull from PyPI. This is currently the only Dockerfile with support to build from the local file system.

Which I don't believe is the proper way, I would expect that xxx:1.2.0 builds from a release but xxx:dev build from the tip of master otherwise you can't really validate something on that image before a release.

Updated docs

@ptitzler see comment above https://github.com/elyra-ai/elyra/pull/1536#pullrequestreview-635095369

Want to include support for https://github.com/elyra-ai/elyra/issues/1557 or handle it in a separate PR?

authors: kevin-bates lresende ptitzler

repo: elyra-ai/elyra


text:
fix: Convert StackExchangeClustering to fast

Resolve #739

Checklist for adding MMTEB dataset

Reason for dataset addition:

[x] I have tested that the dataset runs with the mteb package.
[x] I have run the following models on the task (adding the results to the pr). These can be run using the mteb -m {model_name} -t {task_name} command.

[x] sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2
[x] intfloat/multilingual-e5-small

[x] I have checked that the performance is neither trivial (both models gain close to perfect scores) nor random (both models gain close to random scores).
[x] If the dataset is too big (e.g. >2048 examples), considering using self.stratified_subsampling() under dataset_transform()
[x] I have filled out the metadata object in the dataset file (find documentation on it here).
[x] Run tests locally to make sure nothing is broken using make test.
[x] Run the formatter to format the code using make lint.
[ ] I have added points for my submission to the points folder using the PR number as the filename (e.g. 438.jsonl).

Thanks for starting the work. Please create new tasks in the same file. Note the issue asks for not deleting the old task, but instead make the new one supersede the old one:

Superseed the old tasks
Since now you have new tasks in the benchmark, we don't need the old ones anymore.
However, do not delete the old tasks. Instead, add a superseeded_by attribute on the old tasks.
Thanks for catching that. Fixed it!

repo: embeddings-benchmark/mteb


text:
Update README to reflect move to ember-cli/ember-cli-deploy

Since moving ember-deploy to ember-cli/ember-cli-deploy we need to update the README.  It probably needs quite an overhaul but below are a few of the things mentioned in Slack.

[ ] Change references to ember-deploy and LevelBossMike
[ ] De-emphasise references to Luke's 'Lightening Deployments' presentation
[ ] Add something to the top of the README to briefly explain the migration that has happened and why users of the former ember-cli-deploy will probably be experiencing issues.

Looking closer at the README, it seems it will likely need quite an overhaul.  There are a few unknowns at this stage as well such as how the API will actually look.  So I'm not sure how much detail we can add right away.
Is everyone happy with cutting it down to what we do currently know right now and then building from there as we go?

Sure, take a crack at it @achambers

@achambers did #59 close this?

@samselikoff It will close this yes.  But that PR is maybe a bit premature as it relates to the pipeline work which isn't nailed down right now obviously.  I think that PR will start to make more sense as we start building 0.5.0.

We've got docs!

authors: achambers lukemelia samselikoff

repo: ember-cli/ember-cli-deploy


text:
Remove ember-qunit-notifications and import qunit-notifications from NPM

Death to Bower!
This should be totally backwards compatible. Though, do we want to throw an error/give a warning after upgrading if folks still have ember-qunit-notifications in their bower.json as it is no longer used?
Should also wait to merge for a release of qunit-notifications with this fix in it.
cc @stefanpenner @bcardarella

@stefanpenner r?

Published as v2.0.3.
@trentmwillis - Can you update ember-cli's blueprint to match these changes?

@rwjblue what updates would be needed? ember-cli-qunit is currently set to ^2.0.0 which seems fine unless we want to make 2.0.3 the minimum.

At least this https://github.com/ember-cli/ember-cli/blob/master/blueprints/app/files/bower.json#L6

Ah okay, can do, didn't look for that since it was part of the blueprint for this addon as well.

authors: rwjblue trentmwillis

repo: ember-cli/ember-cli-qunit


text:
[GUI-50] Kubernetes integration.

As for now, "integration" is just describing k8s objects within YAML files and making sure everything works OK.
Related JIRA's task: https://mongoose-issues.atlassian.net/projects/GUI/issues/GUI-57

Network policies should be applied.

repo: emc-mongoose/darzee


text:
Adds a No-SSL Installation Option

This patch adds a No-SSL installation option to the curl-bash
install script. Specifying the flag INSECURE=1 ahead of the initial
curl command causes the script's internal curl commands to specify
the -k flag, indicating that SSL warnings should be ignored.

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

Merging [#507][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master       #507   diff @@
==========================================
  Files             2          2
  Lines           194        194
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits             86         86
  Misses          108        108
  Partials          0          0

[][cc-pull]

Powered by Codecov. Last updated by [b1a73b5...a5101e8][cc-compare]
[cc-base-branch]: https://codecov.io/gh/emccode/rexray/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/emccode/rexray/compare/b1a73b55b47c4ca305e263a71d39c8fd4eb2bd7b...a5101e8b3b4182715d37d270f7e0717338ddb4e8?src=pr
[cc-pull]: https://codecov.io/gh/emccode/rexray/pull/507?src=pr

authors: akutz codecov-io

repo: emccode/rexray


text:
Remove BLOCKS_ALLOWED_IMAGE_EXTENSIONS

Describe the bug
This setting should not be used anymore since we ported the media file field stuff and validation to SmartMedia package.
To Reproduce
Not Available
Expected behavior
There is probably a few stale settings in defaults.py and documentation, this needs to be cleaned

Done in v1.3.2

repo: emencia/cmsplugin-blocks


text:
Pulsante lingua in homepage

@iltempe Per migliorare la fuibilità del sito, sarebbe meglio che in home page comparisse ben visibile il pulsante per passare da lingua inglese a quella italiana, così come era sul sito Covid19Italia.help (vedi immagine).

@cristigalas non ho capito...come lo vorresti fare?

@iltempe vorrei che il bottone language avesse la bandierina e fosse posizionato in alto nella barra blu della home, ben visibile. Lo potremmo mettere accanto al bottone che apre il menù.

@cristigalas non lo cambierei. se abbiamo una traduzione in una terza lingua occorre necessariamente il menu con la tendina come è adesso.

Va bene, lasciamo così e speriamo che la terza lingua arrivi…

authors: cristigalas iltempe


text:
Simple hello world program crashes when linked to hoard

Hi,
I have compiled Hoard according to the instructions under Windows 10 with Compiler "Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24218.1 for x64".
I have then created a new dir containing

hello.cpp
make.bat
libhoard.lib
libhoard.dll
uselibhoard.cpp

I am attaching the text files as "hg_test.zip" to this post:
hg_test.zip
I have then called "make" which creates "hello.exe", with this output on the console:
``
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24218.1 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.
hello.cpp
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xlocale(341): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\exception(359): warning C4577: 'noexcept' used with no exception handling mode specified; termination on exception is not guaranteed. Specify /EHsc
uselibhoard.cpp
Generating Code...
Microsoft (R) Incremental Linker Version 14.00.24218.1
Copyright (C) Microsoft Corporation.  All rights reserved.
/out:hello.exe
hello.obj
uselibhoard.obj
libhoard.lib
``
(OK - I have specified /EHsc in addition to get rid of those warnings, but this is irrelevant here as the crash still happens then.)
When I now execute "hello.exe", a popup window appears: "Appication Error - The application was unable to start correctly (0xc0000142). Click OK to close the application."
What am I doing wrong?
Best regards,
Hagen

Hi Emery, I have a VS 2017 solution for a similar issue.
MemAllocTest.zip
Thanks!
Abhi

There seem to be multiple issues here. For one, x86jump.h incorrectly assumes that 32-bit jumps will work within 4 GB on both sides of the jump, however since jump offsets are signed 32-bit values, this should be 2 GB max (0x7FFFFFFF, not 0xFFFFFFFF).
Also, it seems some Windows-internal components will have their own internal atexit/_onexit, but will call into ucrtbase's original _register_onexit_function which isn't shimmed anymore and ends up somewhat problematic on newer Windows 10 versions.

Great investigative work! Much appreciated. I can work on this soon but I would also gladly accept a PR :).

Great investigative work! Much appreciated. I can work on this soon but I would also gladly accept a PR :).

I tried fixing the rabbit hole of internal UCRT calls directly, but given that some internal _base functions aren't exported anymore it might need a larger rework of how winwrapper works in order for it to work with the new 'rewritten' UCRT. 😕

Hi,
Any news on the issue? I have a software that is running fine on Windows 2016, but crashes with the ucrtbase.dll immediately on Windows 2019.
Currently I'm able to run it with the 2013 horde version, but I'd like to upgrade to the latest version.
Thanks

authors: AbhiGHub barakw2021 blattersturm emeryberger hgaedke

repo: emeryberger/Hoard


text:
Selection Stroke Color is the same color for the cursor for the text box.

ui.visuals_mut().selection.stroke.color  is the same color for the text edit cursor, could you make it so we can change the color of the selection stroke color without changing the text edit cursor color. If you could just tell me where in the code the text edit cursor code is i might be able to do it myself, but im new to rust. So can you add this

Thats what im talking about

I think adding a separate cursor: Stroke to struct Visuals makes sense.
The code is in paint_cursor_end in egui/src/widgets/text_edit/builder.rs

authors: Eskerepvp emilk

repo: emilk/egui


text:
ImageSource::Bytes docs should mention URIs are used for format detection

Describe the bug
The new ImageSource::Bytes docs does not mention providing URIs are mandatory and used for format detection. This is kinda a significant detail.
Based on the current docs one might think these URIs are there just for error reporting and egui is using some kind of format probing on the provided data instead. At least that's what I first thought trying out the new API.

Good point - will fix momentarily

authors: emilk xTibor


text:
Facing scrolling problem if StickyScrollView contain listview or tab

In my layout containing Poster Image then Tab below the image and Tab contain Fragment how can i handle it.
And also facing problem when It contain listview, only listview scrolling is working

I have a same problem. Have no idea how to do it.

repo: emilsjolander/StickyScrollViewItems


text:
Support for replica sets?

I didn't see any support for replica set notation or multiple hosts.  We were able to get it working fine as long as we connected to our current primary node, but that node can change when there is a Mongo election.  Is there something I missed, or does it only have single-host support?

Actually you can make it work on the current version of this project if all your mongos run on the default 27017 port.
Just put your replica set hosts on host param and add replicaset name at the end of db param, like:
module.exports = {
host : 'host1,host2,hostN',
db : 'your_db_name?replicaSet=your_replicaset'
}
A specific parameter for replicaset name would be great and way more elegant though. If we have that parameter, utils.coffee would just need to have the cmds below before returning the connection string:
if config.replicaSet
s+= '?replicaSet=' + config.replicaSet
Hope it helps

I believe I've addressed this in #19 and supported replicaset names as well as alternate ports. Let me know if this works for you.

I've published version 0.6.0 just now, that includes this change from @antony, as well as some updates and refactoring (could result in slightly better performance). Please let me know how it works.

authors: antony codespelunker eberhara emirotin

repo: emirotin/mongodb-migrations


text:
Refactor AWS CLI script

[x] Install Terraform random provider
[x] Run Terraform init
[x] Generate out random bucket name
[x] output the random bucket name

Done


text:
Draw label outside chart

Is it possible to add an option to draw the label outside the chart?

I will try this when I have time.

Hi, this feature added in v0.4.0. You can try it.

That looks great @emn178 and was exactly what I was looking for. Thanks!


text:
lazy_static? multi threading?

Is there a suggested way to use this together with lazy_static and possibly also multi threading...?
I tried
lazy_static! {
    pub static ref PLUGINS: Plugins = create_plugins();
}

but lazy_static does not work with Rc<>, and changing Rc<> to Arc<> results in the following error:
the trait `std::marker::Sync` is not implemented for `*mut std::os::raw::c_void`
   = note: `*mut std::os::raw::c_void` cannot be shared between threads safely

Do you have any ideas? The error suggests that we shouldn't use it with multi threading anyway...

Hi,
I haven't looked into this no. When you resolve a symbol from the library it should be possible to call it on other threads as "extracting" the pointer is an unsafe operation and calling the code itself is unsafe as well.
I can try to take a look at this but it won't happen for a while because I'm currently busy with other stuff. Sorry about that.

Thanks.
Actually the issue already exists in rust_libloading, so I'll report it upstream.

This was already fixed in rust_libloading. Please update the version to 0.3.
Thanks!

Alright. I will try to get around to do this later today.

Hi. I tried update to 0.3 of rust_libloading and I'm running into some issues in the tests. I'm sorry but simply don't have time to investigate why it doesn't work right now.

No worries, I totally understand your situation.
Fortunately only one path was wrong; here's what you have to change to fix the failing tests:
change src/lib.rs:520 to
let lib_path = exe_path.parent().unwrap().parent().unwrap();
And, of course, change Cargo.toml:16 to
libloading = "0.3.0"
Then,
test result: ok. 22 passed; 0 failed; 0 ignored; 0 measured
I could have submitted a PR, but this is really just a one-liner ;-)
Thanks for taking your time.

Ah cool. I can get that sorted out then :) I will try to release a new updated version later today. Thanks for looking into the issue :)

I have release version 0.2.1 now which includes updated rust_libloading to 0.3.0

Thanks.
Unfortunately, I had to fork anyway: Multi threading requires Arc<> instead of Rc<>.
You shouldn't incorporate this as a default, of course... Maybe there is a clever way to support both.

Ah I see. Yeah I will have to think about that one.

@fivethousand just FYI I have updated 0.3.0 of this crate to use Arc<> instead of 'Rc<>'

authors: emoon fivethousand


text:
[Bug] toggle Subscriptions, the contents of the send box are cover

What did I do
Something you have done.
What happened
toggle Subscriptions, the contents of the send box are cover.
Expected
What is the expected result.
Environment

OS: OS version, e.g. MacOS Big Sur 11.1
MQTTX version, e.g. v1.5.0

More detail
More detail include log information or screenshot

Hi! Thanks for your feedback! But could you please describe the problem more specifically? It is better to have a reproducible step.

Hi! Thanks for your feedback! But could you please describe the problem more specifically? It is better to have a reproducible step.

step1: step1
step2: https://tva1.sinaimg.cn/large/008i3skNgy1grd8scutl0j31520u0q7t.jpg    msg normal
step3 : https://tva1.sinaimg.cn/large/008i3skNgy1grd8uwuv32j31520u043b.jpg   msg cover

@mengday OK, thanks! I successfully reproduced it, sorry, this is a bug, we will fix it as soon as possible.

Hi, thanks again! It is now fixed at https://github.com/emqx/MQTTX/releases/tag/v1.6.0.

authors: mengday ysfscream

repo: emqx/MQTTX


text:
adds basic img generation script

Needs some cleanup and exception handling but POC.

Base image needs more pixels — in Figma you can export 3x or more

repo: enclosed-money/metadata-server


text:
Replace Unity DI container with Ninject

I decided to replace [Unity] (https://msdn.microsoft.com/en-us/library/ff647202.aspx) Dependency Injection container with Ninject because Ninject has simpler syntax and its most used features are easier to learn than Unity.

Task completed. Closing issue.


text:
Fail fast mode

fix #274

Added test app with two same errors (TypeError), I suppose that it is needed to keep only same errors because of async code. We can not ensure which error will be invoked as first...

How to cancel async function handle_urls at the moment when first Exception occurs and all tasks which are in progress parallely?

I've changed to TypeErrors to ValueErrors, because of test_expected_output.py, where we catch group of two exceptions (ValueError, MultiError). If I use ValueError I dont have to add another exception to this group.

The output of freezeyt for user usage should be made nicer, if he uses fail-fast config. Add attribute fail-fast to Freezer_info and then improve the output...

Create your own Error! Done :heavy_check_mark:

There is a problem with progressbar. Progressbar does not show at the end of CLI, if small number of pages is defined in app there is no any progressbar shown. If I've specified more than 200 pages and start freezeyt with option -x then I saw progressbar....

repo: encukou/freezeyt


text:
Rename purl to identifiers

purls wasn't a very descriptive key, so changed it to identifiers. Others that I considered were:

package-info
package-identifiers

But I wanted to avoid the package bit, as it doesn't work across all products (devices, services etc).

Conflicts resolved.


text:
add lldb::SBTarget::load_core() function

add support for loading core dump file

Thanks! I'm going to merge this, but it should, perhaps, take a path instead of a string?


text:
[Feature] - Add Build step to CI

Try to trigger a build every push to main branch
You can release the build too

https://medium.com/empathyco/applying-ci-cd-using-github-actions-for-android-1231e40cc52f
https://proandroiddev.com/android-ci-cd-pipeline-with-github-actions-demystifying-github-actions-83258e76a18f

repo: enesky/Doodle


text:
Parameter Description is cluttered in some function

Expected

For some functions

We need to add an empty line after every parameter


text:
add support for binding inbound socket to local address

On a server with multiple IP addresses it can be necessary to be able to specify which interface/address to bind the client socket to.

This covers your use case, but there are other options in the net.createConnection() method and I don't want to add a param everytime there is one someone needs.
What if instead of changing the constructor to add the param we just supported passing in a socket directly as the first param? That way you can configure it however you want and just pass it in.
Something that would be used like:
var net = require('net');
var esl = require('modesl');

var socket = net.connect(/* your options */);
var conn = new esl.Connection(socket, function () { /* connect listener */ });

That ensures that you can configure the socket however you want.

Closing this as v2 will support this use case in a couple different ways.

authors: davehorton englercj

repo: englercj/node-esl


text:
devMode false causes 500 error

Hi,
When we disable the devMode on our live-environment, the view for mapping the feed throws an 500 error exception. When I enable the devMode, the mapping-page is rendered correct and I can map the values to the right columns.
We're using version: 1.4.12
Does anyone has a suggestion or a solution?

Anything in your phperrors.log file? Or feeme.log?

Hi,
Srry, didn't let you know that the problem was solved.
Somehow it magically worked again, so I still don't know what the problem was...
Thanks for your response anyway! 😄

authors: engram-design niekjansenNL

repo: engram-design/FeedMe


text:
New helper interface

New Utility functions
Utility functions are provided to access your generated stylesheet:
import { styles } from '@enhance/arc-plugin-styles'

styles.getLinkTag()   // a <link rel="stylesheet"> tag
styles.getStyleTag()  // a <style> tag for inline styles
styles.getPath()      // root-relative path to the .css file

getAll() is also available to create an object with each result:
import { styles } from '@enhance/arc-plugin-styles'

const myStyles = styles.getAll()
myStyles.link    // a <link rel="stylesheet"> tag
myStyles.style   // a <style> tag for inline styles
myStyles.path    // root-relative path to the .css file

Experimental build
npm i @enhance/arc-plugin-styles@0.0.0-experimental-01a238802ea89c01fe11276c784566ed7fd63045

Having used this interface in a branch over on enhance-dev/arc-plugin-enhance#48 I'm wondering if this change would be more ergonomic
import { getStyles } from '@enhance/arc-plugin-styles'

getStyles.linkTag()   // a <link rel="stylesheet"> tag
getStyles.styleTag()  // a <style> tag for inline styles
getStyles.path()      // root-relative path to the .css file

I really wanted to keep "get" in the interface name so it's clear that you can't set anything here. Also now I can author something like this and actually use the const name style
const styles = getStyles.styleTag()

repo: enhance-dev/arc-plugin-styles


text:
Ingesting of data from ccxt exchanges has some errors.

Dear Catalyst Maintainers,
Before I tell you about my issue, let me describe my environment:
Environment

Operating System: Linux s 4.10.0-42-generic #46-Ubuntu SMP Mon Dec 4 14:38:01 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Python Version: python3.5.3

Python Bitness: 64

How did you install Catalyst: pip3

Python packages:
aiodns==1.1.1
aiohttp==2.3.9
alabaster==0.7.10
alembic==0.9.7
aniso8601==1.3.0
apparmor==2.11.0
apparmor.click==0.3.18
appdirs==1.4.3
apturl==0.5.2
asn1crypto==0.24.0
astroid==1.5.3
async-timeout==2.0.0
Babel==2.4.0
bcolz==0.12.1
beautifulsoup4==4.6.0
beautysh==3.7
bitcoin==1.1.42
blinker==1.3
boto3==1.5.20
botocore==1.8.34
bottle==0.12.13
Bottleneck==1.2.1
Brlapi==0.6.5
bs4==0.0.1
cchardet==2.1.1
ccxt==1.10.840
certifi==2018.1.18
cffi==1.11.2
chardet==3.0.4
click==6.7
coincurve==6.0.0
command-not-found==0.3
contextlib2==0.5.5
CProfileV==1.0.7
crypto==1.4.1
cryptography==2.1.4
cycler==0.10.0
cyordereddict==1.0.0
Cython==0.27.3
dateparser==0.6.0
decorator==4.2.1
defer==1.0.6
devscripts===2.16.8ubuntu2
discord==0.0.2
discord.py==0.16.12
distro-info===0.14build1
docutils==0.14
dryscrape==1.0.1
EasyProcess==0.2.3
empyrical==0.2.1
enigma-catalyst==0.4.7
enum34==1.1.6
eth-testrpc==1.2.0
ethereum==2.0.4
ethereum-abi-utils==0.4.0
ethereum-serpent==2.0.7
ethereum-utils==0.2.2
feedparser==5.1.3
Flask==0.12.2
Flask-RESTful==0.3.6
future==0.16.0
gevent==1.2.1
greenlet==0.4.12
html5lib==0.999999999
httplib2==0.9.2
humanfriendly==4.7
idna==2.6
imagesize==0.7.1
intervaltree==2.1.0
ipaddress==1.0.18
ipython-genutils==0.2.0
isort==4.2.15
itsdangerous==0.24
Jinja2==2.9.6
jmespath==0.9.3
json-rpc==1.10.3
jsonschema==2.6.0
jupyter-core==4.4.0
jusText==2.2.0
keyring==10.5.1
keyrings.alt==2.2
kik==1.5.0
langdetect==1.0.7
language-selector==0.1
launchpadlib==1.10.4
lazr.restfulclient==0.13.4
lazr.uri==1.0.3
lazy-object-proxy==1.3.1
LibAppArmor==2.11.0
Logbook==1.1.0
louis==3.0.0
lru-dict==1.1.6
lxml==4.1.1
Mako==1.0.7
MarkupSafe==1.0
matplotlib==2.1.1
mccabe==0.6.1
minidb==2.0.2
mpl-finance==0.10.0
multidict==4.0.0
multipledispatch==0.4.9
Naked==0.1.31
nbformat==4.4.0
networkx==2.1
nltk==3.2.5
numexpr==2.6.4
numpy==1.14.0
oauth==1.0.1
oauthlib==2.0.6
pandas==0.19.2
pandas-datareader==0.5.0
patsy==0.5.0
pbkdf2==1.3
pbr==1.10.0
PeakUtils==1.1.0
pep8==1.7.1
pexpect==4.2.1
Pillow==4.0.0
plotly==2.2.3
pluggy==0.5.2
psutil==5.0.1
ptyprocess==0.5.1
pushbullet.py==0.11.0
py==1.4.34
py-ecc==1.1.3
pyasn1==0.1.9
pycares==2.3.0
pycodestyle==2.3.1
pycparser==2.18
pycrypto==2.6.1
pycryptodome==3.4.6
pycups==1.9.73
pydocstyle==2.1.1
pydub==0.20.0
pyethash==0.1.27
pyflakes==1.6.0
Pygments==2.2.0
pygobject==3.22.0
PyJWT==1.5.3
pylama==7.4.3
pylama-pylint==3.0.1
pylint==1.7.4
pylru==1.0.9
pylxd==0.18.0
pyOpenSSL==17.3.0
pyparsing==2.2.0
PyQt5==5.9.2
pysha3==1.0.2
PySocks==1.6.8
pytest==3.2.3
python-apt==1.4.0b2
python-dateutil==2.6.1
python-debian==0.1.30
python-editor==1.0.3
python-magic==0.4.13
python-telegram-bot==9.0.0
python-twitter==3.3
pytrends==4.3.0
pytz==2017.3
PyVirtualDisplay==0.2.1
pyxdg==0.25
PyYAML==3.12
raven==6.4.0
raven-aiohttp==0.6.0
redo==1.6
regex==2018.1.10
reportlab==3.3.0
repoze.lru==0.7
requests==2.18.4
requests-file==1.4.3
requests-ftp==0.3.1
requests-oauthlib==0.8.0
requests-unixsocket==0.1.5
rlp==0.6.0
ruamel.yaml==0.15.35
s3transfer==0.1.12
scikit-learn==0.19.1
scipy==1.0.0
scrypt==0.8.0
seaborn==0.8.1
SecretStorage==2.3.1
selenium==3.4.3
sessioninstaller==0.0.0
shellescape==3.4.1
simplejson==3.10.0
sip==4.19.6
six==1.11.0
sklearn==0.0
sky==0.0.198
slackclient==1.1.0
snowballstemmer==1.2.1
socketclusterclient==1.2.2
sortedcontainers==1.5.9
Sphinx==1.6.2
sphinxcontrib-websupport==1.0.1
SQLAlchemy==1.2.2
ssh-import-id==5.6
statsmodels==0.8.0
system-service==0.3
systemd-python==233
TA-Lib==0.4.10
tables==3.4.2
telegram==0.0.1
textblob==0.15.1
tinydb==3.3.1
tldextract==2.2.0
toolz==0.9.0
tornado==4.5.2
tox==2.9.1
traitlets==4.3.2
twilio==6.6.3
tzlocal==1.5.1
ubuntu-drivers-common==0.0.0
ufw==0.35
unattended-upgrades==0.1
unicodecsv==0.14.1
unity-scope-calculator==0.1
unity-scope-chromiumbookmarks==0.1
unity-scope-colourlovers==0.1
unity-scope-devhelp==0.1
unity-scope-firefoxbookmarks==0.1
unity-scope-gdrive==0.7
unity-scope-manpages==0.1
unity-scope-openclipart==0.1
unity-scope-texdoc==0.1
unity-scope-tomboy==0.1
unity-scope-virtualbox==0.1
unity-scope-yelp==0.1
unity-scope-zotero==0.1
unity-tweak-tool==0.0.7
urllib3==1.22
urlwatch==2.7
usb-creator==0.3.3
vaderSentiment==2.5
virtualenv==15.1.0
wadllib==1.3.2
web3==3.8.0
webencodings==0.5
websocket-client==0.45.0
websockets==3.4
Werkzeug==0.12.2
wrapt==1.10.11
ws4py==0.3.4
xkit==0.0.0
yarl==1.1.0
zope.interface==4.3.2

Now that you know a little about me, let me tell you about the issue I am
having:
Exchanging data from binance/kucoin and probably all the other exchanges that are not supported for trading:

Doesn't show a progress bar when downloading. It only shows that it is finished, no way to know if it has hanged.
It doesn't create the symbols.json in the .catalyst/data/exchanges directory so catalyst run just fails silently. I found this is the reason it fails by looking hopelessly through strace. I am open to better suggestions for debugging. xD
If i copy it from poloniex it calls initialize but then fails cause the symbols are different between the exchanges. This is to be expected but it shows the symbols.json absence is the problem.

Here is how you can reproduce this issue on your machine:
catalyst ingest-exchange -x binance -f daily
Sincerely,
$ whoami

@fredfortier Hey Fred, I know you guys were going full steam at that first Engima release, and bugfixing on Catalyst, but is there an ETA on Binance ingesting? I've been trading on Poloniex this whole time, but running into random issues, and only trading there because it's available for ingesting, would much prefer Binance. Thanks!

Yes, we’re later than expected on this milestone because of the reasons
which you mentioned. But we now have a much bigger team and we are catching
up. We’re just putting the final touches on the branch which includes
Binance data and testing. We’ll release very soon.
On Thu, Feb 15, 2018 at 7:09 AM brinew27 notifications@github.com wrote:

@fredfortier https://github.com/fredfortier Hey Fred, I know you guys
were going full steam at that first Engima release, and bugfixing on
Catalyst, but is there an ETA on Binance ingesting? I've been trading on
Poloniex this whole time, but running into random issues, and only trading
there because it's available for ingesting, would much prefer Binance.
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/enigmampc/catalyst/issues/188#issuecomment-365955401,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABZ-QnFuLlMVm3n3p9_kX1pYgnA9-bGcks5tVEiQgaJpZM4Rs0nw
.

Binance historical data was added at release 0.5.15

repo: enigmampc/catalyst


text:
Move Asset Panel open state to zustand

Pull Request Description

Move Asset Panel open state to zustand

This avoids re-rendering the entire Data Catalog view every time an asset is clicked
It's not a perfect solution to the perf issues, however I think it's better to re-evaluate performance once more PRs have been merged in.

Important Notes
None
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[x] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
TypeScript,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
[x] Unit tests have been written where possible.

Something is really broken here I think. Is this because I had it opened before closing on different branch?

yeah my bad, idk what happened there... will look into asap since it should be a relatively easy fix

found the issue, pushing rn

status update: will be continuing to investigate perf issues here.

pinging @MrFlashAccount for CR.

uh oh...

repo: enso-org/enso


text:
Wrangle all FOD wiki's into one config

Needed prior to installation on Meza1-the-server

Useful script to pull all extension info from browser console (must be viewing page on wiki's server):
var wikiBaseURL = "https://example.com/wiki/";
var wikis = ["wiki1", "wiki2", "wiki3"];

var allExtensions = {};
var wikiCompletionStatus = {
	// wiki1: false,
	// wiki2: false,
	// wiki3: false
};

function allWikisComplete () {
	for ( var i in wikiCompletionStatus ) {
		if ( wikiCompletionStatus[i] === false ) {
			return false;
		}
	}
	return true;
}

function printWikiInfo () {
	var output = "Extension\t";

	for( var w in wikis ) {
		output += wikis[w] + "\t";
	}
	output += "\n";

	var extList = [];
	for( var e in allExtensions ) {
		extList.push( e );
	}
	extList.sort();

	for( var i in extList ) {
		e = extList[i];

		output += e + "\t";
		for( var w in wikis ) {
			var extOnWiki = allExtensions[e][ wikis[w] ]
			if ( extOnWiki ) {
				if ( extOnWiki.version ) {
					output += extOnWiki.version + "\t";
				}
				else if ( extOnWiki.git ) {
					output += "git: " + extOnWiki.git + "\t";
				}
				else {
					output += "No version info\t";
				}
			}
			else {
				output += "Not installed\t";
			}
		}
		output += "\n";
	}

	console.log( output );
}

for ( var w in wikis ) {
	var wikiName = wikis[w];
	wikiCompletionStatus[wikiName] = false; // initially not yet complete

	// request extension info from this wiki
	console.log( "requesting " + wikiName + " extensions" );
	$.getJSON(
		wikiBaseURL + wikiName + "/api.php",
		{
			action: "query",
			meta: "siteinfo",
			siprop: "extensions",
			format: "json"
		},
		(function( wiki ){
			return function( response ) {
				console.log( "received " + wiki + " response; processing..." );
				var extensions = response.query.extensions

				for( var i in extensions ) {

					var e = extensions[i];
					if ( ! allExtensions[e.name] ) {
						allExtensions[e.name] = {};
					}

					allExtensions[e.name][wiki] = {
						version: ( e.version ? e.version : "" ),
						git: ( e["vcs-version"] ? e["vcs-version"].substring( 0, 6 ) : "" )
					};

				}

				// mark this wiki complete
				console.log( "complete recording " + wiki + " extensions" );
				wikiCompletionStatus[wiki] = true;

				// check if others are complete
				if ( allWikisComplete() ) {
					printWikiInfo();
				}

			};
		})( wikiName )
	);

}

NumerAlpha is the last remaining item out of config: TOPO has a different version than everyone else. This Gerrit patch will be the merge of the two versions so everyone can use the same extension.

I removed the "Record how to make Windows-based wiki farm on mediawiki.org" from the list of requirements, and am adding it as a task on the FodWikiSettings repository. Recording this for public consumption could require quite a bit of work. Furthermore, we should probably iron out some things in our setup beforehand.


text:
[EWEPNT] Phantasia - Crashes entering world after character creation

Module Information

Identifier: EWEPNT
Module Name: Phantasia
Version: (C)1995

Describe the bug
Crashes entering world after character creation
To Reproduce
Steps to reproduce the behavior:

Load Module
Enter Module
Create Character
See error

Expected behavior
Ability to create character and enter world
Screenshots
2020-11-15 17:24:53.7480 Warn MBBSEmu.HostProcess.ExportedModules.Majorbbs.prfmsg prfmsg() unable to locate message number 1973 in current MCV file EWEPNT.MCV
Unhandled exception. System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. (Parameter 'Unsupported OpCode: Fchs')
   at MBBSEmu.CPU.CpuCore.Tick()
   at MBBSEmu.HostProcess.ExecutionUnits.ExecutionUnit.Execute(IntPtr16 entryPoint, UInt16 channelNumber, Boolean simulateCallFar, Boolean bypassState, Queue`1 initialStackValues, UInt16 initialStackPointer)
   at MBBSEmu.Module.MbbsModule.Execute(IntPtr16 entryPoint, UInt16 channelNumber, Boolean simulateCallFar, Boolean bypassSetState, Queue`1 initialStackValues, UInt16 initialStackPointer)
   at MBBSEmu.HostProcess.MbbsHost.WorkerThread()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
   at System.Threading.ThreadHelper.ThreadStart()

Software Information:

OS: Windows Server 2019 Standard
Telnet Client: NetRunner
MBBSEmu Build: 111220-2

Wanted to let you know I'm the original author of Phantasia back in the MBBS days. Not sure I still have the source code anymore (and not sure it would even help). The error message looks like the MSG isn't in the MCV file. This might be a bug that the MSG is missing the message or the MCV is out of sync with the MSG.

Hey Bil! Welcome to the fun! 😄
The warning of the missing message above is a bit of a red herring, the line after it is the exception being thrown that the x86 core is missing the opcode implementation for FCHS.
We'll need to get FCHS added, which changes the sign value in ST(0) (negative->positive, positive->negative) in ht x87 FPU Stack

I found a new version 0.3Beta ... it throws this OPCode -- guessing it will need both though
2020-11-17 06:45:36.9601 Error MBBSEmu.HostProcess.ExportedModules.ExportedModuleBase.FormatPrintf Invalid Pointer: 2061:6E61
Unhandled exception. System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. (Parameter 'Unsupported OpCode: Fsubp')
   at MBBSEmu.CPU.CpuCore.Tick()
   at MBBSEmu.HostProcess.ExecutionUnits.ExecutionUnit.Execute(IntPtr16 entryPoint, UInt16 channelNumber, Boolean simulateCallFar, Boolean bypassState, Queue`1 initialStackValues, UInt16 initialStackPointer)
   at MBBSEmu.Module.MbbsModule.Execute(IntPtr16 entryPoint, UInt16 channelNumber, Boolean simulateCallFar, Boolean bypassSetState, Queue`1 initialStackValues, UInt16 initialStackPointer)
   at MBBSEmu.HostProcess.MbbsHost.WorkerThread()
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
   at System.Threading.ThreadHelper.ThreadStart()

I'm working on a new branch right now with new opcodes for Crossroads of the Elements, I'll get these two added to that as well! 👍

@bsimser Hey Bil -- If you're able to locate the source code (for this or other modules) let me know! It would be a huge help to getting it emulated properly 😄
You can reach me directly at eric@nusbaum.me

authors: bsimser enusbaum tuday2

repo: enusbaum/MBBSEmu


text:
Secret integration for AWS parameter store

Up until now, dotgpg has served us well and allowed us to restrict who
has access to what secrets within our stacks. However, we now have a
need to do more automation with our cloudformation stacks and we aren't
fully comfortable giving non-humans GPG access.
To address this, I've considered adding a new parameter resolver that
uses AWS parameter store and permission off access via a new IAM policy
that would restrict what secrets the service would have access to. This
would also allow us to move all the secrets into parameter store and
allow/deny access to individual secrets instead of our current all or
nothing approach some services have.
Is this something others would be interested in?

+1, although I'd be more interested in a secret store that uses KMS to encrypt a secret file (similar to the GPG one) over Parameter Store. I'd prefer that because changes to parameters would be kept in source control. Although you can view a given parameters changes in ParameterStore, a parameter can't be retrieved after it's deleted.

@stevehodgkiss so in your mind a file with a key:value pair encrypted with KMS would be a better idea? Is this how you'd envision the workflow?

Developer assumes role with correct KMS permissions
Decrypts local copy of file
Adds/Updates file
Recrypts file
Commit to version control

I don't mind the concept however I would be slightly concerned about people forgetting to recrypt with KMS being committing back to the repository. dotgpg prevents this because you need to use dotgpg edit <file> and it handles encryption on exit.

Sorry, just noticed this issue. I should have perhaps got involved here before I did my parameter store resolver.   Check out release 1.2.0 @jacobbednarz it might be sufficient for your needs.
The biggest problem with using IAM as fine grained arbiter (via KMS  key policies)  of who gets access to which parameter is the case where a common role is used by folks when manipulating stacks rather than individual accounts...


text:
fix syntax issue

fixes warning with syntax in jruby-9.1.* #19
The warning was
`-' after local variable or literal is interpreted as binary operator

For reference:
Related error
https://github.com/colbygk/log4r/issues/52

@stevehodgkiss any update on this?

repo: envato/zxcvbn-ruby


text:
ORG $-1 directive recognised in listing but not in the generated binary file.

Version 1.4 of the Agon Light ez80asm assembler.
Code such as:
DW	LABEL-$
ORG	$-1
DW	LABEL-$
ORG	$-1
DS	48
LABEL:
Will show in the ez80asm listing that the ORG statement decrements the assembly address.
However, the bin file does not show this. The .lst and .bin files disagree.
The generated code is different from the listing.
Background: a common coding technique is the generate an array of offsets to relevant code.
This is often an array of single bytes with low offsets.
DB LABEL-$ will not be accepted by the Agon Light ez80asm.
The Zilog ZDS tool has an embedded ez80asm assembler that offers LOW( ) and HIGH ( ) functions to assist e.g. LOW(LABEL-$).
The documntation says ORG should be followed by a constant.
Does this mean that ORG $-1 is itself invalid?
How should the coding required be generated?

I'm currently at release 1.6, which does support DB label-$

I accept your explanation but with some minor points: the error does not get shown in the assembler output messages or the listing. It doesn't fail the assembly or warn that the code generated will be different from the listing.Does it need a setting to show warnings?I am now completely stuck on how to generate a value that is acceptable to a DB instruction from an expression using a relocatable value (a location). Can you help?I can understand that the assembler may not know whether the expression would be corrupted on only moving bits 7-0 to the DB. But isn't this over-protective? Isn't this similar to type-casting in the C language e.g.... = (byte) valueor... LOW(value)In fact the assembler can know on pass 2 whether the expression will actually fit in a byte or on pass 1 if the location is before the DB.It could warn then...Thank you for you help and assembler.On 23 Apr 2024 13:57, Jeroen Venema @.***> wrote:
I've checked ZDS, which gives 'ERROR (507) Relocatable values not allowed in this expression' when given a
ORG $-1
While both ez80asm and ZDS allow for setting a different ORG later on in code, it doesn't reflect on either's assembled output.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Good to hear; starting 1.6, the DB/DW statements are much less strict and only give warnings if fed a larger number than the length can hold.
You can also use compound statements to get to the high/low byte of a constant or label, like so
.db $>>16 ; gives the high byte
.db $ & 0xFF; gives the low byte
As a side-note, the AgonLight2 is less risky then you might think. When the agon-flash utility fails somehow and the MOS gets borked, you can always use the agon-recovery utility, which requires just two dupont jumpercables to recover MOS. I've written both utilities and done literally hundreds of flash installs/recoveries.

Some news:I tried the fab-agon-emulator 9.0.43 with ez80asm 1.6.Happily DB label-$ now passes. Didn't try if the calculation is >255.However ORG $-1 behaviour is unchanged (but I don't need it now!).When trying to assemble 20,000 source lines and generate around 16k of binary I get "out of memory" and an ungraceful end. Worked on 1.2! Trivia: assembler now objects to 1234 // 5.I was looking for a modulus operator like 1234 % 256. Would be useful.Thanks.Simon.On 23 Apr 2024 17:22, Jeroen Venema @.***> wrote:
Good to hear; starting 1.6, the DB/DW statements are much less strict and only give warnings if fed a larger number than the length can hold.
You can also use compound statements to get to the high/low byte of a constant or label, like so
.db $>>16 ; gives the high byte
.db $ & 0xFF; gives the low byte
As a side-note, the AgonLight2 is less risky then you might think. When the agon-flash utility fails somehow and the MOS gets borked, you can always use the agon-recovery utility, which requires just two dupont jumpercables to recover MOS. I've written both utilities and done literally hundreds of flash installs/recoveries.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

org behavior is similar to other assemblers on the market, which I agree with behavior-wise, so that will not be changed.
Original question has been resolved a while back. User was running an older version of the assembler.

authors: SimonStickling envenomator


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

In 1b59d82, 905 (Managed - Web) - HTTPS ($URL_905) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 905 (Managed - Web) - HTTPS is back up in 7960b24.

repo: envesko/status


text:
xcode: update to 12.5.1

Signed-off-by: Jose Nino jnino@lyft.com

https://github.com/envoyproxy/envoy-mobile/pull/1720

repo: envoyproxy/envoy-mobile


text:
Add several data accessors into wasm API

Add getHeaderMapSize, getDestinationPort and getResponseCode into WASM API.
cc @jplevyak @PiotrSikora

It is for the request size metrics that we collect: https://cloud.google.com/monitoring/api/metrics_anthos#anthos-istio.io

Erm, getHeaderMapSize() has nothing to do with sent / received bytes as needed in metrics.

@PiotrSikora Hmm, but there is no good way to get the bytes transferred on wire easily in filter right? HeaderMapSize() + body_buffer_size could give us a rough idea on the bytes transferred.

@bianpengyuan it looks that StreamInfo has bytesReceived()... but it returns only body bytes received, without headers... so indeed, there is no easy way to do that right now.
But exporting HeaderMapSize() + body_buffer_size as received_bytes_count  is wrong (fine for the demo, though), especially with HTTP/2, because of HTTP/2 framing overhead and HPACK, where the number of bytes calculated this way can be an order of magnitude different from what's on the wire. This also doesn't include the TLS/SSL overhead.

@PiotrSikora Ok, looks like the change needs to be made in upstream.

authors: PiotrSikora bianpengyuan

repo: envoyproxy/envoy-wasm


text:
QUESTION: Static Configuration Failing Validation

QUESTION: Static Configuration for Admission Control Failing Validation
Description:
I’m trying to write a static configuration file to configure an admission control filter in a testing environment. The sr_threshold and max_rejection_probability fields are the source of errors. The configuration is valid if I comment them out (so that default values are used). It seems the problem is a type issue with v3.Percent for those 2 fields. INVALID_ARGUMENT:(sr_threshold.default_value): invalid value "95.0" for type type.googleapis.com/envoy.type.v3.Percent
What am I doing wrong here? I’ve tried numerous combinations of specifying the typed_config or not, etc, copying patterns from other examples, etc
Thank you!

Sorry if I'm being dense here, but still not able to get it to work.
The snippet from the docs says:
...
  sr_threshold:
    default_value: 95.0
    runtime_key: "admission_control.sr_threshold"
...

That didn't work. I also tried replacing default_value with value; having both fields there; also tried both those options with the typed_config for v3.Percent. All no bueno.
The errors flip between what I posted above and Protobuf message (type envoy.config.bootstrap.v3.Bootstrap reason INVALID_ARGUMENT:(sr_threshold) value: Cannot find field.) has unknown fields

Oh amazing! Thanks so much for your help!
Lol, I would never have resolved that. I was looking at the proto for v3.RuntimePercent for the format.
Do you want me to submit a doc PR fixing the example for this sr_threshold and max_rejection_probability. With those changes the config works just fine.

Yes please!

repo: envoyproxy/envoy


text:
WASM Plugin on_log method not called with Matching API

Title: WASM Plugin on_log method not called with Matching API
Description:
The scenario is having two filters in the same filter chain for a http listener.

The first filter rejects the request and a response is returned by it.
If the second filter is an ExtensionWithMatcher with an ExecuteFilterAction delegating to a WASM filter, and the WASM filter is implementing the on_log method, the method is not invoked. As opposed to having the same scenario but without the ExtensionWithMatcher, then the on_log method is correctly invoked.

Repro steps:

Apply the attached configuration
curl -vvv http://localhost:10000/api/get
Expected a log entry containing wasm log examples.http_filter examples.http_filter vm.examples.http_filter: on_log, but it is not shown.

Config:
https://github.com/balbifm/envoy-config/blob/main/envoy.yaml

CC @mpwarres @snowp

authors: balbifm kyessenov


text:
Delta ECDS holds envoy from being ready

If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via emailing
envoy-security@googlegroups.com where the issue will be triaged appropriately.
Title: One line description
When initializing the envoy, I have some configs along  with the delta ecds config:
 istioctl pc ecds httpbin-65975d4c6f-lrzzw -ojson
{
    "ecdsFilters":  [
        {
            "versionInfo":  "2023-10-12T07:00:28Z/4",
            "ecdsFilter":  {
                "@type":  "type.googleapis.com/envoy.config.core.v3.TypedExtensionConfig",
                "name":  "default.hello",
                "typedConfig":  {
                    "@type":  "type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm",
                    "config":  {
                        "name":  "default.hello",
                        "rootId":  "add_header",
                        "vmConfig":  {
                            "runtime":  "envoy.wasm.runtime.v8",
                            "code":  {
                                "local":  {
                                    "filename":  "/var/lib/istio/data/62824cbf8366e3098287bfabcae120ad0b2d828d0a7b4727291c1f0273982a4a/925429df5ad979b3e8a3742d7d6e4a5d3ceaeacdda4465c57dc42849f3594bd5.wasm"
                                }
                            }
                        },
                        "configuration":  {}
                    }
                }
            },
            "lastUpdated":  "2023-10-12T07:00:33.860Z"
        }
    ]
}

the envoy is always in the initializing state without being ready.
Also to note: some of the config in my initial ecds config is missing.
Description:

What issue is being seen? Describe what should be happening instead of
the bug, for example: Envoy should not crash, the expected value isn't
returned, etc.

Envoy should not crash, should be in the ready state with the correct ecds config.
Repro steps:

Include sample requests, environment, etc. All data and inputs
required to reproduce the bug.

I'm using Istio to configure envoy, basically the steps are to have all the config with delta ecds, and when all the configs are sent to envoy, the envoy is always in the initializing state without being ready.

Note: The Envoy_collect tool
gathers a tarball with debug logs, config and the following admin
endpoints: /stats, /clusters and /server_info. Please note if there are
privacy concerns, sanitize the data prior to sharing the tarball/pasting.

Admin and Stats Output:

Include the admin output for the following endpoints: /stats,
/clusters, /routes, /server_info. For more information, refer to the
admin endpoint documentation.

Note: If there are privacy concerns, sanitize the data prior to
sharing.

Config:

Include the config used to configure Envoy.

Other configs are shown in the config dump I provided, and the correct ecds configis :
 istioctl pc ecds httpbin-65975d4c6f-lrzzw -ojson
{
    "ecdsFilters":  [
        {
            "versionInfo":  "2023-10-12T07:00:28Z/4",
            "ecdsFilter":  {
                "@type":  "type.googleapis.com/envoy.config.core.v3.TypedExtensionConfig",
                "name":  "default.hello",
                "typedConfig":  {
                    "@type":  "type.googleapis.com/envoy.extensions.filters.http.wasm.v3.Wasm",
                    "config":  {
                        "name":  "default.hello",
                        "rootId":  "add_header",
                        "vmConfig":  {
                            "runtime":  "envoy.wasm.runtime.v8",
                            "code":  {
                                "local":  {
                                    "filename":  "/var/lib/istio/data/62824cbf8366e3098287bfabcae120ad0b2d828d0a7b4727291c1f0273982a4a/925429df5ad979b3e8a3742d7d6e4a5d3ceaeacdda4465c57dc42849f3594bd5.wasm"
                                }
                            }
                        },
                        "configuration":  {}
                    }
                }
            },
            "lastUpdated":  "2023-10-12T07:00:33.860Z"
        }
    ]
}

The actual ecds config has some fields missing:
{
   "@type": "type.googleapis.com/envoy.admin.v3.EcdsConfigDump",
   "ecds_filters": [
    {
     "ecds_filter": {
      "@type": "type.googleapis.com/envoy.config.core.v3.TypedExtensionConfig",
      "name": "bookinfo.hello"
     },
     "last_updated": "2023-10-13T08:47:48.066Z"
    }
   ]
  },

The init config is:
{
"unready_targets_dumps": [
{
"name": "init manager Listener-local-init-manager 89c6faa8-a2f1-448a-afba-72988d536429 2200412303323231031"
},
{
"name": "init manager Listener-local-init-manager 6d3fca7c-d1dc-47fe-801a-0188e8c7fd79 9872086206848846795"
},
{
"name": "init manager Listener-local-init-manager connect_terminate 13400082664458833867"
},
{
"name": "init manager Listener-local-init-manager main_internal 13582092048675651674",
"target_names": [
"shared target FilterConfigSubscription init bookinfo.hello"
]
},
{
"name": "init manager Listener-local-init-manager connect_originate 10550062674463787435"
}
]
}

configdump.json
Logs:

Include the access logs and the Envoy logs.

wp.log

Note: If there are privacy con
cerns, sanitize the data prior to
sharing.

Call Stack:

If the Envoy binary is crashing, a call stack is required.
Please refer to the Bazel Stack trace documentation.

cc @adisuissa @htuch

Thanks for filing this bug. Some clarifying questions:

Is it correct to assume that this doesn't happen if the same filter-config is statically defined?
Is it possible to test this with State-of-the-World? - FWIW, State-of-the-world and delta shouldn't be an issue in this case, but I just want to cover all the use-cases.

@adisuissa Sorry for the late reply.

Is it correct to assume that this doesn't happen if the same filter-config is statically defined?

This is correct.

Is it possible to test this with State-of-the-World? - FWIW, State-of-the-world and delta shouldn't be an issue in this case, but I just want to cover all the use-cases.

I think State-of-the-World works in this case. Completely removing delta makes envoy work as expected. The situation I observed is as follows: if we have envoy ready and later push with a delta ECDS, envoy works fine. However, if envoy is in an initializing state and we push a delta ECDS, the error I mentioned occurs. If it doesn't make sense, I can provide more test results/details.

This might be a bug in delta client for ECDS if I recall. It only handles a single add/remove I think. Do you have trace/debug logs from Envoy to see if ECDS is rejected for some reason?

I've attached the trace log.
wptrace.txt
BTW from the init config dump it shows:
{
"unready_targets_dumps": [
...
{
"name": "init manager Listener-local-init-manager main_internal 9736802669137004450",
"target_names": [
"shared target FilterConfigSubscription init bookinfo.hello"
]
}
]
}

Not sure if it's related.

@kyessenov I've tested again, and it affects both istio sidecar and waypoint when delta xDS is enabled. If using delta xDS without ECDS, everything works smoothly. However, if sending a delta ECDS config along with other delta configs before envoy is ready, envoy will never reach a ready state, and if sending a delta ECDS config after envoy is ready, envoy only contains the name, without the vm_config:
{
"@type": "type.googleapis.com/envoy.admin.v3.EcdsConfigDump",
"ecds_filters": [
{
"ecds_filter": {
"@type": "type.googleapis.com/envoy.config.core.v3.TypedExtensionConfig",
"name": "default.hello"
},
"last_updated": "2023-11-10T03:26:48.882Z"
}
]
},

it's a config still not wroking as expected.
BTW stow doesn't have this issue, and everything works good.

@hanxiaop is this still an issue

@hanxiaop is this still an issue

@howardjohn Will try tomorrow to see what is happening.

authors: adisuissa alyssawilk hanxiaop howardjohn kyessenov


text:
API Key auth

Title: API Key auth
Description:
An HTTP filter to support API Key auth.  The API key authentication filter can be used to authorize HTTP requests using the provided API key in the request. API keys are a simple and widely used method in web services to ensure that only authorized applications and users can interact with the API. It would be beneficial if Envoy could support this feature.
An API key is a token that a client provides when making API calls. The key can be sent in the query string:
GET /something?api_key=abcdef12345

or as a request header:
GET /something HTTP/1.1
X-API-Key: abcdef12345

or as a cookie:
GET /something HTTP/1.1
Cookie: X-API-KEY=abcdef12345

[optional Relevant Links:]
https://swagger.io/docs/specification/authentication/api-keys/
https://github.com/envoyproxy/gateway/issues/2630

What exactly do you want this filter to do?

s a token that a client provides when making API calls. The key can be sent in the query string:

Hi @mattklein123 Thanks for looking into this issue and sorry for my late response.
The API key authentication filter can be used to authorize HTTP requests using the provided API key in the request. API keys are a simple and widely used method in web services to ensure that only authorized applications and users can interact with the API. It would be beneficial if Envoy could support this feature.

Hi 👋
I'm coming from https://github.com/envoyproxy/gateway/issues/2630, interested in realizing it.
Actually I'm researching other competing gateways, and actually Key auth functionality is one of the gaps that some other implementations implement, while the envoy doesn't. So, I believe it's worthy enough.
I can take an implementer part, would any maintainer be willing to help in reviewing etc to promote it?

It is very pity that we don’t have reliable and out-of-box way to use api keys in envoy proxy.

although API Key Auth is not the most secure or the most performant way to do authn & authz, its still used in existing brownfield environments and also as an additional auth mechanism like the one outlined here, so having support for it would unblock migration to envoy proxy.
Here are the requirements that necessitates a new filter instead of reusing an existing one like the RBAC filter

Ability to read the API key from a header, cookie, or query param
Provide a list/map or allowed API Keys similar to what BasicAuth has
Provide a way to forward the Client id linked to the the API key similar to what Basic Auth has

Agree, that it is essential functionality.

I agree this is essential functionality. I can help with the review if someone want to contribute.

Thanks @wbpcode! I'll ping you when I create the PR.

/assign

authors: arkodg gecube mattklein123 sanposhiho wbpcode zhaohuabing


text:
tls: update BoringSSL to 597b8103 (4183).

Re-land #12815.
Signed-off-by: Piotr Sikora piotrsikora@google.com

Hmm, this broke (again --  #12815) some of our end to end tests. Trying to see if I can get a repro or more info.

On the bright side, there aren't that many changes:
https://github.com/google/boringssl/compare/a0899df79b3a63e606448c72d63a090d86bdb75b...597b810379e126ae05d32c1d94b1a9464385acd0
So I can try a bisect.

Hmm, this broke (again -- #12815 broke as well) some of our end to end tests. Trying to see if I can get a repro or more info.

Did you pick up https://github.com/envoyproxy/envoy/pull/12842? Perhaps you're also using invalid certificates in your tests?

Hmm, this broke (again -- #12815 broke as well) some of our end to end tests. Trying to see if I can get a repro or more info.

Did you pick up #12842? Perhaps you're also using invalid certificates in your tests?

We did pick that up. Yeah, we are suspecting invalid certs too. Let me check.

@PiotrSikora yes -- we had an invalid cert as well. Our issue was triggered by:
https://github.com/google/boringssl/commit/dd86e75b24dcfd47d4ee6b3e4cdce907389335b2
We were using a v1 cert with extensions for our tests. Thanks for the pointer!


text:
http: alpn upstream

Allows configuring both HTTP/1 and HTTP/2 options for a cluster, which triggers TLS alpn negotiation.
Risk Level: Medium (a bunch of little refactors)
Testing: integration tests.  NEEDS UNIT TESTS
Docs Changes: n.a
Release Notes: inline
Fixes #3431

Unit tests are expected to fail - there's some mock clean up around timers and connection.connected() to do, but it's in pretty good shape stability-wise (beyond the new integration test, I've run the full http2_upstream_integration_test and http_integration_test with alpn forced true and they pass)
I wanted to get include-API thumbs up before I spent too much time reordering mocks and writing the new nuit tests.

Whoops, meant to cc @mattklein123 and @snowp last week.  Still got 1 of 2, not bad :-P

Ok, I'll go beat the config loading into shape, and see how much of the config the deprecated CI gets, then ping for another pass.  So waiting w.r.t Matt, but I would appreciate Snow's toughts w.r.t. alpn decoration.  I'm not sure of the motivation for explicitly configured transport ALPN vs cluster failover ALPN so I'm not sure how to address Matt's question there.

CI likely going to fail on this push, but I want to give you a feel for what it's going to look like as I continue cleaning deprecated config failures.

this PR is now up over 100 files with all the docs and configs changes.  Worth splitting out an API-only PR which deprecates the old and adds the new (sans ALPN) then the ALPN PR, or are you Ok with the megadiff?
know offhand where in docs we should doc up the new options other than API stuff?
just want to note we can't migrate from the current "ALPN always includes HTTP/1 and HTTP/1" to "ALPN can selectively include HTTP/1 or HTTP/2, so if we want folks to be able to choose h2/h1 only, we should go with the expected_alpn string.

yeah, on further inspection I thnk I've got to split out config - this is simply too unwieldy.

FWIW I have the transport socket requirements as well as all the prefetch plumbing sorted out for this PR, so just waiting on https://github.com/envoyproxy/envoy/pull/14079 so I can clean up the diffs.

+1 on being futureproof, but my point is I think any shared happy eyeballs extension would go either directly in cluster config, or both TcpProtocolOptions and HttpProtocolOptions.
Basically I think auto ipv4/ipv6 is orthogonal from auto http1/http2/http3 so should not go into the AutoHttpConfig

would go either directly in cluster config, or both TcpProtocolOptions and HttpProtocolOptions.

Yes we are in agreement. My only comment is I think in general we want more things to go in typed_extension_config vs. the raw cluster config so we don't wind up in the same situation you just unwound, but I agree we can cross that bridge later.

Basically I think auto ipv4/ipv6 is orthogonal from auto http1/http2/http3 so should not go into the AutoHttpConfig

Yes agreed I think we are OK.

new conflicts are just two build file additions and two include additions. Will push another update but it should have no impact on tests.

PTAL?