chore: uses sha256compression opcode in Noir and implements acvm solver for it

This PR should be merged after PR #4503 , because it uses the opcode implemented by the latter.
In this PR, I add the implementation of the ACVM solver for sha256compression opcode, and use it in Noir implementation of sha256.
This gives us 3 ways of doing sha256. You can see below the resulting circuit size for hashing 1 byte with each of them:

The full Noir implementation : 17161 ACIR Opcodes, Circuit size is 65065
The full BB implementation: 75 ACIR Opcodes, Circuit size is 38799
Mixed Noir+sha256compression opcode: 351 ACIR Occodes, Circuit size is 15495

The sha256compression opcode is a clear winner, and this is because it uses UltraPlonk lookup-gates.
As a result, I have removed the 2 other methods in the stdlib. The stdlib sha256 is now calling the Noir implementation which is using the sha256compression opcodes.
The old opcode should be removed in a future PR.

Benchmark results
Metrics with a significant change:

note_history_trial_decrypting_time_in_ms (5): 172 (+109%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit 94f436ed and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
128 txs

l1_rollup_calldata_size_in_bytes
45,956
181,604
724,196

l1_rollup_calldata_gas
227,180
888,740
3,535,664

l1_rollup_execution_gas
320,371
1,007,188
3,756,042

l2_block_processing_time_in_ms
1,149
4,334
17,176

note_successful_decrypting_time_in_ms
311
964
3,579 (-1%)

note_trial_decrypting_time_in_ms
19.8 (-2%)
91.3 (-1%)
139 (-5%)

l2_block_building_time_in_ms
18,171
71,694
288,333

l2_block_rollup_simulation_time_in_ms
13,508
53,251
214,651

l2_block_public_tx_process_time_in_ms
4,633
18,365
73,430

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
15,148 (-6%)
29,311 (-3%)

note_history_successful_decrypting_time_in_ms
2,317 (+1%)
4,517

note_history_trial_decrypting_time_in_ms
:warning: 172 (+109%)
215 (-1%)

node_database_size_in_bytes
17,281,104
33,185,872

pxe_database_size_in_bytes
29,923
59,478

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
326
44,528
25,313

private-kernel-ordering
196
43,633
16,193

base-rollup
1,457
129,774
933

root-rollup
82.5 (-1%)
4,192
729

private-kernel-inner
435
70,819
25,313

public-kernel-private-input
238
33,663
26,945

public-kernel-non-first-iteration
237
33,705
26,945

merge-rollup
7.81
2,712
933

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
2 leaves
8 leaves
16 leaves
32 leaves
128 leaves
64 leaves
512 leaves
1024 leaves
2048 leaves
8192 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.2
10.6
12.6
16.7 (-2%)
22.7 (-2%)
63.7
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.9
17.5
23.0
31.6
47.0
143
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.591
0.592
0.538
0.518 (-2%)
0.476 (-1%)
0.440
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
N/A
N/A
N/A
74.2
47.5
239
459
901 (-1%)
3,546

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
N/A
N/A
N/A
159
96.0
543
1,055
2,079
8,223

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
0.459
0.487
0.436
0.430
0.429 (-1%)
0.427

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
N/A
N/A
N/A
103
56.5
350 (+1%)
684
1,359
5,406

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
N/A
N/A
N/A
197
104
691
1,363
2,707
10,771

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
0.494
0.496
0.475
0.472
0.473
0.471

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
N/A
56.3
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
N/A
94.1
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
N/A
0.577
N/A
N/A
N/A
N/A
N/A
N/A
N/A

Miscellaneous
Transaction sizes based on how many contracts are deployed in the tx.

Metric
0 deployed contracts
1 deployed contracts

tx_size_in_bytes
16,859
39,794

Transaction processing duration by data writes.

Metric
0 new commitments
1 new commitments

tx_pxe_processing_time_ms
550 (-3%)
1,435

Metric
0 public data writes
1 public data writes

tx_sequencer_processing_time_ms
0.483 (+1%)
570


add equivalent to bash command

add equivalent to bash command  ${varname:word} if varname exists and isn't null, return its value; otherwise return word
#190

Thank you!


Face North for other directions

Is your feature request related to a problem? Please describe.
Im always frustrated that i when i spin my camera to face east or west i cant get it lined up right and it bothers me immensely.
Describe the solution you'd like
Theres already a solution in game for facing north! Id really enjoy some way to get a button or a right click option somewhere to face east west and also south.  Just like how it does when you click to face north
Describe alternatives you've considered
Im not really sure of any alternatives.
Additional context
I think that this feature could be really helpful to alot of people and for those of us who get frustrated with imperfect camera turning it would make my day.

duplicate of #1770


fix: nfs client check, updated RFS

RFS changes reimplemented
bug fix for NFS client check. Now checks explicitly on RHEL and SLES

Can you please make the following changes ?

Include prefix for sap_hana_preconfigure, sap_netweaver_preconfigure, sap_general_preconfigure ::::

should be redhat.sap_install.sap_general_preconfigure .... .
https://github.com/IBM/ansible-power-linux-sap/blob/ff0055dc2e62cafa015bb947bead0201a9b68236/roles/powervs_configure_os_for_sap/tasks/rhel_saptune.yml#L9

Remove #no-fcqdn [name]. For lvg, vgs etc use community.general (sync with @ludwig)
RFS :

name: Update rps_sock_flow_entries runtime value ?? Why should this be performed when reloading it later ?

Create custom systemd unit for RFS configuration ? Should happen if it doesn’t exit. Idempotent must be respected

The rfs-config.service is a custom service, not a standard one. It is explicitly defined in the playbook to handle a specialized task: dynamically configuring rps_flow_cnt for network interface queues, which cannot be directly persisted via traditional mechanisms like sysctl. After considering few options to modify sysfs file, I think using a systemd service is a good option do  it.
Necessary changes implemented all other comments. Will figure out pipeline failure with Sahitya


2D Axis annotation font defaults prevent saving to config

FontAttributes defaults for font, bold and italic are:
Arial, false,false.
When 2D axes annotation are created, they set their font default for the same settings to:
Courier, true, true
When CreateNode is called (the method that sets up the data written to config files),
the axes font settings are only saved if they differ from the FontAttributes default (because saving to config does not do a 'completeSave').
So if the desired settings are 'Arial, false, false' (which is different than the axes defaults), they aren't saved because they actually match the FontAttributes default.
I see two options:

Change Axes2D to not set its own font defaults, but to use FontAttributes defaults. This will change current behavior and appearance of 2D axes.
Change Axes2D::CreateNode to tell its xaxis and yaxis nodes to always do a complete save.
This will add extra information to config files that isn't usually saved.

How about changing the FontAttributes defaults to Courier, true, true and then having Axes2D set its defaults from FontAttributes defaults. This would preserve the current defaults and fix saving.

Except that would change the behavior of other state objects that also use FontAttributes
(Axes3D annotations, etc).

I didn’t realize that. Let me ponder some more.

I'm thinking the 2nd option might be best, at least for 3.1.2, as it doesn't change default appearance of 2d axis annotations, but still allows for saving the settings.


Whatsapp

Uroog

hello 👋
On Mon, 3 Jul 2023, 7:27 pm Uroog, @.***> wrote:

Uroog
—
Reply to this email directly, view it on GitHub
https://github.com/hackerxphantom/WA_CRASHER/issues/10#issuecomment-1618981170,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A4M4KR6ZA47QQUTMLDNQF2TXOMFIFANCNFSM6AAAAAAXSJTQCU
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Hello
Please give me reply
Can you sell your tool

Yes dm on whatsapp +91<PHONE_NUMBER>

Hello?
On Sun, 24 Sept 2023, 8:45 am Hacker X Phantom (X PH4N70M), <
@.***> wrote:

Yes dm on whatsapp +91<PHONE_NUMBER>
—
Reply to this email directly, view it on GitHub
https://github.com/hackerxphantom/WA_CRASHER/issues/10#issuecomment-1732512087,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A4M4KR2J5NFRUVWGQVPRGY3X37QLPANCNFSM6AAAAAAXSJTQCU
.
You are receiving this because you commented.Message ID:
@.***>

Thanks
On Sun, Sep 24, 2023, 6:47 PM Bot543 @.***> wrote:

Hello?
On Sun, 24 Sept 2023, 8:45 am Hacker X Phantom (X PH4N70M), <
@.***> wrote:

Yes dm on whatsapp +91<PHONE_NUMBER>
—
Reply to this email directly, view it on GitHub
<
https://github.com/hackerxphantom/WA_CRASHER/issues/10#issuecomment-1732512087>,

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

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

—
Reply to this email directly, view it on GitHub
https://github.com/hackerxphantom/WA_CRASHER/issues/10#issuecomment-1732574335,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCYZP4GHXTC2XT6DC6C5NXLX4A2Y3ANCNFSM6AAAAAAXSJTQCU
.
You are receiving this because you commented.Message ID:
@.***>

Two step verification reset in one click

I got in.
On Tue, 17 Oct 2023 at 09:19, Amit kumar mandaiya @.***>
wrote:

Two step verification reset in one click
—
Reply to this email directly, view it on GitHub
https://github.com/hackerxphantom/WA_CRASHER/issues/10#issuecomment-1765641009,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCYZP4FHEL5UXRQVW322WWTX7YBO5AVCNFSM6AAAAAAXSJTQCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRVGY2DCMBQHE
.
You are receiving this because you commented.Message ID:
@.***>

Hi dear
Can you help me anyone I need   to hack whatapps of someone please

No, sorry.
On Mon, 27 May 2024, 5:59 pm CodeSpark21, @.***> wrote:

Hi dear
Can you help me anyone I need to hack whatapps of someone please
—
Reply to this email directly, view it on GitHub
https://github.com/hackerxphantom/WA_CRASHER/issues/10#issuecomment-2133434073,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCYZP4GN4EDVEOO7QRVXY2TZEMU3JAVCNFSM6AAAAAAXSJTQCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZTGQZTIMBXGM
.
You are receiving this because you commented.Message ID:
@.***>

You asking?Sent from my iPhoneOn 27 May 2024, at 15:05, m117772064 @.***> wrote:
No, sorry.
On Mon, 27 May 2024, 5:59 pm CodeSpark21, @.***> wrote:

Hi dear

Can you help me anyone I need to hack whatapps of someone please

—

Reply to this email directly, view it on GitHub

https://github.com/hackerxphantom/WA_CRASHER/issues/10#issuecomment-2133434073,

or unsubscribe

https://github.com/notifications/unsubscribe-auth/BCYZP4GN4EDVEOO7QRVXY2TZEMU3JAVCNFSM6AAAAAAXSJTQCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZTGQZTIMBXGM

.

You are receiving this because you commented.Message ID:

@.***>

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>

Yoy are a great personSent from my iPhoneOn 28 May 2024, at 17:26, CodeSpark21 @.***> wrote:
Thanks with the core of heart ☺
On Mon, 27 May 2024, 6:05 pm m117772064, @.***> wrote:

No, sorry.

On Mon, 27 May 2024, 5:59 pm CodeSpark21, @.***> wrote:

Hi dear

Can you help me anyone I need to hack whatapps of someone please

—

Reply to this email directly, view it on GitHub

<

https://github.com/hackerxphantom/WA_CRASHER/issues/10#issuecomment-2133434073>,

or unsubscribe

<

https://github.com/notifications/unsubscribe-auth/BCYZP4GN4EDVEOO7QRVXY2TZEMU3JAVCNFSM6AAAAAAXSJTQCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZTGQZTIMBXGM>

.

You are receiving this because you commented.Message ID:

@.***>

—

Reply to this email directly, view it on GitHub

https://github.com/hackerxphantom/WA_CRASHER/issues/10#issuecomment-2133444727,

or unsubscribe

https://github.com/notifications/unsubscribe-auth/BIYCHBSG6GXF7DDRHDKJTADZEMVRLAVCNFSM6AAAAAAXSJTQCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZTGQ2DINZSG4

.

You are receiving this because you commented.Message ID:

@.***>

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

OK I'll unsubscribe
On Tue, 28 May 2024, 8:35 pm dazvader, @.***> wrote:

Yoy are a great personSent from my iPhoneOn 28 May 2024, at 17:26,
CodeSpark21 @.***> wrote:
Thanks with the core of heart ☺
On Mon, 27 May 2024, 6:05 pm m117772064, @.***> wrote:

No, sorry.

On Mon, 27 May 2024, 5:59 pm CodeSpark21, @.***> wrote:

Hi dear

Can you help me anyone I need to hack whatapps of someone please

—

Reply to this email directly, view it on GitHub

<

https://github.com/hackerxphantom/WA_CRASHER/issues/10#issuecomment-2133434073>,

or unsubscribe

<

https://github.com/notifications/unsubscribe-auth/BCYZP4GN4EDVEOO7QRVXY2TZEMU3JAVCNFSM6AAAAAAXSJTQCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZTGQZTIMBXGM>

.

You are receiving this because you commented.Message ID:

@.***>

—

Reply to this email directly, view it on GitHub

<
https://github.com/hackerxphantom/WA_CRASHER/issues/10#issuecomment-2133444727>,

or unsubscribe

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

.

You are receiving this because you commented.Message ID:

@.***>

—Reply to this email directly, view it on GitHub, or unsubscribe.You are
receiving this because you commented.Message ID: @.***>
—
Reply to this email directly, view it on GitHub
https://github.com/hackerxphantom/WA_CRASHER/issues/10#issuecomment-2135551317,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCYZP4D5FKUTUXYXW63F62TZESP5LAVCNFSM6AAAAAAXSJTQCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZVGU2TCMZRG4
.
You are receiving this because you commented.Message ID:
@.***>

Plzzzz brother help me

How can ISent from my iPhoneOn 28 May 2024, at 17:45, CodeSpark21 @.***> wrote:
Plzzzz brother help me
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>


Fix types that should be lists

Not only in the doc, but also in the defaults.yml file
This is actually untested, and only looked sensible as the text spoke of lists...

I had a quick look at dnsmasq man page and the jinja template, and this ought to be OK, IMHO

Should work just fine. I often use empty dicts where I need empty lists, never had any problems with it. But I'll try to  be a little more consistent!


Bring your own local model via UI

Add an option to directly add a local model (not publicly available via any URL) through the user interface without requiring the user to modify the .json file as not every user would be familiar with .json syntax.
It could be a separate widget ( model manager ) listing all currently provided models with their attributes.
Also, I found it difficult to modify the .csv files for correct segmentation terminology.

Users certainly should not need to edit any file. The only thing we can expect from them is to be able to select a file on disk. So, having an "import model" feature where the user can select a local file that contains the model zip file (containing the .pt files, labels .csv files, and model desccription json files) could be useful.
We can require developers to generate the .csv and .json file and zip them up in a required folder structure. Maybe something like this:
Models.json
mitralvalve-v1.0.0\model.pt
mitralvalve-v1.0.0\labels.csv
hlhs-v1.0.0\model.pt
hlhs-v1.0.0\labels.csv

The module would unzip the file into c:\Users\andra.MONAIAuto3DSeg (probably into a new subfolder, maybe unique name generated from hash of the .zip file) and the module would always retrieve models from this file as well.
I'm not sure how hard we need to push developers on taking label definition seriously. On one hand, letting developers not use standard terminology has resulted in the mess we are in now with many projects: there are lots of mixups due to different training data sets and AI using different label values and names for the same thing and not being sure what exactly each ad-hoc name means. This certainly has to stop. On the other hand, if only MONAI Auto3DSeg does all the developer education and convincing work then developers may simply feel this as an unnecessary nuisance and will just hate us and fake some .csv files to satisfy requirements or just not work with us.
How do you think we can make the .csv creation easier? I find it already really easy with Excel. However, maybe you mean that figuring out what standard term to use. Would documentation (tutorial on how and where to find codes) and examples for all the commonly used segment be sufficient? Adding a .csv file generator could make things even easier, but then that would be one more thing to maintain.

How do you think we can make the .csv creation easier? I find it already really easy with Excel. However, maybe you mean that figuring out what standard term to use. Would documentation (tutorial on how and where to find codes) and examples for all the commonly used segment be sufficient? Adding a .csv file generator could make things even easier, but then that would be one more thing to maintain.

It would probably be easiest to have a basic segment editor comparable widget that the user can utilize to create a segmentation, add segments, set names, and select terminology. The final segmentation (no actual segmentation needed) can then be used to export the terminology into the expected format. If a different terminology was used (like we did for SlicerHeart), it should be exported with the .csv file and separately loaded if needed.
@lassoan Let me know what you think

it seems this feature haven't realized yet. How can I add my custom model by editing json file?


screen turns off when i put my finger over proximity sensor, no call is in progress

reported by @dupa11111dupa:matrix.org
https://github.com/matrix-org/riot-android-rageshakes/issues/955

There is no " "## onSensorChanged(): " logs after ending the call.
So, i don't think Riot is responsible of this issue : the screen is turned off/on by the app : as there is no log, i assume the phone does something on its side.


Create notification with picture

vRPclient.notifyPicture(source,{"NOTIFY_PICTURE", ICON TYPE, "TITLE", INT, "YOUR TEXT"})
See https://wiki.gtanet.work/index.php?title=Notification_Pictures to view notification pictures aviable.

Tested ? Also add documentation in the readme near vRP.notify (best is to document the function before the definition, then copy the comments+prototype to the readme). You can also add links to an icon list, etc so people can actually use it.

Update first post and readme file. Sorry i'm not familiar with github pull request.

I will make better pull request.


Admin table snapshots api

Table snapshot create, get, list and delete, create a table from snapshot API
GRPC mock test cases

Snapshots are an alpha feature on the service.  This R should be considered a low priority.

@sduskis I am closing this pull request. All admin apis are covered in https://github.com/GoogleCloudPlatform/google-cloud-ruby/pull/2128


Any way to do type coercion on default value in createReducer?

Hey there,
I have a case where I can't be sure if my reducer will be instantiated with an array or an object. I'd like to coerce the array into an object if necessary.
It would look something like this (in vanilla redux):
function myReducer (state={}, action) {
	var newState = {}
	if (Array.isArray(state)) {
		state.forEach(function(item){
			newState[item.id || bsonId()] = item
		});
	} else {
		newState = state
	}
	if (action.type === 'HELLO WORLD') {
		return {newState, hello: 'world'}
	}
	// etc....

	return newState
}

I couldn't think of a way to dynamically set the default reducer value with redux-act. Do you have any suggestions for how to do this? Maybe the create reducer api needs to be expanded slightly?
const reducerMap = createReducer({
  [increment]: (state) => state + 1,
  [add]: (state, payload) => state + payload
}, function(initialValue){var newInitialValue = {}  ...etc....  return initialValue });

Thanks!
Thomas

function normalize(value) {
  return Array.isArray(value) ? /* cast to object */ : value;
}

const reducerMap = createReducer({
  [increment]: (state) => state + 1,
  [add]: (state, payload) => state + payload
}, normalize(initValue);

The init value is only at bootstrap, so you can normalize it right away. If you don't know you state during the reduce call, that's another problem, and a bad one. You shouldn't be in that case, otherwise, you will need to normalize for each action creation unfortunately.

Okay, thanks for the tip. I'll just make sure I normalized at an earlier step.


Redirect from roam.davidvargas.me to roamjs

https://aws.amazon.com/premiumsupport/knowledge-center/redirect-domain-route-53/

Already done!


Configurations issues

Because
Issue to keep track of configuration decisions and questions.
We decided to have two configuration files: one with settings for the model and one with run-time parameters.
The example configuration file modeling/config/classifier-full.yaml has both of them (for now), including some settings for binning:
prebin:
  - bars
  - slate
  - chyron
  - text-not-chyron
  - person-not-chyron
  - credit
  - other
labels: [ "slate", "chyron", "credit", "other" ]
postbin:
  0: 3
  1: 0
  2: 1
  3: 3
  4: 3
  5: 2
  6: 3

Currently, the train code just generates (this is for a different model, but the idea should be clear):
bins: {'pre': {'slate': ['S'], 'chyron': ['I', 'N', 'Y'], 'credit': ['C']}, 'post': {'sladit': ['slate', 'credit'], 'chyron': ['chyron']}}
labels: ['sladit', 'chyron', 'other']

The question is which format we prefer for the config file. I would prefer something like
labels:
  - sladit
  - chyron
  - other
bins:
  - sladit
    - slate
    - credit
  - chryon
    - chyron
  - other

Or even
labels:
  - sladit
    - slate
    - credit
  - chryon
    - chyron
  - other

It is compact yet has all the information needed, I might be wrong about the latter though.
I am also somewhat uncomfortable with the "other" label.
Done when
No response
Additional context
No response

One change we agreed on was to do a file copy of the trainer configuration rather then dumping the loaded configurations as a Yaml file since the latter does not preserve comments.


Don't allow uploading empty files (allowEmptyFiles option)

Source of the #428 and suggested to have some option like allowEmptyFiles: false.

Is an empty file really a file though?

Good question. So actually allowEmpty sounds better, really. Also it is a familiar option from other libraries/servers and such.

@QuantumSheep, anything that has file structure in file-system table is a file, no matter the size :)
@olstenlarck, in case of allowEmpty it wouldn't be obvious whether its for files, fields, or both. (they seem to be different config names)

This is a serious issue that needs prompt attention because the empty files just mess up the entire folder, I have to run fs.unlink() every time I submit a form that has file with an empty value.

Yes of course.

Has this feature request been added yet?

@nakedtoast unfortunately, seems like we do not have any PRs regarding that.

Has there been any movement on this?

@shaneosullivan nope, nothing on my end, sorry.

Hey, sorry for the late response. I only have time to see the notification now. I will take a look at it this weekend.

@tunnckoCore or @GrosSacASac I want to contribute more to this project, there is another issue you recommend to me to work on?

https://github.com/node-formidable/formidable/issues/609


Numba's object mode processing closure failed

When I run the following code in object mode, I get an error
from numba import jit

@jit(forceobj=True)
def fn():
    x = 1
    def gn():
        print(x)
    return gn

fn()

The error message is:
Traceback (most recent call last):
  File "testnumba3.py", line 10, in <module>
    fn()()
NameError: global name 'gn' is not defined

Ooops - it probabably works because there is actually some support for first class functions in Numba now: https://github.com/numba/numba/pull/5287
Apologies for the confusion - will look into this a little further.

In the meantime, as a workaround for your actual code, can you get around the problem by compiling in nopython mode and using an objmode block, e.g.:
from numba import njit, objmode

def python_func():
    print("Python function")

@njit
def fn():
    x = 1
    with objmode():
        python_func()

    def gn():
        print(x)

    return gn

fn()()

What is the difference between object mode and nopython mode?

Nopython mode compiles the Python code so that it uses native types for all values, whereas Object mode compiles the code such that it treats all objects as Python objects and uses the Python interepreter's C API to execute each operation in the compiled function. These are defined in a little more detail in the glossary:
Nopython mode: https://numba.readthedocs.io/en/latest/glossary.html#term-nopython-mode
Object mode: https://numba.readthedocs.io/en/latest/glossary.html#term-object-mode

I think this is a bug/issue in the objmode pipeline.
from numba import jit

@jit
def fn():
    object() # Comment this, it compiles in nopython mode
    x = 10
    def gn():
        print(x)
    return gn

z = fn()
z()

The above compiles fine in nopython mode (comment the object() call), but if the object() call is there, the fall back object mode pipeline is used and the above error appears.


systemd service units and timer

@markjones112358
Are you sure your service units and timer are written correctly?  They do not seem to work for me.
On my system, path to file is /usr/bin/dmenu_extended_cache_build, so I tried to use the system service unit, with systemsctl --user start update-dmenu-extended-db.system.service
Fails with various iterations of:  Invalid user/group name or numeric ID:
Timer will not load since unit does not.
Are these working for you?
Edit: removing the line "User=%i" seems to do the trick (for the user unit).
I am either using the systemd-install.sh script wrong or it fails to insert the user name instead of %i in the unit file.
(In addition, I am not sure specifying the user is necessary in this case.)
But will look further into it and probably write my own service and timer files.

Hi,
Sorry, but I have no idea how these systemd services work. And no, my systemd service isn't working.
This integration was an outside contribution and at the time I merged it I thought it worked.
Sorry I can't be more help, systemd is not something I've become familiar with.
If you find a way to get these service files working, create a merge request and I'll integrate them into dmenu-extended.

Thanks for your feedback. I have it working now.  I just want to make sure the files are written in the best manner possible and once that is done and will create a pull request.

Great, I look forward to integrating your changes.

Hi again.
I've modified your systemd install script slightly so as to improve auto-detection of the dmenu_extended_cache_build script (default location on my machine differs from what was hard-coded into the script). If you get a chance, could you confirm that it's still working as you intended. I've added your name to the contributions at the bottom of the README too.


How does the JSON.Parse(json) function get the total number of records returned?

How to get the total number of records returned by using the JSON.Parse(json) function? I use JSON.Parse(json).count to return only the number 5, which actually has 364 records.

Please post your json string.

json.txt
The total number of records is 364.

Dim sJson As String = IO.File.ReadAllText("..\..\json.txt")         Try             For i As Long = 0 To JSON.Parse(sJson).count                 TextBox2.Text += vbCrLf & JSON.Parse(sJson)("data")(i)("bond_nm").ToString 'textBox1.Text             Next i         Catch ex As Exception             MsgBox(ex.Message)         End Try
I got it this way.

Try :
( JSON.Parse(sJson) as Dictionary<string, object>) ["data"].Count // in c#

Thank you, mgholam! It turned out that my method was wrong.


Running ChaNGa on latest build of charm gives a crash

Original issue: https://charm.cs.illinois.edu/redmine/issues/1026

I used the following command to build charm
./build ChaNGa gni-crayxe hugepages smp --with-production --enable-tracing -j8

latest commit on master is 7c03bc21b3a975ae764ca03e62ce7fa4344e2cd5
I used cosmo25 dataset on 512 nodes
It throws  the following error
Wed Apr  6 14:00:27 2016: [PE_0]:inet_recv:inet_recv: recv error (fd=-1543438960) Bad file descriptor
Wed Apr  6 14:00:27 2016: [PE_0]:_pmi_network_barrier:_pmi_inet_recv from target 0 failed pmi errno -1
Wed Apr  6 14:00:27 2016: [PE_0]:_pmi_barrier:network_barrier failed
Wed Apr  6 14:00:27 2016: [PE_1]:_pmi_barrier:_pmi_smp_barrier failed
Application 37193257 is crashing. ATP analysis proceeding...

ATP Stack walkback for Rank 0 starting:
  start_thread`0x2aaaaacd4805
  call_startfn`machine-smp.c:415
  ConverseRunPE`machine-common-core.c:1268
  _initCharm(int, char**)`init.C:1267
  CmiBarrier`machine-common-core.c:1578
  LrtsBarrier`machine.c:4306
ATP Stack walkback for Rank 0 done
Process died with signal 11: 'Segmentation fault'
Forcing core dumps of ranks 0, 2, 3
View application merged backtrace tree with: stat-view atpMergedBT.dot
You may need to: module load stat

_pmiu_daemon(SIGCHLD): [NID 14607] [c23-7c0s7n1] [Wed Apr  6 14:00:45 2016] PE RANK 355 exit signal Killed
_pmiu_daemon(SIGCHLD): [NID 14677] [c23-7c0s5n3] [Wed Apr  6 14:00:45 2016] PE RANK 859 exit signal Killed

Original date: 2016-04-07 14:33:39

Have you run this on the 6.7.0 release? It'd be good to pin down when it started failing...

Original date: 2016-04-14 04:28:58

Can you retry this with current master now?

Original date: 2016-04-14 19:13:37

It doesn't crash anymore with the current master (046e8f9856f8618f6b4fa845c0a16840f9f252dc).

Original date: 2016-04-19 17:09:35

What was the resolution of this?

Original date: 2016-04-19 17:13:20

It was not reproducible with the latest master


parameters to query

<ldf-client response-format="streaming" auto start-fragment="../data" query="
  PREFIX : <https://whopickedthis.com/ns#>
  SELECT DISTINCT ?p ?o WHERE {
             <help> a :User; ?p ?o .
                   }">
       </ldf-client>

To set a subject for that user, it seems like I have to move to javascript and set 'query' from there somehow, which is a big hurdle for a page that could be just a bunch of polymer elements stitched together with attribute bindings.
Here's the API I'm picturing:
<ldf-client ... var-user="{{user}}" query="
  PREFIX : <https://whopickedthis.com/ns#>
  SELECT DISTINCT ?p ?o WHERE {
             ?user a :User; ?p ?o .
                   }">
       </ldf-client>

where attributes starting with 'var-' turn into initial bindings to the sparql query.

If I am not completely wrong, in order for Polymer to recognize attributes, they have to be declared beforehand. One could, however, imagine a micro syntax in an attribute sparql-bindings (or similar) that would somehow be mapped to the variables in the query attribute. I have too little practical experience with SPARQL to design this micro syntax. Do you, or maybe @RubenVerborgh have anything in mind that could work, ideally something that already exists?

The first thing that comes to mind is VALUES. However, I'd still have to write support for it then in the client.
Alternatively, the SPARQL.js parser (which is included in the bundle because Client.js uses it) provides a query generator as well. So the query could be parsed, the variable replaced, and the query be regenerated again.


Equality constraints?

Could you discuss why typesSatisfyDecConstraints doesn't analyze equality constraints?  Is it difficult, or is it unnecessary for your application, or something else?

I am closing this because I have an adequate solution in my th-desugar branch now.


Operational plugins

Provide some common abstractions that can be used to implement operational plugins.
An operational plugin must have the following characteristics:

Must expose operational info and can allow to control some operation
It's optional. It can be enabled by default but should be possible to disable them
Must expose at least an endpoint to access it's functionality under /operations/{{plugin-endpoint}}
Must be secured with a proper authorization filter.
Should be possible to enable/disable/configure it on the fly

Plugin ideas:

[ ] Health Check: #40
[ ] Metrics
[ ] Configuration
[ ] Application Info
[ ] Logging
[ ] Application Control

List available plugins
Available plugins including it's status (enabled/disable) and a list of media controls can be accessed doing a GET request to /operations with a supported media type.
Eg:
GET /operations
Accepts: application/json

{
  "application-name" : "demo-app",
  "links": {
    "health": { "self": "/operations/health", "status": "ENABLED"},
    "info": {"self": "/operations/info", "status": "DISABLED"},
    ...
  }
}

Must be secured with a proper authorization filter.
Healthcheck should not be behind authorization, at least not the most basic ok/not-ok
Should be possible to enable/disable/configure it on the fly
Using application starter with --flags? via API using an entrypoint? unless this is intentionally left without details, i think it's unclear what this means.


Right Hand py

Hi Christian
Your iniRightHand.py still uses setMinMax which IMHO is replaced by map now?

the setMinMax(min, max) is doing the same as map(min,max,min,max)
doing it one way or the other is fine and will result in the same behavior


Where's the image_projection package?

According to the following line, the get_projected_image.py code imports several functions from the image_projector (nested) in the Evaluation directory. However, I cannot find the package in the Evaluation directory.
https://github.com/lychenyoko/content-aware-gan-compression/blob/64fd76b88a66e4699bad05515c8167c1289cbb85/get_projected_image.py#L11

same question. A lot of packages in the code get_projected_image.py are missing.

https://github.com/lychenyoko/content-aware-gan-compression/issues/10#issuecomment-1024354890
He already answered it in a closed issue. Hope this helps You.


omitting directory on 2.92 EasySolar-II GX

VenusOS (please complete the following information):

Device type: [e.g. VenusGX EasySolar-II GX]
Firmware Version [e.g. 292]

after install
root@EasySolar-IIXXXXXXXXXXXXX:~# sh installrelease.sh
cp: omitting directory '/data/etc/dbus-serialbattery/qml'
cp: omitting directory '/data/etc/dbus-serialbattery/service'

Thanks for your notification.
Those are just warnings that can be ignored. The scripts seperately copy those folders to where they need to be, so the driver will work fine.
This warning has also been suppressed in the new beta release and will ship in the next version 👍


simplify getTextAttribute accessor

There is no need in getOriginal() method cause the original value is already passed to the accessor as official docs says.

Did not know that, thanks!


v. 2.0 release

Awaiting @fkleuver to optimize the code before release of v. 2.0 to NPM.

We can do minor/patch releases with optimizations afterwards. If 2.0 is done from a functional point of view I think it's good to go and release it to get some feedback as well. Makes it easier to compare perf too.

There are two minor issues left to fix as far as I know. @kflash mentioned it in the bypass and on Skype yesterday. There are a few non-failing cases related to (enum identifier / keyword) and the eval and arguments (enum identifier / keyword) .
It was mentioned that this could be fixed if the token code was changed so the enum (identifier / keyword) was also recognized as an identifier. Same thing for the eval and arguments (enum identifier / keyword) . That has to be fixed before a 2.0 release, and validateBindingIdentifier updated to deal with the new changes.
Another important fix is the fact that  a parenthezied async  & non-async arrow with and without a block body doesn't communicate with the scope. The connection is broken.
According to what I understand, this was something that was pending on your optimizations and a solution for the current issue have been described to you on Gitter I think.
Beyond this, we are now reviewing the code and correcting minor errors that we have come across. Maybe by the end of today or tomorrow or review is complete and everything is good to go from our side.

@fkleuver  The code is feature complete, and done from a functional point of view as you mentioned. But there exist a few places that could be optimized. And maybe it should before any release. It depends on how much this parser can parse before it start to kneel down and pray to God to end the misery. We didn't benchmark this, so we don't know.
But tokens can be merged to avoid too many if/else clauses and
also optimized to avoid frequent branch prediction fails e.g. using a table dispatch in parseStatement and parseStatementListItem or eventually use a perfect hash in the switch statement instead.
A few tokens we know that could be merged here is the two for escaped keywords. If they are seen as an identifier you wouldn't need the extra if/else in e.g. class decl & class expr. And a few other places.
But this is all micro optimization, and is it worth it in the long run? If we choose to go down this path, I also think the entire token code should be changed because V8 on first run would optimize on string values, so there are only a win-win case in benchmarking and not a RL scenario when you do
if (token === Token.ForKeyword instead of if(tokenValue === 'for') unless you use a perfect hash. I can be wrong, so don't rely entirely on my words about this.

@fkleuver We are done for now from our side, so I guess you can take it from here as stated in #303

Agree with @axefrog , @KFlash as I told you earlier my plan was to output multiple builds and have rollup do some replacements where particular features are removed from the bundle at build time. I said I would help you fix the performance so don't worry about that. Just focus on spec compliance / tests

I guess this will be done now?
As @KFlash mentioned for you, what's left to fix is the "scope" disconnection so remaining non-failing arrow tests will fail as expected. And so it flatten the expression parsing and performance.
There are still a few non-failing tests, but easier to fix them after your "clean up".
And also documentation is missing, but as far as we understand this should be fixed by the chinese guy @aladdin-add as mentioned in #284
Please note there is a lot of breaking changes in this release and Cherow 2.0 is not backward compatible with Cherow 1.6.x
We are off now, and let you take it from here.

@fkleuver What's the state of this issue and the optimization?

@fkleuver I don't have NPM access to publish a release.

I can publish it if it's feature-ready, but you were still mentioning some bug fixes that needed to happen right? This would take more time for me than general performance improvements as I'd need to dig into the spec. I cannot put a timestamp on it due to having a lot on my plate for Aurelia right now. We talked about this on Gitter as well.
In any case, just to get everything clear, what is your status going to be for the coming weeks / months? Are you going to be doing any more work in any area or are you fully leaving the thing with me? I don't mind either way, but then I know what (not) to expect. If you are completely stepping out then I will start reserving some time slots starting next week. Otherwise I will wait until the beginning of March and focus on other priorities first.

@kflash isn't around. I am one of his former students. I think he has vacationed indefinitely, and he's celebrating life's happy days in the Netherlands.  So I don't think you can expect him to come back at first. Maybe as a little maintainer sometime in the future.
He asked me if I could fix the last things he had on his TODO list, and I've done that now. I don't think there is more that I can do considering my absent knowledge of the ECMA specs. I noted above (it was me who answered you earlier too) what remains. There are also some non-failing cases left to fix, but this is an open source project and people can contribute to get them fixed if they like this parser.
I'm going to talk to @kflash on Skype this weekend so I can ask him if it's any more important to fix, but I doubt it.
So consider it safe to take over the ship.

@fkleuver This is @KFlash complete identifier code for the "hot path". This never ended up in Cherow.
function scanIdentifierOrKeyword(context: Context): Token {
    let scanFlags = AsciiLookup[currentChar];

    while (index < input.length) {
      let charFlags = AsciiLookup[currentChar];
      if ((charFlags & CharType.WhiteSpace) === CharType.WhiteSpace) break;
      scanFlags |= currentChar > 127 ? CharType.SlowPath : charFlags;
      advance();
    }

    if ((scanFlags & CharType.SlowPath) !== CharType.SlowPath) {
      value = input.slice(start, index);
      if ((scanFlags & CharType.NoKeywordCandidate) === CharType.NoKeywordCandidate) {
        return Token.Identifier;
      }
      const len = value.length;
      if (len >= 2 && len <= 11) {
        const keyword: Token | undefined = descKeywordTable[value];
        if (keyword !== undefined) return keyword;
      }
      return Token.Identifier;
    }
    return scanIdentifierOrKeywordSlowPath(context);
  }

  function scanIdentifierOrKeywordSlowPath(_: Context): Token {
    return Token.Identifier;
  }

I see what he's trying to do there, but I'm fairly sure there is no performance gain in using scanFlags like this. Sure, it makes the code base more consistent (perhaps to some eyes even more elegant), but if raw performance is the goal then a few raw comparisons and boolean variables will likely perform better across all browsers.
Apart from that, I've always said that the scanner code is the wrong thing to be focusing on at this point. It is the easiest thing to look at and try to optimize, but the real bottlenecks are object creation, polymorphism and branching in the parser code.

Object creation is hard to optimize, but some gains could be made by using a few tactically chosen classes instead of inline objects. That's a trade-off between perf and lib size, though.

Polymorphism as a bottleneck in cherow mostly boils down to ensuring things that are supposed to be SMI's, are truly always SMI's and not oddballs or worse. I believe there are a few hot paths where both numbers and strings pass through. Not sure though, haven't checked the latest code thoroughly yet.

Branching is the thing he has been focusing on a lot and the main thing he asked me to look into and optimize. Optimizing this also includes figuring out where unnecessary checks are happening, and removing those. This, in turn, might reveal opportunities for reordering logic in a more optimal way which, if the tests are not 100% accurate and reliable, could wreak havoc on the long term if it breaks something unknowingly. This is why I'm a little reluctant to start working on this right now (besides me just being busy) because if it does break something, even more work will come from that. It will spiral out of control with a parser like this.

So, that's why I prefer to confirm first that cherow is indeed fully spec compliant to the best of everyone's knowledge, according to tests, and the 262 suite, and then release 2.0 so the "pressure" is off. Then I can take my time on the long run to go through everything, add tests where needed, and so forth.
Regarding the things that are still not working, are you able to fix them or what should I expect there?

Hi. I fully understand your point of view, and I hope you understand I'm just a drop-in maintainer and doesn't have a very in-depth knowledge of the more technical aspects of Cherow.  I know what works and what doesn't. And there are no critical things that will be destroyed if you start working on this. What remains is dependent on your optimization according to what I understand on @kflash
For arrows and async arrows the "scope" is broken. Soon as it is fixed, 50 non-failing tests will fail as expected. Then you have 60 tests left to fix.
This tests are e.g. yield doesn't fail every places it should etc. Actually an easy fix with bitmask fiddling.
So first thing to focus on is to get the scope working, and after what @kflash told me the plan was to "flatten" the entire expression parsing into one function - something you should do?
Then you just merge array lit and array pattern into one function and same with obj lit and obj pattern. So you have something
So then there would be something like this
function parseObjLitPattern(state, context, scope, isPattern) {
if (isPattern) return pattern;
return expr;
}

The 'scope' today - if no scope exist - is represented by a negative number. -1.
So after what I understand - if you flatten the entire thing you could do something like this I guess
function exprParsing(state, context, scope, origin, isPattern) {
case '{':  `parseObjLitPattern`
}

And to get this working in arrows is then easy - you already have the scope.
exprParsing(state, context, scope, origin, false)
And this should be fine. But I have no further knowledge of this, nor do I know how you to plan this. This was just an example code from me. But I think you get the point?
Except for this is a few non-failing arrow tests exist, but I think if you flatten everything they can be passed as a boolean instead of the mutual parser flag or you use another set of bitmasks. If that is set up correctly I can get them to fail if you wish.
This is what I know remains to be fixed and optimized. And nothing I can do. I'm sorry for that.

@fkleuver I also forgot to mention that there are a few non-failing enum keyword tests and eval and arguments. According to what I understand, this is related to tokens and not something I can fix. In the source code, these things are marked with "TODO (fkleuver)" so it is easy to see where they should fail.

@fkleuver I looked through the source code now and I can't see other things that need to be fixed. There exist around 110 non-failing Test262 suit tests, but they will fail if the code get changed in the way I mentioned earlier.
However there can  be a few regular expression edge cases I may have overlooked - the code doesn't parse regular expression as expected. If you encounter an issue like that, you need to set the | Context.AllowPossibleRegexp bit before you trigger the scanner and the issue is solved.
In his original code @KFlash also uses Context.AllowTemplate and parses the template way different so it has been a little confusing for me.
Except all this I think there is no more.

@fkleuver If it's okay for you I add - when I find it useful - minor tweaks to the code that I have seen in the experimental code. Like what I did for the lower / upper case letters tweak.
You are starting on this next week as mentioned above?

If you are completely stepping out then I will start reserving some time slots starting next week.

I can start working on optimizations yes, but I'm not sure if I'll get around to fix the issues quite yet.

I guess it will take awhile to fully understand the code before you can fix the issues?

@fkleuver I'm not sure how useful it is but I added a way to extend the lexer as you can see in https://github.com/cherow/cherow/commit/1315e96ca9eca92b5780da0e35e28f71e57cc9bb
I'm not an performance expert, and didn't test it. You may improve it, but I think this is one way to extend the parser as I noticed was mentioned in #292.
Once again I "copied" this code from @KFlash private code, and I have seen that he can use different callback that returns different results during a simple parse
const lexer1 = function() {}
const lexer2 = function() {}

nextToken(state, context, lexer1);

nextToken(state, context, lexer2);

No, it just requires a big uninterrupted time slot to focus on the code and I don't have many of those at the moment. Performance improvements lend themselves for a few hours here and there, fixing parser bugs takes a full day or two. You know how it goes

I may think improving the error tracking / messages also would be a good thing.  In v. 2.0 @KFlash added an "arrow" to pinpoint exactly where the error is, but not always correct.
In his experimental code I noticed (for edge cases) he pass the index, line and column values directly to the error func to get exact error loc.
Like this:
     SyntaxError: Multiline comment was not closed properly (1:3)
/**
   ^

@fkleuver I doubt there are more that I can do here, so I let you handle everything from now. I tried to "adopt" some code from his experimental code to Cherow, but not that easy beacuse it's two different worlds. He uses a combination of functions and table lookup inside the function bodies.
So I wish you good luck!

Speaking of that particular example, we need experimental support for parsing decorators. A lot of people ask about this.

How to implement it?
I noticed this code in his experimental code, and this may be a solution for the "scope" issue I mentioned to you before - if not flatten everything into one function?
function parseArrayLiteral(context: Context, scope: ScopeState, isPattern: boolean) {
    token = scan(context);
    const elements: (ESTree.SpreadElement | ESTree.Expression | null)[] = [];
    while (token.token !== Token.RightBracket) {
      if (token.token & Token.IsIdentifier) {
        elements.push(parseMemberExpression(context, parseIdentifier(context)));
      } else if (token.token === Token.LeftBrace) {
        elements.push(parseMemberExpression(context, parseObjectLiteral(context, scope)));
      } else if (token.token === Token.LeftBracket) {
        elements.push(parseMemberExpression(context, parseArrayLiteral(context, scope)));
      } else if (token.token === Token.Ellipsis) {
      }
    }

    return isPattern
      ? {
          type: 'ArrayExpression',
          elements
        }
      : {
          type: 'ArrayExpression',
          elements
        };
  }

We had it in 1.6.x somewhere. It's relatively simple - as far as syntax is concerned, a decorator is just a CallExpression or Identifier (that's the decorator syntax without the parens) preceded by an @ symbol.
It can be placed before a ClassDeclaration, or properties / methods / parameters. The decorator itself is then simply added to a decorators array of the AST node in question.
TypeScript took the "simple" aspect a step further and added an optional decorators property to the base node, so almost everything has a decorators?: ... property. Forward compatibility wise that could be a smart move until the spec has finally settled, since it's still not certain what they can really be placed on when the spec is final.

@KFlash I have done some experimenting with that "everything in a single function" idea in the Aurelia repository but it turns out it's actually a performance killer in V8.
It seems storing stuff on properties of a class can greatly outperform (by a factor of 2-4) loose variables declared in function scope if the function is really big and has many variables, but this applies mostly to isomorphic properties. This has to do with the way V8 optimizes generated hidden classes.
Many small functions does indeed seem to perform better, in particular when the parameter types are isomorphic as well.

@fkleuver I had a Skype chat with @KFlash

Here is my findings yes after experimenting

lexer code in function scope is fast and can perform good, but only allow you to use
a table lookup inside a function scope 2nd level deep or deeper (nested). Hard to maintain.

Table lookup is fast, but it take time on "first run" to create the needed tables. Smaller tables
2nd level deep for one-char punctators and ASCII lookup only and a small switch statement for the
rest is the best choice, See V8 and other engines for comparison.

Also avoid to directly return values. E.g. for a "nextChar" function it's faster if you do

function nextChar(state: ParserState) {
  state.currentChar = 0;
  state.column++;
  state.index++;
  if (state.index <= state.length) state.currentChar = input.charCodeAt(index);
}

>// And then
>
if (state.currentChar) ...

This has been tested by Chakra team among others, and it has been done multiple benchmarks on it.
Also V8 itself do similiar things.

Yes, I managed to come up with a lexer code that outperform Cherow 2.0. On 250 lexer tests my code
uses average of 70ms. Cherow 2.0 uses 200ms for the same.

For the "issue" regarding scoping. Is that an issue? Just move the scope to the scanner state and it's
available everywhere you need it instead of passing as a function arg. I think @fkleuver knows how to >fix that.
Than man is a genious :)

@fkleuver It's me. The real one :) I'm just temporary here to clarify a few things.
I noticed you mentioned hidden classes.  In my research and experiments I found out that if we keep the parser state as a pure object literal, we gain performance with 3% vs a class alternative. You can try it yourself in various benchmarks, and you will notice the performance will drop.
Regarding the function scope thing. If you want the code to be properly scalable, and also care about memory usage a class is the best choice, but as in TypeScript case they have to create a new class instance every time you do a change in the code, and then do a lot of comparison. That is expensive. Use of the new keyword can be a performance bottleneck. In Cherow I can't see any disadvantage of using classes a few places in the code, and it will help reduce memory usage. So you are right there.
Another thing we should be aware of is to avoid using double-precision floating point number, and instead use 31-bit signed integer, or bit masks. This because of how V8 internally treats numbers.
And if things are only locale within one function - use a local boolean instead. This is V8 related, and I'm not sure how the real performance differences are in other JS engines, but V8 is the most common one and also used by NodeJS so we should focusing on optimize for V8.
And we should prefer monomorphic over  polymorphic!
Soon as I get to a computer I will try to push to a new branch my private lexer code so you can see how I do it when I optimize things for real. Still that code is "unpolished" and need improvements, but I changed a few things from the original Cherow code. Example the error handling.
You also mentioned decorators. It's still on stage 2, and the specs keep changing. Therefore I was hesitant to implement it. And if this should be implemented it has to be under the experimental option. But does V8 support decorators? I haven't checked it recently.
The experimental option should be equal to V8's experimental feature flag.
Anyway. It's an easy thing to implement, and I'm sure you can do it if you find time for it :)
The last thing to mention is the non-failing cases. When I left it was around 130 tests that didn't fail as it should, and I know it's down to 110 now. J.K can fix this things. I'm sure. But before that we need to solve the scoping issue.
The scoping issue for arrows can be solved if you

Move the scope to ParserState (be aware of performance)
Try to do something similar that I noticed J.K pasted from my experimental code

I'm offline again now, but I'm 100% confident that Cherow is in safe hands with you !

@KFlash The difference between plain objects and classes is not particularly large unless there are methods involved, but a class does use a little bit less memory per instance. Where is that benchmark showing the perf drop?
Regarding 31-bit signed integer, yes, and perhaps we can use Int32Array instead of Uint32Array for the various lookups.
Regarding differences between engines, Chakra and Gecko benefit a lot more from directly using natives when possible (e.g. TypedArray over a normal array with only numbers) since V8 tends to optimize things in that direction anyway, where other engines don't. I noticed this when I tried to optimize a lis algorithm (there are more factors in play, but TypedArray hardly made a difference in Chrome whereas it almost doubles/triples perf in Edge and IE11: http://jsben.ch/MoAdv)
The only thing that will change about the decorators spec and how that would affect the parsing logic is where they are valid/invalid. So, if for starters we don't attempt to validate them (wait with that until the spec stabilized) then we won't need to keep running after the spec and in the meantime folks can parse decorators.
It's not implemented in any runtime, but folks want to parse code with decorators (which works after transpiling with ts/babel), and cherow fails to. That's a reason for many people to opt for ts or babel instead of cherow, when really they would prefer cherow for performance and precision considerations.

There are no specific benchmark. I just ran the same benchmark that exist on the demo page. With and without "cold" JIT. It always perform worse when I was using classes.
Maybe an good idea to use Int32Array for lookup, but in my experimental code I moved away from the large table lookup and are using multiple smaller table lookup. E.g. 2 different tables for number and identifiers and it did give a performance boost. And similar to how V8 does it.
 // `a`...`z`, `A`...`Z`, `_`, `$`
  if ((AsciiLookup[state.currentChar] & CharType.Letters) > 0) return scanIdentifierOrKeyword(state, context);

  // `0`...`9`
  if ((AsciiLookup[state.currentChar] & CharType.Decimal) > 0) return scanNumericLiterals(state, context, false);

I did stop experimenting with this a while ago because I focused on  finalizing Cherow 2.0. And I'm using a similar lookup for one char token for punctuators.
Regarding decorators. Recently I also noticed they changed the name on some hooks etc, but I guess that hasn't any impact on parsing. So yes I agree that we should implement it and hide it under the experimental option. It's still Stage 2, so not qualified yet for the next option.

@KFlash I added my private experimental lexer code. Can be found here. It's just an experiment, and even if it works don't expect miracles with it :) The only thing that doesn't work is identifier + surrogate and surrogate + identifier. Just me being lazy :)
Note:  This was the code I experimented with before what become Cherow 2.0, and the perf are actually improved over current 2.0.

@fkleuver I updated my private experimental code to latest. Use it if you want when optimizing Cherow 2.0. Most of the "hot path" have been optimized and now uses a table lookup. The performance is good, but ofc. this can be optimized further if you chose to use it. Example numbers in the ASCIILookup table can be separated so you can do a fast lookup for octals and binary as well to mention a few. But this is all micro-optimizations on a very low level and are kind of pointless.  I rather focusing on optimization for significant digits and SMI since that is what is most used. Same for identifiers. I improved the "hot path" for "plain" identifiers, but not for escapes. And so on.
Anyway. My state from now on is not to be available or online. J.K will use my profile from time to time and just ping him if you want him to fix things for you.

@fkleuver When can we expect a v. 2.0 release?

Not sure yet, I'm first going to make benchmarking a bit easier/quicker to do (with more reliable results) so that perf tweaks don't take so long to validate.

@fkleuver Sounds interesting! Btw. What have been suggested before regarding solution for getting the scope working in arrows - I only think that can be fixed if you move the scope to the state object. Not sure about the performance regarding that.
Merging obj lit and obj pattern into one will give you too much headache, and not worth it. If it's possible at all. And if you manage to fix it somehow, what's the benefits? You still can't avoid to re-interpret to pattern (wich can be expensive),  but you can use it to reduce re-interpretation if you example do type: isPattern ? 'ObjectPattern' :  'ObjectExpression.
Another thing you could do is to optimize the cover grammar implementation and avoid the function calls if possible. And also optimize the scope implementation.
And I say you should stick to current parser flow and not try to flatten anything or merge anything into same function. The parser flow Cherow currently are using,  is well tested by many parsers as well as V8. Doing it differently will just cause more headache, and what I tried to show you from my experimental code regarding expression parsing. Well. I may suggest not to walk down that path. Too many wormholes to get out of :) Plus you would need lot more bit masks to keep track of the different states. A simple boolean will not help you :) And this things will turn out to be too complex for open source.
 It's so bad designed in many ways :(

@fkleuver Regarding the wormholes I mentioned above. There is no performance benefits to try to refactor Cherow into something like that, and it's nearly impossible. I guess that why V8 and others didn't write their parsers that way. It's actually to hard :(
Anyway. Just to guide you. The benchmark results below is Cherow 2.0 vs that wormhole idea I just mentioned

You see? There is no performance benefits doing it.

@fkleuver What do you think about something like this? This is taken from my "too many womholes and  headache experiment"
/**
 * Parse array expression or pattern
 *
 * @param {ParserState} state
 * @param {Context} context
 * @param {boolean} isPattern
 * @returns
 */
export function parseArrayExpressionOrPattern(
  state: ParserState,
  context: Context,
  isPattern: boolean
): ESTree.ArrayExpression | ESTree.ArrayPattern {
  nextToken(state, context);
  const elements: (ESTree.Identifier | ESTree.AssignmentExpression | null)[] = [];
  while (state.token !== Token.RightBracket) {
    if (consumeOpt(state, context, Token.Comma)) {
      elements.push(null);
      if ((state.token as Token) === Token.RightBracket) {
        break;
      }
    } else {
      let expr: any;

      if ( (state.token & Token.IsIdentifier) === Token.IsIdentifier) {
        expr = parsePrimaryExpressionExtended(state, context, false);

        if (consumeOpt(state, context | Context.AllowRegExp, Token.Assign)) {
          if (!state.assignable) report(state, Errors.UnexpectedToken, 'Donna G. F');
          expr = {
            type: 'AssignmentExpression',
            expr,
            operator: '=',
            right: parseExpression(state, context)
          };
        }
      } else if (state.token === Token.LeftBrace) {
        expr = parseObjectExpressionOrPattern(state, context, isPattern);
      } else if (state.token === Token.LeftBracket) {
        expr = parseArrayExpressionOrPattern(state, context, isPattern);
      } else if ((state.token & Token.IsStringOrNumber) === Token.IsStringOrNumber) {
        expr = parseLiteral(state, context);
      }

      elements.push(parseAssignmentExpression(state, context, parseMemberExpression(state, context, expr, false)));
      if (consumeOpt(state, context, Token.Comma)) {
        if ((state.token as Token) === Token.RightBracket) {
          break;
        }
      } else {
        break;
      }
    }
  }
  consume(state, context | Context.AllowRegExp, Token.RightBracket);

  return {
    type: isPattern ? 'ArrayPattern' : 'ArrayExpression',
    elements
  };
}

The parser flow Cherow currently are using, is well tested by many parsers as well as V8

That doesn't sound like a you thing to say. Isn't the point of cherow to rely on such extensive testing that it doesn't need to follow well-known patterns, and can instead attempt to do better?

But this is doomed to fail at some point

Not if properly tested. I was trying out stryker to find out exactly which logic in the code base is redundant, and use that information to try and optimize things further.
Now my problem with your hesitation is that, if cherow was indeed sufficiently tested (and you were truly confident about that), you wouldn't be hesitating. If even you are hesitant, then what am I supposed to be, knowing less about the spec?
So let's think first of a strategy on how to be sure we can really rely on the tests then. We need to be able to.

I'm not hesitating regarding the existing tests. They cover everything in Cherow and there are more than enough tests to be confident that the parser works as it should. No problems there :)
I'm only hesitating about my experimental code because I know that code will fail somehow or I will run into edge cases that I can't solve (already experienced it). That's the reason why I let Cherow follow the well-known pattern. That way we will always know the flow and can optimize from there, and we will also always know that the AST are build properly. Example LeftHandSide + member expr + primary expr + member expression is always a pitfall. In Cherow we will always know that this will solve cases like a().b, b[].c.d.e without any issues, And it will always happen.
In my experimental code this has to be done manually. What I take for granted in Cherow, turns out to be a huge failure sometimes in my experiment.  The main reason for my hesitation.
So when it comes to the tests.I trust them, and even if there should be a missing tests, we still know that the code will work because the pattern we follow is set up to work correctly. So it's actually enough with 2 - 3 tests to know that member expr works as expected, and if it does. Well. Then also 1200 other tests that rely on member expr will work.

@fkleuver Just now I ran into an issue with my experimental code while trying to parse out
[x, ...z + arr, y].  The cause of this issue is the missing binary expression.
With Cherow 1.6x and now Cherow 2.0 this kind of issues will never happen because we are following the well-known pattern, but in my experiment this has to be done manually. And how many cases like this I haven't discoverd yet?
So no worries about Cherow 2.0 and the tests. They cover what it needs and the actual test case above was copied from Cherow own tests.
+ expected - actual

             "expression": {
               "elements": [
                 {
                   "argument": {
      -              "name": "z"
      -              "type": "Identifier"
      +              "left": {
      +                "name": "z"
      +                "type": "Identifier"
      +              }
      +              "operator": "+"
      +              "right": {
      +                "name": "arr"
      +                "type": "Identifier"
      +              }
      +              "type": "BinaryExpression"
                   }
                   "type": "SpreadElement"
                 }
               ]

I don't understand. If you ran into an issue that the tests didn't expose, then doesn't that mean there are still missing tests?

@fkleuver I think you are confused with my experiment example? Just think Cherow. The well-known pattern goes like this
assignment expr -> member expr -> primary expr -> member expr (*again)
The MemberExpression are quite limited.
So if you parse out something like ([a.b.]), the "tail" is there. The .b. But let us say you are missing a test for this case. Still no reason to get panic.
Let say you have a test case for this one foo().a.b.c. You actually testing both programs and have a test that cover them both.
This is "freebies" when you follow the well-known pattern. You can always predict, and what pass for one case has to pass for the other one too even if there are no specific tests for it.
Got it?
In my experimental Kleuver code I moved away from this pattern and experimenting and ended up in the situation I illustrated earlier.

@fkleuver One thing that actually could improve performance is a refactor of parseAssignmentExpression or at least clean it up, but note that Async arrow is a PITA to parse.  An ideal solution would be something you see in V8 here and here and the specs for it here
But because of the way ESTree have been designed and the fact that non-async arrow doesn't like the call expression, but the async arrow does. Well. You got one problem. And then if you try to nest them or have a serie of arrows after each other (there exist tests for it) you get another problem. And so on... I tried to come up with a OK solution based on the limitations I had when implemented this.
In Cherow 1.6.x we have a different solution, but that solution have flaws. There are a few cases that doesn't parse at all as it should :) I discovered it while fixing this in Cherow 2.0.
A world without a call expression in this cases would have been the best :)

One thing I noticed in running the benchmark is that both TypeScript and Aurelia are particularly slow to parse in comparison to 1.6. What those 2 files have in common (which the other files don't) is very large functions (in TypeScript they are simply large functions, in Aurelia they are iifes). I've got the feeling that this slows cherow 2.0 down so much due to the scope tracking. But I'm not sure why this would be so much slower in function scope than it would be in module scope. It's really a huge difference, up to 50% extra perf loss

When you are parsing a function in Cherow 2.0 you create 3 scopes, and append 2 scopes. You only create 2 scopes if you are in function expression. You validate the function name in the scope too. In the formal list it also keep track if it is a complex arg or not. Not sure if this have the huge impact?
Did you try to profile it?

@fkleuver Did you try to do a comparison vs Acorn? What's the differences?
Try to either disable or improve the scoping, maybe it help?
I can try to experiment with a different scoping implementation soon as I get to a computer, but in Cherow 2.0 you may move it to the state object so it will work for arrows and async arrows. No way around that because of the well-known pattern we follow, and you can't pass it as func args all the way down to primary expr.
But try lazy loading?

@fkleuver The function args are pattern, so I may think if you use the inArgList bit mask, you can avoid to reinterpret to pattern in AssignmentExpression everytime you parse out a function. Maybe that help?

@fkleuver you will add decorators before releasing?

@fkleuver Can you try to think about a better algorithm for this one? E.g. escaped keywords.
See V8. In a few places we still need to fix this, so something like this?
const awaitPos = state.startIndex;
  let expr = parseIdentifier(state, context);
  if (awaitPos + 5 !== state.startIndex) report(state, Errors.UnexpectedToken, 'escaped');

I'm not on a computer, so I can't test, but can you try to come up with something better? I doubt relying on the token length is a good idea. It's different in Cherow.
And you add decorators?

Did some profiling in V8, seems to be spending a lot of time in recordTokenValue if I'm not mistaken. It seems to be a bit tricky to get a good overview in NodeJS directly though.
output-all.log
Yeah I don't know if relying on token length is a good idea at all, because what about escape characters? Or what was this about?

recordTokenValue is the main function for scoping. Records everything including lexicals and get called when using lexicals, functions, arrows etc. So I am not surprised about that. Ideas how to refactor & optimize it?
An idea for scoping is just convert it to class, and rely entirely on bit masks.
Regarding escaped characters. Almost everything related to it is fixed. There exist a few edge cases like for await that doesn¨t fail. So I was thinking if doing something like mentioned earlier would fix the non-failing  tests. I'm not on a computer now so can't test it but you see how I did check for directive prologues? Take a look at parseStatementList.

@fkleuver Do you think this is an faster way of implementing the grammar? I found some time to work on my experiment, and still not sure this will work...
 if ((state.token & Token.IsIdentifier) === Token.IsIdentifier) {
      expr = parsePrimaryExpressionExtended(state, context, false);
      if (consumeOpt(state, context | Context.AllowRegExp, Token.Assign)) {
        const assignBefore = state.assignable;
        state.assignable = Assignment.Assignable;
        const right = parseExpression(state, context);
        let assignable = (state.assignable | Destructuring.Cant) ^ (Destructuring.Cant | Destructuring.Assign);
        state.assignable =
          (assignBefore |
            ((assignable | Assignment.NotAssignable | Assignment.Assignable) ^
              (Assignment.NotAssignable | Assignment.Assignable)) |
            Assignment.Assignable |
            Assignment.NotAssignable) ^
          Assignment.Assignable;

        expr = {
          type: 'AssignmentExpression',
          left: expr,
          operator: '=',
          right
        };
      } else if (state.token === Token.Comma || state.token === Token.RightParen) {
        if ((state.assignable & Assignment.NotAssignable) === Assignment.NotAssignable) {
          state.destructable |= Destructuring.Cant;
        }
        state.destructable |= state.assignable;
      } else {
        state.destructable |= state.assignable;
      }

@fkleuver What's your progress with v. 2.0? A release soon? My suggestion / idea above isn't possible because of the way Cherow is designed, and I doubt it's faster. Not even V8 handle the grammar like that. Anyway. I got it working like that in my experiment for array and rest & spread, but doubt it's faster. And a lot more code is needed to fix it :(

@fkleuver Ideas on how to improve the scoping so you can release v. 2.0 soon?

@KFlash After giving it some thought I came to the conclusion that scoping would be better done after parsing as a separate, optional step, by walking the parsed AST and analyzing on that instead of directly on the tokens during parsing. There are a few reasons for that:

The obvious one: performance. If you disable scoping, 2.0 might very well even be faster than 1.6
Lib size when not using scoping: if you don't use the feature, the scoping logic can be tree-shaken. Alternatively, we could distribute scoping as a standalone importable file so one would not need to rely on bundlers to do this
Improved API design and test coverage from an integration perspective - by having cherow "dogfood" the AST output that cherow itself produces in order to perform post-processing, we might run into potential issues/limitations and are able to fix those before exposing end users to them (or we might conclude that everything is good and be more confident to release)

@fkleuver Interesting idea! I guess you are thinking of using a pure binary search to walk the AST? It might be faster that way, and just swap the state on the flags as you go and throw / not throw in the end based on the bit mask state. Something like
let const = 1;
mask |= (let | const) // invalid

// In the end throw errors based on masks state
switch (mask) {
  case 'let':
         if (mask & const) // throw
}

I did similar kind of thing in my experiment when I implemented the grammar, but I had to "play" with arrows, arrays, objects and parens at the same time and if the state changed for one of them, it would give different result. Plus I use 3 different masks to keep track of the state.
It was a PITA to implement, but for scoping it's easier because you walk the AST and mark it as you go. However you would need a 2nd set of masks I guess to figure out if you are in global, block or function body / head.
Once again. It's doable and sounds like the best way to go. It would also solve the arrow + scope broken thing :)
And to let the end-user choose if he / she want to use the scoping is the right thing to do. V8 already have scoping implemented, and some may prefer to use the native one, and others just need the performance Cherow give without scoping.
How long time would you use to implement the this change?

If you implement this a natural new breaking change that could land in 2.1 would be to remove the AST itself from the Cherow core and instead use binary values for the AST. Then in the end when you walk the AST, you simply assemble it again based on the state of the binary masks and do lexical scoping as well.

You would be able to output different AST's. Not only ESTree
Lexical analyzes can be done without any parsing (and still solve the regexp issue)

Use Cherow as a validator only. Analyze the input without parsing and if no errors, well everything is okay. That way Cherow would be super fast :)

You want to define a binary notation (something like ProtoBuf) to store the parse result in an ArrayBuffer or the likes? So start and end position + NodeType. And then parse that back into an AST upon request. So if you only need validation, no AST is produced. Lol. I like the idea but I think most people do actually want the AST, and this would put an extra parsing step in between.
It is a really fun idea though, I'll give you that.

I didn't think it through, and as you know I'm experimenting a lot. I was more or less thinking like this
return statement | binary | member | primary | identifier /* additional masks for assignment & destruct */ | destructible
Then I guess you could do a similar lookup as done for tokens & errors? Where the main AST nodes are binary masks & sub masks and the rest is simple enums.
I never thought it through, but I may have a huge Cherow change for v. 2.1, but maybe not this. It all depends if I get done with experimenting, but I have already done the impossible things with my experiment, and I broke free from the default standards and still producing the same ESTree output as Cherow. Not even V8 is close to what I actually have done so far :)

I think the main point of improvement at the moment is to cut loose the scope validation in the first place, as per 80/20 (or in this case more like 95/5) rule. Almost half of the time is spent doing that. It's huge.
If scope validating winds up being a little inefficient compared to what it is now, I don't think that's a big deal as the performance would still roughly be doubled for the majority cases.

Agree that the main focus has to be to cut loose the scope validation, and back then when I implemented it I was focused on getting things working as you suggested, and performance after. The any type is either a number and object. Something I did in a rush. The main purpose is that for expression parsing it should do nothing with the main scope. Only add names and lexicals.  The plan was to use a second arg or a scope masks names NotScopeAble and then if (x === NotScopeAble) return; // does nothing. But I never added the extra arg :)

@fkleuver As I said I may have huge change for Cherow 2.x, but I'm not in open source mode anymore so confused. Is this readable / understandable for the end-users?
export const enum DestructuringState {
  None = 0,
  CanDestruct = 1 << 0,
  Required = 1 << 1,
  // Only destructible if assignable
  Assignable = 1 << 2,
  // __proto__ is a special case and only valid
  // to parse if destructible
  SeenProto = 1 << 3
}

export const enum AssignmentState {
  None = 0,
  Assignable = 1 << 0,
  NotAssignable = 1 << 1
}

@fkleuver You know. In the moment everything become a bit mask, you have lost contact with reality and no longer a human, but a computer yourself :)
Here you see the benchmark on my non-optimized experiment. Mostly everything is bit masks.
Comparison vs. Cherow 2.0

@fkleuver Any progress on perf improvement and the scoping? That has to be the main focus before 2.0 release. Don't worry too much about the few non-failing cases that still exist. I will make sure they will be fixed in v. 2.x sometimes in the future. It depends ...
As you know I have been experimenting, and I think I made the impossible possible. And I plan to release my experimental code to the public one day (not done yet).
My experiment was successful! What I actually did was to parse backward. In that way I have full control on what I should parse, and what should not parse. And I can choose to use only the pieces of the parser code I need. Example let say we parse 1 = 2.
The parser code will do this:
1. Parse out number (1) and set the parser to not assignable
2. Throws an error
3. ... nothing

Result:
Unexpected token '=' (1:2)
1 = 2
  ^

Note: In current Cherow we actually parse out everything before validation and throw an error! We miss this kind of control.
There are a lot more into this, and I still need to play more with this code before I can go public with it. And also the complexity of the bit masks I'm using for the grammar, destructuring and assignments need a re-think before I can release this to open source.
The entire parser have become a bit mask! And I think maybe this is hard to understand?
assignable =
              state.assignable |
                  ((assignable | 2 | 1) ^
                      (2 | 1));

Anyway. The non-failing tests in Cherow 2.0 is already fixed in my current experimental code. So relax on that one!

@fkleuver I experimented a little, and as you said.  But with location tracking enabled the performance seems almost identical to v. 1.x with location tracking enabled.
I did a quick comparison against my own experimental code, and you see it here. Very small diff between 2.x and 1.x

But what is the progress on this for you? When will 2.0 be out the door?

@fkleuver Any progress on the 2.0 release?  I noticed things escalated...    So could you do the separation?  Don't bother too much with the main code except extraction.  I plan to release to public my private reference parser in the future.  Probably for v. 2.x or 3.0.
When I do so I will replace the main Cherie parser code and set a new parser standard.  Still work to fix on it to make it public friendly, but it pass and fail 110% after the spec.
But before that we need to release 2.0.
Your thoughts?

@KFlash I'm not entirely following. Also, apologies, I've been swamped with work recently and also have some catching up to do for Aurelia as well. Too many things happening at the same time.
As for 2.0, I think we've got a dilemma here don't we? Should we do this before or after the separation of scoping?

@fkleuver It's okay, and I understand your situation. Dilemma for 2.0? I'm not sure. It's only to rip out the scoping code and do what we talked about. Later when I find time for it I will only replace the part of Cherow that creates the AST nodes, and your scoping code will be used together with the new code. I can't see any huge issues with that?
In my reference parser I have no scoping code at all, and no plans to add it because of the plans we talked about before.
So just focus on separation of the scoping. My reference parser code is far from finished for open source. For that we talk in the future. I'm still playing around with it :)

@KFlash You already had some code that took out the scoping right? Mind sharing that for reference?
Btw, if you're working on some new experimental stuff, seriously, try wasm. You've good roots in C/C++ right? You can write the parser entirely in that and compile it straight to WASM. Every major browser supports it already. It's several times faster.

@fkleuver I don't have any code without scoping except for v. 1.x, but it should be easy to remove the scoping code. Just remove all code that either start or end with scope and also have a look at common.ts to see the functions related to scoping and remove them too :)
Note: Tests will break ofc. - tests related to scoping. But also be aware that func params, throw statement, switch statement etc is somehow related to scoping. Easy to track it :)
WASM? I consider it after I find and end on my experimental code. Or actually it's not a experiment anymore - it's a parser equal to Cherow 2.x. But me and V8 isn't friends atm. so I tend to run into infinity loops with the code.  Little hard to understand the concept because it hasn't been done before in any programming language.
But yes. I plan to convert to WASM in the end.

@fkleuver Sent you a file on gitter. You can use it as a reference maybe? No export and import, but everything else should work.  Use kleuver instead of cherow and you are good to go :) Then you can test out your scoping

@fkleuver How can we best simplify something like this?
destructible |=
          (destructible |
            ((state.assignable | AssignmentState.NotAssignable | AssignmentState.Assignable) ^
              (AssignmentState.NotAssignable | AssignmentState.Assignable)) |
            ((AssignmentState.Assignable | AssignmentState.NotAssignable) ^ AssignmentState.Assignable) |
            DestructuringState.NotDestructible |
            DestructuringState.Assignable) ^
          (DestructuringState.NotDestructible | DestructuringState.Assignable);
        state.assignable = AssignmentState.NotAssignable;

@fkleuver Your thoughts? I got my experimental code working now. My code is absolutely not optimized or tweaked, so the perf you see in the benchmark is not the finale result But the experimental code does much more validations than Cherow 2.x.

@fkleuver Any timeframe for v. 2.0 release on NPM? Some people want to start using Cherow, and better to let them use v. 2.0.... See gitter for a reference.

It is already possible to try it out by installing cherow@dev for the record. The nightly is publishing directly from master.

Maybe you should mention it on gitter? And implement jsx again?

Maybe you should mention it on gitter?

I did.

And implement jsx again?

Woah. Was it implemented in 1.6?

JSX have always been in Cherow except 2.0. You don't remember that you tried to fix the TS types for JSX before?

@fkleuver Any progress on the v. 2.0 release? See gitter

@fkleuver Any release data for Cherow 2.x yet ?

@KFlash Let's clear something up here. We agreed that I would do performance optimizations, not that I would take over the project and fix your bugs as well. If there were no bugs, it could be released already because performance is just performance. Being slower than 1.6x doesn't block anyone.
If in your opinion it can't be released yet, then what's wrong?

What's was holding back was the fact you talked about rip out the scoping.  If not.  Go ahead and push it to mom.  A minor release can fix performance.
You also mentioned decorators. I guess that can be minor patch as well.

Regarding the REPL you started to work on in may & june 2018. Any progress on it? Do you think it will be useful together with a 2.0 release?

@fkleuver @g-plane Can you publish master to NPM? I can't access the NPM account. And close this ticket.

I can't. Maybe @fkleuver can.

@g-plane Maybe he can. You forgot the password to?

I'm using another operating system and the Node.js haven't been installed.

@fkleuver Any progress on pushing Cherow to NPM?


Support Computed Fields

When defining an API, a user may want to compute a value so it doesn’t have to be computed on the front end. An example would be to compute the distance between two geo points, or return the number of cart entries in a shopping cart. A suite of common functions can be defined so developers can rely on astra apis to solve their needs.
We don't have access to UDA of UDFs in astra but we could include them in the graphql api.

This sounds really complicated.
On the syntax side, we'd have to either have a field for every function, or come up with a construct that allows invoking an arbitrary function, with arbitrary parameters (some of them being columns, but also possibly scalars), and an arbitrary return type. The latter is hard because GraphQL requires strict typing.
On the execution side, we'd have to find out which parameters refer to columns and add them to the query selection, then post-process the result set to compute the function for every row.


Content inside of declarative shadow dom is not rendered

Describe the bug
I am attempting to use a shadow dom tag in leptos and nothing is rendered for the content.  This same html works in a normal html file.
Leptos Dependencies
[package]
name = "leptos-tutorial"
version = "0.1.0"
edition = "2021"

[dependencies]
leptos = { version = "0.6.13", features = ["csr", "nightly"] }

To Reproduce
Steps to reproduce the behavior:

Use shadow dom in leptos

use leptos::*;

fn main() {
    mount_to_body(|| {
        view! {

                <my-component>
                    <template shadowrootmode="open">

"Hello, world!"

                    </template>
                </my-component>

        }
    });
}

Open it in the browser
Notice nothing is rendered

Expected behavior
Shadow dom in declarative shadow dom should render.  It is valid html.
For reference, for the given html,

     <my-component>
        <template shadowrootmode="open">

Hello, world!

        </template>
     </my-component>

It should render  this:

Additional note:  The above styling code works when not inside of declarative shadow dom.

I don't think declarative shadow DOM works in client-side rendering, does it? i.e., if I do this
let tpl = document.createElement("template");
tpl.setAttribute("shadowrootmode", "open");

then tpl.shadowRoot is undefined. Declarative shadow DOM only works while parsing an HTML text:
let working = document.createElement("p");
working.setHTMLUnsafe(`<my-component>
        <template shadowrootmode="open">

Hello, world!

        </template>
     </my-component>`);

This framework works primarily by building up a tree of DOM nodes using ordinary DOM operations (as in the first example), not by parsing from HTML (as in the second example). I would not expect this example to work in this or any other front-end framework that doesn't build in specific support for declarative shadow DOM by special-casing <template>.
(Note also that the "working" version has limited browser support.)

Leptos Dependencies
No extra dependencies.

This section is intended for you to show which version of Leptos you are using, i.e., what your Leptos dependency is.

Sorry for the delay, we had a holiday in Japan yesterday.  For the context of my feature request description, it's black boxing the implementation from the point of view of a user.  Please don't take it as a request for a specific implementation.
From the SSR Side:
Declarative shadow dom is really for the SSR.  If leptos can convert the internal dom tree to html tags it should just work.
From the CSR Side:
For the client rendering it would have to recognize it is shadow dom and traverse inside it to the children.  It's usually not too complicated to implement, but it does require a different logic branch. (I've implemented it for React because the npm libraries that implement it usually are usually garbage.)
I can possibly assist in implementing this if there is interest.  Obviously it would add some complexity which needs to be weighed for its value.
Thank you for the information on the dependencies section, I'll add the toml file.

Thank you! It may take me a month or so as I have to get used to the code base and I am ramping up on rust coming from a typescript/C background.

Thank you for the patience!  I've finally been looking into this the last few days.  (Had a kid born a few days ago, and I'm switching employers this week.)
I'm hoping to have a PR up this week.  It looks like the rendering is working in the first pass.  Including what you said before how it is travesing the dom, it looks like I need to force it to look for  shadowRoot instead of children when the template tag disappears as a child.

This is my personal account for development.

Sounds good, no rush — and congratulations on the child, especially! (and also the job)


Freezing pc

I was in the virtual machine and then all of the sudden the virtual machine froze so I closed it and went to restart it and now every time I try opening up the virtual machine my pc or mouse freezes and the virtual machine never loads and i have to restart my pc

Same

Same too

repatch your usb ports


Test failure with geos 3.9.0

Expected behavior and actual behavior.
The test SvgTestCase.test_collection fails for Shapely 1.7.1 with geos 3.9.0.
======================================================================
FAIL: test_collection (tests.test_svg.SvgTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/builder/package/community/py3-shapely/src/Shapely-1.7.1/tests/test_svg.py", line 176, in test_collection
    self.assertSVG(
  File "/home/builder/package/community/py3-shapely/src/Shapely-1.7.1/tests/test_svg.py", line 41, in assertSVG
    self.assertEqual(svg_elem, expected)
AssertionError: '<g><polyline fill="none" stroke="#66cc99" str[158 chars]</g>' != '<g><circle cx="7.0" cy="3.0" r="3.0" stroke="[158 chars]</g>'
- <g><polyline fill="none" stroke="#66cc99" stroke-width="2.0" points="4.0,2.0 8.0,4.0" opacity="0.8" /><circle cx="7.0" cy="3.0" r="3.0" stroke="#555555" stroke-width="1.0" fill="#66cc99" opacity="0.6" /></g>
+ <g><circle cx="7.0" cy="3.0" r="3.0" stroke="#555555" stroke-width="1.0" fill="#66cc99" opacity="0.6" /><polyline fill="none" stroke="#66cc99" stroke-width="2.0" points="4.0,2.0 8.0,4.0" opacity="0.8" /></g>

So just the order of the polyline and the circle in the SVG changed.
Steps to reproduce the problem.
Use python3 setup.py build
Operating system
Alpine Linux Edge
Shapely version and provenance
Shapely 1.7.1

Yes, the coordinate pair order has changed for several operations in GEOS 3.9.0, and hence causing some failures in existing tests.
This has been fixed in the meantime: https://github.com/Toblerity/Shapely/pull/1042 (note that it is only the test itself that failed due to a slightly changed expected result, there is no actualy runtime failure when using Shapely 1.7 with GEOS 3.9.0)

@jorisvandenbossche thanks for the explanation! @hjaekel there will be a fix when 1.8.0 is released. That's a little ways out yet.


Incorrect region for the S3 location for the Lambda function

Hi
I'm (hopefully) following the instruction.
I encountered the below issue while creating the stack.
Error occurred while GetObject. S3 Error Code: AuthorizationHeaderMalformed. S3 Error Message: The authorization header is malformed; the region 'us-east-1' is wrong; expecting 'ap-southeast-2' (Service: AWSLambdaInternal; Status Code: 400; Error Code: InvalidParameterValueException; Request ID: 4f02d0d7-e5ee-4971-94c2-dc837b35e620)
I've rebuild the release using
AWS_REGION="ap-southeast-2" LAMBDA_NAME="cloudwatch-to-slack" make deploy
I've changed the CF template to
Timeout: 15 # Cross-region metrics lookup requires at least 10s
Code:
  S3Bucket: xxxx-xxx-xxxxxxx
  S3Key: Lambda/release.zip

are you able to provide some assistance please?

Apologies! Face plant moment. Assumptions are evil!
I spun up the Template in the wrong region

Gotcha, thank you for closing the loop!


Add support for linear vector addition

Add LVec struct with support for addition operations. Addition is only defined over references so LVec variables are only borrowed when used in an addition operation.

Merged bypassing 1-approver rule.


Missing "pins" namespace

Would you be so kind to add some more methods for "pins" namespace, as it described in
https://api.slack.com/methods/pins.add
https://api.slack.com/methods/pins.list
https://api.slack.com/methods/pins.remove ?

I also made pull request #14

Thank you for PR.
I'll follow latest API, soon.

I released version 0.09 includes pins namespace.
Some namespaces aren't included in this version yet.
I will work for remaining namespaces in a few days.


GPII-4259: Remove "noMerge" from base grade.

See GPII-4259 for details.

No idea what happened, let's get another data point.  ok to test.

The CI failures were a variation on GPII-4145.  I have disabled Firefox for now.
There were unique issues in IE as well, but I assume we're no longer supporting that?


cache.put always fired

Hi,
thanks for sharing this great tool.
I've a question:
is there a specific reason for having cache.put fired also when the response is already in cache (previous cache.match)?
Thanks!

Hi, thanks for the report!
I don't think there is a reason, I'll fix it now.

Fixed by 9f97dfcc37dc95d6a758660e0b625ba0ee3f95ab. Thanks!