text:
location sharing UI

New location sharing UI and input bar on mobile.
Go
1.) Add a new map server on the local HTTP server for the purposes of rendering a location preview on the frontend.
2.) Change how GetCurrentPosition works to always post the last known position first, and possibly update if we get a newer coordinate within the 4 second window.
JS
1.) Add new input bar styles for exploding mode and the new "more menu".
2.) Add some common slash commands to more menu.
3.) Add new location interface.

cc @adamjspooner

Added the new display stuff as well.


text:
Require login for passphrase recover

This PR makes keybase passphrase recover refuse to work if you're not logged in. It will now tell you to login.
$ keybase passphrase recover
Passphrase recovery requires that you are logged in first.
Please run `keybase login` before `keybase passphrase recover`.
But don't panic, you can log in with a paper key.

The previous behavior on a completely new machine was to do this, which left people a bit stranded.
$ keybase passphrase recover
Password recovery will put your account on probation for 5 days.
You won't be able to perform certain actions, like revoking devices.
Continue with password recovery? (type 'YES' to confirm): YES
▶ ERROR could not find UID or username for self

The previous behavior on a machine which was logged out but knew what UID it used last was this. Which is better in that it's just one command, but is worse in that it requires using a paperkey with no option to use another device, and it asks for the new passphrase before the paper key.
$ kbu passphrase recover
▶ WARNING Running in devel mode
Password recovery will put your account on probation for 5 days.
You won't be able to perform certain actions, like revoking devices.
Continue with password recovery? (type 'YES' to confirm): YES
>>> Asks for new passphrase
>>> Asks for paper key

r? @patrickxb
I know you said to do the login check in the engine, but the same engine gets used by the gui too, and this LoggedInLoad  seemed simple, ok?

TestPassphraseRecover is failing on this. I see how but do you know why? It looks like tc2 here is not logged in. But it's the device that signed up, so I'm not why that would be. Maybe it's related to calling LoggedInLoad from outside an engine?

the tests only run on engine code, not client code.

But the error that the test spits out is this one from the client.

Which test is failing?

oh a systest

Yeah, a systest. TestPassphraseRecover

NewService is called with tc.G, not tc2.G.

Ah, so tc2 has no service at all? Then I'll give tc2 a service as well and that'll fix it? I'm surprised Signup works without a service.

Ok, ready for another look!

The commits 8a909186176a...b1a11dc777e5 introduce visual changes on linux. :mag_right: 1 changed

Changed: Chat_Input-Emoji_Open (before) (after)

The commits 8a909186176a...b1a11dc777e5 introduce visual changes on linux. :mag_right: 1 changed

Changed: Chat_Input-Emoji_Open (before) (after)

The commits 8a909186176a...b1a11dc777e5 introduce visual changes on linux. :mag_right: 1 changed

Changed: Chat_Input-Emoji_Open (before) (after)

source: gharchive/pull-request

authors: keybase-ci-visdiff mlsteele patrickxb

repo: keybase/client

license_type: permissive

license_source: github-api


text:
git-remote-keybase: check for a running service

Dialing it seems to be the best platform-agnostic way to check for a running service.  Just checking for the socket file doesn't work on Windows.
If the service isn't running, the user will see:
git-remote-keybase error: (1) The Keybase service is not running for this user.

cc: @malgorithms
Issue: KBFS-2514

thanks for cc'ing - I assume to talk about the copy? I'm cc'ing @oconnor663 - who suggests that we should probably remind people of the exact command to start it, since they're only ever taught it once, during their initial install, and may have forgotten.
If it has to be the same on all platforms, can we just give all instructions, like:
Error: Keybase isn't running. Windows/Mac: open the Keybase app; on Linux: `run_keybase`

Although if can be different on Windows/Mac/Linux, that can obviously be simplified. I'm happy either way.

@malgorithms it sounds like @strib is more worried about detecting this problem in a platform-independent way, than about what to print after we detect it?

The detection is done, I'm happy to take suggestions on printing.  Was cc'ing @malgorithms because you asked for this feature.
That's fine but I actually don't know what the commands are on mac/windows, as it's all handled by packaging.  I could generically say keybase ctl start?

Two options on Linux:

keybase ctl start will start just the Core service.
run_keybase will (re)start everything, including the GUI.

If the user's situation is that the Core service has crashed or something, then the first command should fix it. (Though we also plan to auto-restart it using systemd really soon.) But if the user's situation is that nothing at all is running, including kbfsfuse, then they'd need to run the second command to get going. Do you guys know if that second situation comes up in practice?

In this case they were running nothing at all.  It's pretty rare, but it happens.  I suggested keybase ctl start because technically git-remote-keybase only requires the service to run, and not anything else.  But of course they won't be able to make any repos without kbfsfuse running as well.

That's fine but I actually don't know what the commands are on mac/windows

I think the mostly likely scenario on mac/windows is just that the user quit the app (from the menu) and needs to start it back up by double-clicking its icon. So telling them to open the app is likely fine.
there is a deeper problem for some macos users (and cc @maxtaco who was just talking about it) where some mac users can't get the app to start at all due to installation/permission problems. I don't think customizing this message for them is so important, as we should be giving them errors on attempts to start up, and they'll be reporting the bugs to us elsewhere. Also, I think Max is going to have a failsafe added...
So I guess in summary for mac/windows we should just tell them to start the app, and it'll cover all the cases that are solvable.

keybase ctl start will start just the Core service.

I'm going to make a core ticket to ask about this....the help suggests this is all platforms and all services...if it's making keybase half work, maybe it shouldn't be showing up in our help.

I'm going to make a core ticket to ask about this....the help suggests this is all platforms and all services...if it's making keybase half work, maybe it shouldn't be showing up in our help.

I don't think this appears in any help text, I was just throwing it out there as a suggestion.  I don't think any changes to core are needed.  I can change the text to run_keybase on Linux and "open the app" everywhere else.

For what it's worth, Linux users also have the option to "open the app" in the regular "find the Keybase icon inside your desktop's Applications menu" sense, which basically just runs run_keybase under the covers. However, I think most desktops do this clever thing where if they detect that the Keybase window is still running, they'll just foreground it instead of running the command again. (For most regular GUI apps that don't hard-restart themselves like we do, that prevents the confusing condition where you have two copies of the same app running at once. Probably Windows and Mac do something similar?) It's possible that if a user was in an oh-no-service-has-crashed state, the GUI could still be alive, and the "open the app" action might just foreground it instead of fixing the problem.
So yeah, slight bias towards telling them to run_keybase manually.

authors: malgorithms oconnor663 strib

repo: keybase/kbfs

license_source: bigquery


text:
journal: add an MDOps.ResolveBranch function for squashing branches

This is Phase 1 in speeding up CR under journaling and coalescing journal entries together.  It allows the upper layers to specify a revision that completely replaces the current conflict branch, and avoid flushing blocks that have since been deleted.  This involves:

Replace the current MD conflict branch with a journal that contains only one MD representing the resolution.
Mark certain block journal entries as ignorable.

The next phase will use ResolveBranch from the conflict resolver, and turn off journal flushing when on a conflict branch.  This should significantly speed up CR since everything needed to run it is guaranteed to be locally available, and will also reduce the number of blocks we have to flush.
After that, the journal will start "faking" conflicts in order to occasionally coalesce MD journal entries together into a single entry, which should speed up flushing, reduce disk requirements, and hopefully reduce the size of conflict branches when they do happen.
Issue: KBFS-1637

Fixed up the nits/bugs.  Pending the unresolved discussion, if we decide to keep the code structure as is this is ready for another pass, otherwise I'll fix up that part.


text:
Failed at: #if !object[key]??  [in template "login.ftl" in function "toJsDeclarationString" at line 253, column 17]

Hi,
I have a problem with errors below when I try to deploy Keycloak themes to a server
- Failed at: #if !object[key]??  [in template "login.ftl" in function "toJsDeclarationString" at line 253, column 17]
- Reached through: ${toJsDeclarationString(.data_model, ...  [in template "login.ftl" at line 20, column 19]

Last successfully deploy was on 28th September 2024 and since this time I don't do changes in Keycloak theme
I have Keycloak v25.0.6, Keycloakify v10
Edit: CI updates Keycloak to latest (v26.0.0) and there are the problems with error, I lock Keycloak version to 25.x.x and it's working

The version of keycloakify your theme was build with probably released before Keycloak 26, so it doesn’t include the compatibility layer for that version. When I mention that Keycloakify themes are compatible with all Keycloak versions, I mean they are compatible with versions available at the time of the Keycloakify release.
To support a newer version, you’ll need to update Keycloakify to the latest version of the major release you're using and rebuild the theme.

source: gharchive/issue

authors: TommyNT garronej

repo: keycloakify/keycloakify

license: MIT


text:
pyright: Ignore a line in keylime/config.py due to newer pyright

Have pyright ignore a line in the code that would otherwise cause the following issue with newer versions of pyright:
.../keylime/keylime/config.py:23:26 - error: Argument of type "map[Any]" cannot be assigned to parameter "__iterable" of type "SupportsIter[_SupportsNextT@iter]" in function "iter"
  "map[Any]" is incompatible with protocol "SupportsIter[_SupportsNextT@iter]"
    TypeVar "_T_co@SupportsIter" is covariant
      Type "map[Any]" cannot be assigned to type "SupportsKeysAndGetItem[str, Any]"
        "map[Any]" is incompatible with protocol "SupportsKeysAndGetItem[str, Any]"
          "keys" is not present
          "getitem" is not present (reportGeneralTypeIssues)
.../keylime/keylime/config.py:23:26 - error: Argument of type "map[Any]" cannot be assigned to parameter "__iterable" of type "_GetItemIterable[_T@iter]" in function "iter"
  "map[Any]" is incompatible with protocol "_GetItemIterable[_T@iter]"
    "getitem" is not present (reportGeneralTypeIssues)
Signed-off-by: Stefan Berger stefanb@linux.ibm.com

Codecov Report

Merging #1267 (15ff051) into master (64e44d8) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

Flag
Coverage Δ

packit-e2e
74.75% <ø> (ø)

testsuite
60.19% <ø> (ø)

unittests
1.94% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Is it possible to fix the version of pyright we use for testing this?

Is it possible to fix the version of pyright we use for testing this?

@mpeters we could but we should be using the latest version, so that it catches more issues. We are doing the same with pylint.

What would be the alternative, doing a cast after the isinstance()?

This here seems to work also:
return dict(cast(Iterator[Any], iter(map(convert, data.items()))))

I pushed the version with the cast now as a patch on top of the previous solution. Let me know what you prefer and I'll squash the two solutions or remove the 2nd patch.

authors: THS-on codecov-commenter mpeters stefanberger

repo: keylime/keylime


text:
Added codecov.io description to TESTING.md

Signed-off-by: Karel Srot ksrot@redhat.com

Codecov Report

Merging #984 (f304f66) into master (458b409) will not change coverage.
The diff coverage is n/a.

Flag
Coverage Δ

packit-e2e
56.95% <ø> (ø)

testsuite
27.34% <ø> (ø)

unittests
13.13% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

authors: codecov-commenter kkaarreell


text:
🛑 진주경찰서 (Jinju Police Station) is down

In d79d39a, 진주경찰서 (Jinju Police Station) (http://www.gnpolice.go.kr/jj/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 진주경찰서 (Jinju Police Station) is back up in 034c325 after 82 days, 3 hours, 36 minutes.

repo: keywordnew/jinju-watchtower


text:
🛑 진주경찰서 (Jinju Police Station) is down

In d1560d6, 진주경찰서 (Jinju Police Station) (http://www.gnpolice.go.kr/jj/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 진주경찰서 (Jinju Police Station) is back up in 3e24060 after 8 minutes.


text:
🛑 Joplin Cloud dashboard is down

In f1e104c, Joplin Cloud dashboard (https://joplincloud.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Joplin Cloud dashboard is back up in 6a4e5f4 after 1 hour, 3 minutes.

repo: keywordnew/uptime-for-joplin


text:
React capstone project - Metrics webapp

Hello ,
In this Pull Request I have:

selected the narrative API: COVID-19 data I used,
built files structure for my React app,
prepared routes and navigation in my app,
made sure that a user can display a list of items and filter them and data should come from the API,
created the tests for the application,
styled my components to match the design,
deployed the project and test for final details,
Here is the link to my presentation
Thank you

Hello to the next Reviewer 🙂
The reason why I disable Eslint is the API that I am using, the camelcase can not be solved through linters as the data coming from API are camel-cased. I have solved other linters errors but don’t mind about this 🙌 thank you!


text:
Makefile

Closes #11.
My spam filter caught your reply for some reason, hence the extreme delay between reporting this and offering a PR to fix it. This commit allows people to specify the prefix in a more regular way though, and creates the bin directory if it doesn't exist to avoid people having to manually create that themselves where it doesn't already exist.
With this merged in you would install with make prefix=/example/prefix install and to remove you would do make prefix=/example/prefix uninstall.

Dominyk, thanks.  I've been buried under a load of client work since these came in, and that continues until mid-January, but I will look at this (and presumably merge it) as soon as I can after that.  I apologize for the delay!

No worries, Appreciate life likes to throw hecticness at people with a certain gleeful abandon, no rush :).

I think the last changed line in the diff should say $(bindir)/onetime, actually?  But I'll merge this first and then commit that change.
Thanks, @DomT4 !

Yeah, it certainly could have. Thanks for spotting & fixing that, and the merge. Appreciated!

repo: kfogel/OneTime

license: mit


text:
fix to issue#1778

fixes issue #1778 . @dwightguth please review

lgtm

repo: kframework/k


text:
Support for programatical meta-level sort declarations

WIP. Do not merge yet.

Can one of the admins verify this patch?

Jenkins: add to whitelist

authors: msaxena2 rv-jenkins traiansf

repo: kframework/kore


text:
Skip reput for action required ucj

Ref

https://nanopay.atlassian.net/browse/NP-5489

Issues

The same IdentityMind KYC rule was triggered multiple times during dependent ucjs reput since the ucj status is in action_required.

Changes

Skip reput for action required ucj

https://github.com/kgrgreer/foam3/blob/c67c772f2219688bae234d027790675ef25fcfdb/src/foam/nanos/crunch/CapabilityJunctionStatus.js#L33-L39
The documentation for ACTON_REQUIRED states: "Information is missing for required fields", if so we might not need to reput the ucj with the status. @Nauna @noodlemoodle @jlhughes ?


text:
check if a user is a member of a specific telegram channel

I would like to check if a user of my webapp is a member of my channel to unlock certain features. how can i check this?

@MadhouseSigma You can directly do it from web app. But what I would do is to send send user id to backend and there to check via bot if the user is member of your channel after which you could send unlocked features.
Also, validation data contains user id. During authentication process, you could add this step in backend.
Ideally, you could do this in Flutter directly, but you would need to hardcode bot keys and your channel id which is a high security risk

@MadhouseSigma You can directly do it from web app. But what I would do is to send send user id to backend and there to check via bot if the user is member of your channel after which you could send unlocked features.
Also, validation data contains user id. During authentication process, you could add this step in backend.
Ideally, you could do this in Flutter directly, but you would need to hardcode bot keys and your channel id which is a high security risk

thanks for the assist. I think I'll go the backend rout as well.
while I got you, how would you pass parameters from the bot to the webapp? like for example if a user invites another user and i want to track who invited them.

@MadhouseSigma you can pass args to the web app via link like t.me/bozorbop_bot/bozorchi?startapp=hello . Here hello is an argument. So you could pass id/token of the person who invited, for example

authors: MadhouseSigma khamidjon-khamidov


text:
How to draw Figure 4?

This is a beautifully drawn picture!
Can you tell me how to draw this kind of loss value and model parameter correlation diagram?

We release the reference code to help. See https://github.com/khanrc/swad/tree/main/visualization.

I'm sorry to bother you again, but I've looked at the code in the visualization folder and the SWA related code, and I still don't understand it, and I've encountered a lot of errors. The main problems are:
(1) The import file infer_utils is empty.
(2) What is the content of the file with the suffix "*.pth"?
Thanks a lot!

As written in the README, the visualization code is provided for reference only, not for execution. *.pth files indicate checkpoints. This code, which is our original reference code, may help you better.

authors: WentaoTan khanrc

repo: khanrc/swad


text:
Ratings: Dao support for rating schemes

#3115

insert into rating_scheme_item (scheme_id, name, description, code, color, position)
  (select rs.id, mc.rating_name_r, coalesce(mc.rating_desc_r, ''), 'R', '#DA524B' , 30
   from measurable_category mc
     inner join rating_scheme rs on rs.name = mc.name)
  UNION
  (select rs.id, mc.rating_name_a, coalesce(mc.rating_desc_a, ''), 'A', '#D9923F' , 20
   from measurable_category mc
     inner join rating_scheme rs on rs.name = mc.name)
  UNION
  (select rs.id, mc.rating_name_g, coalesce(mc.rating_desc_g, ''), 'G', '#5BB65D' , 10
   from measurable_category mc
     inner join rating_scheme rs on rs.name = mc.name)
  UNION
  (select rs.id, mc.rating_name_z, coalesce(mc.rating_desc_z, ''), 'Z', '#939393' , 10
   from measurable_category mc
     inner join rating_scheme rs on rs.name = mc.name)

repo: khartec/waltz


text:
Solution to MacOS Overlapping Issue With An Existing Tool

I installed gpt-cli via pip through the instructions. When I tried to run it in my terminal as gpt I found out it executes a different tool that exists in MacOS's called "GUID partition table maintenance utility" which located at "/usr/sbin".

To solve this problem I changed gpt-cli's executable's name from "gpt" to "gpt-cli". Now I'm able to run gpt-cli via gpt-cli command in my terminal.
Solution:
Find executable. In my case it was located in "/usr/local/bin" folder. It was named "gpt". To see if it works you can run ./gpt inside the "/usr/local/bin" folder.
Change its name to something you want. I wanted to run gpt-cli via gpt-cli command in my terminal so I changed its name to "gpt-cli". To do this you can execute mv gpt gpt-cli or you can replace "gpt-cli" with something you want.

Also if you don't want to rename things you can add alias git-cli="/usr/local/bin/gpt to your .zshrc file then you will be able to call git-cli with git-cli command.

As suggested, an alias (in zshrc for example) would be the best solution so we don't need to rename the executable.  Can we close this issue?

repo: kharvd/gpt-cli


text:
Supporting stateful allocators through stateful disposers

Hi,
I'm trying to use LibCDS in a context where I have custom allocators that may contain state. I'm struggling to make this work, and I think the reason is that only stateless disposers are supported. Here's a toy example to express the problem I'm running into:
template <typename T, typename Allocator, typename GC>
class MyList {
    Allocator allocator_;

    struct rcu_disposer {
        void operator()(Node<T>* node) const {
            allocator_.deallocate(node);
        //  ^^^^^^^^^^ Can't have access to the allocator because the
        //             disposer can't be stateful!
        }
    };

public:
    explicit MyList(Allocator const& alloc)
        : allocator_{alloc} // important: the allocator is stateful
    { }

    void erase(int i) {
        Node<T>* removed_node = remove_node_from_list(i);
        GC::template retire_ptr<rcu_disposer>(removed_node);
    }
};

Here, my allocator may contain state. Hence, I want my disposer, who is going to call deallocate(), to hold a reference to that allocator. If I understand correctly, this is impossible to achieve with LibCDS because only the type of the disposer can be passed to retire_ptr, but no instance of that type. Instead, I think being able to do the following would solve my problem:
template <typename T, typename Allocator, typename GC>
class MyList {
    Allocator allocator_;

    struct rcu_disposer {
        Allocator& alloc_;
        void operator()(Node<T>* node) const {
            alloc_.deallocate(node);
        }
    };

public:
    explicit MyList(Allocator const& alloc)
        : allocator_{alloc} // important: the allocator is stateful
    { }

    void erase(int i) {
        Node<T>* removed_node = remove_node_from_list(i);
        rcu_disposer disposer{allocator_};
        GC::template retire_ptr<rcu_disposer>(removed_node, disposer);
    }
};

Hence, I have the following questions:

Is my use case of stateful allocators supported by LibCDS today, and if so, how can I do it?
If this is not supported, is there desire to add support for it?

Thanks!

Hi Louis,
Any SMR (safe memory reclamation schema - HP, buffered uRCU) in libcds uses deferred deallocation. A node of any container may be deallocated after the container has been destroyed. Thus, STL approach where the allocator or reference to it is incorporated into the container makes no sense in libcds. Instead, the stateful allocator must be a global object.
So, solution for your question is:
// your stateful allocator
class MyListAllocator { ... };
// global stateful allocator object
MyListAllocator theListAllocator;

template <typename T, typename GC>
class MyList {

    struct rcu_disposer {
        void operator()(Node<T>* node) const {
            theListAllocator.deallocate(node);
        }
    };

public:
    void erase(int i) {
        Node<T>* removed_node = remove_node_from_list(i);
        GC::template retire_ptr<rcu_disposer>(removed_node, disposer);
    }
};

I agreed, use of global objects is ugly, but I don't know any other solution for concurrent containers based on HP/RCU or any other deferred reclamation. If you know any better solution - welcome, I open for any discussion.
Further, all containers in libcds has Traits template parameter where you can specify an allocator type among other traits. The library actively uses such fact that for any allocator_type you provided in Traits the expression like
allocator_type().deallocate( ptr )

is correct, i.e. libcds frequently uses temporary object for allocator_type. Evidently, in such case allocator_type is just a wrapper around global allocator object:
class MyStatefulAllocator {
public:
   MyStatefulAllocator() {  ... }
    my_type* allocate() { ... }
    void deallocate( my_type* p ) { ... }
private:
    // allocator data
};
MyStatefulAllocator theAllocator;

// wrapper to access to theAllocator in libcds Traits::allocator_type
struct StatefulAllocatorWrapper {
   my_type* allocate() { return theAllocator.allocate(); }
   void deallocate( my_type* p ) { theAllocator.deallocate(p); }
};

What to do if your stateful allocator is a template class and has two instance for type T1 and T2?..
template <typename T>
class MyStatefulAllocator {
public:
   MyStatefulAllocator() {  ... }
    T* allocate() { ... }
    void deallocate( T* p ) { ... }
private:
    // allocator data
};

One possible solution: create two global instance for type T1 and T2:
MyStatefulAllocator<T1> theT1Allocator;
MyStatefulAllocator<T2> theT2Allocator;

and wrapper:
template <typename T>
struct allocator_wrapper;

template<>
struct allocator_wrapper<T1> {
    T1* allocate() { return theT1Allocator.allocate(); }
    void deallocate(T1* p ) { theT1Allocator.deallocate( p ); }
};

template<>
struct allocator_wrapper<T2> {
    T2* allocate() { return theT2Allocator.allocate(); }
    void deallocate(T2* p ) { theT2Allocator.deallocate( p ); }
};

Now you can use allocator_wrapper<T1> and allocator_wrapper<T2> in container Traits parameter and the wrappers will select global stateful allocator objects correctly.

Thanks for your detailed answer! At the time of asking the question, I had not thought about the additional hurdle that deferred reclamation represented, but now it's clear. However, I think this could still work; in addition to holding on to the pointer you want to retire, you could hold on to the deleter (as in std::unique_ptr deleter) you want to use to delete the pointer. If you make a copy of the deleter, you could still delete the pointer after the container has gone out of scope. It would be the responsibility of the user to make sure that the deleter is still valid even after the container may have gone out of scope. This would require additional storage in the GC, which may or may not be acceptable.
Thoughts? If you think this is not something that LibCDS can support, I might have a shot at it on my own.

Yes, that's how it works now. If you look at cds/gc/details/retired_ptr.h where retired_ptr declared you will see (the code below is simplified):
/// Pointer to function to free (destruct and deallocate) retired pointer of specific type
typedef void (* free_retired_ptr_func )( void * );

struct retired_ptr {
            void * m_p;        ///< retired pointer to free
            free_retired_ptr_func   m_funcFree;
}

I.e. retired_ptr is not just a pointer - it is combined with a function that will be used to destroy the object m_p points to, as you propose. This construction applyes in HP and uRCU in libcds.
Where is an allocator object here you ask? A little spices like template magic:
template <typename Alloc, typename T>
struct static_functor {
    static void free( void * p )
    {
        // here we destroy ptr via temporary Alloc object.
        Alloc().deallocate( reinterpret_cast<T*>( p ));
    }
};

template <typename T, typename Alloc>
void retire_ptr( T* ptr )
{
   SMR.push_to_retired_buffer( ptr, static_functor<Alloc, T>::free );
}

static_functor converts Allocator that will be used to deallocate ptr to the C-style function and it stores types for Alloc and ptr.
It's all from libcds internals. From libcds' user point of view, you should provide just the allocator type as I wrote early. And in that approach the allocator must be a global object (more precisely, the lifetime of allocator must be greater than lifetime of HP/uRCU object).
Yes, in that schema we could store a pointer to allocator object in retired_ptr, not a type via wrapper function. I thought about it. Then, the allocator object must be a shared pointer. But shared pointer has a lot of performance penalty and memory overhead to manage reference counter that is not acceptable in concurrent containers, IMO.

Thanks a lot for your reply! I understand this more general purpose mechanism may not be suitable for LibCDS because of performance reasons. I do hope there will be a general purpose RCU that works with standard allocators (including stateful allocators) at some point, for people that don't really have the choice to use stateful allocators. For the record, I found the following workaround for passing stateful allocators (but it's not very efficient):
struct rcu_record {
  T* ptr;
  Allocator* allocator;
};

struct rcu_disposer {
  void operator()(rcu_record* record) {
    record->allocator->deallocate(record->ptr);
    delete record;
  }
};

void get_rid_of_stuff(T* ptr) {
  rcu_record* record = new rcu_record{ptr, allocator_}; // assume allocator_ outlives the GC
  GC::template retire_pointer<rcu_disposer>(record);
}

Of course, this is crazy because it requires an allocation just to pass the data around, but I think it works.

Closing this since my question has been answered. Thanks a lot for the support!

authors: khizmax ldionne

repo: khizmax/libcds


text:
Linking add to cart with the menu section.

The items when placed order (clicking on "order now") from menu section can be added to the "add to cart" page .
Like the given below :

Please assign me this task under Gssoc'24.

@suhanigupta23  i have assigned u this issue

Thank You ma'am 🙂. I will try to complete the task in the minimum time
possible.
On Fri, May 24, 2024 at 9:09 AM Khushi Joshi @.***>
wrote:

@suhanigupta23 https://github.com/suhanigupta23 i have assigned u this
issue
—
Reply to this email directly, view it on GitHub
https://github.com/khushi-joshi-05/Food-ordering-website/issues/463#issuecomment-2128465352,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCMYVN23NQGB4Q55WWUYTUDZD2Y6JAVCNFSM6AAAAABIGZH5BGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRYGQ3DKMZVGI
.
You are receiving this because you were mentioned.Message ID:
@.***>


text:
Refaktorizace

Models

academical usage change field to name

Models.py

Laboratory model has a typo in a field address (adress)

remove jQuery?

repo: ki-ujep/facilities


text:
gl projection

http://www.songho.ca/opengl/gl_projectionmatrix.html

https://zhuanlan.zhihu.com/p/400791821


text:
Can't seem to get CustomEnchantments to work

I put in a few custom enchantments in customenchantment.yml, file reloaded with no errors, but the plugin refuses to acknowledge that they exist, and I can't do /ce add or /ce book with them. Even when I get a book by using the GUI, it doesn't work when I try to apply it, and breaks the item that it is applying onto even when it has 100% success rate. Also, I did make sure the spaces were right, I put this in quotes as putting it in code completely messes up the format.
My config:

#Potion Effect Names to pick from: https://hub.spigotmc.org/javadocs/bukkit/org/bukkit/potion/PotionEffectType.html
Enchantments:
Sniper: #Enchantment
Name: 'Sniper' #The in-game name of the enchantment
Color: '&c' #The color of the enchantment on the item
BookColor: '&c&l' #The color of the enchantment on the book
MaxPower: 4 #Max lvl the enchantment goes up to
Categories: #All the categories the Enchantment can be found in
- 'T3'
EnchantOptions: #Customizing Options for each enchantment.
ItemsEnchantable: 'Bows' #You can pick from Armor, Boots, Helmets, Axes, Swords, Weapons(Swords & Axes), and Bows.
BowOptions: #Options that only effect Bow Enchantments.
OnHit: #When the arrow Hits.
#Remove the # to use the Exploding option.
#Ground: #Options if the arrow hits the ground.
#  Explode: #Options for the explosion.
#   Power: 2 #The power of the explosion.
#    PowerIncrease: 2 #How much each lvl will increases the strength.
#    Chance: 25 #Chance of the arrow exploding.
Damaged: #The player that is attacked.
PowerIncrease: 1 #How many times the Potion Effects go up each lvl.
PotionEffects: #Effects that are added to the Damaged.
- 'HARM:1, Time:1, Chance:3'
NatureWrath: #Enchantment
Name: 'Nature Wrath' #The in-game name of the enchantment
Color: '&c' #The color of the enchantment on the item
BookColor: '&c&l' #The color of the enchantment on the book
MaxPower: 4 #Max lvl the enchantment goes up to
Categories: #All the categories the Enchantment can be found in
- 'T3'
EnchantOptions: #Customizing Options for each enchantment.
ItemsEnchantable: 'Weapons' #You can pick from Armor, Boots, Helmets, Axes, Swords, Weapons(Swords & Axes), and Bows.
WeaponOptions: #Options that only effect Sword and Axe Enchantments.
#Remove the # to use the Damager options.
#Damager: #The player with the sword.
#  PowerIncrease: 1 #How many times the Potion Effects go up each lvl.
#  PotionEffects: #Effects that are added to the Damager.
#    - 'REGENERATION:2, Time:10, Chance:25'
Damaged: #The player that is attacked.
DamageMultiplyer: #The Damager Multipler Option.
PowerIncrease: 1 #How many times the Multiplier will go up each lvl.
Multiplyer: 2 #How many times stronger the attack is.
Chance: 5 #The chance of the multiplier happening.
#Remove the # to use the Potion options.
PowerIncrease: 1 #How many times the Potion Effects go up each lvl.
PotionEffects: #Effects that are added to the Damaged.
- 'WITHER:1, Time:7, Chance:1'
- 'POISON:1, Time:7, Chance:1'
- 'CONFUSION:1, Time:10, Chance:1'
- 'BLINDNESS:1, Time:10, Chance:1'
- 'SLOWNESS:3, Time:10, Chance:1'<

The < at the end is not in the original file.

Next time please put files like this in pastebin. You can not have an enchantment name with a Space.
Name: 'Nature Wrath'

@Yukun99 Please tell me if this fixed it. If so close the issue. Other wise please tell me if your still having problems.

Alright trying it now, give me a moment haha, I just updated the plugin :P

I'm getting this error now :P
[21:12:37] [Server thread/ERROR]: Could not pass event InventoryClickEvent to SwarmEnchantments v1.5.1 org.bukkit.event.EventException 	at org.bukkit.plugin.java.JavaPluginLoader$1.execute(JavaPluginLoader.java:310) ~[server.jar:git-Spigot-db6de12-18fbb24] 	at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:62) ~[server.jar:git-Spigot-db6de12-18fbb24] 	at org.bukkit.plugin.SimplePluginManager.fireEvent(SimplePluginManager.java:502) [server.jar:git-Spigot-db6de12-18fbb24] 	at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:487) [server.jar:git-Spigot-db6de12-18fbb24] 	at net.minecraft.server.v1_8_R3.PlayerConnection.a(PlayerConnection.java:1630) [server.jar:git-Spigot-db6de12-18fbb24] 	at net.minecraft.server.v1_8_R3.PacketPlayInWindowClick.a(SourceFile:31) [server.jar:git-Spigot-db6de12-18fbb24] 	at net.minecraft.server.v1_8_R3.PacketPlayInWindowClick.a(SourceFile:9) [server.jar:git-Spigot-db6de12-18fbb24] 	at net.minecraft.server.v1_8_R3.PlayerConnectionUtils$1.run(SourceFile:13) [server.jar:git-Spigot-db6de12-18fbb24] 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_91] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_91] 	at net.minecraft.server.v1_8_R3.SystemUtils.a(SourceFile:44) [server.jar:git-Spigot-db6de12-18fbb24] 	at net.minecraft.server.v1_8_R3.MinecraftServer.B(MinecraftServer.java:715) [server.jar:git-Spigot-db6de12-18fbb24] 	at net.minecraft.server.v1_8_R3.DedicatedServer.B(DedicatedServer.java:374) [server.jar:git-Spigot-db6de12-18fbb24] 	at net.minecraft.server.v1_8_R3.MinecraftServer.A(MinecraftServer.java:654) [server.jar:git-Spigot-db6de12-18fbb24] 	at net.minecraft.server.v1_8_R3.MinecraftServer.run(MinecraftServer.java:557) [server.jar:git-Spigot-db6de12-18fbb24] 	at java.lang.Thread.run(Thread.java:745) [?:1.8.0_91] Caused by: java.lang.IllegalArgumentException: bound must be positive 	at java.util.Random.nextInt(Random.java:388) ~[?:1.8.0_91] 	at me.BadBones69.CrazyEnchantments.ECControl.Enchants(ECControl.java:37) ~[?:?] 	at me.BadBones69.CrazyEnchantments.ECControl.pick(ECControl.java:160) ~[?:?] 	at me.BadBones69.CrazyEnchantments.GUI.onInvClick(GUI.java:150) ~[?:?] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_91] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_91] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_91] 	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_91] 	at org.bukkit.plugin.java.JavaPluginLoader$1.execute(JavaPluginLoader.java:306) ~[server.jar:git-Spigot-db6de12-18fbb24] 	... 15 more

You are going to need to upload your code to Github or something so i can see your lines. But from what I am looking at it looks like something in your config mite be missing. Check line 160 of your code.

Ok, I'm uploading... there are some weird class files when I just copy paste the code out though haha

Like, there are weird class files in the file system :P

The zipped one is here:
https://www.dropbox.com/s/jrbj3lthr1k4cxv/SourceCode.zip?dl=0
The whole system if you want to view before downloading is here:
https://www.dropbox.com/sh/c6oav4ojaozegii/AABEHGaX67vdbT0xHl4fT5Lta?dl=0

Do help me check my guardians code too :P, it might be what's killing the plugin D:

So this works now... weird, but normal enchants don't work, that thread is already here, so I'll close this one :D

repo: kicjow/Crazy-Enchantments


text:
MBL-1258: Analytics, new context property for project

📲 What

new property added project_post_campaign_enabled

👀 See
Go to Segment, any event with project properties such as page viewed event for example, and look for the property

When the project has not activated late pledges:

When the project has activated late pledges:

|  |  |
📋 QA

navigate a bit to any random project, check segment events that the value of the property project_post_campaign_enabled = false
navigate to the baconbaconbacon check segment events that the value of the property project_post_campaign_enabled = true

Story 📖
MBL-1278

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 67.87%. Comparing base (1f9f6bd) to head (c83e781).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@             Coverage Diff              @@
##             master    #1992      +/-   ##
============================================
- Coverage     67.87%   67.87%   -0.01%
  Complexity     2004     2004
============================================
  Files           359      359
  Lines         21895    21896       +1
  Branches       3073     3073
============================================
  Hits          14861    14861
  Misses         5398     5398
- Partials       1636     1637       +1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: Arkariang codecov-commenter

repo: kickstarter/android-oss


text:
[KOGITO-6236] Compilation error if quarkus-resteasy is present but quarkus-resteasy-jackson is not

https://issues.redhat.com/browse/KOGITO-6236
Many thanks for submitting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[ ] You have read the contributors guide
[ ] Your code is properly formatted according to this configuration
[ ] Pull Request title is properly formatted: KOGITO-XYZ Subject
[ ] Pull Request title contains the target branch if not targeting main: [0.9.x] KOGITO-XYZ Subject
[ ] Pull Request contains link to the JIRA issue
[ ] Pull Request contains link to any dependent or related Pull Request
[ ] Pull Request contains description of the issue
[ ] Pull Request does not include fixes for issues other than the main ticket

How to replicate CI configuration locally?

Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.
build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.

How to retest this PR or trigger a specific build:

Run all builds
Please add comment: Jenkins retest this

Run (or rerun) specific test(s)
Please add comment: Jenkins (re)run [kogito-runtimes|optaplanner|kogito-apps|kogito-examples|optaplanner-quickstarts|optaweb-employee-rostering|optaweb-vehicle-routing] tests

Quarkus LTS checks
Please add comment: Jenkins run LTS

Run (or rerun) LTS specific test(s)
Please add comment: Jenkins (re)run [kogito-runtimes|optaplanner|kogito-apps|kogito-examples|optaplanner-quickstarts|optaweb-employee-rostering|optaweb-vehicle-routing] LTS

Native checks
Please add comment: Jenkins run native

Run (or rerun) native specific test(s)
Please add comment: Jenkins (re)run [kogito-runtimes|optaplanner|kogito-apps|kogito-examples|optaplanner-quickstarts|optaweb-employee-rostering|optaweb-vehicle-routing] native

Full Kogito testing (with cloud images and operator BDD testing)
Please add comment: Jenkins run BDD
This check should be used only if a big change is done as it takes time to run, need resources and one full BDD tests check can be done at a time ...

The (build) optaplanner-quickstarts check has failed. Please check the logs.

The (build) kogito-examples check has failed. Please check the logs.

The (build) optaweb-employee-rostering check has failed. Please check the logs.

The (build) optaweb-vehicle-routing check has failed. Please check the logs.

The (build) kogito-apps check has failed. Please check the logs.

The (build) kogito-runtimes check has failed. Please check the logs.

The (build) optaplanner check has failed. Please check the logs.

The (build) kogito-runtimes check has failed. Please check the logs.

The (build) kogito-runtimes check has failed. Please check the logs.

The (build) kogito-examples check has failed. Please check the logs.

The (build) kogito-examples check has failed. Please check the logs.

The (build) kogito-runtimes check has failed. Please check the logs.

The (build) optaplanner check has failed. Please check the logs.

The (build) kogito-examples check has failed. Please check the logs.

The (build) kogito-runtimes check has failed. Please check the logs.

The (build) kogito-examples check has failed. Please check the logs.

The (build) kogito-apps check has failed. Please check the logs.

authors: danielezonca kie-ci

repo: kiegroup/kogito-runtimes


text:
Kogito 2532 - monitoring addon support multiple dmn built in types

Jira: https://issues.redhat.com/browse/KOGITO-2532
This PR adds the support of the remaining dmn built-in types in the prometheus-monitoring-addon.
In particular, the remaining 5 time-based built in types are supported. For all of them, a graph with the quantiles is generated in the grafana dashboards (with different scale and unit measurement):

date and time:

days and time duration:

years and months duration: total number of months (Period - toTotalMonths)

time:

date:

Many thanks for submitting your Pull Request :heart:!
Please make sure that your PR meets the following requirements:

[x] You have read the contributors guide
[x] Pull Request title is properly formatted: KOGITO-XYZ Subject
[ ] Pull Request title contains the target branch if not targeting master: [0.9.x] KOGITO-XYZ Subject
[x] Pull Request contains link to the JIRA issue
[x] Pull Request contains link to any dependent or related Pull Request
[x] Pull Request contains description of the issue
[x] Pull Request does not include fixes for issues other than the main ticket

Hi @danielezonca @jiripetrlik , I think this PR is ready for the first iteration of reviews

jenkins retest this please


text:
Use grid positioning instead of pixel positioning

This a major refactoring in how the UI works. It removes absolute positing of elements and instead uses the CSS Grid Layout. Quite a bit of logic need to be changed:
-jQuery draggable and resizable don't like grid, so needed to use mouse handlers to implement these features in the rotation screen
-Due to how grid positioning works, the html structure of viewport contains lane contains sublane contains blobs has been lost. Instead, it now viewport contains lane and sublane and blob. The html structure can be readded, but then we will have a grid inside a grid inside a grid and positioning logic change alot.
-Due to inability to rely on html structure to position the element, ListView keeps a reference to the model of the container, so that child elements can use it to position themselves.
-CSS grid line now places elements instead of using a custom css style, so changes to the grid do not require changes to the style
-SubLane keep a reference to the title of the parent lane so it can find its position within the parent lane, might be able to remove it...
The reason for this refactor is using absolute positioning is bad in general, and this allow the app to be responsive to screen size. Additionally, it allows us to build things as an area in a grid, which is helpful. Additionally, dates are now displayed as [date](time1 time2 time3 ...) where date is formated like "Wed Nov 3, 2018" and time is formatted like "8 PM".
Added a utility that will probably be removed; PageUtils, which allow you to set the height of an element to the remainder of the page after removing all "height eating" elements calc(100vh - eatenHeight - padding). Gonna try to use the window as the viewport frame instead (which removes the need of the utility).

After reading the code this PR adds, I'm inclined not to approve it due to the refactor to use HTML-grid instead of absolute positioning.
The reasons are as follows:
tl;dr I don't think HTML-grid is meant for a highly dynamic grid, which happens to be exactly what we have.

I failed to find any benefits of HTML-grid compared to absolute positioning. The PR description reads "this allow the app to be responsive to screen size" but I don't see how the current implementation can't. Also, I personally don't think that "using absolute positioning is bad in general" since we got a working mechanism that does essentially the same with much less code.
This PR adds very complex methods and no tests. We don't have a testing infrastructure for this kind of thing yet but I don't think that now is the time to think about having one it either. So the option is to keep complexity low to ensure sanity during development.
JQuery UI is used to make dragging and resizing work. As stated on the PR description, it doesn't work with HTML-grid, so this PRs introduces an in-house solution for what jQuery UI does and puts more complex code on our shoulders to maintain, which I think is bad on the medium/long term.
The vertical grid lines displayed are currently pure CSS and no elements on the DOM, which is already crowded with Blobs. By making these grid lines be divs we are slowing down the application and introducing the need to deal with more stuff on the DOM hierarchy.
Using HTML-grid makes we lose flexibility regarding Blob positioning. By using absolute positioning we can have custom-length Shifts like "6:20 to 15:20" without making it step 20 to 20 minutes while dragging/resizing. This is not possible with HTML-grid or even if it were, it would require us to make changes on the in-house drag/resize code. This is particularly important because UX might have big plans for us in the future, so I don't see why committing to a change that kills these possibilities while we can opt not to do so.
We lost Spots pagination along the way.
This PR is an overkill to what we wanted to achieve: better UI/UX on the roster screens.

Certainly this PR contains valuable changes that I really like, but unfortunately, they're tightly coupled with this major HTML-grid refactor.
I understand that timing is delicate here because we're 2 days away from a code-freeze and these changes are really important to be in the release. My suggestion is we merge this and all the other related PRs on 7.7.x (which will be used to generate the upcoming release) and move on with master without these merges. We will have to reimplement these changes on master based on the current absolute positioning mechanism, but for the reasons stated above, I believe this is what we should do.
Of course, it's @ge0ffrey's decision how we're going to proceed.
Please feel free to add your comments @Christopher-Chianelli @mbarkley.

@tiagobento

It decouples styling code from Java code, so if a designer wants to change the width of a blob, they can just do it in CSS without modifying the scales. Additionally, it allows us to "zoom-in" by adjusting grid-column-width/grid-row-height without modifying the position of every single blob.

Agreed, but the entirety of client side needs tests.

Agree-ish; I like JQuery since it means less code to maintain, but it doesn't automatically change the mouse cursor on edges/show a shift is movable.

That is easily revertible; I changed it so code is more maintainable (so if we change grid width, we don't need to update the code/css styling). I did a test and performance was the same between the two implementations.

Do we want to support this (that is, shifts to the minute granularity)?

It actually still have spot pagination; I need to move the elements to the top toolbar (in fact, this PR should still have spot pagination on the bottom, the viewport frame removal one does not)

Can readd.

Define "overkill" (or rather, overkill how?)

authors: Christopher-Chianelli tiagobento

repo: kiegroup/optashift-employee-rostering


text:
Brainstorm for batch accessioning script

This script would process multiple packages and would:

run accession.py on each one
Accept a starting accession number and increment by +1 for each package.
Record as much information as possible to a CSV that would mirror the accessions register which would allow for easy merging with the live register (method to be determined).
Gather technical metadata to allow for direct import into the database
Analyse the log files to determine the order to accession - it's best to accession the concat alongside the camera card or converted material, even though they will not neccesarily have sequential OE numbers (for example, a camera card could be oe8000, but the concat might be oe8004. Doing a simple grep for 'source=' will provide the UUID, which will then allow you to find the OE number.
A dictionary should be created at the very start with OE/UUID pairings and the various relationships between the packages.
In an ideal world, the filmographic should be downloaded as a CSV so that this could be read, the OE number could be cross references and it would pull out the filmographic title for the accessions record.

Run basic mediainfo check in order to populate the 'format' section of the register.
Perhaps a validation check could run that verify that the AV material is consistent, for example - the only AV material in an XDCAM EX is MP4, and MOV for the converteds.
FFV1mkvvalidate could run on Matroska files as part of accession.py

Here's the current headings for the techrecords:
Reference Number | Donor | Edited By | Date Created | Date Last Modified | Film Or Tape | Date Of Donation | Accession Number | Habitat | Type Of Deposit | Depositor Reference | Master Viewing | Language Version | Condition Rating | Companion Elements | EditedNew | FIO | CollectionTitle | Created By | instantiationIdentif | instantiationDate | instantiationDimensi | instantiationPhysica | instantiationDigital | instantiationStandar | instantiationLocatio | instantMediaty | instantGenerations | instantFileSize | instantTimeStart | instantDataRate | instantColors | instantLanguage | instantAltMo | essenceDataRate_vid | essenceTrackEncodvid | essenceFrameRate | essenceTrackSampling | essenceBitDepth_vid | essenceFrameSize | essenceAspectRatio | essenceTrackEncod_au | essenceDataRate_au | essenceBitDepth_au | instantiationDuratio | instantiationChanCon | PixelAspectRatio | FrameCount | ColorSpace | ChromaSubsampling | ScanType | Interlacement | Compression_Mode | colour_primaries | transfer_characteris | matrix_coefficients
so the workflow could be something like

order sips per collection
remove unnecessary converteds
run order.py so that the correct order of accession can occur
run a batch script that processes the list created by order.py using accession.py, incrementing a +1 to each accession number.
use an exported csv of the filmographic to populate the  title field.
populate an accession csv as best as possible
populate a pbcore tech record csv as best as possib;e
quality control the various outputs
write to preservation storage
merge the contents of the accession CSV with the live register(see if this is doable first)
ingest the filmographic and tech CSVs into the database.

Just pasting this here for now as a possible OE folder rearrangment prior to accessioning - NOTE this is not going to change anything in terms of final acessioned folder structures. That will still follow the AAA0001/UUID/logs,objects,metadata structure) :
----Project Folder
--------Intellectual_entity_folder
----------------master_folder
----------------concat_folder
So for example:
----Hugo Hamilton
--------AF10050
----------------oe8101 (xdcam)
----------------oe8103 (concat)
--------AF10051
----------------oe8104(xdcam)
----------------oe8107 (concat)

Ok, jotting this down now before it leaves my head. This is most likely the most efficient method of carrying out all these tasks and it merges the procedures of

accessioning,
AIP finalisation,
tech record/pbcore creation
Filmographic reference number assignment AND linking to technical records

the merging of procedures isn't just done for the sake of speed and automation - it can be the most accurate way of sharing the OE/accession/filmographic identifiers between the various necessary records. This eliminates a lot of tedious and potentially inaccurate work.
The procedure in a very rough nutshell:

send email stopping users from generating new filmographics.
@aoifefitz2016  orders SIPS per collection
@aoifefitz2016 remove unnecessary converteds
@kieranjol download the filmographic CSV for the particular project
use get_metadata() from the premiscsv branch to analyze filmo csv and return oe_list
check oe_list against input dir. is everything there?
loop through oe list - but use order.py to detect parent.
add option to accession.py to get starting filmo reference number.
Run batchaccession processes, which will update the ref no in the pbcore CSV AND filmo CSV.

The outcome will be:

Packages are accessioned and written to preservation storage
Filmographic reference numbers are assigned
Filmographic records can be ingested to DB TEXTWORKS immediately
Technical records can be ingested to DB TEXTWORKS immediately
Skeleton accession record can be also be made available.

repo: kieranjol/IFIscripts


text:
Deletions are not tracked

There is a bug in the USN library. When a folder is deleted, it causes the file paths inside the folder to not display correctly.
I have a file on my Z drive at Z:\demo\2\bed.jpg. When I delete the folder Z:\demo\2, the files inside this folder are also deleted. Below is my test code.
extern crate ntfs;

use ntfs::journal::{Journal, JournalOptions};
use ntfs::volume::Volume;

fn main() -> std::io::Result<()> {
    let volume = match Volume::new("\\\\?\\Z:") {
        Ok(v) => v,
        Err(e) => {
            println!("error: {:?}", e);
            return Ok(());
        }
    };

    let mut journal = Journal::new(volume, JournalOptions::default())?;

    loop {
        let records = journal.read()?;
        for record in records {
            println!("change: {:?}", record);
        }
        std::thread::sleep(std::time::Duration::from_secs(3));
    }
}

The run result is:
change: UsnRecord { usn: 36176, timestamp: 13350091285.7853214s, file_id: 4785074604081198, parent_id: 4785074604081197, reason: 2147484160, path: "bed.jpg" }
change: UsnRecord { usn: 36256, timestamp: 13350091285.7853214s, file_id: 4785074604081197, parent_id: 844424930132012, reason: 2147484160, path: "\?\Z:\demo\2" }
It is evident that the file path for bed.jpg inside the folder is not correctly printed as z:\demo\2\bed.jpg. Can you fix this bug? Thank you.

Hey thanks for the bug report.
I think that by the time the journal tries to compute the path, it has already been deleted and so it fails.
To fix that the journal would need to track deletions too in the history, like it already does for moves:
 if record.reason
                & (Ioctl::USN_REASON_RENAME_OLD_NAME
                    | Ioctl::USN_REASON_HARD_LINK_CHANGE
                    | Ioctl::USN_REASON_REPARSE_POINT_CHANGE
                    | Ioctl::USN_REASON_FILE_DELETE) // <-- Add
                != 0
            {

And then add some logic to get_usn_record_path/get_file_path.
Sounds reasonable, I'll take a stab at it when I have some time.

Hey thanks for the bug report.
I think that by the time the journal tries to compute the path, it has already been deleted and so it fails. To fix that the journal would need to track deletions too in the history, like it already does for moves:
if record.reason
    & (Ioctl::USN_REASON_RENAME_OLD_NAME
        | Ioctl::USN_REASON_HARD_LINK_CHANGE
        | Ioctl::USN_REASON_REPARSE_POINT_CHANGE
        | Ioctl::USN_REASON_FILE_DELETE) // <-- Add
    != 0
{

And then add some logic to get_usn_record_path/get_file_path. Sounds reasonable, I'll take a stab at it when I have some time.

@kikijiki  Thank you for your reply. I tried adding the line of code "| Ioctl::USN_REASON_FILE_DELETE" as you suggested to see if it could fix the problem, but unfortunately, adding just this line does not solve the issue. It seems that modifying the get_usn_record_path/get_file_path functions might be necessary to fix this problem. I have a limited understanding of the Windows underlying USN and my attempt to fix it myself failed. If you have the time, I would greatly appreciate your help in resolving this. Thank you very much.

Yeah just adding that won't be enough unfortunately.
I'll post an update when I have something working.

I took some time to think about it but I don't think this is easily fixable, my original suggestion was wrong.
By the time the journal is processed, both the directory and the files inside will be already gone, and it's too late to compute the path (or save it in the history). You would need to manually recompute the parent's path using file_id/path map that you maintain, or maybe using cached MFT records.
If it's a specific folder you are monitoring, it would be easier to use a file watcher.
In any case, it doesn't seem like something you can implement in the journal directly unfortunately.
Unless there is some solution I overlooked, I'll have to close this.

I took some time to think about it but I don't think this is easily fixable, my original suggestion was wrong.
By the time the journal is processed, both the directory and the files inside will be already gone, and it's too late to compute the path (or save it in the history). You would need to manually recompute the parent's path using file_id/path map that you maintain, or maybe using cached MFT records. If it's a specific folder you are monitoring, it would be easier to use a file watcher.
In any case, it doesn't seem like something you can implement in the journal directly unfortunately. Unless there is some solution I overlooked, I'll have to close this.

@kikijiki Based on my understanding, it is feasible, as I have tested USN libraries written in other languages, and they can display the complete path even when a file is deleted. When I tested other libraries, they were able to input the USN ID of files that had already been deleted and successfully query their information.
My guess is that there might be an issue with the parameters passed to the Windows API, which refuses to query a USN ID for a deleted file, resulting in an incomplete path. I'm not familiar with these low-level Windows APIs; otherwise, I could have fixed it myself and submitted a merge request for the code.

In theory the file should not be immediately deleted, the MFT record should still exist and be flagged as not in use 🤔
Knowing the file id it should be possible to access that record with the name still cached, then you would need to keep processing all the parents to compute the whole path though.

I'll reopen this since it's a valid request, as you said there should be some way of doing it.
Still not sure how to implement it though.
The MFT class has a function to read a record directly from the fs but it could be very slow.

I'll reopen this since it's a valid request, as you said there should be some way of doing it. Still not sure how to implement it though. The MFT class has a function to read a record directly from the fs but it could be very slow.

@kikijiki  I know how they do it, and I have an example in Go language here. But please note that they are using USN_RECORD_V2, while you are using USN_RECORD_V3. My limited understanding of Windows low-level APIs is the reason why I don't know what additional parameters need to be passed for V3 compared to V2 to enable it to read already deleted USN IDs. This is why I am unable to modify your library based on this code.
In the entire process, you don't need to read the MFT; you just need to focus on the USN, because the example I provided only reads the USN and never read the MFT. My sample code can read a deleted USN ID, then find its parent node, and then read the USN information of the parent node again, all the way up to the root directory. This is the core principle. The current issue is how to pass certain parameters in V3 to enable it to read deleted USN IDs. Hope this help.
Please check the example code below.
https://github.com/y4v8/filewatcher/blob/1a16ffa8c63a176b65c3202eb1daefc75ac0a037/watcher.go#L147

Thanks for the reference.
It's using the record only to retrieve the file_id, that information is in V3 too (V2 and V3 are almost identical).
The main difference seems to be that instead of getting the full path from the API (which does not work for deleted files), it requests only the name and then it computes the path by itself.
It is reading the MFT with GetFileNameByID though, similarly to what MFT::get_record_fs() does, but through the Windows API. I guess that still works because the name is stored directly in the record (which persists after the file is "deleted"), while the API to get the full path I am using now fails in that case.
Anyway we can do something similar then. I'm not sure if it should be done that way by default or only when the existing method fails. I'll try to do some profiling.

Thanks for the reference.
It's using the record only to retrieve the file_id, that information is in V3 too (V2 and V3 are almost identical). The main difference seems to be that instead of getting the full path from the API (which does not work for deleted files), it requests only the name and then it computes the path by itself.
It is reading the MFT with GetFileNameByID though, similarly to what MFT::get_record_fs() does, but through the Windows API. I guess that still works because the name is stored directly in the record (which persists after the file is "deleted"), while the API to get the full path I am using now fails in that case.
Anyway we can do something similar then. I'm not sure if it should be done that way by default or only when the existing method fails. I'll try to do some profiling.

@kikijiki Yes, that's right, this code calculates the full path by obtaining the file names at each level.
Indeed, you can consider adopting this approach to retrieve the full path of deleted files when the existing method fails.
You might not need to worry too much about efficiency issues, as there won't be a large number of deletions at the same time in the Windows system. Even if this method is fully adopted, no problems have arisen during testing on my machine.

The path computation is required for all events, not only deletions.
This new method could be used for all events, only for deletions, or only when the current one fails.

It could be more robust in general though.
Even if it's not a deletion event, it could be that at the time of reading the journal the file got deleted in the meantime, and that would make the path fail.
So it's not just for deletions, the question is if we should do the path computation loop always or just when GetFileInformationByHandleEx fails.

Actually after reading the code a bit, it's not doing a loop there.
It only handles 2 cases, either GetFilenamebyID works on the file, or it does GetFilenameByID on the parent and appends the current record name.
I thought GetFilenameByID was a Windows API thing, but not:
func GetFileNameByID(hVolume syscall.Handle, fileID uint64) (string, error) {
	fd := FILE_ID_DESCRIPTOR{}
	fd.DwSize = uint32(unsafe.Sizeof(fd))
	fd.FileId = fileID

	h, err := OpenFileById(hVolume,
		&fd,
		0,
		syscall.FILE_SHARE_READ|syscall.FILE_SHARE_WRITE|syscall.FILE_SHARE_DELETE,
		nil,
		syscall.FILE_FLAG_BACKUP_SEMANTICS)
	if err != nil {
		return "", errors.Wrap(err)
	}
	defer syscall.CloseHandle(h)

	fileNameInfo := FILE_NAME_INFO{}
	sizeFileNameInfo := uint32(unsafe.Sizeof(fileNameInfo))
	err = GetFileInformationByHandleEx(h, FILE_NAME_INFO_BY_HANDLE, unsafe.Pointer(&fileNameInfo), sizeFileNameInfo)
	if err == syscall.ERROR_MORE_DATA {

		sizeFileNameInfo = (4 + fileNameInfo.FileNameLength) / 2
		buf := make([]uint16, sizeFileNameInfo)
		err = GetFileInformationByHandleEx(h, FILE_NAME_INFO_BY_HANDLE, unsafe.Pointer(&buf[0]), sizeFileNameInfo*2)

		if err == nil {
			return syscall.UTF16ToString(buf[2 : 2+fileNameInfo.FileNameLength/2]), nil
		}
	}
	if err != nil {
		return "", errors.Wrap(err)
	}

	return syscall.UTF16ToString(fileNameInfo.FileName[0 : fileNameInfo.FileNameLength/2]), nil
}

It uses GetFileInformationByHandleEx, which I am already using...

This could be the reason it's working there, I'm not using this flag

Also I am using FILE_GENERIC_READ, but passing 0 might be better too.

Also I'm not handling the ERROR_MORE_DATA case.

I tried adding all three changes but still have the same issue as before 🤔

I made a draft PR in the meantime.

I tried adding all three changes but still have the same issue as before 🤔

@kikijiki Unfortunately, you are still encountering the same problem. Perhaps the usage of V3 and V2 is different? I don't quite understand the specific differences in usage, although we know V3 is better. But maybe we should consider switching to V2?

I made a draft PR in the meantime.

@kikijiki Yes, I agree with his opinion. If V3 can't solve this issue, perhaps we can switch to using V2, and then directly convert the Go code into Rust. Thanks.

In #4 I added support for V2. Every test runs both for V2 and V3.
Unfortunately in my local tests both are failing for deletions.
test journal::test::file_create_v2 ... ok
test journal::test::file_create_v3 ... ok
test journal::test::file_move_v2 ... ok
test journal::test::file_move_v3 ... ok
test journal::test::file_delete_v2 ...  WARN ntfs_reader::journal: Could not get path: usn-journal-test-delete.txt
The file deletion was not detected
FAILED
test journal::test::file_delete_v3 ...  WARN ntfs_reader::journal: Could not get path: usn-journal-test-delete.txt
The file deletion was not detected
FAILED

In #4 I added support for V2. Every test runs both for V2 and V3.
Unfortunately in my local tests both are failing for deletions.
test journal::test::file_create_v2 ... ok
test journal::test::file_create_v3 ... ok
test journal::test::file_move_v2 ... ok
test journal::test::file_move_v3 ... ok
test journal::test::file_delete_v2 ...  WARN ntfs_reader::journal: Could not get path: usn-journal-test-delete.txt
The file deletion was not detected
FAILED
test journal::test::file_delete_v3 ...  WARN ntfs_reader::journal: Could not get path: usn-journal-test-delete.txt
The file deletion was not detected
FAILED

I don't know why switching to V2 still doesn't work. Could it be because of the RUST language? The same code runs fine in GO language.
There's a phenomenon I'd like to share with you, which might be helpful. In the test code at the top of this post, if you remove the following line, it causes a dead loop, but then it can display the complete path normally. However, the cost of doing this is 100% CPU usage on one core.
std::thread::sleep(std::time::Duration::from_secs(3));

One last difference I see is that the go library uses overlapped IO to do asynchronous operations.
I can try using it too to see if it helps.

I tried adding it in the same PR but still failing 🤔
I must be missing something.

I'm gonna try to peek at other implementations as well!
https://github.com/PoorBillionaire/USN-Journal-Parser/blob/master/usnparser/usn.py

I think this might be related to the timing of the deletions.
As an experiment I tried pulling https://github.com/y4v8/filewatcher and adding this bit in main.go:
	for event := range events {
		if event.Reason&win.USN_REASON_FILE_DELETE != 0 {
			if strings.Contains(event.Name, "dummy") {
				log.Println(event.Name, reasonNames(event.Reason))
			}
		}
	}

While this was "watching" I run cargo test on this library. In the test I create a file c:\dummy\dummy_file.txt and then delete the parent directory c:\dummy. The result is that the go library manages to obtain the path correctly only 2 out of 10 times:
2024/03/31 09:24:53 c:\\dummy FILE_DELETE
2024/03/31 09:24:56 c:\\dummy FILE_DELETE
2024/03/31 09:24:57 c:\\dummy FILE_DELETE
2024/03/31 09:24:58 c:\\dummy FILE_DELETE
2024/03/31 09:24:59 c:\\dummy FILE_DELETE
2024/03/31 09:25:00 c:\dummy\dummy_file.txt FILE_DELETE
2024/03/31 09:25:00 c:\\dummy FILE_DELETE
2024/03/31 09:25:03 c:\\dummy FILE_DELETE
2024/03/31 09:25:06 c:\dummy\dummy_file.txt FILE_DELETE
2024/03/31 09:25:07 c:\\dummy FILE_DELETE
2024/03/31 09:25:08 c:\\dummy FILE_DELETE
2024/03/31 09:25:09 c:\\dummy FILE_DELETE

But if I delete the directory from Go instead it always works well. So I think it might be a combination of two things:

Go uses a separate thread that continuously runs in the background, and is able to process events in the middle of the RemoveAll (the directory is the last thing that gets deleted, so it still exists for the deleted files).
Rust's std::fs::remove_dir_all() is faster than Go's os.RemoveAll() so the chances of getting the parent directory path before it gets deleted are lower.

So the solution would be to have this watcher run on a separate thread in an infinite loop continuously reading the journal.
It should start before the directly is deleted, so that it can process the file deletion before the parent deletion happens.
And it would need to be lucky enough with the timing I guess.
This is not really fixed but it's not something that this library is supposed to implement. The journal reading function is available but how it is invoked (sync or async, continuous or chunked, etc.) is left to the user's specific use case.

So the solution would be to have this watcher run on a separate thread in an infinite loop continuously reading the journal. It should start before the directly is deleted, so that it can process the file deletion before the parent deletion happens. And it would need to be lucky enough with the timing I guess.
This is not really fixed but it's not something that this library is supposed to implement. The journal reading function is available but how it is invoked (sync or async, continuous or chunked, etc.) is left to the user's specific use case.

While running the watcher in a separate thread with an infinite loop might seem like a workaround, but it could consume 100% of a CPU core, which isn't an efficient solution.
Actually, there is another solution that will definitely solve this issue, though it will increase memory usage. We could create a map where the key is the USN ID, and it includes the filename and parent USN ID. When a file needs to be deleted, we can retrieve the complete path from the map through a step-by-step query, print the full path of the file to be deleted, and then remove the corresponding node from the map.

@peter-parker-git That would work only for files that get created after the watcher starts monitoring the journal. Even if you set the option to process the journal from the start, the journal has finite size so it will contain only file creations of the past few hours/days.
To make it work properly you would need to initialize the map by first scanning the MFT and then keeping it up to date with journal events. More realistically, you could initialize it only with the files of some folder you are interested in, instead of the whole volume (so just a file walk instead of loading the MFT).

@peter-parker-git That would work only for files that get created after the watcher starts monitoring the journal. Even if you set the option to process the journal from the start, the journal has finite size so it will contain only file creations of the past few hours/days.
To make it work properly you would need to initialize the map by first scanning the MFT and then keeping it up to date with journal events. More realistically, you could initialize it only with the files of some folder you are interested in, instead of the whole volume (so just a file walk instead of loading the MFT).

@kikijiki Hello, you might have misunderstood. The specific approach is that when the program starts, it scans the entire hard drive for the USN IDs of all files and records the file USN ID, names and parent node USN ID, then stores them in a map as I just described.
Next, it starts listening for USN changes, checking every 500 milliseconds for the latest changes. For example, if a folder is deleted and many files within it are also deleted, the path may not be correctly retrieved due to the folder's deletion.
However, this is not a problem as our in-memory map acts like a complete backup, allowing us to find the full path using the parent USN ID and display it. Since the files are deleted, our task is to remove the corresponding USN IDs from the map. This method ensures that a complete path can be outputted. I have a 2TB hard drive, and using this method only takes up a few dozen megabytes of memory (I conducted tests using Go based on the Go example link I shared with you earlier).

That's what I said basically, I think you are confusing the file reference number with the USN though.

Owner

Thank you for clarifying. I thought that the USN log queried in the following way (in Go language) could contain all the USN changes on a disk. If this method can only scan recent changes, such as from the past few days, then indeed, scanning the entire MFT is necessary.
err = syscall.DeviceIoControl(volumeHandle, IOCTL_FSCTL_QUERY_USN_JOURNAL, nil, 0, (*byte)(unsafe.Pointer(&queryUSNData)), uint32(unsafe.Sizeof(queryUSNData)), &bytesReturned, nil) 	if err != nil { 		log.Fatalf("Failed to query USN journal: %v", err) 	}
Can you tell me how to correlate a file’s USN record with its MFT record? The only method I can think of is relying on the file path. From my understanding, an MFT record does not contain the USN information of the file, and similarly, when a file is modified, the USN record does not contain a reference to the MFT. Only by using the complete path can the two be linked. Then, when a file is deleted, I would know which MFT record needs to be removed from memory. Is there another way?

Both the MFT record and USN record should contain the file id/number, if you use V3 you might have to convert the 128bit reference to 64.

authors: hkhk368 kikijiki peter-parker-git stevenhuyn

repo: kikijiki/ntfs-reader


text:
Adding yflip option

cf. https://github.com/timholy/ProfileView.jl/issues/22
The PR #34 introduces set_default(), so I'm not going to change the default orientation.

The original "flamegraph.pl" uses the inverted option for generating icicle graphs. However, I do not like the name because it is ambiguous.
flip_y is clearer, but the y doesn't make sense on sunburst charts.

yflip seems better than flip_y, since the yflip option is used in Plots.jl and the name does not include non-alphabetic symbols.


text:
[Feature Request] Set a delay between commands

I would like to start by saying that this is a great library and has proven very useful. Just came across an instance where I needed to delay the start of a particular command.
For context Im working on a Shopify theme and am using concurrently to run webpack --watch and theme watch side-by-side. The problem is that I dont want themekit to watch until the first webpack build has run. I would only need a simple delay to make that happen.

I think that's not the best approach. Take a look at this, it wait-on appears to be much more reliable approach. Problem with delay would be how long you want to delay to ensure the files were created.

Yep. wait-on is way more robust.
Thanks for the hint @PeterKottas, I use it at work and didn't even remember 😄

For those looking for how to implement this, look at https://github.com/kimmobrunfeldt/concurrently/issues/65.
The short answer is:
npm install --save-dev wait-on

And then just prefix your command with something to wait for, like:
"app": "wait-on http://localhost:3000/ && node app.js"

authors: HauntedSmores PeterKottas gustavohenke joshuapinter

repo: kimmobrunfeldt/concurrently


text:
Support for svelte 5

Svelte 5 support would be nice, when trying to use it in a svelte 5 project currently i get this warning in the console:
Error: Your application, or one of its dependencies, imported from 'svelte/internal', which was a private module used by Svelte 4 components that no longer exists in Svelte 5. It is not intended to be public API. If you're a library author and you used 'svelte/internal' deliberately, please raise an issue on https://github.com/sveltejs/svelte/issues detailing your use case.

Fair thanks king

repo: kindoflew/svelte-parallax


text:
How to uninstall?

Is there an uninstallation step for this?

delete .vim folder and .vimrc

authors: hgedek robophil


text:
Subdomains on MeshLine

from skfem import *
from skfem.helpers import *

mesh = MeshLine(np.linspace(-1, 1, 100))
mesh = mesh.with_subdomains({'core': lambda p: abs(p[0]) < .22})

basis_epsilon = Basis(mesh, ElementLineP0())

epsilon = basis_epsilon.zeros() + 1.444 ** 2
epsilon[basis_epsilon.get_dofs(elements='core')] = 3.4777 ** 2
basis_epsilon.plot(epsilon).show()

leads to

I'd expect it to be high in the middle and then have on both sides just one transition to the lower value.
Instead it has for x~=.23 two values.

That is a bit mysterious. Most likely a plotting issue. I usually pass explicit nrefs=0 when drawing piecewise constant basis:
basis_epsilon.plot(epsilon, nrefs=0, color='k-').show()

You can see that now there is no double value.

The kwarg nrefs controls how many times the mesh is refined for plotting purposes. When we use piecewise constant basis there is no need to refine for plotting so I set nrefs=0. My guess is that in Basis.refinterp routine (which does the refining for plotting), the point at 0.212 gets different value from two sides of the element interface due to some floating point rounding issue:

This diff will "fix" the issue for me:
modified   skfem/assembly/basis/cell_basis.py
@@ -121,7 +121,7 @@ class CellBasis(AbstractBasis):
         # mesh reference domain, refine and take the vertices
         meshclass = type(self.mesh)
         m = meshclass.init_refdom().refined(nrefs)
-        X = m.p
+        X = 0.999 * m.p + 0.0005

         # map vertices to global elements
         x = self.mapping.F(X)
         ```
         So definitely some sort of floating point issue.

Hmm okay, strange. Is maybe just the order in which the points are plotted wrong? If the two points at 0.212 would be exchanged, it would look perfect :thinking:
But plotting it with nrefs=0 sounds also good :)

Yes I found the issue.
First in Basis.refinterp the endpoints of elements are duplicated in order to draw discontinuities over element interfaces. This is working as intended.
Next a plotting mesh is initialized which has those duplicate nodes. However, in skfem.visuals.matplotlib.plot_meshline the drawing routine clearly cannot cope with such duplicate nodes because it runs argsort and now with all those duplicate nodes, it can accidentally and rather randomly flip their order.

The easiest fix is to separate those points returned by Basis.refinterp by machine epsilon. If I do it by modifying plot_meshline, to draw element-by-element, then the resulting plots will look different:

However, perhaps it makes the discontinuity more apparent?

What do you think? Should this type of a plot have the vertical line or not?

I usually like these lines, as it helps to faster understand the plot, e.g. if the value would just alternate between two values it would take some time to understand if they are really alternating without the lines - especially if there's a large difference between the values
Also the case "000000010111100000" would be quite hard to differentiate from "000000001111100000" without the lines.
But I also see the point of emphasizing the discontinuity, which is somehow a bit more correct 🤔 but then we would also need to discuss if for higher order than linear it's okay to have straight lines between the interpolation points 🤔🤔
I'd lean towards keeping the lines, to have an efficient visualisation

authors: HelgeGehring kinnala

repo: kinnala/scikit-fem


text:
WIP: primitive Orr–Sommerfeld example

Here's a new example, a primitive variables (pressure–volume) version of the Orr–Sommerfeld equation of linear hydrodynamic stability.
This is the example that motivated the addition of ElementLineP2 #235, since that's needed here for the velocity components of the one-dimensional Taylor–Hood elements.
Other features not demonstrated in other examples so far are:

complex unknowns
nonhermitian eigenproblem

These are both handled easily by scipy.sparse.linalg.eigs.
The example might be a bit specialized, so the documentation might need a bit more background.

This is the figure produced by the example, reproducing figure 3.2 of Criminale et al and figure 4.19 of Drazin & Reid.  It's like the figure on Wikipedia except that that plots λ ≡ −j αc so is effectively rotated 90° clockwise, and it's at Re = 5772.22 and α = 1.02056 instead of 10 000 and 1, but still recognizable.


text:
Update aauth.py to add gamecard support

This PR aims to add gamecard support to NintendoClients.
I made a tool that asks the console to complete the challenge, and allow the python script to pass AAuth authentication.
The repo is here: https://github.com/EpicUsername12/nx-netauth-link
Example usage here: https://github.com/EpicUsername12/nx-netauth-link/blob/master/python/example_mk8dx_get_top_competitions.py
It works well and reliably, with a very decent amount of checks.
I have tested against pre-defined values and seeds from AAuth, and they all matched what the console normally returns.

If you agree with adding this to Nintendo clients, i will commit the gamecard example

Looks good. I don't think I want to add the example script, because the purpose of NintendoClients is to do this stuff without a Switch. I could add a link to your repo to the readthedocs documentation though? If we do add an example script, I think it would be best if it focuses on the gamecard only, without MK8DX stuff around it. What do you think?

It will be whatever you decide, it's your software after all;
If you want to add an example script, what would it contain? Code up to the NEX login? Or code up to the AAuth token ?
I'm fine with any

I added a link to your repo to the documentation.

repo: kinnay/NintendoClients


text:
implemented support for testplan custom fields values obtaining

Implemented support for testplan custom fields
This was needed to integrate jenkins with testlink in a more elegant way

Just confirmed in 1.9.14 that the method getTestPlanCustomFieldDesignValue is available in the XML-RPC API.

There are a few parameters missing. The getTestPlanCustomFieldDesignValue method in the PHP API calls the getCustomFieldValue internal method.
This last method receives:

scopeParamName ("scope") (set by the getTestPlanCustomFieldDesignValue with 'design' value)
testPlanIDParamName ("testplanid")
testProjectIDParamName ("testprojectid")
customFieldNameParamName ("customfieldname")
nodeTypeParamName ("nodetype") (set by the getTestPlanCustomFieldDesignValue with 'testplan' value)
nodeIDParamName ("nodeid")
executionIDParamName ("executionid")
linkIDParamName ("linkid")

But if the method works without the other parameters, let's add it anyway and we will add the remaining parameters another time.

Looking good! Merging.

Thanks for the attitude! Are you going to update version in mvn repo soon?

Scheduled for Sunday noon New Zealand time - https://github.com/kinow/testlink-java-api/blob/b94c530259de75e79f353c9080f72cbd58268b3f/src/changes/changes.xml#L8
Should happen on Sunday, or in case I don't have spare time on Sunday, definitely Monday evening.

Oh, many thanks to you, sorry for not finding it on my own

Not a problem, just committed that moments ago :smiley:

authors: kinow maiksaray

repo: kinow/testlink-java-api


text:
Add linkerd component

Add the service mesh tool linkerd as a component of lokomotive. This will be an unsupported experimental component before it graduates over time.
In current context I am not sure how to mark some component as experimental and some as not.

Done in #690

authors: invidian surajssd

repo: kinvolk/lokomotive