text:
module restructuring proposal

The module structure of leptos is almost completely flat, making it hard to find certain items or add documentation about groups of items. I discussed this briefly in https://github.com/leptos-rs/leptos/issues/2007#issuecomment-1807411843
I suggest we restructure the modules such that there are clearer sections (e.g. reactive, dom, async, components etc.. get their own module), and switch to using a prelude for common imports (use leptos::prelude::*; over use leptos::*;)
Restructuring the modules is obviously a major breaking change, and would probably also cause a lot of merge conflicts with existing PRs too. Maybe this change could be done right before 0.6, when there are probably fewer ongoing PRs and all the changes can be made at once. For the majority of users, the only changes should be changing use leptos::*; to use leptos::prelude::*;, and maybe a few more imports for more uncommon items not included in the new prelude.
Below is my idea for a potential restructure; please add your own suggestions/feedback too! hopefully the half made-up syntax makes sense. I didn't include every single module / crate, only the most commonly used ones
crate leptos_reactive {
    // move `Callback` to `leptos` instead? it's not used anywhere internally,
    // just a helper type, not really reactive either.

    // make these `pub mod` instead of re-exporting at crate root
    pub mod hydration { ... }
    // renamed from `runtime`
    pub mod runtime_primitives { ... }
    pub mod macros { ... }

    pub mod reactive {
        // traits are accessible in `crate::reactive::*` or `crate::reactive::traits::*`
        pub mod traits { SignalGet, SignalDispose, SignalWith, IntoSignal, etc... }
        pub use traits::*;

        pub mod primitives {
            // move these files from old modules over here
            crate::{diagnostics, trigger, node}
        }

        signals, Memo, Effect, watch, slices, selector, MaybeSignal, MaybeProp, TextProp
        // should `batch`, `on_cleanup`, `untrack`, `untrack_with_diagnostics`
        // be moved from `crate::runtime` to here?
    }

    // better name? anything that is stored in the runtime but not reactive
    pub mod stores {
        context, StoredValue
    }

    // does this need to be its own module, or is `crate::Oco` fine?
    pub mod oco { Oco }

    // rename this? i don't like the look of the trailing _
    pub mod async_ {
        // not sure where `queue_microtask` should go, not exactly async but
        // it's mainly used in Resources
        Resource, SuspenseContext, spawn_local, queue_microtask
    }

    pub mod prelude { ... }
}

// rename the folder `router` to `leptos_router`
crate leptos_router {
    // module tree looks fine: make everything `pub mod` and re-export in `prelude` instead.
}

crate leptos_dom {
    // modules look fine, but maybe move the stuff in `lib.rs` to separate file(s)
    // does this need a prelude?
}

// rename the folder `meta` to `leptos_meta`, otherwise looks fine, no need for a proper module tree
// should this have a prelude?
crate leptos_meta;

// i don't really use server functions much so I'm not sure what's used commonly/uncommonly
// seems like some of the stuff in `lib.rs` could be moved to a separate file though.
crate server_fn;

crate leptos {
    // re-export
    pub use leptos_reactive::*;
    // most of the `leptos_dom` re-exports should be moved to prelude
    pub use leptos_dom as dom;
    pub use leptos_macro as macros;

    // additional_attributes is deprecated, could remove in 0.6?

    pub mod components {
        Await, AnimatedShow, Show, Transition, Suspense, Provider, Portal, For, ErrorBoundary
    }

    #[doc(hidden)]
    pub mod component_builder {
        // all the stuff in lib.rs (except type AttributeValue)
        // could also move crate::children::ToChildren here
    }

    // move `crate::children::Children*` types here? remove `children.rs`

    // any other helpful types / structs
    pub mod helpers {
        ViewFn, Callback // (Callback moved from leptos_reactive)
        // maybe also `pub use leptos_reactive::reactive::{MaybeProp, TextProp}`
    }

    pub mod prelude { ... }

    // what does leptos_config do? no clue what to do with that.
}

This restructure would then make it a lot easier to add module documentation to provide higher-level overviews and improve the discoverability of features.
An alternative to this would just be adding all of this documentation in the leptos book instead, but that may make the book too large and it's easier to quickly read through docs within the IDE instead of the book.

For now I'll just say that switching to a prelude and restructuring exports/modules is very much on my agenda for 0.6, and I'm very open to thoughts on the most ergonomic way for that to be structured. Thanks for thinking through this. The ability to add module-level docs is great too.

@gbj I've had a look through rustdoc to see the new module structure, and I'm really liking it so far! I have some thoughts, though these are very opinionated and minor, so feel free to disagree with many of them :)
In no particular order (numbered to make it easy to reference):

leptos::attr::Attribute::hydrate<const FROM_SERVER: bool> - the const generic here could be an enum instead, to make it clearer what FROM_SERVER = false means (does it mean it's from the client?)
Items in leptos::context are suffixed with _context - maybe it could be nicer to use a qualified path instead? Similar to the std mpsc::channel, these could also be used as context::provide(), context::get() (renamed from use_context() since use is a keyword).

It looks like expect_context() is missing (rename to context::expect()?)
leptos::mount is similar, rename to mount::{to_element, to_body, to_renderer} (maybe remove to_ as well?).
If these changes are made, the prelude should probably just export mount and context instead of mount::* and context::*.

Should the leptos provided components (Show, For, Suspense, etc) be in modules based on its purpose (current), or just one big components module? Not sure which is better.
Is it possible to only export components but without their *Props struct too? view! doesn't need them to be public, and you could maybe add something to make it easy to build using builder pattern like Suspense::builder() instead of leptos::component::component_props_builder(Suspense).
Rename leptos::spawn to leptos::task

tick() isn't really related to spawning futures, slightly more related to tasks ig

Docs are missing for this function

Could add queue_microtask into here as well?
the qualified path task::spawn() sounds nice :)

Rename long re-exported crate names leptos_dom -> dom, reactive_graph -> reactive?

Does leptos_dom actually need to be completely re-exported? The macros are already exported in leptos::logging, and leptos_dom::logging isn't really necessary with the macros. Perhaps pub use leptos_dom::helpers as dom; instead?

Does tachys need to be completely re-exported (in both leptos::tachys and leptos::prelude::tachys)? It seems like most of its contents are already re-exported individually.

Why is re-exporting tachys::html::event as ev marked as #[doc(no_inline)]?
The crate re-exports should be marked as #[doc(inline)] so that it can be searched. It looks like re-exported crates are just shown under the re-exports section and they don't show up when searching, while inlined/module re-exports show it as if it's part of leptos.

It seems like many functions are re-exported in the prelude but nowhere else. This might also be because many crates are re-exported and their inner items don't show up when searched, so it looks like it's only available in the prelude.

There are a lot of things in the prelude, many of which seem to be very niche. Since the modules are a better organised now, it might not be necessary to re-export so many things; just import them when we need it.

Rename the EitherOf* enums to just Either*?
Why are Either*Future variants in the form A { inner: T } instead of A(T), like Either* are?
Rename the Writable trait to Write to match the Read trait (and general Rust conventions).
unwrap_signal! looks like it should be an internal thing (blanket re-exported from leptos::reactive_graph::unwrap_signal, should probably be internal within reactive_graph too).
Re-exporting reactive_graph::untrack at the root seems odd, there's no other functions that are re-exported at the root of this crate. Maybe reactive_graph::signal::untrack is a better spot to put it.

Thanks for reading this long brain dump! Lmk your thoughts, I'm happy to implement any of these changes.

Thanks for this feedback @blorbb — I read through it initially and agree with most of it, I will go through and implement individual pieces but just have not had the time to do it as I have been focused on bugfixes and filling out missing features instead. I can also write a piece by piece response if that's helpful but I find those tend to end up being longer and longer comment chains.
For example things like
12. Why are [Either*Future](https://docs.rs/either_of/0.1.0/either_of/enum.EitherOf3Future.html) variants in the form A { inner: T } instead of A(T), like [Either*](https://docs.rs/either_of/0.1.0/either_of/enum.EitherOf3.html) are?

The answer here is something along the lines of "pin_project_lite macro doesn't support tuple structs."  If this level of individual detail is helpful I can take the time to write it out.

Thanks @gbj, no need for a piece by piece response :) If you would like me to implement these just lmk which ones you agree with (/any variations) and I can have a go at most of these. Otherwise if you would like to implement them instead you can go ahead whenever you're free.

I think 3 should stay that way and 6 I suspect the shorter names are not available on crates.io
On Mon, Aug 5, 2024, at 5:33 AM, blorbb wrote:

@gbj https://github.com/gbj I've had a look through rustdoc to see the new module structure, and I'm really liking it so far! I have some thoughts, though these are very opinionated and minor, so feel free to disagree with many of them :)
In no particular order (numbered to make it easy to reference):

leptos::attr::Attribute::hydrate<const FROM_SERVER: bool> https://docs.rs/leptos/0.7.0-beta/leptos/attr/trait.Attribute.html#tymethod.hydrate - the const generic here could be an enum instead, to make it clearer what FROM_SERVER = false means (does it mean it's from the client?)
Items in leptos::context https://docs.rs/leptos/0.7.0-beta/leptos/context/index.html are suffixed with _context - maybe it could be nicer to use a qualified path instead? Similar to the std mpsc::channel, these could also be used as context::provide(), context::get() (renamed from use_context() since use is a keyword).
It looks like expect_context() is missing (rename to context::expect()?)
leptos::mount https://docs.rs/leptos/0.7.0-beta/leptos/mount/index.html is similar, rename to mount::{to_element, to_body, to_renderer} (maybe remove to_ as well?).
If these changes are made, the prelude should probably just export mount and context instead of mount::* and context::*.
Should the leptos provided components (Show, For, Suspense, etc) be in modules based on its purpose (current), or just one big components module? Not sure which is better.
Is it possible to only export components but without their *Props struct too? view! doesn't need them to be public, and you could maybe add something to make it easy to build using builder pattern like Suspense::builder() instead of leptos::component::component_props_builder(Suspense).
Rename leptos::spawn https://docs.rs/leptos/0.7.0-beta/leptos/spawn/index.html to leptos::task
tick() isn't really related to spawning futures, slightly more related to tasks ig
1. Docs are missing for this function
Could add queue_microtask into here as well?
the qualified path task::spawn() sounds nice :)
Rename long re-exported crate names leptos_dom -> dom, reactive_graph -> reactive?
Does leptos_dom https://docs.rs/leptos_dom/0.7.0-beta/leptos_dom/index.html actually need to be completely re-exported? The macros are already exported in leptos::logging https://docs.rs/leptos/0.7.0-beta/leptos/logging/index.html, and leptos_dom::logging https://docs.rs/leptos_dom/0.7.0-beta/leptos_dom/logging/index.html isn't really necessary with the macros. Perhaps pub use leptos_dom::helpers as dom; instead?
Does tachys need to be completely re-exported (in both leptos::tachys and leptos::prelude::tachys)? It seems like most of its contents are already re-exported individually.
Why is re-exporting tachys::html::event as ev marked as #[doc(no_inline)] https://docs.rs/leptos/0.7.0-beta/src/leptos/lib.rs.html#264?
The crate re-exports should be marked as #[doc(inline)] so that it can be searched. It looks like re-exported crates are just shown under the re-exports section and they don't show up when searching, while inlined/module re-exports show it as if it's part of leptos.
It seems like many functions are re-exported in the prelude but nowhere else. This might also be because many crates are re-exported and their inner items don't show up when searched, so it looks like it's only available in the prelude.
There are a lot of things in the prelude, many of which seem to be very niche. Since the modules are a better organised now, it might not be necessary to re-export so many things; just import them when we need it.
Rename the EitherOf* enums to just Either*?
Why are Either*Future https://docs.rs/either_of/0.1.0/either_of/enum.EitherOf3Future.html variants in the form A { inner: T } instead of A(T), like Either* https://docs.rs/either_of/0.1.0/either_of/enum.EitherOf3.html are?
Rename the Writable https://docs.rs/leptos/0.7.0-beta/leptos/prelude/trait.Writeable.html trait to Write to match the Read https://docs.rs/leptos/0.7.0-beta/leptos/prelude/trait.Read.html trait (and general Rust conventions).
unwrap_signal! https://docs.rs/leptos/0.7.0-beta/leptos/prelude/macro.unwrap_signal.html looks like it should be an internal thing (blanket re-exported from leptos::reactive_graph::unwrap_signal https://docs.rs/reactive_graph/0.1.0-beta/reactive_graph/macro.unwrap_signal.html, should probably be internal within reactive_graph too).
Re-exporting reactive_graph::untrack at the root seems odd, there's no other functions that are re-exported at the root of this crate. Maybe reactive_graph::signal::untrack is a better spot to put it.
Thanks for reading this long brain dump! Lmk your thoughts, I'm happy to implement any of these changes.

—
Reply to this email directly, view it on GitHub https://github.com/leptos-rs/leptos/issues/2086#issuecomment-2268966153, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVBTCK5OY5L6SX27Q6WYXTZP5WLJAVCNFSM6AAAAAA75ALZUKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRYHE3DMMJVGM.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

@blorbb So I've finally worked through these, and I have a few minutes to write down thoughts.
For context, the goal of the prelude in 0.7 is

to make the migration from leptos 0.0-0.6 (where nearly everything is exported as leptos::*) as easy as possible; if something is exported as leptos::*, for the most part I've tried to export it from leptos::prelude::*
without cluttering up the leptos root docs

So I'm not bothered about the prelude being a mess at the moment, even though it's worse than the prelude just having traits etc.

Rename the Writable trait to Write to match the Read trait (and general Rust conventions).

Yes.

Items in leptos::context are suffixed with _context - maybe it could be nicer to use a qualified path instead? Similar to the std mpsc::channel, these could also be used as context::provide(), context::get() (renamed from use_context() since use is a keyword).

Yeah maybe. We can always add these in future and deprecate the old ones if we want, although the fact that context::use() isn't possible (keyword) is probably just more hassle than it's worth.

It looks like expect_context() is missing (rename to context::expect()?)

Have since added.

leptos::mount is similar, rename to mount::{to_element, to_body, to_renderer} (maybe remove to_ as well?).

I can see the logic but mount_to is a better name than to for a function, and to_element is longer than mount_to. I don't have strong feelings on this.

Rename leptos::spawn to leptos::task

Like it, done.

tick() isn't really related to spawning futures, slightly more related to tasks ig

Docs are missing for this function

Thanks.

Is it possible to only export components but without their *Props struct too? view! doesn't need them to be public, and you could maybe add something to make it easy to build using builder pattern like Suspense::builder() instead of leptos::component::component_props_builder(Suspense).

Props are useful for docs, because they are where the props are best documented IMO. I'm fine with the latter ergonomics suggestion but I think it's out of the scope of this particular conversation.

Rename long re-exported crate names leptos_dom -> dom, reactive_graph -> reactive?

I like leptos::reactive as a reexport of reactive_graph. I think leptos_dom has been reexported as such forever, I don't think it's worth changing.

Does leptos_dom actually need to be completely re-exported? The macros are already exported in leptos::logging, and leptos_dom::logging isn't really necessary with the macros. Perhaps pub use leptos_dom::helpers as dom; instead?

It's not clear whether even having it as a separate package makes sense long term. It is definitely a relic of the pre-tachys structure. I'm open to more thoughts here.

Does tachys need to be completely re-exported (in both leptos::tachys and leptos::prelude::tachys)? It seems like most of its contents are already re-exported individually.

Agreed.

Why is re-exporting tachys::html::event as ev marked as #[doc(no_inline)]?

This one's actually quite important: the current docs inline these by default, and it leads to some very confusing documentation.

These are the docs I get if I search MouseEvent in the 0.6 docs, which instruct me to activate the MouseEvent feature, which doesn't exist on leptos but exists on web-sys. These docs give no evidence that they're talking about web-sys. Avoiding inlining them means that the still show up in search, but just as a link to web_sys::MouseEvent, which is much better.

The crate re-exports should be marked as #[doc(inline)] so that it can be searched. It looks like re-exported crates are just shown under the re-exports section and they don't show up when searching, while inlined/module re-exports show it as if it's part of leptos.

Thanks, this is really helpful and not something I knew! Works much better.

It seems like many functions are re-exported in the prelude but nowhere else. This might also be because many crates are re-exported and their inner items don't show up when searched, so it looks like it's only available in the prelude.

There are a lot of things in the prelude, many of which seem to be very niche. Since the modules are a better organised now, it might not be necessary to re-export so many things; just import them when we need it.

unwrap_signal! looks like it should be an internal thing (blanket re-exported from leptos::reactive_graph::unwrap_signal, should probably be internal within reactive_graph too).

The rules around macro_rules exports are baffling to me. For now I'm just making it #[doc(hidden)].

Re-exporting reactive_graph::untrack at the root seems odd, there's no other functions that are re-exported at the root of this crate. Maybe reactive_graph::signal::untrack is a better spot to put it.

Agreed, I reexported this from leptos::prelude and left it in its own module.

Should the leptos provided components (Show, For, Suspense, etc) be in modules based on its purpose (current), or just one big components module? Not sure which is better.

I have limited opinion on this. They're trying to be organized logically for now.

Rename the EitherOf* enums to just Either*?

I have no opinion on this except that it's not something I've heard in the last few months of people using it.

Why are Either*Future variants in the form A { inner: T } instead of A(T), like Either* are?

This one is just because pin_project_lite doesn't support tuple enums, IIRC.
See #3050.

Thanks so much for taking the time to make a response, I really appreciate it! I agree with all your thoughts :)

:tada: see, I always get to issues eventually :smile:

authors: benwis blorbb gbj

repo: leptos-rs/leptos


text:
Lettuce waitForReplication command executes at slave

Bug Report
Current Behavior
Lettuce client executes the WAIT command on slave nodes
It returns the following error:

Stack trace
Caused by: com.lambdaworks.redis.RedisCommandExecutionException: ERR WAIT cannot be used with replica instances. Please also note that since Redis 4.0 if a replica is configured to be writable (which is not the default) writes to replicas are just local and are not propagated.

The above error is part of http://download.redis.io/redis-stable/src/replication.c where it is returned if command is executed on a slave node. But directly before the WAIT call, I am calling a SET command, so it seems highly unlikely that it is a mess up in topology
Expected behavior/code
The calls should only execute at MASTER node specifically
Environment

Lettuce version(s): 4.4.3
Redis version: 5.0

Additional context
I executed this on AWS ElastiCache Redis with cluster mode enabled and multiple shards

Can you post some code that shows how you're using the command? Redis Cluster and Redis Master/Replica consider WAIT as a command to be run only on master nodes.

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

source: gharchive/issue

repo: lettuce-io/lettuce-core

license_type: permissive

license_source: bigquery


text:
Some executed commands are not in buffer when flushCommands called

Bug Report
I used manual flushing for bulk importing. But sometimes in the middle processing, LettuceFutures.awaitAll() was not completed until timeout. I checked debug log and found some commands were missing when flushCommands() called.

Current Behavior
When flushCommands() called manually, some executed commands are not in buffer. So missing commands never be completed normally.

Stack trace
// your stack trace here;

Input Code

Input Code
try (StatefulRedisClusterConnection<String, String> conn = redisClusterClient.connect()) {
    final RedisClusterAsyncCommands<String, String> commands = conn.async();
    commands.setAutoFlushCommands(false);
    final List<RedisFuture<?>> futures = new ArrayList<>();
    for (User user : users) {
        futures.add(commands.hset(...));
        futures.add(commands.hset(...));
        futures.add(commands.expire(...));
    }

    commands.flushCommands();
    if (!LettuceFutures.awaitAll(1, TimeUnit.MINUTES, futures.toArray(new RedisFuture[futures.size()]))) {
        // sometimes this block is executed
        log.error("Some data may not be inserted to redis cluster");
    }
}

Expected behavior/code

Environment

Lettuce version(s): 5.1.7.RELEASE
Redis version: 5.0.5

Possible Solution

I think this code can cause the problem because it buffer commands asynchronously. But I'm not sure about it and have no idea on how to fix it.
Workaround
4.3.3.Final works well with manual flushing.
Additional context

How many commands do you run in the bulk? Please note that Redis with Redis Cluster are allocated lazily. So by the time calling flushCommands(), a connection to a particular cluster node might not be yet established and you bring the client into an invalid state.
Please either ensure that all connections are established prior to changing setAutoFlushCommands  state or do not use setAutoFlushCommands at all if you cannot guarantee that.

I tried 50 and 1000 commands in the bulk. Regardless of the bulk size, missing commands are observed. Bulk insert code is executed in a loop because the total number of commands is much larger than the bulk size. The problem randomly happens in the middle of the loop.
Is there a way to use manual flushing safely?

Manual flushing is safe on standalone-connections. For cluster connections, it's not safe when not all connections are initialized. Have you tried without setAutoFlushCommands?

I thought that manual flushing works even on redis cluster. But it was my misunderstanding.
I just tried bulk insert without setAutoFlushCommands. It works well and is not too slow.
Thank you.


text:
Use AttributeKey.valueOf(…) instead of AttributeKey.newInstance

Changed the method to make sure that it calls getOrCreate instead of createOrThrow

Thank you for your contribution. That's merged and backported now.

source: gharchive/pull-request


text:
Make Status Filters Tabs instead of Buttons

I think the Status Filters on the Tasks page would look better if they were Tabs (with Active selected) rather than buttons.

Closing since tasks are dead for now. :(

repo: levlaz/braindump

license: mit


text:
Error at initialization: "The coroutine failed with this message: .../gitsigns.nvim/lua/gitsigns/git.lua:256: attempt to concatenate field 'gitdir' (a nil value)"

Describe the bug
Couroutine error, breaks and shows error message after initiating an nvim. Everything after latest commit on main branch update
To Reproduce
Steps to reproduce the behavior:

Update the plugin (:PackerUpdate if using packer.nvim)
Start a new nvim instace
See error

Observed output

Gif

Additional context
System: Ubuntu Linux 20.10
Neovim version: NVIM v0.5.0-dev+1231-g48e805728
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3

I've reverted the latest commit (https://github.com/lewis6991/gitsigns.nvim/commit/fd4e283efb798ed9493a658d7f5d2d0ef34e92e4) that causes this, obviously it wasn't quite ready.
I've been able to reproduce the issue but found this only happens when openeing files outside of a git repository. Do you get the same problem when opening tracked files?

I've opened #137. Can anyone this issue affects test that out before I merge it. Thanks.

Hello @lewis6991, thanks for the fast reply.
I found the issue when:
+ Opening untracked files
+ Opening files outside of a git repo
I didn't see the issue when:
+ Opening a new file in a git repo
+ Opening a tracked file
Hope that help. If needed, I can help you with further testing.

@kdav5758 thanks! Have you tried #137? Does that resolves the issues?

@lewis6991 yes, that resolves the issue.

Tested latest commit on the main branch and since you reverted it, it's now working as expected.
Tested latest commit on the refactor branch and it was working as intended too.

Many thanks for the feedback. I've gone an merged the PR.

Btw @lewis6991 I'm still seeing this issue on the latest commit of gitsigns, I believe I'm seeing this when I switch branches.

Steps to reproduce -> raise new issue.
If issues can be reproduced, then we can add them to the testsuite. There's at least one testcase already that has some coverage of switching branches.

license: MIT

license_source: github-api


text:
Enable profiling errors when used with fzy-lua-native

Hi,
When requiring https://github.com/romgrk/fzy-lua-native the following error is thrown, it appears there is an assertion on that line assert(pb.exec > 0) which fails.
wilder: draw: Vim(return):E5108: Error executing lua ...ck/packer/start/impatient.nvim/lua/impatient/profile.lua:146: ...ck/packer/start/impatient.nvim/lua/impatient/profile.lua:164: assertion failed!

This issue began a few weeks/commits ago but previously worked an is only visible when impatient.enable_profile() is used otherwise it doesn't occur.
For context this plugin is being used by wilder.nvim which internally is requiring fzy-lua-native
    use {
      'gelguy/wilder.nvim',
      event = { 'CursorHold', 'CmdlineEnter' },
      rocks = { 'luarocks-fetch-gitrec', 'pcre2' },
      requires = { 'romgrk/fzy-lua-native' },
    }

I don't know entirely but it seems like the fzy-native package probably doesn't have the same setup as other modules and so this check doesn't apply for it. I don't know what exec is supposed to be but is seems like maybe a package should be skipped if doesn't have one.

There are 3 main sections when running require:

resolve: time it took to find the module in the search path
load: time to load the file into the VM
exec: time to execute the module

The sum of these is the total time to require. However, the profiler excludes sub-requires of a module since if that sub-module is required by another module, then the second require cost will be significantly lower, so to make the profiler useful we exclude these. This means the profiler results shouldn't be effected by module load order.

I'm not sure how the above connects to this issue exactly tbh, wilder.nvim requires lua-fzy-native here, from what you are saying this plugin excludes sub-requires by which I guess you mean require'module.submodule' except in this case that's not how the fzy module is required, instead it is required via the main module require'lua-fzy-native' and has no submodules being used by wilder.

Is this still an issue?

Ah sorry I forgot this was still open. I actually no longer use wilder and don't use the profiling functionality anymore either. So I'm not sure. Last I checked which was quite a while ago. It was still an issue but it's not a setup I use anymore so I can close this out since it's not something I'm still reporting


text:
fix the flannel namespace version usage issue #49

hi,lework.i have fixed this issue #49,which is about the the wrong usage of the new flannel version when we install by this project.

@jelen56  thanks

repo: lework/kainstall


text:
Extending JWTAuthenticator - How can I add services to my extension?

Hello,
I'm trying to extend the new JWTAuthenticator (https://github.com/lexik/LexikJWTAuthenticationBundle/blob/2.x/Resources/doc/6-extending-jwt-authenticator.md), and I need to inject in my extension the reference to a custom repository, eg:
class CustomJWTAuthenticator extends JWTAuthenticator
{
    private CustomRepository $repository;

    public function __construct(
        JWTTokenManagerInterface $jwtManager,
        EventDispatcherInterface $dispatcher,
        TokenExtractorInterface $tokenExtractor,
        UserProviderInterface $userProvider,
        CustomRepository $repository
    ) {
        $this->repository = $repository;
        parent::__construct($jwtManager, $dispatcher, $tokenExtractor, $userProvider);
    }
    // ...
}

My config is:
# services_yaml
// ...
app.custom_jwt_authenticator:
    class: App\Security\Authenticator\JwtTokenAuthenticator
    parent: lexik_jwt_authentication.security.jwt_authenticator

# security.yaml
// ...
        api:
            pattern: ^/graphql|^/api/v1/(?!tokens)
            stateless: true
            provider: 'users'
            jwt:
                authenticator: app.custom_jwt_authenticator
            custom_authenticators:
                     - App\Security\Authenticator\LegacyJwtTokenAuthenticator
                     - App\Security\Authenticator\OAuthAuthenticator

I've followed the steps in the documentation,  cache:clear works correctly but when I try to interact with my firewalls, I get this error:
Too few arguments to function App\Security\Authenticator\JwtTokenAuthenticator::__construct(), 4 passed in /home/assoconnect/backend/var/cache/dev/ContainerOdA0ED5/getSecurity_Authenticator_Jwt_ApiService.php on line 26 and exactly 5 expected
And seeing the stack trace, it looks like Symfony tries to instantiate my service with only  the 4 arguments from the LexikJWT bundle.
What am I missing?
Thanks in advance :-)

I'm not really sure about this. But i do have a workaround for this case (by manually wiring arguments) :
app.custom_jwt_authenticator:
    class: App\Security\Authenticator\JwtTokenAuthenticator
    parent: lexik_jwt_authentication.security.jwt_authenticator
    arguments:
                $repository: '@App\Repository\CustomRepository'

Hope that help!

Hello, thanks for your answer! I'll fallback to that indeed if no option comes up by using autowiring, but we try to keep our services files as slim as possible to avoid future mistakes where one did not update the config files properly.

My guessing is that https://github.com/lexik/LexikJWTAuthenticationBundle/blob/2.x/Resources/config/token_authenticator.xml
This will inject four services into constructor by default. That's why we will getting the error "4 passed in the constructor, 5 expected" in custom authenticator.

Yes, this is the file that configures my parent class (and it relies on the standard Symfony authenticator structure, with the UserProvider being replaced with the SecurityExtension).
Do you know if this forces me to use extra service configuration & prevents me from using simple DI?

Do you know if this forces me to use extra service configuration & prevents me from using simple DI?

For me, yes. Because the JWTAuthenticator from this bundle is not using autowiring, we have to manual wire the extra service by ourself.
I think this is related with the order of compiling, symfony will compile its own libraries first before ours. What service configuration(services.yaml) does is just override the default behaviour of the services after compile.
P.S The explanation above might be wrong, have to read more about service container from docs.

repo: lexik/LexikJWTAuthenticationBundle


text:
PREEMPT_RT support for EVE

This PR introduces the PREEMPT_RT support for the main EVE kernel (pkg/kernel) for the x86_64 architecture by

Bumping up the minor version of the main kernel to the 5.1.131 to be aligned with PREEMPT_RT patches.

Adding the official patch-5.10.131-rt72.patch.gz set of patches.

Adding the patch which does not export the migrate_enable() and migrate_disable() kernel calls as GPL. OpenZFS is not GPL but uses those calls. Before the PREEMPT_RT patches those two calls were declared as "static inline" in the header, thus no export was needed.

Once the 'make pkg/kernel PREEMPT_RT=1' is specified the PREEMPT_RT kernel flavour is built in the 'eve-rt-kernel' docker image.

To build a live image with the PREEMPT_RT kernel call as the following: 'make live PREEMPT_RT=1'. The same applies for the installer images, e.g.: 'make installer-iso PREEMPT_RT=1'.

The PR is quite conservative and introduces a new kernel flavor which can be enabled on demand, so that by default other functionality is not touched.
This PR targets only amd64, since PREEMPT_RT scheduler can't be enabled on arm64 along with the KVM support (what a bummer).
There are a few changes in Dockerfile (recent security improvements) and kernel-build-yml.sh script, so @shjala please take a look.

Frankly I don't want to bother with a new kernel now, because it is used for risc only and the future of the whole new-kernel is not clear: do we drop it and switch the main kernel to a 5.15?

Should we do a separate PR which applies this to new-kernel as well?

@eriknordmark Frankly I don't want to bother with a new kernel now, because it is used for risc only and the future of the whole new-kernel is not clear: do we drop it and switch the main kernel to a 5.15?

Over the next few months we should update the kernel. But if we keep them in synch that can be done by "rm -rf kernel; mv new-kernel kernel; mkdir new-kernel; // fill new-kernel with next kernel LTS"
Don't know if it is worth the effort to keep them in synch for that reason.
@rene  any thoughts on this?

Update: or better to invest time and unify both Dockerfile and do the same trick with building a 5.15 on demand by 'KERNEL=5.15' make argument?

Probably not worth while if we are going to externalize the kernel build from the repo.

Probably not worth while if we are going to externalize the kernel build from the repo.

This does not eliminate the dockerfile and all the efforts to keep both in sync, we just skip the step of downloading the kernel sources and applying patches. Other than that stays the same.

@rouming you say this PR targets only amd64, do we need to include some checks that PREEMT_RT will not build for arm or did I miss them?

@rouming you say this PR targets only amd64, do we need to include some checks that PREEMT_RT will not build for arm or did I miss them?

The config for other arches is missing, so no worries, you get an error :)

Difference to the previous version:

s/PREEMPT_RT_SUPPORT/PREEMPT_RT_SUPPORT_ARG/ in the Makefile

Difference to the previous version:

Just commit message tweaks

I pay 5 euro for approval. Offer is valid today only.

Should we do a separate PR which applies this to new-kernel as well?

@eriknordmark Frankly I don't want to bother with a new kernel now, because it is used for risc only and the future of the whole new-kernel is not clear: do we drop it and switch the main kernel to a 5.15?

Over the next few months we should update the kernel. But if we keep them in synch that can be done by "rm -rf kernel; mv new-kernel kernel; mkdir new-kernel; // fill new-kernel with next kernel LTS"
Don't know if it is worth the effort to keep them in synch for that reason. @rene any thoughts on this?

Update: or better to invest time and unify both Dockerfile and do the same trick with building a 5.15 on demand by 'KERNEL=5.15' make argument?

Probably not worth while if we are going to externalize the kernel build from the repo.

They are not in that sync anyways, I don't think is worth to introduce all these change in new-kernel right now....

Difference to the previous version:

Docs tweaks

LGTM

authors: eriknordmark rene rouming shjala uncleDecart

repo: lf-edge/eve


text:
Sorting storage config and status before comparing

Storage disks in the config and status can be in any order, it is not necessary
that they will be available in the same order. So before starting comparision, we
need to sort both config and status structures. Currently, we are sorting on the
basis of Image UUID.
Signed-off-by: zed-rishabh rgupta@zededa.com

If it looks good, I will do the same for the rest of the files.

What tests did u run? Can you provide the EveImageCheck link?

What tests did u run? Can you provide the EveImageCheck link?

EveImageCheck no. 45, currently in the queue. I will update the link once it will be done.

I wouldn't have an issue with sorting things locally to perform the comparison by doing a deep copy of the slices. But here you are sorting the config (and status) which will change the order in which the virtual disks and vifs are presented to the domU. You can't do that. It can break the domU in terrible ways, corrupt data on the virtual disks, violate security assumptions when the domU has multiple network interfaces with different properties.)
Is there a bug where the current comparison (of the unsorted lists) is causing an issue?
Was this introduces by zedcloud starting to sort these arrays? (I think that needs to be backed out FWIW for the same reasons.)

@eriknordmark No, I am not facing any issues with unsorted data. The thinking was why EVE is dependent on the order sent by the controller. A controller can send data in any order in config and EVE will sort it at its end. But if these changes can cause issues, we can close this PR.

Yeah @zed-rishabh -- I think this needs to be closed and the contract with the cloud ordering needs to be enforced

Yeah @zed-rishabh -- I think this needs to be closed and the contract with the cloud ordering needs to be enforced

@rvs Ok, Thanks!

Ah.. Thanks for pointing out.. Missed it.. I was mainly thinking as an
optimization for detecting the changes
The main issue here, if we change the order is - We are mapping the volumes
provided to the mount points provided by the Manifest in order. That would
be broken..
Thanks,
Kalyan
On Wed, Feb 19, 2020 at 7:18 PM zed-rishabh notifications@github.com
wrote:

I wouldn't have an issue with sorting things locally to perform the
comparison by doing a deep copy of the slices. But here you are sorting the
config (and status) which will change the order in which the virtual disks
and vifs are presented to the domU. You can't do that. It can break the
domU in terrible ways, corrupt data on the virtual disks, violate security
assumptions when the domU has multiple network interfaces with different
properties.)
Is there a bug where the current comparison (of the unsorted lists) is
causing an issue?
Was this introduces by zedcloud starting to sort these arrays? (I think
that needs to be backed out FWIW for the same reasons.)
@eriknordmark https://github.com/eriknordmark No, I am not facing any
issues with unsorted data. The thinking was why EVE is dependent on the
order sent by the controller. A controller can send data in any order in
config and EVE will sort it at its end. But if these changes can cause
issues, we can close this PR.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/lf-edge/eve/pull/657?email_source=notifications&email_token=AK4GJOMY6WIV7UWWHIUYDKTRDXZABA5CNFSM4KXTQM2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMKSO4I#issuecomment-588588913,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AK4GJOLQRZAEMPRY5GWRKC3RDXZABANCNFSM4KXTQM2A
.

authors: kalyan-nidumolu rvs zed-rishabh


text:
New Project Proposal - Open Sustainable Technology

https://lists.lfenergy.org/g/tac/message/447

Confirmed- 9/21

authors: jmertic yarille

repo: lf-energy/tac


text:
重构项目

重构支持多平台
重构冷却机制，现在冷却更灵活了
按照自己的喜好更改了其他内容（翻新 readme，更换包管理器到 pdm，更换 workflow 等）

新的自动发版 workflow 用法：
在 PyPI 上向你的插件添加 Trusted Publisher，之后在 GitHub 创建 Release 即可自动发版
如果有意愿将此插件转入我组织维护的话，可以先不管这个 PR，联系我把你邀请进我的组织后迁移仓库让我处理就行

好了，注意一下邮箱，然后transfer repo就好了，顺便把仓库名下划线换成横线，再去pypi加一下trusted publisher

应该可以了吧

这回w稳

只留横杠的那个就行了

只留横杠的那个就行了

问题不大 多多益善（）

https://github.com/lgc-NB2Dev/nonebot-plugin-random-stereotypes/actions/runs/10559471918
✅


text:
Battery measurement

I noticed your comment about measuring the battery voltage...
I am simply using the internal measurement of the ESP (this means the ADC doesn't work but you get a decent idea of the power anyway.

This screenshot above was a test of an environment monitor that slept for 10 seconds, then it ran for about 5 seconds to send data back to my server. I wanted to see how long an 18650 (~2500mAh) would last. (About 36 hours).
But the interesting data is the relatively slow decay of voltage as seen by the ESP. I am using an MCP1700-3302E LDO regulator: http://uk.rs-online.com/web/p/low-dropout-voltage-regulators/6989044/

I think, this LDO is very tightly dimensioned:
I have measured peaks up to 350mA while the WLAN transmitter is active...
Futuremore i think, the wakup/sleep ratio (5s/10s+5s = 0.3 ) is to big:
A medium current of 200mA assumed:
200mA * 0.3 = 66mA => 2500mAh / 66mA = (around) 37h working time... :-)
Suggestion: Try to increase the sleep time (if possible) to 300sec (!).

I have :-). That was my first test just to check reliability.
The same circuit board is now running on a 10 minute sleep cycle - which is how it will be when it goes into my Polytunnel. This run is on a different battery and I have a suspicion that some of mine are less good than others.
But the point was that voltage measurement doesn't need to use an external divider and the ADC port.
https://github.com/theopensourcerer/esp8266_envmonitor/blob/master/code/src/main.cpp#L46
The graph clearly shows how the voltage degrades. The good thing was that the ESP wasstill able to transmit when the supply VCC was only 2.63v.

My Environment test is still running since the 6th February and the VCC measurement of the ESP has not dropped below 3.20v yet, although I suspect it is about to. It has been "bouncing" between 3.21v and 3.20v almost since the very start of the test, but now it is spending more time at 3.20 and less at 3.21v.

Just to follow up on this, my test on a 10 minute sleep cycle ran for approximately 28.7 days. Which is OK for my needs.

@zentris when you place a big cap of 1000uF between vcc and gnd of the ESP you can minimize the peaks very well. See the video of Andreas Spieß. He explains it very well. https://youtu.be/6SdyImetbp8

authors: Zentris lh84 theopensourcerer


text:
Make the first argument supplied to lifecycle arguments persistent

The current component vnode API makes it easy to get stuck with stale vnode references, which becomes problematic if, for instance, you define persistent methods depending on vnode.attrs in oninit. The reduced failure case looks like this:
const Component = {
  oninit( vnode ){
    vnode.state.method = () =>
      alert( vnode.attrs.input )
  },

  view : vnode =>
    m( 'button', {
      onclick : () =>
        vnode.state.method()
    }, 'Feedback' )
}

m.mount( document.body, {
  oninit(){
    vnode.state.value = 'foo'
  },

  view : vnode => [
    m( 'input', {
      value : vnode.state.value,
      oninput : e =>
        vnode.state.value = e.target.value
    } ),

    m( Component, {
      value : vnode.state.value
    } )
  ]
} }

In the example above, the intention is to have the value of the input bound to the top level component state and passed in to the nested component, such that hitting the button alerts the input value. In practice, the alerted value will always be the same, because the method references the outdated vnode supplied on the first render.
This isn't a blocking problem — there are all manner of ways of getting around it. The problem is that all the intuitive patterns for defining custom stateful methods in components are liable to suffer from stale references to attrs.
We can mitigate this by changing render logic such that the vnode received by components — which need not necessarily be the same construct used by the render internals — be stateful, this ensuring that the vnode received by any given component instance will be the same throughout that component's perpetuity. Thus vnode.attrs is reassigned on every upstream draw, and the problem disappears.

@barneycarroll You've got two issues in your example, which makes it harder to follow:

Your base oninit is missing the vnode argument.
Either your Component should alert with vnode.attrs.value, or you should pass an input argument when you use it in the base component.

As for the attributes, it is rather surprising that it doesn't mutate the retained vnode.attrs on each change. More specifically, it sounds like a bug to me. A more minimal (untested) example would be this:
var Component = {
    view: vnode => m("div", ["Count: ", vnode.attrs.count]),
}

m.mount(document.body, {
    count: 1,
    view: vnode => m.fragment([
        m("button", {onclick() { vnode.state.count++ }}, "Increment"),
        m(Component, {count: vnode.state.count}),
    ]),
})

@isiahmeadows  that example works fine: https://jsfiddle.net/bruce_one/mdz3baoe/
I think I hit something very very similar (although I can't quite remember in what exact incarnation) that was very frustrating/confusing initially. (Will try and remember how/why...) But it definitely came down to changes applying to the old vnode.state whilst the new vnode.state kept getting reinitialised (or not set, or some such).
I'd be keen on the idea of making vnode persistent to avoid "surprises". (vnode seems like it's consistent, so it's really surprising when something goes wrong -- and hard to find (because it's quite internal, imo))

Maybe I'm misunderstanding and a shorter clarification would help, but I think this is working exactly as I'd expect. Object refs are fine, property refs (unless also to an object) are not.
https://jsbin.com/haxosa/2/edit?js,output
Note that the object reference works exactly as expected because the vnode object being passed to Component.oninit is persistent. Isn't it already the same object, and the problem is accessing properties on that object that aren't themselves objects means your refs go bad when they're changed?

Fiddle of @barneycarroll's code, just if of any use: https://jsfiddle.net/bruce_one/1yk6xchy/

This looks to me like standard JS object/non-object references, maybe I'm misunderstanding.
https://jsbin.com/haxosa/3/edit?js,console,output
var obj = { prop : 0 };
var ref = { prop : obj.prop };

obj.prop += 5;

// Because ref.prop is a reference to the value in obj.prop, when you update
// obj.prop ref.prop DOES NOT CHANGE
//
// This looks like exactly what is happening above in the mithril code

obj.prop // 5
ref.prop // 0, it still points at the old 0 value that obj.prop was previously

@tivac, yes and since on redraw the hooks/view receive a fresh vnode, the reference becomes stale.
IIUC, @barneycarroll suggests that we keep around and recycle the same vnode object for every redraw,  with update fields.

Initially when I ran into issues with this I thought about raising an issue, but couldn't isolate it well enough to do so... Hence I'm not sure I'm much help... But...
I'm fairly sure one of the reasons I ran into this is because I thought I could treat vnode.state as an immutable state container (ish).
Eg:
vnode.state = Object.freeze(Object.assign({}, vnode.state, { count: vnode.state.count + 1 }))

Personally, I was very surprised/confused when it didn't work (iirc, it was a bit race-y because it worked sometimes but not others? (iirc, integrating into non-mithril event listeners)) -- but now I think that I was misinterpreting the word state. (Had been doing some React, hence why I think I wanted to do it as such.) And hence understand if that type of use is not supported.
More recently I believe I've had issues with passing vnode to closures eg in oncreate which close over the original vnode value and hence the attrs have gone out of date (which I now understand/expect but initially it came as a surprise because I assumed that vnode.attrs was mutated not replaced). Although I can't think of a good example... So maybe ignore me on this :-s (Maybe https://jsfiddle.net/bruce_one/cmfL3gcc/ - click show then hide; and the vnode.attrs.onclick helps illustrate? (because in normal js, I'd expect the vnode.attrs.onclick value to have changed because of the object being updated)

@tivac not quite. Your issue is with primitives being copied by value, not reference. The problem with the vnode object is that vnode and vnode.attrs are disposable values that never update. It doesn't matter if the properties you pass to attrs are primitive or not - if you define a method referencing vnode,attrs in oninit, and call that reference after a subsequent redraw, the reference will be to the attributes passed in on the first draw. This is a really nasty gotcha, because state does update, and Mithril's API encourages people to define stateful methods.

I'm withdrawing the proposal to make component vnodes persistent objects because that treads on the toes of the update methods, which rely on newVnode, oldVnode signatures. vnodes being disposable makes sense, the lifecycle methods make sense. the thing that's going against the grain is stateful methods, which authors should be dissuaded from under the component docs anti-patterns section.

seems like oninit( vnode ) should instead be oninit( instance ) with a instance.vnode that would get replaced, so your methods simply use that than the vnode directly. this is actually how domvm manages the same situation because its vnodes also get replaced (vm.node where vm is the referentially persistent component instance)

So you'd reserve the state.vnode field and swap vnode.state for state.vnode?

right, i imagine you'd have to either pass in state or bind this within the hooks to state and access state.vnode or this.vnode. i'm not too familiar with mithril internals, so just going off an educated guess from own experience.

@bruce-one This might be better:
var Component = {
    oninit(vnode) { vnode.state.get = () => vnode.attrs.count },
    view: vnode => m("div", ["Count: ", vnode.state.get()]),
}

m.mount(document.body, {
    count: 1,
    view: vnode => m.fragment([
        m("button", {onclick() { vnode.state.count++ }}, "Increment"),
        m(Component, {count: vnode.state.count}),
    ]),
})

I think it's that the new vnode, not the old one, is what's being passed to the view. An easy way to test this is using this:
var Component = {
    oninit(vnode) { vnode.state.vnode = vnode },
    view: vnode => m("div", "Same: " + (vnode.state.vnode === vnode)),
}

m.mount(document.body, {
    count: 1,
    view: vnode => m.fragment([
        m("button", {onclick() { m.redraw() }}, "Redraw"),
        m(Component),
    ]),
})

In order to maintain the correct attrs/state, the vnode.state has to be transferred each time to the new vnode instead of the new vnode.attrs to the old vnode. So I suspect this is what's happening, and may need fixed.

In order to maintain the correct attrs/state, the vnode.state has to be transferred each time to the new vnode instead of the new vnode.attrs to the old vnode. So I suspect this is what's happening, and may need fixed.

yes, this.

Actually I don't see this as a bug at all and in fact as exactly the expected behavior.
The issue it seems is how the attrs are being stored or used by a child container not their value at any given point.
Firstly, attrs/props are the domain of the containing caller not the child component that receives them.
Secondly, If the child is trying to maintain them especially within an oninit event I would expect the exact behavior that is being shown.
That is, where only the oninit attrs are shown not as a reference or the latest but as it was when it was in fact called - oninit!

@mglazer-cengage
Focusing on oninit and vnode is perhaps not illustrating the issue adequately. The problem is being able to define handlers (whenever) that can access some persistent state, whether it be a transfered vnode.state, a bound this somewhere, or some other mechanism. The fact that state lives on the vnode is simply a means to an end given the current API. Unless i'm missing something.

the vnode.state has to be transferred each time to the new vnode

It does this already: https://github.com/lhorie/mithril.js/blob/rewrite/render/render.js#L208
As I understand, the issue is when there's a component with a closure like in doStuff below:
// example 1
{
  oninit(vnode) {
    this.doStuff = () => console.log(vnode.attrs.count)
  },
  view() {
    return m("button", {onclick: this.doStuff})
  }
}

The code is written like this as an attempt to get a handle on the latest vnode.attrs.count, but clicking on the button logs the count from creation time, because the developer misunderstands how closures work.
To achieve what we want, the code needs to be written like this instead:
// example 2
{
  doStuff(vnode) {console.log(vnode.attrs.id)},
  view(vnode) {
    return m("button", {onclick: () => this.doStuff(vnode)}
  }
}

One proposal says example 1 should mutate vnode.attrs after the fact so that calling doStuff logs the latest count. Pros: it makes the actual behavior be in line w/ the developer's (flawed) expectations. Cons: this is voodoo magic
Another proposal is to have a vnode.state.attrs that always points to the latest attrs. Pros: This can be easily implemented. Cons: this complicates vnode consumption (i.e. it's usually more convenient to use vnode.attrs, but that doesn't work as per (flawed) expectation when closures are involved.
React gets around the whole thing by using a variation of the second proposal:
React.createClass({
  componentWillMount() {
    this.doStuff = () => console.log(this.props.count) // `this` is equivalent to `vnode.state`
  },
  render: function() {
    return <button onClick={this.doStuff}>;
  }
})
//or
React.createClass({
  doStuff() {console.log(this.props.count)},
  render: function() {
    return <button onClick={this.doStuff}>;
  }
})

I think it's reasonable to tell people to write like example 2. Making changes to the mithril codebase in order to hide the fact that vnodes don't persist through the entire lifecycle won't work. People will still encounter confusion, only later and in more subtle ways.

And if the reason they're writing example 1 is that they don't know how closures work, I woudn't add code to mithril's codebase that robs them of the opportunity to gain that understanding.

I entirely understand why example two is the solution, there's just something about the way the vnode is presented (or maybe/probably just how I read it?) that makes it feel like:
// Magic behind the scenes (_in my mind_):
var vnode = new ...

Component.oninit.call(vnode.state, vnode)
Component.view.call(vnode.state, vnode)
Component.oncreate.call(vnode.state, vnode)

// m.render()

Component.view.call(vnode.state, vnode)
Component.onupdate.call(vnode.state, vnode)

//etc (as opposed to thinking it's like `Component.view.call(state, { attrs, state, dom })` ish)

Hence in my mind it's just a standard reference argument, and hence reference to vnode.attrs would always refer to the new version (also, in my mind, that's what I'd want so it makes it feel even more likely/logical -- eg it seems like a trap to ever refer to vnode.attrs in oninit/oncreate because it's potentially/probably out of date).
I just feel like it's a bit of a trap and a bit confusing (when it bites you the first time; but from then on it's what you expect so it's fine).
Maybe the solution to my concern is just an equivalent of Typically, Virtual DOM trees are then recreated every render cycle, which normally occurs in response to event handlers or to data changes front and center in the lifecycle doc?
Although, in terms of oncreate and third-party-lib integration, there's now a bit of clumsiness (ime) eg:
const X = {
    view({ attrs, state }) {
        state.onclick = attrs.onclick
        state.onmouseup = attrs.onmouseup
        // ...
    }
    , oncreate({ state, dom }) {
        new ThirdPartyLib(dom, { onclick: (...args) => state.onclick(...args), onmouseup: (...args) => state.onmouseup(...args) })
        // because if this fn refers to attrs, and then there's a reason to change an attr, it won't work (feels trap-y)
    }
}

m(X, { onclick: state.create ? state.doCreate : state.xyz, ...

Anyway, I'm happy for this issue to be closed :-) (I just thought it a trap when I first encountered it, so felt it worth mentioning, but it's np :-) )

@brlewis I think you have a very strong argument. I'm going to leave it as is

authors: barneycarroll brlewis bruce-one isiahmeadows leeoniya lhorie mglazer-cengage pygy tivac


text:
Added docs for stream scan and scanMerge

These hadn't been added yet so I took a stab at it. TBH I'm a bit out of my depth, so I looked at the flyd docs for some help. Their scan docs appear to have typos so I tried to straighten it out. scanMerge is here

@JAForbes would you be willing to take a look?

I think it's all spot on, I just added some ideas / notes to the diff.  But you could merge as is and be 100% accurate.

@JAForbes thanks! If someone wants to act on your feedback I'll happily merge that PR.

authors: JAForbes spacejack tivac


text:
sysInit and task cleanup

closes #201

Some additional files need to be deprecated. Rtospedals and sendTritium are the two that come to mind.

Also, if you're deprecating a file, there needs to be a reason to not just delete it.

Make sure you redo OS error locations, as those have now changed because of removed tasks

I don't know how much of this has been verified at this point, but given that we are all effectively working on this branch by default now, are we ready to merge into master?

authors: IshDeshpa babusid chaseblock

repo: lhr-solar/Controls


text:
Unable to resume downloading the course

Steps to reproduce:

Start downloading any course.
Stop the download after at least one video is downloaded.
Now start downloading the same course.
Displays the following error.

Traceback (most recent call last):
  File "frontendmasters-dl.py", line 24, in <module>
    downloader()
  File "/home/manish/Desktop/anaconda2/lib/python2.7/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/home/manish/Desktop/anaconda2/lib/python2.7/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/home/manish/Desktop/anaconda2/lib/python2.7/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/manish/Desktop/anaconda2/lib/python2.7/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "frontendmasters-dl.py", line 17, in downloader
    spider.download(course, high_resolution, video_per_video)
  File "/home/manish/Downloads/OS_FrontendMaster-dl/extractor/spider.py", line 56, in download
    self.download_course(course_downloadbale)
  File "/home/manish/Downloads/OS_FrontendMaster-dl/extractor/spider.py", line 219, in download_course
    self.download_video(i1, i2, subsection, section_title, course_path)
  File "/home/manish/Downloads/OS_FrontendMaster-dl/extractor/spider.py", line 227, in download_video
    i1, i2, subsection, section_title, course_path
  File "/home/manish/Downloads/OS_FrontendMaster-dl/extractor/helper.py", line 16, in get_local_file_path
    extension = get_file_path_from_url(subsection['downloadable_url'])
  File "/home/manish/Downloads/OS_FrontendMaster-dl/extractor/helper.py", line 43, in get_file_path_from_url
    return url.split("?")[0].split(".")[-1]
AttributeError: 'NoneType' object has no attribute 'split'

Same issue as #63 i am guessing because there is already the a file with the same name. Trying now if thats the case.

Nope. I don't think this is the issue. Because I have checked even after deleting the files that are not downloaded.

If I did not remember incorrectly, there is a file used to note down which file(s) is downloaded.

use  --video-per-video it will fix the problem

thank you @vahidm-sp this is how I could resume downloading this way, I had to download some courses from scratch before this

authors: imadyaici li-xinyang lostdesign manishbisht vahidm-sp


text:
Update README.md

Bonnehomme > Bonhomme
(and thank you to show our work :) )

Oops! No problem, it was an awesome project!

Thank you, awesome thanks to matter :)

Kevin* Boudot.*
Lead Developer @BonhommeParis
kevinboudot.me
06 59 68 56 79 <0659685679>
linkedin https://www.linkedin.com/in/kevinboudot - twitter
https://twitter.com/kevinboudot
On Mon, Feb 1, 2016 at 12:00 PM, Liam notifications@github.com wrote:

Oops! No problem, it was an awesome project!
—
Reply to this email directly or view it on GitHub
https://github.com/liabru/matter-js/pull/199#issuecomment-177915787.

authors: kevinboudot liabru

repo: liabru/matter-js


text:
Cannot build with Gradle 8.x

After upgrading Gradle to 8, I get an error below when trying to build.
If I understand correctly, all plugins must now declare a namespace in build.gradle
FAILURE: Build completed with 2 failures.

1: Task failed with an exception.
-----------
* What went wrong:
A problem occurred configuring project ':flutter_asa_attribution'.
> Could not create an instance of type com.android.build.api.variant.impl.LibraryVariantBuilderImpl.
   > Namespace not specified. Specify a namespace in the module's build file: /Users/lukasnevosad/.pub-cache/hosted/pub.dev/flutter_asa_attribution-0.0.3/android/build.gradle. See https://d.android.com/r/tools/upgrade-assistant/set-namespace for information about setting the namespace.

     If you've specified the package attribute in the source AndroidManifest.xml, you can use the AGP Upgrade Assistant to migrate to the namespace value in the build file. Refer to https://d.android.com/r/tools/upgrade-assistant/agp-upgrade-assistant for general information about using the AGP Upgrade Assistant.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
==============================================================================

2: Task failed with an exception.
-----------
* What went wrong:
Failed to query the value of property 'buildFlowServiceProperty'.
> Could not isolate value org.jetbrains.kotlin.gradle.plugin.statistics.BuildFlowService$Parameters_Decorated@5c23b7fc of type BuildFlowService.Parameters
   > A problem occurred configuring project ':flutter_asa_attribution'.
      > Could not create an instance of type com.android.build.api.variant.impl.LibraryVariantBuilderImpl.
         > Namespace not specified. Specify a namespace in the module's build file: /Users/lukasnevosad/.pub-cache/hosted/pub.dev/flutter_asa_attribution-0.0.3/android/build.gradle. See https://d.android.com/r/tools/upgrade-assistant/set-namespace for information about setting the namespace.

           If you've specified the package attribute in the source AndroidManifest.xml, you can use the AGP Upgrade Assistant to migrate to the namespace value in the build file. Refer to https://d.android.com/r/tools/upgrade-assistant/agp-upgrade-assistant for general information about using the AGP Upgrade Assistant.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
==============================================================================

BUILD FAILED in 1s

I'm stuck on the same issue. Have you managed to resolve it? Could you please share your solution?


text:
PersistenceManager:default can't be resolved

PersistenceManager:default can't be resolved if you don't use @InjectPersistenceManager() before DrivineModule.withOptions()
It was working be course we were importing Repositories with @InjectPersistenceManager() decorator, but if you run DrivineModule.withOptions() before importing the Repository, the default provider will be not defined
@jasperblues I'm working on the PR with e2e tests to illustrate the issue, if you can check it out, for you it should be quicker to debug

Hey,
I'm currently facing kinda the same issue, but with a slightly different log
[Nest] 15904   - 12/13/2020, 20:06:52   [NestFactory] Starting Nest application...
[Nest] 15904   - 12/13/2020, 20:06:52   [ExceptionHandler] Nest can't resolve dependencies of the PersistenceManagerFactory (?, TransactionContextHolder). Please make sure that the argument dependency at index [0] is available in the DrivineModule context.

It refers to the PersistenceManagerFactory when I'm not directly usnig it.
I'm trying to have nest, drivine and graphql running together, but when starting the app, it logs this error. (Afterward, I'll have some "service" files, but they does corresponds to the resolvers files like in the drivine-insipration, but named differently for avoiding confusion with graphql).
My current stack is:

"@nestjs/core": "^7.0.0"
"@liberation-data/drivine": "^2.1.3"
"neo4j-driver": "^4.1.1"
and
yanr2: "1.22.10"

When I'm cloning the repo drivine-inspiration and running it, it does start like a charm; but in this case, I'm first creating a nest app, then adding drivine,  with the config set from the .env in the app.module, then used in another file, user.service (the same as a resolver, just the name changing)
Here is the app.module:
@Module({
  imports: [
    ConfigModule.forRoot(),

    GraphQLModule.forRoot({
      typePaths: ['./**/*.graphql'],
      definitions: {
        path: join(process.cwd(), 'src/graphql.ts'),
      },
      include: [UserModule],
    }),

    DrivineModule.withOptions(<DrivineModuleOptions> {
      connectionProviders: [DatabaseRegistry.buildOrResolveFromEnv()]
    }),

    UserModule,
  ],
  controllers: [AppController],

  providers: [AppService],
})
export class AppModule {}

and the user.resolver:
@Injectable()
export class UserService {
  constructor(
    @InjectPersistenceManager() readonly persistenceManager: PersistenceManager,
  ) {}

  async getAll (): Promise<User[]> {
    const spec = new QuerySpecification<any>().withStatement(`
      MATCH (user:User)
      RETURN user
    `);
    return this.persistenceManager.query<any>(spec);
  }
}

then the .env
NODE_ENV=dev
DRIVINE_LOG_LEVEL=VERBOSE

DATABASE_TYPE=NEO4J
DATABASE_USER='neo4j'
DATABASE_PASSWORD='yolo'
DATABASE_HOST='localhost'
DATABASE_PORT='7687'

Also, I would like to say that I'm an utter beginner with nestjs, drivine, yarn2 and ts: I can't really say if this is the same error or just something different ._.

Hello @Vincent-Alexandrine.
Can you confirm once more that it was Drivine 2.1.3 that got installed for you?
According to the error message, NestJS can't find DatabaseRegistry, which is to be injected into PersistenceManagerFactory (the thing that emits a PersistenceManager for a given database config).
But this DatabaseRegistry is configured to be a NestJS component on startup. Look at DrivineModuleBuilder:
infrastructureProviders(): Provider[] {
        return [
            <Provider>{ provide: DatabaseRegistry, useFactory: () => DatabaseRegistry.getInstance() },
            <Provider>{ provide: TransactionContextHolder, useFactory: () => TransactionContextHolder.getInstance() },
            PersistenceManagerFactory,
            TransactionContextMiddleware,
            TransactionalPersistenceManager,
            NonTransactionalPersistenceManager
        ];
    }

^-- There it is. So what is happening here?
What we know so far:

Sample app is behaving correctly.
In your custom app (was it forked from sample app or built from scratch?) does not appear to be able to find DatabaseRegistry. DatabaseRegistry is not the configured DB, but the registry that contains all of them. Odd.

Next Steps
Is it possible you can sure the source of your app or create a cut down one that reproduces the problem?

Hey @jasperblues ,
So I tried a couple of stuffs:

remove all ./node_modules and yarn.lock then reinstall, I'm still having the error
I created a new nest repo with nest new then installed everything with npm. Some modules haven't been installed: cli-color, class-transformer. Then I have the same error Nest can't resolve dependencies of the PersistenceManagerFactory (?, TransactionContextHolder)..  Logging DatabaseRegistry.buildOrResolveFromEnv() in my app.module (after the import), will output

Neo4jConnectionProvider {
 name: 'default',
 type: 'NEO4J',
 host: 'localhost',
 port: 7687,
 user: 'neo4j',
 password: 'password',
 database: 'eternes',
 driver: Driver {
   _id: 0,
   _address: ServerAddress {
     _host: 'localhost',
     _resolved: null,
     _port: 7687,
     _hostPort: 'localhost:7687',
     _stringValue: 'localhost:7687'
   },
   _userAgent: 'neo4j-javascript/4.2.1',
   _authToken: { scheme: 'basic', principal: 'neo4j', credentials: 'password' },
   _config: {
     userAgent: 'neo4j-javascript/4.2.1',
     maxConnectionLifetime: 3600000,
     maxConnectionPoolSize: 100,
     connectionAcquisitionTimeout: 60000,
     fetchSize: 1000
   },
   _log: NoOpLogger { _level: null, _loggerFunction: null },
   _connectionProvider: null
 }
}

The same is output when I do the same in the drivine-inspiration, but in this case afterward there is the error.
Was it what you were asking for ?
Thanks

Wild guess based on past experience:
I suspect it might be the NestJS version. Can you try installing exactly the same version of Nest that the sample app uses?
If this is it - great, use that for now, while I find a fix for all versions.

I changed the nest version to the one in the drivine-inspiration (@nestjs/core, @nestjs/common, @nestjs/cli to ^7.4.4), but I'm still having the issue.
Also I don't know if it could be related, but the yarn install fails to add @liberation-data/agensgraph .

Are you able to (privately) send the code or a sample app that reproduces the problem?

I am having the same problem. Was this issue resolved ?

All - this issue is closed.
If you are having an issue, and you think it is a bug:
Please post exactly what you have tried, what you expected to happen, what actually happened.
If you need help learning Drivine:
Please post under the drivine stack-overflow tag. You will receive an answer just as quickly. The benefit of using StackOverflow for learning is that it is well-indexed by google, so you will help others to learn as well.

For anyone still having this problem. I was able to fix this by importing modules from @liberation-data/drivine instead of nested folders within driving.
I.e.
Before:
import { DrivineModule } from '@liberation-data/drivine/DrivineModule';
import { DatabaseRegistry } from '@liberation-data/drivine/connection/DatabaseRegistry';

After:
import { DrivineModule, DatabaseRegistry } from '@liberation-data/drivine';

At least, that is what fixed this for me :blush:

For anyone still having this problem. I was able to fix this by importing modules from @liberation-data/drivine instead of nested folders within driving.
I.e.
Before (broken -1)
import { DrivineModule } from '@liberation-data/drivine/DrivineModule';
import { DatabaseRegistry } from '@liberation-data/drivine/connection/DatabaseRegistry';

After (working +1)
import { DrivineModule, DatabaseRegistry } from '@liberation-data/drivine';

At least, that is what fixed this for me blush

I just wasted so much time on this, wish I had looked at @not-Ryan's response earlier. My IDE didn't grap the imports from @liberation-data/drivine and that minor difference changed it all. Thanks @not-Ryan that was huge.

authors: Vincent-Alexandrine jasperblues myflowpl not-Ryan pfrank13 sashokbg

repo: liberation-data/drivine


text:
Add a configuration file

I would like to have the ability to invoke the download (and compiling) and standard Configurations from a file.
Don´t care it it´s csv, xml, txt or whatever.
ie.:
defaultConfig{
//the default values if nothing else is specified.
date-before=now
automaticallyWrite=true
}
worldnews{
min-score=100
date-after=?
onlySelf=true
}
nintendoswitch{
}
You get it...

Sounds alright. This could be accomplished with some simple bash scripting too.

yeah, but batch sucks.


text:
Redundant public key in ed25519 private key

The private key bytes already includes the public key. However, we append it on again. Steps to fix:

Fix parsing keys without this additional public key copy appended.
Stop producing keys with the key appended.

Fixed.


text:
Add connection type param to hangUp()

Fixes https://github.com/libp2p/js-libp2p/issues/299
Note: Requires https://github.com/libp2p/js-libp2p-circuit/pull/41 for tests to pass

@dirkmc I reran CI so the latest libp2p-circuit would get pulled in. Looks like there are some failures, can you take a look at those?

Thanks Jacob, I’m in Nicaragua this week but I can take a look when I’m
back next Wednesday
On Wed, Jan 2, 2019 at 2:37 PM Jacob Heun notifications@github.com wrote:

@dirkmc https://github.com/dirkmc I reran CI so the latest
libp2p-circuit would get pulled in. Looks like there are some failures,
can you take a look at those?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/libp2p/js-libp2p-switch/pull/298#issuecomment-450977818,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKUpMI5GDvrv9jR-xVAGv0OvagKEEaYks5u_Rh5gaJpZM4ZfCzh
.

@jacobheun with the refactor, these need to be remade or closed. I'll let you do the review

Closing this as tagging will be needed for this and it will likely change the structure of this significantly.

authors: daviddias dirkmc jacobheun


text:
Prepend libra to metrics package

Motivation
To publish to crates.io, all packages need to have unique names. Prepending libra to the names of all packages provides unique names for all packages. This PR prepends libra to the metrics package.
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Only cosmetic changes, existing tests should suffice.
Related PRs
#1226
#1235
#1350
#1353
#1371

CC @bmwill

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

@bmwill can we get this through before I have to rebase again?

@bors-libra r+

:pushpin: Commit 4f9f899 has been approved by bmwill

:hourglass: Testing commit 4f9f899002cdd403fe53d1019de27ef389e8679a with merge a5615f1cf1a14671c247b09ff0f8f0d874ab490e...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: bmwill
Pushing a5615f1cf1a14671c247b09ff0f8f0d874ab490e to master...

authors: TristanDebrunner bmwill bors-libra

repo: libra/libra


text:
Add type checking to spec translator.

Motivation
In order to deal with things like field selection and correct treatment of references, we need type information for the translated SpecExps. This change adds type checking to the translator and extends the test suite.
The type checking also has the added benefit that we report context errors in the spec language directly at the source instead of via the generated boogie. Right now, the tool bails out on the first type error, but the code is setup so systematic collection of errors with source level backlink can be added in subsequent PRs.
Have you read the [Contributing Guidelines on pull requests]
Yes
Test Plan
Added new tests, verified existing tests, and updated golden files.
Related PRs
NA

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

Rebased and adapted to new resource name parsing.

@bors-libra r=sblackshear

:pushpin: Commit 15a0480 has been approved by sblackshear

:hourglass: Testing commit 15a04803d8e95bdf938313e90617744bcf9cbeb1 with merge 7fa48c22293d349d9cedd0c1cf0353538a411c79...

:sunny: Test successful - checks-circle_commit_workflow
Approved by: sblackshear
Pushing 7fa48c22293d349d9cedd0c1cf0353538a411c79 to master...

authors: bors-libra wrwg


text:
[storage] Remove dependency on the strum crate

Motivation
To simplify dependency.
Have you read the Contributing Guidelines on pull requests?
(Write your answer here.)
Test Plan
compiling and dashboard
Related PRs
(If this PR adds or changes functionality, please take some time to update the docs at https://github.com/libra/website, and link to your PR here.)

@bors-libra r=metajack

:pushpin: Commit 1758305 has been approved by metajack

:hourglass: Testing commit 1758305217db0411a730ea377ed46b2cec85316e with merge bdc0ca40de862ceb9ed09719bd51bc40896ceb20...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: metajack
Pushing bdc0ca40de862ceb9ed09719bd51bc40896ceb20 to master...

authors: bors-libra msmouse


text:
[cleanup][network] Remove 12 untested, unused methods from network

This PR removes 13 untested, unused methods from network. The value of the PR may reside more in the signaling of the nature of those untested, unused methods rather than actual removal.
I do hope & expect that reviewers will come up with valid reasons why one or another of those methods should be part of our public API — I've hence separated commits per method so that those valid methods can be kept, by omitting the commit that removes them. Just say so in review, plz :slightly_smiling_face:

@bors-libra r+

:pushpin: Commit ae6a7ca has been approved by davidiw

:broken_heart: Test failed - checks-circle_commit_workflow

@bors-libra retry

:bulb: This pull request was already approved, no need to approve it again.

There's another pull request that is currently being tested, blocking this pull request: #4139

:pushpin: Commit ae6a7ca has been approved by davidiw

:hourglass: Testing commit ae6a7cad0c6accae07eb662f518578daeb9633d1 with merge 4ff3db423a3be0c99ccd28764b0681bdba0a4f98...

:broken_heart: Test failed - checks-actions_land_blocking_test

@bors-libra r+

:pushpin: Commit ae6a7ca has been approved by davidiw

:bulb: This pull request was already approved, no need to approve it again.

This pull request previously failed. You should add more commits to fix the bug, or use retry to trigger a build again.
There's another pull request that is currently being tested, blocking this pull request: #4187

:hourglass: Testing commit ae6a7cad0c6accae07eb662f518578daeb9633d1 with merge 79fe51e608eada3701c0282b1c80486f91ce9ace...

:sunny: Test successful - checks-actions_land_blocking_test, checks-circle_commit_workflow
Approved by: davidiw
Pushing 79fe51e608eada3701c0282b1c80486f91ce9ace to master...

authors: bors-libra davidiw huitseeker


text:
[mempool] refactor garbage collection to be sub-quadratic runtime

Motivation
The current implementation of garbage-collection in mempool has runtime O(n^2) - for each txn to be removed, we iterate through all the subsequent txns for that given account to try and park them, and worst-case it is possible that all the txns that were parked may be txns we need to remove anyway - this is inefficient. This PR refactors such that the runtime is sub-quadratic O(n log(n)): O(n log n) from sorting the gc-ready txns, and O(n) from parking all txns for an account with n txns
Test Plan
Existing tests

/land

:broken_heart: Test Failed - Build images and run cluster test

/land

:broken_heart: Test Failed - Build images and run cluster test

LBT/CT is still having issue. I just pulled its plug.  Try to /land again.

/land

authors: bors-libra christinacelee sausagee


text:
Workaround/replace/remove unmaintained Jenkins plugins

Abandoned extremely old plugins are potential security and integration hazards.
If there's a possibility to do so, dependency on them should be removed or effort should be made to maintain them again.
List of the least maintained plugins used in LCCI as of 7.11.17:
filesystem_scm:
(WARNING!) Extremely old (6y since last release) plugin.
Tracks changes in the filesystem like it was an SCM repo.
Oleg Nenashev got control over plugin and currently tries to modernize it.
Github repo
saferestart:
(WARNING!!!) Extremely old plugin (5y since last release). Allows restarting Jenkins safely: it's waiting till all builds in progress finish before launching restart.
simple-theme-plugin:
(WARNING!!!) Extremely old plugin (5y since release).
Custom CSS styling and JS on the page.
(WARNING!!!) Potentially hazardous due to its nature and age.
description-setter:
(WARNING!) Old plugin (3y since last release).
Sets build description based on build logs.
log-parser:
(WARNING!) Old plugin (2y since release).
Parses Jenkins CI build logs and collects warnings and errors.

As I Jenkins contributor/user, I would say that 4 plugins are more or less fine. FileSystem SCM plugin is not fine for sure, but I am working on its facelift.
Do you have any specific concerns about other plugins in the list?

My personal biggest concern is simple-theme-plugin. Client-side Javascript and XSS threats are real and if you choose to use Java web UI at all you should try to be up to date at all costs.

Sorry, missed the update

If it is realistical I would recommend to exclude client-side JS completely. Maybe I'm bit paranoid because I tried to make tor services one day but still.

It is not realistic in Jenkins. It moves towards Javascript UIs. The Simple Theme plugin itself is not a security risk, a vulnerable theme would need to be explicitly configured. I would be rather aware about BlueOcean in such case.
I will think whether it is possible to add feature flags to the packaging.

FileSystem SCM will be updated in https://github.com/librecores/librecores-ci/pull/40

authors: Houkime oleg-nenashev

repo: librecores/librecores-ci


text:
:Z for docker container on SELinux-enabled distros

 Issue by axelsimon
Tuesday Aug 01, 2017 at 15:32 GMT
Originally opened as https://github.com/plietar/librespot/pull/230

Added a comment to help run the cross-compile docker container on SELinux-enabled distros (ie: add :Z at the end of the docker volume argument).

axelsimon included the following code: https://github.com/plietar/librespot/pull/230/commits

Added.

repo: librespot-org/librespot


text:
Make file extensions case insensitive

This PR makes file extension limitations case insensitive.
This was a bug I noticed while trying to upload an R file 😅

Yes fair point! Would you mind opening up an issue so we can keep track of that? 🦦


text:
libxml2 copyright missing

The the libxml2 vendor subdirectory of libxmljs does not contain the upstream copyright notice even though the MIT license wording states that

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software

as the sole condition of use. We should make sure to include them in the source repository, and in the sources as provided by the npm registry.

Sorry, I wrote into the wrong browser tab. This should have been what's now #419, i.e. a pull request. Apparently I'm too tired to do such things properly…

repo: libxmljs/libxmljs


text:
Adjustable Memory Allocation Functions

Hi, mini MP4 was works as expected for me, and I adopt this instead old and harder to intergerate libmp4v2 to generate h264 encoded stream in MP4 container. But could I have adjustable malloc functions to custom functions? My reasons is beacuse I'm prefer to use another memory allocator (e.g mimalloc) than the CRT default one, but I think it will somewhat useful for task including custom memory tracing functions, etc. I mean, like the miniaudio has adjustable macros for MA_MALLOC, MA_REALLOC and MA_FREE. Thanks!

Hi) That's a good idea. Will do it at some point.

authors: lieff thiekus


text:
Link to storybook doesn't work

Link in readme to the storybook page doesn't work

Fixed in #35

repo: lienputnina/react-components-for-you


text:
Add new feature Code formatter

HTML, CSS, JavaScript, JSON, YML

2 days

repo: lifeparticle/binarytree


text:
gulp watch not taking correct version number

Gulp Watch with liferay-theme-tasks 7.0.0 does not consider the version number in package.json. Instead always creates a theme with version 1.0.0. Therefore after ending gulp watch and after a new gulp deploy two themes with different versions are active.
Problem occurs on linux with liferay 7.0.x

We have significantly changed the watch implementation in #190 with the hope of fixing the existing issues. At the time of writing, that's in the "master" branch and will be included in the next release (v8.0.0-rc.4). The master issue for tracking the rewrite is #127, so I am going to close these separate tickets and ask that we consolidate further discussion about watch there.

authors: schwaaab wincent

repo: liferay/liferay-js-themes-toolkit


text:
Create a MANY server mock crate

This can even be part of the many cli tool. To facilitate with development against MANY modules that don't exist yet.

As a user, I want to be able to start a server that will send pre-configured responses to requests.
Response configuration should be located in a configuration file.
This will be used to develop and facilitate module development and integration.
E.g.:
{
 "endpoint": "ledger.send",  // The endpoint
 "response": "....",         // The response to send back
}

Some of the responses will probably require some value from the request itself, like identities, etc. Hardcode as much as you can, but you could maybe implement some DSL/Tagging.
Please make a plan before implementing anything so we can review and iterate on it.

authors: fmorency hansl

repo: liftedinit/many-rs


text:
Module file names don't allow hyphens

I would like to be able to name modules in standard xquery "train-case" format.
e.g. my-xquery-module.xqy
This is pretty normal in XQuery but is not supported by the plugin which tries to sanitize the filename into camel case for some reason.
It should either allow hyphenated names or explain in the error message why it is refusing to create the file. I had to look in the source code to find out what caused the warning message.
(Really great plugin by the way!)

Hi,
Thanks for raising the issue.
The reason for not using hyphenated names was that IDEA in many places (internal IDEA engine code) does rely on names not containing any characters that are not alphanumeric.
I'll review if this is still the case and if not then the rules might get relaxed!
Thanks for using the plugin and letting me know how to improve it!

Hi
The new rules for function names are as below:

has to start with either _ (underscore) or letter
can contain letters, numbers, hyphens, underscores
Hope these rules make sense now

authors: eurochriskelly ligasgr

repo: ligasgr/intellij-xquery


text:
Switch to Dart Sass

Libsass is now officially deprecated as of october 2020 (https://sass-lang.com/blog/libsass-is-deprecated), and had not recieved support for any new language features since november 2018.
This switch will bring the last 3 years of sass improvements to users, including the use of sass modules (fixes #29)
It seems that libsass was outputting the closing brace on the same line as the last member of the block, with a trailing newline, whereas dartsass now puts the closing brace on its own line, with no trailing new line, the tests have been updated to reflect this.
Since DartSass is compiled down to javascript, this also required a javascript engine as a depenedency, this is accomplished with https://github.com/Taritsyn/JavaScriptEngineSwitcher and their ChakraCore packages. The chakra core packages could be removed, requiring consumers of this library to register a default Javascript engine with JavaScriptEngineSwitcher, which the dartsass wrapper would make use of.
I have made a best effort attempt at mapping the existing WebOptimazerScssOptions that were based on SharpScss.ScssOptions to their equivelant DartSassHost.CompilationOptions.
I am willing to make any changes needed to this PR, just let me know.

Thanks @Thelonedevil ! Going to test this out.

authors: HybridSolutions Thelonedevil


text:
Add cloud-init config for DHCP based network config/Bump dependencies

Switch to DHCP based IP address assignment for cluster nodes using
MAC based reserved IP addresses in DHCP server
Bump dependencies
Bump sbt to 1.4

Looks good to me. Perhaps need to mention new akka-pi-os-dhcp.yml file in docs

True! I plan to do an update of the docs: I recently ran the workshop for a group of students, and it's clear that the docs need some attention.

repo: lightbend/Pi-Akka-Cluster