Stepper rework as variable

This PR is to convert the stepper construction to using the variable blocks.
Reasoning:

I want to reuse the stepper mechanism for other components. However, the current method in stepper is for stepper only, so this PR creates a general mechanism that needs to be reused for other components

The core part is a version of field_variable, that only shows variables of a specific component type. This can be stepper now, but in the future also ledstrip, IR_Sensor, ... .

In making the construct general, I converted it to the stepper name being a variable like the other variables present. This has the benefit that where previously it looked like a variable but wasn't, it now looks like it, and is it also. So rename is now working, which is a big benefit.

What is contained in the variable? A component is connected to an Arduino via pins, so the variable is the pin to which the component is connected. This will/might be useful for other components like a LED strip, but for stepper it means it is an array of two pins (as stepper connects to two pins). I don't see a use for this at the moment, but it also is not a problem, it is not because a variable exists that one has to use the variable. If array methods are added like in the mdxly fork, then one could query the first or second pin, and send specific commands to those pins as needed. It being a variable means it shows up in the variable blocks, which was the aim, as this allows to do things like digitalwrite, ... via variables (in my branch).

The aim is now to add extra components.

Oh, this is really interesting! I've been meaning to refactor the current stepper implementation for ages, it was a "temporary workaround" for a workshop that ended up in the codebase far longer than  anticipated.
It's a bit late to have a proper look now, but i'll check it out as soon as I can. Quick question based purely on the general description, would this result in the stepper variable name to appear in the variable block dropdown?

Yes, I choose to have it appears in the variable block dropdown. Removing it there would mean more changes in core. As it contains a value (the pins the stepper is connected to), it can be a variable. For stepper it is array of two pins, which we cannot do much with, but for other components (button, ledstrip, ...) it is the pinnumber. I don't see a big need to work with these variables, but it is something I can think some interesting applications for.

Thanks for the submission, looks quite good, I've added a few minor comments.
I've been thinking about this and I quite like the idea of having a mechanism to store global "lists of things" that can be displayed on dropdowns, however I'm not quite sure they should be variables. In a lot of cases we are basically creating class instances, and while they are stored in variables, these are not variables that could be used in any other blockly "variable" context. So I think we should separate this completely from the variable class, while mirroring the functionality and allowing to create different isolated categories.

Well, the fact that they are variables fits with my overarching idea of assigning pins to variables, then using the variables to do writes/reads. So I need these variables to be able to do this, they should not be something special, but behave like the variables that have values of pins, so I can use them.
My overall plan for how I want to have children work with our projects is like this:

put a hub component on the board: eg an UNO, which will be a block where parts can be added:
Hub component UNO. Attach to digital pin <dropdown_pin_numbers>:
The nice thing here is that I will set Arduino.Board.selected automatically like that, no longer settings section needed then. What is also nice for the children is that as you give a manual of a project with how to build with breadboard, you can give these HUB block parts as a way to visualize it in blockly.

Then one can attach to hub components actual components: LED, LEDSTRIP, SERVO, ... which all use the scheme in this PR to obtain a variable value. Attaching it to the hub sets the pin value. A component would also have a block like SERVO now, where you set the pin in the block itself.

So, next one can use the variable to do things, or use the pin numbers. Using the variable in the dropdown of eg digitalwrite requires that it has something special to appear there, like in the #70 At the moment my branch has actual variable digitalwrite versions, so I use this.

So, a somewhat roundabout way to use the variables. It is not really needed to do this (eg in ardublockly GUI you could not expose components that assign to a hub, and only use components that set variable and pin in the block. All will work like that.

Main takeaway is, if the assigned names are not variables with pin number in it, you can only use predefined blocks like eg a new simple block for young children: set LED <LEDNAME_VARIABLE> ON/OFF. If LEDNAME_VARIABLE is a real variable, you can also use the digitalwrite function (in my branch with extended digitalwrite that allows a variable to determine the pin, in the future hopefully standard digitalwrite with this variable in the dropdown list). As you might want to make a runlight over 4 LED, changing the variable for digitalwrite is what you want to be able to do, as that allows for compact, simple code, so variables used in this way must be settable, and by extension hence also the variables set in the component blocks.

If we mantain this idea of "instances of things" separated from variables, you could still assign a "thing instance" to a variable and use it as you are describing, no?

Yes. Extra block needed on the canvas to describe it though. Although it are different things, variables already are different things now too (number, decimal, string ...).
I'm not convinced these variables to be separate from the other variables brings something extra to the table.

Ok, tackled most issues, inheritance can indeed be simplified. Not a js coder though, so I hope I follow the correct paradigm ...
I'll do these changes in my branch where I use this construct more extensively for further testing.

To have an idea how this looks when having many constructs that use this, see example:
http://ingegno.be/Manuals/Blockly4Arduino/blockly4Arduino/index_en.html?url=examples/MD_Caroussel_Muziek.xml
So, if you add a variable there, then the dropdown of the variable has all those names. Is that a problem or cumbersome? If you work with variables you typically set it once, and then use copy/paste to have other copies, so the fact that the dropdown contains more is not really a problem.
If we have a way to identify which variables are pins, then all those should be present in the dropdownbox of a digitalwrite or read.

Thanks a lot for all your contributions @bmcage . I'll finally have some time to look into this properly, for now I've merged into master and started playing with it locally, I'll let you know how it goes as I might think about creating this "instances of things" system based on the same concept as blockly variables.

As I mentioned in the earlier discussions, I finally had some time to add some kind of "instance" implementation that can be used to create custom dropdowns. It's not finished, and needs some work to fix a couple of minor issues, but the bulk is in there: https://github.com/carlosperate/ardublockly/commit/c757d75abc5cc795ff7af6ce189bc761c6bfdf6b
You can see that blocks can now do a new Blockly.FieldInstance() and based on the input arguments everything else should be taken care of.
@bmcage I was wondering what was the reason to add a global array for the stepper pins in this PR.
Using the stepper config block creates a global int MyStepper[2] = {1, 2};, which is really not used for anything else?

The stepper is special in attaching to two pins. For components that attach to one pin, this global is an integer and can be easily used in blocks.
For the Stepper this is not directly possible. One could create functions though that work on the pins of a stepper, and then passing a stepper means the function can use the MyStepper global to access these pins, knowing that global exist.
So it is a design choice to always create a global with the pins of a component. If it was an LCD, it would be a longer array. In reality, a component hopefully has a library with one init function, and one can pass the pins once, and forget about them, making this global unneeded for actual use as the functions are then library functions.
PS: almost in holiday mode, so slow posting ...


Add License informtion

Hello,
I would like to use this repository in the firm and but not finding anyt licece information.it would be great if  you can  add a licence in to it.

@arunbpt7 added Apache 2 license

Excellent, thank you


Add HTTP::Cookies#to_h method

HTTP::Cookies#to_h from Enumerable was broken.

Looks good. I would just add in the comments that it returns the underlying hash used by the Cookies object, so changes to it will be visible in that object (a copy is not returned).

I'm actually leaning towards returning a copy, that eases future compatibility when changing the internal structure.

Okay, I will correct it in the next commit.

Done?..

Could you rebase and squash your commits into one please?

I tried :)

Thanks!


AttributeError: module 'quant_cuda' has no attribute 'vecquant4recons'

I got my 30b model trained, it took 40 hours
I got the monkey patch setup correctly
all the paths are happy
finally I have an error in my text-generation-webui logs
Exception in thread Thread-3 (gentask):
Traceback (most recent call last):
  File "/home/eric/miniconda3/envs/textgen/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
    self.run()
  File "/home/eric/miniconda3/envs/textgen/lib/python3.10/threading.py", line 953, in run
    self._target(*self._args, **self._kwargs)
  File "/home/eric/git/alpaca_lora_4bit/text-generation-webui/modules/callbacks.py", line 63, in gentask
    ret = self.mfunc(callback=_callback, **self.kwargs)
  File "/home/eric/git/alpaca_lora_4bit/text-generation-webui/modules/text_generation.py", line 218, in generate_with_callback
    shared.model.generate(**kwargs)
  File "/home/eric/git/alpaca_lora_4bit/text-generation-webui/../repository/peft/src/peft/peft_model.py", line 581, in generate
    outputs = self.base_model.generate(**kwargs)
  File "/home/eric/miniconda3/envs/textgen/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
    return func(*args, **kwargs)
  File "/home/eric/git/alpaca_lora_4bit/text-generation-webui/../repository/transformers/src/transformers/generation/utils.py", line 1462, in generate
    return self.sample(
  File "/home/eric/git/alpaca_lora_4bit/text-generation-webui/../repository/transformers/src/transformers/generation/utils.py", line 2478, in sample
    outputs = self(
  File "/home/eric/miniconda3/envs/textgen/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/home/eric/miniconda3/envs/textgen/lib/python3.10/site-packages/accelerate/hooks.py", line 165, in new_forward
    output = old_forward(*args, **kwargs)
  File "/home/eric/git/alpaca_lora_4bit/text-generation-webui/../repository/transformers/src/transformers/models/llama/modeling_llama.py", line 765, in forward
    outputs = self.model(
  File "/home/eric/miniconda3/envs/textgen/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/home/eric/miniconda3/envs/textgen/lib/python3.10/site-packages/accelerate/hooks.py", line 165, in new_forward
    output = old_forward(*args, **kwargs)
  File "/home/eric/git/alpaca_lora_4bit/text-generation-webui/../repository/transformers/src/transformers/models/llama/modeling_llama.py", line 614, in forward
    layer_outputs = decoder_layer(
  File "/home/eric/miniconda3/envs/textgen/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/home/eric/miniconda3/envs/textgen/lib/python3.10/site-packages/accelerate/hooks.py", line 165, in new_forward
    output = old_forward(*args, **kwargs)
  File "/home/eric/git/alpaca_lora_4bit/text-generation-webui/../repository/transformers/src/transformers/models/llama/modeling_llama.py", line 309, in forward
    hidden_states, self_attn_weights, present_key_value = self.self_attn(
  File "/home/eric/miniconda3/envs/textgen/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/home/eric/miniconda3/envs/textgen/lib/python3.10/site-packages/accelerate/hooks.py", line 165, in new_forward
    output = old_forward(*args, **kwargs)
  File "/home/eric/git/alpaca_lora_4bit/text-generation-webui/../repository/transformers/src/transformers/models/llama/modeling_llama.py", line 209, in forward
    query_states = self.q_proj(hidden_states).view(bsz, q_len, self.num_heads, self.head_dim).transpose(1, 2)
  File "/home/eric/miniconda3/envs/textgen/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1501, in _call_impl
    return forward_call(*args, **kwargs)
  File "/home/eric/miniconda3/envs/textgen/lib/python3.10/site-packages/accelerate/hooks.py", line 165, in new_forward
    output = old_forward(*args, **kwargs)
  File "/home/eric/git/alpaca_lora_4bit/text-generation-webui/../repository/peft/src/peft/tuners/lora.py", line 682, in forward
    result = super().forward(x)
  File "/home/eric/git/alpaca_lora_4bit/text-generation-webui/../repository/GPTQ-for-LLaMa/autograd_4bit.py", line 162, in forward
    out = fast_4bit_forward(x, self.qweight, self.scales, self.zeros, self.bias)
  File "/home/eric/git/alpaca_lora_4bit/text-generation-webui/../repository/GPTQ-for-LLaMa/autograd_4bit.py", line 114, in fast_4bit_forward
    quant.quant_cuda.vecquant4recons(qweight, buffer, scales, zeros)
AttributeError: module 'quant_cuda' has no attribute 'vecquant4recons'

Any idea what could cause this?  I tried reinstalling quant_cuda and that didn't fix it.
It does seem to load the model correctly
===================================BUG REPORT===================================
Welcome to bitsandbytes. For bug reports, please submit your error trace to: https://github.com/TimDettmers/bitsandbytes/issues
================================================================================
CUDA SETUP: CUDA runtime path found: /home/eric/miniconda3/envs/textgen/lib/libcudart.so
CUDA SETUP: Highest compute capability among GPUs detected: 8.9
CUDA SETUP: Detected CUDA version 117
CUDA SETUP: Loading binary /home/eric/miniconda3/envs/textgen/lib/python3.10/site-packages/bitsandbytes/libbitsandbytes_cuda117.so...
Monkey Patch Completed.
Loading ../llama-30b-4bit.pt ...
Loading Model ...
Loaded the model in 31.61 seconds.
../alpaca_lora/ Lora Applied.
Apply auto switch and half
/home/eric/miniconda3/envs/textgen/lib/python3.10/site-packages/gradio/deprecation.py:40: UserWarning: The 'type' parameter has been deprecated. Use the Number component instead.
  warnings.warn(value)
Running on local URL:  http://<IP_ADDRESS>:7860

I've had this problem a bunch of times messing with different versions of GPTQ, Python, CUDA and more. All this quantized LLaMA stuff is experimental and unfinished, and very much a dependency nightmare. At least until maybe this stuff makes it into Transformers sometime, in a more finished state.
Anyway, the fact that it complains about vecquant4recons and not vecquant2matmul suggests you've got an older version of quant-cuda installed. You could also have multiple versions, with the wrong version taking priority somehow. They all show up as version 0.0.0 right now, so it can be hard to tell.
I would suggest pip uninstall quant_cuda, and running python setyp.py install from the repo downloaded by the installer. Make sure to delete the build directory inside that repo, to force a clean rebuild of the CUDA module. If that doesn't help, start over with a fresh conda environment maybe.

I'll start again from scratch and see if it still happens

Now I have a different error... closing this.


[TH18, TH19] Window opens, then almost immediately closes when running lang_en patch on Wine

The games run fine in Steam. I have tried:

Validating the game files (they were fine)
earlier games (found this on th19, same thing happens on th18, th17 and lower are fine)
Looking at the logs (seems like there's files missing, but I don't know where to get them)
32-bit wineprefix (same problem)
Proton (No arguments)
Standalone patch (Still same errors)
Different resolutions (borderless dot by dot, windowed 1280x920)

System Info:
Artix Linux kernel 6.3.2-zen1-1-zen
Wine 8.8 staging
Logs (Unmarked are th19):
thcrap-th18_log.1.txt
thcrap-th18_log.2.txt
thcrap-th18_log.txt
thcrap_log.1.txt
thcrap_log.2.txt
thcrap_log.txt

Update: Removed patches individually to try to find what causes it, all of them were removed and TH18 still didn't start with the standalone. Also of note is both are through Steam with Steam on the beta branch

Works on my end with both wine 7.7 and wine 8.8.
Can you open the thcrap configuration tool, click on "Configure Settings", select "Enhanced" under Exception Detail, save, try again, and send the logs?

Sadly I can only use the old version of 'thcrap_configure.exe' because I either can't install .NET 4.6.1 on a 64bit prefix or it gives me a black screen with the message 0148:err:d3d:wined3d_context_gl_update_window Failed to get a device context for window 006083B0. in a 32bit prefix. Is there another way to change the exception detail?

Yes, open config/config.js, and set "exception_detail" to 103

Here are the new logs, thanks for the help by the way
thcrap_log.1.txt
thcrap_log.2.txt
thcrap_log.txt

I understand this is a relatively small issue, but is there anything I can do while you work on more important issues?

Update:
It works now, for whatever reason. My guess is something with my controller being overridden and connected as a directinput device instead of xinput, but the game still worked fine even without that. Maybe it's from me messing around with VK_ICD_FILENAMES, but it looks like I already tried that.


Epoch/lockup module bug fix and grpc chores

Add a few simple grpc to the pool-incentives module
Fix bug within the lockup module where amino isn't registered internally, leading to amino transaction not being able to be sent
Modify so that lockup module's grpc supports http gateway
Fix bug where epoch module's Begin, EndBlocker isn't actually registered and doesn't run when chain is live

You can ignore the parts where the swagger docs are updated.

Can you fix the swagger docs conflict, then its good to merge imo


clean_tmpdisk.py: filter squeue for worker_node

I agree, but I like keeping it and having the double check


⚠ Mobitopup has degraded performance

In d083730, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 4201 ms

Resolved: Mobitopup performance has improved in cc23724.


[tie] add wind effect

This turned out to be more complicated than expected, and I ended up implementing an instanced renderer for the instances with wind. Unlike the original game, we do the wind math in the graphics thread.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 301 (0.0%)  changed or added relevant lines in 6 files are covered.
10 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.2%) to 53.246%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

decompiler/level_extractor/BspHeader.cpp
0
1
0.0%

common/custom_data/Tfrag3Data.h
0
2
0.0%

decompiler/level_extractor/extract_tfrag.cpp
0
10
0.0%

common/custom_data/TFrag3Data.cpp
0
22
0.0%

decompiler/level_extractor/extract_tie.cpp
0
125
0.0%

game/graphics/opengl_renderer/tfrag/Tie3.cpp
0
141
0.0%

Files with Coverage Reduction
New Missed Lines
%

game/graphics/opengl_renderer/tfrag/Tie3.cpp
1
0%

goalc/listener/Listener.cpp
3
84.35%

decompiler/level_extractor/extract_tie.cpp
6
0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.2%

Covered Lines:
40850

Relevant Lines:
76720

💛  - Coveralls


remove installation from batch

@gmalinve I think you should also remove the batch file from the repo?, it is under doc/source/Resources


Allow read split behavior overrides

Iceberg exposes the following read path properties as of today:
read.split.target-size
read.split.planning-lookback
read.split.open-file-cost
However, these properties must be set at the Table.properties() level to be effective.
In this PR, we allow these read flags to override behavior of a Scan object:
TableScan scan = table.newScan()
        .splitOptions(
            new SplitOptions()
                .splitSize(256L * 1024 * 1024));

They can also be passed in as a DataFrameReader option:
Dataset<Row> resultDf = spark.read()
    .format("iceberg")
    .option(TableProperties.SPLIT_SIZE, String.valueOf(256L * 1024 * 1024))
    .load(tableLocation);

retest

Not sure how to retest. Failed tests do look unrelated, caused by a java.net.SocketException.

I restarted the tests. The Hive tests are a little flaky right now.

Merged. Thanks @xabriel!


short email address not normalizing

<EMAIL_ADDRESS>correctly normalizes to<EMAIL_ADDRESS>However
<EMAIL_ADDRESS>normalizes to<EMAIL_ADDRESS>instead of<EMAIL_ADDRESS>

@milobob The first part of the address may be case sensitive (RFC 5336). See this PR

So I'm not as much of an expert as you, I don't know what RFC 5336 is, but google email addresses are not case sensitive and so the go-email-normalizer is not solving the problem of duplicate email addresses on my server from google email addresses.
I did find a workaround, and that's to do:
n := normalizer.NewNormalizer()
//email with uppercase case and dots removed to be unique
emailLowerCasePre := n.Normalize(userEmail)
emailLowerCase := strings.ToLower(emailLowerCasePre) //normalizer should automatically do this but it doesn't seem to for short email addresses

@milobob go-email-normalizer has separate rule https://github.com/dimuska139/go-email-normalizer/blob/master/google_rule.go for domains gmail.com, googlemail.com and google.com. This rule converts the first part of email address (before @) to lowercase and cuts it to a plus sign.
Can you provide you google emails as an example (slightly change them for safety)? Maybe I missed some domain...

ohhh I see! I am using @companydomain.com where my companydomain is connected to google workspace! So maybe I need to make a custom rule for the companydomain?

@milobob you can just add Google rule to you companydomain:
package main

import (
	"fmt"

	normalizer "github.com/dimuska139/go-email-normalizer"
)

func main() {
	n := normalizer.NewNormalizer()
	n.AddRule("companydomain.com", &normalizer.GoogleRule{})
<EMAIL_ADDRESS>== n.Normalize("TeStgoOgle+test@companydomain.com")) // true
}

uh oh... that changes:
<EMAIL_ADDRESS>to<EMAIL_ADDRESS>I'll just stick with my ToLower hack!

@milobob Are you worried about domain changing to gmail.com? There is no way to compare<EMAIL_ADDRESS>and<EMAIL_ADDRESS>(this is the same email addresses) without it. This library converts email addresses to the normalized form - so domain in result (after normalizing) should not be different.

n.AddRule("companydomain.com", &normalizer.GoogleRule{})
<EMAIL_ADDRESS> results in<EMAIL_ADDRESS>so it changes the email domain. So I'll stick to the ToLower hack!

I don't want an account for<EMAIL_ADDRESS>to be stored on my server as<EMAIL_ADDRESS>

@milobob you should use the normalized version of the email address only for internal usage. You should not display it in UI. So you can use something like this users table structure in your database: id (pk), key (normalized email, id from social network etc), registration_type (via email address + password, using facebook etc), email (user's real email). Also You should create composite unique index on fields "key" and "registration_type". When the user tries to create an account on site (using email and password authentication), you should normalize his email address and check the existence in the database by fields key and registration_type (for ex: SELECT * FROM users WHERE key='' AND registration_type='email+password'). Thus, the "email" field (in users table) is only needed to be displayed in the user interface. It is not used in the duplicate checking logic. So the email domain does not matter, because the user will not see it.


Remove declares statement if empty

Added

Let declares stmt be gone when there's nothing being declared

Cool! Thanks!


refactor code with hooks

refactored code to functional programing
refactored calculator.js component from class-based components to functional-based components while using hooks

Hi @xtrahuman 👋,
Your project is complete!  There is nothing else to say other than... it's time to merge it :shipit:
Congratulations! 🎉

Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.

As described in the Code reviews limits policy  you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.


Write/publish all online docs on cloud site

I know there's an internal bug tracking this work, but here's an external bug so we don't forget about it either.
This issue is to track the work needed to write and publish all the necessary documentation on https://cloud.google.com/spanner/.
/cc @mmmarklu

/cc @antfitch

This is done: https://cloud.google.com/spanner/docs


Add r flag to fix issue #13

As the r flag(recursive file searching) was missing in the JSON file, running gf  was causing an error and output is "grep: .: Is a directory". So I added r flag on each pattern file.

this creates error when it is piped with urls
seems this tool is broken

Do you mean, it creates an error when the r flag is added or without it?

try changing it with -HnriE

try changing it with -HnriE

grep -RiIl '"-iE"' | xargs sed -i 's/"-iE"/"-HnriE"/g'

So it is possible to modify all files at once


Using custom tags as keys?

Thanks for this library, this looks awesome and I'm going to play with it a bit.
Can we use custom tags as keys? i.e.:
foo:
    !bar: Hello

Yes, custom tags are supported. To use them with YAML.parse, you'll need to define them in YAML.defaultOptions.tags, but with YAML.parseDocument you can get the AST and handle it yourself. Note that there'll be an entry in doc.warnings about the fallback to string due to the missing tag.
Just to clarify your example, according to the spec it's parsed as a mapping with a key foo and a value Hello that has the tag !bar:. If there was a space before the :, the value would be parsed as a mapping with an empty key that has the tag !bar, and the value Hello. Is one of those what you intended to mean?

No I don't think so 😕
What I'm looking for is something that would parse to something like (in pseudo-JS code):
{
  foo: new Map([
    [ new Baz, 'Hello' ]
  ])
}

Not sure this can even be expressed in yaml though.

Yes, that can be represented in YAML. What you're looking for is a custom schema for your data, i.e. a way of telling the parser that this particular thing should be represented by a Map, and this other thing by a Baz.
For Map you'd probably want to customise the built-in !!map parser's toJSON method to produce a Map rather than an Object. Arguably this would make sense to implement as a configurable option, for which I'll add a separate issue. In the meantime, you can avoid the string-key issue by using YAML.parseDocument rather than YAML.parse, as the internal representation of a map does not have this issue.
For Baz a custom local tag like !baz is the right answer. To implement that, take a look at how e.g. the !!binary tag is implemented; there's a link from the Custom tags section of the docs. If you don't need to stringify your data, you don't need to implement a stringify() function, just the resolve().
With all of that, you'd end up with this YAML representation of your data:
foo:
  !baz : Hello


Feature request: set update interval

It would be nice to add support for changing the update interval. Like top, a key (d and/or s?) could be used to change the refresh interval from the default value to another value.
Also, if that feature is added, perhaps the default refresh interval can be increase to 3.0 seconds, like top?
If that sounds like something that would add value to the project, I can start working on it.

Update interval would be nice; however, in the case we would only be changing the screen refresh interval, as docker stat collection still has a static stream interval of per-second.

@aleveille do you still think update interval is setting is still relevant? Reading @bcicen answer, you could set only how often UI refreshes, so basically you could only set it to refresh less often than every second. And even that wouldn't speed up, or save resources (docker stat will still send every second). Is that correct @bcicen ?


JSON fields output not following the same order as defined

If I define a preparer like this:
preparer = FieldsPreparer(fields={
    'id': 'id',
    'city': 'city',
    'state': 'state'
})

The JSON output:
'{"objects": [{"city": "Sao Paulo",  "state": "SP", "id": 1}]}'

And I think the fields should be in the same order as I defined them. Is there a way to change this behavior?
By the way, this happens if I use an OrderedDict .

No response? Really?

Ordering is not guaranteed in JSON, as per the spec.


[FLINK-21030][runtime] Backport of FLINK-21030 to release-1.12

What is the purpose of the change
Applies FLINK-21030 related changes of PR #14847 to the release-1.12 branch.
Brief change log
I only skipped cherry-picking 6fd59e3 as it is based on some refactoring in master post-1.12
Verifying this change
Rerun changed tests locally
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: yes
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? not applicable

The failed test seems to be unrelated: https://issues.apache.org/jira/browse/FLINK-21518. Merging this PR now.

Manually merged via e9af362f0caa16e75e66aa1403c62666e77f98f0


Implement GraphQL Endpoint

Description
⚠ Depends on Django 3.2 or later, so on hold until the project is upgraded to a newer version.
Implement Strawberry + Strawberry Django Plus to provide a GraphQL endpoint to query the models.
Early agenda tests shows a 10x performance improvement compared to the current implementation.
Would replace temporary REST endpoint implementation:
https://github.com/ietf-tools/datatracker/blob/main/ietf/meeting/views.py#L1596
Code of Conduct

[X] I agree to follow the IETF's Code of Conduct

Closing this as OBE. We might use strawberry or another graphql endpoint for specialized APIs, but will track that with another issue.


Bicep or Terraform?
Bicep
Module Classification?
Resource Module
Module Name
avm/res/sql/server
Module Details
This module was previously owned by @bryansan-msft. When a new owner volunteers, the related GitHub teams need to be handed over by Bryan.
Original module proposal: https://github.com/Azure/Azure-Verified-Modules/issues/295
Do you want to be the new owner of this module?
No
Module Owner's GitHub Username (handle)
No response
(Optional) Secondary Module Owner's GitHub Username (handle)
No response

I am willing to take the maintenance on this module.

Hi @emichellecarter,
Thanks for requesting/proposing to be an AVM module owner!
We just want to confirm you agree to the below pages that define what module ownership means:

Team Definitions & RACI
Shared Specification (Bicep & Terraform)
Module Support

Any questions or clarifications needed, let us know!
If you agree, please just reply to this issue with the exact sentence below (as this helps with our automation 👍):
"I CONFIRM I WISH TO OWN THIS AVM MODULE AND UNDERSTAND THE REQUIREMENTS AND DEFINITION OF A MODULE OWNER"
Thanks,
The AVM Core Team
#RR

Can we get confirmation that this module is no longer orphaned? The README file still indicate that it still is.
Thanks!

Hi @send-itDuong, the ownership is not yet transferred to @emichellecarter as her response to the above is still pending.

I CONFIRM I WISH TO OWN THIS AVM MODULE AND UNDERSTAND THE REQUIREMENTS AND DEFINITION OF A MODULE OWNER.  Thank you

Hi @emichellecarter,
Thanks for confirming that you wish to own this AVM module and understand the related requirements and responsibilities!
Before starting development, please ensure ALL the following requirements are met.
Please use the following values explicitly as provided in the module index page:

For your module:

ModuleName - for naming your module
TelemetryIdPrefix - for your module's telemetry

For your module's repository:

Repo name and folder path are defined in RepoURL
Create GitHub teams for module owners and contributors and grant them permissions as outlined here.
Grant permissions for the AVM core team and PG teams on your GitHub repo as described here.

Check if this module exists in the other IaC language. If so, collaborate with the other owner for consistency. 👍
You can now start the development of this module! ✅ Happy coding! 🎉
Please respond to this comment and request a review from the AVM core team once your module is ready to be published! Please include a link pointing to your PR, once available. 🙏
Any further questions or clarifications needed, let us know!
Thanks,
The AVM Core Team

@bryansan-msft, can you please hand over the ownership of the 2 related GitHub teams to @emichellecarter?
@emichellecarter, can you Please also remove the ORPHANED.md file from the module's folder and its content from the README.md, by following the steps described in point 5 here and let me know in a comment when this is done. Thanks!

@bryansan-msft, thanks for letting me know. With no members remaining in these two teams, we lost access to them, so we'll need to involve GH support, which might take longer. I'll take care of this.

 I am sure you can add him yourself

That's what we'd all hope for, but unfortunately that's not how teams work in GitHub. :) We've run into this once, and managed to solve it, so it will be fixed this time, it's just going to take some time. But don't worry about this, I'll handle it.

@emichellecarter, the request just went through. You should now be a maintainer in both teams. Please let me know when the orphaned.md file is updated too, so we can close this issue. Thank you!

@matebarabas : Would it make sense to have two co-owners for this module? If yes, I'd be interested

@peterbud, each module can have 1 owner (primary owner), 1 co-owner (secondary owner), and any number of contributors. As @emichellecarter is now the owner of this module, you can definitely be its secondary owner. Should I sign you up?
PS: @emichellecarter, I can see the orphaned.md has been updated, so I'm closing this issue now.

Yes, pls sign me up


Not picking up prettier installed via yarn pnp properly when using melpa package

I'm seeing a weird thing where the pnp install isn't picked up if I start emacs in the project root, but it works if I start emacs one directory closer to the file being edited.
afaict this is due to the apheleia-npx script not knowing where the file to be formatted is (buffer contents are piped to it so apheleia can work when there's no filename associated with the buffer)
I'm thinking the thing to do here is rewrite apheleia-npx as an elisp function; I'll tinker a bit and put a PR in if it works well

OK now I can't repo the behavior, closing.

The filename shouldn't matter, as apheleia-npx works based on working directory, which should always be set.


0.1110.0 has breaking changes with no migration guide?

We adopted playwright-test at the suggestion of @dgozman on April 8. It's been awesome and we're really happy we switched over from jest-playwright ♥
However, now we see that this project is not considered ready for production as of 22 days ago.
And now that playwright v1.11.0 is out, we were planning to upgrade but it seems there are breaking changes?
As a user, it's hard to know if I should file this issue here, or in playwright or folio.
Before, we had a configuration file like this:
config.js

Click to toggle contents of `config.js`
import {
  ChromiumEnv,
  FirefoxEnv,
  WebKitEnv,
  test,
  setConfig,
  PlaywrightOptions,
  Config,
  globalSetup,
} from "@playwright/test"
import * as crypto from "crypto"
import path from "path"
import { PASSWORD } from "./utils/constants"
import * as wtfnode from "./utils/wtfnode"

// Playwright doesn't like that ../src/node/util has an enum in it
// so I had to copy hash in separately
const hash = (str: string): string => {
  return crypto.createHash("sha256").update(str).digest("hex")
}

const cookieToStore = {
  sameSite: "Lax" as const,
  name: "key",
  value: hash(PASSWORD),
  domain: "localhost",
  path: "/",
  expires: -1,
  httpOnly: false,
  secure: false,
}

globalSetup(async () => {
  console.log("\n🚨 Running globalSetup for playwright end-to-end tests")
  console.log("👋 Please hang tight...")

  if (process.env.WTF_NODE) {
    wtfnode.setup()
  }

  const storage = {
    cookies: [cookieToStore],
  }

  // Save storage state and store as an env variable
  // More info: https://playwright.dev/docs/auth?_highlight=authe#reuse-authentication-state
  process.env.STORAGE = JSON.stringify(storage)
  console.log("✅ globalSetup is now complete.")
})

const config: Config = {
  testDir: path.join(__dirname, "e2e"), // Search for tests in this directory.
  timeout: 60000, // Each test is given 60 seconds.
  retries: 3, // Retry failing tests 2 times
  workers: 1,
}

if (process.env.CI) {
  // In CI, retry failing tests 2 times
  // in the event of flakiness
  config.retries = 2
}

setConfig(config)

const options: PlaywrightOptions = {
  headless: true, // Run tests in headless browsers.
  video: "on",
}

// Run tests in three browsers.
test.runWith(new ChromiumEnv(options), { tag: "chromium" })
test.runWith(new FirefoxEnv(options), { tag: "firefox" })
test.runWith(new WebKitEnv(options), { tag: "webkit" })

See file here.
Breaking Changes
Here are the breaking changes we've noticed:

folio prints error --config=config.ts https://github.com/microsoft/folio/issues/210#issuecomment-841415055
@playwright/test no longer exports ChromiumEnv, FirefoxEnv, WebKitEnv, setConfig, PlaywrightOptions, Config, globalSetup

We completely understand that this is an early project and we're happy to support and use it because it makes end-to-end testing easier for us, but would love if you could help us by documenting any breaking changes and providing a proper guide to migrate/upgrade appropriately.

@jsjoeio Sorry for confusion! You have migrated to the experimental version, and that gave us a lot of feedback - thank you! We are busy addressing that feedback and more, and meanwhile released 0.1110.0 to keep up with the recent Playwright release (using the old api and old underlying folio framework).
Configs and new stuff will be available at the next big release for playwright-test, so you won't have to update much, since you are already on the experimental version. Currently, we are developing under next label on the npm to avoid frequent breakages. With that release we'll also publish migration guide.
Hopefully, this clarifies the situation. I am happy to answer any questions here.

Thanks for the quick reply. Totally make sense.

With that release we'll also publish migration guide.

Really glad to hear that.

next big release for playwright-test

I'll subscribe to the Releases so I get notified when that comes out. Thanks @dgozman!


Stormblessed: Watch CIOB

Stormblessed requests the watch of the watch_keyword CIOB. See the MS search here and the Stack Exchange search here.

CIOB has been seen in 2 true positives, 2 false positives, and 0 NAAs.

Approved by tripleee in Charcoal HQ


python3.pkgs.browser-cookie3: unbreak on darwin

Description of changes
This seems to build fine locally for me.
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[x] x86_64-darwin
[x] aarch64-darwin

[x] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@ofborg build python310Package.browser-cookie3 python311Package.browser-cookie3

https://github.com/ofborg build python310Packages.browser-cookie3 python311Packages.browser-cookie3


Add support for Linux ID-mapped mounts

The Linux kernel 5.12 introduces a feature called "ID-mapped mounts", which is a kernel-native replacement to the shiftfs module currently used by Sysbox.
This Epic calls for adding support for ID-mapped mounts in Sysbox.

As of v0.5.0, Sysbox now supports ID-mapped mounts.
Note however that the Linux ID-mapped mount mechanism still has some limitations such as:

Can't be mounted on top of overlayfs, btrfs, or tmpfs.
Can't be mounted on top of /dev/null.
Overlayfs can't be mounted on top of an ID-mapped mount ext4.

We expect these to be resolved in future kernel releases and we will keep an eye on these.


[full-ci] Use sizediff propagation

testing sizediff propagation for https://github.com/owncloud/ocis/issues/5061

I obviously messed up the move code ... will check tomorrow


Virtual not accepting regexp

Hello,
I try to add virtuals using regexp, but it seems to be broken. I tried multiple ones without success, including the example here (PR was never merged, by the way): https://github.com/camptocamp/puppet-postfix/pull/116. The result is always the same:
<EMAIL_ADDRESS>virtual -<EMAIL_ADDRESS>Could not evaluate: Save failed, see debug output for details
I have latest versions of the modules, including augeas.

Can you post the code you're using please?


Version 1.3.0 - Roadmap

A small roadmap for Version 1.3.0

[ ] Support for RainLab.User plugin (account pages + user profile page)
[ ] Support for RainLab.Forum plugin
[ ] Improvements and Changes on both headers: Condesned & Extended
[ ] New Sidebar Builder (with additional widgets)

[ ] Related Posts widget
[ ] Comment List widget
[ ] Image w/ Text widget

[ ] New content elements for Page Builder

[ ] Blog Posts (posts by author, category, date, tag, ...)
[ ] Blog Lists (list of authors, categories or tags)
[ ] File List (for downloads)

[x] Update bootstrap dropdown design (to fit own dropdown design)
[ ] Optional sidebar for archive pages
[ ] Update Archive / Search pages (more details about the archive[s] itself)
[ ] Improved dark mode for all native bootstrap elements
[ ] Documentation on demonstration page
[x] New Customization Options
[x] Update Meta Tags / clean-up header and footer areas
[x] Change JS Bundler from rollup to esBuild
[x] Update Dependencies (Bootstrap & Keen-Slider --- Bootstrap Lightbox will be replaced)
[ ] Replace Bootstrap Lightbox

You can also write down your wishes here, if possible I will try to include them in the new update.

Status Update: Currently working on the new header stylings and structure.

Unfortunately, I didn't had much spare time left in the last few weeks... however... I'm still working on the new v1.3.0 release, including an improved page builder
Before it looked like this...

Now it's more like this...

This is not only more compact, but also be included with every content element (soon), providing a better customization without relying to a section as parent.


docs(installation): Add missing links

Noticed that simple and basic links were missing from the installation code block.
This also revealed a css usability issue regarding anchor tags in blockquote elements. As the colors of the a are being inherited. Currently that would be gray, :visited is unaffected.

:tada: This PR is included in version 2.24.0-next.1 :tada:
The release is available on:

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.23.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update ark-snark to ark-algebra

Description
This PR has several changes: (1) add patching, (2) change ark-test-curves feature to the curve one temporarily before a corresponding PR in ark-algebra is merged, and (3) fix a confusing "type annotations needed".

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[x] Targeted PR against correct branch (master)
[x] Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
[x] Re-reviewed Files changed in the Github PR explorer

N/A:

[ ] Wrote unit tests
[ ] Updated relevant documentation in the code
[ ] Added a relevant changelog entry to the Pending section in CHANGELOG.md

Waiting for the CI to pass.

Note: the new requirement that Proof and ProcessedVerifyingKey must implement CanonicalSerialize and CanonicalDeserialize may require some updates to Groth16 and other repos.


distance of Polygons always 0.0. nearest_points always two identical points.

Expected behavior and actual behavior.
distance of Polygons always 0.0
nearest_points always returns two identical points
Steps to reproduce the problem.
>>> from shapely.ops import nearest_points
>>> from shapely.geometry.polygon import Polygon
>>> triangle = Polygon([(0, 0), (1, 0), (0.5, 1), (0, 0)])
>>> square = Polygon([(0, 2), (1, 2), (1, 3), (0, 3), (0, 2)])
>>> [o.wkt for o in nearest_points(triangle, square)]
['POINT (0.5 1)', 'POINT (0.5 2)']
>>> a = Polygon([(-16.0447, -33.6399), (-21.1562, -33.6399), (-21.1562, -30.325), (-16.0447, -30.325), (-16.0447, -33.6399)])
>>> b = Polygon([(-28.4283, -31.8875), (-20.1377, -25.9855), (-6.99585, -32.6618), (4.73425, -24.0754), (2.02204, -41.6133), (-39.5908, -42.0918), (-37.9966, -23.754), (-28.4283, -31.8875)])
>>> nearest_points(a, b)
(<shapely.geometry.point.Point object at 0x11e182ac8>, <shapely.geometry.point.Point object at 0x11e1985f8>)
>>> [x.wkt for x in nearest_points(a, b)]
['POINT (-16.0447 -33.6399)', 'POINT (-16.0447 -33.6399)']

Operating system
Mac OS X 10.12.3
Shapely version and provenance
shapely==1.6.4

One polygon contains the other, so I believe this is expected, right?

The triangle and the square do not intersect. Shapely says the distance between them is 1.0 and the distance between their nearest points is also computed to be 1.0. Expectation and observation are the same, as far as I can see. Yes?
Polygons a and b do intersect. The distance between them is 0.0 and their nearest points are consistent with that distance: the distance between the nearest points is also 0.0. I don't think there is any expectation we can have of what the nearest points would be in this case.
I don't see any difference between expectation and results here. Can you point out what I might be missing?


Set a different container

Is it possible to add the option to set a different container ?
Right now, Scrollify is only working on a full page but I'de like to set my page to full height and in this page, set a container with all my sections in it and overflow-y on it.

Currently, Scrollify only supports full page scrolling.


vscode volar???

Environment (please complete the following information):

OS (e.g., Windows 10):
Extension version (e.g., 1.2.3):

Describe the bug:

Repro steps:

Expected behavior:

Additional context:

Closing as incomplete.


Blockfile testsuite failure due to page size

Description
Related to discussion #8666.
In the blockfile snapshotter testsuite, the initial scratch file size is set based on the system page size (https://github.com/containerd/containerd/commit/0c386e2eb#diff-5127e16713ba51ac58a224116f8a35708ecbf8ffa2c0572f5af58ddf7c056347R40-R43). This has caused the "128LayersMount" test to crash on the ppc64le architecture when the disk space is smaller than 100GB. The ppc64le system has a larger page size, making each snapshot file at least 650MB which completely fills up the disk space before the test finishes. The test succeeds on the same system if the scratch file size is kept to 128MB.
I was not able to find any place where this page size logic applies outside of the test suite. It looks like it can be removed without affecting the validity of the test results.
Steps to reproduce the issue

Download containerd source and install dependencies on a ppc64le system (where storage size is less than 100GB)
Run the Blockfile test suite (go test -test.root -v -run TestBlockfile)
Errors begin to appear during the test such as "copy file range failed: no space left on device"

Describe the results you received and expected
Received: During the test suite execution, the storage device runs out of space and the test suite is unable to finish properly.
Expected: The test suite finishes properly without any IO errors.
What version of containerd are you using?
main branch
Any other relevant information
No response
Show configuration if it is related to CRI plugin.
No response

Hi @Jenkins-J , I don't have ppc64le machine so would you mind to test it in your local with 16MiB or 32MiB? I reduces the size to 8MiB if the pagesize is 4KiB. If it works well, please feel free to open pr to update it. Thanks.
REF: https://github.com/containerd/containerd/pull/8696/files#diff-5127e16713ba51ac58a224116f8a35708ecbf8ffa2c0572f5af58ddf7c056347


STK Demo: Change the updated beat value to be published on the main thread

When I start the STK Demo, Xcode displays a warning, saying:

Publishing changes from background threads is not allowed; make sure to publish values from the main thread (via operators like receive(on:)) on model updates.

Adding DispatchQueue.main.async publishes the new values to the main thread.

Looks good. Thanks, Mark!


Upgrade Metropolis (our font) to Release 8

Select one ...  (check one with "x")
[ ] bug
[ ] feature request
[X] enhancement

There is a new release of Metropolis. We should upgrade to the latest (release 8) of Metropolis: https://github.com/chrismsimpson/Metropolis/releases/tag/r8

Removing the milestone until we can fix the issue mentioned over here: #197


Add Space-Nvim-Theme to list

Adds spacemacs light and dark vim colorscheme

Awesome!! Looks great :)


test/runtime: remove netperf benchmarks

These benchmarks aren't run in CI. The same functionality is covered in
the cilium connectivity test --perf command which can be run against
arbitrary clusters.

/test-runtime

/test-runtime

/test-runtime


Remove mention of devel branch from tutorial

A mention of 'platform-devel' found in the 'customizing the platform' tutorial was replaced with 'platform-main'.
Grep'd all the tutorial for any other mentions where not appropriate.
No QA steps performed.
No issues to link, minor fix.
Readiness

[x] Merge (pending reviews)
[ ] Merge after date or event
[ ] Draft

Overview
Why merge this PR? What does it solve?
Checklist
Optional. Add a 'x' to steps taken.
You can fill this out after opening the PR. "Did I..."

[ ] Run spelling and grammar check, preferably with linter.
[x] Avoid changing any header associated with a link/reference.
[x] Step through instructions (or ask someone to do so).
[x] Review for wordiness
[x] Match tone and style of page/section.
[ ] Run make linkcheck.
[ ] View HTML in a browser to check rendering.
[x] Use semantic newlines.
[x] follow best practices for commits.

[x] Descriptive title written in the imperative.
[x] Include brief overview of QA steps taken.
[x] Mention any related issues numbers.
[x] End message with sign off/DCO line (-s, --signoff).
[x] Sign commit with your gpg key (-S, --gpg-sign).
[x] Squash commits if needed.

[x] Request PR review by a technical writer and at least one peer.

Comments
Any thing else that a maintainer/reviewer should know.
This could include potential issues, rational for approach, etc.

Docs for 1eaef53efdfcad00a5c17de03436a6b2785c6a21 are browsable at: https://ci.foundries.io/projects/fio-docs/builds/2483/docs/artifacts/html/index.html


Custom field in webhook api response

Hi,
We have added the custom field check box in the template in docusign admin panel and on user end if the user is checked the check box we are not able to find the value,kindly tell me how to achieve it

You can see a code example to show you how to obtain custom field data here - https://github.com/docusign/code-examples-php/blob/master/src/Services/Examples/eSignature/EnvelopeCustomFieldDataService.php


Error in webpack-sources

Do you want to request a feature or report a bug?
bug
What is the current behavior?
TypeError: item.source is not a function
TypeError: item.source is not a function
    at /Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/node_modules/webpack-sources/lib/ConcatSource.js:23:50
    at Array.map (native)
    at ConcatSource.source (/Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/node_modules/webpack-sources/lib/ConcatSource.js:22:24)
    at /Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/node_modules/webpack-sources/lib/ConcatSource.js:23:50
    at Array.map (native)
    at ConcatSource.source (/Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/node_modules/webpack-sources/lib/ConcatSource.js:22:24)
    at /Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/node_modules/webpack-sources/lib/ConcatSource.js:23:50
    at Array.map (native)
    at ConcatSource.source (/Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/node_modules/webpack-sources/lib/ConcatSource.js:22:24)
    at CachedSource.source (/Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/node_modules/webpack-sources/lib/CachedSource.js:28:44)
    at Compiler.writeOut (/Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/lib/Compiler.js:346:27)
    at require.forEach (/Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/lib/Compiler.js:336:21)
    at /Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/node_modules/async/dist/async.js:3083:16
    at eachOfArrayLike (/Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/node_modules/async/dist/async.js:1003:9)
    at eachOf (/Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/node_modules/async/dist/async.js:1051:5)
    at Object.eachLimit (/Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/node_modules/async/dist/async.js:3145:5)
    at Compiler.emitFiles (/Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack/lib/Compiler.js:325:21)
    at Immediate.<anonymous> (/Users/u_021ly/Desktop/projects/arui-feather/node_modules/webpack-dev-middleware/node_modules/memory-fs/lib/MemoryFileSystem.js:288:4

This is Travis build https://travis-ci.org/alfa-laboratory/arui-feather/jobs/255237762#L718
If the current behavior is a bug, please provide the steps to reproduce.
git clone https://github.com/alfa-laboratory/arui-feather.git
git checkout feat/add-md-lint
npm i
npm run gemini-ci

What is the expected behavior?
Runs without errors.
If this is a feature request, what is motivation or use case for changing the behavior?
Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
npm -v 5.3.0
node -v 6.10.1
webpack 3.3.0

Works good with webpack 2.7.0

Could you check webpack 3.4.1. and also provide a reproducible repository for us to test against?

@TheLarkInn , yes , I'll do it today

@TheLarkInn @stepancar Thanks a lot for looking at this. Having the same issue also. It seems that the follow line isn't handling the case of item being:
ConcatSource {
  children: [ 'module.exports =\n', ConcatSource { children: [Array] } ]
}

https://github.com/webpack/webpack-sources/blob/master/lib/ConcatSource.js#L23
specifically in the case of ExtractTextPlugin: extract-text-webpack-plugin/dist/loader.js:99:87

@TheLarkInn
I updated to 3.4.1 and still see error.
Could you please give a look at
git clone https://github.com/alfa-laboratory/arui-feather.git
git checkout chore/branch-for-reproduce-webpack-error
npm i
npm run gemini-ci

created pull request https://github.com/alfa-laboratory/arui-feather/pull/194
you can see travis error
https://travis-ci.org/alfa-laboratory/arui-feather/jobs/259937469#L736

Can I get some clarification on why plugins run through the ConcatSource lib in the first place? I am troubleshooting a custom plugin I am writing, and it seems that plugin code that includes some require statements is causing me similar issues. Does webpack do some sort of concat operation on the config file itself? Is there any way to disable that for certain included libs?

Hello, I have just the same error. The important detail is that when I run webpack from command line it builds the bundle without errors. When I run script with npm which executes webpack-dev-server with config it gives me error about item.source.
Sadly I cannot provide you with repo because my project is not open source.
I even made a lengthy debug session of webpack and discovered that bad 'source' is adding at webpack\lib\Template.js:145
source.add(module.source);
where module.source is function which leads to the error in the end.
Hope it'll help to inspect the bug.

Also having this issue. I believe I've got this after updating npm deps.

I found the bug and fixed it locally.
After git bisect search, I found that 2bd2d2844cf656d7a653464e226d753394894e04 introduced the bug. However, the commit just updated syntax and API, so I doubt that these APIs behave differently in different runtime(Which I had met before in bisheng).
I tried to update the usage of API https://github.com/webpack/webpack/pull/5821/commits/1af69d6fa1fb1f06a47ceeb808174df059e031fc, and then every thing works fine.
@cbrwizard @unfalse @Smolations @stepancar @Donmclean you can try my patch locally, I think that will solve your issue.
And the PR https://github.com/webpack/webpack/pull/5821

So I stumbled into this issue a while ago, and discovered it was not webpack's fault at all, but instead a dependency's dependency that was loading a poorly written poly/ponyfill library that instead of adding JS functions/features that were missing (like adding Array.from if not defined) they instead ALWAYS replaced Array.from with a bad implementation. For example, my issue was pulling in q-io which pulled in the collections npm package that poorly clobbers JS builtins in a really bad way.

Thanks @nowells and @1more for your investigation on this issue! I'm closing it since it is not webpack's fault.


Optimize trade aggregations query

I looked at this a bit more, see my findings and proposed solution below.
According to the horizon logs over a period of 7 days, there are over 2.3M requests to the /trade_aggregations endpoint of horizon.stellar.org. Out of that, response times for 99.8% of those requests are under 2seconds. From the remaining 0.2%, 14 requests were over 30seconds. The good news from this is that most times, the API is being used on the happy path and everything is fine. But it also means that there is a possibility for misuse. It can easily be the other way around and the requests could be more delayed.
An example of the delayed request is shown below; this request took 68 seconds probably timed out
/trade_aggregations?base_asset_type=native&counter_asset_type=credit_alphanum4&counter_asset_code=DRA&counter_asset_issuer=GCJKSAQECBGSLPQWAU7ME4LVQVZ6IDCNUA5NVTPPCUWZWBN5UBFMXZ53&start_time=0&end_time=0&resolution=86400000&order=desc&limit=200

this translates into the sql query
SELECT timestamp, count(*) as count, sum(base_amount) as base_volume, sum(counter_amount) as counter_volume, sum(counter_amount)/sum(base_amount) as avg, max_price(price) as high, min_price(price) as low, first(price) as open, last(price) as close FROM (SELECT div((cast((extract(epoch from ledger_closed_at) * 1000 ) as bigint) - 0), 86400000)*86400000 + 0 as timestamp, history_operation_id, "order", base_asset_id, base_amount, counter_asset_id, counter_amount, ARRAY[price_n, price_d] as price FROM history_trades WHERE base_asset_id = '2' AND counter_asset_id = '5833' AND ledger_closed_at >= '1970-01-01 00:00:00' ORDER BY history_operation_id , "order") AS htrd GROUP BY timestamp ORDER BY timestamp desc LIMIT 200

When analyzed, we get this
QUERY PLAN                                                                                -----------------------------------------------------------------------------------------------------------------
 Limit  (cost=2833991.45..2833991.95 rows=200 width=80) (actual time=44213.773..44213.893 rows=200 loops=1)
   ->  Sort  (cost=2833991.45..2833991.95 rows=200 width=80) (actual time=44213.771..44213.816 rows=200 loops=1)
         Sort Key: (((div(((((date_part('epoch'::text, history_trades.ledger_closed_at) * '1000'::double precision))::bigint - 0))::numeric, '86400000'::numeric) * '86400000'::numeric) + '0'::numeric)) DESC
         Sort Method: top-N heapsort  Memory: 78kB
         ->  HashAggregate  (cost=2833979.30..2833983.80 rows=200 width=80) (actual time=44212.371..44213.110 rows=516 loops=1)
               Group Key: (((div(((((date_part('epoch'::text, history_trades.ledger_closed_at) * '1000'::double precision))::bigint - 0))::numeric, '86400000'::numeric) * '86400000'::numeric) + '0'::numeric))
               ->  Sort  (cost=596769.28..601960.03 rows=2076297 width=52) (actual time=6214.336..7484.817 rows=2687984 loops=1)
                     Sort Key: history_trades.history_operation_id, history_trades."order"
                     Sort Method: external sort  Disk: 249592kB
                     ->  Index Scan using htrd_pair_time_lookup on history_trades  (cost=0.56..297799.79 rows=2076297 width=52) (actual time=0.061..3635.642 rows=2687984 loops=1)
                           Index Cond: ((base_asset_id = '2'::bigint) AND (counter_asset_id = '5833'::bigint) AND (ledger_closed_at >= '1970-01-01 00:00:00'::timestamp without time zone))
 Planning time: 0.612 ms
 Execution time: 44250.765 ms
(13 rows)

45seconds execution time is definitely not acceptable.
Precompute Trade Aggregation Buckets
One of the suggestions mentioned earlier was pre-computing the trade aggregation buckets. I think that is a good idea so I decided to test it out. I precomputed the buckets for the asset pair above using 1-hour resolutions and saved it as a materialized view. With that, the slow query above can be converted to
SELECT timestamp, sum(count) as count, sum(base_volume) as base_volume, sum(counter_volume) as counter_volume,  sum(avg)/count(*) as avg, max_price(high) as high, min_price(low) as low, first(open) as open, last(close) as close FROM(SELECT div((cast(timestamp as bigint) - 0), 86400000) * 86400000 + 0 as timestamp, count, base_volume, counter_volume, avg, high, low, open, close FROM trdagg_view WHERE base_asset_id = '2' AND counter_asset_id = '5833' AND timestamp >= '1468800000') as htrd GROUP BY timestamp ORDER BY timestamp desc LIMIT 200;

Analyzing this gives
QUERY PLAN
------------------------------------------------------------------------------------------------------------------
 Limit  (cost=1498.62..1710.12 rows=200 width=196) (actual time=18.271..75.610 rows=200 loops=1)
   ->  GroupAggregate  (cost=1498.62..13543.55 rows=11390 width=196) (actual time=18.269..75.516 rows=200 loops=1)
         Group Key: (((div((((trdagg_view."timestamp")::bigint - 0))::numeric, '86400000'::numeric) * '86400000'::numeric) + '0'::numeric))
         ->  Sort  (cost=1498.62..1527.10 rows=11390 width=196) (actual time=17.968..19.284 rows=4432 loops=1)
               Sort Key: (((div((((trdagg_view."timestamp")::bigint - 0))::numeric, '86400000'::numeric) * '86400000'::numeric) + '0'::numeric)) DESC
               Sort Method: quicksort  Memory: 3358kB
               ->  Seq Scan on trdagg_view  (cost=0.00..731.19 rows=11390 width=196) (actual time=0.017..12.141 rows=11391 loops=1)
                     Filter: (("timestamp" >= '1468800000'::numeric) AND (base_asset_id = '2'::bigint) AND (counter_asset_id = '5833'::bigint))
 Planning time: 0.131 ms
 Execution time: 75.709 ms
(10 rows)

:zap: Alright, Precomputing the buckets definitely looks like the way to go, but there are some issues. Let us look at some numbers:
Currently, there are 25,070 assets in the history_assets table. With Stellar each of those asset can potentially create a trading pair with every other asset; this gives us about 628,454,760 asset pairs. Multiply that by 24(hourly buckets per day), that is a lot of data.
Thankfully(At the moment), not all of those asset pairs are in play. Looking at the history_trades tables, there are 2,683 distinct asset pairs. This gives 64,392 precomputed entries per day. Following this, the maximum amount of entries per day to be precomputed is N * 24, where N is the number of distinct asset pairs. Note that, this assumes that all asset pairs are active every day, which is not necessarily the case.
Bounded time range
Another solution that I have considered is having the time-range bounded to multiples of the specified resolution.
Given that horizon will only respond with a maximum of 200 records, we should limit the starttime to a minimum of  endtime - (200 * r), where r is the resolution. The next link in the response will then be updated with corresonponding start and end times with intervals of 200r.
If we do this, the slow query above will be represented as
SELECT timestamp, count(*) as count, sum(base_amount) as base_volume, sum(counter_amount) as counter_volume, sum(counter_amount)/sum(base_amount) as avg, max_price(price) as high, min_price(price) as low, first(price) as open, last(price) as close FROM (SELECT div((cast((extract(epoch from ledger_closed_at) * 1000 ) as bigint) - 0), 86400000)*86400000 + 0 as timestamp, history_operation_id, "order", base_asset_id, base_amount, counter_asset_id, counter_amount, ARRAY[price_n, price_d] as price FROM history_trades WHERE base_asset_id = '2' AND counter_asset_id = '5833' AND ledger_closed_at >= '2019-01-26 00:00:00' ORDER BY history_operation_id , "order") AS htrd GROUP BY timestamp ORDER BY timestamp desc LIMIT 200

When we analyze this, we get
QUERY PLAN
------------------------------------------------------------------------------------------------------------------
 Limit  (cost=1053711.98..1053712.48 rows=200 width=80) (actual time=2530.585..2530.708 rows=200 loops=1)
   ->  Sort  (cost=1053711.98..1053712.48 rows=200 width=80) (actual time=2530.583..2530.632 rows=200 loops=1)
         Sort Key: (((div(((((date_part('epoch'::text, history_trades.ledger_closed_at) * '1000'::double precision))::bigint - 0))::numeric, '86400000'::numeric) * '86400000'::numeric) + '0'::numeric)) DESC
         Sort Method: quicksort  Memory: 78kB
         ->  HashAggregate  (cost=1053699.84..1053704.34 rows=200 width=80) (actual time=2530.109..2530.385 rows=201 loops=1)
               Group Key: (((div(((((date_part('epoch'::text, history_trades.ledger_closed_at) * '1000'::double precision))::bigint - 0))::numeric, '86400000'::numeric) * '86400000'::numeric) + '0'::numeric))
               ->  Sort  (cost=307102.24..308834.49 rows=692898 width=52) (actual time=369.907..435.424 rows=151092 loops=1)
                     Sort Key: history_trades.history_operation_id, history_trades."order"
                     Sort Method: external sort  Disk: 14032kB
                     ->  Index Scan using htrd_pair_time_lookup on history_trades  (cost=0.56..226349.23 rows=692898 width=52) (actual time=0.038..229.375 rows=151092 loops=1)
                           Index Cond: ((base_asset_id = '2'::bigint) AND (counter_asset_id = '5833'::bigint) AND (ledger_closed_at >= '2019-01-26 00:00:00'::timestamp without time zone))
 Planning time: 0.202 ms
 Execution time: 2533.212 ms
(13 rows)

2.5seconds is better than 45seconds so this has some potential as well.
Proposed Solution
My proposal for optimizing the trade_aggregation endpoint is a that we approach this in stages.

Stage 0: Implement the bounded time range strategy above and monitor how this improves requests. I am going with this solution first because it introduces a significant amount of gain with minimum overhead. The changes needed will only be to the codebase. From a user perspective, they still get the same response structure. Also it has the added advantage of not involving extra storage.

Stage 1: After monitoring the changes in Stage 0, should we feel the need to further improve this endpoint we can implement the precomputed records strategy. This will involve the creation of a new table: history_trade_aggregations that will have trade aggregation records for asset pairs based on hourly resolutions. Resolutions greater than or equal to an hour will use this table, otherwise it can use the current query. Given that this feature requires extra resources it should be accompanied by 2 flags

TRADE_AGGREGATION_HISTORY: boolean to indicate if trade aggregations should be precomputed.
TRADE_AGGREGATION_HISTORY_RANGE: the amount of history that should be saved. 1month, 3months, 6months, 1year?

Will love to hear some feedback on this. My plan is to implement stage 0 in the next sprint.

Wow! Great find with the time bounding approach.
That nested query completely ignores paging right now and brings the entire time range worth of trades for every page. Who ever wrote that monstrosity... :man_shrugging:
I agree about stage 0. Given the performance gains from that I think that precomputing buckets is pretty aggressive. Let's put that on a hold until evidence suggests otherwise.

Yikes! It's kinda amazing that this query isn't doing this already. Totally agree we should do that ASAP and then re-measure.
I'd expect the time bounding should handle insane cases like asking for 1m summaries of an asset from genesis to the present day. I'd like to see the performance of some large time bounded 1w resolution queries though. There may still be work to do there.

Added bounded time range in https://github.com/stellar/go/pull/2856.

I implemented Bounded Range solution in https://github.com/stellar/go/pull/2856 and I'm currently checking it in stg. There's a small improvement in p99 response time, much better in p95 but it's still above 1s for many queries. After https://github.com/stellar/go/pull/2869 which improves performance of /trades, /trade_aggregations in the single route that responds in seconds instead of milliseconds time. Fixing this will help us build better metrics, alerting and improve Horizon clusters health overall.
I think we should spend more time next sprint and implement the buckets solution. It will be much simpler than a couple months ago:

We have a new ingestion system so we really just need a new processor on ingestion side.
We have the reingesiton cluster so we can check storage requirements for new data the day after reingestion is started.

To make sure users can upgrade without having to reingest their DBs we can add the new code behind a feature flag.
Moving to Horizon 1.8.0 milestone temporarily. To be discussed in Horizon Team meeting.

We had to revert the Bounded Range solution in: https://github.com/stellar/go/pull/2893. It doesn't work for markets with some buckets missing for a given time range and limit (more in the revert PR description).
Again, we should probably implement precomputed buckets idea. This issue should not occur in this solution.

Damn, that's disappointing. Since the issue is now not even partially resolved, lets prioritise this now then. Moved to top of backlog.

Sidenote: Reading back through this, the explain line saying: Sort Method: external sort  Disk: 14032kB, seems slightly odd. Doesn't the worker have 14MB free memory to quicksort those?
Intuitively, I'd say we should do bounded ranges (more flexible, and lower disk use), and do multiple queries to fix the limit issues with #2893.
We could possibly combine that with table-partitioning. This would need some experimentation and analysis on the table/index sizes and access patterns, but we could partition either on:

ledger_closed_at

this would be better if we typically query across all assets within a time range

max(base_asset_id, counter_asset_id)

this would be better if we typically query for a specific asset-pair across all time

both

Suspect this might be too much for now.

Per discussion in team meeting today, I think this will be easier if we change some of the trade aggregation endpoint semantics. Particularly around start_time, end_time, and offset.
Proposed API Param changes:
- start_time (optional) long
+ start_time (required) long
    The lower time boundary represented as milliseconds since epoch.

- end_time   (optional) long
+ end_time   (required) long
    The upper time boundary represented as milliseconds since epoch.

- resolution (optional) long
+ resolution (required) long
    The segment duration represented as milliseconds. Supported values are 1 minute (60000), 5 minutes (300000), 15 minutes (900000), 1 hour (3600000), 1 day (86400000) and 1 week (604800000).

  offset     (optional) long
-  Segments can be offset using this parameter. Expressed in milliseconds. Can only be used if the resolution is greater than 1 hour. Value must be in whole hours, less than the provided resolution, and less than 24 hours.
+  Segments can be offset using this parameter. Expressed in milliseconds. Value must be in multiples of 15 minutes, less than the provided resolution, and less than 24 hours. Used to adjust queries for a timezone offset.

  order      (optional)
    A designation of the order in which records should appear. Options include asc(ascending) or desc (descending). If this argument isn’t set, it defaults to asc.

  limit      (optional)
    The total number of records returned. The limit can range from 1 to 200 - an upper limit that is hardcoded in Horizon for performance reasons. If this argument isn’t designated, it defaults to 10.

  ... asset pair type/issuer/code ...

The offset param, in theory, is used to adjust the query for timezone offsets. I was hoping we could get rid of it, but I don't actually think we can. e.g., daily buckets, where midnight is in UTC-7. This change, changes the minimum offset from 1h to 15m. This actually makes the api more flexible, but will help us actually account for all timezones. I figure we should get this in earlier, as it can help inform our caching/precomputing work.
e.g.

1 hour offset on a daily aggregation

Range/Resolution Tradeoffs
As discussed, we should enforce range/resolution tradeoffs. The idea being, that for a given resolution, there's a maximum end_time-start_time. Given the maximum limit value is 200, I'd suggest starting with that. IMO, seems more than enough for most charts, and charts should lazy-load in more data as you scroll/zoom, anyway.

Resolution
Max Range
Max Buckets/Query

1 minute (60000)
200 minutes
200

5 minutes (300000)
1000 minutes
200

15 minutes (900000)
50 hours
200

1 hour (3600000)
200 hours
200

1 day (86400000)
200 days
200

1 week (604800000).
1400 days
200

if (end_time - start_time) > (resolution * 200) {
  w.WriteStatus(http.StatusBadRequest)
  return
}

This is contract change breaks clients that give a duration that can contain multiple pages of results and depend on the paging links.
Maybe it's worth taking a look at public horizon logs to see what percentage of requests this will break?

It seems like we need some more information on the paging strategy of trading clients to make an informed decision. The suggestion above by @paulbellamy has the potential to introduce breakage in paging (or not). And, to the best of my understanding, #2856 by @bartekn was reverted because it effectively changed the paging contract (more on this below).
This is a bit of a tragedy because trading aggregations don't really need opinionated server side paging. The combination of parameters gives clients all the freedom in the world to page as they please. However, when creating this endpoint we adhered to the same HAL response structure as the rest of the API. I'll add this to my upcoming book titled Crimes committed in the name of generics.
Revisiting #2893 that reverted #2856. It seems like the issue with timebounding is that the results are sparse (empty buckets not included) which breaks paging logic. Paging logic assumes that len(results)<page_limit means there are no more results and the client shouldn't further page.
What if we restor #2856 and solve this problem by artificially un-sparsing the results adding 0-buckets where there are non buckets to the results? This should restore paging logic. This is very inefficient for for rarely traded pairs, but maybe that's not the end of the world. We should also probably not serve 0-buckets from before the existence of a given orderbook.
This is an implicit contract change as clients have never had to deal with empty buckets but it's fairly non offensive and we can check with the major trading clients if it breaks them. My bet is that it won't introduce breakage.

I've had an idea how to reduce disk size of pre-computed buckets, which would allow us to make this more efficient without changing the API. Just seeing how feasible it is before committing to that, though.


Move vtt_talk_sources to shared conditions

This pull request addresses the problems described at issue #2076.
Need to add a two tests: one that loads the check-opentype checks and one for check-googlefonts.

@felipesanches Have a look :)


SDF3 representations do not correspond to the ForSyDe models

As issued in the forsyde-demonstrators repository, the generated SDF3 representations are not correct.

Could you elaborate this further?
Maybe with an example?


Cannot use parents version of method using super

class VeryBase
  getter msg : String

  def initialize(@msg)
  end
end

class Base < VeryBase
  def initialize
    super "base message"
  end
end

class Derived < Base
  def initialize
    super "derived message"
  end
end

def func(ex : Base)
  puts ex.msg
end

func Base.new # => base message

func Derived.new

https://carc.in/#/r/21bi (My use case is with exceptions: https://carc.in/#/r/21bg)
Errors with:
Error in line 26: instantiating 'Derived:Class#new()'

in line 16: wrong number of arguments for 'Base#initialize' (given 1, expected 0)
Overloads are:
 - Base#initialize()

It seems that from Derived#initialize, I can only use super to access Base#initialize but not VeryBase#initialize(msg)

It strikes me that it makes sense for crystal to treat initialize methods in this manner.  If Derived is a subclass of Base, then it's prudent to say that super in an initialize method will only match an initialize method of Base.  For the case of initialize, you really don't want a mistake in specifying parameters to cause all the initialization of VeryBase to occur without any of the initialization expected for Base.
If the writer of Derived really needs to call the alternate version of initialize, then they could first re-open Base to add an initialize method to that class which matches the initialize they need to reach in the VeryBase class.
For instance, before the line class Derived < Base , put:
class Base
  def initialize(msg)
    super msg
  end
end

... or at least that's my gut feeling after only a few minutes of thinking about it.  It could also be that the tactic I suggested is a bad idea.

In pascal, there is a syntax VeryBase.initialize("derived message") for it. Not sure if it worths adding, but it's imho clearer then reopening base class for adding methods.

For the case of initialize, you really don't want a mistake in specifying parameters to cause all the initialization of VeryBase to occur without any of the initialization expected for Base.

Yeah I missed that case, and it seems logical, but I think it's redundant to reopen the Base just for this.. (but I can't see any other way though)

Just my 2¢ but when I use super, I see it as calling the parent of that method, but in this case, you're not calling the parent of initialize, you're calling initialize(msg : String). So in this case, I would just use
def initialize
  initialize("derived message")
end

Looks like you should do
class Base < VeryBase
  def initialize(msg = "base message")
    super(msg)
  end
end

Thanks all for your answers, I resolved my issue, I think this can be closed now


fixed tasks in modules/file

same here, please check the changed cursor behavior as I mentioned in #51

You're right. Keep it simple as possible :)

Could you resolve the conflicts first?

Could you resolve the conflicts first?

✅


[1.18.1] Piglin brute weird spawning conditions in hunting dimension

I noticed some weird piglin brute spawning conditions while in the hunting dimension. Here's  a video of what I mean. I believe this may be due to the fact that piglin brute spawning in vanilla minecraft doesn't occur 'randomly' and only occurs while spawning the bastion remnants(Note: I'm getting this from here  based off this information "A small number of piglin brutes spawn in bastion remnants only upon generation and in some rooms.") So I believe that since piglin brutes are not meant to spawn 'randomly' they don't have the correct conditions set for their spawn.
Here's a video of flying around a bastion with all brutes set with NoAI and glowing upon spawn.(Note none of them being on the ground)
Overall not really sure but this can be replicated by teleporting to y=300(to prevent mobs spawning on the ground) and creating a layer of blocks.
Edit: If interested, Here's the spawns with NoAI and glowing. Also forgot to mention it but here's a list of my mods

It is a little odd.   So, other than brutes falling from above, what exactly is the problem this creates?

Sorry I might not have been clear or just might be misunderstanding your response. Essentially the brutes are able to spawn in the air without direct sunlight, I presume this isn't on purpose as looking at the code nothing seems to intentionally be causing this. The problem this creates for me is creating a 'passive' farm for these will cause increased inefficiency shown here.(Although they would fall to their death, it forces you to build this at a height that guarantees all falling will die which would have to be extremely high as brutes could spawn with feather falling and could spawn up to 128 blocks below you. Even with them dying it would still cause inefficiencies due to how long the entities will stay within the mobcap and possible spawns being wasted on ones that will die below you.

It was intentional for them to spawn in the air.  Seems to be a byproduct of vanilla code.  The Hunting Dim was not primarily designed for farms, but for the "on the ground" fighting experience, for which the brutes provide a nice challenge.
I am confident that a clever farm builder like yourself will find a way around the inefficiency if you are so inclined.

I did some  checking in the vanilla code and I  do not see any way  to  control the height of the brute  spawning.  The dimensions and  mobs in the mod are added via  daypack, which provides little control for such things.

e

It was unintentional for them to spawn in the air. Seems to be a byproduct of vanilla code. The Hunting Dim was not primarily designed for farms, but for the "on the ground" fighting experience, for which the brutes provide a nice challenge.
I am confident that a clever farm builder like yourself will find a way around the inefficiency if you are so inclined.

Glad to have confirmation about it being a byproduct of vanilla code. The brutes do provide a nice challenge for quite a good reward during the early-mid game but I just couldn't help but let out the farmer inside me haha.

I did some checking in the vanilla code and I do not see any way to control the height of the brute spawning. The dimensions and mobs in the mod are added via daypack, which provides little control for such things.

I don't believe it's an issue with the height, more about the lack of a height check... If I get some time I'll set up the project and see if I can figure anything out :shrug:

After looking into the vanilla code it seems that there is no SpawnRestriction set for the PIGLIN_BRUTE entity in net.minecraft.entity.SpawnRestriction. This causes the SpawnRestriction for brutes to default to NO_RESTRICTIONS. If this were to be fixed here's the mixin I used for testing.

I'm not quite sure I understand that mixin entirely.  Did you write it yourself or grab it from another mod on GitHub?

I'm not sure this is wise, since I believe it world create a restriction for ALL Piglin brutes throughout the game.  Which might lead to unexpected results in vanilla and other mods.
If you got this working in a version of Mining Dimensions of your own, enjoy.
I would what a safer approach that confines the effect to my hunting dim only.

I'm checking in with a more experienced mod author to get a second opinion.

After consulting with a more experienced model, he thinks that it is safe to do.  I will add it to v41 of the mod.
Thank you for researching this and providing the mixin.  I've been at this 2 years and still have som much to learn.

I'm not quite sure I understand that mixin entirely. Did you write it yourself or grab it from another mod on GitHub?

I wrote something very close to this however my lack of knowledge about mixins(mainly @Shadow) and confusion about that static declaration caused me to turn to the internet. Originally I found the method here but whilst trying to find it again I found it here as well.

I'm not sure this is wise, since I believe it world create a restriction for ALL Piglin brutes throughout the game. Which might lead to unexpected results in vanilla and other mods.
If you got this working in a version of Mining Dimensions of your own, enjoy.
I would what a safer approach that confines the effect to my hunting dim only.

Oh my, I had entirely forgot about the affect on other mods! I did test out most cases in vanilla and it seemed to not affect it 🤷🏼♂. I definitely would prefer a way to make it hunting dimension specific though...

After consulting with a more experienced model, he thinks that it is safe to do. I will add it to v41 of the mod.
Thank you for researching this and providing the mixin. I've been at this 2 years and still have som much to learn.

Alright, my other idea for fixing this(and how I found the issues originally) is by adding a mixin too canSpawn in SpawnHelper. However I never found a way with mixins to take in all parameters and modify only one based on the others(In this instance modify location based on entityType) . The only other issue with this is that I was unable to find the dimensions registry key and only managed to get a DimensionType that wasn't very useful. A more experienced developer like you might defyingly be able to do it though.


Nicer error messages on a likely forgotten resume

Students (and many other users like me) often forget to resume from a handler.
We could customise the error message, especially when it's obvious from the type that using resume would fix the type error one gets.
Let's take a look at a small example:
effect get(): Int

def foo() =
  try { println(do get()) }
  with get {
    42
//  ^^
//  Expected Unit but got Int.
  }

We could customise ( 🚲🏠 ) the error to something slightly more specific like:
Expected Unit but got Int.
Did you mean to use `resume: Int => Unit` in the handler in order to resume?

The heuristic is pretty straightforward: an additional hint should fire if in the handler we get "expected τ1 but got τ2" and resume has type τ2 => τ1.

If I'm looking at it correctly, the error message is produced by the body checkAgainst ret here (and we could use the resumeType):
https://github.com/effekt-lang/effekt/blob/000a76885d1a1d0004a41422ca35a87362582503/effekt/shared/src/main/scala/effekt/Typer.scala#L470-L482


Allow to set custom direction

Hello! I'm testing the tool and is amazing!
I've a quick question: is possible to change the direction, ex: from bottom to top like as facebook reactions on live events?
Thanks!

hello, thank you for your feedback!
currently it is not possible, however this sounds like cool thing to implement. I'll try to work on that when I have time

and/or choose a target from which to emit the confetti please 🙏🏻 - I'd like to fire confetti from behind a button that triggers it.

Any updates about button animation? Want to implement it on my website)


dev: refactor KakarotClient trait

We currently have a mix of Starknet and Eth types in the KakarotClient. Refactor the code in order to have KakarotClient only use Eth types.
This leads to two subtasks:

Splitting KakarotClient in two: one trait which implements the EthApi and only uses Eth types and another trait which defines any internal functions that are not exposed routes (ex: proxy_account_class_hash) and the visibility of those functions should probably be limited to the crate (pub(crate)).
Renaming: this new trait which will only contain Eth types should be renamed to something like KakarotEthApi in order to inform that this is the Kakarot implementation of the EthApi. Additionally, it should use the EthApiError for all Results.

@greged93 I can take this one.

We can change the name of this issue, as KakarotClient has been renamed to KakarotProvider


Cant set badge height on Heroku

Badge height of svg is undefined if a valid number is entered for BADGE_HEIGHT variable in Heroku.
If left blank, the height is the same as the width
Here's an example
https://react-data-grid.herokuapp.com/badge.svg

I'm experiencing the same issue. Have you found a solution for it yet?


Move implicit tendency to src

This PR moves the implicit column tendency into src and removes some global closures.

bors r+


Update STATUS with date-fns v2 and ISO helpers

I went through the functions of date-fns, and found a few to be missing, some have been added in (the unpublished) v2 and the rest is the ISO functions currently with placeholder TODO in the document.
I don't know if all of them are desired to have in this library, I just added all I couldn't already find. So I'm totally fine with you suggesting me to remove some (or all!) of the functions I have added to the STATUS document.
I would like to help out with the ISO-functions if that is ok :-)
Thanks for a great library!

@mikaello stellar job! 💯 feel free to contribute 😊


If we go back and forth between the designer and code view, the action will not load properly.

Describe the Bug with repro steps

Add a managed connector to workflow

This example uses the [Office 365 Outlook] connector.

Go to Code View without saving the workflow

Save on CodeView

Save the workflow in the Code View screen without making any changes.

Back to Designer

Press this button to return to the designer.

The connector cannot be read properly and an error occurs.

This also occurs with other managed connectors.
What type of Logic App Is this happening in?
Consumption (Portal)
Which operating system are you using?
Windows
Are you using new designer or old designer
New Designer
Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg
Yes
Workflow JSON

Screenshots or Videos
No response
Browser
Edge
Additional context
No response

Is this happening in China cloud or Public Azure? If it's happening in public azure can you try on the following link: https://aka.ms/emastaging

Hi @hartra344 , sorry for the late reply. This issue occurred in Public Azure.


notifications: normalize case of realm_uri and account.realm

account.realm is an only-lightly-normalized form of whatever the
user typed in; what little normalization is done does not include
case-folding.
On the other hand, based on errors in Sentry, the notification's
provided URL is case-normalized.
N.B.: case-normalization may be destructive to non-ASCII URLs or in
Turkish locales.

Non-ASCII URL comparison is probably already broken, because we
don't do punycode encoding on our end.

Turkish locale users with ASCII realm URLs should be mostly
unaffected, unless they have typed a capital (dotless) I in their
realm URL. In this case they will need to replace it with a
lowercase (dotted) i.

... and I've forgotten to mark this as a draft PR – it's untested! :fearful: (Please avoid actually merging for now.)

Thanks for tracking this down!
The realm URL that appears in the notification data is the one the server has for itself (for that realm).
Thinking about... you know what, I'm going to move this to chat. :slightly_smiling_face:

It's worth noting that the right fix here is probably not to do any sort of URL mangling: it's to ask the server what it calls itself at login (or thereabouts), then use that as a comparand. We've been getting a number of Sentry errors indicating that people are connecting to renamed servers.

Sorry, it seems I dropped this thread. Added more just now in chat after you pinged me in person; thanks!
Sounds like we both agree on the right direction for a complete fix: we'd drop any attempt at canonicalizing the URL ourselves, and just quote the server's idea of it from server_settings.
That shouldn't be super complicated, but this commit is very simple, so it's a fine quick mitigation. Code LGTM; my only comments are

adjust the TODO comment to reflect the new plan
adjust the commit message ditto

:ping_pong:

We're now accomplishing this by parsing both URLs as URL objects, with ebbab7e99 and previously #4235 .
In the chat thread linked above, we'd discussed that as the ideal way to solve this problem. At the time we didn't have a useful URL implementation handy, because RN provides only a skeleton of one. Since #4081, we have a suitable URL implementation as a polyfill, and this is one of many handy applications for it.


cheap-module-source-map doesn't generate sourcesContent

Do you want to request a feature or report a bug?
Bug.
What is the current behavior?
No sourcesContent is generated in the source map if UglifyJsPlugin({ sourceMap: true }) is enabled and devtool: 'cheap-module-source-map' is used. cheap-source-map works.
If the current behavior is a bug, please provide the steps to reproduce.

Clone https://github.com/survivejs-demos/webpack-demo
Check out source-map-bug
npm i
npm run build
Examine build/app.js.map, note above.
Tweak webpack.config.js (contains comments how).

What is the expected behavior?
It should generate sourcesContent like cheap-source-map option.
Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.
Webpack ^2.2.0. Node 6, macOS.

Is this still broken?

This is webpack 2. Probably this is already fixed. If not, open a new issue.

This is webpack 2. Probably this is already fixed. If not, open a new issue.

@Freddie-Pike If you still see this issue, please create a new issue with repro repo :)

@Freddie-Pike If you still see this issue, please create a new issue with repro repo :)

@alexander-akait may have a repro too?

@alexander-akait may have a repro too?

Ok Update: This is expected behavior. cheap- devtools can't be used in production mode, as they only map lines and do not do column mapping. When minimizers optimize the code they usually emit only a single line. This can't be mapped by cheap- devtools.

Ok Update: This is expected behavior. cheap- devtools can't be used in production mode, as they only map lines and do not do column mapping. When minimizers optimize the code they usually emit only a single line. This can't be mapped by cheap- devtools.


Build with go 1.18, use glangci-lint in 1.17 mode

Go 1.17 will become End of Life in August. There's a push in ACM to get all projects building with 1.18. However, some golangci-lint linters don't work with 1.18 yet and would need to be disabled, causing a gap in coverage (see https://github.com/stolostron/backlog/issues/22428). Instead, figure out how to run golangci-lint in 1.17 mode.
This will also require an update to Prow, see https://github.com/stolostron/backlog/issues/22428.
It seems that both ACM 2.4 and 2.5+ want this, so this will need to be backported to the release-0.12 and release-0.13 branches.

To run golangci-lint in 1.17 mode, set go to 1.17 in the run section; see https://golangci-lint.run/usage/configuration/#run-configuration

Note that we’re already building with Go 1.18 upstream, but we’re listing 1.17 at most as our minimal version in go.mod, which causes golangci-lint to run in 1.17 mode anyway.

Nice, thanks for the details @skitt!

I don't think there's actually anything to be done in submariner-io repos for this, closing.