hello developer

i found issue in this app its big issue and app not work proper when set alarm and remove the app from background then alram not working.... i found this issue in your code but your previous app (new-clock-fdroid) its work properly in new-clock app its not working ple resolve this issue and update the app thks advance

Done

thks bro i asked you one thing where you changing in this projects???

The project is being updated, at the moment the problem has been solved, many things have been fixed, you can see them from the commits.  A new version will be released when it is ready.

sir i donwload you updated source code and run the project and et the alarm
set time (5 mint above of current time like current time is 10:00 am and i
set alram at 10:05 am) when i closed the app foregpound and background both
the at 10:10am time reached thent he alarm not play and alarmscreen not
show and does not play alarm i asked you did you resolve this issue ???
On Wed, 13 Mar 2024 at 23:03, qw123wh @.***> wrote:

The project is being updated, at the moment the problem has been solved,
many things have been fixed, you can see them from the commits. A new
version will be released when it is ready.
—
Reply to this email directly, view it on GitHub
https://github.com/qw123wh/new-clock/issues/38#issuecomment-1995208380,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A6EH5BZKGFOKMJ5P2J32DLDYYCIGJAVCNFSM6AAAAABELTJW4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJVGIYDQMZYGA
.
You are receiving this because you authored the thread.Message ID:
@.***>

Done

sir you chk it your app after update it... Alarm Functionality not working on open ads and background also.... chk your code and test it and tell mie bro

The error you are telling me about is only experienced by you. The version has not been released, the updated fork however is this https://github.com/BlackyHawky/Clock you need to generate an apk with android studio. You have to tell me what phone you have, Android version, I would also need a log, otherwise I can't solve it. To work correctly the app you must give all the necessary permissions such as "deactivate battery saving" and more. If you also have restrictions like on Miui, it's Xiaomi's fault.

bro i test the app at android 8 ,10, 11,12, 13 also all devices alarm not
show if the app is removed from the background... if android sdk version
above 30+ alarm not working if set it into below 30 its show alarm and
working if app is open and remove background also
On Sat, 16 Mar 2024 at 14:59, qw123wh @.***> wrote:

The error you are telling me about is only experienced by you. The version
has not been released, the updated fork however is this
https://github.com/BlackyHawky/Clock you need to generate an apk with
android studio. You have to tell me what phone you have, Android version, I
would also need a log, otherwise I can't solve it. To work correctly the
app you must give all the necessary permissions such as "deactivate battery
saving" and more. If you also have restrictions like on Miui, it's Xiaomi's
fault.
—
Reply to this email directly, view it on GitHub
https://github.com/qw123wh/new-clock/issues/38#issuecomment-2001934368,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A6EH5B7BO2YUKXY5JUQK6UDYYQJZLAVCNFSM6AAAAABELTJW4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBRHEZTIMZWHA
.
You are receiving this because you authored the thread.Message ID:
@.***>

I have already explained to you that if you do not remove the battery optimization it will not play and I have already explained to you that the app has not been released. There are other open-source clock apps try other apps. This will never work for you. Change app and don't write anymore


[Launcher] Keyboard shortcuts for buttons only works for run as admin

Using msi from commit 064d638
I tried using the keyboard shortcuts on the buttons which are mentioned (https://github.com/microsoft/PowerToys/wiki/Launcher#213-keyboard-shortcuts) but only ctrl+shift+enter works. The other buttons (see below for reference) don't behave as expected.

3
Users can copy path location when executing Ctrl+C
1

4
Users can open file location when executing Ctrl+Shift+E
1

5
Users can open selected result in console when executing Ctrl+Shift+C
1

@jyuwono.  Can you attach a screenshot or gif?   How the buttons show up is plugin specific.  I just want to determine if this a bug, or misalignment on desired behavior.   I'm not able to repro on my branch, but it could be an issue with the msi build.

Not repro anymore using MSI April 26th


Compiler error starting in v3.2.2 with non-copyable user type

Hi,
After upgrading my sol2 version from v3.2.1 to v3.2.2 I started seeing a compile error which I traced it to commit 0e1aafe4d.  It is preventing me from registering a callable whose return type is a const & to a non-copyable type (although the problem may well be more general than that).  Below I provided all of the info that you might need, but let me know if you need anything else.
Environment:

Language: C++, -std=c++20
OS: Linux/Pop!_OS 20.10
Compiler: Clang trunk as of a couple weeks ago:

    $ clang++ --version
    clang version 12.0.0 (https://github.com/llvm/llvm-project.git 6c2ad4cf8758335e0896ba0540b21bbf6d239fbd)
    Target: x86_64-unknown-linux-gnu
    Thread model: posix

Stdlib: libstdc++ from gcc 10.2.0
sol2 compiler defines:

SOL_USING_CXX_LUA=1
SOL_CXX17_FEATURES=1
SOL_ALL_SAFETIES_ON=1
SOL_EXCEPTIONS_ALWAYS_UNSAFE=1
SOL_PRINT_ERRORS=0

Standalone Reproducer
struct no_copy_type {
  no_copy_type()                      = default;
  no_copy_type( no_copy_type const& ) = delete;
  no_copy_type( no_copy_type&& )      = default;
};

struct my_callable {
  no_copy_type const& operator()() const {
    static no_copy_type o;
    return o;
  }
};

void test() {
  auto st = sol::state{};
  st["AAA"] = my_callable{};  // compile error here!!
}

This is impacting me because some of my types are movable but not copyable, and I used to be able to register callables that return const & of one of those non-copyable types but can't seem to anymore as of v3.2.2.  Am I doing something wrong?
Compiler Error
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/alloc_traits.h:514:4: error: no matching function for call to 'construct_at'
          std::construct_at(__p, std::forward<_Args>(__args)...);
          ^~~~~~~~~~~~~~~~~
../../extern/sol2/include/sol/stack_push.hpp:120:46: note: in instantiation of function template specialization 'std::allocator_traits<std::allocator<rn::lua::(anonymous namespace)::no_copy_type>>::construct<rn::lua::(anonymous namespace)::no_copy_type, const rn::lua::(anonymous namespace)::no_copy_type &>' requested here
                        std::allocator_traits<std::allocator<T>>::construct(alloc, obj, std::forward<Args>(args)...);
                                                                  ^
../../extern/sol2/include/sol/stack_push.hpp:127:11: note: in instantiation of function template specialization 'sol::stack::unqualified_pusher<sol::detail::as_value_tag<rn::lua::(anonymous namespace)::no_copy_type>, void>::push_fx<sol::stack::stack_detail::undefined_metatable &, const rn::lua::(anonymous namespace)::no_copy_type &>' requested here
                        return push_fx(L, fx, std::forward<Args>(args)...);
                               ^
../../extern/sol2/include/sol/stack_push.hpp:137:12: note: in instantiation of function template specialization 'sol::stack::unqualified_pusher<sol::detail::as_value_tag<rn::lua::(anonymous namespace)::no_copy_type>, void>::push_keyed<const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> &, const rn::lua::(anonymous namespace)::no_copy_type &>' requested here
                                return push_keyed(L, usertype_traits<T>::metatable(), std::forward<Arg>(arg), std::forward<Args>(args)...);
                                       ^
../../extern/sol2/include/sol/stack_core.hpp:919:14: note: in instantiation of function template specialization 'sol::stack::unqualified_pusher<sol::detail::as_value_tag<rn::lua::(anonymous namespace)::no_copy_type>, void>::push<const rn::lua::(anonymous namespace)::no_copy_type &>' requested here
                                return p.push(L, std::forward<Arg>(arg), std::forward<Args>(args)...);
                                         ^
../../extern/sol2/include/sol/stack_push.hpp:324:19: note: in instantiation of function template specialization 'sol::stack::push<sol::detail::as_value_tag<rn::lua::(anonymous namespace)::no_copy_type>, const rn::lua::(anonymous namespace)::no_copy_type &, void>' requested here
                                return stack::push<detail::as_value_tag<T>>(L, std::forward<Args>(args)...);
                                              ^
../../extern/sol2/include/sol/stack_core.hpp:919:14: note: (skipping 29 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all)
                                return p.push(L, std::forward<Arg>(arg), std::forward<Args>(args)...);
                                         ^
../../extern/sol2/include/sol/table_core.hpp:630:4: note: in instantiation of function template specialization 'sol::basic_table_core<true, sol::basic_reference<false>>::set<std::tuple<char const (&)[4]>, sol::function_arguments<sol::function_sig<>, rn::lua::(anonymous namespace)::my_callable>>' requested here
                        set(std::forward<Key>(key), as_function_reference(std::forward<Fx>(fx), std::forward<Args>(args)...));
                        ^
../../extern/sol2/include/sol/table_core.hpp:603:4: note: in instantiation of function template specialization 'sol::basic_table_core<true, sol::basic_reference<false>>::set_fx<rn::lua::(anonymous namespace)::my_callable, std::tuple<char const (&)[4]>, sol::meta::enable_t::_>' requested here
                        set_fx(types<>(), std::forward<Key>(key), std::forward<Args>(args)...);
                        ^
../../extern/sol2/include/sol/table_proxy.hpp:100:8: note: in instantiation of function template specialization 'sol::basic_table_core<true, sol::basic_reference<false>>::set_function<std::tuple<char const (&)[4]>, rn::lua::(anonymous namespace)::my_callable>' requested here
                        tbl.set_function(std::move(key), std::forward<Args>(args)...);
                            ^
../../extern/sol2/include/sol/table_proxy.hpp:119:29: note: in instantiation of function template specialization 'sol::table_proxy<sol::basic_table_core<true, sol::basic_reference<false>> &, std::tuple<char const (&)[4]>>::set_function<rn::lua::(anonymous namespace)::my_callable>' requested here
                                return std::move(*this).set_function(std::forward<T>(other));
                                                        ^
../../src/lua.cpp:89:16: note: in instantiation of function template specialization 'sol::table_proxy<sol::basic_table_core<true, sol::basic_reference<false>> &, std::tuple<char const (&)[4]>>::operator=<rn::lua::(anonymous namespace)::my_callable>' requested here
  st["AAA"] = my_callable{};
            ^
/usr/lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_construct.h:94:5: note: candidate template ignored: substitution failure [with _Tp = rn::lua::(anonymous namespace)::no_copy_type, _Args = <const rn::lua::(anonymous namespace)::no_copy_type &>]: call to deleted constructor of 'rn::lua::(anonymous namespace)::no_copy_type'
    construct_at(_Tp* __location, _Args&&... __args)
    ^
1 error generated.

I would have given a godbolt link, but v3.2.2 does not seem to appear there yet.

This was causing problems in another issue, where const& return types were not having the const properly stripped out before being considered a copy. Constant references are meant to used as a proxy for copying things in Lua, but we behave differently for non-const...
This is likely drilling down to the fact that we don't have a "const reference" table: everything in Lua is either a plain, non-const reference or a value. We should probably fix this.

Thanks for the response, and yes fixing would be great (how hard is it?), since it is currently blocking me from updating my sol version.

By the way -- the fact that this broke would seem to imply that there are no unit tests covering this case... perhaps sol2 needs some better unit test coverage.

Pull requests welcome.

I am happy to look into making a unit test for this -- but I think fixing it would be a bit tough since I don't have any familiarity with the code base.  Unless you think it is simple and could give me a sketch of how to do it...

This can't be fixed without breaking a fairly fundamental tenent that:
Arguments:

T& is not copied
const T& is copied
T&& is moved

Returns:

T& is not copied
const T& is copied
T&& is moved

The old behavior where const T& wasn't copied but stored in a (non-const) reference was reminiscent of a bug. The workaround is to return a pointer or a std::reference_wrapper<const T>. That means there's room here to either tweak the way return values and arguments are pushed into Lua on a more fundamental level, and let the user override the behavior appropriately. Thinking it over, it's probably best to allow:

sol_lua_push_argument, identical to the sol_lua_push extension point
sol_lua_push_return, identical to the sol_lua_push extension point

Folks could override these 2 to change the behavior. A greater change of "add a const reference table" is overkill and adds to the "too much runtime data" problem, albeit that's solved with an orthogonal feature to "pin the set of allowed operations at compile time to completely avoid issues of needing to grow or add things at runtime". So, we might just add a const & table to the already 3 internal tables we have, bringing it to 3 (value, reference, unique usertype, and the new const reference table).
The extension points are probably a better fundamental fix for this issue, that goes beyond the already-in-develop solutions of marking things as value-semantic.

Here is probably a dumb question: why does sol associate const ref return types with copying?  Shouldn't it only copy (or move) if a function returns the type by value?  What was the original reasoning for wanted to copy const ref return types?
In any case... I guess for now I will just use non-const refs for return types and deal with it.
Thanks

¯\_(ツ)_/¯
#include <string>

const std::string& jekw (const std::string& xD) {
     return xD;
}

int main () {
     const std::string* ptr = &jekw(":)");
     return otr->size();
}

(In other words, const blah& binds to temporaries which artificially extend lifetime in ways I cannot predict. blah& does not extend the lifetime of temporaries, unless you're on MSVC with their really bad extension turned on, but they've started shutting that one off by default because it's error prone and buggy in newer project builds under /Zc:conforming or whatever that compiler flag was supposed to be.)

Right, but do you think we could say something like, generally in C++, a function should not return a reference unless it is sure that it is not referring to a temporary.  In other words, the above example would seem to be more the fault of the person who wrote jekw and not sol.  I think that the API of sol should not be designed to try to prevent people from making dangling-ref bugs in their code, otherwise it will limit support for the proper use cases of returning const&, such as my own use case which is to return const& to entities stored in global state which are not temporaries.
Is this something that we can/should change with sol?  I know that it might break backward compatibility, but it seems like the right thing to do if I understand correctly what's going on here.

This is, unfortunately, not how people write code in the wild and not how legacy code behaves. People have been returning const whatever& values and taking const whatever& values to "save space" and "only materialize temporaries when necessary". sol2 can't assume the benefit of the doubt that someone will do it properly because it ultimately puts it into a system which does not -- and cannot -- play by C++'s rules for statically evaluated programs. It goes into a runtime system, there is no lifetime extension detection I can do to figure out when the compiler's made the call to extend lifetime, so I have 2 choices:

let everyone's code crash when they (inevitably) make this mistake (a higher chance when dealing with C++03 and before-times code)
let everyone's code compile and run without issue, at the cost of others with pure, correct code requiring markup

Compilers warn on more direct examples but protracted ones still break, without warning. These bugs would be hard to find and hard to track down because the nature of their brokenness means they go into the Lua system and would demand quite the suite of runtime tools to catch. (Or just a lucky break with AddressSanitizer and UBSanitizer.)

I hear you.  I guess a counter could be that, if sol is "silently" copying types that are returned by const&, that could introduce bugs as well, where a user thinks they're operating on the "original" object in Lua when they are in fact just using a copy.
It sounds like for the time being I will just have to return non-const refs in my code.  But thanks for your prompt responses, I appreciate it.
P.S. when are we getting your Unicode stuff in C++?

Still working on this.
P.S.: Unicode stuff is coming. We had some wins in the C Committee - https://soasis.org/posts/planted-seeds-unicode-c-c++-2021/

So I've spent some time on this trying to think about making a const table that propagate const-ness so you can have it work in Lua and get errors when you call functions on logically and morally const data. And, unfortunately,
it just doesn't work.
It's easy to detect for const member functions or similar: we just strip them from the const metatables in Lua and have a const-only version of the metatables (sol2 already has 3 versions of the metatable: self-destructing values, non-owning references, and unique usertype-style).
The problem gets more interesting (read: more annoying) when you start doing things like this:
sol::state lua;
lua["f"] = [] (int count, std::string& value) {
     // ...
};

static const std::string my_string = "hi";
lua["f"](1, std::cref(my_string)); // Uh???

What am I supposed to do here? Using std::cref produces a std::reference_wrapper<const std::string>. Am I supposed to blow up the code for lua["f"] and error? That implies that not only am I type checking, but I'm not qualifier checking. This gets more interesting when you throw in other qualifiers:

& and && reference qualifiers for member functions
const
volatile

The approach of "checking if the qualifiers match and performing C++-style resolution for each argument" is bad enough; doing it to also make things like sol::overload(...) choose the best overload is just asking for not only a HUGE performance drag but also a sincere problem in the whole system. The reality of the matter is that C++ only enforces const through its optimizer and through its compile-time, because that's the only sane time to enforce such constraints (alongside volatile and other qualifiers). Doing it at runtime is a bonkers task, and by saying "well if you bind const stuff it should track that and treat it like it, including const references" in the system, you're opening that same pandora's box.
So, unfortunately, I can't really implement this one. I think we'll just have to stay with the copies, and in the new docs make sure it's noted pretty clearly what happens with arguments vs. returns vs. function calls.

So I've spent some time on this trying to think about making a const table that propagate const-ness so you can have it work in Lua and get errors when you call functions on logically and morally const data. And, unfortunately,
it just doesn't work.
It's easy to detect for const member functions or similar: we just strip them from the const metatables in Lua and have a const-only version of the metatables (sol2 already has 3 versions of the metatable: self-destructing values, non-owning references, and unique usertype-style).
The problem gets more interesting (read: more annoying) when you start doing things like this:
sol::state lua;
lua["f"] = [] (int count, std::string& value) {
     // ...
};

static const std::string my_string = "hi";
lua["f"](1, std::cref(my_string)); // Uh???

What am I supposed to do here? Using std::cref produces a std::reference_wrapper<const std::string>. Am I supposed to blow up the code for lua["f"] and error? That implies that not only am I type checking, but I'm not qualifier checking. This gets more interesting when you throw in other qualifiers:

& and && reference qualifiers for member functions
const
volatile

The approach of "checking if the qualifiers match and performing C++-style resolution for each argument" is bad enough; doing it to also make things like sol::overload(...) choose the best overload is just asking for not only a HUGE performance drag but also a sincere problem in the whole system. The reality of the matter is that C++ only enforces const through its optimizer and through its compile-time, because that's the only sane time to enforce such constraints (alongside volatile and other qualifiers). Doing it at runtime is a bonkers task, and by saying "well if you bind const stuff it should track that and treat it like it, including const references" in the system, you're opening that same pandora's box.
So, unfortunately, I can't really implement this one. I think we'll just have to stay with the copies, and in the new docs make sure it's noted pretty clearly what happens with arguments vs. returns vs. function calls.

@ThePhD Thanks for taking a detailed look at this.  Given that it looks like things need to stay the way they are, I am wondering if you could just confirm my understanding so that I can better use the sol2 API:

When a C++ function returns a const & to Lua, the value will be copied.
When a C++ function accepts a const & parameter from Lua, it will be copied and the const & as seen from the C++ function will refer to a temporary.

Are those correct?  (second one seems unlikely, but just making sure)
And one other thing as a last attempt to make something work: I noticed above in your analysis that you are consider function parameters.  For my use case I happen to only be concerned with const & return types from C++ functions into Lua; the semantics of function parameters are working fine for me as they are.  So therefore, would it make it any easier to address this issue only for const & return types, leaving the behavior for function parameters as-is?  Thanks

@ThePhD Thanks for taking a detailed look at this.  Given that it looks like things need to stay the way they are, I am wondering if you could just confirm my understanding so that I can better use the sol2 API:

When a C++ function returns a const & to Lua, the value will be copied.
When a C++ function accepts a const & parameter from Lua, it will be copied and the const & as seen from the C++ function will refer to a temporary.

Are those correct?  (second one seems unlikely, but just making sure)
And one other thing as a last attempt to make something work: I noticed above in your analysis that you are consider function parameters.  For my use case I happen to only be concerned with const & return types from C++ functions into Lua; the semantics of function parameters are working fine for me as they are.  So therefore, would it make it any easier to address this issue only for const & return types, leaving the behavior for function parameters as-is?  Thanks


Crashing with Access violation

I have been running program with 0.1.6-Alpha2 for a few days without issues, and today I have updated nuget package to 0.1.6 stable and after changing folder a few times the program just exists with 'Access violation'

The program 'X.exe' has exited with code -1073741819 (0xc0000005) 'Access violation'.

There is no breakpoint, program just closes in debugging mode so I don't know where it breaks, and no stack trace.
I restored previous project version, it ran without issues, and again, right after the nuget update I'd start getting this program crashes with the same message.
Not sure if it is relevant, but what I am doing differently than your examples is that I am monitoring each folder individually wihout recursion, so I am monitoring the same folder with two watchers (two user controls that handle their own folder content listing and monitor). Can that be an issue, or is there something else?
One of the updates before the 0.1.6-alpha2 had the same issue, but then I was not sure that directorywatcher was causing it so I did not report.

Update: It crashes even when I disable watcher in the second panel. So there are no two watchers that monitor the same directory.

Update2: It crashes on watcher.Stop();. I have placed the breakpoint on watcher.Stop(); and I change folder which calls Stop();, press F10 to stop over, and F5 to continue. After 3-6 times repeating this it will crash after stepping over that line.

Hi,
Can you please try
update-package MyOddWeb.DirectoryWatcher -Version 0.1.7-alpha1
I think it addresses the crash issue although I have not been able to reproduce the exact same scenario.
Thanks

I think this was fixed in 0.1.7, as mentioned, very hard to test without a proper sample.


version of mwc-tab published on npm does not tally with released commits

Not sure what is happening here but the version I get with npm i @material/mwc-tab does not seem to be in sync with commits listed here: https://github.com/material-components/material-components-web-components/compare/v0.13.0...master
For instance changes under https://github.com/material-components/material-components-web-components/commit/85c6a4239d2c76e1f536b578611657a011a5c856  are not effective in the distributed files (e.g. mwc-tab-css.js still uses deprecated --mdc-tab-text-transform, supposedly new --mdc-typography-button-text-transform has no effect).

The typography variables have not been released yet. Are all the features you're missing part of the Unreleased section of the changelog?

Ooups, sorry you are right.
Misinterpreted the following, thinking the 70 commits were part of v0.13.0 ...


Add a closing method with timeout for JDBC connection

Why are the changes needed?

add the method in KyuubiConnection for forcibly closing the connection with timeout

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

Codecov Report

Merging #5111 (1043350) into master (998b5d5) will not change coverage.
Report is 1 commits behind head on master.
The diff coverage is 0.00%.

@@          Coverage Diff           @@
##           master   #5111   +/-   ##
======================================
  Coverage    0.00%   0.00%
======================================
  Files         564     564
  Lines       31293   31313   +20
  Branches     4095    4096    +1
======================================
- Misses      31293   31313   +20

Files Changed
Coverage Δ

.../org/apache/kyuubi/jdbc/hive/KyuubiConnection.java
0.00% <0.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

cc @jeanlyn


case 1; end should be rejected

A case clause with no when clause must be rejected.
$ ./local/bin/irb -ryarp
irb(main):001> RubyVM::AbstractSyntaxTree.parse("case 1; end")
<internal:ast>:59:in `parse': syntax error, unexpected `end', expecting `when' (SyntaxError)
case 1; end
        ^~~

        from (irb):1:in `<main>'
        from <internal:kernel>:187:in `loop'
        from /home/mame/work/ruby/local/lib/ruby/gems/3.3.0+0/gems/irb-1.8.1/exe/irb:9:in `<top (required)>'
        from ./local/bin/irb:25:in `load'
        from ./local/bin/irb:25:in `<main>'
irb(main):002> YARP.parse("case 1; end")
=>
#<YARP::ParseResult:0x00007fbe4a1037a8
 @comments=[],
 @errors=[],
 @source=#<YARP::Source:0x00007fbe49f2d7d0 @offsets=[0], @source="case 1; end">,
 @value=
  @ ProgramNode (location: (0...11))
├── locals: []
└── statements:
    @ StatementsNode (location: (0...11))
    └── body: (length: 1)
        └── @ CaseNode (location: (0...11))
            ├── predicate:
            │   @ IntegerNode (location: (5...6))
            │   └── flags: decimal
            ├── conditions: (length: 0)
            ├── consequent: ∅
            ├── case_keyword_loc: (0...4) = "case"
            └── end_keyword_loc: (8...11) = "end",
 @warnings=[]>

Similarly, this is accepted by YARP but not by MRI:
case 1
else
  2
end


fixes for #2863 and #2793

The PR has fixes for:

#2793, custom class to be added for scroll filler of expandable grid.
#2793, Last few subgrids in expandable grid don't align with their "+" icon.

Also, today I added to PR fix for:
3. #2945, broken test cases of move column functionality.

Thanks @jpuri.


Gradle fails with Duplicate Classes error when using Firebase Cloud Messaging and sceneform:core in mainTemplate.gradle

[REQUIRED] Please fill in the following fields:

Unity editor version: 2019.4.21
Firebase Unity SDK version: 7.1.0
Source you installed the SDK: Unity Package Manager
Problematic Firebase Component: Cloud Messaging
Other Firebase Components in use: App (Core), Crashlytics, Analytics
Additional SDKs you are using: Third party remote assistance library (as .AAR + dependencies in mainTemplate.gradle)
Platform you are using the Unity editor on: Windows
Platform you are targeting: iOS and Android
Scripting Runtime: IL2CPP

[REQUIRED] Please describe the issue here:
When using the Firebase Cloud Messaging (through the Unity Package Manager), having a custom mainTemplate.gradle where a third party dependencies to com.google.ar.sceneform:core is specified (implementation "com.google.ar.sceneform:core:1.17.1"), the build process fails during "Building GRadle project" phase with the following errors:
java.lang.RuntimeException: java.lang.RuntimeException: Duplicate class com.google.flatbuffers.Constants found in modules classes.jar (com.google.ar.sceneform:sceneform-base:1.17.1) and classes.jar (com.google.firebase:firebase-messaging-unity:7.1.0)
Duplicate class com.google.flatbuffers.FlatBufferBuilder found in modules classes.jar (com.google.ar.sceneform:sceneform-base:1.17.1) and classes.jar (com.google.firebase:firebase-messaging-unity:7.1.0)
Duplicate class com.google.flatbuffers.FlatBufferBuilder$ByteBufferFactory found in modules classes.jar (com.google.ar.sceneform:sceneform-base:1.17.1) and classes.jar (com.google.firebase:firebase-messaging-unity:7.1.0)
Duplicate class com.google.flatbuffers.FlatBufferBuilder$HeapByteBufferFactory found in modules classes.jar (com.google.ar.sceneform:sceneform-base:1.17.1) and classes.jar (com.google.firebase:firebase-messaging-unity:7.1.0)
Duplicate class com.google.flatbuffers.Struct found in modules classes.jar (com.google.ar.sceneform:sceneform-base:1.17.1) and classes.jar (com.google.firebase:firebase-messaging-unity:7.1.0)
Duplicate class com.google.flatbuffers.Table found in modules classes.jar (com.google.ar.sceneform:sceneform-base:1.17.1) and classes.jar (com.google.firebase:firebase-messaging-unity:7.1.0)
Duplicate class com.google.flatbuffers.Utf8 found in modules classes.jar (com.google.ar.sceneform:sceneform-base:1.17.1) and classes.jar (com.google.firebase:firebase-messaging-unity:7.1.0)
Duplicate class com.google.flatbuffers.Utf8Safe found in modules classes.jar (com.google.ar.sceneform:sceneform-base:1.17.1) and classes.jar (com.google.firebase:firebase-messaging-unity:7.1.0)

This does not happen in a native Android Studio project (no Unity involved), where the app.gradle dependencies are as follows:
implementation "com.google.ar.sceneform:core:1.17.1"
implementation platform('com.google.firebase:firebase-bom:26.6.0')
implementation 'com.google.firebase:firebase-messaging'

Steps to reproduce:

Clone https://github.com/Vangaorth/UnityFCMDuplicateClasses, switch to Android Platform, build an APK

Or

Create a new Unity Android project, add the Firebase Cloud Messaging (7.1.0) using the Unity Package Manager (when asked from the External Dependency Manager, specify "Enable")
In Player Settings -> Publishing Settings, specifiy that you want to use a custom mainTemplate.gradle
Add "implementation "com.google.ar.sceneform:core:1.17.1" to the dependencies of mainTemplate.gradle
Build an APK

Thank you for providing details and clear steps for reproduction. I can see this error in Unity 2020 and Firebase Unity plugins 7.1.0. Filing this as a bug.


Compatibility Issue with Next.js

While importing PinoWebpackPlugin in Next.config.js, next.js always shows the message for not having CommonJsRequireDependency.
When I push PinoWebpackPlugin into array of plugins by this clause where currDir is simply a variable for __dirname
config.plugins.push(new PinoWebpackPlugin({transports: [`${currDir}/src/modules/logger/transport.mjs`]}));

The error for dependency always occurs, regardless of my TS-baed project, or new JS-based project created by create-next-app. next build always fail, and dev-server throws error for it.
The message below is shown by error page:
Failed to compile
./node_modules/pino/browser.js
No template for dependency: CommonJsRequireDependency

The message below is shown by terminal running server:
No template for dependency: CommonJsRequireDependency
{"level":30,"time":1673234383826,"pid":23900,"hostname":"<MyDevice>.local","msg":"info logger"} # this is the log I've created
Could not find files for / in .next/build-manifest.json
Could not find files for / in .next/build-manifest.json
<w> [webpack.cache.PackFileCacheStrategy] Skipped not serializable cache item 'Compilation/modules|javascript/dynamic|/Users/user/workspace/project/test/next-test/node_modules/pino/browser.js': No serializer registered for CommonJsRequireDependency
<w> while serializing webpack/lib/cache/PackFileCacheStrategy.PackContentItems -> webpack/lib/NormalModule -> Array { 3 items } -> CommonJsRequireDependency

I've searched for the CommonJsRequireDependency error cases and haven't found any clue for it. If further information is needed, let me know by leaving a comment for that.

@ShogunPanda wdyt?

https://github.com/GodDrinkTeJAVA/pino-webpack-test
This is a simple example project made from create-next-app. In modules/logger.ts, Pino constructor actually has no transport property, and only adding PinoWebpackPlugin to plugin arrays from next.config.js causes the error.
If any of my implementation is broken, I would appreciate a lot for letting me notified.

I tried cloning your repo and then run next build or next dev and never got any issue.
Have you tried deleting node_modules files and any lockfile, reinstall from scratch and build with Next again?

I've checked out the commit and you were right. I'll check more conditions and re-comment when the problem is correctly found.
Oh.. and.. could you tell me which directory should be given to transport.target when target is js file? I supposed it be moved to the root so it would be like '__dirname/{filename}' no matter where the file is. Would this be right?

I'm not sure I understand the question. Can you please clarify?

@mcollina I think you have more knowledge in this. Can you help?

https://github.com/GodDrinkTeJAVA/pino-webpack-test
Also, I found the way to reproduce the error. Now main branch shows error when npm build.
Commenting out lines which push PinoWebpackPlugin will fix the error, but when included back, it gives 'No template for dependency: CommonJsRequireDependency' error again.

Sorry about the somewhat off topic comment but I fail to understand what benefit using this would bring to a Next.js app? We're currently using Pino 7 with Next.js like any other library and everything seems to work as expected.

Sorry about the somewhat off topic comment but I fail to understand what benefit using this would bring to a Next.js app? We're currently using Pino 7 with Next.js like any other library and everything seems to work as expected.

This plugin allows you to use transports in a bundled server component. Not something that I would recommend, but it seems people are really interested in doing it.

Has anyone here found a way forward for using Next.js with Pino transports? I've searched everywhere and come to no conclusion. #109 is the exact same issue as me and has received no attention from the PinoJS community in months.
What do Next.js developers do, as there doesn't seem to be any other great logging libraries out there...

https://github.com/pinojs/pino-webpack-plugin/issues/109 is the exact same issue as me and has received no attention from the PinoJS community in months.

Pull Requests are welcomed, especially for bugs like this.
Unfortunately it does not help that none of us are using Next.js :(.

Hopefully the below helps in some following work on this, as I could not fix this problem.

When next compiles it runs webpack with 2 targets: web and node. For node the pino module is pulled but for web it substitutes it with ./browser.js (as indicated in the pinos package.json in the browser prop). This means that if we include logger.info("asdf") as part of the client code the webpack will try and pull in the ./browser.js. And this somehow conflicts with this plugin.

I am not 100% sure what we are trying to achieve here, by using the same logger configuration on both client and server, but there are some bullet points worth mentioning:

pino itself exposes browser compatible api that can be used to log on the client - this however means we need to use it differently than on the server see https://github.com/pinojs/pino/blob/master/docs/browser.md

not all transport plugins will work on the client - as some of them might use only node side modules

even though we include transports in the plugin configuration - we still need to configure the logger with them to work, so something like this might be necessary. Also the __dirname will be resolved to the path in the .next build folder - I think

import pino from "pino";

const logger = pino({
  transport: {
    target: `${__dirname}/modules/logger/transport.mjs`,
  },
});

export default logger;

Hope this helps for further investigation.

Sorry about the somewhat off topic comment but I fail to understand what benefit using this would bring to a Next.js app? We're currently using Pino 7 with Next.js like any other library and everything seems to work as expected.

This plugin allows you to use transports in a bundled server component. Not something that I would recommend, but it seems people are really interested in doing it.

Hi mcollina. Without transports it is not possible to save the log to a file or push the log to an external SaaS log tracker. WIthout transports, in Next.js, pino can only be used without transport, or with pino-pretty if it is passed in as a stream. In other words, without bundling the worker etc, it is not possible to use pino in a meaningful way in Next.js 14 apps.
Am I missing something, or would you agree?

Sorry about the somewhat off topic comment but I fail to understand what benefit using this would bring to a Next.js app? We're currently using Pino 7 with Next.js like any other library and everything seems to work as expected.

Are you doing it with transports? It does not work on my end in Next.js 14. Without transports, pino becomes a lot less useful (i.e. only console printing).


Template Update for EBSD Data Collection

Scan size should allow for 2 dimensions, height and width (for example: 500 x 1200 µm).  Right now "scan size" only accepts a single numerical value.
We should also include something in the template that notes orientation. For example, someone looking at a rolled sheet would want to note whether the rolling direction is vertical, horizontal, or if they just stuck it in willy nilly.
I think we'd want text fields that prompt:
horizontal direction:
vertical direction:
So for one of my scans I might use:
horizontal direction: short transverse
vertical direction: long transverse
There are a lot of fields in this template I don't think are necessary (current, sample tilt, magnification, acquisition time...); however, I'm assuming someone did at one point so we can leave them there until we get more feedback.

Added requested fields for horizontal and vertical direction. Due to limited types I broke scan size into two attributes: Scan Size Height and Scan Size Width. This required adding a conversion for existing scan size properties.