Live node check with Farm Filtering

Description
How will the live node check work since the node selection is now changed to farm selection?
Currently the nodes on devnet are offline and when i configured my vm i was allowed to deploy but after that i got this error message mentioning that the node was not accessible.

And there's no check being done now and the deployment is allowed once the resource validation is passed.

@alichaddad please check if anything is needed for the gridproxy

Verified on devnet.
Live node check was added and each node is checked when it's selected from the nodes list to verify that it's online.
TF Playground _ Full Virtual Machine (4).webm


Does piknik -genkeys omit something for the server?

Thank you for creating piknik: this is a grand idea!
piknik 0.3 precompiles binaries from releases/. I run
piknik -genkeys

and copy the section marked for a server to the server, and the section marked client to a client. If I then launch the server (piknik -server) and use pkc on the client, the client says:
echo hello | pkc
2016/07/23 16:37:06 EOF

pkp
2016/07/23 16:37:22 unexpected EOF

If, however, I use the "hybrid configuration" from -genkeys on the server, it works.
The following contains my ~/.piknik.toml on the server (no worries: I'll throw this away later :-)
# Hybrid configuration

#Connect   = "<IP_ADDRESS>:8075"	# Edit appropriately
#Listen    = "<IP_ADDRESS>:8075"	# Edit appropriately
#Psk       = "0f51549a6c18c18a48695939f75e231de755543e18d08c2b5698d74515eb40c1"
#SignPk    = "670ab3a47bc63ca4c55f0e507fab249576ec5fc2ab9af4ddfdad96a417feb932"
#SignSk    = "b6dea70cdd36b28b2dbe9bfb24844fa1a7e534f30af7231c6dbdd0c40b5a3f64"
#EncryptSk = "b8a1a03b73906c0afdc7036c902d604fecd3e866cac05cb55e649a1d6cc33343"

# Configuration for a server

Listen = "<IP_ADDRESS>:8075"	# Edit appropriately
Psk    = "0f51549a6c18c18a48695939f75e231de755543e18d08c2b5698d74515eb40c1"
SignPk = "670ab3a47bc63ca4c55f0e507fab249576ec5fc2ab9af4ddfdad96a417feb932"

Leaving just bottom part: fails
Using just top part: succeeds

Thanks a lot for reporting this!
This has been fixed. Version 0.4 has been tagged and updated binaries are available for all platforms.
The test script was also changed to use two configurations instead of a hybrid one. I should have done that to start with :(

Testing with 0.4 binaries: no change in behavior: same errors (EOF respectively unexpected EOF) with separate configs.
With Hybrid config on -server it works ...

My bad. The code is good, the binaries are not. Went a bit too fast and forgot a git pull.
New binaries are being built as we speak.

Binaries have been updated.

New binaries confirmed working with separate configs on -server. Thank you very much.

Thank you!


Values stored as keys when using sub of sub

I'm getting values stored as keys when using sub, minimal example to reproduce:
let Hypercore = require('hypercore'); let Hyperbee = require('hyperbee'); let myCore = new Hypercore('/myCore2', {valueEncoding: 'utf-8'}) let myBee let a myCore.ready(async () => { 	console.log('core ready') 	myBee = new Hyperbee(myCore,{keyEncoding: 'utf-8', valueEncoding: 'binary'}) 	await myBee.ready() 	console.log('bee ready') 	let mySubBee = myBee.sub(myCore.key.toString('hex')) 	let mySubSubBee = myBee.sub('fe766f9a420f08c28f4c067fd7a5a01f86aa6e198e44dd68af1470c1db611c09') 	await mySubSubBee.put('e3e03a4a511d49a87468f13d1aa297081812d51e6138cfc70071d237a561a2c9','testvalue') 	await mySubSubBee.put('ca7bd4311e9d21e4c8d04162970998d715b8b92c92ee4ff434357f312647b401','anothertestvalue') 	for await (let val of mySubSubBee.createReadStream()){ 		console.log(val) 	}		 });
Gives:
{   seq: 2,   key: 'ca7bd4311e9d21e4c8d04162970998d715b8b92c92ee4ff434357f312647b401\x1A\x10anothertestvalue',   value: null } {   seq: 1,   key: 'e3e03a4a511d49a87468f13d1aa297081812d51e6138cfc70071d237a561a2c9\x1A\ttestvalue',   value: null }
I expected the value fields to be populated with testvalue and anothertestvalue

Can you clean up the formatting? A bit hard to read.

Can you clean up the formatting? A bit hard to read.

Done

was the key

let myCore = new Hypercore('/myCore2', {valueEncoding: 'utf-8'})

is wrong. Don't set the encoding on the core itself when using bee, as that'll corrupt it. Just do
let myCore = new Hypercore('/myCore2')


PPU sprites processing update

Increasing the maximum allowed sprites on a single scanline
extract a dedicated function for fetching sprite info on a specified line, fetch_sprite_info_on_specified_line()
Add a Y-order-list to avoid unnecessary sprite info scanning
Add dirty bit for oam_data to avoid unnecessary Y-order-list update.
simplify the OAM access with structure and bit-fields

Just for your information, I will push another PPU dedicated request in three days.
Cheers,
Gabriel

Maximum allowed sprites per line
merged it, but set default to 8 as the test roms would fail
Sprite optimisations
I like the idea. I'm not sure if it would change the behavior of emulation. The current test roms are ok with this, but I don't have a special sprite testing rom in my test cases.
Another point: My benchmark shows 4% decrease with this change. Do you see an improvement?
simplify the OAM access with structure and bit-fields
OK. Maybe jeg_cfg.h is not the right place to define _BV.

I believe this optimisation should improve the performance, and in fact, I have observed a 9% improvement on my side (440ms -> 401ms). If you check the scheme, it is obviously saving cycles. But I guess the x86 has some fansy optimisation which is affected by this low level changing, that’s why you see the 4% decreasing.
I usually put _BV in compiler.h, but I don’t want to make jeg depending on some external header file, so I put it in jeg_cfg.h (which is supposed to be included by all files of JEG)

This optimisation is an equivilant refactory, so the logic is actually the same. I believe it will not change the behaviour of emulation.

Added (temporary) flag to jeg_cfg.h: JEG_USE_OPTIMIZED_SPRITE_PROCESSING. Default is Enabled. Will remove the flag as soon as I've reviewed the changes and have the original performance back.

Removed includes of jeg_cfg.h in files where it is not used. Understand it now as _BV should be available everywhere. I'm thinking of using something like automake to create the jeg_cfg.h via ./configure script

Thank you. And do you still see the 4% performance decreasing?

Yes, still 4% depending on OPTIMZED_SPRITE_PROCESSING. Will look into this issue with a profiler.


Transit support

Is there interest in transit support for clj-http?

Closing this since Transit support was added in #215


Alternity 2017 (new sheet)

Changes / Comments
I have been working on a character sheet for the Alternity 2017 rule system and I want to submit it for use in roll20.net
Roll20 Requests
Include the name of the sheet(s) you made changes to in the title.
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

Is this a bug fix?
Does this add functional enhancements (new features or extending existing features) ?
Does this add or change functional aesthetics (such as layout or color scheme) ?
Are you intentionally changing more that one sheet? If so, which ones ?
If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

clicked this by accident, closing


MemDB with Random Replacement

This PR introduces a version of memdb with Random Replacement policy. This will ensure that the DB will not exceed a capacity (which is defined by the user of the cache). In the event that the capacity is exceeded, data will be randomly removed from the DB.
Motivation
The current memdb implementation can throw out of memory errors when the map runs out of in-memory storage. This implementation allows the user to specify a maximum number of entries that must be stored without replacement.

@divyakoshy what is the justification for using Random Replacement over LRU?


Getting error

  File "/home/username/Code/Whatsapp_Instagram_Messanger_ChatGPT_OpenAI/InstagramBot.py", line 8, in <module>
    from subprocess import CREATE_NO_WINDOW
ImportError: cannot import name 'CREATE_NO_WINDOW' from 'subprocess'

i am using Python3.9.16 , Zorin OS 16 (Ubuntu based)
Edit : i found this in documentation https://docs.python.org/3/library/subprocess.html#subprocess.CREATE_NO_WINDOW  does that mean it will only work in windows ???

the "CREATE NO WINDOW" constant is only available for Windows systems. You can remove the lines or comment them out.
"from subprocess import CREATE_NO_WINDOW" line 8
"self.service.creationflags = CREATE_NO_WINDOW" line 16.

Their purpose was just to prevent selinium from creating a terminal


Combine gen_truth_data.R And get_target_data.R

See comments here https://github.com/CDCgov/covid19-forecast-hub/pull/118#discussion_r1866671098

With some additional expressions, the contents of gen_truth_data.R and get_target_data.R (which both cover retrieval of NHSN COVID hospital admissions data) can be merged.


Development

Coverage increased (+0.09%) to 93.939% when pulling 58eee294a8165a5a9569b303ff4979d3e74c4654 on development into b7500d1fe50e260e609890a37cf58f9c9b14c081 on master.


OSX 10.11.5 Docker pull extremely slow from private registry for Mac only

I looked for existing issues, although some are similar, they are already closed in older versions, so I am creating this new one. Also so far this appears to be specific to my particular combination of OSX + Docker Toolbox (VBox VM + Docker engine) + private docker registry. Similar, but apparently different Issue to #13309 we have a "large" layer in the image I am trying to download (~3+GB).
When I say "slow" it took 6 hrs total time to download this one image. Colleagues on the same internal network downloaded to non-OSX hosts in only 20 minutes or less.
BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Tue Apr 26 23:44:17 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.11.1
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   5604cbe
 Built:        Wed Apr 27 00:34:20 2016
 OS/Arch:      linux/amd64

docker info:
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 2
Server Version: 1.11.1
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 21
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 4.4.8-boot2docker
Operating System: Boot2Docker 1.11.1 (TCL 7.0); HEAD : 7954f54 - Wed Apr 27 16:36:45 UTC 2016
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 9.746 GiB
Name: default
ID: ZAWT:UQY4:FC4N:7DAB:6QTB:BE73:HBJ3:EOBF:NXJW:DEGA:AVAG:ZUR3
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug mode (client): false
Debug mode (server): true
 File Descriptors: 12
 Goroutines: 32
 System Time: 2016-06-08T18:13:30.422397673Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox

uname -a:
Darwin *****-mbp.****.com 15.5.0 Darwin Kernel Version 15.5.0: Tue Apr 19 18:36:36 PDT 2016;
root:xnu-3248.50.21~8/RELEASE_X86_64 x86_64

Provide additional environment details (AWS, VirtualBox, physical, etc.):
Mac OSX 10.11.5, VirtualBox 5.0.20, Installed with Docker Toolbox
List the steps to reproduce the issue:

Using team's private registry, attempt to pull an image for the first time using docker-compose up
Image is composed of several layers, one layer in particular was around 3 GB in size.

Describe the results you received:
Pull of image takes approx. 6 hrs to complete
Describe the results you expected:
Colleagues on the same internal network tried to pull the same image from our registry
Windows Docker Toolbox host: ~20 min
Linux Docker host: ~13 min
Given the Macbook Pro is at least on par with the Windows host in terms of HW specs, would expect something similar.
Provide additional info you think is important:
Disk space does not appear to be an issue on either the Host or the docker-machine VM. (220 GB free)
It seemed as if some layers downloaded extremely rapidly, within a few seconds, but there was one layer of about 3GB in size, where the majority of time was spent. During the time I was waiting for the pull, I observed no significant activity either on CPU, memory or disk/io. Network I/O seemed to average around 100 KB/s received during this period, but I could download other files from FTP or web much faster.
Colleague was able to try to FTP from the private registry server and was getting around 3.0 MB/s download for a simple file transfer.
Not clear if there is some specific configuration required for Docker machine or VirtualBox for Mac?
----------END REPORT ---------

Can you open this issue in the Docker Toolbox or Docker Machine issue tracker? Looks like this it an issue with Toolbox. https://github.com/docker/toolbox/issues
Also, perhaps Docker for Mac (beta) would be worth a try; you can register for the beta at beta.docker.com


Sort stream service ports to avoid extra reloads

This fixes a bug where an Ingress controller would continuously reload its configuration if multiple TCP/UDP stream services were specified. This is caused by the list of ports not being sorted.

This change is

Coverage increased (+0.02%) to 46.145% when pulling bc96000360fbbc95811b767380f66c13061b6ed4 on williamsandrew:sort-upstream-ports into 5ab0f284b0d6d486bd31f5c59af94d5308fef98b on kubernetes:master.

@williamsandrew please sign the CLA

Sorry for the delay. CLA should be good now

@williamsandrew closing. The stream section is different now.


Work order edit

store all the field text in a dict
Load text from a dict and use a factory to initialize the class fields.
render the question list with a macro
have a generic template to edit question values
future refactor - remove all the if statements for address fields

Just leaving my notes here, as we discussed:
There's obviously a lot of smarts that can be pulled into the forms themselves, but it's probably more harm than good to do this before we need to.  I vote for sticking with what works for now, and adding extra abstraction when we know more about the real-world use cases, otherwise we risk adding complexity that just gets in the way.  There should be some refactoring when (if) more field types are ever needed.


PEAR-2001: Fix for  "isLoggedIn" is in the filters member when cohorts are saved

Description
Checklist

[N/A] Added proper unit tests
[N/A] Left proper TODO messages for any remaining tasks
[N/A] Scanned for web accessibility with aXe, and mitigated or documented
flagged issues

Screenshots/Screen Recordings (if Appropriate)

verified isLoggedIn is gone now. 👍


Updates babel-jest resolution

Summary
The babel-jest default transform is currently located through Resolver.findNodeModules. This has the inconvenient that when using a custom resolver, this new custom resolver will be completely  bypassed.
Given that require.resolve is the standard and safe way to obtain the requirable path to a package, I think we should use it whenever possible, at least until the custom resolver has been properly setup (ie after the config has been normalized).
Two notes:

This might be a slight breaking change if users were specifying different version of babel-jest than the default. I'm not sure it's often the case, so it doesn't feel too problematic.

The regenerator package is still located using Resolver.findNodeModules. It would be nice to fix this as well, but since this package is meant to be added by the user, only the user can use require.resolve to obtain its path (we can't use process.main because it points to the Jest cli). Since it's quite more complex, it can be done later on.

Test plan
I've updated the tests to match the behavior (ie mostly checked that the resulting configuration was matching whatever is returned by require.resolve rather than an hardcoded node_modules/babel-jest).

cc @mjesun @cpojer

I left a few comments. I think this will break resolution of custom transformers which we'll need to support. Can you fix that?

Are you rebased on master?

@SimenB Yep, rebased on master. My theory is that the current codebase has an issue with Node 8/9 that was hidden until now. The problem is on the following condition: https://github.com/facebook/jest/pull/5932/files#diff-8ee186ad0e07dceb57c11f7c7b5d072aR121
Before my commit, Jest was sometimes failing to locate babel-jest, probably because the tests were running inside a temporary directory. Due to this, the transpilation wasn't actually being ran at all, and the correct results were being returned on Node 8/9.
Starting from my commit, babel-jest is now always resolved (by using the one that Jest depends on), so the transpilation always run, and we apparently always hit the bug where the sourcemaps aren't correctly computed on Node 8/9.
What do you think?

Codecov Report

Merging #5932 into master will increase coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #5932      +/-   ##
==========================================
+ Coverage   64.33%   64.34%   +0.01%
==========================================
  Files         217      217
  Lines        8286     8286
  Branches        4        3       -1
==========================================
+ Hits         5331     5332       +1
+ Misses       2954     2953       -1
  Partials        1        1

Impacted Files
Coverage Δ

packages/jest-config/src/normalize.js
94.04% <100%> (+0.02%)
:arrow_up:

packages/jest-environment-jsdom/src/index.js
40% <0%> (+0.97%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1a51672...76adee3. Read the comment docs.

It's green now :man_shrugging:

Yeah, we discussed it with @mjesun and figured it would be good enough
until we get to make another PR to fix the sourcemap thing (since it seems
caused by something outside of the PR, and only affect projects that don't
have babel-jest available, which I'm not sure can happen under normal
circumstances), but if you feel otherwise let me know!
On Tue, Apr 10, 2018, 12:56 PM Simen Bekkhus<EMAIL_ADDRESS>wrote:

It's green now 🤷♂
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/facebook/jest/pull/5932#issuecomment-380226864, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA_WaxraZt_yxK5cEe7ggwRrLlMAmLvzks5tnQ5egaJpZM4TI25k
.

I'm not comfortable moving away from working sourcemaps, even though they might be working through a happy accident (working by accident is better than not working :D)
If you can tell me how the current approach is wrong with regards to sourcemaps, I'll be happy to remove my objection (to the degree it matters)

@SimenB this PR doesn't actually break the sourcemaps - they're already broken (in some extent). To reproduce, just create a new project with 23.0.0-alpha.5, add a testfile containing the following code, and run it. It will crash with an invalid column on Node 9 (but works on Node 6), printing 1 instead of 5:

    it('it', () => {});
    it('it foo');
    test('test bar');

I think the issue simply comes from babel just keeping track of the rows instead of rows+columns.

Is it just broken in the alphas (meaning master) or in the stable 22 releases as well?

I dont have good internet
ср, 11 апр. 2018 г., 0:27 Simen Bekkhus<EMAIL_ADDRESS>
Is it just broken in the alphas (meaning master) or in the stable 22
releases as well?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/facebook/jest/pull/5932#issuecomment-380252401, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Ajd4IL2rp3WEk2KYEH1To2RFvv0Oskx6ks5tnSPZgaJpZM4TI25k
.

@SimenB Not sure. Before the 23.0.0, not entering the test definition wasn't a hard error (it was just skipping the test altogether), and regular errors thrown from within the test definition don't seem to suffer from this issue in both 22.X and 23.X.

Possibly. Are you ok with this PR then?
On Wed, Apr 11, 2018, 12:18 AM Simen Bekkhus<EMAIL_ADDRESS>wrote:

Might mess up #5889 https://github.com/facebook/jest/pull/5889 as well,
then
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/facebook/jest/pull/5932#issuecomment-380352320, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA_Waw51GDgQ7U2m8Uc46uycY3ik0VLCks5tna4tgaJpZM4TI25k
.

👍

This does indeed mess up #5889 (I've rebased it), but just for the globals test (same one you had to strip out the line and column info in this PR). I think I'll have to dig into why this change makes us lose column information


Potential breaking changes for pyfar 1.0.0

Description
these breaking changes could be implemented at some point

[ ] Order of input arguments for fractional filter banks pyfar.dsp.filter.fractional_octave_bands gets sampling rate not at the end, which is the case everywhere else.

maybe also the Orientation class, #639


Change engine name to url

Hi! This "federated package specification" looks promising.
I noticed one thing: why are the engines also not an URL? It does not seem consistent with other aspects of the spec that are deemed important:

Package names are purely cosmetic
It's a packspec of "artifacts depending on artifacts", and those artifacts all 'live' at an URL
Consistency with the dependencies field

It however does seem consistent with package.json, where the engines are also just names instead of URLs
{
  "name" : "lspconfig", // OPTIONAL cosmetic name, not used for resolution nor filesystem locations.
  "description" : "Quickstart configurations for the Nvim-lsp client", // OPTIONAL
  "engines": {
      "https://github.com/neovim/neovim": "^0.10.0",
      "https://github.com/vim/vim": "^9.1.0"
  },
  "repository": { // REQUIRED
      "type": "git", // reserved for future use
      "url": "https://github.com/neovim/nvim-lspconfig"
  },
  "dependencies" : { // OPTIONAL
    "https://github.com/neovim/neovim" : "0.6.1",
    "https://github.com/lewis6991/gitsigns.nvim" : "0.3"
  },
}

Sorry if this is out of the question or does not make sense.

Engines as currently envisioned (i.e. until a strong case is made otherwise) are client-defined "modes". If the client supports the "nvim" engine then it knows how to install packages for nvim.
Clients must opt-in to supporting a presumably limited set of engines. Whereas URLs are treated by the client transparently.
Thus nothing is gained (afaict) by specifying engines as URLs.


Refactor parallel operation manager

Description
There is still a tiny chance that we will attempt to schedule some work twice, but this was never observed, so I am not making it part of #4629 .
In ParallelOperationManager we should figure out work to do under lock, set a property on the slot that we are processing it, and then leave the lock. Under the lock we should not read anything from the slots, just loop over the collections of work we got.
This way we avoid reading ShouldPreStart (or similar property) from 2 threads just at the wrong moment, where both threads will try to start the work.

fyi @cvpoienaru this should probably be done before re-enabling the pre-start. It is not a lot of work, just a small reshuffle.


Complex fixes in SDEs

Some fixes imported from https://github.com/patrick-kidger/diffrax/pull/418
(SDEs still do not pass all tests)

These look reasonable to me!
I just want to check which argument is being conjugated, though. There isn't a convention on which argument of a sequilinear form is conjugated. Ultimately this is a choice that we should (a) perform consistently across the whole ecosystem and (b) document carefully. I've just taken a quick look at Lineax and I think we're doing the right thing there too, but just wanted to check?

I was doing the first argument conjugation everywhere (that's what I'm used to). If nobody else added conjugations, we should be good.

Alright! First-argument conjugation it is :D


How do you ensure that people who annotate won't type the wrong label name?

For example, when you only have class car and license plate.
And people put the class as ca when annotating. What would this do?

Closing this because it's essentially the same as: https://github.com/tzutalin/labelImg/issues/239


Reduce queue table font and set minimum width

Description
This reduces the font size within the queue table. There's also now a minimum width on the table itself so that all columns will always be displayed, so any scrolling will be in the browser window, not within the table.
Reviewer Notes
How does the width work for you? I found 1000px was the sweet spot, but I'd like to know if that's the case for other folks.
Also, looks like my linter had some feelings on the CSS file. Is this ok?
Code Review Verification Steps

[ ] All tests pass.
[ ] There are no aXe warnings for UI.
[ ] This works in IE.
[ ] Request review from a member of a different team.
[ ] (TRIAL) Have the Pivotal acceptance criteria been met for this change?

References

Pivotal story #1 for this change
Pivotal story #2 for this change

Screenshots

I'm going to merge this shortly.


model training suddenly stops

i am training on aws instance on custom dataset , just added a custom experiment option in utils/datasets.py
    elif experiment == 'custom':
        train_dataset = MultiLabelDataset(root='/home/ec2-user/SageMaker/iccv19_attribute/images_data/',
                    label='/home/ec2-user/SageMaker/iccv19_attribute/data_list/custom/train.txt', transform=transform_train)
        val_dataset = MultiLabelDataset(root='/home/ec2-user/SageMaker/iccv19_attribute/images_data/',
                    label='/home/ec2-user/SageMaker/iccv19_attribute/data_list/custom/test.txt', transform=transform_test)
        return train_dataset, val_dataset, attr_nums['custom'], description['custom']

but model suddenly stops training on the first epoch without any messages

no error message? does the training start or not?

yes , trainig starts ,seems like that the code gets the hardware exhausted so suddenly training stops

yes , trainig starts ,seems like that the code gets the hardware exhausted so suddenly training stops

if cpu or gpu memory is exhausted, there might be some error message

if cpu or gpu memory is exhausted, there might be some error message


Unable to launch single kernel for bge-rerank-base model

Issue Description
Hi, I am trying to use MonoNN with bge-rerank-base model, but it doesn’t seem to take effect, my profiling result shows below.

I have tested MonoNN with the bert_base model following the provided example, and it works fine.
Steps to Reproduce

set up the environment for MonoNN
download the bge-rerank-base model
convert the onnx model to tensroflw .pb format:

pip install onnx-tf==1.10.0
onnx-tf convert -i BAAI/bge-reranker-base/onnx/model.onnx -o bge-reranker-base-tf

obtain the frozen graph following the instructions
the minimal code snippet can be found here.

Environment

Driver Version: 555.42.06
CUDA Version: 12.5
OS: Ubuntu 20.04.6

Thanks in advance for your help!

I’ve added a screenshot of the output from running the code snippet:

I’m not sure if the final line is the key issue. From my observations, it seems like MonoNN is not entering the key optimization phase and exits early. Could this be the root cause?


Statement without example (pending or otherwise)

If I am writing a spec, and just need to make a statement appear in my output, I believe my only option is to do something like:
it["As...."] = () => true.should_be_true();
it["I...."] = () => true.should_be_true();
it["So..."] = () => true.should_be_true();

Before I go further, I understand that nSpec isn't intended as a Gherkin-style BDD framework.  That's just an example.  The output should tell a story though, and many times you need to describe intent without running an example.
The output in this situation is fine, but it renders the example count useless.  The example count is only a useful metric when it's not augmented by these statement affirmations.  I'd like to get to work on adding a way to make a statement that isn't counted, but I'd like some guidance regarding the preferred implementation:
Should I add an action, similar to todo?
it["As..."] = stated;

or should I add an actionregister?
state["As..."] = stated;

or perhaps both, or something entirely different?  If I implemented this functionality would you be interested in pulling it in?

No activity. /cc @BrainCrumbz

The feature still seems interesting. I'd go with a new issue (!) targeted more specific to the feature request, poining at this current issue, and maybe just copying over your comment showing the steps for implementing the feature.

And then, of course, close this one :)


Sankey

Closes #788
Closes #896
Implements Sankey trace type

@nicolaskruchten @VeraZab Ready for review
I'm open to a better name for ColorArrayPicker - which is just a switch between a constant and an array color.

do we need to add a sankey.json for percy tests?

its weird, when I load a sankey, from the dev/json mock search: percy/sankey.json, I get:

The data selectors, don't show that data is inlined, but also no datasrcs appear in the panel

Yeah, I use inlined data and then data source names from test fixtures. That way the dropdowns usually get filled in percy. But yes, it's a hack...

yeah the inline thing seems to be brittle in ways that I don't fully understand :(

✨ once one change is made: please move links.labels to below links.values. My reasoning is that the absolute minimal data input for Sankey is link.{sources,targets,values} ... surprisingly nothing from node is strictly required (although we should keep node above link as it is now IMO)

Are you guys OK with the name ColorArrayPicker? We have too many color picker, I'm out of names...


A point of interest

It might pay to note the attention in the detail here.

You may use int main( void ) or int main() if you don't want your program to be able to accept and process command line arguments.

The difference between these two is subtle but significant, in that an implementation may require the (void) to explicitly specify no arguments, where-as int main() specifies an indeterminate number of arguments of indeterminate type. See for yourself:
int main() {
    return main("Man... This is so unconventional", 42.0, &main);
}

Since this doesn't actually declare a prototype for the function, I could reasonably see an implementation getting confused about which prototype to use, perhaps pushing some things to the stack which aren't meant to be pushed... Pass no arguments, or pass two arguments, or pass three (there's often an envp extension in Unix)? How does the linker decide? I suppose they could write logic to build that kind of expensive analysis into the linker, but the better option is to avoid the undefined behaviour.
So what is () good for, then? You'll notice most compilers won't even warn you when arguments are completely invalid... This works on ideone... as in, it compiles and runs...
unsigned int fubar();
int main(void) {
     fubar("hello", "world");
}
unsigned int fubar(unsigned int x, unsigned int y, unsigned int z) {
     return x ^ y ^ z;
}

Try it with (void) on the other hand and you'll most likely get compiler error after compiler error telling you not everything is so peachy! Using () fundamentally breaks all type checking in C, as though there was enough to begin with... They're not the same thing, that's for sure!

Please have a look at lessons/defining_main_lesson.txt.
/Matthew Campbell

What else do you think I'm commenting on? This kind of stuff here...

The main() function must return an integer value in every case

More specifically, main must return int, not just an integer.

You may use int main( void ) or int main()

... and I've already pointed out what's wrong with int main()... if there are any words there which you don't understand, why not ask about them rather than suggest I review this document which you haven't yet fixed?

you should add the following command line options when compiling your
programs: -pedantic -std=c11 -Wall if they are not already specified.

Curious if you add -Wstrict-prototypes to that, what do you get, hmmm? Try it... I did.

Owner@Core MINGW64 ~
$ cat strict_prototype_test.c
int main() { }

Owner@Core MINGW64 ~
$ gcc -pedantic -std=c11 -Wall -Wstrict-prototypes strict_prototype_test.c
strict_prototype_test.c:1:5: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
 int main() { }
     ^~~~

Not sure if you want your students to run into undefined behaviour and unstable issues with portability, but you know, it's best to be safe than sorry... right?

When I said integer I was merely spelling out the name of the data type in plain language.  No need to get so worked up over it.  I didn't specifically add any warning for strict prototypes and my code compiles just fine.  main() isn't normally prototyped anyway.
/Matthew Campbell

When I said integer I was merely spelling out the name of the data type in plain language.

Do you go by the standard? I mean... the standard says there are a few standard integer types... which one are you referring to? I presume int. You don't mean to say main returns long or long long, right? Because both of those are technically also integer types... then you've got the unsigned types, and size_t... main doesn't typically return size_t, right? That's an integer...

It may be worth pointing out that your main() function in your example did not do or return anything.

Please refer to C11/<IP_ADDRESS>.3p1 Program Termination for further details on what my program does. Here it is quoted, with some important bits emphasized in bold (by me) for your convenience:

If the return type of the main function is a type compatible with int, a return from the initial call to the main function is equivalent to calling the exit function with the value returned by the main function as its argument;11) reaching the } that terminates the main function returns a value of 0.

In your example about main(), those comma separated constants will likely be ignored and the address of the main() function will be returned to the operating system as the process' exit code.
/Matthew Campbell

My main point is to show you the devil in what you're doing. Beyond that, I don't really care what you do with that insight. Risk four hours hunting for some portability bug caused by four missing keystrokes for all I care... that only affects you, unless you try to teach others.

the address of the main() function will be returned to the operating system

Care to take another shot at that? The main function is invoking itself recursively. Supposing it ever returns, its return value (which has type int) is returned, not a function pointer. To return that function pointer I would have to sans the invocation and write return main;.

those comma separated constants

The arguments, you mean? Are there zero, one, or many arguments there? int main() { } declares a function with an indeterminate number of arguments of indeterminate type (as evidenced by the fact that you can call it with any number of argument of any type), and a linker can't see your source code, so do you suppose a linker will always know how to call it? Or might this be another one of those potential portability traps?


IGNITE-14501: Ignite 3: Fix toString implementations.

Ported "ToStringBuilder" with all dependant classes and related tests.
Removed deprecated code.
Originally used "Unsafe" to access class fields rewritten to VarHandles.
Implemented SystemProperyExtension for JUnit 5 to make annotation WithSystemProperty works.

Inspections failed on TC due to C-style code in CircularStringBuffer.
This requires either disabling inspection for this particular case or rewriting direct char[] array access to CharBuffer.


Improve debug representation of transactions

The current debug representation shows everywhere byte arrays and that makes it difficult to work with and compare with goal and other SDKs. With this PR hashes are displayed as base32 encoded strings and the signature as base64:
SignedTransaction {
    sig: Some(
        RQOF4OazISb9AMUtcr4A1F/mpph+JeLQVCGiCQymSeRxWukKzNZuSgJzMDRPixlswhHseXOuvgt8FJN2DGkGDQ==,
    ),
    multisig: None,
    logicsig: None,
    transaction: Transaction {
        fee: MicroAlgos(
            10000,
        ),
        first_valid: Round(
            9025,
        ),
        genesis_hash: 2YKA7K2Z5JDSTNMWHEC65NVL7UEL5TDUHFZQMLCBHWLYXPGSLQOA,
        last_valid: Round(
            9035,
        ),
        sender: GIZTTA56FAJNAN7ACK3T6YG34FH32ETDULBZ6ENC4UV7EEHPXJGGSPCMVU,
        txn_type: Payment(
            Payment {
                receiver: BFRTECKTOOE7A5LHCF3TTEOH2A7BW46IYT2SX5VP6ANKEXHZYJY77SJTVM,
                amount: MicroAlgos(
                    123456,
                ),
                close_remainder_to: None,
            },
        ),
        genesis_id: "tn50e-v1",
        group: None,
        lease: None,
        note: None,
        rekey_to: None,
    },
    transaction_id: "MMTXWOGGPCH6BISS5IXXZSYFFOL7AZKQRK3U3645RV52YF73XCLQ",
}

Also, separated from/to string in Account from the encoding/decoding, which seems a bit better.
I wonder whether we should make Account, Ed25519PublicKey, etc. contain HashDigest instead of [u8; 32]? Then we'd have to write the base32 debug representation only once. Account would override it as it uses base32 + checksum. Only issue I see against this is the assumption that they represent a hash, which can be considered an implementation detail of the system. But e.g. the group id is implemented as a hash..
Considered implementing Display instead, but it's a bit complicated/verbose when using Option, as it's not enough to implement it for the contained types.

Ah yes, it's the private key that's a hash (mostly). Anyway, at least Address shouldn't make assumptions about how the bytes were generated.


fix: Set default search_type to 'similarity' in as_retriever method of AzureSearch

Description
This PR updates the as_retriever method in the AzureSearch to ensure that the search_type parameter defaults to 'similarity' when not explicitly provided.
Previously, if the search_type was omitted, it did not default to any specific value. So it was inherited from AzureSearchVectorStoreRetriever, which defaults to 'hybrid'.
This change ensures that the intended default behavior aligns with the expected usage.
Issue
No specific issue was found related to this change.
Dependencies
No new dependencies are introduced with this change.

i.e. if you look at the default values in the __init__ of AzureSearch: https://python.langchain.com/api_reference/community/vectorstores/langchain_community.vectorstores.azuresearch.AzureSearch.html#azuresearch

Thank you for your comment, @efriis .
The intent of this PR is to align with the comment and documentation for search_type of as_retriever which states "Can be "similarity" (default), "hybrid", or "semantic_hybrid".
https://python.langchain.com/api_reference/community/vectorstores/langchain_community.vectorstores.azuresearch.AzureSearch.html#langchain_community.vectorstores.azuresearch.AzureSearch.as_retriever
As you've correctly pointed out, the default value of search_type is "hybrid". Therefore, I think we have two options: either merge this PR or update the comment and documentation.


Note in Quality Attributes

A note explaining the Quality Attributes' table must be done.

I have finished this task.


Rebase on current biocad master

This PR aims at getting the commits pushed since March 13, 2023 into our master repo

@teto is it good to merge?


Update parameter from manualLink to manualLinkUrl in Address Input component

What is the context of this PR?
104
As per the ticket tech notes, renamed the param name from manualLink to manualLinkUrl in the Address Input component and removed the default option.
Updated _macro-options.md file
BREAKING CHANGES

Description of change: manualLink parameter is renamed manualLinkUrl

Reason for change: This update helps to standardise the parameter names within the project.

Migration steps:

Locate all instances of the manualLink parameter in the Address Input component
Replace manualLink with manualLinkUrl.

Click for example
    OLD
    {{
        onsAddressInput({
             "manualLink": "Example-manual-link"
        })
    }}

    NEW
    {{
        onsAddressInput({
            "manualLinkUrl": "Example-manual-link"
        })
    }}

How to review this PR
Describe the steps required to test the changes (include screenshots if appropriate).
Checklist
This needs to be completed by the person raising the PR.

[x] I have selected the correct Assignee
[x] I have linked the correct Issue

The description needs updating with steps to test this


Add a variant field to the league and include the variant in the registration form information

rating_type is not enough to determine the type of chess that's being played, unfortunately. We should allow for a variant field as well and use it when asking the form question.

i believe this is already fixed.


Categorical model cov names in mrbrt

Don't think this is a problem, for MRBRT if we need the number of variables, we have num_vars attribute, and num_covs only refer to the number of covariates that are in the model. Will close this issue for now @n-gilbertson, until we find more details on this problem.


round trip time slowly increases?

If you checkout a fresh copy of yojimbo and add the following to the end of the while() loop in the loopback.cpp example, you'll see the round trip time value increases slowly (screenshot attached)
NetworkInfo networkInfo;
client.GetNetworkInfo(networkInfo);
printf("RTT: %f\n", networkInfo.RTT);

(This is running on windows btw)
Max

Also worth mentioning that by "fresh copy", I mean yojimbo master w/o the latest commit that updates submodules because the latest versions of netcode.io and reliable.io break yojimbo.

Yeah I gotta fix that

Glenn

On Apr 6, 2018, at 5:32 PM, Max Weisel<EMAIL_ADDRESS>wrote:
Also worth mentioning that by "fresh copy", I mean yojimbo master w/o the latest commit that updates submodules because the latest versions of netcode.io and reliable.io break yojimbo.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

So the client_server.cpp sample seems to remain constant, but it sticks at 600ms with the default deltaUpdate time of 100ms. Any idea what's up with that? I'd expect 100 or 200ms, but not 600ms.
Max

Worth mentioning that I'm trying to write some code that will give me a timestamp on all clients that's roughly in sync with the server. My plan was to have the server send its timestamp on connect, then subtract half of the roundtrip time from that.

Weird

Glenn

On Apr 6, 2018, at 7:48 PM, Max Weisel<EMAIL_ADDRESS>wrote:
So the client_server.cpp sample seems to remain constant, but it sticks at 600ms with the default deltaUpdate time of 100ms. Any idea what's up with that? I'd expect 100 or 200ms, but not 600ms.
Max
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

I'll keep digging... Let me know if you think of what could be wrong. I'll make a fix and submit a PR.
Max

I'm not sure the above is correct. The acks should be measuring actual network latency from a client to the server and back, it's difficult to see how the client_server.cpp loopback test should have an effective latency of 600ms, so my bet is that the RTT calculation is broken.
I guess I should take a look this weekend.

reliable.io sends a packet with a timestamp, the server sends this timestamp back in the corresponding ack, and then the client compares how old the timestamp is to its current clock. However, since acks are so heavily delayed, the round trip time calculation is always off.

It doesn't actually work this way. No timestamp is sent over the network by reliable.io, only sequence numbers. The client stores its local sequence # per-timestamp at time of send, and compares with the timestamp when received, and that is what it considers the RTT to be.
Are you saying that the server is basically acking blocks of packets, so in your case, it's getting an ack for the old n frames as well as the most recent feeding in and causing this? That sounds like the most likely culprit to me, and fixing that should be easy, eg. only do RTT calculation on the most recent ack in a packet...

Even if the timestamp is cached locally, the issue is that the sequence numbers in each ack are delayed. When the server receives sequence 0, the ack 0 message doesn't go out in the same or even next SendPackets()/ReceivePackets() loop.
If you turn on debug logging in the client_server example and add a log at the beginning/end of the while loop, you'll see something like this: (I've stripped some of the excess messages)
[client/server]
started server
client started on port 53847
client connecting to server <IP_ADDRESS>:40000 [1/1]

Run loop began begin
client sent connection request packet to server
server received connection request from <IP_ADDRESS>:53847
server sent connection challenge packet
Run loop ended. Current RTT: 0.000000

Run loop began begin
client received connection challenge packet from server
client sent connection response packet to server
server accepted client <IP_ADDRESS>:53847 b2894f3ebf089be5 in slot 0
Run loop ended. Current RTT: 0.000000

Run loop began begin // Packet 0 goes out here
[server endpoint] sending packet 0 without fragmentation
[client endpoint] sending packet 0 without fragmentation
client connected to server
Run loop ended. Current RTT: 0.000000

Run loop began begin
[server endpoint] sending packet 1 without fragmentation
[client endpoint] sending packet 1 without fragmentation
[client endpoint] processing packet 0
[client endpoint] process packet 0 successful
Run loop ended. Current RTT: 0.000000

Run loop began begin
[server endpoint] sending packet 2 without fragmentation
[client endpoint] sending packet 2 without fragmentation
[server endpoint] processing packet 1
[server endpoint] process packet 1 successful
[client endpoint] processing packet 1
[client endpoint] process packet 1 successful
Run loop ended. Current RTT: 0.000000

Run loop began begin // Ack 0 is received here
[server endpoint] sending packet 3 without fragmentation
[client endpoint] sending packet 3 without fragmentation
[server endpoint] processing packet 2
[server endpoint] process packet 2 successful
[server endpoint] acked packet 0
 // This is my own log that prints the RTT for a single packet right when it arrives (instead of the average)
Received Packet! RTT: 600 - current endpoint time: 101.000000 - packet time:100.400000
[client endpoint] processing packet 2
[client endpoint] process packet 2 successful
Run loop ended. Current RTT: 0.000000

Run loop began begin
[server endpoint] sending packet 4
[server endpoint] sending packet 4 without fragmentation
[client endpoint] sending packet 4
[client endpoint] sending packet 4 without fragmentation
[server endpoint] processing packet 3
[server endpoint] process packet 3 successful
[server endpoint] acked packet 1
packet rtt: 0.600000 - endpoint time: 101.200000 - packet time:100.600000
[client endpoint] processing packet 3
[client endpoint] process packet 3 successful
[client endpoint] acked packet 1
packet rtt: 0.600000 - endpoint time: 101.100000 - packet time:100.500000
Run loop ended. Current RTT: 600.000000

One other note for clarity: the client_server example still connects over local sockets instead of using the loopback APIs in yojimbo. The loopback example has its own problems with growing RTT time.
client_server stays constant, but the RTT calculation is much larger than your ping + deltaTime would be due to acks going out several send/receive loops later.

Seems like a bug.
On Tue, Apr 17, 2018 at 1:38 PM, Max Weisel<EMAIL_ADDRESS>wrote:

One other note for clarity: the client_server example still connects over
local sockets instead of using the loopback APIs in yojimbo. The loopback
example has its own problems with growing RTT time.
client_server stays constant, but the RTT calculation is much larger than
your ping + deltaTime would be due to acks going out several send/receive
loops later.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/networkprotocol/yojimbo/issues/82#issuecomment-382133898,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAqhUGq5JDZvgMn7Y-jRxZrTrNeC2PR9ks5tplLUgaJpZM4TK0QI
.

Let me know if you think of what might be causing it. I keep looking into how reliable.io does its acks and haven't come up with anything.

On Tue, Apr 17, 2018 at 2:14 PM, Max Weisel<EMAIL_ADDRESS>wrote:

Let me know if you think of what might be causing it. I keep looking into
how reliable.io does its acks and haven't come up with anything.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/networkprotocol/yojimbo/issues/82#issuecomment-382148879,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAqhUJMkE9s2pJ-RfHCGoX9vm-Z4f5LBks5tpltQgaJpZM4TK0QI
.

I can confirm that when reliable.io does the rtt calculation for a single packet, it comes back incorrectly, which rules out the math that does the averaging in yojimbo. And the calculation in reliable is just (send_time - current_time), so I don't think the math is wrong.
It's definitely due to these ack messages coming in several Send/Receive loops later. And from the looks of it reliable.io is responsible for deciding when these acks are sent out.

I've been working on another bug and found that the delayed acks actually cause yojimbo to send most reliable messages multiple times too.
If you add this line to the Serialize template on TestMessage you can see it in action:
yojimbo_printf(YOJIMBO_LOG_LEVEL_INFO, "Serialize test message (ReadStream: %i, MeasureStream: %i, WriteStream: %i)", std::is_same<Stream, Yojimbo::ReadStream>::value, std::is_same<Stream, Yojimbo::MeasureStream>::value, std::is_same<Stream, Yojimbo::WriteStream>::value);
You'll get logs similar to this for all clients that have a ping time above 15ms:
Log: SendMessage(TestMessage) Log: Serialize test message (ReadStream: 0, MeasureStream: 1, WriteStream: 0) Log: Serialize test message (ReadStream: 0, MeasureStream: 0, WriteStream: 1) Log: Serialize test message (ReadStream: 0, MeasureStream: 0, WriteStream: 1) Log: Serialize test message (ReadStream: 0, MeasureStream: 0, WriteStream: 1)
I have a production app that uses yojimbo. I see this behavior for all reliable messages that we send to clients with a ping time above 15ms.
I haven't dug too much more, but I imagine this also means yojimbo uses about 3x the bandwidth when sending reliable messages. I'm still deep on another bug, but will let you know when I get more time to look into this one.
Max

That makes sense. Yojimbo is currently setup to resend unacked reliable
messages every 10th of a second.
You can change this in the reliable channel config to make it resend
unacked messages less frequently.
On Mon, Apr 23, 2018 at 1:47 PM, Max Weisel<EMAIL_ADDRESS>wrote:

I've been working on another bug and found that the delayed acks actually
cause yojimbo to send most reliable messages multiple times too.
If you add this line to the Serialize template on TestMessage you can see
it in action:
yojimbo_printf(YOJIMBO_LOG_LEVEL_INFO, "Serialize test message
(ReadStream: %i, MeasureStream: %i, WriteStream: %i)", std::is_same<Stream,
Yojimbo::ReadStream>::value, std::is_same<Stream, Yojimbo::MeasureStream>::value,
std::is_same<Stream, Yojimbo::WriteStream>::value);
You'll get logs similar to this for all clients that have a ping time
above 15ms:
Log: SendMessage(TestMessage) Log: Serialize test message (ReadStream: 0,
MeasureStream: 1, WriteStream: 0) Log: Serialize test message (ReadStream:
0, MeasureStream: 0, WriteStream: 1) Log: Serialize test message
(ReadStream: 0, MeasureStream: 0, WriteStream: 1) Log: Serialize test
message (ReadStream: 0, MeasureStream: 0, WriteStream: 1)
I have a production app that uses yojimbo. I see this behavior for all
reliable messages that we send to clients with a ping time above 15ms.
I haven't dug too much more, but I imagine this also means yojimbo uses
about 3x the bandwidth when sending reliable messages. I'm still deep on
another bug, but will let you know when I get more time to look into this
one.
Max
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/networkprotocol/yojimbo/issues/82#issuecomment-383717446,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAqhUGIDIyjPLeEEpL74xOT88HmCrxM5ks5trj3jgaJpZM4TK0QI
.

Now that I think about it, every 10th of a second would be 100ms. I'm seeing this bug with people who have a ping <50ms and with our server running with a run loop time of 10ms. The default message resend time seems ideal for us, but because round trip times are 600ms even when both client/server are running on the same machine, every reliable message fails the message resend time test.

This sounds crazy. Why isn't everybody else seeing this behavior?
On Mon, Apr 23, 2018 at 2:53 PM, Max Weisel<EMAIL_ADDRESS>wrote:

Now that I think about it, every 10th of a second would be 100ms. I'm
seeing this bug with people who have a ping <50ms and with our server
running with a run loop time of 10ms. The default message resend time seems
ideal for us, but because round trip times are 600ms even when both
client/server are running on the same machine, every reliable message fails
the message resend time test.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/networkprotocol/yojimbo/issues/82#issuecomment-383735419,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAqhUIs8qo-mbUoAzpJU35aKQKGmSknKks5trk1igaJpZM4TK0QI
.

I imagine they are seeing this behavior... That said, resending packets has no noticeable effect on anything other than bandwidth usage, so I doubt anyone has noticed. And given that the bandwidth stats are averaged over a few seconds, unless someone is sending a constant stream of reliable updates, this bug wouldn't be apparent in those stats either.

I think most people assume that if things are getting through, the system is working perfectly.

Maybe we should do a consult. I'm happy to look into this specific bug for
you, and it probably won't take a lot of time, but I have to prioritize
paid work for my company first.
Would you like me to look into this as paid work? I'm sure it would only
take a few hours.
cheers

Glenn

On Mon, Apr 23, 2018 at 3:00 PM, Max Weisel<EMAIL_ADDRESS>wrote:

I think most people assume that if things are getting through, the system
is working perfectly.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/networkprotocol/yojimbo/issues/82#issuecomment-383736927,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAqhUCuHrygV2iHoqaryeOaWGFioFZEfks5trk76gaJpZM4TK0QI
.

No worries. I'm not in a huge rush over here. I'll add it to my list and fix it down the road.
Apologies if these bug reports are getting annoying btw. I figured it would be helpful to write up my findings as I go in case anything stuck out to you. Happy to keep quiet until I have PRs ready for each bug that I find.
Max

Not annoying. Just don't have a lot of time to investigate right now.
cheers

Glenn

On Mon, Apr 23, 2018 at 3:38 PM, Max Weisel<EMAIL_ADDRESS>wrote:

No worries. I'm not in a huge rush over here. I'll add it to my list and
fix it down the road.
Apologies if these bug reports are getting annoying btw. I figured it
would be helpful to write up my findings as I go in case anything stuck out
to you. Happy to keep quiet until I have PRs ready for each bug that I find.
Max
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/networkprotocol/yojimbo/issues/82#issuecomment-383745114,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAqhUE1OVq3FiUqBOIcJGvk-xefK_f8kks5trlfpgaJpZM4TK0QI
.

I also have a server and client on the same computer running and with the app at 60FPS, I have around 70ms as RTT. I would expect 16ms to 33ms... Any thought ?

Last I looked into this, it's caused by reliable.io resending all reliable packets three times. Unfortunately, I didn't have time to dig into the root cause and had to write my own rtt calculation.

Friends, it seems like there is a bug here. RTT should work properly. I'm super slammed with my new startup, but it would be great if somebody could investigate this, and then we could get a new release out with all the fixes!
Thanks

@gafferongames @maxw I am really new at yojimbo but I tried your problem on my local machine on mac. With loopback.cpp example it gives exactly your output but I think that example is wrong because it is advancing the client time before server. If we cut the client.AdvanceTime( time );  and paste it after server.AdvanceTime( time ); it works properly and gives 200ms always. I tried it with secure server and secure clients, it works normal with delta_time 0.1 it gives 200 with delta_time 1/60 it gives 33.891ms. As I said before I am really new in yojimbo and my bold assumption is check client.AdvanceTime( time ); for rtt problem. I think it is important for calculating RTT. I hope it helps you.

Yes, you need client.AdvanceTime!

This fixes the loopback client, but does it fix the client_server example for you? For my most recent tests, I was running client / server in separate processes on the same machine...

Hi @maxw let me show you examples. In the usage.md file there is a paragraph about that.
In the Update method, there are 3 methods of the Server class that you need to call: AdvanceTime, ReceivePackets and SendPackets. Note that the order is very important. Using another order might add a couple frames of delay to your server's latency. Here is what it looks like:
I think this paragraph is valid for client loop too.
`
void GameServer::Update(float dt) {
// stop if server is not running
if (!m_server.IsRunning()) {
m_running = false;
return;
}
// update server and process messages
m_server.AdvanceTime(m_time);
m_server.ReceivePackets();
ProcessMessages();

// ... process client inputs ...
// ... update game ...
// ... send game state to clients ...

m_server.SendPackets();

}
`
And there is my server.cpp
`
#include "pch.h"
#include "yojimbo.h"
#include <signal.h>
#include <time.h>
#include "shared.h"
using namespace yojimbo;
static volatile int quit = 0;
void interrupt_handler(int /dummy/)
{
quit = 1;
}
int ServerMain()
{
printf("started server on port %d (insecure)\n", ServerPort);
double time = 0;

ClientServerConfig config;

uint8_t privateKey[KeyBytes];
memset(privateKey, 0, KeyBytes);

Server server(GetDefaultAllocator(), privateKey, Address("<IP_ADDRESS>", ServerPort), config, adapter, time);

server.Start(MaxClients);

char addressString[256];
// ReSharper disable once CppExpressionWithoutSideEffects
server.GetAddress().ToString(addressString, sizeof(addressString));
printf("server address is %s\n", addressString);

const double deltaTime = 0.1;

signal(SIGINT, interrupt_handler);

while (!quit)
{
	server.AdvanceTime(time);
	server.ReceivePackets();

	server.SendPackets();

	time += deltaTime;

	if (!server.IsRunning())
		break;

	yojimbo_sleep(deltaTime);
}

server.Stop();

return 0;

}
int main()
{
printf("\n");
if (!InitializeYojimbo())
{
	printf("error: failed to initialize Yojimbo!\n");
	return 1;
}

yojimbo_log_level(YOJIMBO_LOG_LEVEL_INFO);

srand((unsigned int)time(NULL));

int result = ServerMain();

ShutdownYojimbo();

printf("\n");

return result;

}`
Client.cpp
`#include "pch.h"
#include "yojimbo.h"
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <inttypes.h>
#include <time.h>
#include <signal.h>
#include "shared.h"
using namespace yojimbo;
static volatile int quit = 0;
void interrupt_handler(int /dummy/)
{
quit = 1;
}
int ClientMain(int argc, char* argv[])
{
printf("\nconnecting client (insecure)\n");
double time = 0;

uint64_t clientId = 0;
random_bytes((uint8_t*)&clientId, 8);
printf("client id is %.16" PRIx64 "\n", clientId);

ClientServerConfig config;

Client client(GetDefaultAllocator(), Address("<IP_ADDRESS>"), config, adapter, time);

Address serverAddress("<IP_ADDRESS>", ServerPort);

if (argc == 2)
{
	Address commandLineAddress(argv[1]);
	if (commandLineAddress.IsValid())
	{
		if (commandLineAddress.GetPort() == 0)
			commandLineAddress.SetPort(ServerPort);
		serverAddress = commandLineAddress;
	}
}

uint8_t privateKey[KeyBytes];
memset(privateKey, 0, KeyBytes);

client.InsecureConnect(privateKey, clientId, serverAddress);

char addressString[256];
// ReSharper disable once CppExpressionWithoutSideEffects
client.GetAddress().ToString(addressString, sizeof(addressString));
printf("client address is %s\n", addressString);

const double deltaTime = 0.1;

signal(SIGINT, interrupt_handler);

while (!quit)
{

	client.AdvanceTime(time);
	client.ReceivePackets();

	NetworkInfo network_info;
	client.GetNetworkInfo(network_info);
	printf("RTT is %f\n", network_info.RTT);

	client.SendPackets();
	time += deltaTime;

	if (client.IsDisconnected())
		break;

	if (client.ConnectionFailed())
		break;

	yojimbo_sleep(deltaTime);
}

client.Disconnect();

return 0;

}
int main(int argc, char* argv[])
{
if (!InitializeYojimbo())
{
printf("error: failed to initialize Yojimbo!\n");
return 1;
}
yojimbo_log_level(YOJIMBO_LOG_LEVEL_INFO);

srand((unsigned int)time(NULL));

int result = ClientMain(argc, argv);

ShutdownYojimbo();

printf("\n");

return result;

}
`
I tested this in Windows 10 machine and my results are changing between 100  - 103 ms on mac it is almost stable 100ms.

I think results are pretty acceptable. I am gonna create a tutorial about creating secure server and secure client aswell -If I can found time I am gonna make video too-. When I finish it I can share with you guys


Hello everyone, "profile lookup" problem works correctly with ony one record from arrays, but not for other records. Help

Profile lookup, problem 216

Challenge Name

"Profile Lookup challenge"
Issue Description

My code works correctly for one record from the nested array of records in the problem, i.e. record of "Kristian", but for the other records, it returns undesired results.
Browser Information

Browser Name, Version: Mozzila Firefox, Chromium
Operating System: Arch Linux
Mobile, Desktop, or Tablet:

Your Code

var contacts = [
    {
        "firstName": "Akira",
        "lastName": "Laine",
        "number": "0543236543",
        "likes": ["Pizza", "Coding", "Brownie Points"]
    },
    {
        "firstName": "Harry",
        "lastName": "Potter",
        "number": "0994372684",
        "likes": ["Hogwarts", "Magic", "Hagrid"]
    },
    {
        "firstName": "Sherlock",
        "lastName": "Holmes",
        "number": "0487345643",
        "likes": ["Intriguing Cases", "Violin"]
    },
    {
        "firstName": "Kristian",
        "lastName": "Vos",
        "number": "unknown",
        "likes": ["Javascript", "Gaming", "Foxes"]
    }
];
function lookUpProfile(first, prop)
{
var val;
  for (var i=0; i<contacts.length; i++)
    {
      val = "";
      if (!contacts[i].prop)
          val = "No such property";
      if(contacts[i].firstName == first)
        {
          if(contacts[i][prop])
          {
            if(prop == "likes")
            {
              val ="[\""+contacts[i].likes[0];
              for(var k =1; k<contacts[i].likes.length; k++)
              {
            val +=(",\""+contacts[i].likes[k]+"\"");
              }
            val +="]";
              }
          else
            val = contacts[i][prop];
          }
        }
      else
            val = "No such contact";
    }
return val;
}
lookUpProfile("Akira", "likes");

![screenshot_20170601_130504](https://cloud.githubusercontent.com/assets/16181876/26677215/371ccd8e-46cb-11e7-8cf5-76de430c3ffe.png)
![screenshot_20170601_130603](https://cloud.githubusercontent.com/assets/16181876/26677214/3716e8b0-46cb-11e7-9c6d-754490a15fb9.png)

Screenshot

Oops, my bad, I'm closing it now.


Accessing DUNE computing from Windows

https://dune.github.io/computing-training-basics/putty.html has a nice description of how to set up putty to access FNAL computers from Windows.
From Roger Huang, LBNL

Has anyone tried mobaXterm? Far superior to PuTTy.

MobaXterm is a very powerful suite of network tools for Windows, which includes X11, ssh, sftp and tunneling, and much more. The free version will be enough for most people. I recently upgraded to the Pro version, which lifts the limit on how many configurations and tunnels you can use.


Expose Movies Path to Blueprints to change change video played at Runtime

How would I go about exposing the classes to blueprint so we can change MoviePaths to DefaultScreen struct at Runtime? I'm trying to have it so through blueprints that it can change the moviepaths, so when I make a change to level, a cutscene will play out instead of a static array we set in the Project Settings.
I was able to expose the structs and variables, but I'm unable to expose Loading Screen as a reference so I can plug it into the target node.

Yes, it would be nice to be able to change things like that or the array with "tips" in runtime.

Actually, since I posted this, I have made the Loading system accessible through blueprints with the ability to change any settings at any moment at runtime. I might clean up the code and push it to the repository!

That would be very welcome.


Fix field name and suffix separation

This fixes #294. Deeply nested field references will now work properly if the field name starts with raw. The field name and the suffix are now separated with a regular expression instead of removing every occurrence of _raw in the key with key.name.replace('_raw', '').
const contentType = store.addContentType({
  typeName: 'TestPost',
  route: '/:foo__rawValue'
})

const node = contentType.addNode({
  fields: {
    foo: {
      rawValue: 'BAR'
    }
  }
})

console.log(node.path) // Output: '/bar'

Every element of the routeKeys array now has an additional suffix property that holds either the value of the suffix or null if the key doesn't have any suffix.

Thanks again! Looks like a good solution :)


How to concatenate firstname and lastname in one column?

How do I concatenate firstname and lastname in one column? and show as Name column.

In the example  it covers how to change the supplied data into all uppercase. This should easily be changed into a simple concatenation.


feat: Implement a Test-Suite for Pull-Requests

/kind feature
Describe the solution you'd like
The current changes that will be merged with a PR are not being tested.
This should be improved.
Anything else you would like to add:
Maybe something like using Taskfile and Github Actions  which will prov. a KinD cluster and bootstrap everything with frigg bootstrap capd cluster
Environment:

Cluster-api-provider-vsphere version:
Cluster-api-provider-azure version:
Cluster-api-provider-docker version:
Cluster-api-provider-harvester version:
Cluster-api-provider-proxmox version:
cluster-api-provider-vcluster version:
Kubernetes version: (use kubectl version):
OS (e.g. from /etc/os-release):

This feature is currently on hold, because we should implement a much easier and simpler way to test the cluster creation.
We dont need every step from the default capd-controller command, instead we should implement another cli command only used by the github actions.


Add option to always display alpha and fix vec4 alpha to always be float

Just as the title says 😄

Currently when alpha is 1, it is not outputted -> Newly added settings toggle can force to always output alpha.
Currently when alpha is 1 and it is outputted it stays 1 which is a no go for vec4 -> thus this pull also addresses to always output float 1.0 in this case.

Looks good, @kroko. Thanks!

https://github.com/thomaslindstrom/color-picker/commit/7f95eb5e7b0ac685c3e4f0cd5857c0d52e87297a

thanks for the merge!


Feature request: API endpoint for sending

When building apps on frameworks like Next.js and Remix.run for platforms like Vercel and Cloudflare Pages, people tend to use services which offer a HTTP integration like Resend, SendGrid, Postmark, etc. as SMTP support is tricky (e.g. running nodemailer doesn't necessarily work).
Mailpit has a great HTTP API, however there is no endpoint for sending email. Adding one would make it easy to send test emails from these platforms.
As a bonus, offering API-compatibility with the most popular services like SendGrid, Resend, Postmark, Mailgun, AWS SES, etc. would mean that in development users could re-use the same code.

Firstly, thank you for your contribution @ryan0x44. This has been discussed in #167 where I actually rejected the idea which also proposed a mock-api of these various services. This was primarily because these services all offered different implementations & features for their APIs, so there was no one-shoe fits all, and I just did not intend on trying to maintain a separate set of ever-changing APIs and have to reverse-engineer each one.
Please note that this is just to open up a conversation to try understand the problem better, and not to reject your idea....
You say "offering API-compatibility with the most popular services like", but is it? I'm asking purely on the assumption that you have more experience than I do with these services. Looking at a couple of them now again, I see:
Mailpit (as proposed by your PR)
{
    "from"<EMAIL_ADDRESS>    "to": [
<EMAIL_ADDRESS>    ],
    "subject": "hello",
    "bodyHTML": "Hello",
    "bodyText": "Hello"
}

Sendgrid
{
    "personalizations": [
        {
            "to": [
                {
                    "email"<EMAIL_ADDRESS>                    "name": "John Doe"
                }
            ],
            "subject": "Hello, World!"
        }
    ],
    "content": [
        {
            "type": "text/plain",
            "value": "Heya!"
        }
    ],
    "from": {
        "email"<EMAIL_ADDRESS>        "name": "Sam Smith"
    },
    "reply_to": {
        "email"<EMAIL_ADDRESS>        "name": "Sam Smith"
    }
}

Resend
{
    "from": "Acme<EMAIL_ADDRESS>    "to": [
<EMAIL_ADDRESS>    ],
    "subject": "hello world",
    "html":"Hello",
    "text": "it works!",
    "headers": {
        "X-Entity-Ref-ID": "123"
    }
}

Mailgun uses multipart/form-data
Postmark has different APIs for sending single and batch emails
etc etc

My point is they are all very different, and all of these support far more than just a text & html part (eg: attachments, headers, cc, bcc, reply-to etc).
So to come back to my questions:

How does this offer "API-compatibility" with any of those services? Do you just mean that Mailpit would also offer a HTTP API to send (or rather in this case receive) email (in which case we really cannot say "API-compatibility")?
Assuming it is just another HTTP API, wouldn't this mean that an application would need a separate set of "sending instructions" to test with, ie: a separate library etc? How would developers be expected to handle this?
I believe that any HTTP API to do this, no matter how simple, requires a lot more flexibility and features (eg: Cc, Bcc, headers and attachments). I'm not proposing you change your PR yet as I think there is likely a far better approach (assuming I do add a HTTP sending API) to build the message as your implementation is fairly hard-coded (ie: requires both a HTML and text body) - it does however provide a foundation to work from.

Hey thanks @axllent for the thoughtful response!
On reflection I think you're right that it wouldn't make sense to try and support all of the different APIs necessarily. It would be a huge amount of work to build and maintain.
That said, I do see it as crucial functionality to offer some kind of HTTP API for sending messages. In my context I basically can't use mailpit without it (or running some kind of proxy).
I think my PR has a couple of improvements that could be made (e.g. I don't think the correct headers are being set), but it's working well enough that I can see the subject and HTML/Text body of the emails in development now. Keen to get some eyes and feedback on that, and would be happy to try and get it well-formed enough for a merge! (assuming you're ok with adding that basic functionality?)

Thanks @ryan0x44. I do understand now (better) the merit of such a feature, and have been giving this a fair bit of thought in the last week. I guess where my confusion lies is in the requirement, if any, to align the Mailpit HTTP API with any of the others (eg: those previously mentioned), or whether, from a developer's perspective, it actually doesn't matter?
What I am hesitant about is adding a HTTP API (regardless how), and users not being able to use it because it doesn't align with their chosen "SMTP" provider's HTTP API (ie: their app's current functionality). If it is common for developers to just switch out the library (or rather have a testing fallback library) when testing, then this is a non-issue - your feedback is welcome as I have no idea!
As part of my thought process over the last week, I thought it may be possible to eventually create "simplified versions" of some of the more common APIs, "mapping" the posted data to the supported Mailpit API. This way at least they could theoretically send using their existing library (assuming it allowed the API URL to be changed to Mailpit's), though maybe not all features are supported. This would be a secondary feature once I knew the Mailpit API was stable.
So the real question I have is, in your opinion, is having a different API to  an issue for developers in your situation? If not, is it normal for JS developers to have separate library packaged for testing, and if so, how would a developer go about switching between the two? I am just trying to get a better understanding.
As a secondary question, if/when Mailpit would get this functionality, would you be willing to create and maintain a JS library for this, or do you think it's not necessary? Again, I don't know what JS developers prefer in these situations.
As a final thought, I would likely be looking at implementing it with the structure of something like Resend as this seems flexible enough, although using arrays more for addresses (including separate name & email fields), attachments etc - and thus the email generation (in Mailpit) would be very different to what you created. Don't worry, I am not asking (or wanting) you to modify what you have, I will do that work as it'll need to fit into the bigger picture of what I have potentially planned. Please leave your PR as-is for now as I can use that for reference.

This is what I have come up with so far in developmen:
{
  "From": {
    "Email"<EMAIL_ADDRESS>    "Name": "John Doe"
  },
  "To": [
    {
      "Email"<EMAIL_ADDRESS>      "Name": "Jane Doe"
    }
  ],
  "Cc": [
    {
      "Email"<EMAIL_ADDRESS>      "Name": "Manager"
    }
  ],
  "Bcc": [
    {
      "Email"<EMAIL_ADDRESS>      "Name": "Jack Black"
    }
  ],
  "ReplyTo": [
    {
      "Email"<EMAIL_ADDRESS>      "Name": "Secretary"
    }
  ],
  "Tags": [
    "Tag 1",
    "Tag 2"
  ],
  "Subject": "Mailpit API subject",
  "Headers": {
    "X-IP": "<IP_ADDRESS>"
  },
  "Text": "This is the text body",
  "HTML": "
This is the HTML body
",
  "Attachments": [
    {
      "Content": "VGhpcyBpcyBhIHBsYWluIHRleHQgYXRhY2htZW50Lg==",
      "Filename": "AttachedFile.txt"
    }
  ]
}

The only fields which are mandatory are the From.Email and To.Email, the rest are optional. I think this covers most user-cases - what do you think @ryan0x44 ?

So the real question I have is, in your opinion, is having a different API to an issue for developers in your situation? If not, is it normal for JS developers to have separate library packaged for testing, and if so, how would a developer go about switching between the two? I am just trying to get a better understanding.
As a secondary question, if/when Mailpit would get this functionality, would you be willing to create and maintain a JS library for this, or do you think it's not necessary? Again, I don't know what JS developers prefer in these situations.

I don't think it's an issue - it's such a trivial amount of code to support a second mail provider (maybe 30 lines, largely just for building the payload). I think for the time-being just supporting the proposed API (from your last comment) makes sense, and at a later date you could always support additional formats for compatibility with things like Resend by adding a query param or similar.
I really like your API proposal - I've updated the PR to align to that, and also resolved issues where the payload didn't contain the right headers for From/To/etc. So now in my testing it appears to be working exactly how I'd hoped!
Let me know if you have any other feedback on the PR, would be fantastic to get this merged :)

@ryan0x44 Thanks for the feedback. As I mentioned before (but maybe wasn't clear on), I am already actually implementing a different version of this functionality in another local branch, so I don't actually need your PR (to merge). The way I'm doing it is somewhat more flexible, eg: there is no forced HTML multi part, support for attachments, etc, and the way I'm doing it ties into a few other things too.
I do appreciate your effort though! Please leave your PR as-is as I am referencing it to see if I don't leave out anything. My plan is to have something merged and released within the next few days (definitely by the end of the weekend).

@axllent are you saying you're not open to outside contributions?
FWIW, my PR has conditionals around those fields so they're already optional. I've also just updated it to support attachments, customers headers, and tags - I think that's everything. More than happy to make any other changes you want to see. It would be nice to be able to contribute :)

This new feature has been released in v1.18.0.
Hopefully you'll see the very different approach I took to your implementation, and clears up why it made no sense to to merge your PR? I did credit you for your contribution in the release notes.
I look forward to your feedback and testing!

Great to see this change released! Can confirm it works as expected (once I accounted for the slightly different URL path).
I don't see a significant difference on the implementation, but your solution works and I appreciate the credit in the release notes. Thanks @axllent !


Add PDFs from #1773 to the reftests

Are both of these new test-cases actually checking specific things not already covered by existing tests?

There is no easy way to tell without code coverage information, but since we still have relatively few reftests for XFA, I'm inclined to think these are likely to cover at least something that isn't already covered.

And layout stuff is pretty touchy so having more reftests will help to avoid future layout regressions.

/botio makeref


Haddock link returns 404

https://input-output-hk.github.io/cardano-wallet/haddock/edge

We've indeed removed automatically exported haddock documentation. The link to Haddock needs to be removed :+1:

fixed.


[docs] add shared spacer assets

We've been duplicating the same spacer SVGs in each of the element docs directories. We should migrate these to a shared directory (possibly docs/assets/spacers) and update all the existings paths to refer to the shared assets.

@zeroedin is addressing this issue in https://github.com/RedHat-UX/red-hat-design-system/issues/1014 🥳

Thank you @eyevana and @zeroedin. I'll reopen this and mark it to close when #949 lands


Add an option to sort the keys in the query string FIX #64

This option is needed when we want to create predictable query strings.

Hi @nlf could you review this PR? :)

I'll try to get to this today

Thanks!

Great :)

Is this mentioned in the docs at all?

@codeclown a PR to flesh out the docs is always welcome

@ljharb Sure! #191


Got endOfInput even if config file is mapped and readable

This is pertaining to docker v<IP_ADDRESS>
docker run --rm -v $(pwd)/postgrest.conf:/etc/postgrest/postgrest.conf -p 3000 -it begriffs/postgrest:v<IP_ADDRESS> /bin/bash

root@11e9c4162571:/# cat /etc/postgrest/postgrest.conf
db-uri = "$(PGRST_DB_URI)"
db-schema = "$(PGRST_DB_SCHEMA)"
db-anon-role = "$(PGRST_DB_ANON_ROLE)"
db-pool = "$(PGRST_DB_POOL)"

server-host = "$(PGRST_SERVER_HOST)"
server-port = "$(PGRST_SERVER_PORT)"

server-proxy-uri = "$(PGRST_SERVER_PROXY_URI)"
jwt-secret = "$(PGRST_JWT_SECRET)"
secret-is-base64 = False

max-rows = "$(PGRST_MAX_ROWS)"
pre-request = "$(PGRST_PRE_REQUEST)"

root@11e9c4162571:/# ls -l /etc/postgrest/postgrest.conf
-rw-r--r-- 1 root root 380 Aug 12 02:40 /etc/postgrest/postgrest.conf

root@11e9c4162571:/# postgrest /etc/postgrest/postgrest.conf
postgrest: ParseError "/etc/postgrest/postgrest.conf" "endOfInput"

some update: i think it was due to invalid config file. After i populated all the envvars the problem goes away.
I think it'll be helpful to output more explanatory error messages in this case.

I'm seeing this message despite an hour or two trying to solve it. Populating all envvars doesn't change the outcome for me. Running docker v<IP_ADDRESS>. @Jimexist any chance you can share your configs (dockerfile+postgrest.conf)? I've checked against various issues/docs ~ 10 or so times now.

@jlsphar i'm just filling out all the envvars with values in the config then i'm all good

@Jimexist dang, i haven't been able to crack this shell. wish i had some haskell chops... my only experience with the language is using xmonad, a piece of software so great that i only need to play with the configuration. i'll take my issue over to gitter and see if we can't get this working :) thanks @Jimexist

@jlsphar in the project chat @jcasto reported the same problem.
Can you try running the file command on your config file, like
file myfile.conf

I'm curious if it will report a different encoding than I see locally for my own config file that works properly.

I am also fighting this problem.
$ file postgrest.conf postgrest.conf: ASCII text

It would appear that my password for my user was too complex, and the special characters in the file were causing the binary to not function as expected.

Greetings, I had this issue as well, turned out that I was using single quotes to quote my strings.

@robx Have you seen a similar issue happen with configurator-pg?

@steve-chavez I haven't seen similar issues, but I'm also not really sure what the issue is here. I.e., there might well be some concrete issue where some wrongly quoted fields cause an unhelpful error message. I'd be happy to address such. As it stands, the issue is very vague to me.

@robx For now, I can reproduce the single quote issue:
## postgrest.conf
## ..
app.settings.external_api_secret = 'some_value'

## Will cause
postgrest postgrest.conf
Error parsing config file:
        parsing support/configs/config: endOfInput

Though the main issue here is related to env var interpolation. In https://github.com/PostgREST/postgrest-heroku/issues/25#issuecomment-547604233 it's mentioned that a config like:
export TEST=".\"https://somedomain.example/key\""

## postgrest.conf
app.settings.external_api_secret = "$(TEST)"

Would cause the endOfInput error reported here, however I cannot reproduce it.

So it looks like due to the use of attoparsec any parse error will backtrack back to endOfInput. I'll have a look at switching it out for megaparsec.

The config error messages should be more descriptive now that #1457 got merged.
I'll close for now but will reopen if unclear errors are reported again.


Make Default Module Action Menu Configurable

Fixes issue #2762
Summary
Added a new property to the Host Setting entity that will allow solution developers to change what control get's loaded for the portal's default Module Action Menu.
Adjusted the the Container.cs class to read from the new HostSetting instead of a hard coded value.
The new behaviour will default to the core module action menu if a HostSetting entry for the new property is not found in the database,
I added a git ignore for SolutionInfo.cs as local build scripts were modifying that file to update the versioning.
Note:  I've tested that the SQL script works when running manually but it is not being ran (or appears that way) when I modify a nightly 9.4 build to include this script.  If someone can put another set of eyes on the script and see if they can spot the issue, if not I'd like to see if it works properly when we do a RC build (the script not running will not break the site/code but it would be nice to add the value into the DB).

Wouldn't it be easier, to provide the default value in the API instead of the database table? This way, no record would be needed, unless using a custom action menu.

@sleupold That is exactly how I have it currently. The default value is supplied in the API and if it exists in the database then it will use that one instead. You can find the defaulting in the PortalSettingsController.cs file change.
For including it in the DB during install, my thought was from a discover-ability perspective that it would be easier for developers to get started using this if they could see the setting in the DB instead of it being hidden away.
Since it works without the script, if the script isn't working properly then it's not a blocker to move ahead without it.

Thanks @mikesmeltzer!
Is the alternative action menu something open source that you can point to, or is it custom/proprietary?

@bdukes There aren't any alternatives at the moment. I am intending to do a blog post for the 9.4 release informing users as to what the feature is and how one would get started building their own menus.

Thanks for the contribution @mikesmeltzer! Sorry for the confusion around the SolutionInfo file too.

Successful build queued manually.


feat: set slinky state in upgrade handler

Set the x/oracle and x/marketmap state from our core market config

add corresponding tests

NOTE: this PR is on top of https://github.com/neutron-org/neutron/pull/516

Could you embed this file via //go:embed static directive?
it's really not convenient to share an additional file with validators

please run gofumpt


Application does not start if subscription is dependent in any level on Marten services

Infected version: 7.31.0 and above
Discord thread
Repository for reproduction of error

For anybody reading this, the very easy workaround is to not inject Marten services into a subscription. Instead use the IDocumentOperations service that is pushed into your class.

@piotreksda sorry, but the way I'm "beating" this is through documentation and maybe a better error message. The real answer is "don't do it that way"

Might have to address this in Marten 8. We need to redo how the IoC-loaded subscriptions work and move all the event filtering rules out of base classes. Or finally give up and use constructor injection around the projection. For right now, this is strictly a documentation issue.


fix(cts): add e2e for monitoring

🧭 What and Why
It's getting pretty repetitive.
Monitoring API needs a special API key, I've added it to github.

YOU'RE THE BEST

When you look at the PR content, you know that's painful. So 💙  on you @millotp


Remove use of GNU C extensions typeof, and statement expressions

toybox's maxof() and minof() don't have double evaluation problems, they're defined in lib/lib.h:
#define minof(a, b) ({typeof(a) aa = (a); typeof(b) bb = (b); aa<bb ? aa : bb;})
#define maxof(a, b) ({typeof(a) aa = (a); typeof(b) bb = (b); aa>bb ? aa : bb;})
It snapshots them into local variables with the same type as the argument precisely so it doesn't evaluate the argument twice.
So first you remove a use that's valid for the existing implementation, and then you break the implementation. What on earth is the point of this? This works fine in llvm, what broken compiler are you trying to work around the deficiencies of? Or is this "infrastructure in search of a user" where you think someday someone might want to build on Turbo C?
Are you going to remove the ~2000 uses of typeof() from the linux kernel? Or do you expect to build with a compiler that doesn't build the linux kernel? (If so, which compiler?)
~/linux$ toybox grep -rwM '*.[ch]' typeof | wc -l
1919


Test

Codecov Report

Merging #10 (43eb24a) into master (fdf5e88) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #10   +/-   ##
=======================================
  Coverage   82.57%   82.57%
=======================================
  Files         204      204
  Lines       50327    50327
=======================================
+ Hits        41559    41560    +1
+ Misses       8768     8767    -1

Impacted Files
Coverage Δ

rust/parquet/src/encodings/encoding.rs
95.43% <0.00%> (+0.19%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 73e5097...43eb24a. Read the comment docs.

Codecov Report

Merging #10 (43eb24a) into master (fdf5e88) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #10   +/-   ##
=======================================
  Coverage   82.57%   82.57%
=======================================
  Files         204      204
  Lines       50327    50327
=======================================
+ Hits        41559    41560    +1
+ Misses       8768     8767    -1

Impacted Files
Coverage Δ

rust/parquet/src/encodings/encoding.rs
95.43% <0.00%> (+0.19%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 73e5097...43eb24a. Read the comment docs.

Codecov Report

Merging #10 (43eb24a) into master (fdf5e88) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #10   +/-   ##
=======================================
  Coverage   82.57%   82.57%
=======================================
  Files         204      204
  Lines       50327    50327
=======================================
+ Hits        41559    41560    +1
+ Misses       8768     8767    -1

Impacted Files
Coverage Δ

rust/parquet/src/encodings/encoding.rs
95.43% <0.00%> (+0.19%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 73e5097...043bd97. Read the comment docs.

Codecov Report

Merging #10 (43eb24a) into master (fdf5e88) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #10   +/-   ##
=======================================
  Coverage   82.57%   82.57%
=======================================
  Files         204      204
  Lines       50327    50327
=======================================
+ Hits        41559    41560    +1
+ Misses       8768     8767    -1

Impacted Files
Coverage Δ

rust/parquet/src/encodings/encoding.rs
95.43% <0.00%> (+0.19%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 73e5097...043bd97. Read the comment docs.

@github-actions autotune everything

@github-actions autotune everything


SDK-1576 Fix potentially persisting/retrieving empty strings

Linear Ticket: SDK-1576
Changes:

Add guardrail for a potentially empty string being returned for a session token in auth interceptor
Ensure that we never persist or return an empty string from the storage helper
Lint
Version bump

Notes:

Checklist:

[x] I have verified that this change works in the relevant demo app, or N/A
[x] I have added or updated any tests relevant to this change, or N/A
[x] I have updated any relevant README files for this change, or N/A

UI tests are failing randomly because of AVD flakiness when transitioning between tests. Going to ignore it for this PR.


Adding feature flags to minimize dependencies

Description
To keep dependencies minimal, we could add feature flags to compile the Typst crates. By default, all feature flags should be enabled, so most users won't have to think about setting the right feature flags for their use case.
I've made an example commit for adding such a feature flag in a fork here. Note that this PR fails a test, as I haven't figured out how to flag them yet.
I was wondering if there is interest in merging these kinds of PR's, when we open them.
Use Case
We're using the Typst crates in an embedded context for the Dutch Electoral Council, so we are benefited by small binaries and keeping the list of dependencies as small as possible for security reasons. As an added bonus, compile times would also be shorter.

Our use case is a combination of beign able to audit the supply chain (which I failed to mention previously), and lowering the attack surface as much as possible. As this will be part of security critical software, we want to minimize the chance to pull in vulnerable code. Every dependency we don't compile with our final binary, is a dependency we don't have to worry about.
Although the smaller binary and faster compile times would be nice, I agree that it's not a good idea to go and eliminate dependencies willy-nilly, just for the sake of eliminating dependecies.
For us, it's most important to target unmaintained crates that we don't use (for example serde_yaml comes to mind).
If you need me to elaborate more about the use case, let me know.

I am concerned about the maintaibility aspect of adding a bunch of features. Crates with lots of features are very hard to properly test. Morever, I think the overall amount of code that Typst pulls is so large that it would be a lot work to audit, even if you remove some of the dependencies.
Maybe an alternative approach for you would be to containerize your Typst usage?

Sorry for the late answer. I see your point that adding a lot of feature flags would make maintaining and testing more difficult. We're actually using the Typst crates as dependencies in our binary. Here's a link to the repository if you're interested:  https://github.com/kiesraad/rust-pdf-poc
I think we have some trade-offs to consider. Either forking the Typst repo and see how far we get stripping off dependencies, or put effort into containerization like you said.
I'll close the issue as it is getting out of scope, but if you have any ideas on this, we would love to hear your perspective.

Adding here with my own usecase. I'm starting to use typst to produce paper booklets for popular education. We don't care so much about the number of dependencies, but more about the final binary size. We don't need:

citations/references
SVG embedding
mathematical equations
WASM plugins
data loading
outlines
(probably more?)

For example, a quick cargo bloat shows that hayagriva and citationberg take 4.5MiB (or ~850KiB with lto=thin and codegen-units=1) on a release binary. Very unscientific benchmark but just by removing stuff we don't need i got the release build down to 25MiB (from 36).
The main challenge faced was that the macros used in typst don't supports #[cfg(feature="...")] inside them.
This changes nothing about the good reasons not to add many feature flags. I just thought i would share my experiment here on this issue. Personally i don't think it's worth it right now... if it reduced by 90% it would certainly be. But for ~25% it's a lot of efforts. Maybe this will be revisited in the future...


Incorrect resize behaviour with controlled component

Problem
In a controlled component, it seems the height is initially determined before the value prop is updated.
I have a component that strips newlines from entered text. Simplification of my logic:
export function simplifyWhitespace(string) {
  return string.replace(/\s+/g, ' ')
}

class Example extends Component {
  constructor(props) {
    super(props)
    this.state = { text: '' }
    this.handleTextChange = this.handleTextChange.bind(this)
  }

  handleTextChange(event) {
    this.setState({ text: simplifyWhitespace(event.target.value) })
  }

  render() {
    return (
      <Textarea
        value={this.state.text}
        onChange={this.handleTextChange}
      />
    )
  }
}

Problematic behaviour when tapping enter:

Cause
It seems to me that the resize code being called in the textarea's onChange callback makes sense only for an uncontrolled component. It assumes that new size will be based on the current value attribute of the element, which is not true for an uncontrolled component.
Possible solution
The calculateNodeStyle function should also take a string containing the next value (since this cannot be assumed to be the current value of the element). For a controlled component, I think this logic might be added to the componentWillReceiveProps.
Perhaps something like:
_resizeComponent(value) {
  // directly modify element stye in DOM
  Object.assign(
    this.textareaElement.style,
    calculateNodeStyle(value, /* other args... */)
  )
}

componentWillReceiveProps(nextProps) {
  // If this is a controlled component (ie. `value` is set, and has changed), then resize:
  if (this.props.value !== nextProps.value) {
    this._resizeComponent(nextProps.value)
  }
}

_onChange(event) {
  // An uncontrolled component will update each time its content changes:
  if (this.props.value == null) {
    this._resizeComponent(event.target.value)
  }
}

Happy to provide a PR to address this. If my understanding is correct it should be fairly straight forward.

I think your use case got fixed with recent changes and fixes. Going to close this, but if you can confirm that it's working it would be great.
Also if you want to propose better implementation than what has been done in the library - please send a PR so we can discuss more.