Kotlin: compilation error after any change

Demo project: https://github.com/romansl/KotlinWeather
Environment:
Toothpick: 1.0.8
Kotlin: 1.1.4-3
Andoird Studio: 2.3.3
Android gradle pugin: 2.3.3
Gradle: 3.3
Instant run: enabled

How to reproduce:

Open Weather.kt
Add variable val ggg: Int = 1
Got compilation error: error: cannot find symbol

D:\Projects\KotlinWeather\app\build\generated\source\kapt\debug\weather\ekamp\com\weatherappkotlin\FactoryRegistry.java:32: error: cannot find symbol
      return (Factory<T>) new weather.ekamp.com.weatherappkotlin.presenter.LandingPresenter$$Factory();
                                                                          ^
  symbol:   class LandingPresenter$$Factory
  location: package weather.ekamp.com.weatherappkotlin.presenter

You have to disable incremental compilation in kapt. Kapt incremental
annotation processing will break with annotation processors that generate a
single file out of multiple source files (like TP, dagger, henson, and some
auto value extensions, and probably many others).
https://stackoverflow.com/questions/36740100/disable-incremental-build-for-kapt
2017-09-18 3:08 GMT-07:00 Roman Leukin<EMAIL_ADDRESS>
Demo project: https://github.com/romansl/KotlinWeather
Environment:
Toothpick: 1.0.8
Kotlin: 1.1.4-3
Andoird Studio: 2.3.3
Android gradle pugin: 2.3.3
Gradle: 3.3
Instant run: enabled
How to reproduce:

Open Weather.kt
Add variable val ggg: Int = 1
Got compilation error: error: cannot find symbol

D:\Projects\KotlinWeather\app\build\generated\source\kapt\debug\weather\ekamp\com\weatherappkotlin\FactoryRegistry.java:32: error: cannot find symbol
return (Factory) new weather.ekamp.com.weatherappkotlin.presenter.LandingPresenter$$Factory();
^
symbol:   class LandingPresenter$$Factory
location: package weather.ekamp.com.weatherappkotlin.presenter
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/stephanenicolas/toothpick/issues/245, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABv33QWXMlCGtALAf5oSCZgVtzidBjG-ks5sjkEzgaJpZM4Parxm
.

Also, another workaround is not to use TP registries but to use reflection. For most apps, you won't see the difference.

It does not help:
kotlin.incremental=false

https://github.com/romansl/KotlinWeather/commit/89b7c7a08bc25d79aca72315447b0b8d4ff119dc

I would like to keep the incremental compilation, but removing our registry configuration will yield a warning saying warning: No option -Atoothpick_registry_package_name to the compiler. No registries will be generated. and we're treating warnings as errors (-Pwerrror).
Can you provide some mechanism that will allow us to specifically run without registries and not get this warning?

If I disable TP registries, then I got runtime error.


use new ChainRulesCore correctly

Oh god, I need to change all of these?
https://github.com/SciML/DiffEqSensitivity.jl/blob/master/src/concrete_solve.jl#L188
Right now I have both:
https://github.com/SciML/DiffEqBase.jl/blob/master/src/solve.jl#L290-L308
but I'm scared to remove the Zygote.@adjoint because it works. Can I get some help making sure that's all good?

Oh god, I need to change all of these?
https://github.com/SciML/DiffEqSensitivity.jl/blob/master/src/concrete_solve.jl#L188

Yeah, those a kinda wrong for ChainRules since they use nothing when they should use NoTangent and Tuple when they should use Tangent{Tuple}.

but I'm scared to remove the Zygote.@adjoint because it works

Yes, right now having the @adjoint will be blocking the the rrule from ever being hit, which is probably why those errors never were detected.
(though Zygote might gracefully accept rrules that violate the convention, Diffractor and Nabla are less likely to)

Can I get some help making sure that's all good?

Yes sure, but after JuliaCon stuff is all submitted.


Hardcoded white background when SVG mode is used

Environment data

VS Code version: 1.60.1
Jupyter Extension version (available under the Extensions sidebar): v2021.8.2041215044
Python Extension version (available under the Extensions sidebar): v2021.9.1230869389
OS (Windows | Mac | Linux distro) and version: macOS 11.5.2
Python and/or Anaconda version: 3.9.5
Type of virtual environment used (N/A | venv | virtualenv | conda | ...): N/A
Jupyter server running: Local | Remote | Local

Expected behaviour
Background of SVG plots to be either transparent or to follow editor background
Actual behaviour
Background of SVG plots is white regardless of color theme in use.
Steps to reproduce:

Set VS Code to use any color theme with a non-white background.

Create test.ipynb file.

Execute the following code:

%config InlineBackend.figure_format = 'svg'
import pandas as pd
pd.DataFrame({'y': [1, 2, 3]}).plot()

Screenshot:

Logs
Not applicable.

Thanks for the bug. This is likely a duplicate of https://github.com/microsoft/vscode-jupyter/issues/7470. We plan to set it to only be white immediately behind the figure, not the entire plot.

Thanks for the feedback! We've been asked about this a lot.  Being able to modify the background of matplotlib to make sure that everything in the plot itself is visible is a tough problem to solve. We don't have plans on attempting it.
The fact that we're whiting out 100% width is a dupe of #7470.


Add Windows Support

https://news.ycombinator.com/threads?id=kermatt#36729903

I don't have a Windows machine so wasn't testing against it.

I do, and happy to test.

Attempting a Windows cross-compilation on Debian 12. Is it possible to build the extension without building the duckdb executable which available pre-built from DuckDB ?

Thank you! I should be able to get pretty far with the Github actions Windows runner but would definitely appreciate someone testing it in real life on Windows.
The build process is a slight modification to the default DuckDB extension template which uses CMake.

So far, cross-compiling locally on Debian 12 with CMake mingw32 and a toolchain file:
set(CMAKE_SYSTEM_NAME Windows)

set(CMAKE_C_COMPILER /usr/bin/i686-w64-mingw32-gcc)
set(CMAKE_CXX_COMPILER /usr/bin/i686-w64-mingw32-g++)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

and
# Select POSIX from:
sudo update-alternatives --config i686-w64-mingw32-gcc
sudo update-alternatives --config i686-w64-mingw32-g++

Gets me halfway:
[ 55%] Building CXX object extension/odbc_scanner/CMakeFiles/odbc_scanner_extension.dir/src/odbc_scan.cpp.obj
In file included from /odbc-scanner-duckdb-extension/src/odbc_scan.cpp:1:
/odbc-scanner-duckdb-extension/src/include/odbc_scan.hpp: In static member function ‘static duckdb::unique_ptr<duckdb::GlobalTableFunctionState, std::default_delete<duckdb::GlobalTableFunctionState>, true> duckdb::OdbcScanFunction::OdbcScanInitGlobalState(duckdb::ClientContext&, duckdb::TableFunctionInitInput&)’:
/odbc-scanner-duckdb-extension/src/include/odbc_scan.hpp:339:12: error: could not convert ‘global_state’ from ‘unique_ptr<duckdb::OdbcScanGlobalState,default_delete<duckdb::OdbcScanGlobalState>,[...]>’ to ‘unique_ptr<duckdb::GlobalTableFunctionState,default_delete<duckdb::GlobalTableFunctionState>,[...]>’
  339 |     return global_state;
      |            ^~~~~~~~~~~~
      |            |
      |            unique_ptr<duckdb::OdbcScanGlobalState,default_delete<duckdb::OdbcScanGlobalState>,[...]>
gmake[3]: *** [extension/odbc_scanner/CMakeFiles/odbc_scanner_extension.dir/build.make:77: extension/odbc_scanner/CMakeFiles/odbc_scanner_extension.dir/src/odbc_scan.cpp.obj] Error 1

diff --git a/src/include/odbc_scan.hpp b/src/include/odbc_scan.hpp
index a177d9b..2c4557d 100644
--- a/src/include/odbc_scan.hpp
+++ b/src/include/odbc_scan.hpp
@@ -335,7 +335,7 @@ public:
   static unique_ptr<GlobalTableFunctionState>
   OdbcScanInitGlobalState(ClientContext &context,
                           TableFunctionInitInput &input) {
-    auto global_state = make_uniq<OdbcScanGlobalState>();
+    auto global_state = make_uniq<GlobalTableFunctionState>();
     return global_state;
   }

gets me to  [ 75%] Linking CXX shared library libduckdb.dll with multiple undefined references to look into next.

Do the instructions for the nix shell work? https://github.com/rupurt/odbc-scanner-duckdb-extension#development

So far, using Nix to create local environment with dependencies on Debian 12, and cross-compiling with mingw32:
# Select POSIX from:
sudo update-alternatives --config i686-w64-mingw32-gcc
sudo update-alternatives --config i686-w64-mingw32-g++

A CMake toolchain file:
set(CMAKE_SYSTEM_NAME Windows)

set(CMAKE_C_COMPILER /usr/bin/i686-w64-mingw32-gcc)
set(CMAKE_CXX_COMPILER /usr/bin/i686-w64-mingw32-g++)

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)

set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

Gets me halfway:
[ 55%] Building CXX object extension/odbc_scanner/CMakeFiles/odbc_scanner_extension.dir/src/odbc_scan.cpp.obj
In file included from /odbc-scanner-duckdb-extension/src/odbc_scan.cpp:1:
/odbc-scanner-duckdb-extension/src/include/odbc_scan.hpp: In static member function ‘static duckdb::unique_ptr<duckdb::GlobalTableFunctionState, std::default_delete<duckdb::GlobalTableFunctionState>, true> duckdb::OdbcScanFunction::OdbcScanInitGlobalState(duckdb::ClientContext&, duckdb::TableFunctionInitInput&)’:
/odbc-scanner-duckdb-extension/src/include/odbc_scan.hpp:339:12: error: could not convert ‘global_state’ from ‘unique_ptr<duckdb::OdbcScanGlobalState,default_delete<duckdb::OdbcScanGlobalState>,[...]>’ to ‘unique_ptr<duckdb::GlobalTableFunctionState,default_delete<duckdb::GlobalTableFunctionState>,[...]>’
  339 |     return global_state;
      |            ^~~~~~~~~~~~
      |            |
      |            unique_ptr<duckdb::OdbcScanGlobalState,default_delete<duckdb::OdbcScanGlobalState>,[...]>
gmake[3]: *** [extension/odbc_scanner/CMakeFiles/odbc_scanner_extension.dir/build.make:77: extension/odbc_scanner/CMakeFiles/odbc_scanner_extension.dir/src/odbc_scan.cpp.obj] Error 1

I tried debugging this by compiling with gcc & g++ instead of clang. I ran into the same error on return of global_state and fixed it. Changes are on main if you want to give it another go.

Do the instructions for the nix shell work? https://github.com/rupurt/odbc-scanner-duckdb-extension#development

They do (as far as I can tell, Nix is new for me), and with the changes in 9ad0f91 it builds, failing at link time which is not a surprise as linking probably needs to occur against Windows ODBC lib not unixODBC. Not sure yet how to tackle that as I'm cross-compiling on Debian.

Sweet. Great to hear. I'll try to take a stab myself this week.

Has there been any progress on this issue? This would be most welcome as it would allow access to many other databases (MS SQL Server for one).

Sorry, I haven't had time to work on this extension in a while.
As I learned more about ODBC and the DuckDB API I've decided to totally re-architect this extension. I'm building a performance oriented ODBC client in zig. It will then link to that library for this extension to the majority of the heavy lifting. I need performance oriented bulk ODBC -> Arrow format for other projects and bindings to DataFrame libraries like Polars.

No apology necessary. I am just interested in this and noticed there was nothing since last July. I am definitely supportive of what you just described and I am happy to test it when it is ready to do. My main database is in SQL Server but I am trying to build a smaller, performance driven platform for data analytics and DuckDB is proving to be well suited for this. I will keep an eye on this for your future updates.

I've got the Zig ODBC library to a decent spot where I'm making regular progress https://github.com/rupurt/zodbc. I have the build working on Linux x86_64 & Mac aarch64 + x86_64 through rosetta. It should be trivial to compile for Windows as it ships out of the box with ODBC headers and Zig cross compilation is fantastic.
I think it'll take me ~1 more month to get a robust initial version. Adherence to the ODBC concurrency model for maximum performance is why I decided to write it in the first place. That work is in ConnectionPool and I feel like I've got a decent worker abstraction where each worker executes in a separate kernel thread. Totally open to any improvements or suggestions.
To get it integrated with DuckDB my plan is to ship a python zodbc package on pip with support for the pyarrow.RecordBatchReader interface. DuckDB has great support Arrow so that should get a bunch of y'all unblocked. The next phase of the plan is to restart this extension from scratch and build the extension with Zig so that we have a tight integration between the DuckDB catalog and ODBC. I haven't been able to find any guides or examples on how to do that so if y'all have any links you can drop me for building DuckDB extensions with Zig that would be a huge help :pray:

I've got Zig building DuckDB extensions working https://github.com/rupurt/duckdb-extension-template-zig. Starting work on the Zig ODBC DuckDB extension this weekend. Stay tuned!

Hello.
This is probably not the most common usage, but I would like to use old Microsoft Access (.mdb files under Windows 7 64 bit) as ODBC data sources and do my queries joining those tables against some other datasources using DuckDB.
Do you think MS-Access connection will be solved by this extension too?
Thanks a lot for working on this!
@abubelinha


Missing --tw-shadow-color Variable

how it currently is
When I add the shadow-border-b class, the box-shadow property is applied without the --tw-shadow-color variable.

how it should be
However, when I use the shadow-border class, the relevant css variables are applied alongside the box-shadow property.

@brandonmcconnell
@shreyas-jadhav


Make .destroy() work with attribute inference

Discussed in this thread.
With this patch, the @safety etc. of object.destroy depends on the destructor of the struct.
Also adds postblitRecurse to enable explicit copying with attribute inference, to be used in emplace.
Attribute inference for destruction/postblit of fixed-length arrays with struct elements seems to be broken even for implicit/in-built destruction/postblit, so that needs to be fixed in the compiler before it's tackled here.
This impacts attribute inference in a couple of key Phobos building blocks, such as emplace and the Array container. Grepping for malloc tends to be a good way to find code that uses explicit destruction.
I plan to file one or more dependent Phobos PRs to leverage this.

As I mentioned in the discussion, I don't like that we are re-implementing what the compiler already has done. But I think the idea of doing this is OK, and as long as it's completely private, we should be good. I'd like to see a compiler-assisted solution here for the implementation of the destructor call order (seeing that the compiler already does this).
Can you rename the private templates stolen from phobos to something else? I don't want to see any name conflicts appearing for existing code. I know they are private, but you know how D likes to ignore that fact. And every module imports object.di
Speaking of that, nothing from phobos will use this code, because you didn't update object.di.

As I mentioned in the discussion, I don't like that we are re-implementing what the compiler already has done. But I think the idea of doing this is OK, and as long as it's completely private, we should be good. I'd like to see a compiler-assisted solution here for the implementation of the destructor call order (seeing that the compiler already does this).

I completely agree, and this patch doesn't have to be permanent. If someone with the aptitude to hack on DMD to fix this in a more uniform manner steps up, they can simply erase the functions added by this patch. The case for postblitRecurse is less clear, since it adds a public function; I suggest we keep it undocumented until a destroy-like public API is devised, if ever. emplace is the only use-case for it in Phobos that I could find, though more thorough grepping might uncover more.

Can you rename the private templates stolen from phobos to something else? I don't want to see any name conflicts appearing for existing code. I know they are private, but you know how D likes to ignore that fact. And every module imports object.di

Yeah, I ran the Phobos unit tests and were satisfied that they still passed, but you never know... I'll prefix them with something.

Speaking of that, nothing from phobos will use this code, because you didn't update object.di.

Thanks, will do.

Yeah, I ran the Phobos unit tests and were satisfied that they still passed, but you never know... I'll prefix them with something.

I don't want to say that I'm 100% sure there would be name conflicts, but simply due to the fact it was not in object.di, the phobos tests didn't test it.

I don't want to say that I'm 100% sure there would be name conflicts, but simply due to the fact it was not in object.di, the phobos tests didn't test it.

Ah, right.
Well I prefixed the templates and added the code to object.di as well. Seems to work.

So postblitRecurse isn't used in destroy at all, right? Should this not be split into 2 pulls, one for the postblit and one for destroy? Of course one will depend on the other for the inclusion of object_satisfyAny.
I'm actually unsure as to why we need postblitRecurse in object anyway, since it's only to be used in Phobos.

I'm in favor of adding the change. The lack of an attribute correct destroy is an issue when using manual memory mangagement.

Ah, it's a lot cleaner now that the helper templates are in core.internal.traits. Thanks.

I'm actually unsure as to why we need postblitRecurse in object anyway, since it's only to be used in Phobos.

It appears that .dup contains a hacky workaround to make itself conditionally @safe, but nothing to make it conditionally pure or nothrow. This could be fixed by using postblitRecurse instead. There are many other places in druntime that use explicit postblit but I don't know if any of them are sensitive to attribute inference.

OK, I like how traits moved to core.internal. I see nothing wrong with this, and it's easy to fix once the compiler exposes its function (or maybe the compiler should CALL this function?).
LGTM.

There are many other places in druntime that use explicit postblit but I don't know if any of them are sensitive to attribute inference.

I think druntime mostly glosses over this because the API is via extern C and it basically ignores attributes. Not the best thing, but it is what it is.

I prefixed destructRecurse and postblitRecurse with an underscore to be consistent with the convention in object.

It appears that .dup contains a hacky workaround to make itself conditionally @safe, but nothing to make it conditionally pure or nothrow.  These are VERY welcome changes, and will have VERY positive repercussions throughout the language (dup, emplace, appender, to, and everything built on top of that will immediately benefit).

There are many other places in druntime that use explicit postblit but I don't know if any of them are sensitive to attribute inference.

Using postblitRecurse over the typeid is still preferable, if only for performance consideration. That said, I do believe that most of the explicit posbliting that happens in druntime operates on run-time types, so using it is not possible anyways.

These seem to not handle the case where a postblit fails, in which case every fully constructed object should be destroyed.
For static arrays, this should be pretty easy to handle, with low overhead, so we should do it. It might be a bit harder to do it in a "smart" way for structs, as the current static foreach loops don't really lend themselves to this very well.
Maybe a mixin loop though? Something like:
foreach (member : FieldNameTuple!T)
{
    mixin(member ~ ".postblitRecurse();");
    mixin(scope(failure) member ~ ".destroyRecurse();");
}

These seem to not handle the case where a postblit fails, in which case every fully constructed object should be destroyed.
For static arrays, this should be pretty easy to handle, with low overhead, so we should do it. It might be a bit harder to do it in a "smart" way for structs, as the current static foreach loops don't really lend themselves to this very well.

Thanks for catching this, that would've been a sneaky bug! I believe static-foreach and static-if do not introduce a new scope, so the obvious solution should work. At any rate, I'll fix it and add appropriate tests ASAP.
I've also filed issue 14242 for the problem with in-built destruction of fixed-length arrays. I should add some tests that test the fixed-length array support in a separate test where attributes are not yet tested. The problem is only for destruction; copying seems to work correctly.

I never bothered filing it, but another outstanding issue in druntime is that subsequent exceptions that may be thrown during the cleanup-destruction of a failed postblit should not interrupt the clean up, but rather, be collected and thrown back as a chained exception. Or, at the very least, at least just not interrupt if you don't chain.
Thankfully, very few things throw on destruction, so I'm not too worried about that one.

ping, what's the status on this?

ping, what's the status on this?

I'm back in my regular schedule and can continue work on the unittests. It's more work than it wouldbe if the compiler-generated code behaved correctly in all cases, but this PR shouldn't be blocked by that, I'll figure it out.

Thanks, that would've been a sneaky bug! I believe static-foreach and static-if do not introduce a new scope, so the obvious solution should work. At any rate, I'll fix it and add appropriate tests ASAP.

Argh, static-if does indeed not introduce a new scope and thus works nicely for injecting scope statements, but static-foreach does introduce a new scope. I wonder if this is a recent development, I swear I used to get variable name conflicts when declaring variables inside the body of a static-foreach loop, but I can't reproduce it now.
Without making a mess of try-catch and even more recursion, I guess the string-mixin approach is the only viable choice.

I wonder if this is a recent development, I swear I used to get variable name conflicts when declaring variables inside the body of a static-foreach loop, but I can't reproduce it now.

Or maybe it was function declaration:
  foreach (T; TypeTuple!(string, int)) {
    void func(T arg) {}
  }

Or maybe it was function declaration

Yeah, that is probably it. I also seem to remember that things like templates and/or enums could create conflicts, but more like mangling conflicts, not conflicting variable conflict.

I completely agree, and this patch doesn't have to be permanent. If someone with the aptitude to hack on DMD to fix this in a more uniform manner steps up, they can simply erase the functions added by this patch.

Might make sense to move that functionality completely into druntime and have the compiler use it.

Might make sense to move that functionality completely into druntime and have the compiler use it.

The function is already pretty concise in the compiler, so it wouldn't make too much sense.
https://github.com/D-Programming-Language/dmd/blob/4e811cba25f0f7e51d1b686c893030bc4b8ab2fb/src/clone.c#L919

Implemented the string-mixin solution for failing postblit. Also implemented proper destruction when postblitting a static array fails.

If the compiler already implements all of that correctly for TypeInfo.xdestroy, shouldn't we use that instead, i.e. make it available as T.__aggrDtor or T.__destroy and call it.

@MartinNowak said that in my first comment. But this is a PR that is ready to be pulled, and I see no PR to fix the compiler...

Auto-merge toggled on

Can we please work on a compiler solution @JakobOvrum. I can help you with the details if you have any question.

Possible follow ups:

[ ] Expose compiler-generated primitives and use those instead
[ ] Measure performance and code size characteristics of primitives introduced in this patch (would be obsoleted by the above)
[ ] Optimize destroy to use memset (although this is really the compiler's job; important because slice assignment is a memory safe interface, while memset is not, requiring @trusted)
[ ] Define how D should behave on failed destruction (throwing from a destructor)

Compiler primitives are now available https://github.com/D-Programming-Language/dmd/pull/4650, can you do a follow-up?

Thanks! Will do.

@JakobOvrum what about the follow up?

This pull request introduced a regression:
https://issues.dlang.org/show_bug.cgi?id=14746

This introduced a regression:
https://issues.dlang.org/show_bug.cgi?id=14839


Fantasy Land method aliases

There are several related questions which must be answered before we can merge #216. Discussing these in a dedicated thread seems wise, as that pull request is very large.
Currently we provide Maybe and Either types compatible with the Fantasy Land spec prior to the merging of fantasyland/fantasy-land#146. In #216 we're adding support for the prefixed method names. Should we continue to expose methods via the unprefixed names? Concretely, should we provide Maybe#map and Maybe#fantasy-land/map or just the latter?
Reasons to alias (:alien:):

to maintain Ramda compatibility until ramda/ramda#1900 is merged; and
to support method chaining.

Reasons not to alias (:no_entry_sign: :alien:):

it would violate The Zen of Python (python -c 'import this' | grep 'only one');
it would increase Sanctuary's surface area (more to document and test); and
method chaining is at odds with Sanctuary's emphasis on function composition.

If we decide to include these aliases, there's a second question to answer: should we also provide Maybe.empty, Maybe.of, and Either.of? These are already aliases (for () => Nothing, Just, and Right respectively). There's value, of course, in providing the prefixed equivalents to facilitate the creation of polymorphic functions, but if one is dealing with the Maybe type, say, I see no reason to write Maybe.empty() rather than Nothing. Am I missing anything?
The final question is what to do with Maybe#filter. It's currently defined for compatibility with R.filter and R.reject. My plan, though, is to define filter in sanctuary-type-classes, since it can be derived from other FL functions:
//# filter :: (Monad m, Monoid m a) => ((a -> Boolean), m a) -> m a
var filter = function(pred, m) {
  return chain(function(x) { return pred(x) ? of(m, x) : empty(m); }, m);
};

Thanks, @joneshf, for sharing this approach way back in #10!
With Z.filter in place, #216 could easily add S.filter and S.reject. At that point Maybe#filter would only be useful for Ramda compatibility. Is that important, do you think?
I have views on these matters, but I'd love to hear from @safareli and @Bradcomp (and others) before weighing in.

it would increase Sanctuary's surface area (more to document and test); and

How I see this is that we could just document normal non namespaced functions and state somewhere which FL interfaces the structure conforms to. About tests if a.map === a[fl.map] and if one is tested then other one is tested too as thay are same so why do we need to write more tests. or at least we would not need to write too many tests. maybe just check if structure implements some FL method it to also have non namespace alias. So I dont see this as a big issue.

method chaining is at odds with Sanctuary's emphasis on function composition.

I understand that Sanctuary emphasis function composition, but I don't think we should make it painful to do chaining. Also even though composition is great, Sometimes it's easier to add ... .map(f) to so(m(e(big),ex),pre,sion) then wrapping it in map(f, ...) when you the expression is not in composition.  Also as chaining is pure in this case it's still good think and I don't see why should we make it hard to do.

it would violate The Zen of Python (python -c 'import this' | grep 'only one');

That's a good point but if we see fantasy-land/methods as private interface which is used to communicate between fantasy-land structures, then there are no multiple ways to do one think.
If in a code we are working with some specific version of Maybe and want to do map over it, then we would just just write a.map(f)
If we are writing some generic function like filter which requires it's arguments to conform to some FL interface then in that function we should definitely use namespaced methods.

Related: my comment on same discussion in folktail#39

About tests if a.map === a[fl.map] and if one is tested then other one is tested too as thay are same so why do we need to write more tests.

Absolutely. In fact, I have eq(x[methodName], x[FantasyLand[methodName]]); in the test suite right now, so testing all the aliases requires just one line of code. The documentation is more of an issue.

That's a good point but if we see fantasy-land/methods as private interface which is used to communicate between fantasy-land structures, then there are no multiple ways to do one think.

I agree that we should consider the prefixed methods private. There are still two ways to do it, though: maybe.map(f) and S.map(f, maybe). I worry that documenting the former will make new Sanctuary users less likely to discover S.map, which in turn will result in fewer functional pipelines.
It's worth noting that I was able to improve performance significantly in #216 by removing type checking from methods. Since Ramda does not do type checking, methods such as Either#chain needed to perform type checking in order to catch misuses of R.chain (this check caught a type error in a package with 100% coverage when I upgraded its Sanctuary dependency to a version with type-checked methods). Sanctuary will soon provide its own Fantasy Land functions which can take on the responsibility of type checking. Sanctuary users who use methods directly will not receive helpful error messages when they err.

I understand that Sanctuary emphasis function composition, but I don't think we should make it painful to do chaining.

I agree. I'm happy for the aliases to exist; I'm just not comfortable documenting their existence. If advanced users want to use Maybe#map, that's fine with me. If users with existing code don't want to switch to S.map when upgrading, that's fine with me too. But I want to encourage new Sanctuary users to reach for S.map.

If we are writing some generic function like filter which requires it's arguments to conform to some FL interface then in that function we should definitely use namespaced methods.

Absolutely. The point is, though, that we can have S.filter and S.reject without defining Maybe#filter, but if we want values of the Maybe type to work with R.filter and R.reject we need to define Maybe#filter (since the Ramda functions dispatch to filter).

Sanctuary will soon provide its own Fantasy Land functions which can take on the responsibility of type checking. Sanctuary users who use methods directly will not receive helpful error messages when they err.

so Maybe#map and Maybe#fantasy-land/map would not be typechecked?

so Maybe#map and Maybe#fantasy-land/map would not be typechecked?

That's the current situation in #216, yes. Paying the cost of type checking twice—once in S.map and once in Maybe#fantasy-land/map—doesn't seem fair.
Do you think the methods should be type checked? I'm not convinced that it was correct to remove the type checking.

Aliasing
Pros

to maintain Ramda compatibility until ramda/ramda#1900 is merged;

:+1:

to support method chaining.

:-1:
Cons

method chaining is at odds with Sanctuary's emphasis on function composition.
it would violate The Zen of Python

:ok_hand:
I recently started a new project and was evaluating which libraries to use for functional tools and types.  I like Sanctuary because it is much more opinionated than Ramda in various areas (type safety and variadic functions to name two).  For that reason I am all for deprecating the non-prefaced versions of the methods.  Sanctuary makes it easy to write code in a certain way, and helps me out if I make a mistake in a way that Ramda doesn't.  Especially once Sanctuary includes functions for all the FL methods, I see no reason to use the non-prefixed methods in practice.  There are plenty of other libraries for ADTs that will support the non-prefixed versions and are good choices if you want to use method chaining.
On the other hand, I don't support removing the non-prefixed versions for a little while. It would be nice to not break compatibility with existing code until libraries are caught up with FL 1.0.  I would argue that both the prefaced and non-prefaced versions should be considered a private interface.
Of
It would be nice to have an S.of function (does it already exist?) that takes a type as a parameter.
of :: Applicative m => m -> a -> m a
Filter and Reject
I am all for creating Sanctuary versions of Ramda functions where it makes sense to do so, and I do think this is a case where it makes sense to do so.
Typechecked methods
Given what I've said above, I think it's fair to not typecheck the methods.  However, the one down side is then if I write a generic function to operate on a ADT it will lose out on the type checking.  On the other hand, I could always define the function using sanctary-def to get that type checking back, so I think it's a wash.

Thank you both for your thoughtful feedback.
I intend to do the following:

Add prefixes to the documentation of the methods. We'll document Maybe#fantasy-land/map, for example, rather than Maybe#map.

Update the code examples to use S functions. The doctests for Maybe#fantasy-land/map, for example, will feature S.map rather than direct method invocations.

Leave the method aliases. These will still be verified by the test suite, but will no longer be documented. We may decide to remove these at some point in the future.

Remove Maybe.empty, Maybe.of, and Either.of. These simply aren't necessary.

Remove Maybe#filter. #216 will add S.filter and S.reject so I don't think maintaining compatibility with the Ramda equivalents is important.

It would be nice to have an S.of function (does it already exist?) that takes a type as a parameter.

It doesn't exist yet, but we can add it in #216 once we agree on the appropriate type of Z.of in sanctuary-js/sanctuary-type-classes#3.

I'm reconsidering this issue.
My long-term goal is to move the Maybe and Either types to their own packages. These packages will only provide the data constructors and the various fantasy-land/-prefixed methods. They will be compatible with Sanctuary and sanctuary-type-classes (and Ramda if it is updated to support version 2 of the FL spec). I do not intend to provide unprefixed methods. Those who prefer method chaining to function composition are better served by Folktale, which is to Scala as Sanctuary is to Haskell.
Given this goal, what is the best transition? Initially I had thought it wise to keep the unprefixed methods around for the next six months, say, to making upgrading to<EMAIL_ADDRESS>less onerous. I'm now questioning this logic. sequence has been replaced with fantasy-land/traverse. Should we keep the sequence methods around for some time? The type of fantasy-land/ap differs from that of ap. Should we keep both versions of the method? What about new methods? Should we provide alt in addition to fantasy-land/alt? alt is not required for backwards compatibility, but providing some aliases but not others for historical reasons would be confusing for new users.
I'm now in favour of removing all the aliases from #232. This will mean code which invokes Sanctuary methods directly will need to be updated when upgrading to v0.12.0, but this cost will need to be paid at some point regardless.

I think given the work you've done on sanctuary-type-classes, it makes a lot of sense to remove the aliases.  By using the provided functions in conjunction with the data types, one does not have to worry about the types and functions falling out of sync.
If one doesn't want to use the functions provided, they can make sure to update their calling code, or just not update Sanctuary.  Eventually that would have to be the case anyway, might as well do it once you have the functions available to manage the transition.

Thanks for the additional feedback, folks. :)


Move message fix

en.json: fixed spelling mistakes
After creating your pull request, tick these boxes if they are applicable to you.

[X] I have tested my changes against the review branch (the latest developmental version), and this pull request is targeting that branch as a base
[X] I have tested my changes on Python 3.8 or higher
[X] I have ensured my code is formatted using Black

Description
Fixes the formatting of the move message. .format() has to be called on the result of self.str.get(), as that returns the string from the en.json file and we need to format that.
Related issues (if applicable)

thanks


Rename --bundle to --no-bundle in Pages commands for similarity with Workers

Ah, the ol' switcheroo.
What this PR solves / how to test:
--bundle was recently added which transforms any imports in a _worker.js with a default value of false. Eventually though, I think this functionality will be turned on by default, and we'll want to keep our arguments similar to Workers', so this PR renames --bundle to --no-bundle (like Workers') and gives it a default value of true. Once we're comfortable with it, we can just flip the default to false.
Associated docs issues/PR:

https://github.com/cloudflare/wrangler2/pull/2404

Author has included the following, where applicable:

[x] Tests
[x] Changeset

Reviewer has performed the following, where applicable:

[x] Checked for inclusion of relevant tests
[x] Checked for inclusion of a relevant changeset
[x] Checked for creation of associated docs updates
[x] Manually pulled down the changes and spot-tested

LGTM! Once Pete's comment is addressed, I'll review one more time, but it's pretty much 👍 from my side

@petebacondarwin , that doesn't seem to be necessary here? No complaints from yargs/tsc/our tests, at least. Perhaps a quirk of using the builder pattern in src/dev.tsx vs. us using these objects in src/pages/dev.tsx?

@petebacondarwin , that doesn't seem to be necessary here? No complaints from yargs/tsc/our tests, at least. Perhaps a quirk of using the builder pattern in src/dev.tsx vs. us using these objects in src/pages/dev.tsx?

Interesting! OK. If it works then it works.

OK, so I pulled this down and tried it out
The main difference appears to be that with the current PR you cannot do --bundle to turn bundling on.
The only thing you can do is no-bundle=false or no-no-bundle.
Whereas in wrangler dev you can use --bundle to negate the no-bundle option.

And can you fix up my failure to add to the docs? E.g. here : https://developers.cloudflare.com/workers/wrangler/commands/#pages

--no-no-bundle!!! Hahaha! That is a bizarre default behavior from yargs! Looks like --no-no-bundle also works on wrangler dev proper since you add the no-bundle option in your config.
I'll add bundle to wrangler pages dev and wrangler pages publish so we have parity.
We'll hold off on docs just a minute until we figure out exactly what we want to do with the new experimental pack stuff that's imminent.

I got one of my flip-flops flip-flopped. Inverted it, and we're good now :)


New API to transform tag names prior to sorting | Fix tag filter

fix new tag filter not called

FIX #571

add new ability to transform tags (tag name) prior to sorting, allowing to transform tags into semver format can be achieved

tags will keep the original name post sorting
FIX #571

add debug log messages for transformer and filter
recompile dist

I just noticed that this tag_resolver.transform option isn't documented in the README in the reference


Update type definitions for toMatchImageSnapshot

Update options type def of toMatchImageSnapshot, based on https://github.com/meinaart/cypress-plugin-snapshots/issues/54

@meinaart Can you please have a look on these changes?
Thanks for such a helpful plugin!


Set up pre-release branch

Branch & release namespace should be titled next, and we should configure the changesets action to ship changes merged to this branch
Will be the branch where we ship the first version fo

Other options, include:
How duckdb is shipping (seems like every commit?)

Look at duckdb (seems like they are creating a new release tag for every... pr?)
Ship svelte kit (#540) upgrade here

My first suggestion is to have a next version in npm registry similar to the Beta in this project. (https://github.com/cloudflare/wrangler2/blob/main/.github/workflows/prereleases.yml#L47)
It will allow testing of the latest changes on main using the npm registry.

In the current setup, we can merge to main without affecting our users. It's when we merge the changeset package PR that we can introduce breaking changes.
We should enhance our UI testing and have good feedback before merging the changeset PR

We can have Git workflow with develop/release branch. However, it can be intimidating and most open-source project don't use that model.
To read: https://nvie.com/posts/a-successful-git-branching-model/


Annotation placed at the end of a source file is ignored

regardless of annotation type

Can you give a specific example of what's happening? I just want to make sure it's clear what exactly is happening.

I changed the title to better state the problem.
This may help reproduce the problem:

copy a requirement from the report that hasn't been annotated
paste it to the end of any source file that is to be scanned
run duvet report and check the report

The annotation seems to be ignored, as if it weren't in the source code, regardless of annotation type.
Then I try putting something after that annotation, say a dummy comment, and run duvet report again. It becomes effective and is reflected in the report.

The bug here is we don't finalize the state machine after completing the last line.
https://github.com/awslabs/duvet/blob/02c92452158debf1be82c702824689ab01b08aa0/src/pattern.rs#L98
I can push a fix


Automatic Rietveld Refinement (DARA)

This project has been renamed as DARA as that is the most practical system now.


Nuget lint

Dotnet has task format, using that, we can format and enforce some codestyle

Thank you for the review I will process it shortly

The added Resharper config is there to conform with the existing code. If I remove it, anyone who makes an update with VS + Resharper / Rider will create style changes, which are again used code style.
It only makes the life of contributors easier, the default tooling does not need to understand it.
I aim to have such a configuration for dotnet format that it conforms with the current code.
Of course, we can spend hours writing formatters that will ensure strictness. That will undoubtedly be awesome, but I do not see a real value.
If you insist that all configurations must be used by tooling, there are some possibilities. The easier one is to use Resharper CLI, which comes as a Nuget package. It's stricter than the dotnet format, but also slower and requires more configuration.
Another option is to use, e.g., csharpier (I am not a fan of it, but it's an option).

About current changes, the only one I am aware of is an indention of raw string literals, which was written in many different ways in this codebase. I only unified it into one style.

I believe I addressed all comments and that the PR is ready.

Thank you for all the reviews, I like to push things forward :)

Thanks a lot @trejjam for all the help!

I'm having this issue as well. Looking for the best workaround until the fix is released.
I could remove the grouping from my yml files but then I'd have to put them back later. What I'm thinking is to simply merge the change and then let dependabot re-discover the updates in a subsequent pass. Will that work?


WIP: Implement Config class

Closes: https://github.com/metarhia/impress/issues/885

@belochub Please help reimplement JSTP integration to Impress. Now we get Cannot connect to Cloud Controller: RemoteError: Application not found after start.

@belochub I have detected the problem, it isn't connected with jstp, so debugging now

Landed in 1f20afd, 88a80e4 and bc58d4a


Unable to mount root fs with (driver?) on Ingenic T31X(Wyze V3)

Are you able to give me where in kernel mtd driver is loaded? jz_sfc_probe() successfully loads mtd driver as in the dmesg. It should set disk->driverfs_dev->driver, shouldn't it? Does your dmesg have "JZ GMAC disabled"?
dmesg:
[    0.000000] Kernel command line: console=ttyS1,115200 panic=10 root=/dev/mtdblock3 init=/init mtdparts=jz_sfc:256k(boot),64k(env),2048k(kernel),5120k(rootfs),-(rootfs_data) mem=64M rmem=6c
....
[    0.367776] squashfs: version 4.0 (2009/01/31) Phillip Lougher
....
[    0.483702] JZ SFC Controller for SFC channel 0 driver register
[    0.489819] 5 cmdlinepart partitions found on MTD device jz_sfc
[    0.496160] Creating 5 MTD partitions on "jz_sfc":
[    0.501108] 0x000000000000-0x000000040000 : "boot"
[    0.507122] 0x000000040000-0x000000050000 : "env"
[    0.513113] 0x000000050000-0x000000250000 : "kernel"
[    0.519252] 0x000000250000-0x000000750000 : "rootfs"
[    0.525487] 0x000000750000-0x000001000000 : "rootfs_data"
[    0.532099] SPI NOR MTD LOAD OK
[    0.535688] JZ GMAC disabled
...
[    0.618898] List of all partitions:
[    0.622524] 1f00             256 mtdblock0  (driver?)
[    0.633610] 1f01              64 mtdblock1  (driver?)
[    0.644490] 1f02            2048 mtdblock2  (driver?)
[    0.655380] 1f03            5120 mtdblock3  (driver?)
[    0.666252] 1f04            8896 mtdblock4  (driver?)
[    0.679136] No filesystem could mount root, tried:  squashfs
[    0.684987] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3)
uImage and rootfs:
OpenIPC # mw.b ${baseaddr} ff 1000000; fatload mmc 0:1 ${baseaddr} uImage.${soc} ; sf probe 0; sf erase 0x50000 0x300000; sf write ${baseaddr} 0x50000 0x1BE8A6
OpenIPC # mw.b ${baseaddr} ff 1000000; fatload mmc 0:1 ${baseaddr} rootfs.squashfs.${soc} ; sf probe 0; sf erase 0x350000 0xa00000; sf write ${baseaddr} 0x350000 0x4AF000
[root@WCV3:~]# /media/mmc/ipctool-mips32
chip:
vendor: Ingenic
model: T31X
ethernet:
mac: "7c:78:b2:7f:48:43"
rom:

type: nor
block: 32K
partitions:

name: boot
size: 0x40000
sha1: dda0626f
name: kernel
size: 0x1f0000
sha1: 6887b828
name: rootfs
size: 0x3d0000
sha1: d368892a
name: app
size: 0x3d0000
path: /system,squashfs
sha1: 04b813a8
name: kback
size: 0x1f0000
sha1: 6a9dfced
name: aback
size: 0x3d0000
sha1: e5b26a97
name: cfg
size: 0x60000
path: /configs,jffs2,rw
name: para
size: 0x10000
sha1: 472a55b0
size: 16M
ram:
total: 128M
media: 32M
firmware:
kernel: "3.10.14__isvp_swan_1.0__ (PREEMPT Wed Apr 14 17:44:51 CST 2021)"
toolchain: gcc version 4.7.2 (Ingenic r2.3.3 2016.12)
libc: uClibc <IP_ADDRESS>
main-app: /system/bin/iCamera

I am not familiar with OpenIPC yet. I may have a trivial mistake. Thank you.

I just installed openipc on three wyze cam v3's tonight using info in the file below. no problems.
https://github.com/themactep/device-wyze-v3/blob/master/README_RETIRED.md
Firmware
Version <IP_ADDRESS>-lite
Build master+0bcb229, 2024-05-18
Majestic master+90c0b57, 2024-05-16
U-Boot U-Boot 2013.07-g90873ad (May 01 2024 - 19:56:15)

@ckuethe could not install openipc
when install finally, camera resets every x minutes
had to move to thingino firmware, working ok for wyze v3

Disregard. I moved to thingino. It works fine. Will close.


how can i uninstall the program

i cant find any setting to uninstall the program, how can i fully uninstall bloxstrap?

https://github.com/pizzaboxer/bloxstrap/wiki/Uninstalling-Bloxstrap

You uninstall it the same way you uninstall any other program on your computer.

https://github.com/pizzaboxer/bloxstrap/wiki/Uninstalling-Bloxstrap

thanks a bunch


refactor(plugins/gcpaudit): improvements for first release

What type of PR is this?
/kind bug
/kind cleanup
Any specific area of the project related to this PR?
/area plugins
What this PR does / why we need it:
Minor improvements and refactors to the gcpaudit plugin before proceeding with a first release.
Which issue(s) this PR fixes:
Special notes for your reviewer:

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: jasondellaluce
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

plugins/gcpaudit/OWNERS [jasondellaluce]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 948178d5a7c6b665e3cbd4e4eb86657caf4018ea


Fix Issue #409

TamTam Micro Activity can now be made into fullscreen mode. This should fix #409

It's a good start but there is an error in console:
activity.js:25 Uncaught TypeError: TamTam.App.computeSize is not a function
    at HTMLButtonElement.<anonymous> (activity.js:25)

Look like you don't call the right function to recompute size.

I've replaced the function call and adjusted the position of the unfullscreen button on this new PR. Let me know if there are still some issues!

Good job Andrea, as usual. Thanks.


[CSL-121] [New] [Research] Update system

@georgeee
SSFK scheme was pointed out in CSL-118 and is now an outdated idea.
Need to design update system for Cardano SL.
So, sysupdate feature includes:

Way to sign & announce update
Way to deliver update

HTTPS mirrors wil work for now

Way to apply update

bsdiff
how binary update would be applied by executable itself
look at google chrome update system (is updater opensource?) -- idea by Jonn
use self-unpacking archive to deliver update (i.e. application retrieves update, verifies it, finalizes and launches update archive executable)

Way to handle protocol modifications

proof of burn

Also should be clarified:

sysupdate structure
block field for versioning & updates

@georgeee

Idea of leveraging responsibility of sys update to stakeholders.
For update to be applied at least majority of stake should put their signatures on it
Announcing could be done as combination of broadcasting and block versioning.

Sequence of steps:

we have required signatures

we send broadcast-notification to all nodes to download update, providing signatures in announcement

nodes have 8h (or ??) to download update

after 8h, old block version is considered deprecated

to do it safely, stakeholder can sign scheduled update epoch along with binary

Nodes perform update and use only new block version

Proof of burn means when node adopts update and sees update is marked as one requiring modification to protocol, it sends all it's coins to so called burn address in old chain

this should be obvious this address is artificial, noone holds private key, e.g. address like 'ArTiFiCiAlKeyForBurn-/=='
proof of transaction if applied (i.e. >k blocks passed since it's in blockchain) is taken and passed to new blockchain, same amount of money is generated.
further only new chain is maintained, old one eventually gets deprecated (cause major stake holders leave it)

@georgeee
Mind that slot leaders shouldn't update immediately
Or maybe should
Need to think hard on how this pause for update is managed

@georgeee
Current state:
First, need to specify 3., 4. (what this proof should look like)
For 1. need to discuss stake signature proposal w/ Charles

@georgeee
Proposed idea 1. to CH:

@charleshoskinson regarding update system, concern of who should sign update binary, we have an idea of leveraging responsibility of sys update to stakeholders.
For update to be applied at least majority of stake should put their signatures on it. Like they sign it with some mouse clicks. In simplest case, to ensure update is proposed by us major stakeholder could receive phone call with announcement of update and plea to confirm (i.e. put signature on) update.
It seems really natural, cause cryptocurrency is maintained via consensus between stakeholders. Software update is actually a part of this maintenance. And stakeholders should reach consensus on whether to apply this update.
This idea taken further (not for Dec, but for future releases) we may ship code patch along with binary patch, so that engineers from stakeholders could verify no malicious code were introduced (and it's not hard to create VM image with certain compiler versions, which would compile same binary from same sources, to let stakeholders ensure binary diff corresponds to text diff).

@georgeee
BIP: [9|https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki]
Title: Version bits with timeout and delay

@neongreen
Regarding Google: they use something called Omaha, but it's Windows-only. They have also developed a new binary diff algorithm for executables that produces 10× smaller diffs than bsdiff. It's open-source, written in C++ and we could probably write bindings to it: http://www.chromium.org/developers/design-documents/software-updates-courgette.

@neongreen
(However, I'd propose using bsdiff at first, and implementing courgette later. We can always serve courgette diffs for versions that support them, and bsdiff updates for old versions that don't support them.)

@neongreen
Regarding “how binary update would be applied by executable itself”: someone would have to do it separately for Windows, macOS and Linux. I have googled and existing update frameworks (Squirrel, etc) would likely be hard to integrate with Haskell.
Telegram, for instance, does it as follows: they download an updater executable, and the executable does the work. They don't care about violating existing conventions – e.g. my Telegram executable is in /usr/sbin, which Telegram can't overwrite, and so the updater just changed the path to ~/.TelegramDesktop in the desktop shortcut and put the executable there. We can do the same, or we can rely on system's package manager.

@neongreen
Regarding the idea of “leveraging responsibility of sys update to stakeholders”: I don't like this idea. What should happen if one of the stakeholders is using a client that wasn't written by us, or a modification of our client (which is going to be open-source)? In fact, the “8 hours” rule would make it impossible for anyone else to produce a viable alternative client (or a hardware implementation), as they won't be able to guarantee the 8h SLA for updating their client.
What goal is the -complicated update protocol with stakeholder pleading- supposed to achieve?
*If the goal is “making hard forks easy”, then it won't make them easy because not everyone would be able to update in 8 hours (or even 24 hours) and IIUC people who haven't updated wouldn't be able to see transactions. Everyone outside of IOHK who wants to deal with our currency would hate us.
*If the goal is “making sure that the stakeholders are okay with the change”, then it is already satisfied. If a stakeholder isn't okay with the change, they simply won't update. If all stakeholders won't update, nobody would update either simply because they wouldn't want to be cut off the network.

@jagajaga

Telegram, for instance, does it as follows: they download an updater executable, and the executable does the work. They don't care about violating existing conventions – e.g. my Telegram executable is in /usr/sbin , which Telegram can't overwrite, and so the updater just changed the path to ~/.TelegramDesktop in the desktop shortcut and put the executable there. We can do the same, or we can rely on system's package manager.
In linux world we will rely on system's package manager. no to self updating programs. Otherwise lots of users would hate us.

@neongreen
Nice.

@manpages

no to self-updating programs.

@jagajaga sorry, but we have to provide a way of applying hotfixes, so we have to provide users two options — install from their package manager (packaged by third party) and have binary diff update mechanism disabled, and the second option — provide binary build with binary diff update mechanism enabled and auto-updates a la Firefox. More on binary diff updates later

@georgeee
https://docs.google.com/document/d/14-iltC_RbmH0goBJ1ZbsLiQGwLK8aJEt3QwM4lwqHDM/edit#


translate WorkloadRebalancer api

What type of PR is this?
/kind documendation

What this PR does / why we need it:
translate WorkloadRebalancer api docs
Which issue(s) this PR fixes:
Parts of #633
Special notes for your reviewer:

cc @windsonsea @chaosi-zju

website of v1.10 should also have this doc, but now in v1.10 neither english version nor chinese version exist~

website of v1.10 should also have this doc, but now in v1.10 neither english version nor chinese version exist~

Nice finding, I'll fix it in another pr


[generators] Adding migration step to provision Laravel application

Adding php artisan migration to Laravel provision.

Closed in favor of #567 .


Vue doesn't support rendering MathML

Vue version
3.2.27
Link to minimal reproduction
https://sfc.vuejs.org/#eNrlV71u2zAQfhVWixO0lpCikyEL6JYhXoqiXTRUlmiLgUgKJO0MhsdOfcs+SY5SYlvkMbGTDPlZDN4v7+476wM30fe2jdcrGk2iVJeKtYZoalZtlgvGW6kM2RBFF2RLFkpyMgLXUS5yUUqhDeF6SabWfja6pE0jyW+pmurT6DwXadKng0QgGMrbpjAUJELS+iL7QUVFFRNLMitMPbsiN8zU5NeKpglYOy8Ohu5kz6aYN330nax2QidWB6JV6K6FvcbqlLxxdFYrs7M0gV/fwrICLAyN+RyMmQdjzpEYUPllpVxkX8Eihk0lTlegGPSNjEFmU+fSI4Kw2bGsRPo6stDQyGz4Nz8cvP7/+4t4Y1ClfKGKEqnrwkv8QL1eDhx9HF8M2+GYrbRf2KdtL76NL4AAEn5i81hevAXsz/GRtv05s34zK/VxoQ9DZM87CgPhntvCXJiWsqIZE4Kqy5+zqzTp5D09Vmzdp16Pa8ObaR7d3/sHCHd/wYA6B3viTMSfB0aZIcIMbxNOluGVwIgSoUkMEgcQBw63XXdnHnH3p4PtyhFl4UPByBCnQgwChAZxEgzU50RjaKLfJA+twyEO/gAnbh7+VXzGbL3AE1r082EFY+T4/nb0aXN8pWvx3mHEx35ARjsqAtKwTj2LJJ3l4NEWfYn65+CYF218raWAB+PGuuZ3Bp1HE9JprA6eiVbOo9qYVk+SRC9K+8y81rFUywROsVoJwziNqebjOXzcNVWQuL9/m4tttL0FFv2m3Q==
Steps to reproduce

Try rendering any MathML tags.

What is expected?
Vue will properly render MathML like it does with HTML and SVG.
What is actually happening?
Vue ignores MathML and thinks the tags are wrongly configured custom elements.
System Info
System:
    OS: macOS 13.2.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 16.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.14.0
    npm: 9.3.1
  Browsers:
    Firefox: 110.0
    Firefox Developer Edition: 111.0
    Safari: 16.3
    Safari Technology Preview: 16.4

Any additional comments?
MathML is well supported in all browser engines since Chrome 109 (CanIUse MathML) and tremendously useful for any web pages that want to render mathematical formulas.

A quick test showed that React does support MathML and Svelte does not.
Prior issues:

https://github.com/vuejs/core/issues/3746

There's two layers to this:

Vue needs to add these new tags to the list of known elements, now that they have become supports amongst all major browsers.
Even without 1., I would assume for the MathML to properly render as all of the elements are seem to be added to the DOM just as you would expect them to (check the devtools elements tab).

Oh, we need to use the MathML namespace like we use SVG namespace for SVG elements. That will be a bigger change than initially expected.

@LinusBorg This is exactly right. I just checked the code and made it work with MathML.

Obviously I don't have tests yet, but if you want I could open a PR and would be happy to finish the MathML support with some guidance.

Oh, we need to use the MathML namespace like we use SVG namespace for SVG elements. That will be a bigger change than initially expected.

@LinusBorg This is exactly right. I just checked the code and made it work with MathML.

Obviously I don't have tests yet, but if you want I could open a PR and would be happy to finish the MathML support with some guidance.
Edit: Here is the code if you want to check it out -> main...sto3psl:core:main

I took a quick look and it looks great, I think you can add the test and submit a pr to let everyone see how it goes 👍


Enhancements for the Identity registry

Identities code need some enhancement :

Identity methods must not return Json data anymore. It should return Identity objects.
Identity should be able to instanciate other Identities in requests methods
Identity instanciating should do a "Certifiers-of", and if it fails, a lookup. Because the lookup is not necessary written in the blockchain, whereas certifiers-of is.
We must add a "LOCAL_STATE" attribut describing : "COMPLETED/PARTIAL". When all data of an identity have been downloaded locally, it will be set as COMPLETED. In the meantime, it's PARTIAL.
We must add a "BLOCKCHAIN_STATE" attribute describing "VALIDATED/BUFFERED". An identity is buffered until it is written in the blockchain, where it becomes "VALIDATED".
Caching of identity should not save Json data anymore, only lists of pubkeys+uid corresponding to Identities.

@vtexier : I did most of work on the identities backend.
I think the wot graph should not handle metadata anymore, but "Identity" objects return by the certifiers-of and certified-by objects.
These two methods now return a dict with 2 keys :

"identity" : The certifier or certified Identity instance
"cert_time" : An int, the median time of the certification


Compiling error: ld: symbol(s) not found for architecture arm64

Maybe someone could help me.
Thanks
Stephan
MacBook-Pro:UTM stephan$ ./scripts/build_dependencies.sh
....
     _qcrypto_hash_alg_map in hash-nettle.o   "_nettle_sha256_init", referenced from:       _qcrypto_hash_alg_map in hash-nettle.o   "_nettle_sha256_update", referenced from:       _qcrypto_hash_alg_map in hash-nettle.o   "_nettle_sha384_digest", referenced from:       _qcrypto_hash_alg_map in hash-nettle.o   "_nettle_sha384_init", referenced from:       _qcrypto_hash_alg_map in hash-nettle.o   "_nettle_sha512_digest", referenced from:       _qcrypto_hash_alg_map in hash-nettle.o   "_nettle_sha512_init", referenced from:       _qcrypto_hash_alg_map in hash-nettle.o   "_nettle_sha512_update", referenced from:       _qcrypto_hash_alg_map in hash-nettle.o   "_nettle_twofish_decrypt", referenced from:       _twofish_decrypt_native in cipher.o       _twofish_decrypt_wrapper in cipher.o   "_nettle_twofish_encrypt", referenced from:       _twofish_encrypt_native in cipher.o       _twofish_encrypt_wrapper in cipher.o   "_nettle_twofish_set_key", referenced from:       _qcrypto_cipher_new in cipher.o   "_uncompress", referenced from:       _vmdk_co_preadv in vmdk.o      (maybe you meant: _dmg_uncompress_bz2, _dmg_uncompress_lzfse ) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [libqemu-system-aarch64.dylib] Error 1 make: *** [aarch64-softmmu/all] Error 2 MacBook-Pro:UTM stephan$

Please read the readme. It mentions specifically about a vm and how existing packages can taint a build.

If you’re careful, you can do it on your own machine too. It’s a bit complicated, though.

The underlying issue is that pkg-config will always use the system default path in addition to the specified pkg config path. For aarch64 it might be easy to fix but for x86_64 simulator builds it could be more work. That's why I suggest using a fresh VM/container. Just so it's easier.

diff --git a/scripts/build_dependencies.sh b/scripts/build_dependencies.sh
index c99c175..c4bce60 100755
--- a/scripts/build_dependencies.sh
+++ b/scripts/build_dependencies.sh
@@ -177,17 +177,30 @@ build () {
 build_qemu_dependencies () {
     build $FFI_SRC
     build $ICONV_SRC
-    build $GETTEXT_SRC --disable-java
+    port -f deactivate libiconv
+    build $GETTEXT_SRC --disable-java gl_cv_libcroco=no
+    port activate libiconv
+    port -f deactivate zlib
     build $PNG_SRC
+    port activate zlib
     build $JPEG_TURBO_SRC
+    port -f deactivate libiconv
+    port -f deactivate zlib
     build $GLIB_SRC glib_cv_stack_grows=no glib_cv_uscore=no --with-pcre=internal
+    port activate libiconv
+    build $GLIB_SRC glib_cv_stack_grows=no glib_cv_uscore=no --with-pcre=internal
+    port activate zlib
+    port -f deactivate gawk
     build $GPG_ERROR_SRC
+    port activate gawk
     build $GCRYPT_SRC
     build $PIXMAN_SRC
     build_openssl $OPENSSL_SRC
     build $OPUS_SRC
     build $SPICE_PROTOCOL_SRC
+    port -f deactivate zlib
     build $SPICE_SERVER_SRC
+    port activate zlib
     build $NCURSES_SRC --without-debug --enable-overwrite --enable-widec --with-ospeed=int16_t --without-progs --without-tack --without-tests
 }

@@ -197,6 +210,12 @@ build_qemu () {
     #    echo "${GREEN}Cloning qemu...${NC}"
     #    git clone --depth 1 --recursive --shallow-submodules "$QEMU_GIT" "$QEMU_DIR"
     #fi
+    port -f deactivate bzip2
+    port -f deactivate zlib
+    port -f deactivate nettle
+    port -f deactivate libusb
+    port -f deactivate libxml2
+    port -f deactivate gnutls
     QEMU_CFLAGS="$CFLAGS"
     QEMU_CXXFLAGS="$CXXFLAGS"
     QEMU_LDFLAGS="$LDFLAGS"
@@ -210,6 +229,12 @@ build_qemu () {
     CFLAGS="$QEMU_CFLAGS"
     CXXFLAGS="$QEMU_CXXFLAGS"
     LDFLAGS="$QEMU_LDFLAGS"
+    port activate bzip2
+    port activate zlib
+    port activate nettle
+    port activate libusb
+    port activate libxml2
+    port activate gnutls
 }

 steal_libucontext () {
@@ -221,11 +246,23 @@ steal_libucontext () {
 }

 build_spice_client () {
+    port -f deactivate zlib
     build $JSON_GLIB_SRC
+    port activate zlib
     build $GST_SRC --enable-static --enable-static-plugins --disable-registry
+    port -f deactivate gcc9
+    port -f deactivate zlib
     build $GST_BASE_SRC --enable-static --disable-fatal-warnings
+    port activate zlib
+    port activate gcc9
+    port -f deactivate zlib
+    port -f deactivate bzip2
     build $GST_GOOD_SRC --enable-static
+    port activate zlib
+    port activate bzip2
+    port -f deactivate zlib
     build $SPICE_CLIENT_SRC --with-gtk=no
+    port activate zlib
 }

 fixup () {
@@ -376,7 +413,7 @@ CPPFLAGS="$CPPFLAGS -arch $ARCH -isysroot $SDKROOT -I$PREFIX/include -miphoneos-
 CXXFLAGS="$CXXFLAGS -arch $ARCH -isysroot $SDKROOT -I$PREFIX/include"
 LDFLAGS="$LDFLAGS -arch $ARCH -isysroot $SDKROOT -L$PREFIX/lib"
 MAKEFLAGS="-j$NCPU"
-PKG_CONFIG_PATH="$PKG_CONFIG_PATH":"$SDKROOT/usr/lib/pkgconfig":"$PREFIX/lib/pkgconfig":"$PREFIX/share/pkgconfig"
+PKG_CONFIG_PATH="$PKG_CONFIG_PATH":"$SDKROOT/opt/local/lib/pkgconfig":"$PREFIX/lib/pkgconfig":"$PREFIX/share/pkgconfig"
 PKG_CONFIG_LIBDIR=""
 export CFLAGS
 export CPPFLAGS

Like I said, it's a bit complicated ;)

The underlying issue is that pkg-config will always use the system default path in addition to the specified pkg config path. For aarch64 it might be easy to fix but for x86_64 simulator builds it could be more work. That's why I suggest using a fresh VM/container. Just so it's easier.

If I want to fix it on macos aarch64 (sdk15.0), how to do it, can you give a guideline? And thanks very much! @osy


[reference-bindings] Add some more tests.

Just a test I had locally that I am getting into tree.

@swift-ci smoke test and merge

@swift-ci smoke test macOS platform


Package war as Docker image

Hello there
The videos we saw shows how to create the operator, domains and managed servers.
But it also shows how to provide your war to the admin console to supply to the cluster.
Is there a more native Kubernetes way to package the managed server with the war in the form of a Docker image, so that when we say domain.start or cluster.start it automatically fires up the Pod as a Weblogic Managed Server with the war already contained in the image.

I think you can customize your domain creation kubernetes/internal/create-weblogic-domain-job-template.yaml as per your requirements

@tusharmahale  : Is there an example that I can refer ?

Yas


Keyword Documentation links point to old imap library

The Keyword Documentation links all point to the old imap library. I get that the keywords may be the same, but the version information is different.

Readme has link to https://lasselindqvist.github.io/robotframework-imaplibrary2/doc/ImapLibrary.html but I might have missed other links. Any PRs are welcome.

Those that I found have been fixed.


[3.x] Hide last DirectionalLight shadow split distance property when using PSSM 3 Splits

The last shadow split property only has an effect when using PSSM 4 Splits.
I noticed this while testing https://github.com/godotengine/godot/pull/99536 :slightly_smiling_face:
Preview
https://github.com/user-attachments/assets/a6d1905c-7bc9-4e51-be11-423e3fe6bddc

Thanks!


Action Menu

Putting this into review although there are still a few outstanding items that need some attention - it should be ready to start getting eyes on it.
This component uses the ActionList as a base to create an accessible and customizable dropdown menu.

Fixes #1069

Not sure why vercel is failing - I don't have access to check the logs.

I noticed some interesting resize behavior when the action menu is open. Is this expected?
https://user-images.githubusercontent.com/4608155/114942145-f69f0900-9df8-11eb-89cb-b3cb84fcf30f.mp4

I noticed some interesting resize behavior when the action menu is open. Is this expected?
CleanShot.2021-04-15.at.14.42.13.mp4

Good catch, Captured in https://github.com/primer/components/issues/1169!

Is this difference in spacing between the right and the left intentional?

Is this difference in spacing between the right and the left intentional?

Not intentional, just didn't notice it. I knocked out the right margin for the trailingVisualContainer, and I think this looks pretty even now:


Base64 data seems to be different for the same file between IOS and Android

What I notice is that on android the base64 data length is larger than one with IOS for the same file. Also for android data base64decode fails while it looks fine on IOS. Is there any difference on the base64 generation logic between the two or am I missing something?

had to change Base64.encodeToString(bytes, Base64.DEFAULT) to Base64.encodeToString(bytes, Base64.NOWRAP); in my case otherwise server side decode was failing.

Thanks. I fixed this with 29ea3b2f1ed9fbfff705774a19c33be683a43982


Describe peer discovery in ADR

Number 003 is selected, because 002 is proposed in #29.

Thanks for comments and suggestions. Everything is addressed, please re-review.


Domestic and Local Movers Packers in Dubai

Some of our customers want to move within the city or country while others want to relocate their office to a foreign location. Irrespective of your requirement, we can provide you with solutions that will meeting your supplies. Our Movers and Packers Dubai handle each local move professionally and reliably. Also, we also offer unresolved moving services.

U got the wrong place to spread ad contents


How to remove NavigationBar space in menu?

Are you sure it is a navigation bar. You have section in your table view...

I'm not sure it is a navigation bar.
UIView above TableView, I pick UIView and drop on top TableView. It's use Static Cells

Try to delete Table View section

What does the UIView contains?


Update MD file on new branch 2017-11-18_23-29-17

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

split/content1.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Stop DeSoMiner When Block Height is Past PoS Cutover

Current dependencies on/for this PR:

feature/pos-syncing-and-steady-state

PR #993   👈

PR #994

This stack of pull requests is managed by Graphite.

Merge activity

Feb 1, 5:43 PM EST: @tholonious started a stack merge that includes this pull request via Graphite.


Node_type_id is not required when instance_pool_id is given

The documentation states that the node_type_id is required, however, only one of node_type_id or instance_pool_id is required. Maybe this can be better documented as now it seems that the node_type_id should always be given for the request to succeed which is not the case when the instance_pool_id is given.

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

ID: 5e5705b9-3ec2-f680-3238-acc4ab646b52
Version Independent ID: 5d6b6e4c-efa9-bc3d-e76e-8f104f3e887c
Content: Clusters API - Azure Databricks - Workspace
Content Source: databricks/dev-tools/api/latest/clusters.md
Service: azure-databricks
GitHub Login: @mssaperla
Microsoft Alias: saperla

@lmicverm Thanks for the feedback !  I have assigned this issue to content author to investigate and update the document as appropriate.

Thanks for your dedication to our documentation. Unfortunately, we have been unable to address your issue and apologize for the delayed response. We are closing this issue, but if you feel that it's still a concern, please let us know directly at<EMAIL_ADDRESS>#please-close

#please-close


Atai/0724/athena fix

Fix athena's error by making useCopilotChat's functions state-abuse-proof

@ataibarkai What do we do with this one?

@mme did the fix make it into our release any other way?
if not, can you please merge it in and help Cham run full QA on it
it's a realtively big fix so we definitely want to get it in sooner rather than later.
(i actually thought it was already committed in)


Translation of the navigation sorting

In the category tree, we need an A-Z sort order to display the categories. In German CH, the categories are sorted alphabetically (see attached image). If we translate the category names into FR, the order in the display (French language) is not correct. Is there a way to display the A-Z menu correctly in French?

[public] Thank you for your report. We have concluded, that the behaviour you describe does not meet the criteria for a bug and instead consider this suggestion to be an improvement. Please note that Github Issues is for bug reports only. Therefore, we have decided to close this issue and ask you to submit your idea to our Shopware Feedback & Ideas portal: https://feedback.shopware.com/forums/942607-shopware-6-product-feedback-ideas
[created from NEXT-39370, comment 508995]


Read timeouts

Every once in a while, a search never returns.  It hangs, seemingly forever, until I have to kill my process and start over.
Is there a way to set a timeout value that can be passed along to the underlying requests object?

I had the same problem, at the end the problems was that I had a very high ping towards Spotify endpoint, and Spotify wasn't replying, it's weird, but that's how I solved. Try with a VPS with low ping to api.spotify.com

Thanks for the feedback (again).  I'm running my app from my house, and don't have any intention of hosting it somewhere else.
Seems like the spotipy API could simply put a timeout on the 'requests' call and return if no reply comes back in sufficient time.

I know, but that's not how it works right now, I guess they are not interested in very small project, I tried contacting them but they didn't told my why

I have created a fork and added a new option requests_timeout
https://github.com/alexey-v-paramonov/spotipy
So you can add a timeout on Spotipy initialization like this:
spotify = spotipy.Spotify(requests_timeout=10)
After that all Spotify requests will have that timeout.

#125


document optimization

I was just poking around learning about how Twine works and was implemented. Ending up focusing on this part a bit. I think a comment is worth it here to distinguish this as perf based choice rather than a logic one.
@pushrax @qq99

nitpick: change your commit message to reflect that it's adding a comment, rather than optimizing something :P

done!

Thanks!


score meaning is not right in document

Describe the bug
A clear and concise description of what the bug is.
Reproduction steps
From https://github.com/ossf/scorecard#scoring

I think the above info is not right, as higher values means less risk, so 10 means no risk
Expected behavior
A clear and concise description of what you expected to happen.
Additional context
Add any other context about the problem here.

Should not it be as following?

“Critical” risk checks are weighted at 0
“High” risk checks are weighted at 2.5
“Medium” risk checks are weighted at 5
“Low” risk checks are weighted at 7.5

This is the score that I get from open-telemetry:
% docker run -e GITHUB_AUTH_TOKEN=$GITHUB_AUTH_TOKEN gcr.io/openssf/scorecard:stable --repo=https://github.com/open-telemetry/opentelemetry-collector --format=json | jq .
{
  "date": "2022-07-12",
  "repo": {
    "name": "github.com/open-telemetry/opentelemetry-collector",
    "commit": "6133c820fd50d66585cec422738d116a9a22bad8"
  },
  "scorecard": {
    "version": "v4.4.0-11-g48291a3",
    "commit": "48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e"
  },
  "score": 6.6,
  "checks": [
    {
      "details": null,
      "score": 10,
      "reason": "no binaries found in the repo",
      "name": "Binary-Artifacts",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#binary-artifacts",
        "short": "Determines if the project has generated executable (binary) artifacts in the source repository."
      }
    },
    {
      "details": null,
      "score": 8,
      "reason": "branch protection is not maximal on development and all release branches",
      "name": "Branch-Protection",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#branch-protection",
        "short": "Determines if the default and release branches are protected with GitHub's branch protection settings."
      }
    },
    {
      "details": null,
      "score": 10,
      "reason": "30 out of 30 merged PRs checked by a CI test -- score normalized to 10",
      "name": "CI-Tests",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#ci-tests",
        "short": "Determines if the project runs tests before pull requests are merged."
      }
    },
    {
      "details": null,
      "score": 0,
      "reason": "no badge detected",
      "name": "CII-Best-Practices",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#cii-best-practices",
        "short": "Determines if the project has a CII Best Practices Badge."
      }
    },
    {
      "details": null,
      "score": 10,
      "reason": "all last 30 commits are reviewed through GitHub",
      "name": "Code-Review",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#code-review",
        "short": "Determines if the project requires code review before pull requests (aka merge requests) are merged."
      }
    },
    {
      "details": null,
      "score": 10,
      "reason": "38 different organizations found -- score normalized to 10",
      "name": "Contributors",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#contributors",
        "short": "Determines if the project has a set of contributors from multiple organizations (e.g., companies)."
      }
    },
    {
      "details": null,
      "score": 0,
      "reason": "dangerous workflow patterns detected",
      "name": "Dangerous-Workflow",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#dangerous-workflow",
        "short": "Determines if the project's GitHub Action workflows avoid dangerous patterns."
      }
    },
    {
      "details": null,
      "score": 10,
      "reason": "update tool detected",
      "name": "Dependency-Update-Tool",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#dependency-update-tool",
        "short": "Determines if the project uses a dependency update tool."
      }
    },
    {
      "details": null,
      "score": 0,
      "reason": "project is not fuzzed",
      "name": "Fuzzing",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#fuzzing",
        "short": "Determines if the project uses fuzzing."
      }
    },
    {
      "details": null,
      "score": 10,
      "reason": "license file detected",
      "name": "License",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#license",
        "short": "Determines if the project has defined a license."
      }
    },
    {
      "details": null,
      "score": 10,
      "reason": "30 commit(s) out of 30 and 26 issue activity out of 30 found in the last 90 days -- score normalized to 10",
      "name": "Maintained",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#maintained",
        "short": "Determines if the project is \"actively maintained\"."
      }
    },
    {
      "details": null,
      "score": 10,
      "reason": "publishing workflow detected",
      "name": "Packaging",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#packaging",
        "short": "Determines if the project is published as a package that others can easily download, install, easily update, and uninstall."
      }
    },
    {
      "details": null,
      "score": 7,
      "reason": "dependency not pinned by hash detected -- score normalized to 7",
      "name": "Pinned-Dependencies",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#pinned-dependencies",
        "short": "Determines if the project has declared and pinned its dependencies."
      }
    },
    {
      "details": null,
      "score": 10,
      "reason": "SAST tool is run on all commits",
      "name": "SAST",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#sast",
        "short": "Determines if the project uses static code analysis."
      }
    },
    {
      "details": null,
      "score": 10,
      "reason": "security policy file detected",
      "name": "Security-Policy",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#security-policy",
        "short": "Determines if the project has published a security policy."
      }
    },
    {
      "details": null,
      "score": 0,
      "reason": "0 out of 5 artifacts are signed -- score normalized to 0",
      "name": "Signed-Releases",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#signed-releases",
        "short": "Determines if the project cryptographically signs release artifacts."
      }
    },
    {
      "details": null,
      "score": 0,
      "reason": "non read-only tokens detected in GitHub workflows",
      "name": "Token-Permissions",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#token-permissions",
        "short": "Determines if the project's workflows follow the principle of least privilege."
      }
    },
    {
      "details": null,
      "score": 10,
      "reason": "no vulnerabilities detected",
      "name": "Vulnerabilities",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#vulnerabilities",
        "short": "Determines if the project has open, known unfixed vulnerabilities."
      }
    },
    {
      "details": null,
      "score": -1,
      "reason": "check is not supported for this request: SCORECARD_V6 is not set, not running the Webhook check",
      "name": "Webhooks",
      "documentation": {
        "url": "https://github.com/ossf/scorecard/blob/48291a3dd48a01b8c601f3f38f86f7c1f61d9e3e/docs/checks.md#webhooks",
        "short": "This check validate if the webhook defined in the repository have a token configured."
      }
    }
  ],
  "metadata": null
}

score is how well the repo performs to mitigate risks: the highest the score, the better; so the lower the risk.

@laurentsimon how about using https://github.com/ossf/scorecard/issues/2041#issuecomment-1181770383 to fix
https://github.com/ossf/scorecard#scoring


fix: 🐛 fix problem that moving the nodes in the case of multiple sele…

fix problem that moving the nodes in the case of multiple selections, resulting in the deviation of the relative positions between the multiple selected nodes
Closes: #2332

Description

Motivation and Context

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Enhancement (changes that improvement of current feature or performance)
[ ] Refactoring (changes that neither fixes a bug nor adds a feature)
[ ] Test Case (changes that add missing tests or correct existing tests)
[ ] Code style optimization (changes that do not affect the meaning of the code)
[ ] Docs (changes that only update documentation)
[ ] Chore (changes that don't modify src or test files)

Self Check before Merge

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
0

Relevant Lines:
0

💛  - Coveralls

框选有些节点  里面节点还是会乱飘

这个 PR 先关闭了。


When the user  does not have access to a GPU on Colab, render a nice message explaining the problem

Currently this error is shown:

Blocked by: review by UX team


(hacky fix?) Exclude 3.9 release from config_dev, since its already released.

This fixes #2938  for me.  I don't know if it breaks other people though.  if this causes problems, should we have a  make-master directive of some sort... or maybe update the makefile?
Description
This removes 3.9 from make_dev, since, the development branch (i think) is supposed to build master ?  Im not 100% sure this is the right thing to do, but it seemed to fix an issue i specifically was having.
If nothing else, this PR might serve as a way to jumpstart the memory of how jekyll / dev-manifests is supposed to work :), as it does seem to be laden with a few tricky knobs that are hard to doc.
Related issues/PRs
#2938
Release Note
None required

Deploy preview for calico ready!
Built with commit 30950da91f9df5ac0ac1943f9cac2ff5d7fa0730
https://deploy-preview-2944--calico.netlify.com

ok, so i think this is the solution.
I've Confirmed that the above fix creates manifests successfully on a from-scratch VM.
Digest: sha256:d00757603f7863e09946a9b4337df83447c4e9056eabd05e311bbd52f72bb72e
Status: Downloaded newer image for jekyll/jekyll:pages
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-linux-musl]
Configuration file: _config.yml
Configuration file: _config_dev.yml
Configuration file: /config_images.yml
            Source: /srv/jekyll
       Destination: /srv/jekyll/_site
 Incremental build: enabled
      Generating...

                    done in 10.884 seconds.
 Auto-regeneration: disabled. Use --watch to enable.
make[1]: Leaving directory `/calico_all/calico'
[root@node1 calico]#
[root@node1 calico]# ls _output/dev-manifests/
alp/                     calico-etcd.yaml         calico.yaml              crds.yaml
calicoctl-etcd.yaml      calico-policy-only.yaml  canal-etcd.yaml          flannel-migration/
calicoctl.yaml           calico-typha.yaml        canal.yaml               rbac/
[root@node1 calico]# ls -altrh _output/dev-manifests/canal.yaml
-rw-r--r--. 1 root root 18K Oct 16 20:27 _output/dev-manifests/canal.yaml
[root@node1 calico]# date
Wed Oct 16 20:28:22 UTC 2019

removed the (hacky fix) PR title since i think this is valid :)


Expand import targets regex examples

This PR adds an example to pick out a container name from a nested folder structure following the point raised in https://github.com/openmicroscopy/openmicroscopy/pull/4543#issuecomment-202448281
It would be worth @pwalczysko checking the workflow in this example.

Built in http://www.openmicroscopy.org/site/support/omero5.2-staging/users/cli/import-target.html

Possibly not done in this PR, but
the name discriminator should be always marked just like in https://github.com/openmicroscopy/ome-documentation/pull/1436/files#diff-809a44562994b4be41ca2b89252d0492R30.
There is no such markup in https://github.com/openmicroscopy/ome-documentation/pull/1436/files#diff-809a44562994b4be41ca2b89252d0492R83 thoiugh, which makes it more difficult to understand the text in this case.

Consider

Above confuses me here a bit. Is it the example we are/have been just doing ? Or is it the one-above example which lists, unfortunately, the same folder, but just once (i.e. not all three plates are in this folder as claimed by the sentence).

@pwalczysko the last two commit try to address your comments. Thanks.

The workflow described in the doc for Screen creation using regex works as expected (went through the week-1 & week-2 & bd-pathway example step by step).
Can have a look at the two fixes in the commits above tomorrow.

All looks fine. Ready to merge.

Apologies. I realize now my merge button hitting was premature as the code is still under review.

@sbesson the two PRs are independent. This doc fix applies to the existing code rather than anything in the code PR. It was just @pwalczysko's review that highligfhted the need for a fuller example.


Added Graphite deployment event support

Solves #46

Current coverage is 83.90% (diff: 88.33%)

Merging #48 into master will increase coverage by 0.14%

@@             master        #48   diff @@
==========================================
  Files             8          9     +1
  Lines           714        764    +50
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            598        641    +43
- Misses          116        123     +7
  Partials          0          0

Powered by Codecov. Last update 5f0c768...32c8de3

Btw, don't merge yet, still need to have a discussion on how to configure the graphite metrics name to include service name, environment or other variables


Theme support

Theme support would be nice, at least blue, light, and dark themes like in visual studio.

Yes please!

Btw, you can now have a full dark mode using the code in this gist. The search result background could be changed once my PR #372 is put inside a release.
Using a similar technique you can have any other color theme implemented as well.

How I can use a dark theme? or I should do a custom build? I want to have native support

How I can use a dark theme? or I should do a custom build? I want to have native support

any updates here? *sorry for question, but this feature is really important for me)

I found another way may help you
    DarkModeHighlightColors darkModeHighlightColors = new DarkModeHighlightColors();

    FieldInfo classificationHighlightColorsFieldInfo = editor.GetType().GetField("_classificationHighlightColors",
        BindingFlags.Instance | BindingFlags.GetField | BindingFlags.NonPublic | BindingFlags.ExactBinding);
    classificationHighlightColorsFieldInfo.SetValue(editor, darkModeHighlightColors);

    FieldInfo braceMatcherHighlighterFieldInfo = editor.GetType().GetField("_braceMatcherHighlighter",
        BindingFlags.Instance | BindingFlags.GetField | BindingFlags.NonPublic | BindingFlags.ExactBinding);
    braceMatcherHighlighterFieldInfo.SetValue(editor, new BraceMatcherHighlightRenderer(editor.TextArea.TextView, darkModeHighlightColors));

    editor.RefreshHighlighting();

@aelij  fyi, i'm toying around w/ a simple light/dark mode.
It's just a matter of where would you like the toggle icon. Up top in the DocumentView toolbar or down below next to the FontSize and Feedback icon

I could not find a way to switch to a dark mode in Roslynpad 18.
Is there already an option (config file, command line argument) to start roslynpad in dark mode?

Happy to announce RoslynPad 20 will support VS Code theme files :)
Most of the code is already in main


add logout logic

Pull Request Test Coverage Report for Build<PHONE_NUMBER>2
Details

12 of 12 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.008%) to 98.239%

Totals

Change from base Build<PHONE_NUMBER>7:
0.008%

Covered Lines:
2859

Relevant Lines:
2889

💛  - Coveralls


[WIP] Fix performance test

Signed-off-by: jwcesign<EMAIL_ADDRESS>
Changes

:bug: Fix bug

/kind bug

Fixes #

Release Note

none

Docs

none

/test performance-tests

/test performance-tests

/test performance-tests

/test performance-tests

Should we really copy these files from serving repo? how about: git clone serving repo in script, cd to right dir, run it directly to launch the cluster?
Because it needs efforts to care and sync from repo when there is updates.

Common scripts should go in https://github.com/knative/hack , which has automation to handle syncing across repos.
Do we really need copies of all the serving scripts to run these performance tests?

/test performance-tests

/test performance-tests

/test performance-tests

/test performance-tests

/test performance-tests

/test unit_tests

/test unit-tests

/test unit-tests

/test performance-tests

/test performance-tests

/test performance-tests

/test performance-tests

/test integration-tests

/test performance-tests

Now the test result is ok:  https://gcsweb.knative.dev/gcs/knative-prow/pr-logs/pull/knative-sandbox_container-freezer/185/performance-tests_container-freezer_main/1580825153942589440/artifacts/hey/
cc @psschwei

Now the output is csv, I am asking whether it has plan to support html output: https://github.com/rakyll/hey/issues/287

/test performance-tests


Cleanup Add-DbaComputerCertificate help

Fixes #
Changes proposed in this pull request:

Clean up comment-based help for Add-DbaComputerCertificate
Bring comment-based help style in line with templates

How to test this code:

[ ] Review help text
[ ]

Has been tested on minimum requirements:

[ ]  Powershell 3
[ ]  Windows 7
[ ]  SQL Server 2000

Has been tested on maximum requirements:

[ ]  SQL Server vNext
[ ]  Windows 10
[ ]  Azure Database

Tests for tester:

[X] Working/useful help content, including link to command on dbatools web site
[ ] All examples work as advertised
[ ] Does not contain template content
[ ] Does not contain excessive/unnecessary amounts of comments
[ ] Works remotely
[ ] Works locally
[ ] Works on lower versions or throws error specifying version not supported
[ ] Works with named instances
[ ] Works with clustered instances
[ ] Handles offline/read only databases
[ ] Supports multiple servers (at the command line or piped from Get-SqlRegisteredServerName)
[ ] No un-handled errors which stop the command working with multiple servers

ON a roll! Thanks, bud!


Check Axis Threshold When Detecting button_pressed

Checks axis thresholds when checking when an action is pressed. This must have gotten lost in a refactor, but it was a simple fix.
@ndarilek this should fix your issue in #218, and it fixed a similar issue I was having in my game.

Nevermind, I just realized something is up with this, because something else is wrong with the fact that input_axis_pair() shouldn't be returning a value here.

Closing in favor of a more correct fix.

There, fixed in #232