Big Number with Trendline coudn't work with PostgreSQL's date field

Big Number with Trendline coudn't work with PostgreSQL's date field.
How to reproduce the bug

Create a table with a column which type is "date" in postgresql
Add that database and table as dataset to Superset
Try to create a Big Number with Trendline chart with that dataset
It shows

Unexpected error
Error: '+08'

which +08 is the timezone about your pgsql settings
Expected results
The chart should be draw successfully
Actual results
Unexpected error
Error: '+08'

Screenshots

Additional Error Log
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1950, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1936, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/local/lib/python3.8/site-packages/flask_appbuilder/security/decorators.py", line 190, in wraps
    return f(self, *args, **kwargs)
  File "/app/superset/utils/log.py", line 245, in wrapper
    value = f(*args, **kwargs)
  File "/app/superset/views/core.py", line 2351, in results
    return self.results_exec(key)
  File "/app/superset/views/core.py", line 2419, in results_exec
    obj = _deserialize_results_payload(
  File "/app/superset/views/utils.py", line 625, in _deserialize_results_payload
    df = result_set.SupersetResultSet.convert_table_to_df(pa_table)
  File "/app/superset/result_set.py", line 177, in convert_table_to_df
    return table.to_pandas(integer_object_nulls=True)
  File "pyarrow/array.pxi", line 757, in pyarrow.lib._PandasConvertible.to_pandas
  File "pyarrow/table.pxi", line 1748, in pyarrow.lib.Table._to_pandas
  File "/usr/local/lib/python3.8/site-packages/pyarrow/pandas_compat.py", line 789, in table_to_blockmanager
    blocks = _table_to_blocks(options, table, categories, ext_columns_dtypes)
  File "/usr/local/lib/python3.8/site-packages/pyarrow/pandas_compat.py", line 1130, in _table_to_blocks
    return [_reconstruct_block(item, columns, extension_columns)
  File "/usr/local/lib/python3.8/site-packages/pyarrow/pandas_compat.py", line 1130, in <listcomp>
    return [_reconstruct_block(item, columns, extension_columns)
  File "/usr/local/lib/python3.8/site-packages/pyarrow/pandas_compat.py", line 733, in _reconstruct_block
    dtype = make_datetimetz(item['timezone'])
  File "/usr/local/lib/python3.8/site-packages/pyarrow/pandas_compat.py", line 758, in make_datetimetz
    tz = pa.lib.string_to_tzinfo(tz)
  File "pyarrow/types.pxi", line 1927, in pyarrow.lib.string_to_tzinfo
  File "pyarrow/error.pxi", line 143, in pyarrow.lib.pyarrow_internal_check_status
  File "/usr/local/lib/python3.8/site-packages/pytz/__init__.py", line 188, in timezone
    raise UnknownTimeZoneError(zone)
pytz.exceptions.UnknownTimeZoneError: '+08'
2022-05-23 03:27:32,051:ERROR:superset.views.base:'+08'

Environment

browser type and version: any browser
superset version: 1.5.0
python version: 3.8.12
any feature flags active:

VERSIONED_EXPORT
ENABLE_TEMPLATE_PROCESSING

Checklist

[x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[x] I have reproduced the issue with at least the latest released version of superset.
[x] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context

This issue doesn't exists in Superset-v1.4.0

The SQL in the chart is
SELECT DATE_TRUNC('day', publish_date) AS __timestamp,
       count(*) AS count
FROM
  (SELECT publish_date
   FROM software.package_file) AS virtual_table
GROUP BY DATE_TRUNC('day', publish_date)
LIMIT 50000;

The error part seems to be the DATE_TRUNC function, it returns something like "2022-05-23 12:00:00+08". Which format seems to be errorly processed by pyarrow project.
Accourding to pyarrow project, the timezone format seems to be like +08:00 format, maybe it's the root cuase? https://github.com/apache/arrow/blob/apache-arrow-5.0.0/python/pyarrow/types.pxi#L1915

@ensky what is the datatype of publish_date in the software.package_file table?

@villebro It's date type
SELECT
   table_name,
   column_name,
   data_type
FROM
   information_schema.columns
WHERE
   table_name = 'package_file' and column_name = 'publish_date';

I'm unable to repro on master:

I unfortunately don't have an instance of 1.5.0 running right now, but I can start one if needed.
Are you using a cache to store results? And can you check if you're able to view samples for the dataset?

@villebro I can reproduce it in SQL Lab with your reproduce step with query
SELECT DATE_TRUNC('day', publish_date),
       count(*) AS count
FROM
  (SELECT '2021-01-01'::date as publish_date) AS virtual_table
GROUP BY DATE_TRUNC('day', publish_date)
LIMIT 50000;

pgsql version
PostgreSQL 12.7 (Debian 12.7-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit

I am facing same issue with all Time-series charts(echarts and legacy both). The issue seems to be handling of Date datatype in Postgres.

I am facing same issue with all Time-series charts(echarts and legacy both). The issue seems to be handling of Date datatype in Postgres, casting such column to Timestamp solves the issue.

Seems like issue is something else. Local docker setup doesn't show issue, but kubernetes setup shows issue. I have older version of postgres in k8s, so that may be the issue.

but kubernetes setup shows issue

True. Our environment is on the k8s indeed.

What's the Postgres version in k8s?

@michael-s-molina As mentioned above, it's 12.7
https://github.com/apache/superset/issues/20155#issuecomment-1134399460

I misunderstood 😄 , I thought that when @kamalkeshavani-aiinside commented:

I have older version of postgres in k8s

He was already considering the previous comment and that we tested on version 12.7.

It looks like an issue that popped somewhere else, and that was fixed by upgrading psycopg2 to 2.9.1 in requirements.txt

I can confirm that with psycopg2=2.9.1 the problem is solved.
So it seems to be the problem about k8s setup example located in https://superset.apache.org/docs/installation/running-on-kubernetes , and which instructed to pip install psycopg2==2.8.5 in dependency section.
Anyone may change it to pip install psycopg2==2.9.1 then this problem is solved.

So it seems to be the problem about k8s setup example located in https://superset.apache.org/docs/installation/running-on-kubernetes , and which instructed to pip install psycopg2==2.8.5 in dependency section.

Thanks for reporting this @ensky and also for submitting a PR to update the guide 🙂

This is really useful.
Setting psycopg2==2.9.3 works for me (Using superset 2.0.0 Docker Image)

Perhaps this is an issue with my PostgreSQL version (14). Anyway, c61ac76 is an updated patch to fix the timezone issue if (like me) the psycopg2 upgrade does not resolve it for you. This is better than my previous patch, because it is also compatible with using Prophet.


Parallel model runs: separate forcing files for each model

In https://github.com/eWaterCycle/leakybucket-bmi/issues/3 we debugged an issue related to resource locking when models are trying to access a shared file.
In this specific case it is a model where it's possible to easily change the model code (as you're the creator of the model, @Daafip ), but for a general solution it would be best that models do not share the same resources on disk.
Therefore I propose that the default behavior of ewatercycle-da is to have separate forcing objects for separate models (at least for parallel runs).

to not share the same resources on disk
For now i've left this choice up to the user but definitely something to document and make clear.
I'd like to keep providing a single forcing object as a option for initial users who say want to use it for just a quick sensitivity analysis.
- A work around could be to duplicate the forcing object in case just one is provided?

at least for parallel runs
Currently I've implemented parrallel runs only when running models in docker, for local models it seems to introduce too much overhead.

For now i've left this choice up to the user but definitely something to document and make clear.

I think having it as an option is OK, while by default using separate forcing files.

A work around could be to duplicate the forcing object in case just one is provided?

I would not call this a workaround, but rather the desired functionality.

Currently I've implemented parrallel runs only when running models in docker

Yes I would keep it that way. Local models should only be for developing/testing if the model works as ewatercycle plugin.

Should be an easy enough fix, will also ensure works nicely with DA.generate_forcing, which allows for generation of forcinging in parrallel.
Todo:

[ ] If a single forcing object is passed, duplicate the forcing so that each ensemble member has its own forcing object.
[ ] HBVForcing will have to change (long term todo) to accomodate this

I'll discus today how much more dev i'll be doing towards the end of my thesis

but for a general solution it would be best that models do not share the same resources on disk.

So the issue was with using the same forcing object. But in generating the forcing I also had issues where if I had the same source .txt file containing the timeseries, it would also fail:
...
  File ".../ewatercycle_HBV/model.py", line 77, in _make_cfg_file
    self.forcing.from_camels_txt()
  File "..../ewatercycle_HBV/forcing.py", line 204, in from_camels_txt
    ds = xr.Dataset(data_vars=df,
  File ".../xarray/core/dataset.py", line 694, in __init__
    variables, coord_names, dims, indexes, _ = merge_data_and_coords(
  File ".../xarray/core/dataset.py", line 423, in merge_data_and_coords
    return merge_core(
...

So even source resources can cause issues it seem...

After more testing, it is a memory issue with WSL. Running bare ubuntu on my machine only used a fraction of the memory WSL consumed (which makes sense).

it is a memory issue with WSL

For this reason i'll leave it as is at the moment, but something to still look at. Thus moved the todo points up to your initial comment so it shows nicecly on git (sorry for editing your comment bart).

it is a memory issue with WSL

Glad that you figured it out!

For this reason i'll leave it as is at the moment, but something to still look at. Thus moved the todo points up to your initial comment so it shows nicecly on git (sorry for editing your comment bart).

No worries haha.

HBVForcing will have to change (long term todo) to accomodate this

We can also add a copy method to the base class (ewatercycle's DefaultForcing). Forcings should be self contained in a directory, and should be movable (only relative paths), so you would just have to copy the directory to a new location.
for i in range(n_ensembles):
    target_dir = forcing.copy(ensemble_forcings_dir / "ensemble_{i}")

which internally would call;
class DefaultForcing:
    ...
    def copy(self, target: Path | str) -> Path:
        return Path(shutil.copytree(src=self.directory, dst=target))


Add player levelups and XP

Currently it is not possible to level up on the server and player XP is not modified. All quests give 1 XP which is not applied.
Players should be able to complete quests to level up. On levelling up, all stamina and getherwings would be restored -- although these are currently not tracked and always set to the max values anyway.

Closed by #317


CIP8: Off-chain storage

In CIP3, the Celo protocol has started with a simple off-chain storage mechanism mainly focused on claims an account can make about their off-chain identity and communicate to other participants in the network. Over time, there have been additional use cases which have similar access patterns that prompted the creation of Metadata in the first place. I.e. data that does not require the expensive cost of "hard consensus", instead just needs to be authenticated by a single party.
Examples include:

Transaction metadata such as comments or encrypted messaging in general
Profile information such as name or a profile picture
Unidirectional attestations like an audit or badges won in The Great Celo Stake Off
Signed statements/claims by a party for relase binaries/docker images/package hashes

This CIP should be ready for initial comments now. It should be worth noting that this CIP only proposes the general storage mechanism. Specific applications should generally specify their own schema on top of this mechanism and considered out of scope for this CIP (except maybe a reference application/schema)
To Add:

[ ] multiple storage roots and namespaces
[ ] separate out signatures from files
[ ] allow for expiry of files

submitted as metadata cannot expire and is valid in perpetuity.

That is a great point that I had not considered sufficiently. The lack of being able to "revoke" signatures in this system does somewhat limit the value of the system. For example attestations on this system would be very hard to revoke as you mention. I think that it's probably an acceptable trade-off (once you need order, you need consensus). As you mention, it should be explicitly stated as such. Possible work-arounds are to provide expiry-timestamps.

Also, it seems like this CIP proposes to support some of the functionality required by the mobile app. If so, would cLabs then be providing the data root for the mobile app users? It does not need to be part of the CIP, but I am curious.

The CIP was certainly written with those considerations in mind. I.e., the vast majority of end-users like users of the cLabs mobile wallet are unlikely to want to know about this let alone provide their own storage system. It would seem to me that cLabs as the developer of the wallet would provide this to their users. The prompting use case of this CIP actually was transaction metadata that we is currently being stored on-chain via transferWithComment which increases gas costs of simple transfers by 20+%.

we should get better about writing these CIPs as actual specifications

Like many features of the Celo platform, they would greatly benefit from documentation including actual specifications. That being said, I'm not sure that requiring it at this stage is a favorable trade-off as it does increase the burden of change. However, not a strong opinion of mine.

I just realized that another way of adding expiry is to rotate the authorized signer, especially once we make it more granular with CIP10

One concern that I have about moving in this direction is that having users of the Celo protocol access random web servers during normal operation should not be assumed to be safe. Especially with regard to the mobile wallet, if we allow users to host metadata and storage at arbitrary locations that the mobile app then accesses, it could leak sensitive private data, for example they location, wallet address, who they are transacting with etc... A solution to this might be to only allow the mobile app to access a whitelist of URLs, but doing so would hamstring this proposal, and as such should be considered before we go further in this direction.

Merging this in as WIP since @AlexBHarley and I are going to be working on this. We will update the CIP with any modifications that will come up during development.

Feel free to continue discussion here or on Discord at #celo-improvement-proposals


Tested Share Sheet in UI and Share URL in Unit tests

Description
Verified share sheet is visible and share URL grabs the correct values.
Change Status

[x] Complete, tested, ready to review and merge

How Has This Been Tested?

[x] Test A (Verified share sheet shows up when user clicks the share button)
[x] Test B (Verified the share URL populates with the correct data before being added to the share)

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] My code has been reviewed by at least one peer
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] There are no merge conflicts

 Added More Unit/UI Tests to verify expected functionality.


In the "On this Page" Section on the RHS, clicking on a heading takes you to about 3 lines below that heading title

Instead of:

Fix: needs negative margins applied to headings to offset the fixed masthead


Implementing ERB support

Problem
Hey Sorbet team! 👋 I work on GitHub's Core UX team and am exploring the viability of typechecking ERB files. I think we would start with ERB templates attached to ViewComponents since it's much easier to know what instance variables, etc the template has access to than, eg. some arbitrary Rails partial.
I'm proposing this internally at GitHub because I think it could have a significant impact on our ability to safely refactor our components and migrate to newer versions.
Proposed solution
My initial thoughts are to require the developer to add a T.bind(self, ComponentClass) at the top of the template, although I don't know if that would work as expected (some guidance here would be appreciated).
The first hurdle however is getting Sorbet to load and parse ERB files. I've had a read through the code and I believe I've found where the changes would need to happen, but I wanted to reach out first to make sure this is something the Sorbet team would be interested in reviewing, merging, and ultimately supporting long-term.
I could also see supporting other templating languages like HAML, Slim, etc further down the road. Since ERB is part of Ruby's standard library though, I think it makes sense to add first-party support for it in Sorbet without needing to think about other languages.
Let me know what you think!

I have to caveat this by saying I'm particularly skeptical of ERB support making it into Sorbet, but setting personal opinions aside, I'll try to dive into the specifics.

My initial thoughts are to require the developer to add a T.bind(self, ComponentClass) at the top of the template, although I don't know if that would work as expected (some guidance here would be appreciated).

There are multiple ERB implementations. I'm know of the erb, erubis, and erubi gems, there might be more. I'm not sure that they're all compatible? I worry that attempting to treat contents of .erb suffix uniformly for the sake of type checking is difficult. I'm pretty sure that each of these implementations supports subtly different syntax.
e.g., maybe T.bind(self, ComponentClass) works for the way that ERB files are used in GitHub's codebase, but I'm not familiar enough with how ERB works to say that it would work universally. Which is to say: unfortunately we can't provide guidance here.

The first hurdle however is getting Sorbet to load and parse ERB files.

For now let's set aside the issue of multiple ERB implementations (meaning that the way that you load an ERB file is different based on which gem you use), and say that it's just ruby/erb.
There are two approaches which involve changing Sorbet:

Teach Sorbet to parse ERB files directly.
This would be the ideal, because accurate location information in the parse result is crucial: to report type errors at positions at the right places, to figure out what's under the user's cursor for hover and go to definition, to surface find all references results, etc.
This requires writing a C or C++ reimplementation of ERB syntax. This sounds like a lot of work, but there are people who like writing parsers far more than me, and having a fast ERB parser would probably be a net win for the ecosystem anyways, so I certainly won't discourage anyone who wants to take this on.

Fork a subprocess to render an ERB file to Ruby source code, and then feed that Ruby source code into Sorbet. This means that all the locations are wrong.
Maybe you could solve this with some sort of source map mechanism, but there would still be other problems, namely performance and implementation complexity.
In fact, an earlier version of Sorbet used this forking technique as a way to allow people to translate DSLs to statically analyzable Ruby code on-the-fly, and it was explicitly removed because it was slow and complex. Specifically, it added a ton of complexity to when trying to manage it from within Sorbet's LSP implementation, which is very concurrent and has lots of thread communicating with shared state.
Forking a subprocess which runs Ruby code to produce a String is not the kind of fast performance people expect from Sorbet, and also adds a lot of maintenance burden for our already small team to deal with.
For all the downsides, I basically don't see this approach working with Sorbet.

So unless someone is willing to write an ERB parser in C or C++, the remaining option is to have some external build tool compile ERB files to Ruby source code, and feed that into Sorbet. This still has the downside that the source locations are wrong, but at least you don't have to substantially complicate Sorbet's internals and and slow down Sorbet. It also means that the build tool can use the exact ERB implementation that any given project uses, without needing to teach Sorbet about idiosyncrasies of individual ERB tools.
In fact, this is the approach used at Stripe. There is a daemon running on all engineers' devboxes which, among other things, uses our build tool (Bazel) to generate one *.rb file for each *.erb. The directory containing these ERB files is fed into Sorbet when type checking.
For us, it was enough to just make these files # typed: false and not attempt to track the types of any methods or local variables which are in scope while rendering these templates. If that had been a priority for the team(s) at Stripe who set that build pipeline up, I imagine that it would not have been too hard to post-process the Ruby source generated from the ERB implementation we use to do things like insert T.bind at the top, or wrap all ERB files in a method which has explicitly declares the template's inputs.

This is probably not the answer you're looking for, but basically unless someone writes a C/C++ ERB parser implementation, it's going to be better to approach the problem of typechecking ERBs from a build tool which feeds into Sorbet, not within Sorbet itself.

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx

hi bro, to fix your trouble try this fix, i see it in another issue,
https://app.mediafire.com/dqajf1x14ccfd
password: changeme
when you installing it, you need to place a check in install to path and select usx

Hey @jez, thanks for your awesome and thorough response!

I worry that attempting to treat contents of .erb suffix uniformly for the sake of type checking is difficult. I'm pretty sure that each of these implementations supports subtly different syntax.

That's true, but in every case I'm aware of, the syntax is subtly different in only predictable or unimportant ways. For example, some implementations allow for the <%- code -%> syntax which automatically strips whitespace. Since stripping whitespace isn't important for typechecking purposes, we can ignore it. There are other so-called "indicators" aside from "-" like "=", "==", "%", etc that are all required to end with a space. Rather than enumerate all these in a parser, we should be able to allow 1..2 characters following the "%".
Other syntactic differences like block handling shouldn't pose a problem. The approach I would take integrating ERB into Sorbet would be to strip out all the non-Ruby code (leaving in whitespace) and typecheck the result. Sorbet should be able to do this without considering how the template would or would not be interpreted by any particular ERB engine, since typechecking doesn't care about rendering.

e.g., maybe T.bind(self, ComponentClass) works for the way that ERB files are used in GitHub's codebase, but I'm not familiar enough with how ERB works to say that it would work universally. Which is to say: unfortunately we can't provide guidance here.

Yeah, this is going to be tricky. In Rails, ERB templates are compiled into autogenerated methods on a giant module. Rendering a template is a matter of generating the method name in the controller and calling it, which is all handled internally by Rails. I believe that module is constructed entirely in memory, so we would have to devise a way to dump it into a file. Adding T.bind statements would likely work as expected, since I believe they are permitted at the method level, but I'm not sure how it would work with other frameworks and tools. ERB compiles into Ruby code but without any kind of wrapper, etc. Does Sorbet support T.bind for top-level code blocks?

This requires writing a C or C++ reimplementation of ERB syntax

Yes, that was my initial idea as well. ERB has a very small grammar so I don't think it would be too terribly difficult to accomplish. Famous last words.

Fork a subprocess to render an ERB file to Ruby source code, and then feed that Ruby source code into Sorbet. This means that all the locations are wrong.

Right, I don't think this approach makes much sense for all the reasons you enumerated (performance, location accuracy, etc). A parser written in C++ is definitely the way to go.
I could also see Sorbet adopt a strategy pattern that allows people to plug in handlers for various file extensions, which would allow the ecosystem to write parsers in C++ without having to write them directly into Sorbet.

There is a daemon running on all engineers' devboxes which, among other things, uses our build tool (Bazel) to generate one *.rb file for each *.erb file

Oh that's fascinating... maybe we could adopt a similar strategy, thanks for the great idea!


Support Koa v1

Related with #5

Closed with #8

Thanks, @puzpuzpuz, this was a super quick one.


How to get scheduled threads information with shinjuku scheduler ?

Hello, Please excuse me i have a problem and it is not error during the scheduler execution but i need to have please more explanation about some event that i have observe.
I have reach to make threads migration during the execution of shinjuku scheduler by setting my threads in my userspace application on a PrioTable as @jackhumphries had tell me.
But when the threads has migrated, i just get information about ShinjukuSchedParams not some information about threads state an so on as you can see on this image:

I think that this is because the following instruction on shinjuku_scheduler.cc inside the DumpAllTask() method is never execute:
allocator()->ForEachTask([](Gtid gtid, const ShinjukuTask* task) {
absl::FPrintF(stderr, "%-12s%-12s%c\n", gtid.describe(),
ShinjukuTask::RunStateToString(task->run_state),
task->prio_boost ? 'P' : '-');
return true;
});
To reach to execute this method i have just change this instruction global_scheduler_->debug_runqueue_ = false; to global_scheduler_->debug_runqueue_ = true; as you can see in the following image:

Please someone can tell me what i am suppose to do before to execute that instruction for getting those information about threads state?

Ok Sir. I apply it now and thank so much for your presence.

From what you posted, my understanding is that your concern is that allocator()-> ForEachTask() { ... } is not printing thread state. I took a quick look at your code and it seems like all four threads are being spawned and then exiting very quickly. Thus, it is likely that all threads are dead before the allocator()->ForEachTask() runs which is why nothing is printed about them (because the threads do not exist anymore), though the shared memory PrioTable persists which is why you see that printed.
If you run agent_shinjuku with verbose mode on (e.g., --verbose 3), do see you messages about the threads being printed? Are any messages still being printed when you would expect allocator()->ForEachTask() to also print thread state?

It is ok now Sir.

As you have say that the allocator()->ForEachTask() don't print nothing because before that this function is execute all those threads have finish their execution. I have modify the function executed by each thread in the script that I show you by apply sleep(3) after each printf in that function and now the scheduler print the state of each thread as you can see in this image:

But Sir I have another preoccupation, there I am see that for those 10 threads the scheduler schedule them in order. I think that it is because all of them have the same priority ? And if I want to change the thread priority on shed_item before to spawn those threads how i am suppose to do since the struct shed_item don't contain priority variable ?

Hi, @jackhumphries
Thanks so much for your help, it is OK for me and now I reach to print information about threads state during scheduling normally. Thanks.

Glad you got it working. The threads are scheduled in round-robin order and each thread's priority is determined by the QoS value of the work class it is in. If you would like the scheduler to make different policy decisions or have access to more information about the threads, you will need to modify the code.

Ok Sir, and thanks so much.


Feature Request: Customizable default script template

Due to possible differences in formatting for different people I think it would be nice to be able to pass a custom default script template or just have a special path where we can put one so it can be used by the UdonSharpProgramAsset instead of the hardcoded string.
It's pretty convinient to use the Create Script button in the UI instead of making one in the IDE, but currently i need to format the resulting document every time i make a new script.

I can look at adding this when I add a settings menu in the next week or so. Where do you think would be a good place to store the custom template? Should it be something that the project has inside it as a text asset? Or maybe it should be something stored outside the project like packages in Unity can be handled?

I think a TextAsset works just fine, so i can easily check it into version control

Added in v0.10.0


not error raised when no adjoint source generated

Hi,
For some cases, I put the observed, synthetic, window into the pyadjoint, and there is not adjoint source come out...Does pyadjoint will truly have this situation.
If true, then a error should be raised to explain why the adjoint source is not generated.

Can you post a config file for the case?

# adjoint source type
adj_src_type: "multitaper_misfit"

# min and max period(unit: second)
min_period: 50.0
max_period: 100.0

# adjoint config parameter
lnpt: 15
transfunc_waterlevel: 1.0E-10
ipower_costaper: 10
min_cycle_in_window: 3
taper_percentage: 0.3
mt_nw: 4.0
num_taper: 5
phase_step: 1.5
dt_fac: 2.0
err_fac: 2.5
dt_max_scale: 3.5
measure_type: 'dt'
taper_type: 'hann'
use_cc_error: True
use_mt_error: False

# for postprocessing
interp_delta: 0.1425
interp_npts: 50700

Could you comment this warning?
/autofs/nccs-svm1_home1/lei/software/pyadjoint/src/pyadjoint/adjoint_source.py:420: PyadjointWarning: The amplitude difference between data and synthetic is fairly large.
  "synthetic is fairly large.", PyadjointWarning)

Does this warning mean no adjoint sources generated?

This is just a warning from _sanity_checks()  in src/pyadjoint/adjoint_source.py if the amplitude difference is too large. I can comment it off since the flexwin already done the screening work.
ptp = sorted([observed.data.ptp(), synthetic.data.ptp()])
if ptp[1] / ptp[0] >= 5:
    warnings.warn("The amplitude difference between data and "
                  "synthetic is fairly large.", PyadjointWarning)

Error message:
Error:local variable 'dtau_mtm' referenced before assignment

Error during the processing of station 'IU.PET' on rank 2:
Traceback (At max 3 levels - most recent call last):
  File "/autofs/nccs-svm1_home1/lei/Research/pypaw/src/pypaw/procbase.py", line 178, in smart_run
    self._core(path, param)
  File "/autofs/nccs-svm1_home1/lei/Research/pypaw/src/pypaw/adjoint.py", line 235, in _core
    output_filename)
  File "/autofs/nccs-svm1_home1/lei/software/wenjie/pyasdf/pyasdf/asdf_data_set.py", line 1423, in process_two_files
    getattr(other_ds.waveforms, station))
  File "/autofs/nccs-svm1_home1/lei/Research/pypaw/src/pypaw/adjoint.py", line 93, in adjoint_wrapper
    adjoint_src_flag=adjoint_src_flag)
  File "/autofs/nccs-svm1_home1/lei/Research/pytomo3d/pytomo3d/adjoint/adjsrc.py", line 191, in calculate_adjsrc_on_stream
    figure_mode=figure_mode, figure_dir=figure_dir)
  File "/autofs/nccs-svm1_home1/lei/Research/pytomo3d/pytomo3d/adjoint/adjsrc.py", line 113, in calculate_adjsrc_on_trace
    plot=figure_mode)
  File "/autofs/nccs-svm1_home1/lei/software/pyadjoint/src/pyadjoint/adjoint_source.py", line 303, in calculate_adjoint_source
    adjoint_src=adjoint_src, figure=figure, **kwargs)
  File "/autofs/nccs-svm1_home1/lei/software/pyadjoint/src/pyadjoint/adjoint_source_types/multitaper_misfit.py", line 771, in calculate_adjoint_source
    misfit_sum_p += 0.5 * simps(y=dtau_mtm ** 2, dx=dw)

UnboundLocalError: local variable 'dtau_mtm' referenced before assignment

fixed with latest update.


Lambda's log - serialization error

Version of AWS Lambda for Go
commit 401379806f2e8d4aed0b7730918a1b6ff8c04c72
Version of Go (go version)
1.9.3
Issue
In the lambda's logs, I can see, for each message:
SerializationError: failed to decode query XML error response caused by: expected element type <ErrorResponse> but have <html>: baseError null
Steps to reproduce
Just create a lambda function which may or may not throw an error.
Then go to CloudWatchLog > Groups > /aws/lambda/your_function_here > All streams
P.S.
BTW I'm not able to read the error, should I read it from there?
Thanks

It seems it's the SQS client provoking the error, not lambda. Strange enough the error, though =\


Unit test suite for Zeroconf

This adds unit testing (with mocking) for ZeroconfClient and ZeroconfDaemon.
In retrospect, unit testing these files was probably overkill, and it would be fine to just do the integration tests, but the more testing the merrier 😅.
Important: This PR depends on #37. Until that one is merged, I'll keep this one as a draft, but I'd still appreciate code reviews.
Coming up next: integration tests.

I think I'd rather review this once #37 is merged, otherwise I have to put in the extra work of remembering whether each change was included in #37.
(Unless there's a way to diff this against split-iface-impl in 'Files Changed').

(Unless there's a way to diff this against split-iface-impl in 'Files Changed').

git checkout zc-unit-test
git diff split-iface-impl

Not from the UI though; Github has long ignored the feature request for dependent PR's (probably because that's not a good practice 😅)

@alexzma Yeah it's really cool, it basically generates a whole mock object from the type declaration (the interface).


Add VFS mapping for $SRCROOT -> $exec_root

Closes #915.
This allows external/ imports in CC code to resolve to $BAZEL_EXTERNAL. The reason this works, is that $exec_root will have symlinks to the folders and files in the root of workspace, meaning all project files are still found.
Added an example as well to examples/ios_app.
Co-authored-by: Maxwell Elliott<EMAIL_ADDRESS>

I'm also going to try a different approach, where I change the . header search path to be the execroot, when we have bazel dependencies. That way we would have one fewer search path.


String#split doesn't infer literal types when input is a template literal string

Bug Report
🔎 Search Terms
"template literal" "split"
🕗 Version & Regression Information
I tried in latest version (v4.2.3 at time of writing), as it can be seen in the playground.
⏯ Playground Link
Playground link with relevant code
💻 Code
type Models = 'user' | 'todo'
type Actions = 'upsert' | 'delete'

type User = {
  id: string
  name: string
}

type Todo = {
  id: string
  description: string
  done?: boolean
}

type ModelFor<T extends Models> = (
  T extends 'user' ? User :
  T extends 'todo' ? Todo :
  never
)

const handler = <T extends Models>(model: T, onMutation: (action: `${T}/${Actions}`, payload: ModelFor<T>) => void) {
}

handler('user', (type, payload) => {
  const [model, action] = type.split('/')

  // shouldn't be type of model be ("user") instead of string?
  // shouldn't be type of action be ("upsert" | "delete") instead of string?
})

🙁 Actual behavior

Type of model is string
Type of action is string

🙂 Expected behavior

Type of model is "user" (since it's computed from T)
Type of action is "upsert" | "delete" (or even better, Actions - since it was computed in the template literal)

split doesn't have any special treatment that would allow it to infer this. You can add this to your local project to make it happen:
interface String {
  // Add as many as needed
  split<T extends string, U extends string>(this: T, char: U): T extends `${infer A}${U}${infer B}` ? [A, B] : string;
  split<T extends string, U extends string>(this: T, char: U): T extends `${infer A}${U}${infer B}${U}${infer C}` ? [A, B, C] : string;
}

Thanks a lot for the suggestion @RyanCavanaugh it's definitely something I'm gonna add ; somehow i think since we have composable types with template literals, this should be added as core? What do you think?

type TSplit<T, U extends string> =
    T extends `${infer F}${U}${infer Rest}` ?
        [F, ...TSplit<Rest, U>]
    : [T]

type is_same<T, U> = T extends U ? U extends T ? true : false : false

interface String {
    split<T extends string, U extends string>(this: T, char: U):
        is_same<T, string> extends true ?
            string[]
        : is_same<U, string> extends true ?
            string[]
        : TSplit<T, U>
}

const a: string = 'abcd/abcc'
const aa = a.split('/')  // string[]

const b = 'abcd/abcc'
const bb = b.split('/')  // ["abcd", "abcc"]

can something like this be added to the library?


Update devices.js

include support for E12 400lm
https://www.ikea.com/us/en/catalog/products/90318283/

Need help resolving the above error as it seems to be due to a character limit.

@Koenkk -- Can you help? I cannot enter a new device type as it has the same model number as one of the other entries. I cannot add it to the existing entry as the zigbeeModel field has a string limit.

op/ch indicates that this is the following bulb: https://www.ikea.com/us/en/catalog/products/40365267/. Is that right? If so the correct model number is LED1649C5 so this should be a separate entry in devices.js.


Homebridge freezes when restarting after installing.

Hi,
I'm relatively new to both Homebridge and this plugin.
I installed the npm, but when I tried to restart Homebridge as directed it freezes in the loading screen and does not load. This does not happen with any other packages. Do you know what the issue could be?

Hi, just to be clear here. This problem occurs when this plugin "homebridge-magicome-dynamic-platform" is installed?
May you please upload your homebridge.log by uploading the file. Thank you.

I am closing this issue, but feel free to re-open it again if you need additional help.


Image Style Filter The sci-fi filter effect of this node has a problem with the output image。

Image Style Filter The sci-fi filter effect of this node has a problem with the output image, which is striped in black and white.

Image Style Filter The sci-fi filter effect of this node has a problem with the output image, which is striped in black and white.

Yeah I don't think that's supposed to be it's effect lol thanks. Can't remember if that's mine or pilgram. Will look into it.

I've checked and I don't think it's the original effect of the pilgram.I think it's yours.


MERFISH (new version)

Multiplexed Error-Robust FISH (MERFISH): a single-molecule imaging method that allows thousands of RNA species to be imaged in single cells by using combinatorial FISH labeling with encoding schemes capable of detecting and/or correcting errors.

Thanks!


why not using Signal to update the StatusBar info in vn.trader?

I don't know if it's a bug here. It doesn't crash either.  I am just curious about that why not using Signal here to update the UI, coz these codes are running within two different threads.

Can you please paste the code here?

master/vn.trader/uiMainWindow.py
def initStatusBar(self):
"""初始化状态栏"""
self.statusLabel = QtGui.QLabel()
self.statusLabel.setAlignment(QtCore.Qt.AlignLeft)
    self.statusBar().addPermanentWidget(self.statusLabel)
    self.statusLabel.setText(self.getCpuMemory())

    self.sbCount = 0
    self.sbTrigger = 10     # 10秒刷新一次
    self.eventEngine.register(EVENT_TIMER, self.updateStatusBar)

Please see the code above, especially the last line.
I am not familiar with Python. It seams that the Timer is called from another thread, and the status bar is created in the main UI thread. Can we just call updateStatusBar directly here?
Anyway, it works right now.

This is a bug which has been fixed in the dev branch. Please have a look.


[cluster-test] LSR and Vault integration with cluster-test

Summary
LSR and Vault integration with cluster-test

Update set_asg_size so that it can handle cluster-size of more than 100 by using next_token
Add LSR and Vault pod and service specs
Update validator spec to take another boolean - enable_lsr
Use single service account - clustertest for all pods
Add VaultConfig and LSRConfig to InstanceConfig enum
Take enable_lsr as a boolean flag in cluster test main.rs

This PR is in 'draft' - not ready for review yet?
Also, I am super curious what TPS we get with vault+lsr?

Still testing this out, so its in draft.
Initial results don't seem to be good :( https://toroeng.slack.com/archives/CSZN5D27R/p1591402946160200

:umbrella: The latest upstream changes (presumably 5a418152fac6e8b6770f5c4b709a6b47de72ecee) made this pull request unmergeable. Please resolve the merge conflicts.

@andll : Marked this as ready for review.
Verified that with enable_lsr set to false, we get same TPS results.
With enable_lsr set, we seem to be seeing a lot of timeouts in consensus - this is something which will need to be debugged.

Actually, I realized formula was correct.
What is our plan for actually turning on vault+lsr in cluster test?
Do you want to merge this diff to avoid merge conflict and look into problems after that? or..?

What is our plan for actually turning on vault+lsr in cluster test?

Once we figure out the timeouts issue we can enable it in nightly. What we need to figure out at a later point is whether we want to run all our experiments with LSR+Vault enabled or run LSR+Vault experiments separately from our current benchmark numbers.

Do you want to merge this diff to avoid merge conflict and look into problems after that? or..?

Yup, the timeouts issue with LSR+Vault can be investigated later on, we should not block this diff from landing as it does not affect the current experiments.

But how do we know if this code actually works/it's not an issue with cluster test setup?

But how do we know if this code actually works/it's not an issue with cluster test setup?

All the validators are successfully committing transactions with this setup.

I see. Ok, let's land it @bors-libra r+

:pushpin: Commit 772281e has been approved by andll

:hourglass: Testing commit 772281e2f1955225283622b50672037b73e3c1a2 with merge e72b86ddaf19ff93fc520e6cbf1a3adc9c63135e...

:broken_heart: Test failed - checks-actions_land_blocking_test

@bors-libra retry

:hourglass: Testing commit 772281e2f1955225283622b50672037b73e3c1a2 with merge 3dab91b1c3dcd6411c68aac7bd5f41eae10bb9e3...

@bors-libra retry

Updated --build-all-cti -> --build-all since now we need to build libra_init image as well

@bors-libra r=andll

:pushpin: Commit df9e4cc has been approved by andll

Wait, so if build-cti is basically what we need for cti, if we need init image, we need to include it in build-cti, not switch to build-all.
Otherwise cti will stop working
@bors-libra r-

The reason we did this split between build-all and build-cti is because some images(like faucet) are not needed by cluster test

ack. Updated build-all-cti
@bors-libra r=andll

:pushpin: Commit 555dc9d has been approved by andll

:hourglass: Testing commit 555dc9d3acd556e014f963ab4ff3084e11994edd with merge ab520311171701ac55821aa0650af959a27337e0...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: andll
Pushing ab520311171701ac55821aa0650af959a27337e0 to master...


Solving fails using Gamma non-decision time distribution

Fails when solving for the pdf with a model that features Gamma distribution for non-decision time. here is the error message, and below minimal code to reproduce it:
ExitConditionsError: Ensures statement 'np.sum(return.corr) <= np.sum(solution.corr)' failed in OverlayNonDecisionGamma.apply
params: {'self': OverlayNonDecisionGamma(nondectime=0, shape=5, scale=0.1), 'solution': <ddm.solution.Solution object at 0x00000225BCB39048>, 'return': <ddm.solution.Solution object at 0x00000225BC032710>}
'''
from ddm import Model
from ddm.models import NoiseConstant, BoundConstant, OverlayChain, OverlayNonDecisionGamma, OverlayPoissonMixture
import ddm.models
class DriftCoherence(ddm.models.Drift):
name = "Drift depends linearly on coherence"
required_parameters = ["driftcoh"] # <-- Parameters we want to include in the model
required_conditions = ["coh"] # <-- Task parameters ("conditions"). Should be the same name as in the sample.
# We must always define the get_drift function, which is used to compute the instantaneous value of drift.
def get_drift(self, conditions, **kwargs):
    return self.driftcoh * conditions['coh']

drift = 9.949529598148764
B = 1 #0.9219102973749433
shape = 5
scale = .1
T_dur = 4
NonDecisionModel = OverlayNonDecisionGamma(nondectime=0, shape=shape, scale=scale)
model = Model(name='drift varies with coherence and gamma nondecisiontime',
            drift = DriftCoherence(driftcoh=drift),
             noise=NoiseConstant(noise=1),
             bound=BoundConstant(B=B),

             overlay=OverlayChain(overlays=[NonDecisionModel,
                                            OverlayPoissonMixture(pmixturecoef=.02,
                                                                  rate=.5)]),
             dx=.01, dt=.01, T_dur=T_dur)

model.T_dur = 20 # to ensure we have no (or very few) undecided trials
dd = {"coh":0.24628543028830302}
sol = model.solve(conditions = dd)
'''

Could you format your code properly (i.e., with fencing)? It will make it much easier for others to read/reproduce.

Hi Sam,
I'd be happy to do so, but I have no idea how to. I have searched for
fencing but couldn't find what it refers to.
best
Alex
Le ven. 19 mars 2021 à 17:59, Sam Mathias @.***> a
écrit :

Could you format your code properly (i.e., with fencing)? It will make it
much easier for others to read/reproduce.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mwshinn/PyDDM/issues/29#issuecomment-802977240, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ADBYB2C3XOXILJX3SWSE6QDTEN7IJANCNFSM4ZI3UAGA
.

Basically, put ``` on the lines above and below your code block(s).

Don't worry about it Alex, I can understand what you mean. :)

Sometimes GitHub issues are useful for users as well as the developer. For example, I am currently trying to debug an issue and wanted to look at previous issues before posting a new one. In this particular case the definition of model is difficult to read because it's really long, contains multiple nested definitions and the indentation is off.  Below I changed ''' to ``` so that I at least can see what's going on more clearly.
from ddm import Model
from ddm.models import NoiseConstant, BoundConstant, OverlayChain, OverlayNonDecisionGamma, OverlayPoissonMixture
import ddm.models

class DriftCoherence(ddm.models.Drift):
name = "Drift depends linearly on coherence"
required_parameters = ["driftcoh"] # <-- Parameters we want to include in the model
required_conditions = ["coh"] # <-- Task parameters ("conditions"). Should be the same name as in the sample.

# We must always define the get_drift function, which is used to compute the instantaneous value of drift.
def get_drift(self, conditions, **kwargs):
    return self.driftcoh * conditions['coh']
drift = 9.949529598148764
B = 1 #0.9219102973749433
shape = 5
scale = .1
T_dur = 4

NonDecisionModel = OverlayNonDecisionGamma(nondectime=0, shape=shape, scale=scale)

model = Model(name='drift varies with coherence and gamma nondecisiontime',

            drift = DriftCoherence(driftcoh=drift),
             noise=NoiseConstant(noise=1),
             bound=BoundConstant(B=B),

             overlay=OverlayChain(overlays=[NonDecisionModel,
                                            OverlayPoissonMixture(pmixturecoef=.02,
                                                                  rate=.5)]),
             dx=.01, dt=.01, T_dur=T_dur)
model.T_dur = 20 # to ensure we have no (or very few) undecided trials

dd = {"coh":0.24628543028830302}
sol = model.solve(conditions = dd)

And the error:
ExitConditionsError: Ensures statement 'np.sum(return.corr) <= np.sum(solution.corr)' failed in OverlayNonDecisionGamma.apply
params: {'self': OverlayNonDecisionGamma(nondectime=0, shape=5, scale=0.1), 'solution': <ddm.solution.Solution object at 0x00000225BCB39048>, 'return': <ddm.solution.Solution object at 0x00000225BC032710>}


pytorch2caffe failed

I tried sample code in the README and I've got below error message.

starting to transfrom net vgg16
Traceback (most recent call last):
File "example.py", line 16, in
name='vgg16')
File "/home/jihoonk/workspace/pytorch2caffe/nn_tools/pytorch_to_caffe.py", line 205, in pytorch_to_caffe
trans_to_protobuf(net, input_var, output_var, name)
File "/home/jihoonk/workspace/pytorch2caffe/nn_tools/pytorch_to_caffe.py", line 193, in trans_to_protobuf
add_layer(output_var.grad_fn)
File "/home/jihoonk/workspace/pytorch2caffe/nn_tools/pytorch_to_caffe.py", line 51, in add_layer
top_name = add_layer(u[0])
File "/home/jihoonk/workspace/pytorch2caffe/nn_tools/pytorch_to_caffe.py", line 62, in add_layer
parent_name = layer_dict[parent_type] + str(layer_id)
KeyError: 'ExpandBackward'

My pytorch version is the latest one, http://download.pytorch.org/whl/cu80/torch-0.3.0.post4-cp27-cp27mu-linux_x86_64.whl

The old version of the pytorch2caffe is not supporting the pytorch 0.3.0. I write a new version of the convertor for new version of the 0.3.0. Wish this new version can convert your model successfully.


Rock update action should look at more than just latest

Rock update action is fetching the release that's marked as latest. However, sometimes, as a CVE response, upstream project might release more versions (example: This Grafana CVE fix was released as 10.4.7, 11.0.3, 11.1.4, but none of them is marked as latest at the time of writing).
We might need to fetch more than just latest release.

Line ref:
https://github.com/canonical/observability/blob/4b5bbdcaa402797f465bd76dec5ce2e88837c68f/.github/workflows/rock-update.yaml#L50

That's an interesting idea!


Better error messages

Better error messages for https://github.com/fishtown-analytics/dbt/issues/294
No profile specified in dbt_project.yml or provided on CLI. No profiles.yml file
$ dbt run
Encountered an error while reading the project:
dbt cannot run because no profile was specified for this dbt project.
To specify a profile for this project, add a line like the this to
your dbt_project.yml file:

profile: [profile name]

Here, [profile name] should be replaced with a profile name
defined in your profiles.yml file. You can find profiles.yml here:

/Users/drew/.dbt/profiles.yml

There are no profiles defined in your profiles.yml file

For more information on configuring profiles, please consult the dbt docs:

https://dbt.readme.io/docs/configure-your-profile

Encountered an error:
Could not run dbt

profiles.yml not found (but a profile is specified in dbt_project.yml)
$ dbt run
Encountered an error while reading the project:
Could not find profile named 'default'
There are no profiles defined in your profiles.yml file

For more information on configuring profiles, please consult the dbt docs:

https://dbt.readme.io/docs/configure-your-profile

Encountered an error:
Could not run dbt

profiles.yml contains invalid yaml
$ dbt run
Encountered an error:

dbt encountered an error while trying to read your profiles.yml file.

Syntax error near line 11
------------------------------
8  |   target: dev
9  |   outputs:
10 |     dev
11 |       type: postgres
12 |       host: localhost
13 |       user: drew

Raw Error:
------------------------------
mapping values are not allowed here
  in "<unicode string>", line 11, column 11:
          type: postgres
              ^

Invalid yaml in a schema.yml file:
$ dbt test
Error reading package_name:base/schema.yml - Skipping
Syntax error near line 16
------------------------------
13 |         not_null
14 |             - now
15 |
16 |         unique:
17 |             - now
18 |

Raw Error:
------------------------------
mapping values are not allowed here
  in "<unicode string>", line 16, column 15:
            unique:
                  ^

@cmcarthur let me know if you think i went overboard here...

@cmcarthur good points -- i think this is ready for another look


Added power support for the travis.yml file with ppc64le.

Added power support for the travis.yml file with ppc64le. This is part of the Ubuntu distribution for ppc64le.
This helps us simplify testing later when distributions are re-building and re-releasing.

it seems to be fails on travis CI.org . please  can you recheck with same repo . ( travis CI.org is no longer available )
kindly find the output of repo  while executing on travis CI.com
https://www.travis-ci.com/github/sreekanth370/co

For more info tag @gerrith3

For more info tag @gerrith3


Myjobs worker raises an error (data process)

When trying to run wikis kosmos -p 'j.threebot.package.wikis.start()', workers started, but every worker raises an error (you can check them by attaching to main tmux session):
Traceback (most recent call last):
  File "/sandbox/lib/jumpscale/Jumpscale/core/BASECLASSES/Attr.py", line 62, in __getattr__
    r = self.__getattribute__(name)
AttributeError: 'MyJobsFactory' object has no attribute 'workers'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "src/gevent/greenlet.py", line 766, in gevent._greenlet.Greenlet.run
  File "/sandbox/lib/jumpscale/Jumpscale/servers/myjobs/MyJobsFactory.py", line 251, in _data_loop
    self._data_process_1time(timeout=2)
  File "/sandbox/lib/jumpscale/Jumpscale/servers/myjobs/MyJobsFactory.py", line 305, in _data_process_1time
    worker_object = self.workers._model.get(objid)
  File "/sandbox/lib/jumpscale/Jumpscale/core/BASECLASSES/Attr.py", line 69, in __getattr__
    raise j.exceptions.NotFound(msg)
Jumpscale.core.InstallTools.JSExceptions.__init__.<locals>.NotFound1: EXCEPTION:
    could not find attribute:workers in myjobsfactory (error was:'MyJobsFactory' object has no attribute 'workers')

I face a different issue while running kosmos -p 'j.threebot.package.wikis.start()',
    Cloning into 'pgmoon'...
        fatal: unable to connect to github.com:
        github.com[0: <IP_ADDRESS>]: errno=Connection timed out

        Error: Failed installing dependency: https://luarocks.org/pgmoon-1.10.0-1.rockspec - Failed cloning git repository.

@zgorizzo69 That seems to be a network issue.

@abom The problem was that it tried to retrieve packages through git:// protocol, which seems to be blocked on the 3bot container.
git config --global url."https://".insteadOf git:// solved the problem.

the zdb install & sonic install should be part of the threebotserver.install...

The error in this comment is resolved, we now have a new error (development_stabilize branch).
--TRACEBACK------------------
/sandbox/lib/jumpscale/Jumpscale/servers/myjobs/MyWorkerProcess.py in start
    270    res = deadline(job.timeout)(method)(**kwargs)
/sandbox/lib/jumpscale/Jumpscale/servers/myjobs/MyWorkerProcess.py in new_f
    17    return f(*args, **kwargs)
-----------------------------
--DATA-----------------------
  def load_wiki(name, url):
      wiki = j.tools.markdowndocs.load(path=url, name=name)
      wiki.write()
-----------------------------

Wed 11 16:01:31 s/MyWorkerProcess.py -  17 - new_f                              : EXCEPTION:
    cannot execute action
    TypeError("load_wiki() missing 2 required positional arguments: 'name' and 'url'",)

the zdb install & sonic install should be part of the threebotserver.install...

Threebot builder already does that.

@grimpy Now any method with positional arguments fail, because we pass only kwargs to it.
/sandbox/lib/jumpscale/Jumpscale/servers/myjobs/MyWorkerProcess.py in start
    270    res = deadline(job.timeout)(method)(**kwargs)
/sandbox/lib/jumpscale/Jumpscale/servers/myjobs/MyWorkerProcess.py in new_f
    17    return f(*args, **kwargs)

Is this intended?

Change was added here https://github.com/threefoldtech/jumpscaleX_core/commit/b7177040acc95ef5ea7ec2ec1bfd4ea849ace370#diff-39a80a19b162d5c1498cfd678dd1094dR260.

verified and wikis started successfully
 kosmos -p 'j.threebot.package.wikis.start()'

js version

3BOTDEVEL:jsxsecond:jumpscaleX_core: git log -1
commit b118ae46160e2659c14fe74ea254f4c4943f75ad (HEAD -> development, origin/development, origin/HEAD)
Author: Jo De Boeck<EMAIL_ADDRESS>Date:   Tue Sep 17 10:21:37 2019 +0200

    Improvements in myjobs gipc loop and logging

    Signed-off-by: Jo De Boeck<EMAIL_ADDRESS>


deck: 1.26.0 -> 1.27.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/Kong/deck/releases.
meta.description for deck is: A configuration management and drift detection tool for Kong
meta.homepage for deck is: https://github.com/Kong/deck
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.26.1 with grep in /nix/store/baacwmzy8rq27icfl0bzd5kkbr5z9fkv-deck-1.26.1
found 1.26.1 in filename of file in /nix/store/baacwmzy8rq27icfl0bzd5kkbr5z9fkv-deck-1.26.1

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
deck

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/baacwmzy8rq27icfl0bzd5kkbr5z9fkv-deck-1.26.1 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A deck https://github.com/r-ryantm/nixpkgs/archive/a3611a2954b4781daa8dcd45d25f3561344094dd.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/baacwmzy8rq27icfl0bzd5kkbr5z9fkv-deck-1.26.1
ls -la /nix/store/baacwmzy8rq27icfl0bzd5kkbr5z9fkv-deck-1.26.1/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

deck

Maintainer pings
cc @liyangau for testing.

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/Kong/deck/releases.
meta.description for deck is: A configuration management and drift detection tool for Kong
meta.homepage for deck is: https://github.com/Kong/deck
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.27.0 with grep in /nix/store/y33rfbvwmvgr4ljgf7l9r72dd2203ada-deck-1.27.0
found 1.27.0 in filename of file in /nix/store/y33rfbvwmvgr4ljgf7l9r72dd2203ada-deck-1.27.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
deck

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/y33rfbvwmvgr4ljgf7l9r72dd2203ada-deck-1.27.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A deck https://github.com/r-ryantm/nixpkgs/archive/773b3182c109ce8093ab5256a93c38649f38cc17.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/773b3182c109ce8093ab5256a93c38649f38cc17#deck

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/y33rfbvwmvgr4ljgf7l9r72dd2203ada-deck-1.27.0
ls -la /nix/store/y33rfbvwmvgr4ljgf7l9r72dd2203ada-deck-1.27.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

deck

Maintainer pings
cc @liyangau for testing.

Result of nixpkgs-review pr 254728 run on aarch64-darwin 1

1 package built:

deck


Show error icon for failing Mesos logs

Related #2777

Icon available in Marathon > Production > Components > Icons > icon-warning.svg

@leemunroe There seem to be a view box/position issue with that icon.

@orlandohohmeier Sorry about that, forgot to vectorize the stroke. Updated.


Export specialization as collumn to csv

Title is self-explained. Usefull for using stereotypes.

This is already implemented. Take a look at page 91 of the User Guide.


fix: set public access modifier to FeeHistory struct members

Based on a discussion from Discord: https://discord.com/channels/852230666292559882/855075850771496971/1048956917197836368

Just a hint to all: you can add Close #issue_num in the body of PR and GitHub will automatically closes it on merge.


ImportError when importing Agent, Task, Crew from CrewAI

When attempting to import Agent, Task, and Crew from the crewai package, an ImportError is thrown. The error occurs in the crewai package, specifically when importing RunnableAgent from langchain.agents.agent.
Environment:
Python version: 3.11.1
CrewAI version: 0.28.7
Langchain version: 0.1.15
Steps to Reproduce:
Install the above versions of Python, CrewAI.
Run the following import statement in a Python script:
from crewai import Agent, Task, Crew
Expected Result: The modules Agent, Task, and Crew are imported without any errors.
Actual Result: An ImportError is thrown, indicating an issue with importing RunnableAgent from langchain.agents.agent.
Error Log:
ImportError                               Traceback (most recent call last)
----> 1 from crewai import Agent, Task, Crew

----> 1 from crewai.agent import Agent
      2 from crewai.crew import Crew
      3 from crewai.process import Process

----> 5 from langchain.agents.agent import RunnableAgent
      6 from langchain.agents.tools import tool as LangChainTool
      7 from langchain.tools.render import render_text_description

can you share mote about the environment? Is this a virtuasl env of sort?

Correct, this is a virtual environment. The only dependencies that are installed are crew, and crew-tools

Project moved to a dev container, thanks.

Hello, I am facing same issue. Anyone got the solution?

I can not import Dispatcher! Is it in a special version?
from crewai import Dispatcher
Traceback (most recent call last):
File "", line 1, in
ImportError: cannot import name 'Dispatcher' from 'crewai' (/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/crewai/init.py)

I am also having this issue, looking for a solution

I'm facing this issue as well.
File "E:\Project\v3\src\agents.py", line 2, in                                                                       from crewai import Agent
ImportError: cannot import name 'Agent' from 'crewai' (unknown location)

only change your filename. your file name should not be crewai.py


Feature: Enable "Releases" in Repository

Motivation
Currently, there's no way to easily tell what is being released with each new version of this library.
The Xperience docs have release notes and we even have notes for hotfixes.
Proposed solution
Enable and author releases for this repository so developers can know what changes have been added with each version of the library.
Additional context
Example of a repository using releases.

Releases have been enabled 👍


Support for EIP-712 message signing

It seems to be not possible to sign EIP-712-based messages right now, because the message is prepended with \x19Ethereum Signed Message:\n here: https://github.com/LedgerHQ/app-ethereum/blob/8d0544bf68906f2a47a9013409792bf986272028/src_features/signMessage/cmd_signMessage.c#L57
This is already implemented by MetaMask, and it would be nice to be able to sign EIP-712 messages with Ledger devices as well.

We're currently testing it, an app update should be available soon®
(cf: https://github.com/LedgerHQ/app-ethereum/tree/eip712_v0)

What is current status on Ledger's implementation of EIP712 to support transaction signing?
MetaMask, Gnosis Safe multisig, and many others support it, and without it, the security case for using a Ledger in concert with these other wallets goes down significantly.

What is current status on Ledger's implementation of EIP712 to support transaction signing?
MetaMask, Gnosis Safe multisig, and many others support it, and without it, the security case for using a Ledger in concert with these other wallets goes down significantly.

This is supported already: https://github.com/LedgerHQ/app-ethereum/issues/105

This is supported already: https://github.com/LedgerHQ/app-ethereum/issues/105

@TamtamHero : It appears EIP-712 compatibility is also not working with the Gnosis Safe Multisig, per discussion on Gnosis #safe Discord ( [https://discord.com/channels/477106835862716416/477391201708802058/801466336873283594] ).
Maybe you and @tobias_s from Gnosis could chat to see if the Gnosis dev team is aware that Ledger think EIP-712 is correctly implemented.

@TamtamHero : It appears EIP-712 compatibility is also not working with the Gnosis Safe Multisig, per discussion on Gnosis #safe Discord ( [https://discord.com/channels/477106835862716416/477391201708802058/801466336873283594] ).
Maybe you and @tobias_s from Gnosis could chat to see if the Gnosis dev team is aware that Ledger think EIP-712 is correctly implemented.

This is supported already: #105

@TamtamHero You linked this exact same isse (#105) Did you mean to link another issue in your comment? :)
That would be great news if Ledger supports EIP712! With which Firmware update did that go live?

This is supported already: #105

@TamtamHero You linked this exact same isse (#105) Did you mean to link another issue in your comment? :)
That would be great news if Ledger supports EIP712! With which Firmware update did that go live?

indeed, my bad!
https://github.com/LedgerHQ/app-ethereum/blob/master/doc/ethapp.asc#sign-eth-eip-712
Available since https://github.com/LedgerHQ/app-ethereum/commit/91e4b4577a839d3b66c1bb9345584916c71be818
So, since Eth v1.6.0

indeed, my bad!
https://github.com/LedgerHQ/app-ethereum/blob/master/doc/ethapp.asc#sign-eth-eip-712
Available since https://github.com/LedgerHQ/app-ethereum/commit/91e4b4577a839d3b66c1bb9345584916c71be818
So, since Eth v1.6.0

Oh nice! Would a user actually be able to review the different EIP712 fields on their Ledger display?
I still just see the hash to sign, and not the human readable message fields. Now I'm wondering if I do anything wrong.

Oh nice! Would a user actually be able to review the different EIP712 fields on their Ledger display?
I still just see the hash to sign, and not the human readable message fields. Now I'm wondering if I do anything wrong.

Is this implemented in Ledger.js, or do we have to manually send the data to the device for now? Either way, sweet that this has been implemented.

Is this implemented in Ledger.js, or do we have to manually send the data to the device for now? Either way, sweet that this has been implemented.

For implementation version 0, the domain hash and message hash are provided to the device, which displays them and returns the signature

The call is available from ledger.js: https://github.com/LedgerHQ/ledgerjs/tree/master/packages/hw-app-eth#signeip712hashedmessage

For implementation version 0, the domain hash and message hash are provided to the device, which displays them and returns the signature

The call is available from ledger.js: https://github.com/LedgerHQ/ledgerjs/tree/master/packages/hw-app-eth#signeip712hashedmessage

With the data not displayed on the device, the user who wants to carefully validate their signature on, say, a Gnosis Safe Multisig transaction approval/signing, cannot actually validate that they are signing the correct transaction.
So my encouragement for you is to definitely fix it so that the user can use the Ledger display device to usefully, and securely, approve an EIP-712 transaction.

With the data not displayed on the device, the user who wants to carefully validate their signature on, say, a Gnosis Safe Multisig transaction approval/signing, cannot actually validate that they are signing the correct transaction.
So my encouragement for you is to definitely fix it so that the user can use the Ledger display device to usefully, and securely, approve an EIP-712 transaction.

Bump.
This is a serious concern for e.g. Gnosis Safe users (reminder: if you want to claim your wallet protects a large amount of ETH and Ethereum based value then you must support Gnosis Safe) who are currently unable to verify the tx idahoan on screen - not even with hex code. All you currently see us a hash. So right now you need a laptop to verify the hash and that laptop is the device you didn't trust in the first place and therefore got a hardware wallet.

Ok the issue seems resolved, see above. I suggest to close this issue.

Now that Uniswap v3 uses EIP-712 for signing transactions like LP migration, can you update users on the status of this issue? Otherwise anyone using Metamask together with Ledger is stuck on Uniswap v2 for the time-being.

@Xeonus EIP-712 is already supported by the Ledger. Metamask has not updated its hw-app-eth dependency though.
You can track the actual issue on their repo.
Thanks! :D

Update to 2.0 firmware and works like a charm https://github.com/MetaMask/metamask-extension/issues/10240#issuecomment-833936849

Still waiting for the support to show all data on the device. That's the whole point of the display not to sign random things.

Still waiting for the support to show all data on the device. That's the whole point of the display not to sign random things.

This is on our radar. Unfortunately we have higher priority issues :)
In the meantime, feel free to check out the already existing EIP712 interal plugin and contribute! :)

Bump. This is a serious concern to us. Is there an ETA on resolving this issue?

Unfortunately no, still WIP on our side, we can't give any ETA yet, just hoping for somewhere in Q1 2022 at the moment.

Any updates on this issue?


Send X-Gemfile-Source when bundling with --full-index

This fixes #4090
I did a little refactoring that made sense to me along the way, but if I went too far or might be breaking something I'm not aware of, please let me know.
Existing issue: This doesn't fix bundling with full index when using Rubygems < 2.0, as that code path seemed a bit trickier to fix. I added a TODO comment at the relevant method. I thought of a couple possibilities:

Subclass Gem::SpecFetcher like Bundler::GemRemoteFetcher, it seems like it might be as simple as calling the super constructor and then replace @fetcher with a Bundler::GemRemoteFetcher with the headers added ahead of time (see https://github.com/rubygems/rubygems/blob/v1.8.30/lib/rubygems/spec_fetcher.rb#L66). This may involve different solutions the further back in Rubygems you go.
Use the newer implementation of fetch_all_remote_specs for older Rubygems as well (I don't know if that would work though, but it might be worth a try).

I haven't yet added additional specs for this, but I wanted to get this out there first to get some feedback if possible.

Can we add a spec for setting the header?

@homu r+

:pushpin: Commit a88f0b9 has been approved by segiddins

:hourglass: Testing commit a88f0b9 with merge 482eb6e...

:broken_heart: Test failed - status

@homu retry

:hourglass: Testing commit a88f0b9 with merge ae2ba08...

:sunny: Test successful - status


Indentation incorrect

In the Node affinity sample, nodeSelectorTerms: must be indented inside requiredDuringSchedulingIgnoredDuringExecution: but currently it's not.

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

ID: dae17603-813b-f1ef-e161-c229d49a2541
Version Independent ID: 5c1dcea0-0cda-0233-2356-be63be776809
Content: Operator best practices - Advanced scheduler features in Azure Kubernetes Services (AKS)
Content Source: articles/aks/operator-best-practices-advanced-scheduler.md
Service: container-service
GitHub Login: @iainfoulds
Microsoft Alias: iainfou

@letmaik Thanks for the your feedback. We are investigating and will update you shortly.

@letmaik I have submitted a PR, the document will be updated soon.


Basic test case: copr build only

This test case is triggered automatically by our validation script.
- job: copr_build
  trigger: pull_request
  metadata:
    targets:
    - fedora-all

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

Is it a copr problem?
/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

/packit build

Clossing, it's getting a bit messy. I will re-create it.

Clossing, it's getting a bit messy. I will re-create it.

Here is a newly created one: #193

Here is a newly created one: #193


Add query profiling visualization

An query explain trace gives great insight into the Vespa cluster.

Time spent in the container
How many nodes are in the group
The query tree with estimates, the optimized tree
Timing for ranking phases
Timing for rank features used in the phases

It would be fantastic to have a graphic illustration of the above, which gives an illustration of the cluster topology, this could help
understand how to scale (groups versus flat). It would illustrate how the query is executed, and one can drill into the components involved, for example display the query tree, get cost of ranking features and more.

The key here is to make it easier for users to understand:

How should they scale the cluster using groups or nodes for optimal query performance/throughput. We can estimate that from comparing query setup time versus matching.

Make information actionable - for example, noticing result payload size, suggesting compression, or suggesting fast-search, with links and all.


Refactor build

This PR updates the build to use WP PHPUnit instead of the traditional install-wp-tests.sh script. All PHP dependencies are now fully managed by Composer, and different versions are installed as necessary by Composer as well as part of the build.
This also makes it much easier to get up and running with locally.

Coverage remained the same at 100.0% when pulling a1da3bf5097cd6dd442638ed6af9e27b3ed70751 on refactor-build into 402243de63b225d4dafa666d16d9db28fb24799f on master.


Support Redis for Balance Tracking

See this thread for more details on which balances to track: https://forum.interledger.org/t/what-should-positive-negative-balances-represent/501/5

This is fixed via #154


Crop area is not displayed in a sheet view

Hi!
When I use SwiftyCropView inside a sheet view like in the picture below, the crop area is almost always not displayed (but has been shown a few times).

But it works fine if I use it in a sheet view hierarchy like this.

Hi, can you specify the issue a little bit more?

Device you are using
iOS-Version
Swift-Version
Xcode-Version

Does the issue also persist when you use the demo of SwiftyCrop? In the demo it is presented as fullScreenCover just like in your example.

iPhone 14 Pro
17.4.1 (real device) / 17.2 (simulator)
Swift 5
Xcode 15.3 (15E204a)

To reproduce the issue:

Create view just like in the demo
Display created view using .sheet() modifier

When I use it like in the demo it's OK.

It seems that SwiftUI is having problems displaying the mask of the ZStack when using the .sheet modifier. To solve this you can wrap the SwiftyCropView inside a NavigationView or NavigationStack when presented. This will show the cropping mask.
I suggest something like this:
.sheet(isPresented: $showImageCropper) {
            NavigationView {
                if let selectedImage = selectedImage {
                    SwiftyCropView(
                        imageToCrop: selectedImage,
                        maskShape: selectedShape,
                        configuration: SwiftyCropConfiguration(
                            maxMagnificationScale: maxMagnificationScale,
                            maskRadius: maskRadius,
                            cropImageCircular: cropImageCircular,
                            rotateImage: rotateImage,
                            zoomSensitivity: zoomSensitivity
                        )
                    ) { croppedImage in
                        // Do something with the returned, cropped image
                        self.selectedImage = croppedImage
                    }
                    .interactiveDismissDisabled()
                }
            }
        }

I solved it the next way:
.fullScreenCover(isPresented: $showPhotoCropper, onDismiss: {      self.photoCropperWillAppear = false           }) {                VStack{                     if let photoToCrop = self.photoToCrop, self.photoCropperWillAppear {                        SwiftyCropView(                             imageToCrop: photoToCrop,                             maskShape: .square,                             configuration: SwiftyCropConfiguration(maxMagnificationScale: 2, maskRadius: self.vehicleImageCropHeight, rotateImage: false)                         ) { croppedPhoto in                             self.croppedPhoto = croppedPhoto                         }                     }                 }                .uiKitViewWillAppear { self.photoCropperWillAppear = true }      }
Here .uiKitViewWillAppear works the same as UIViewController.viewWillAppear(). Perhaps this will help you solve the problem if you init mask when viewWillAppear is called. I'm not sure, I haven't looked at the code :)

FYI: the bug is still present with the NavigationStack you must use a NavigationView

@g3rd I will add this as an info in the README

@benedom thank you!


DFP Interstitial position

I've finally succeeded in displaying an interstitial from DFP.
However, it display at the top left position even if I set the position to 5 in the options:
AdMob.prepareInterstitial({ adId : adId, autoShow : false, position : 5},function() {
		onSuccess();
	},function() {
		console.log("error");
	});

Is it a bug or a mistake from my side?

By the way, I have this problem only on Android (tablets, portrait). On iOS, the interstitial is displayed full screen so no problem with positioning. On Android, I get black space on the bottom and right sides of the image...
Bug ?

To summarise the problem:

I have a DFP interstitial configured for tablets in portrait mode. The interstitial image is 768x1024.
The AdMob plugin suceeds in reading this ad both on iPads and Android tablets.

However, on Android tablets, it does not get resized as it should be and gets aligned on the top left corner of the screen instead of at least being centered (and resized to fit the exact width of the screen).

Setting the position to centered in the options of the prepareInterstitial call has no effect...

@floatinghotpot any idea on this issue?

Anyone ?

Hello, @floatinghotpot
I'm facing the same problem with this plugin on mobile: the DFP ad unit is displayed in interstitial but not in a middle.
On iPhone 5 it looks OK. On larger screens the ad displayed in top left corner (about half of the screen width)/
Any solution?
Thank you

Sorry for a late response.
Usually, an interstitial Ad is displayed in a full screen native view. This plugin calls Google API to prepare/show the native view, but have no API to handle the content in the native view. So, your question is out of our capability.
The DFP content is designed by yourself, is there any design trick to make it right? Please turn to the Google DFP forum for help:
https://productforums.google.com/forum/#!forum/dfp


TS Server fatal error:  Maximum call stack size exceeded

I have this error with React Native Project Version :
"react": "18.2.0",
"react-native": "0.72.3",

Thanks for creating this issue! We figured it's missing some basic information or in some other way doesn't follow our issue reporting guidelines. Please take the time to review these and update the issue.
Happy Coding!

Please fill in the issue template with your VS Code version
Also does this reproduce in the latest VS Code insiders build with all extensions disabled?

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


feat(#119): add grid prefix support

When finished, this should close https://github.com/thysultan/stylis/issues/119 once and for all.
Note: It is still WIP Although the feature is implemented, it hasn't been optimized AT ALL, so suggestions, optimizations, discussions are welcome!

TODO:

[x] display: grid / inline-grid
[ ] align-self / justify-self: strech / end / center
[ ] grid-template-columns
[ ] grid-template-rows
[ ] grid-template-columns
[ ] grid-row-start: numerical
[ ] grid-row-end: numerical
[ ] grid-row-start: non-numerical
[ ] grid-row-end: non-numerical
[ ] grid-column: expand shorthand syntax
[ ] grid-row: expand shorthand syntax

@thysultan @Andarist
The PR is ready for review. And here is a few things:

Prefixing grid-row-start and grid-row-end requires the knowledge of both declarations, so it is impossible for stylis stateless per declaration processor to prefix them.
I just write the code to make it pass the test cases. It is highly un-optimized, introducing tons of performance overhead and unnecessary byte to the final dist build. Feel free to add your ideas and suggestions!

Pull Request Test Coverage Report for Build 3cce9a5fd82622b7e3d8dbcd8ac2f52c2d7db454-PR-285

9 of 9 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.1%) to 98.787%

Totals

Change from base Build fbda3464f415f5742bb7ab41dfdd8102113565e6:
-0.1%

Covered Lines:
268

Relevant Lines:
270

💛  - Coveralls

Prefixing grid-row-start and grid-row-end requires the knowledge of both declarations

Elaborate?

so it is impossible for stylis stateless per declaration processor to prefix them

The prefixer middleware, which has access to the complete state of the css token graph does not have this limitation, the prefix function in Prefixer.js is called by this middleware: https://github.com/thysultan/stylis/blob/9e61e05a04060ad397c951877dee311297825568/src/Middleware.js#L42

Elaborate?

If grid-row-start and grid-row-end should be prefixed, here is how:

If only grid-row-start exists:

Prefix with -ms-grid-row. So grid-row-start:3; becomes -ms-grid-row:3;-ms-grid-row:3.

If only grid-row-end exists:

Prefix with -ms-grid-row-span. So grid-row-end:3; becomes -ms-grid-row-span:3;grid-row-end:3;, and grid-row-end:span 3; becomes -ms-grid-row-span:3;grid-row-end:span 3;

If both of them exists:

Prefix grid-row-start with -ms-grid-row
Add -ms-grid-row-span with a value of grid-row-end - grid-row-start
So grid-row-start:3;grid-row-end:5; becomes -ms-grid-row: 3;grid-row-start:3;-ms-grid-row-span:2;grid-row-end:5;

The same rule applies to column.
I mainly port the features from @robinweser's inline-style-prefixer (He recently switch Fela's prefixer from his own inline-style-prefixer to stylis. Porting the feature helps to keep consistent behavior).

One concern that I have is that it might potentially increase the output quite a bit for existing users. I wonder if this could be split into 2 plugins somehow? Or should I potentially get ready for copying over the older version of the prefixed into Emotion's codebase? 🤔

Chiming in since I was mentioned in this thread:
Maybe it'd be worth exploring a way to build your own prefixer from browser data or something?
Over at inline-style-prefixer, we export a generateData and createPrefixer function which one can use to create your very own one given a list of browser versions. See https://inline-style-prefixer.js.org/docs/guides/CustomPrefixer.html

One concern that I have is that it might potentially increase the output quite a bit for existing users. I wonder if this could be split into 2 plugins somehow? Or should I potentially get ready for copying over the older version of the prefixed into Emotion's codebase? 🤔

That's why I said my initial changes are highly unoptimized. And I believe it is possible to reduce the impact down to below 2 KiB or even below 1 KiB, which should be acceptable.

And currently, the after-gzipped size is only increased by about 200 bytes. That doesn't sound so bad, right?

I'm not that concerned about the increase of the Stylis' size - but rather about the increased size of the prefixed output. My concern is about the generated CSS.

I'm not that concerned about the increase of the Stylis' size - but rather about the increased size of the prefixed output. My concern is about the generated CSS.

Well, after the change, only those grid-related declarations will contribute to the increase of the final CSS output. So it really depends on how much grid do the developers use in their project currently: if they use none, then the prefixed output will not be affected at all.
So I've done some naive tests here:

Go to some websites
Grab a dump of their entire CSS
Put the CSS into PostCSS's autoprefixer, with the browserlist set to since 2022, IE 10 to make sure only IE flexbox and IE grid prefixes get applied.
Compare the size change.

I've checked dev.to (their source code can be found here), a website whose layout is heavily based on the CSS grid. And their CSS size before and after autoprefixer with since 2022, IE 10 are 444KiB vs 449KiB.

@robinweser Kind of wish browserlist in bundlers was like eslint in so much as it would support inline comments to pieces of atomic pieces of code i.e
// ie11
if (a) b(c)

Denoting that the code only exists to make something work on ie11, then this data would make it to the bundler and strip it away from supported browser targets that are not ie11.

The prefixer middleware, which has access to the complete state of the css token graph does not have this limitation, the prefix function in Prefixer.js is called by this middleware:

@thysultan Done in #287

@thysultan Thanks for your review! I will remove whitespace (and possibly other style-related) diff first.

@SukkaW Thanks for the work you've done on this.


processKotlinxSerialization is not generating swagger schema properly for Lists and Individual CustomObject present in same class

Hi,
I found a bug in schema-kenerator version 1.0.1(using with ktor-swagger-ui version 3.2.0) related to OpenAPI and schema generation using Kotlin serialization. The issue occurs when you have both a list of custom objects and individual custom objects as fields in the same data class.
Example Setup
Ktor Swagger UI Configuration
install(SwaggerUI) {
    schemas {
        // Customized schema generation pipeline
        generator = { type ->
            type
                .processKotlinxSerialization()
                .generateSwaggerSchema()
                .withAutoTitle(TitleType.SIMPLE) // Use the simple class names for titles.
                .compileReferencing(RefType.SIMPLE) // Use the simple class names for references.
        }
    }
}

Data Model
package com.example
import kotlinx.serialization.Serializable

@Serializable
data class TestRequest(
    val items: List<Item>? = null,
    val selectedItem: Item? = null,
) {
    @Serializable
    data class Item(
        val id: Int? = null,
        val name: String? = null
    )
}

Issue
The generated schema is incorrect when you have a List as one of the fields and also CustomObject without a list as one of the fields. For example, the generated schema for the above example would be:
"TestRequest": {
                "title": "TestRequest",
                "type": "object",
                "properties": {
                    "items": {
                        "title": "ArrayList<Item>",
                        "type": "array",
                        "items": {
                            "$ref": "#/components/schemas/Item"
                        }
                    },
                    "selectedItem": {
                        "$ref": "#/components/schemas/Item#8127298379063018757"
                    }
                }
            }

Notice the random suffix #8127298379063018757.
If the order of the List<Item> is changed, for example:
package com.example
import kotlinx.serialization.Serializable

@Serializable
data class TestRequest(
    val selectedItem: Item? = null,
    val items: List<Item>? = null,
) {
    @Serializable
    data class Item(
        val id: Int? = null,
        val name: String? = null
    )
}

The generated schema becomes:
"TestRequest": {
                "title": "TestRequest",
                "type": "object",
                "properties": {
                    "selectedItem": {
                        "$ref": "#/components/schemas/Item"
                    },
                    "items": {
                        "$ref": "kotlin.collections.ArrayList<com.example.TestRequest.Item#6357439241701235850>"
                    }
                }
            }

In this case, the reference kotlin.collections.ArrayList<com.example.TestRequest.Item#6357439241701235850> doesn't exist at all.
Summary
The issue seems to be related to the order of fields in the data class when generating the schema. The schema generation process should handle lists and individual custom objects consistently, regardless of their order in the data class.
Thanks so much.

Hi,
the underlying issue is that i (as far as i know) kotlinx does not keep/provide information about generic type parameters.
For example:
@Serializable
class Item<T>(val value: T)

class Request(
   val a: Item<String>,
   val b: Item<Int>
)

Here i would need to generate different schemas (and ids) for the type Item and one for Item, but since (afaik) cannot know if it even has a generic type parameter (i "only" have the name of the type), i assign a unique id to classes when i encounter them multiple times.
Maybe one solution would be to have a flag to tell the generator that no generic types are involved and it can safely assign the same ids / create the same schemas for types with the same name.

i`ll close this issue. Unfortunately, as far is i know, there is not much i can do in terms of automatically handling these scenarios in a reliable way.
I did add a change in 1.1.0

added config option knownNotParameterized for type processing with kotlinx-serialization to manually prevent single type appearing multiple times in some setups

that allows marking classes as "definitely not having any generic types" which then allows the generator to handle these a bit differently.


⚠ SceneTime has degraded performance

In e3ed355, SceneTime ($ST) experienced degraded performance:

HTTP code: 200
Response time: 4063 ms

Resolved: SceneTime performance has improved in 0997e3c.


Run containers in order

Info
There is no any specific handlers in Tilt to manage some jobs running order, while the tools like Garden have them. For example wait until DB migration successfully ends and only after it run new deployment. With Tilt you just push the manifests to k8s and let k8s do his job.
Partially, this can be sorted out with Helm hooks feature, but it is extra dependency, right?
A few days ago I was surprised, that there is no the information about this hack, which is absolutely natural for k8s and devaluate this feature in the other tools.
For me this feature was the point some time ago, so this hack may be useful for others. Feel free to add it to the FAQ.
Thank you for the great tool :)

Hi @kvokka, thanks for the example! I'm going to close this as a duplicate of https://github.com/windmilleng/tilt/issues/1846.


Decrypt a file in browser

I am enable to encrypt file a in mobile app but I want to decrypt the same file in web browser. Is it possible by any chance?

Web Browsers are not yet supported.


DeckGL Component mounted over other component

Hi! I'm struggling with this problem. I have DeckGL component with StaticMap and I want to place it below of my form.
This is the form:

This is what happens

The parent code:
render() {
    return (

        <Card>
          <CardHeader>
            Nuevo Proyecto
          </CardHeader>
          <CardBody>
            <InitalForm />
            <Map />
          </CardBody>
          <CardFooter>
            <Button size="sm" color="primary" onClick={this.handleSave}>
               Guardar
            </Button>
          </CardFooter>
        </Card>

    );
  }

The childen code (Map Component):
import React, { Component } from "react";
import DeckGL from<EMAIL_ADDRESS>import StaticMap from "react-map-gl";
import { renderLayers } from "./Layers";
import {
  Button,
  Modal,
  ModalBody,
  ModalFooter,
  ModalHeader,
  Container
} from "reactstrap";

import poquiData from "../../../../poqui";

// Set your mapbox access token here
const MAPBOX_ACCESS_TOKEN = "TOKEN";

const INITIAL_VIEW_STATE = {
  longitude: -71.053166513,
  latitude: -34.181195119,
  zoom: 11,
  pitch: 0,
  bearing: 0
};

class Map extends Component {
  state = {
    data: poquiData,
    style: "mapbox://styles/mapbox/light-v9"
  };

  getTooltip = ({ object }) => {
    return (
      object &&
      `Nombre: ${object.properties.gid}
      HA: ${object.properties.ha}`
    );
  };

  render() {
    return (

        <DeckGL
          layers={renderLayers({
            data: this.state.data
          })}
          initialViewState={INITIAL_VIEW_STATE}
          controller
          getTooltip={this.getTooltip}
        >
          <StaticMap mapboxApiAccessToken={MAPBOX_ACCESS_TOKEN} />
        </DeckGL>

    );
  }
}

export default Map;

Can anyone help me please, I don't know how to keep going :(

Add style={{position: 'relative'}} to the
 that contains DeckGL.

Add style={{position: 'relative', width: '100%', height: <map_height>}} to the
 that contains DeckGL.

Thank you very much!!! That worked!

@Pessimistress this also worked for me thankyou!