Newbie issue

Sorry to bother you.  But given this is well packaged, I wonder whether there could be

a readme detail
how to import it (use quicklisp or ...)
a sample asm
a sample shell script to run the whole package on the asm and how to use it.

Thanks.

Test so far can generate some nes and move to fceux/wine64 ... still not sure what I am doing as no simple step-by-step, guess that is not the purpose of this hack ...
; not for m1 so far !!!!
; or at least very complicated as quicklisp does not have spec for M1/M2
; hence no sdl2; not sure why I add these into how-to-run this system though
; (ql:quickload "sdl2")
; (ql:quickload "sdl2/examples")
; (sdl2-examples:basic-test); this work under Intel Mac
; let us start without sdl2
; see https://ahefner.livejournal.com/20528.html
; and github to load the files under asm6502 (lisp)
; then load it
; rlwrap sbcl --load "kwc-to-r
; temp solution to load the asd as defined
(push 'default-pathname-defaults asdf:central-registry)
(asdf:load-system :asm6502)
; see https://lispcookbook.github.io/cl-cookbook/systems.html
; how you have the asm6502 system (but not nes though)
; (nes:setup-and-emulate "")
() ; you can do nothing but what you can do
(in-package :asm6502)
; when have issue as the package defined does not have exit/quit
; try to go back to cu or
;  (sb-ext:exit)
(defpackage :nes-test-1
(:use :common-lisp :asm6502 :6502 :6502-modes ;
:asm6502-nes
:asm6502-utility))
(in-package :nes-test-1)
(in-package :asm6502)
#|
(write-ines
"/tmp/nes-test-1.nes"
())
(write-ines
"nes-test-1.nes"
(let ((context (make-instance 'basic-context :address #x8000))
(color (zp 0)))
;; Program Entry Point
(set-label 'entry-point)
(sei)                                ; Disable interrupts
(cld)
(ldx (imm #xFF))                     ; Init stack pointer
(txs)
(lda (imm 3))
;(sta color)
(lda (imm #x00))
;(sta color)
; color whatever you do or not do always return #<ZP {70078CDAC3}>
;#|
;; Configure PPU
(lda (imm #b10000000))               ; Enable VBlank NMI
(sta (mem +ppu-cr1+))
(lda (imm #b00000000))               ; Display off
(sta (mem +ppu-cr2+))
(jmp (mem origin))                 ; Spin.
;; VBlank Handler
(set-label 'vblank-handler)
(lda (mem +ppu-status+))             ; Clear NMI, reset high/low state
(lda (imm #x3F))                     ; Program address #x3F00
(sta (mem +vram-addr+))              ; ..write MSB
(lda (imm #x00))
(sta (mem +vram-addr+))              ; ..write LSB
(inc color)                          ; Increment and load color
(lda color)
(lsr)                                ; Shift right two bits, so each
(lsr)                                ; color appears for four frames.
(sta (mem +vram-io+))                ; Write color to palete.
(poke #x3F +vram-addr+)     ; Reset address due to palette latching.
(poke #x00 +vram-addr+)
(rti)
;; IRQ/Break Handler
(set-label 'brk-handler)
(rti)
;; Interrupt Vectors
(advance-to +nmi-vector+)
(dw (label 'vblank-handler)) ;; NMI
(dw (label 'entry-point))    ;; RESET
(dw (label 'brk-handler))    ;; BRK/IRQ
;|#
(link context)
(format t "hello, world asm6250~%")
(format t "~A" color)
; )
)
)
;(exit)
|#
; the generated file can be loaded, well, anywhere even commodore
; and definitely OpenEMU (like supertank and it)
; now try to run
;  rlwrap sbcl --load "kwc
; see https://www.reddit.com/r/Common_Lisp/comments/14it7ag/asdfloadsystem/
; better to use load directory like
;  ~/.config/common-lisp/source-registry.conf.d/
(asdf:load-asd "~/Documents/Github/asm6502/hacks/nes-hacks.asd")
; see https://lispcookbook.github.io/cl-cookbook/systems.html
; how you have the asm6502 system (but not nes though)
; (nes:setup-and-emulate "")
() ; you can do nothing but what you can do
; line 31 = value nil of ; (load "./hacks/music-demo.lisp")
(load "./hacks/nes-test-1.lisp")
; to see doc try
; but actually fuecu2 is better ??? and all goes somewhere on assembler ... nesmaker etc.
(list-all-packages)

I agree, a README and some documentation is something I've considered in
the back of my mind for some time, but also I haven't used asm6502 in
several years. I really never put it in a state where I expected other
people to use it.
I'm not what you're referring to by m1/m2 or why you'd need SDL here.
It seems like you've figured out how to build NES roms.
In practice when I've used this, I've stayed inside emacs rather than
having any kind of outside script to trigger building a rom file. Edit, C-c
C-k my buffer in SLIME (was never working on anything large enough that the
code didn't fit comfortably in one file..), then tab over to a terminal and
open the rom in my emulator of choice. I mostly use one I wrote a long time
ago (in C, not lisp...), and occasionally Nestopia if I need something more
accurate, but anything should work. I was never a big fan of FCEUX but some
versions do have a good debugger...
On Thu, Nov 16, 2023 at 8:28 AM Kowloon walled city (coin) <
@.***> wrote:

Test so far can generate some nes and move to fceux/wine64 ... still not
sure what I am doing as no simple step-by-step, guess that is not the
purpose of this hack ...
; not for m1 so far !!!!
; or at least very complicated as quicklisp does not have spec for M1/M2
; hence no sdl2; not sure why I add these into how-to-run this system
though
; (ql:quickload "sdl2")
; (ql:quickload "sdl2/examples")
; (sdl2-examples:basic-test); this work under Intel Mac
; let us start without sdl2
; see https://ahefner.livejournal.com/20528.html
; and github to load the files under asm6502 (lisp)
; then load it
; rlwrap sbcl --load "kwc-to-r
; temp solution to load the asd as defined
(push 'default-pathname-defaults asdf:central-registry)
(asdf:load-system :asm6502)
; see https://lispcookbook.github.io/cl-cookbook/systems.html
; how you have the asm6502 system (but not nes though)
; (nes:setup-and-emulate "")
() ; you can do nothing but what you can do
(in-package :asm6502)
; when have issue as the package defined does not have exit/quit
; try to go back to cu or
; (sb-ext:exit)
(defpackage :nes-test-1
(:use :common-lisp :asm6502 :6502 :6502-modes ;
:asm6502-nes
:asm6502-utility))
(in-package :nes-test-1)
(in-package :asm6502)
#|
(write-ines
"/tmp/nes-test-1.nes"
())
(write-ines
"nes-test-1.nes"
(let ((context (make-instance 'basic-context :address #x8000))
(color (zp 0)))
;; Program Entry Point
(set-label 'entry-point)
(sei) ; Disable interrupts
(cld)
(ldx (imm #xFF)) ; Init stack pointer
(txs)
(lda (imm 3))
;(sta color)
(lda (imm #x00))
;(sta color)
; color whatever you do or not do always return #<ZP {70078CDAC3}>
;#|
;; Configure PPU
(lda (imm #b10000000)) ; Enable VBlank NMI
(sta (mem +ppu-cr1+))
(lda (imm #b00000000)) ; Display off
(sta (mem +ppu-cr2+))
(jmp (mem origin)) ; Spin.
;; VBlank Handler
(set-label 'vblank-handler)
(lda (mem +ppu-status+)) ; Clear NMI, reset high/low state
(lda (imm #x3F)) ; Program address #x3F00
(sta (mem +vram-addr+)) ; ..write MSB
(lda (imm #x00))
(sta (mem +vram-addr+)) ; ..write LSB
(inc color) ; Increment and load color
(lda color)
(lsr) ; Shift right two bits, so each
(lsr) ; color appears for four frames.
(sta (mem +vram-io+)) ; Write color to palete.
(poke #x3F +vram-addr+) ; Reset address due to palette latching.
(poke #x00 +vram-addr+)
(rti)
;; IRQ/Break Handler
(set-label 'brk-handler)
(rti)
;; Interrupt Vectors
(advance-to +nmi-vector+)
(dw (label 'vblank-handler)) ;; NMI
(dw (label 'entry-point)) ;; RESET
(dw (label 'brk-handler)) ;; BRK/IRQ
;|#
(link context)
(format t "hello, world asm6250~%")
(format t "~A" color)
; )
)
)
;(exit)
|#
; the generated file can be loaded, well, anywhere even commodore
; and definitely OpenEMU (like supertank and it)
; now try to run
; rlwrap sbcl --load "kwc
; see
https://www.reddit.com/r/Common_Lisp/comments/14it7ag/asdfloadsystem/
; better to use load directory like
; ~/.config/common-lisp/source-registry.conf.d/
(asdf:load-asd "~/Documents/Github/asm6502/hacks/nes-hacks.asd")
; see https://lispcookbook.github.io/cl-cookbook/systems.html
; how you have the asm6502 system (but not nes though)
; (nes:setup-and-emulate "")
() ; you can do nothing but what you can do
; line 31 = value nil of ; (load "./hacks/music-demo.lisp")
(load "./hacks/nes-test-1.lisp")
; to see doc try
; but actually fuecu2 is better ??? and all goes somewhere on assembler
... nesmaker etc.
(list-all-packages)
—
Reply to this email directly, view it on GitHub
https://github.com/ahefner/asm6502/issues/2#issuecomment-1814438192, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABLQMNM6Z3Q2ZKEFVFRYE3YEYIITAVCNFSM6AAAAAA7NMRL22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJUGQZTQMJZGI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>


send_command is not a function

I am using metroplex node module that requires a redis connection. When I used ioredis, I got the following error whereas the default Redis client (that comes with metroplex) seems to work fine.
/node-web-projects/test3/node_modules/ioredis/node_modules/bluebird/js/main/async.js:43
        fn = function () { throw arg; };
                                 ^
TypeError: leverage._.client.send_command is not a function

Any ideas what send_command is and why it is not supported?
FYI: I am using iojs

Looks like metroplex is using https://github.com/mranney/node_redis

send_command is a private method in node_redis.

Ok, so you're saying that metroplex is dependent on that particular node module because of the function/method it uses.
Any chance ioredis would implement a function/feature like that?

Well, I checked the documentation of node_redis again and it turns out send_command is a public method since it's documented here. I'm going to implement it in ioredis.
BTW, Where does metroplex use send_command method? I just checked it out and didn't find it.

Looks like metroplex is using a Redis wrapper named leverage (https://www.npmjs.com/package/leverage) around redis client and that wrapper is using send_command.
I used the following command to list all instances where send_command is used in both leverage and redis client.
egrep -ir "send_command"  node_modules/metroplex/

Added in 1.5.10

Thank you.


big error of the ASI mode: single line "var a = b return c" doesn't raise any error

(new here)
I'm using v2.6.3 with rhino, asi=true, and this kind of code doesn't wake jshint up:

function a() {
	var b = 3 return 5
}

in other terms, it looks like every single semicolon warning is being silenced; does jshint treat newlines as if they weren't there at all?
just like the similar fixed (?) bug here, my version doesn't always warn me correctly against this type of thing:

var a = b
[3].foo() ////nothing :(

var c = d
('a'+'b').foo() ////nothing :(

var e = f
+g ////Bad line breaking before '+'. ok

var h = i
-g ////Bad line breaking before '-': ok

var j = k
/qwe/.foo() ////Bad line breaking before '/'.

////yet it goes on ignoring the first / and "throws" an error telling me
////that '.foo' isn't the indentifier it expected;
////it however doesn't have any problem, first '/' excepted, with this type of thing:

var foo = bar
/aze/4

////is it its normal behavior?

anyhow, quite annoying for someone who uses asi like me; quite absurd too that the two first asi exceptions (by far, more common than the three others) don't raise any warning :/
i checked the same stuff without asi=true, it happens that jshint treats the above expressions like any actual interpreter, ie without raising warnings:
var a = b
[3].foo()
////is treated just like:
var a = b[3].foo()

thus: it's truly missing some important thing wrt helping those using the asi syntax not to make those very few mistakes we (and in fact, others that would forget one semicolon at the wrong place) could do.

afterthought, i guess that the warnings for each case where there's "(" or "[" (or the three less probable other cases) would be annoying if one has the habit like i do to write stuff like:

foo.bar
(
    very_very_very_very_long_stuff,
    yet_another_very_very_very_very_long_stuff
)

it remains that missing warnings for fully incorrect missing semicolons inside one single line (eg "var a = b return c"), which are (relatively) present with asi=false (raises a missing semicolon; an error would've been more logical i think) are in my opinion definitely constituting a bug.

nobody for this bug? it's kindof big if jshint doesn't even warn for actual syntax errors.

i'll take a look --- on the upside, it's an early error whenever you try to run this in a js engine, so...

the fact that warnings for absence of semicolons inside one single line (eg "var a = b return c") are not there when asi=true, is in my opinion definitely a bug.

You're using the the option incorrectly. asi is a relaxing option, so by setting it to true, you're relaxing the rules.

i beg you pardon, but the ASI of JS doesn't append any semicolon in the middle of a sentence, this jshint option is utterly absurd, doesn't correspond to anything
there's a difference between becoming more "relaxed" and altogether becoming pointless because not even warning for mere syntax errors that won't even be accepted by the parser.
i think you don't know enough about ASI to say that it's quite normal that the "relaxing" option called "asi" doesn't warn for missed semicolons inside lines: it's got nothing to do with js's ASI, it's just syntax error.

on the upside, it's an early error whenever you try to run this in a js engine, so...
totally agree, but it's nevertheless unsettling, and isn't one of the biggest point of jshint to help bypassing this annoying process of correcting small forgotten syntax mistakes one by one with a tiresome go-and-back game between browser and editor?
i admit this particular example is probably improbable, but i wonder if there wouldn't be others less improbable... overall it's a bit annoying that the asi option be not written in accordance with the rules of ASI of JS (which are quite simple by the way), that it seem that the option was simply to mute every single missing-semicolon warnings, even the ones not connected with ASI... i find it a bit "cheap", and, clearly buggy for the least.


[FZ Editor] Include template name in edit template dialog title + don't resize dialog when typing to long name

Summary of the Pull Request
Co-author: @niels9001
What is this about:

Edit template dialog title

Include template name in Edit template dialog title

When template name is too long, title is being trimmed

Do not resize edit dialog title while typing too long template name

Before

After

What is included in the PR:
How does someone test / validate:
Check the attached gifs for testing
Quality Checklist

[x] Linked issue: #10847
[ ] Communication: I've discussed this with core contributors in the issue.
[ ] Tests: Added/updated and all pass
[ ] Installer: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Docs: Added/ updated
[ ] Binaries: Any new files are added to WXS / YML

[ ] No new binaries
[ ] YML for signing for new binaries
[ ] WXS for installer for new binaries

Contributor License Agreement (CLA)
A CLA must be signed. If not, go over here and sign the CLA.

@niels9001 WDYT about adding tooltip with full title when title is trimmed?

We should add tool tip for shortened template name.

Is this for custom and default templates?

We should add tool tip for shortened template name.

The name is literally there when you press the edit button and it's in the Name field.. so that feels a bit like overkill while it might introduce accesibility quirks.
@stefansjfw Actually, is the Title in sync when editing the name in the TextBox? Doesn't need to be IMO, but just curious :-)

@stefansjfw Actually, is the Title in sync when editing the name in the TextBox? Doesn't need to be IMO, but just curious :-)

No, it's not. I don't see much value there either.

Is this for custom and default templates?

Yes, both.


replace request with HA preferred lib https://docs.aiohttp.org/en/stable/client.html

saw today that HA prefers api calls to use an async library like aiohttp instead of request's sync implementation, I'll reimplement Kia USA

https://developers.home-assistant.io/docs/api_lib_auth ("Home Assistant is written in async, but is able to work with synchronous libraries too. We prefer async libraries")

As a side note, this is a very good architectural change but will not have any impact in performance or usability.

I added this for best practices and because I think I'll enjoy learning a new useful library.  This academically does have performance impact, but I barely care about that edge case. :)

had to revert the shim solution I made using run_coroutine_threadsafe due to deadlock created during interval updating invocations using different threading model then the other update invocations.  Threading seems inconsistent vs
https://developers.home-assistant.io/docs/asyncio_working_with_async


Retry update operation when a conflict happens

Changes
Fixes the following test case error from this run:
 Failure [15.266 seconds]
Integration tests BuildRuns and TaskRuns
/home/runner/work/build/build/test/integration/buildruns_to_taskruns_test.go:26
  when a buildrun is created and the taskrun is cancelled
  /home/runner/work/build/build/test/integration/buildruns_to_taskruns_test.go:312
    should reflect a TaskRunCancelled reason and no completionTime [It]
    /home/runner/work/build/build/test/integration/buildruns_to_taskruns_test.go:319

    Expected
        <*errors.StatusError | 0xc000c7c8c0>: {
            ErrStatus: {
                TypeMeta: {Kind: "", APIVersion: ""},
                ListMeta: {
                    SelfLink: "",
                    ResourceVersion: "",
                    Continue: "",
                    RemainingItemCount: nil,
                },
                Status: "Failure",
                Message: "Operation cannot be fulfilled on taskruns.tekton.dev \"buildrun-test-build-225-xkw6k\": the object has been modified; please apply your changes to the latest version and try again",
                Reason: "Conflict",
                Details: {
                    Name: "buildrun-test-build-225-xkw6k",
                    Group: "tekton.dev",
                    Kind: "taskruns",
                    UID: "",
                    Causes: nil,
                    RetryAfterSeconds: 0,
                },
                Code: 409,
            },
        }
    to be nil

    /home/runner/work/build/build/test/integration/buildruns_to_taskruns_test.go:337

Submitter Checklist

[ ] Includes tests if functionality changed/was added
[ ] Includes docs if changes are user-facing
[x] Set a kind label on this PR
[x] Release notes block has been filled in, or marked NONE

Release Notes
NONE

Change has been included in another PR.


Add Algolia synonyms for searches with no results

According to our internal dashboard called 'Algolia Metrics', we returned no search results for the following terms:

optgen
writetooolderror
material view

This change adds synonyms for each of them to our search config. In particular the 'writetooolderror' is important to address, since it relates to a specific type of transaction retry error:
https://www.cockroachlabs.com/docs/v23.1/transaction-retry-error-reference

Nick Vigilante @.***> writes:

LGTM! Once we merge it, we'll be able to test the index a bit better.

Awesome, thanks!

Not relevant for the scope of this PR, but I hope that one day, we can
get to a point where we have testing indexes that generate alongside
each Netlify build where we can observe how our results rank.

Interesting, I look forward to learning more about this!


This page appears to no longer be accurate

Currently the only way to register an application in the Amazon Developer Console is with Amazon Moments, which doesn't support entering web Allowed JavaScript origins or Allowed Return URLs

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

ID: 15e8f05f-7ae6-d266-bb6f-5adf0fe4f585
Version Independent ID: faa8058e-7bea-900b-3067-716bdb028bd2
Content: Set up sign-up and sign-in with an Amazon account - Azure Active Directory B2C
Content Source: articles/active-directory-b2c/active-directory-b2c-setup-amzn-app.md
Service: active-directory
Sub-service: b2c
GitHub Login: @mmacy
Microsoft Alias: marsma

@alexmarshall132 Hope you have self resolved and thus closed the issue. Thanks for the update.


[MNT] Adds an Issue/PR Assigning Bot

As per the discussion with @MatthewMiddlehurst,
What does this implement/fix? Explain your changes.
It implements an Issue/PR assigning bot to eliminate the chances of people working on the same Issue.

Any other comments?
This would look something like :

@chrisholder, do you think we could add more interactivity to this?

Could you run through the code and what each bit is doing? Not very reader friendly currently for anyone who may not know much about bash 🙂.

@MatthewMiddlehurst, added the comments to make it more readable!

Three issues I have with this really at the moment.

It is rather rigid, requiring a specific phrase and formatting
The code does not really match the style of other actions, it would be better as a bash script (or preferably a python file using pygithub).
There is nothing to indicate that this is available, I don't expect new users (who are most likely to not have write access) to know this is available. Probably best place is the contributor guide.

Hi @MatthewMiddlehurst !, so answer your questions:

It is rather rigid, requiring a specific phrase and formatting

We can make it more generic to include flexibility in the phrases.
by making it accept phrases like :
"Aeon-Assign bot", "assign this to", "please assign"

The code does not really match the style of other actions, it would be better as a bash script (or preferably a python file using pygithub).

I'll opt for using PyGithub

There is nothing to indicate that this is available, I don't expect new users (who are most likely to not have write access) to know this is available. Probably best place is the contributor guide.

We can add it to the contributor's guide or describe a simple bot, that would comment on the Issues/PRs stating how we can trigger this bot.
Do you think this approach is fine?

@MatthewMiddlehurst please review.

We are mostly volunteers and there is a lot of other work we do, so try to be a bit patient and we will get around to it 🙂

I understand, I apologize if it felt rushed, I just meant it is up for review at your convenience.

Would it be possible to only run this if the message starts with @aeon-actions-bot? If so the comment text only needs to contain "assign" for it to run, probably.

Even now, if the text only contains " assign " it would still Assign the PR, I just added the other phrases as contingencies to keep the bot flexible.

I would look at the other workflows i.e. the PR comment one to see the token generator. That will allow the bot to assign.

@MatthewMiddlehurst,
I think when the task is as trivial as just assigning the PR, we can directly use the personal access token (PAT) stored in the repository, and we would not need the app token(did you mean this?)

Using the app token will make the bot assign rather than github actions. Its cosmetic I guess.
I mean since you are explicitly asking the bot, you can just remove the list and run it on any string which contains "assign" (which would cover "assigning", "assign this to", etc). You could avoid parsing users (any word starting with @) as well, but probably not required.


feat(gi): added Empty, Single, Repeat, Enumerate, FilterMap and more

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

Project coverage is 100.00%. Comparing base (7a4d8b9) to head (4eb6f77).

Additional details and impacted files
@@            Coverage Diff             @@
##              main       #39    +/-   ##
==========================================
  Coverage   100.00%   100.00%
==========================================
  Files           46        55     +9
  Lines          872       736   -136
==========================================
- Hits           872       736   -136

Flag
Coverage Δ

gi
100.00% <100.00%> (ø)

optional
?

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

coverage: 100.0%. remained the same
when pulling 4eb6f7725fefa674d38f734e43f063670f360fe9 on feature/gi-2
into 7a4d8b9f440f3adc6f19ae16a1913081749aee5c on main.


Could not replicate results obtained with OpenNMT-py

Hi all,
I've run a training on a private small dataset (~200K parallel sentences) trying to use the same hyperparameters for both OpenNMT-py and Sockeye, as far as it was possible.
After 50 epochs I stopped the training with OpenNMT-py, which had a validation perplexity of 3.03, while after 50 epochs the validation perplexity was more than 400 with Sockeye. The training continued until epoch 137, where the validation perplexity was still more than 200.
The followings are the training commands:
OpenNMT-py
python $OpenNMTpy/train.py -data data/train.pt -save_model models/output -brnn -batch_size 120 -epochs 50 -start_epoch=1 -optim sgd -learning_rate 1 -learning_rate_decay 0.9 -start_decay_at 9 -gpus 0 -dropout 0.3 -brnn_merge sum

Sockeye
python -m sockeye.train --source data/train.en --target data/train.it --validation-source data/dev.en --validation-target data/dev.it --output models --device-ids 1 --rnn-num-layers 2 --rnn-num-hidden 500 --num-embed 500 --max-seq-len 50 --batch-size 120 --dropout 0.3 --optimizer sgd --initial-learning-rate 1.0 --learning-rate-reduce-factor 0.9 --clip-gradient 5 --attention-type 'dot' --use-fused-rnn --normalize-loss

Something to point out:

500 is the default value in OpenNMT-py for both rnn-units and word embedding size.
From what I've understood, the attention implemented there is equivalent to the dot attention.
Without --normalize-loss the model diverges immediately, producing really high perplexity.

I'll try with a publicly available dataset to provide you with more information.
UPDATE: I'm trying with IWSLT2016 En-Fr and the same training commands, but the situation is exactly the same.

Hi!
generally a learning rate of 1.0 is incredibly high and I'm not surprised that the model diverges. I'm not exactly sure how OpenNMT-py normalizes the loss, which is very important to know when trying to compare the two setups. By default Sockeye does not normalize the loss. This means that the magnitude of the loss scales with the number of target words in a batch. For this reason generally we would choose a much smaller learning rate (see the default value of 0.0003). Now when --normalize-loss is turned on, the loss becomes independent of the batch size and one can use a larger learning rate. Effectively a normalized loss with a learning rate multiplied by the number of words in a batch should be equivalent to not normalizing the loss. Note also that from what I know MXNet clips gradients based on the absolute value rather then based on the norm. The norm clipping in PyTorch on the other hand rescales the gradient to make sure the norm is bounded, which in turn could also allow for higher learning rates.
So long story short because of these implementation details you might need different hyperparameters for the two systems. Specifically a lower learning rate would probably make sense.

Ok, once I realized I could not replicate the same settings, I've started a training with adam and initial learning rate 0.003.
Now the perplexity is going down still slower than the other case, but at least it seems reasonable.
I'll update this thread at the end of the training.
Thanks.

The training with these parameters is finished, but the output of Sockeye is 2 bleu scores under OpenNMT-py (35.73 vs 37.84).
For completeness, this is the script I've run:
python -m sockeye.train --source $data/train.$src --target $data/train.$tgt --validation-source $data/dev.$src --validation-target $data/dev.$tgt --output $output_dir --device-ids 1 --rnn-num-layers 2 --rnn-num-hidden 500 --num-embed 500 --max-seq-len 50 --batch-size 120 --dropout 0.3 --optimizer adam --initial-learning-rate 0.0003 --learning-rate-reduce-factor 0.9 --clip-gradient 5 --attention-type 'dot' --use-fused-rnn

I should have dropped "--learning-rate-reduce-factor 0.9" but it should not affect, I hope.

Does OpenNMT also use two layers by default? With such a small dataset like IWSLT it might be easier to converge with a smaller network.
From what I can tell from the OpenNMT-py code the attention mechanism is what is called 'mlp' in Sockeye. While 'dot' is usually faster you also normally loose a bit in terms of BLEU.

Ok, then I'll try with mlp attention.
The number of layers is two in both cases.

@tdomhan I've tried with mlp attention but it is still 2 bleu score under OpenNMT-py.
Have you compared the performance on bigger datasets?

It's hard to figure out why that is, as there are probably some other subtle differences in how the models are implemented. I'll close this issue for now.


Wrong over push temp when using F as temp

Hello.
I just installed GravityMon and it seems to be working well but I noticed the temperature recorded in Fermentrack is 30 degrees F or more higher than what the GravityMon web server page shows. Is this a push configuration error?
Thanks for any advice or information.
EDIT:
Okay I just figured out that GravityMon is detecting the temperature as 68F but it's sending it to Fermentrack as 68C.
Any idea how I can correct this?

It looks like that the ispindle format always should be in Celsius. So this is a bug. If you change the format template to the following it should work:
{"name" : "${mdns}", "ID": "${id}", "token" : "${token}", "interval": ${sleep-interval}, "temperature": ${temp-c}, "temp-units": "${temp-unit}", "gravity": ${gravity}, "angle": ${angle}, "battery": ${battery}, "rssi": ${rssi}, "corr-gravity": ${corr-gravity}, "gravity-unit": "${gravity-unit}", "run-time": ${run-time} }

As a work around I entered in Format Editor:
"temperature": ${temp-c},

Looks like I had a spelling error in the format defintion. The temp format should be "temp_units" and not "temp-units"... If you change the format to this it should work. Since fermentrack could not find the format type it defaults to celsius
{"name" : "${mdns}", "ID": "${id}", "token" : "${token}", "interval": ${sleep-interval}, "temperature": ${temp}, "temp_units": "${temp-unit}", "gravity": ${gravity}, "angle": ${angle}, "battery": ${battery}, "rssi": ${rssi}, "corr-gravity": ${corr-gravity}, "gravity-unit": "${gravity-unit}", "run-time": ${run-time} }

Fixed in dev


[WIP] Python 3 Support

Python 3! :+1:

Before this goes in, we're going to need a lot of testing.  Tbh, py3 support wasn't planned to be a priority until the next release.

Relates to issue #120.

Oh yeah, I was just looking for something to pick off this morning. I don't expect to put this in the coming release, but hopefully the following one.

Absolutely the following one, probably with lots of input from @dan-blanchard too. :)

Is there any sense of the ETA on a release with Python 3 support? I'm building a project right now that I'd love to use pykafka for, but I might have to revert to kafka-python if compatibility just isn't in the cards.

Python 3 compatibility is slated for the next pykafka release, which we hope to have ready in the next few months. The main concerns for that release are the asynchronous producer implementation and python 3 support. You can track the progress of this release here.

Thanks for the update, @emmett9001.

This looks like it doesn't merge anymore.  This seems more up to date than #106 but we should probably merge branches together so people like me who want python3 support can help contribute :)


SNS to notify when scheduler takes any action

Hopefully I am not over stepping by using the issues section to make a suggestion.
The scheduler works great for us. However, there are many actions we have to take once the scheduler takes effect for our IaaS services.
Currently we are building outwatch rules, then within our lambdas, checking to see if the scheduler started/stopped the instance before taking action.
It would be awesome to be able to subscribe our lambdas to a topic to trigger these post-scheduled start/stop actions.

Yes... Sorta.
For our use case, we are very IaaS driven. When the scheduler starts/stops we need to do things to notify other systems that stuff is happening to each EC2 Instance. Currently we are wrapping the AWS Scheduler with our own custom lambdas. We are triggering our own lambda on EC2 Start/Stop cloudtrail events that are coming from the Scheduler Role. I just thought it would be nice to us an SNS topic that our response lambdas can subscribe to instead of the hackey solution we have now.
Thanks for your response!
Hope that makes sense! Thanks for your response!

Hi guys.. any updates or  plans to implement this feature?

Hi @Rayv1 , our next release is focused on developing a CDK (eta Q3-20). This feature request is in our backlog.

Hi @Rayv1. We will not implement this feature after further review and discussion. The concern is this feature will generate too many emails/notifications, which makes for a bad customer experience. Instead, we recommend you write a filter for CloudWatch logs so you can select the notifications you want to receive.


Fix debug log level always set to debug

This regression has been introduced during the upgrade to Spring Boot 2.4.0-M4.

The cause is https://github.com/spring-projects/spring-boot/issues/23985, for now I will fix it via an artificial reflection config.


Crashes OBS Everytime

Crash and Log files attached.
Crash 2021-10-07 09-45-33.txt
2021-10-07 09-44-24.txt

crashed as soon as I add audio/video filter.

Hi, i have the same problem all the time i add "Visual Backgroud detector" OBS crash, this is the LOG :
Crash 2022-01-20 20-28-56.txt.

@P-Gaz Please add obs log, not only crash log.

having a crash as well when I add the detector.
Crash 2022-07-25 09-46-27.txt
2022-07-25 09-46-11.txt


Do not redirect to list view after saving form

@goliney could you check this ?

Sure. But can it wait? I don't know exactly when I'll be able to

Sorry, no rush at all. Created issue in order not to forget.
On Sat, Nov 12, 2016, 00:51 Sergey Goliney<EMAIL_ADDRESS>wrote:

Sure. But can it wait? I don't know exactly when I'll be able to
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/aio-libs/aiohttp_admin/issues/101#issuecomment-260074060,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AANoZ5vzlc6mHso9UQmkqrjTotolhKC3ks5q9PFzgaJpZM4KwMY0
.


Tag 0.1

Please create new tag.
"minimum-stability": "stable",

  Problem 1
    - The requested package odeception/assert-throws could not be found in any version, there may be a typo in the package name.

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <https://getcomposer.org/doc/04-schema.md#minimum-stability> for more details.
 - It's a private package and you forgot to add a custom repository to find it

Read <https://getcomposer.org/doc/articles/troubleshooting.md> for further common problems.

odeception/assert-throws
???

Done!


Proxy

Examine, if and how Javascript-Proxy-Objects may help optimize

They are far too slow! Tested multiple times for different purposes...


[Impeller] Image/Color filters should return an Entity and not a Snapshot if opacity doesn't need to be absorbed

More general case of https://github.com/flutter/flutter/issues/124025
Currently all of our image and color filters render to a subpass, and then composite that subpass into the parent via Entity::FromSnapshot. These should be re-written to return an entity directly and elide the subpass if opacity doesn't need to be absorbed.
As a consequence all of our image/color filters are using 2x the texture the operations that would otherwise be needed.
The caveat is that my PR to do this for advanced blends hit an issue with surprising behavior of the snapshot transform which is different depending on whether the filter is applied to a subpass or to a contents directly:  https://github.com/flutter/engine/pull/40927

For example, this is the color matrix filter:

First we render to subpass and return a snapshot, then that snapshot gets pushed through the color matrix filter into another subpass, and then that subpass gets composited into the parent pass. We can elimate that second pass


[middelware-autoset] An ability to setup Rails middleware usage  manually

Added:

An ability to setup Lamian::Middleware manually

coverage: 100.0%. remained the same
when pulling 2a66ce984b1d9bc1982de433677d43906b3a2976 on middleware-autoset
into 1a412a3d1ae84b600e90d77976c6b3b5b164a8c9 on master.


[WIP] Implement search monitors tool

Description
Adds a search monitors tool. Utilizes the added getMonitor() & searchMonitors()  fns exposed by the alerting interface in common utils. These were refactored from the alerting plugin -> common utils plugin. See related PRs for details:
https://github.com/opensearch-project/common-utils/pull/566
https://github.com/opensearch-project/alerting/pull/1305
Based on the passed parameters, the tool will execute either the get monitor transport action, or search monitors transport action. The get monitor action is straightforward, and just takes in a monitor ID. The search monitors action takes in DSL to query the system index containing the monitor info. The tool handles the query generation logic to prevent the agent from generating it, which would likely be error prone and need advanced prompt engineering. Various params (all optional) are available to pass to the tool's run() function to generate a query (see here for an example generated query).
The amount of parameters and/or the default values may be changed later on depending on agent performance and accuracy. For example, too much parameter tuning may lead to messy or invalid results.
Additionally, further integration testing will need to be done to validate different alerting-related questions input to the agent that will have this tool associated to it.
Issues Resolved
#1545
Check List

[x] New functionality includes testing.

[x] All tests pass

[x] New functionality has been documented.

[x] New functionality has javadoc added

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Leaving as draft until the following is complete:

[ ] Common utils refactor change is exposed in the feature/agent_framework_dev branch. May need to create a dev branch and update the gradle dependency to consume
[ ] Alerting refactor change is exposed in common utils and this feature/agent_framework_dev branch (only needed for e2e testing)
[ ] Sufficient unit tests added to test run()

Closing in favor of direct merge to main - #1749


fix current date and add specific set date

fixed the bug: after selecting a specific date, when changing months, the selected date remained 'checked'
added possibility to create calendar with specific date different than today

hey @luciluci somehow I wasn't notified about the pull request! Sorry about that.
I'll give this a review in the next couple of days, I'm really sorry.
Also, thank you so much for submitting a pull request 😃


Support compiling project with Swift 5.5

Background
When using SwiftSyntax and linking to a specific version of lib_internalSwiftSyntaxParser, it does not matter which toolchain you use to compile the project.
In #1037, we just updated Package.swift to require Swift 5.6 or later (Xcode 13.3+), enforced by setting swift-tools-version to 5.6 - Doing this then caused SPM to update the Package.resolved format to v2 and also required some syntax changes in Package.swift, but that's about it since using SwiftSyntax 0.50600.1 and linking to the right version of lib_internalSwiftSyntaxParser is something separate.
The downside locking into Swift 5.6+ is that you can no longer build the project using anything older than Xcode 13.3. While this is not common, since most users of Sorcery use the precompiled binary, there are still some users who want to be able to use tools such as Mint to compile from source but find themselves unable to (i.e if they user GitHub Actions, which don't currently support Xcode 13.3/macOS 12) - #1045
Initially I thought that if we wanted to support Xcode 13, 13.1 or 13.2 then we had to use SwiftSyntax 0.50500.0, and thus have essentially two different versions of Sourcery to test/maintain, I thought that this wouldn't be worth doing. But after testing, it seems like its simpler than that.
Changes
In this change, I update Package.swift to set swift-tools-version back to 5.5, revert some syntax changes and revert Package.resolved back to the v1 format (being careful to preserve the pins from before). This allows the following:
➜  Sourcery git:(ln/xcode-13) swift --version
swift-driver version: 1.26.21 Apple Swift version 5.5.2 (swiftlang-13<IP_ADDRESS> clang-13<IP_ADDRESS>)
Target: arm64-apple-macosx12.0
➜  Sourcery git:(ln/xcode-13) swift build
...
➜  Sourcery git:(ln/xcode-13) swift run sourcery --version
[0/0] Build complete!
1.8.0

We could continue to support Swift 5.5 like this until a point where we might want to use Swift 5.6 language specific features in the codebase.
I guess the one big thing to note here, since it is a bit meta and confusing, while you can compile the sourcery codebase with Swift 5.5, we still use SwiftSyntax 5.6 and therefore remain able to parse the AST of both Swift 5.5 and 5.6 source code.
Note: Since we downgrade swift tools here, this might need you to clear out .swiftpm or .build directories on local machines. I don't anticipate that to be much of a problem though.

Looks fine for me and works perfect. Thanks @liamnichols

WDYT @krzysztofzablocki?
Looking back at this, we can think a little differently about this since lib_internalSwiftSyntaxParser is statically linked so as long as we don't want to leverage any Swift 5.6 language features in the codebase at this moment, it shouldn't be an issue.

it looks ok to me


fix type error in manifest asset bundle

Description
Fixes https://github.com/flutter/flutter/issues/42723
Adds regression test.

Hi guys, I'm getting the same error. Is there any workaround?

@natanloterio what version of flutter are you on? unfortunately we haven't been able to do a dev release in a while but if you're on master an update will work.

@jonahwilliams , I figured out that the problem was with the Master Channel's version. When I switched back to the Stable Channel, the hot-load started to work back again.
Sorry, it was my fault.
Thank you!


Is there a plan to add pop3 wrapper to this project ?

As an smtp wrapper, this util is amazing.
It will be great if  wrapper for pop3 be added too....

I agree with you! This feature would be great!

Haha, I would love it, but POP3 is an entirely different beast from SMTP. I'm not even sure what problem a potential Simple Java Pop3Mail project would solve.
With SMTP it is very clear: there are so many specs for defining an email and so many clients that needs to understand your email, that Simple Java Mail simplifies the process of creating a fool-proof email. What problem does POP3 have?

To be honest, refering to the javamail api by Oracle, I can now sync the whole mails from my INBOX(such as gmail) to local, stored in a database, but I have encountered the following issues too:

How to identified new files to be synced to local ( may be messageId & search func by pop3?)

Once the mail is synced to local, is it possible to impl the REPLY/FOWARD just as the users do on the web client provided by the mail vendor(gmail for example)

Any suggestion will be appreciated.


Remove TypeScript definition

According to TypeScript documentation the TypeScript definition shouldn't really be in this package. It should be published in https://github.com/DefinitelyTyped/DefinitelyTyped by PR.
So I've removed the obsolete TypeScript definition from this project. Once this and the other outstanding PRs are merge, we should be good to cut the 4.0 release.

Coverage remained the same at 100.0% when pulling 43cb4608b051da9ba8761959524c3def4a5b9fb4 on juanjoDiaz:remove_typescript_definition into fb7ad5390c471eda3263fd9f1954e0cc794cdd00 on zemirco:master.

Coverage remained the same at 100.0% when pulling 43cb4608b051da9ba8761959524c3def4a5b9fb4 on juanjoDiaz:remove_typescript_definition into fb7ad5390c471eda3263fd9f1954e0cc794cdd00 on zemirco:master.

Coverage remained the same at 100.0% when pulling 43cb4608b051da9ba8761959524c3def4a5b9fb4 on juanjoDiaz:remove_typescript_definition into fb7ad5390c471eda3263fd9f1954e0cc794cdd00 on zemirco:master.

Has a PR already been submitted to DefinitelyTyped for types or is this relating to #236 where types will not be included until someone champions them?

The later.
Types will not be included until someone champions them.
Reason for that being that the previous types were totally outdated for the 4.0.0 release.
Are you willing to do such contribution? :)

One reason for an alpha release, so get some of these questions figured out 👍 If you are willing to champion that, we can add a reference to the readme about the availability of the types.

Understood. I would love to help however already bogged down in three separate projects. I just installed on one of them and 'npm i' uses the alpha and saw it break. Wanted to understand if there was a fix coming or if I was locked to v3. If I manage to get unburied from this mound of work, I will try to circle back to help out! Sorry I can not pitch in at this time!

@myspivey did your projects break because the API is different in v4.0.0 or because of the missing typescript?

If you use the alpha, you are no longer able to use this project with Typescript in an Angular project. v3 still works fine. I did not look into the full cause but on the Alpha I installed it still had the TS file so I would assume the api change.

alpha.1 no longer has types, they snuck into alpha.0. We will probably release 4.0 and not wait on types. If no one submits types I'll probably work on it myself.

In case this is useful to anyone, I have some preliminary types for v4. I haven't added the Transform class so they're not quite ready for DefinitelyTyped. If someone wants to add the Transform class then go ahead.
interface Field<T> {
    label?: string;
    default?: string;
    value: string | ((row: T, field: keyof T) => string | null | undefined);
    stringify?: boolean;
}

interface Options<T> {
    ndjson?: boolean;
    fields?: Array<keyof T | Field<T>>;
    unwind?: string | string[];
    flatten?: boolean;
    defaultValue?: string;
    quote?: string;
    doubleQuote?: string;
    delimiter?: string;
    eol?: string;
    excelStrings?: boolean;
    header?: boolean;
    includeEmptyRows?: boolean;
    withBOM?: boolean;
}

export class Parser {
    constructor(options?: Options<any>);
    parse(data: any);
}

export function parse<T>(data: ReadonlyArray<T>, options?: Options<T>): string;

Thanks @aj-r I have all the types ready and am currently testing before pushing them to DifinitelyTyped. I'll check if it matches your types.

Typings have been published.
Please let me know if you find any issue with them.


Will fail if config is not in the same folder as project root.

I have my project organized in various folders. One of them is app. Within there, I have a folder leading to all internal configuration files, including WebPack:
app/
  System/
    Config/
      webpack.js

Unfortunately, this breaks this plugin. Because the folder I want to delete is on the same level as the app folder - and that is cdn, my public assets.
app/ ...
cdn/
  app/
    [hash]-[name].(js|css)

Adding an option to the plugin to gently force a delete would be nice. I use an automated Surge.sh uploader, and it now uploads everything...

Should be fixed in #7


Don't drop into ZSH in the installer

Hi!
Is it possible for the installer to not drop me into a ZSH session at the end of the script when oh-my-zsh has finished installing?
I have this installed as part of my Dockerfile and there are several steps I want to take after installing oh my zsh liky making symlinks etc. These all get skipped if I get dropped into zsh.
How do I solve this issue?

Nevermind.
I'm just doing a git clone now, with my own .zshrc :-)

This will be fixed on #5123; but yes, for the moment a git clone is enough. The installer is also more directed to end users instead of to non-interactive installations, so we check if zsh is installed and if it's the default $SHELL.


Allow resolve plugins to handle fs when target is node

Feature request

I have target set to node, so webpack automatically sets fs as external. I want my resolve plugin to still be able to modify imports to fs.
What is the expected behavior?
When a resolve plugin does resolver.hooks.resolve.tapPromise, it should be able to handle Node.js modules like fs and http.
What is motivation or use case for adding/changing the behavior?
I want to use webpack for mocking modules when testing. When I import jsonfile I want it to use a mock file system. For that I need to change imports from fs to memfs
How should this be implemented in your opinion?
Let the resolve plugins modify requests to external modules. Also let the plugins mark a module as external.
Are you willing to work on this yourself?
no

use externals option, e.g.
externals: { fs: "Memfs" },

and in entrypoint
global.Memfs = require("memfs");

@vankop That doesn't solve my issue because I want to replace fs with memfs conditionally, depending on the path of the file which is importing fs.

external could be a function in case of fs resolving to fs external should looks like externals: { fs: "commonjs fs"}


Chain Serialization Support with Azure OpenAI LLMs

It's really useful to move away the prompts etc. from the main codebase. Currently, from the documentation and my own testing, seems that only those chains can be serialized that have OpenAI LLM (only text-davinci-003). But, no such support is available for Azure-based OpenAI LLMs (text-davinci-003 and gpt-3.5-turbo).
Is my understanding correct? If yes, any plans on adding it soon?

I have the same question.


Use jackson to replace the related code of fastjson, and improve the related unit test of jackson

Why are the changes needed?

For project security, fastjson needs to be replaced with jackson. First, a jackson tool class is needed to encapsulate some functions of fastjson
(For example: The Arctic Flink dataStream API has already supported this configuration: 'scan.startup.mode', but it is not available with Flink SQL. We should expose this configuration to users when they are using Flink SQL.)
Brief change log
(For example:)

Add the 'scan.startup.mode' configuration to the ArcticScanContext in the flink modules
The flink 1.12 and 1.14 versions are affected.
Add the documentation in the flink chapter

How was this patch tested?

[ x] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x ] Run test locally before making a pull request

Documentation

Does this pull request introduces a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Thanks for your contributions. All class must have license

This pr relate a issue, please label "fix #xxx" in comment

The title format does not conform to the specification


Saving user profile details

Saves profile details on second try from<EMAIL_ADDRESS>accounts (X=1-9), profile details to be saved on first attempt.

@inside1D  can u verify if it's still like this after deploying. if yes/no update the ticket and the report
https://github.com/CPSC319-2022/JungleCart/issues/255

@armintalaie  The issue persists. I still cannot modify anything during the first login. I will update the report accordingly


Panic in rasterizer.rs

Hi,
When I move text in my program, I get this panic:
RUST_BACKTRACE=1 cargo run --release test_data/kicad.lib test_data/kicad.sch                                                                                 130   gfx-rework
   Compiling schema_parser v0.1.0 (file:///home/bastli/Programming/schema_renderer)
    Finished release [optimized] target(s) in 13.93 secs
     Running `target/release/schema_renderer test_data/kicad.lib test_data/kicad.sch`
thread 'main' panicked at 'internal error: entered unreachable code', /home/bastli/.cargo/registry/src/github.com-1ecc6299db9ec823/rusttype-0.3.0/src/rasterizer.rs:155:17
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:68
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:57
             at /checkout/src/libstd/panicking.rs:381
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:397
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:577
   5: std::panicking::begin_panic
   6: <rusttype::rasterizer::CurveSliceIter as core::iter::iterator::Iterator>::next
   7: rusttype::rasterizer::rasterize
   8: gfx_glyph::gpu_cache::Cache::cache_queued
   9: <gfx_glyph::GlyphBrush<'font, R, F>>::draw_queued_with_transform
  10: <schema_renderer::drawables::text_drawable::TextDrawable as schema_renderer::drawables::Drawable>::draw
  11: <schema_renderer::drawables::group_drawable::GroupDrawable as schema_renderer::drawables::Drawable>::draw
  12: schema_renderer::main
  13: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:101
  14: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:459
             at /checkout/src/libstd/panic.rs:365
             at /checkout/src/libstd/rt.rs:58
  15: __libc_start_main
  16: _start

Unfortunately I am not really familiar with the rusttype codebase so a fix by myself doesn't seem feasible ...
Best,
Yatekii

Okay, so I tried to reproduce this but I wasn't able to thus far.
The font was Inconsolata-Regular, directly loaded from Google.
I had some changes to the codebase but tried to go back to the old state with git. But somehow it just wont trigger anymore. I keep on trying and will notify you as soon as it happens again.
Also, in the source head the glyph.draw call is not on line 494. Could that be possible? It's more like line 525 for me.

It's more like line 525 for me.

Right you are, not sure where I got 494 from...

I'll close this for now, please re-open if/when anyone can reproduce.


[Refactor] Refactor some publish version logs

remove duplicated host in log and duplicated debug log when publish version failed in FE
2023-07-04 18:49:36,325 ERROR (pool-41-thread-11[237) [PublishVersionDaemon.publishPartition():438] Fail to publish partition 45403 of txn 70128: Fail to publish version for tablets {}[477041], host: <IP_ADDRESS>, host: <IP_ADDRESS>

refactor publish version success log in BE

Fixes #issue
What type of PR is this:

[ ] BugFix
[ ] Feature
[ ] Enhancement
[x] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] This pr will affect users' behaviors
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[x] 3.1
[x] 3.0
[ ] 2.5
[ ] 2.4

[FE PR Coverage Check]
:disappointed: fail : 0 / 3 (00.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/lake/Utils.java
0
1
00.00%
[145]

:large_blue_circle:
com/starrocks/rpc/RpcException.java
0
2
00.00%
[28, 29]

@Mergifyio backport branch-3.1

@Mergifyio backport branch-3.0

@Mergifyio backport branch-3.1

@Mergifyio backport branch-3.0


Getting  ConcurrentModificationException when trying to parse a number on android

Hi,
I got a ConcurrentModificationException at one instance while parsing the number .I am using java version 7.0.1
Following is the stack trace:
ANDROID_VERSION=5.0.1
PHONE_MODEL=Nexus 4
STACK_TRACE=java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:787)
at java.util.HashMap$KeyIterator.next(HashMap.java:814)
at java.util.jar.JarVerifier.readCertificates(JarVerifier.java:266)
at java.util.jar.JarFile.getInputStream(JarFile.java:380)
at libcore.net.url.JarURLConnectionImpl.getInputStream(JarURLConnectionImpl.java:222)
at java.net.URL.openStream(URL.java:470)
at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:444)
at java.lang.Class.getResourceAsStream(Class.java:1334)
at com.google.i18n.phonenumbers.PhoneNumberUtil$1.loadMetadata(PhoneNumberUtil.java:62)
at com.google.i18n.phonenumbers.PhoneNumberUtil.loadMetadataFromFile(PhoneNumberUtil.java:616)
at com.google.i18n.phonenumbers.PhoneNumberUtil.getMetadataForRegion(PhoneNumberUtil.java:2043)
at com.google.i18n.phonenumbers.PhoneNumberUtil.parseHelper(PhoneNumberUtil.java:2901)
at com.google.i18n.phonenumbers.PhoneNumberUtil.parse(PhoneNumberUtil.java:2763)
at com.google.i18n.phonenumbers.PhoneNumberUtil.parse(PhoneNumberUtil.java:2753)

Are you running the library in a multi-threaded environment?

yes .I have synchronized my function so i didn't receive a exception  till now

Can you clarify? You are running in a multi-threaded environment. The function which calls libphonenumber is synchronised. Are other synchronised functions also calling the phone number library? Have you tried guarding the call with a lock?

I had contact sync function which was getting called from multiple instances  so by synchronizing this sync function i am able to resolve this issue now


Moving components into packages of a monorepo breaks the babelifiedMessages

Hi @nbouvrette Nicolas
have you ever done some work in a monorepo?
I have changed our codebase and some of the translated components are moved into a packages folder in second workplace.
If you use inside a component from packages/components:
import { getMessages } from 'next-multilingual/messages';

it will break the main process due to:
function getBabelifiedMessages(sourceFilePath) {
    var parsedSourceFile = path.parse(sourceFilePath);
    var sourceFileDirectoryPath = parsedSourceFile.dir;
...

while sourceFileDirectoryPath is relative (missing root).
I just made a quick fix into the node_modules js file
if (sourceFileDirectoryPath.startsWith('Users/')) sourceFileDirectoryPath = '/' + sourceFileDirectoryPath;

which does the work now on my machine.
I am thinking if a path translator should be added in the plugin configuration like imports from webpack or paths from tsconfig.json
like:
  pluginConfiguration: [
    "next-multilingual/messages/babel-plugin",
    {
      applicationId: appId,
      ...,
      paths: {
        "Users/"; "/Users/"
      }
    }
  ]

or if it just should check if relative path exists and if not try as full path.
Thanks for feedback and hopefully you are fine
Tom

Hi @TomFreudenberg
Long time no talk. I don't have much experience playing with mono-repos, but it also looks like you are using an old version.
Last summer I moved most of the Babel plugin logic into this new package: https://github.com/Avansai/messages-modules
I think if we would need to support your use case we would probably need to modify this package as well. I'm not too sure where the code you provided was used and also not sure I fully understand what is going on in your scenario.
It might be easier to jump on a call like we did last time to save on some back and forth if this can be an option for you.

Yes @nbouvrette Nicolas :-) long time ago but still using your component :-)
I use my fork and be aligned with your version v0.12.0 from June 2022.
I will try to apply our needs to your current stable and come back to you.
Have you already got the new NEXTjs 13 features from src/app ?
Looks pretty interesting what is coming up there.
Will give you more feedback later
Tom

I'm about to release version 3 which will support dynamic catch-all routes (probably tomorrow). There will be a few breaking changes that I will document.
Regarding Next 13 it's on my to-do list to check. If I understood correctly from the conference yesterday the routing patterns should stay the same which is good news for us!

Regarding Next 13 it's on my to-do list to check. If I understood correctly from the conference yesterday the routing patterns should stay the same which is good news for us!

yeah

I'm about to release version 3 which will support dynamic catch-all routes (probably tomorrow). There will be a few breaking changes that I will document.

ok thanks for the info. then i will wait for your update and apply my work on top
currently i have enough to do with moving our work into turbo monorepo ;-)

Do you know if Truborepo forces you to use SWC?
This is a big challenge for next-multilingual because it looks like we would need to rewrite our plugin in Rust. That part is not too bad but the problem is that if we would want the same level of details we are getting with our own https://github.com/Avansai/properties-file package, we would also need to rewrite it in Rust...

As far as I can get it by now, babel ist still available

Great news. Looking forward to try this myself shortly as well

Hey @nbouvrette Nicolas
As I see, your update is only - so I will start on that?

Yes, I don't foresee significant changes any time soon unless we find unexpected bugs with the new version but the +800 tests should have hopefully caught most of them :)

Hi @nbouvrette Nicolas
I was currently only able to align your release 1.0.7
Changes due to your new packages message-modules and properties-file will break my changes while I still use yaml files for the translation files.
I guess in case of your strict design decisions it won't be possible to do it as a translation-file package which can handle more than properties file.
I will come up to you when digging more deeper into.
Cheers
Tom

One reason I wrote the new properties-file package was to get more insights into possible issues with localizable assets.
As we discussed in the past (I think) my main concern with yaml files is that you can use them for more than just key/values which might cause issues during the translation process.
Nobody else asked for other file support so far, which is either because there isn't a lot of serious users of the package around (even tho we hit 150 stars), or the current solution meet most needs.
I don't have a ton of experience personally supporting yaml files with commercial TMSes but  I do recall various issues related to parsing some files so I am still hesitant to consider official support for them.

Yeah I know and respect your concerns and arguments.
Mostly my biggest issue still with the current properties files is the force / need of "app_id.segment.key" instead of just having "key".
I mean we have discussed this also already - applicationId should not a must on properties file and segment is auto-adjustable to source-filename.
While this may not valid or good for blogs and lot of written international content, but it is the best solution on app development for us.
I check out the current state and come back to you ;-)

OK cool and I still had  a few thing in our backlog that we never got to. Not sure if they would help or not at this point but keep me posted!

Yes, this error could happen if you don't configure your Webpack handler correctly. There is a weird issue where Webpack doesn't handle imports using the node: prefix that has been available for a while and that is also the recommended way to import Node-native modules now.
I presume you are using the advanced config? Can you make sure your Webpack config is set correctly based on the info provided here: https://github.com/Avansai/next-multilingual#-config-advanced-config

Hi Nicolas @nbouvrette
thanks for the hint, I got it working - I missed the requirement for webpack configuration!
Now I come back to your .properties decision:

AppIdentifier

This may make sense if I have to translate a lot of applications at the same time.
I would say - most developers are working and translating on ONE application at the same time. Also I assume, mostly they will translate the (few) app strings by themself or in the small team.
So for that, repeating the "AppIdentifier" each line in each .properties file is just annoying.

Section

Again, this may make sense if I have to translate a lot of applications at the same time.
With same assumption as 1), the "section" identifier is just some (random) unique key to make sure that the correct translations are used on each source. But, the unique key of each source file is the "path/filename" of themself.
So "section" could be build automatically by "path/filename" from source file.

Summarize 1) and 2): ApplicationId and Section should not be required always in the .properties file. For small teams and apps it is versus the DRY-rules

Key

a) Your key is required to be only alphanumeric and numbers from 1-50 chars.
b) If key is not found in .properties file, NOTHING is shown in the app but only a warning on console.
This decision a) only allows to have a kind of "cryptical" ids in your app while developing and enforce you to directly fill in the translation files as well.
While using hot reloading features and working on the app, there are moments when nothing is shown in the app due to b)
I can't get the necessarity for your decision 3) at all. Maybe it is that you need to enforce your developers on your development projects but on our - and I would say again also on any small teams and apps - projects it is just annoying.

As already said on our phone call, there are some requirements for us to use next-multilingual:

ApplicationId is not required in .properties file
"section" will be generated automatically from "path/filename" and is not required in .properties file
"keys" may contain normal text
If a "key" is not found in the translation file, the "key" itself will be shown

Last, as you can get now from our above requirements 1), 2), 3) also the .properties file type is not necessary in all cases. Having keys in a full text manner, then also or even better YAML file type can handle the translation files:
Access denied: Kein Zugang
Cancel: Zurück

You are not signed in!: Sie sind nicht angemeldet!
You do not have proper rights!: Sie haben keine ausreichenden Rechte!

or even lines with line breaks
Approval: Posteingang prüfen
Cancel: Abbruch

A sign-in link has been sent to your email address.: >-
  Ein Link zur Anmeldung wurde<br/>
  an Ihre Email‑Adresse versendet.

For us, YAML file type has a high visibility for text content.

As said in our phone call, I would like to help and work on OPTIONAL settings to just ALLOW our requirements in addition by the "Config" and not for default. I respect your decisions but they don't fit in any case ;-)
Looking forward to your feedback.
Cheers
Tom

I went through your comments, and unless I am misunderstanding how you deal with your translation on your projects, it really sounds like you operate in teams that are autonomous. Basically your team both handles the development and the translation of your application. In these conditions, these constraints can seem annoying like you said but let me try to explain why they are there.
1) Key prefixes
Regarding the applicationId and the context part of the key, to clarify they have nothing to do with this:

I would say - most developers are working and translating on ONE application at the same time.

These constraints are not for developers, they are for LSPs (language service providers, also known as translators).
Especially if you are a smaller client, they will most likely leverage their translation memory, which means if you use short keys, they might set the configuration in their tools to generate ICE matches. And in these cases, they might just take whichever translation was in their tool without verifying, which might or might not cause quality issues. By having unique keys you make sure that you never run into these issues and also guaranteed that your company/project will be able to scale without running into these issues.
2) Key constraints

Your key is required to be only alphanumeric and numbers from 1-50 chars.

I don't think this is the problem. In fact, having large keys are known to cause problems for some translation tools. I think what you are looking for is to be able to use the sentence in the code instead of keys? If so, I had a backlog item for this but since you were the only person asking for this I never prioritized it yet. I also think that having a fallback option could be feasible. If you check the TODO, you can see they are on the list at the bottom.
If the other benefit you are seeing is for the translation itself, this would probably only apply if your developers are doing the translation so that they can see the source text next to the translated text. You could achieve similar results with .properties files by simply opening them side to side. Even IntelliJ (the Jetbrain IDE) have a table view for .properties file which mimics a bit the tools translators are using.
Of course, translators don't need this because the tools they use already provide them with that side-by-side view.
3) File type

Having keys in a full text manner, then also or even better YAML file type can handle the translation files

You could do the same with .properties file. You can have spaces in your keys and newlines just like .yaml. But the big question is will translation tools support this?
Remember, next-multilingual is not just for developers. In the sense that a lot of i18n tools out there have been developed by developers, for developers. Often by people who have no experience working with LSPs or translators.. which basically makes those tools non-scalable and inadequate for translation services.

One Sentence her:

You can have spaces in your keys and newlines just like .yaml.

If I remember correctly, those keys must be written always in paranthesis (") ?
And you can't (if I am correct) enter your value in multiple lines which get conjuncted by the yaml parser
See my examples from above YAML examples.

All I'm discussing here is to make a developer's job easier ;-)

You can check all the weird ways you can use properties files here (don't rely on the highlight that much because even the Git parser does not follow the official Java standard...):
https://github.com/Avansai/properties-file/blob/main/assets/tests/test-all.properties
Having said this, this is one of the reasons I wrote this new package because the specification for .properties files are not very well defined. It's mostly a Java creation and they never really release clear specifications, so a lot of other libraries out there will provide different results when parsing the files.
.yaml is probably worse, especially for translation tools because it's a less mature format and it is also much more complex than .properties file - so it's almost certain that it will cause more tooling-related issues.
And yes I know you want to improve the developer experience, we all do. But this is also why next-multilingual exists, to bridge the gaps between developers and translators.
Regarding not using a fork, totally make sense but I don't know which comprise you are willing to make or not.
On my end, we have items that have been in the backlog for a while, and to be completely transparent I am a bit more concerned about Next.js 13 right now than any features on the backlog.
I did some tests yesterday and it looks like the future of i18n for Next.js will be quite different than it is today... meaning if we want to continue future support with next-multilingual we will have a huge effort ahead (most likely weeks or even months of development) to:

define how to configure, and get locales across applications when using the app directory
rebuild the new router to support the new app directory model
support SWC and Rust and get rid of Babel once and for all?

Hey Nicolas
yes the big question ... how to proceed on next 13 is the main point
As I got it now, "app" is still beta and therefore until next year I am pretty sure.
In addition, pages will still be supported and also other's discussing i18n already
https://github.com/vercel/next.js/issues/41980
But yeah, it is something like reinventing the wheel.
Also SWC is more and more important, Babel will have it's counted days until that should be dropped.
Nevertheless, to fit our needs as well, we need to get the optional path as written above.
Not sure if you want to make next-multilingual the next standard for i18n but for that you have to catch a lot of developer's.
Do you have an idea why currently not more are using it?
What about having an additional call to discuss again? I am working currently on a template for a nextjs app starter, so my time is also counted.
Good night
cheers, Tom

I'm currently making 0 noise around this repo :) I'm actually surprised it has so many stars.
The main reason I did this repo was for myself... and I am happy to open-source it but one thing I don't want this to become is another i18n solution made by developers, for developers. It would go against everything I learned over the past few years and wouldn't be something I would be proud of maintaining. It's also why in the description I call this an opinionated package because I know it won't be the most popular package and honestly I'm pretty OK with this. I'm not looking for glory or attention :)
Having said this, I was thinking about your situation, correct me if I am wrong but you don't have many benefits from localized URLs? If this is a trade-off you would consider, maybe simply using https://github.com/Avansai/messages-modules would be a good option for you.
A benefit of using this directly is that you can create your own wrapper, which includes the file type and everything you don't like about next-multilingual. Of course, you would need to create your own wrapper, but I think it can be done with a few hours of development at most which will probably be better than maintaining a fork.
Let me know if you think this could be a good option and I am happy to continue to help you if you go in this direction.

Hi Nicolas

It's also why in the description I call this an opinionated package because I know it won't be the most popular package and honestly I'm pretty OK with this. I'm not looking for glory or attention :)

Got that and I am fine on that. But let me say - it's a petty because the concept is a good one and more should use it or have the option to use it. I like it very much to have the translation files directly beneath the sources !!!

you don't have many benefits from localized URLs?

Absolutely correct - we have NONE because we don't use them. The URL is still - based on the app and customer - native mostly german or international and english.
Non of the apps we make is SEO important. Most of the stuff is behind the login wall. So all we are looking for is a nice developer experience when working with translations and translation files.

Let me know if you think this could be a good option and I am happy to continue to help you if you go in this direction.

Agree on that, I have already thought about in same manner you do.
But at least - isn't it still a kind of fork (downstripped) of next-multilingual with another file type provider and some other opinionated (my) defaults?

Got that and I am fine on that. But let me say - it's a pity because the concept is a good one and more should use it or have the option to use it. I like it very much to have the translation files directly beneath the sources !!!

Thanks. I think the "message modules" concept is probably the most generic concept of next-multilingual and also why I created a separate repo just for this. I think in general people tend to have a lot of different opinions when it comes to i18n and that probably it's one of the reasons why Next.js decided to stop their support

But at least - isn't it still a kind of fork (downstripped) of next-multilingual with another file type provider and some other opinionated (my) defaults?

If you use the message module repo directly you can decide on the file type and rules you want to implement around your message files. You can inspire yourself from the next-multilingual implementation here https://github.com/Avansai/next-multilingual/tree/main/src/messages. Probably the only "advanced" feature you would want to keep would be the JSX formatter which you would need copy and then maintain but it should not be a lot of code to manage on your end I would think.
Ultimately if you do this, you own the code.. other than the Babel plugin which does most of the "message module" logic.. so for me, it would no longer be a fork. It's basically your own package.

Hi Nicolas
ok, so I try to go with messages-modules - If looking for SWC as babel replacement - where would you start? Is this the messages-modules then which has to be changed or is the babel plugin still inside the next-multilingual or "my component"?
Thanks for your open mind and words

I originally created the messages-modules package to be able to handle both Babel and SWC plugins.
Unfortunately, it looks like the SWC JavaScript plugins are being replaced by Rust plugins (for performance reasons). The way I originally split messages-modules was basically to handle all the plugin logic here:

https://github.com/Avansai/messages-modules/blob/main/src/index.ts

And then you could use the package to create your own plugin on top (a wrapper) that would be responsible to parse the file and send the key/values to the messages-modules plugin package. This is an example of a wrapper:

https://github.com/Avansai/messages-modules/blob/main/src/babel-plugin/index.ts (not to be used for production)

You can see you could easily replace .properties file by .yaml or whichever else file you want to support. Of course, the example plugin does not include any formatting feature like ICU syntax which is something we added on top of JSX injection in next-multilingual here:

https://github.com/Avansai/next-multilingual/tree/main/src/messages

So now the challenge, is because of the way the boundaries are defined it won't work with Rust.. we would need to write both the messages-modules in Rust as well its wrappers. This comes with challenges in terms of being able to use the same file parser between the JavaScript application and the Rust plugin. This might not be a big issue for you for for next-multilingual it was nice to be able to parse the files the same way for both the localized URLs and the messages.
Now I don't know if this context helped or not but if you want to dig more into this, maybe there is an opportunity to work together and integrate your work in messages-modules since it was something I had on my personal backlog.
Keep me posted!

Hi Nicolas

maybe there is an opportunity to work together and integrate your work in messages-modules since it was something I had on my personal backlog.

That's also what I would like to do - keeping our connection und our work together.
I will checkout the messages-modules and RUST opportunities and come back to you.
A question on this: why is "properties-file" a "Dependency" but not only a "devDependency" of messages-modules?
Cheers
Tom

I didn't put it as a dev dependency because the package offers a working example plug-in which is based on properties file. This is something we could reconsider but unless you use the example plugin you should never need to use this dependency. It's sort of a convenience dependency that is never really used other than to test/learn to use the package


Couchbase logical operator

Does logical operator work ? Didn't found any example or working code. For me it hasn't any effect on query.
Example:
const results = database.query({
	select: [],
	where: [{ property: 'group', comparison: 'equalTo', value: 'articles', logical: 'and' },
{ property: 'articleNr', comparison: 'like', value: 'demo', logical: 'and' }],
	order: [{ property: 'articleNr', direction: 'desc' }],
	limit: 10,
});

Query either returns nothing or everything. What I'm doing wrong ?
Background:
I'm trying to save different kind of "types" (Articles, Adresses...) - thats why I need at least to where operators (first for type, second for specific search query)

Answering myself. Was testing this for hours until I tried Uppercase operators...
In case somebody has similar issues  - this one works:
const results = database.query({
	select: [],
	where: [{ property: 'group', comparison: 'equalTo', value: 'articles', logical: 'AND' },
{ property: 'articleNr', comparison: 'like', value: 'demo', logical: 'AND' }],
	order: [{ property: 'articleNr', direction: 'desc' }],
	limit: 10,
});


Add Singer information

Add singer information in the Song class
Add singer information extraction in Scrapper

Done in b1b3613;


Update routeguide tutorial for tokio 1.0

Feature Request
Hola compadres!
Newbie here, was going through the routeguide tutorial and noticed that it uses really old version of tokio. In the same time https://github.com/hyperium/tonic/issues/443 this here states that tonic is ready for v1.0 of tokio, so I was wondering if it is possible to update the tutorial to make it closer to real life example?
Basically the error is:
error[E0277]: the trait bound `tokio::sync::mpsc::Receiver<std::result::Result<Feature, Status>>: futures_core::Stream` is not satisfied
   --> src/main.rs:22:5
    |
22  |     type ListFeaturesStream = mpsc::Receiver<Result<Feature, Status>>;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `futures_core::Stream` is not implemented for `tokio::sync::mpsc::Receiver<std::result::Result<Feature, Status>>`
    |
   ::: /home/ikiselev/git/rust/routeguide/target/debug/build/routeguide-d2cfcf7a92f3d239/out/routeguide.rs:196:34
    |
196 |         type ListFeaturesStream: Stream<Item = Result<super::Feature, tonic::Status>>
    |                                  ---------------------------------------------------- required by this bound in `RouteGuide::ListFeaturesStream`

I suggest it's somehow connected to tokio moving out stream feature to a separate crate, but being generally newbie in rust - I couldn't understand how to use it to come up with a solution. Also, if somebody would give me a clue in what direction to dig - I'll happily submit a PR when I find how to fix the thing
Motivation
Tutorials being up to date and not using outdated libraries/APIs is just always nice thing to have

Ah wait, I see that in the examples Cargo.toml - tokio is already 1.0. So it's that the tutorial itself was not updated!
That makes it easier!

Ah wait, I see that in the examples Cargo.toml - tokio is already 1.0. So it's that the tutorial itself was not updated!
That makes it easier!

Yeah, we just need to update that, I think I just missed it in the release PR :D

Yeah, we just need to update that, I think I just missed it in the release PR :D

I just stumbled upon the same problem while updating my code from tonic 0.3 to 0.4 and to tokio 1. It seems that examples do not contain use case where type ListFeaturesStream = mpsc::Receiver<Result<Feature, Status>>; is used like this.

Okay I learned something today.
So instead of this: https://github.com/hyperium/tonic/blob/master/examples/src/routeguide/server.rs#L39-L65
type ListFeaturesStream =
    Pin<Box<dyn Stream<Item = Result<Feature, Status>> + Send + Sync + 'static>>;

async fn list_features(
    &self,
    request: Request<Rectangle>,
) -> Result<Response<Self::ListFeaturesStream>, Status> {
    println!("ListFeatures = {:?}", request);

    let (tx, rx) = mpsc::channel(4);
    let features = self.features.clone();

    tokio::spawn(async move {
        for feature in &features[..] {
            if in_range(feature.location.as_ref().unwrap(), request.get_ref()) {
                println!("  => send {:?}", feature);
                tx.send(Ok(feature.clone())).await.unwrap();
            }
        }

        println!(" /// done sending");
    });

    Ok(Response::new(Box::pin(
        tokio_stream::wrappers::ReceiverStream::new(rx),
    )))
}

You can do this:
type ListFeaturesStream =
    tokio_stream::wrappers::ReceiverStream<Result<Feature, Status>>;

async fn list_features(
    &self,
    request: Request<Rectangle>,
) -> Result<Response<Self::ListFeaturesStream>, Status> {
    println!("ListFeatures = {:?}", request);

    let (tx, rx) = mpsc::channel(4);
    let features = self.features.clone();

    tokio::spawn(async move {
        for feature in &features[..] {
            if in_range(feature.location.as_ref().unwrap(), request.get_ref()) {
                println!("  => send {:?}", feature);
                tx.send(Ok(feature.clone())).await.unwrap();
            }
        }

        println!(" /// done sending");
    });

    Ok(Response::new(Box::pin(
        tokio_stream::wrappers::ReceiverStream::new(rx)
    )))
}

https://github.com/rumanbsl/tonic-routeguide-code
I was solving the same, haha


Separating buildAttempts & checkAttempts in build tooling & edge case fix

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

[x] The toolchain has been rebuilt successfully (or no changes were made to it)
[x] The toolchain/worker package manifests are up-to-date
[x] Any updated packages successfully build (or no packages were changed)
[x] Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
[x] Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
[x] All package sources are available
[x] cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
[x] LICENSE-MAP files are up-to-date (./SPECS/LICENSES-AND-NOTICES/data/licenses.json, ./SPECS/LICENSES-AND-NOTICES/LICENSES-MAP.md, ./SPECS/LICENSES-AND-NOTICES/LICENSE-EXCEPTIONS.PHOTON)
[x] All source files have up-to-date hashes in the *.signatures.json files
[x] sudo make go-tidy-all and sudo make go-test-coverage pass
[x] Documentation has been updated to match any changes to the build system
[x] Ready to merge

Summary

What does the PR accomplish, why was it needed?
Other parts of the pipeline couldn't parse the log names to mark test pass/fail because of the log renaming, so the last attempt isn't getting renamed anymore. Also, the logic has been fleshed out more for buildAttempts / checkAttempts.
Change Log

Doing retry.Run multiple times to separate buildAttempts, checkAttempts, and the last buildAttempt (not renaming log file on check failure for this single attempt).

Does this affect the toolchain?

NO
Test Methodology

Pipeline build id: 322456

I think for now we could go for something simpler and keep the code cleaner: instead of moving the log file for errors, let's only copy it. This way we will keep the logs for all failing builds as well as maintain the original behaviour where the original log file path pointed to the most recent build.
Here's what I have in mind:

Revert the current changes.
Copy the log file instead of renaming it, which should only require replacing os.Rename with file.Copy.
NOTE: file.Copy is our internal function. Yes, default Go libraries don't have a function for copying files. Or at least they didn't in the previous versions. :)
Let's also save a copy of the log for regular build failures. I'd suggest extracting to log copying logic into a separate function and calling that build and test failures.

I reverted the previous version that was a bit complicated / messy; does this line up more with what you were suggesting?


Node Security Issue with lodash: 577 - Prototype Pollution

We need a lodash update. It'd be a good time to release to resolve #301 as well.

I can approve this. +1

It still seems to be a problem on 1.12.0 according to Snyk (https://app.snyk.io/test/npm/vorpal/1.12.0).

I'm pretty sure this project is dead, @Berkmann18.

@johncblandii I hope not. @dthree ?

Why has this not been merged, rather unacceptable that a high security vulnerability has been here for over a year

Because the project is dead and the old vorpal admins haven’t put anyone else in charge.

@slinkardbrandon I guess either https://github.com/vorpaljs-reforged/vorpal or https://github.com/oclif/oclif is the play now.

I'm starting using this fork: npm i @moleculer/vorpal


feature(core): create local storage

What kind of PR is this?:

/kind feature
What this PR does / why we need it:

Allows the use of a local storage json file for native devices and localStorage for web.
Uses expo-file-system to create a local file for storage purposes
User preferences will be called on change of network or wallets
Ability to fetch setUserPreferences via dispatch
setAddresses can be done to overwrite the preferences file
useAppDispatch hook to be able to fully use thunks, should be chainable like a promise

Which issue(s) does this PR fixes?:

Fixes https://github.com/DeFiCh/wallet/issues/2225
Additional comments?:
Developer Checklist:

[ ] Read your code changes at least once
[ ] Tested on iOS/Android device (e.g, No crashes, library supported etc.)
[ ] No console errors on web
[ ] Tested on Light mode and Dark mode*
[ ] Your UI implementation visually matched the rendered design*
[ ] Unit tests*
[ ] Added e2e tests*
[ ] Added translations*

Can you help to add some unit tests to mobile-app/app/api/secured/index.test.ts? Like how we did for SecuredStoreAPI

Will add this test on another PR so integration won't be blocked


404 Not Found errors for retrieving Overpass data

I am running the clone example from the README. The docker image starts successfully, but after downloading data, I have many 404 Not Found errors for retrieving from the Overpass server.
kmehta@kmehta-desktop:~$ sudo docker run   -e OVERPASS_META=yes   -e OVERPASS_MODE=clone   -e OVERPASS_DIFF_URL=https://planet.openstreetmap.org/replication/minute/   -v /big/docker/overpass_clone_db/:/db   -p 12346:80   -i -t   --name overpass_world   wiktorn/overpass-api
No database directory. Initializing
--2021-01-19 18:46:58--  http://dev.overpass-api.de/api_drolbr//trigger_clone
Resolving dev.overpass-api.de (dev.overpass-api.de)... <IP_ADDRESS>, 2a01:4f9:2b:2fd4::2
Connecting to dev.overpass-api.de (dev.overpass-api.de)|<IP_ADDRESS>|:80... connected.
HTTP request sent, awaiting response... 416 Requested Range Not Satisfiable

    The file is already fully retrieved; nothing to do.

--2021-01-19 18:47:01--  https://dev.overpass-api.de/clone//2021-01-15/replicate_id
Resolving dev.overpass-api.de (dev.overpass-api.de)... <IP_ADDRESS>, 2a01:4f9:2b:2fd4::2
Connecting to dev.overpass-api.de (dev.overpass-api.de)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2021-01-19 18:47:02 ERROR 404: Not Found.

Fetching nodes.bin
--2021-01-19 18:47:02--  https://dev.overpass-api.de/clone//2021-01-15/nodes.bin
Resolving dev.overpass-api.de (dev.overpass-api.de)... <IP_ADDRESS>, 2a01:4f9:2b:2fd4::2
Connecting to dev.overpass-api.de (dev.overpass-api.de)|<IP_ADDRESS>|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2021-01-19 18:47:02 ERROR 404: Not Found.

It might be the case that you didn't manage to download all the files of the clone, before it was removed from server, as it looks like you're trying download a bit old files. Anyway - for me the first request trigger_clone returns the date 2020-01-19 and from the logs it looks like the file already exists, so you try to download to directory that was already partly download. The script tries to continue, but it will continue as long as the files are available on the server, which is no longer the case.
You need to start over with empty directory.

It might be the case that you didn't manage to download all the files of the clone, before it was removed from server, as it looks like you're trying download a bit old files. Anyway - for me the first request trigger_clone returns the date 2020-01-19 and from the logs it looks like the file already exists, so you try to download to directory that was already partly download. The script tries to continue, but it will continue as long as the files are available on the server, which is no longer the case.
You need to start over with empty directory.

Ah got it. Do the files get updated every day? The initial download takes me ~20 hours

Ah got it. Do the files get updated every day? The initial download takes me ~20 hours

Yes, files are updated every day.

Yes, files are updated every day.

Ok, so I need the entire initial download to finish within one day, but after that the container can continue running?

Ok, so I need the entire initial download to finish within one day, but after that the container can continue running?

Exactly

Exactly

hey @wiktorn, sorry to open up an old issue but at the moment http://dev.overpass-api.de/api_drolbr//trigger_clone returns
https://dev.overpass-api.de/clone//2023-05-08, but https://dev.overpass-api.de/clone//2023-05-08/replicate_id is currently missing as it returns 404. How do I resolve this?

@mitkodev I guess you were just unlucky. Now trigger_clone returns 2023-05-09 and the files are there.


End-to-End testing with KinD

This PR adds some end2end testing with a KinD cluster.
The suite is intended to cover high-level features, while edge cases and special case errofor are demanded to unit tests.
I think they are helpful to work on new features or bug fixing without breaking what is already working.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 49.732%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
836

Relevant Lines:
1681

💛  - Coveralls

First, thank you for your PR for e2e.
I agree with you about to have e2e testing, but I wonder whether we should have golang e2e test or not.
Golang based e2e test is pretty good to test about Kubernetes API or some controller which utilize Kubernetes API, for example, consuming some CRDs and creating/modifying other CRDs dynamically.
Our testing focuses to check the traffic, so I suppose shell script based e2e is pretty enough because to testing the traffic, shell script can express the tests more simpler.
I've checked LoC (line of code) for each implementation (golang e2e and shell script based e2e, of your repo).
Your shell script based e2e:
https://github.com/zeeke/multi-networkpolicy-iptables/tree/multinetpolicy-bugs/e2e
[tohayash@sakaki e2e]$ wc -l $(find . -name  "*")
wc: .: Is a directory
      0 .
     16 ./README.md
     64 ./cni-install.yml
    122 ./multi-network-policy-iptables-e2e.yml
     43 ./oneway-test.sh
    204 ./oneway.yml
     97 ./setup_cluster.sh
     30 ./stacked-test.sh
    278 ./stacked.yml
     10 ./teardown.sh
     15 ./get_tools.sh
    879 total

Your PR, golang based e2e code:
https://github.com/zeeke/multi-networkpolicy-iptables/tree/e2e-testing/e2e
[tohayash@sakaki e2e]$ wc -l $(find . -name  "*")
wc: .: Is a directory
      0 .
     27 ./README.md
     64 ./cni-install.yml
     18 ./get_tools.sh
    123 ./multi-network-policy-iptables-e2e.yml
     85 ./setup_cluster.sh
     10 ./teardown.sh
wc: ./test: Is a directory
      0 ./test
     51 ./test/e2e_suite_test.go
wc: ./test/model: Is a directory
      0 ./test/model
     94 ./test/model/multinetworkpolicy.go
     54 ./test/model/namespace.go
     57 ./test/model/networkattachmentdefinition.go
     51 ./test/model/pod.go
    516 ./test/multinetworkpolicy_test.go
wc: ./test/reachmatcher: Is a directory
      0 ./test/reachmatcher
    429 ./test/reachmatcher/reachmatcher.go
     13 ./update_image_on_cluster.sh
   1592 total

As a result, golang based e2e has twice lines of code from shell script based. Unfortunately our community is pretty small and we don't have a big resource to maintain the lots of code, hence I prefer small lines of code implementation.
In addition, if we write networkpolicy as pure YAML (not golang), then it might help users to understand how to write multi-networkpolicy code.
So I believe that shell script based e2e could be feasible to implement our test cases. What do you think about it?

@s1061123 thank you for your feedback.
I definitely that the test suite should be as simple as possible, and sample YAML testable files are an excellent way to document features.
BTW, here are my thoughts about the comparison you did between "script-version" and "go-version" of tests:

"script-version" contains only two test cases (oneway-test.sh and stacked-test.sh), while the "go-version" has 12 test cases. We may talk about how many tests of this kind we want to implement, as they are much slower than unit tests, but I'm at least going to add some others for the IPv6 work, for instance.
Adding a test case with the "go-version" is about 30 LoC, while the "script-version" is about copy-pasting hundreds of YAML lines.
The "script-version" is missing any test framework to make it executable by a CI lane (e.g. shunit2 would do the work). Tests that are not scheduled in CI are likely to decay.

Can we find a tradeoff solution between maintainability and simplicity? Or maybe it's ok to add the shell test fwk and have redundancy in scenarios.

I think I can refactor these tests to have resources created by *.yaml files, but still using ginkgo as test runner.
In each test we can render pods, NADs and policies from YAML files, so they can be referred by README as examples, and we can still use go to make assertions.
@s1061123  WDYT about it? Can it be a good middle-way solution?

Hi,
This repo's E2E test has following requirements:

Less code is better (for easy maintenance)
Easy to add, easy to remove (for easy maintenance)
Easy to understand what we test from users' perspective (e2e for user demo to show sample pod/multi-networkpolicy)
Less dependency framework (not only for framework, container image should be independent from other repo)

As far as I know, ginkgo is to test golang code, so to me I still unsure why we need to rewrite in golang/ginkgo, because E2E test is to test end-to-end (create multi-networkpolicy and check the connectivity, in our repo's context).
BTW, this topic (idea to rewrite e2e in golang) is no longer about the PR's code, so how about to file a new issue in the repo and continue to discuss.
Let me close PR for that. So let's make new issue for that and continue to discuss.