Any way to retrieve/pass ref, not from the UI side?

Hi Terry,
The below code updates Text(myAccountID(ref)) each time setAccountID(ref, 'newID') was called.
final Creator<String?> _accountID = Creator<String?>.value(null, name: 'Account ID');
String? myAccountID(Ref ref) => ref.watch(_myAccountID);
void setAccountID(Ref ref, String? value) => ref.set(_myAccountID, value);

I have a case where the _accountID is not used in UI but used as a variable (document ID) in Emitter<Account>.stream... from Firestore. setAccountID is being called not from the UI side but from a class Controller.
class Controller extends Something {
  _doSomething() {
    if (firebaseUser != null) {
      setAccountID(ref, 'firebaseUser.uid');
    }
  }
}

1. How can ref be passed or retrieved in this class?
2. ref.recreate is one interesting item that I am quite curious about. I would probably use it to reset variables to default states. Is there a ref.recreateAll?

Just sharing my feedback. I came across Creator through Medium's recommendation of your article. Found 'Graph' very interesting, (the nodes, its elements and the edges... did a little googling on graph data structure... pardon me if I am wrong...). In my own opinion, I would say Creator is not the easiest to understand as compared to GetX but definitely much easier and straight-forward than 39 state management libraries. I have only 1.5 years of dev experience and I am still lost with the other libraries (except Getx and setState) and it took about 2 days for my 42-year-old frail brain to grasp Creator.
I did my own small performance/memory comparison (listview of network images with texts and search function), Creator vs GetX's Rx/GetBuilder. I must say I am quite pleased with the preliminary outcome particularly on memory usage. The only thing with Creator is that there is slightly a little more to code.
I like the "defining creators in global variables". It is really convenient. No more worries that I will forget to inject dependencies.
Anyway, I will be attempting to switch to Creator for my published marketplace apps. Hopefully, the apps can gain an overall performance boost.
Look forward to more interesting updates and examples, medium articles and growing popularity on Creator!

Hi @iamshaunwu, thanks for trying out the library and sharing your feedback.
As for the questions:

Does something like this works for you?

final controllerCreator = Creator((ref) => Controller(ref), keepAlive: true);

However, it means when you need to use the controller, you need to use ref.read(controllerCreator). I guess you will likely have a ref by then, for example, through context.ref.

That's an interesting question. The closest thing I have now is ref.dispose(). However, it removes everything from the graph, if you could add things back, they will be in the default state.

Implementing something like ref.recreateAll is not impossible, but would be tricky, since we probably don't want derived creators being recreated multiple times. Do you mind sharing your use case a little bit more?

As for your feedback:

Personally I didn't do any performance comparison, because it's not a bottleneck for my app. But I'm glad to hear that you are happy with your performance test result.

Sure I will add more examples to make Creator easier to understand!

Thanks!

Thanks @terryl1900!

Passing of ref: Will give it a try. Sorry, I missed it where you have already mentioned under Service Locator.

Ref.recreate: I had the impression that ref.recreate kind of 'resets' the creators with the below counter app scenario.

// initial creators
countA: 0
countB: 0
sum: 0 (countA + countB)

// functions
void incrementA: countA + 1
void decrementB: countB + 2

// initial UI
Text(${ref.watch(sum)}) shows 0

After tapping incrementA...
countA: 1
countB: 0
sum: 1

// UI updates
Text(${ref.watch(sum)}) shows 1

After disposeAll()...
// Nothing is logged on debug console.
// UI has no updates. No issues here since it is disposeAll.
Text(ref.watch(sum)) shows 1

Then I tapped decrementB.
// I believed the variables were re-added from default and updated with decrementB.
// variable updates are logged on debug console.
countA: 0
countB: -1
sum: -1

// UI has no updates
Text(${ref.watch(sum)}) shows 1

However, when I tried ref.recreate (all 3 variables) instead of disposeAll(),
// 'reset' to initial values
// variable updates logged on debug console
countA: 0
countB: 0
sum: 0

// UI updates
Text(${ref.watch(sum)}) shows 0

My personal opinion is that ref.recreate(countA) is much convenient than, in a non-Creator environment,

re-setting 'countA = 0', and/or
disposing a controller (with the variables inside) then inject the controller when required.

This is just my own opinion. In Creator, not sure if not disposing would hold more memory but for the current state management library I use, not disposing a controller of variables would hog up memory usage.

Names for variables is super useful in logging. How can I include a log to show something is disposed? Would be useful to track if certain creators should be included with keepAlive: true.

About recreate:
If you want to reset a bunch of fields in a table, calling ref.recreate manually for those creators is the way to go. ref.disposeAll or even a potential ref.recreateAll seems overkill since they might affect other creators outside the form.
recreate is designed to just rerun the user-provided function. So there are three cases:

Creator.value('foo') which is equal to Creator((ref) => 'foo'). Recreate will reset the value to 'foo'. This is what you want.

Creator((ref) => ref.watch(number) * 2). Recreate is basically a no-op if the number stays the same.

Emitter((ref, emit) async => emit( getDataFromServer() )). Recreate will re-fetch the data from the server.

About dispose::
Sounds good. I will add the functionality to log the dispose event. Tracked here.

Thanks @terryl1900! In the midst of migrating... =)
Closing this.

Hi @terryl1900,
I would like to ask. Inside a Scaffold, there are multiple creators (no expensive widgets though...). Wrapping only Scaffold with a Watcher populates all UI changes when creators are updated.
Aside from the expensive widgets, what differences would there be or things to take note when wrapping only Scaffold  with a Watcher versus wrapping each creator with a Watcher?

Just sharing with regard to my earlier question on passing Ref to functions in "controller" class, I found a better way to pass Ref with mixin. Do enlighten if you feel this otherwise.

Create a mixin.

mixin SomeController on StatelessWidget {
  void doSomething(Ref ref) {}
  Future<String?> getString(Ref ref) {}
}

Add mixin to UI.

class MyHomePage extends StatelessWidget with SomeController  {
  const MyHomePage({super.key});

  @override
  Widget build(BuildContext context) {

    return Scaffold(
        appBar: AppBar(
          title: const Text('Counter App'),
        ),
        body:  Center(
          child: TextButton(
            onPressed: () => doSomething(context.ref),
            child: Text('Do Something'),
          ),
        ),
      );
  }
}

Hello, this is my personal account. I'm moving this project to my personal account.
As for updating scaffolding, so those creators are only used in the scaffolding widget, not its descendence, right? I guess the answer depends on your use case. Maybe imagine just using StatefulWidget, whether you want to put the states into one StatefulWidget, or split states into several widgets. The same answer should apply to using creators.
As for mixin, it sure works, as long as you don't need to construct those controllers explicitly since mixin cannot have a constructor.

Nice, got it! Thanks for enlightening!

@liangxianzhe Hi once again!

What does ref.readSelf actually do? Saw the News example but don't quite catch it. What circumstances would you use ref.readSelf.

While I may have yet to encounter such a use case in the midst of my migration, I would like to ask. How can a value be set on a Creator, where it gets an initial value from another Creator/Emitter then stops listening to it. It's like get 1st value, then remove the edge.

/// global_variables.dart
final Emitter<Account?> _account = Emitter<Account?>.stream((Ref ref) async {
    final String? uid = firebaseUser(ref)?.uid;
    return _streamAccount(uid);
  },
);

Account? account(Ref ref) => ref.watch(_Account.asyncData).data;

final Creator<String?> _someData = Creator<String?>((Ref ref) => account?.someData);

String? someData(Ref ref) => ref.watch(_someData);

void setSomeData(Ref ref, String value) => ref.set(_someData, value);

/// UI side
...
     Text(someData(ref)),
...

For example,
a. When the stream receives data, the initial value for someData is "fromStream".
b. Subsequently, User A enters "UserA", which sets someData to "UserA" and continues filling up the form.
c. Assuming the account is a multi-user account, User B happens to be on the form view too, sets the someData to "UserB" and submits the form first, saving all new data to the database.
d. On User A display, someData will be refreshed as "UserB".
How can we make someData (on User A display) retain as "UserA" instead of the new data?

Hello!

readSelf returns the current state of the creator. It should be only used if my_new_state = some_function( my_current_state, other_creator_state).

If you need to get the first value, I guess you could use read rather than watch.

final account = Emitter<Account>(...);
final accountName = Emitter<String?>( (ref, emit) => emit(await ref.read(account).name ) );

// Since accountName is emitter, set value using Future
... ref.set(accountName, Future.value('input form user A'));

It seems you use helper functions to hide _account, then maybe you could expose a account(Ref ref) for ref.watch and a accountRead(Ref ref) for ref.read.
On another note, personally, I would only use asyncData in the UI layer, not in the logic layer unless I really need to differentiate loading vs data state. Using Future seems more natural in the logic layer.

Thanks for enlightening!

Hey @liangxianzhe.
I created an Emitter.
final Emitter<int?> cloudData2 = Emitter<int?>(
  (Ref ref, emit) async => emit(
    await Future<int>.delayed(const Duration(seconds: 2)).then((_) => 2),
  ),
);

As per your last reply, I tried to then set a value after with ref.set(cloudData2, Future<int>.value(10)). However, the UI still shows 2 instead of 10.
            Watcher(
              (BuildContext context, Ref ref, _) => Text(
                ref.watch(cloudData2.asyncData).data.toString(),
              ),
            ),
            ),

What did I miss out?

Hey sorry. My bad. It seems setting Emitter with Future.value doesn't change Emitter.asyncData. Let me see what can be done there.
In the meantime, maybe something like this?
final account = Emitter<Account>(...);

final accountName = Creator<String?>.value(null);
final accountListner = Emitter<void>( (ref, emit) {
  final account = await ref.read(account)); // Just read once
  ref.set(accountName, account.name);
} ) );

// When the user make changes
... ref.set(accountName, 'input from user A');

Hey thanks for the quick reply. Will give it a try and update if any issues.

@liangxianzhe I am experiencing some challenges on streams and hot reload. I am on VSCode, Flutter 3.0.5 and testing on real device - iPhone 13 Pro Max. Here's my code.
Creator<String?> sellerID = Creator<String?>.value(
  null,
  name: 'Seller ID',
  keepAlive: true,
);

final Creator<int> mainViewTabIndex = Creator<int>.value(0, name: 'Main View Tab Index');

final Emitter<SellerAccount?> streamSeller = Emitter<SellerAccount?>.stream(
  (Ref ref) => _streamSellerAccountFromFirestore(ref.watch(sellerID)),
  name: 'Seller Account,
  keepAlive: true,
);

final Emitter<List<Order>?> streamOrders = Emitter<List<Order>?>.stream(
  (Ref ref) => _streamOrdersFromFirestore(ref.watch(streamSeller.asyncData).data?.uid),
  name: 'All Orders',
  keepAlive: true,
);

final Emitter<List<Order>?> activeOrders = Emitter<List<Order>?>(
  (Ref ref, Function(List<Order>?) emit) async {
    final List<Order>? results = await ref.watch(allOrders).then(
          (List<Order>? value) => value
              ?.where(
                (Order order) => order.orderStatus != OrderStatus.completed,
              )
              .toList(),
        );
    emit(results);
  },
  name: 'Active Orders',
);

// DashboardView (UI layer)
                          Watcher(
                            (BuildContext context, Ref ref, _) => Text(
                              ref.watch(activeOrders.asyncData).data != null
                                  ? ref.watch(activeOrders.asyncData).data!.length.toString()
                                  : '0',
                            ),
                          ),

App launches...

a UID (firestore docID) is assigned to sellerID
streamSeller works fine. No issues here for now
streamOrders retrieves only 9 out of 16 docSnapshots
mainViewTabIndex updates correctly when switching tabs

On hot-reload...

sellerID is reseted to null
mainViewTabIndex is reseted to 0, view returns back to first tab
streamSeller then now returns a null
however, streamOrders now retrieves 15 out of 16 docSnapshots

Can you shed some light as to:

Why hot-reload would reset sellerID and mainViewTabIndex?
As for streamOrder, why were only 9 docs retrieved upon launch and then another 6 docs on hot-reload?

If T is a list, create a new list rather than update the existing one.

I am a bit lost with lists. The activeOrders appears correctly on Watcher widget. However, I am not sure if the way I code is correct. Do advise. Thanks in advance.

I cannot see a problem with the code. I think you will need to figure out why sellerID goes back to null. Try to find a minimum working code to repro the issue. Hot reload is fine to me if using the code below. Set sellerID, then hot reload, and sellerID stays the same.
import 'package:flutter/material.dart';
import 'package:creator/creator.dart';

Creator<String?> sellerID = Creator<String?>.value(
  null,
  name: 'Seller ID',
  keepAlive: true,
);

void main() {
  runApp(CreatorGraph(child: const MyApp()));
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: const Text('Counter example')),
        body: Center(
          child: Watcher((context, ref, _) {
            return Text('${ref.watch(sellerID)}');
          }),
        ),
        floatingActionButton: FloatingActionButton(
          // Update state is easy.
          onPressed: () => context.ref.set<String?>(sellerID, 'Foo'),
          child: const Icon(Icons.add),
        ),
      ),
    );
  }
}

As for list. Your code is fine. The below code is not:
final List<String> names = ...;

final a = Creator<List<String>> ( (ref) {
  names.add('foo');
  return names;
});

Because from the library's view, previous state (names) == current state (names), there is no state change.

Because from the library's view, previous state (names) == current state (names), there is no state change.

Does this also apply to a stream that returns a list? I was wondering if this could be the reason why my streamOrders only retrieves 9 at a start where there should be 16 documentSnapshots actually.
final Emitter<List<Order>?> streamOrders = Emitter<List<Order>?>.stream(
  (Ref ref) => _streamOrdersFromFirestore(ref.watch(streamSeller.asyncData).data?.uid),
  name: 'All Orders',
  keepAlive: true,
);

Stream<List<Order>?> _streamOrdersFromFirestore(String? sellerID) {
  return FirebaseApi.to.firestore
      .collection('orders')
      .where('sellerID', isEqualTo: sellerID)
      .where('orderDate', isGreaterThan: Timestamp.fromDate(DateTime.now().subtract(const Duration(days: 30))))
      .orderBy('orderDate', descending: false)
      .snapshots()
      .map((QuerySnapshot<Map<String, dynamic>>? querySnapshot) {
    if (querySnapshot != null && querySnapshot.docs.isNotEmpty) {
      final List<Order> list = <Order>[];
      for (int i = 0; i < querySnapshot.docs.length; i++) {
        list.add(Order.fromDocumentSnapshot(querySnapshot.docs[i]));
      }
      return list;
    }
    return null;
  });
}

Firestone returns new list so that's fine. If you go to Emitter.stream's source code, you can copy how it works and implement an emitter listen to stream manually. Then you can print something to see where is the problem.

Hi @liangxianzhe, just updating you on previous issues that I had.
1. Hot-reload resets creators/emitters
This is resolved. I had a DevicePreview() wrapped over MyApp() and I wrapped CreatorGraph over MyApp() thus in every Ctrl+S then hot-reload, all values were "recreated". I moved CreatorGraph() as top wrapper of everything else in runApp() and done.
2. Missing documents from Stream?
My bad. I overlooked some fields while sorting. Emitter is smooth and perfect.

Great! Thanks for sharing the root cause. That could help others in future.
So have you finished all migration?

No problem. Glad to share them.
I am still in the midst of migrating my marketplace buyer/seller apps from GetX, while at the same time, refactoring some codes and making UI changes. GetX is easy and 'magical', however, depending on your projects, it can be a problem when they get bigger, like in my case... =P
At times, GetX would only allow certain navigations or UI portions on a controller that can make the controller super cluttered. An example would be GetX's Worker that is an event listener. You would create workers inside controller class and put them under onInit. When certain event happens, you need to push/pop a view or show AlertDialog/Bottomsheet, and you can only do so inside the controller. (I think there could be other non-recommended alternative ways but so far, I can't think of a better one other than the above...)
Now, Creator also has a listener that is in a Watcher widget and IMO, it makes the flow and coding cleaner when added on the UI layer. In the below code, I added a Watcher A right above MyApp() to start an authListenerEmitter that listens to uidEmitter and updates isAuthCreator throughout the app lifecycle. When the initial SplashPage (which has a Watcher B) is built, Watcher B watches isAuthCreator and pushes to the relevant page accordingly.
runApp(
      CreatorGraph(
        child: DevicePreview(
          enabled: false,
          builder: (BuildContext context) => Watcher(
            null,
            listener: (Ref ref) {
              /// add global listeners here
              ref.watch(authListener);
            },
            child: const MyApp(),
          ),
        ),
      ),

This is my approach on the redirection of pages based on event. Compared to GetX, while magical, you will still need to manually dispose the workers followed by controller and reinit the controller again if you return to the SplashPage.
Whereas on Creator, a Watcher's listener is automatically disposed after leaving its page (since this Watcher is not longer on screen) and automatically recreated when returning to SplashPage (because Watcher widget is built again).
This is how I understand. Can you share your best practices on listeners? Do you use them to handle navigations based on certain events?

Referencing to https://github.com/flutter/packages/blob/main/packages/go_router/example/lib/redirection.dart, it uses ChangeNotifierProvider wrapped over MaterialApp.router. In GoRouter(), param refreshListenable is Listenable.

How can this be done with Watcher?
How can ref be passed into GoRouter() param redirect: (GoRouterState state) {}?

Something like this. Will add a full example but I don't have time at the moment.
// auth
final self = Emitter<User?>((ref, emit) async {...}, name: 'self', keepAlive: true);

/// Allowed urls. Enum is safer than strings.
enum Url {
  // System
  home('/'),
  login('/login'),
  setting('/setting'),
  splash('/splash'),
  ;

  final String url;
  const Url(this.url);
}

/// Notifier bridges creator with go_router.
class RouterNotifier extends ChangeNotifier {
  RouterNotifier(this._ref) {
    _ref.watch(_listener);
  }

  final Ref _ref;

  /// This notifier will not rebuild since _listener always generate a void.
  /// _listener will rebuild when login user changes and notifier go_router.
  late final _listener = Creator((ref) {
    ref.watch(self);
    notifyListeners();
  }, name: 'routerNotifier');
}

/// go_router creator.
final goRouter = Creator((ref) {
  return GoRouter(
    routes: <GoRoute>[
      // System
      GoRoute(path: Url.home.url, builder: (_, __) => const HomeScreen()),
      GoRoute(path: Url.login.url, builder: (_, __) => const LoginScreen()),
      GoRoute(path: Url.setting.url, builder: (_, __) => const SettingScreen()),
      GoRoute(path: Url.splash.url, builder: (_, __) => const SplashScreen()),
    ],
    redirect: (state) {
      if (ref.read(self.asyncData).status == AsyncDataStatus.waiting) {
        return Url.splash.url;
      }
      // Note here we read instead of watch, so we don't rebuild this creator
      // when login user changes. We rely on refreshListenable to do the work.
      return ref.read(self.asyncData).data == null &&
              state.subloc != Url.login.url
          ? Url.login.url
          : null;
    },
    refreshListenable: RouterNotifier(ref),
  );
}, name: 'goRouter', keepAlive: true);

// main.dart

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    final router = context.ref.watch(goRouter);
    return MaterialApp.router(
      theme: AppTheme(br: Brightness.light).themeData,
      darkTheme: AppTheme(br: Brightness.dark).themeData,
      routeInformationProvider: router.routeInformationProvider,
      routeInformationParser: router.routeInformationParser,
      routerDelegate: router.routerDelegate,
      debugShowCheckedModeBanner: false,
      title: 'My App',
    );
  }
}

Hey thanks a million! I should be able to work it out from here. No worries. You go get busy. =)

A nice thing about this is it can route without context if needed. ref.read(goRouter).go('some url') works fine.

Hi @liangxianzhe,
I have the following code.
// main.dart
ref.watch(authStream);
ref.watch(user);

// globalVar.dart
final Emitter<User?> authStream = Emitter<User?>.stream(
  (Ref ref) => FirebaseAuth.instance.authStateChanges(),
  name: 'Firebase Auth Stream',
  keepAlive: true,
);

final Emitter<User?> user = Emitter<User?>(
  (Ref ref, Function(User?) emit) async {
    final User? results = await ref.watch(authStream);
    emit(results);
  },
  name: 'User',
  keepAlive: true,
);

Assuming no previous login, when the app is launched,
authStream.asyncData: status = waiting / data = null
user.asyncData: status = waiting / data = null

After login, debug console shows
[Creator] Firebase Auth Stream: User(...)
However, on print(), debug console shows the following statuses and datas for both creators.
authStream.asyncData: status = waiting / data = null
user.asyncData: status = waiting / data = null

Next, after a hot-restart, on print(), debug console shows the following.
authStream.asyncData: status = active / data = User(...)
user.asyncData: status = active / data = User(...)

Next, after a sign out. On print(), debug console shows the following.
authStream.asyncData: status = active / data = null
user.asyncData: status = active / data = null

This happens only to Firebase Auth stream and the user Emitter when the app is first launched without a previous authenticated user.
I don't encounter this with Firestore streams. Any issues with my code?

Hey, I'm not following on point 2, where did you do the print command?

On the LoginView with a TextButton(onTap: () => print().

Hmm, I'm not quite sure. My wild guess is maybe your router refresh mechanism or device preview mechanism somehow mess things up. If you could have a minimum reproducible example, I can debug against my firebase project too.
Otherwise, maybe debug by attaching a customized logger to CreatorGraph. The default logger doesn't print changes related asyncData creators. The below one print everything.
class MyCreatorObserver extends CreatorObserver {
  const MyCreatorObserver();

  @override
  void onStateChange(CreatorBase creator, Object? before, Object? after) {
    debugPrint('[Creator] ${creator.debugName}: $after');
  }

  @override
  void onError(CreatorBase creator, Object? error) {
    debugPrint('[Creator][Error] ${creator.debugName}: $error');
  }
}

...CreatorGraph(observer: const MyCreatorObserver(), child: const MyApp())

Noted. I'll give it a try later and update you. I am using Go Router like what you shared previously.

@liangxianzhe tried to figure out how I could reach out to you in private but anyway, I wanted to share that I just published an introductory article in medium here. Feel free to read it. Apart from the top story section, do let me know if there is any mis-information on the technical part.

Hey, @iamshaunwu thanks for the article! I like it and I'm glad to see your point of view!
As for technical details, all seems correct to me, a minor fix would be "ref.create that recreates a Creator/Emitter" should be "recreate".

@liangxianzhe
In the below code, after pushing SecondPage().

counter is disposed
name is not disposed

Shouldn't name be automatically disposed too? I doubt it is related to TextField because TextField was automatically disposed too.
final counter = Creator.value(0);
final name = Creator.value('shaun');

void main() {
  runApp(CreatorGraph(child: const MyApp()));
}

class MyApp extends StatelessWidget {
  const MyApp({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: const Text('My App')),
        body: Center(
          child: Column(
            children: [
              TextField(
                onChanged: (value) => context.ref.set(name, 'terry'),
              ),
              Watcher(
                (context, ref, _) {
                  return Text('${ref.watch(counter)}');
                },
              ),
              TextButton(
                onPressed: () => Navigator.pushAndRemoveUntil<void>(
                  context,
                  MaterialPageRoute<void>(
                      builder: (BuildContext context) => const SecondPage()),
                  (Route<dynamic> route) => false,
                ),
                child: Text('To Page 2'),
              ),
            ],
          ),
        ),
        floatingActionButton: FloatingActionButton(
          // Update state is easy.
          onPressed: () =>
              context.ref.update<int>(counter, (count) => count + 1),
          child: const Icon(Icons.add),
        ),
      ),
    );
  }
}

class SecondPage extends StatelessWidget {
  const SecondPage({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: const Text('Second Page')),
        body: Center(
          child: Column(
            children: [
              TextButton(
                onPressed: () => Navigator.pushAndRemoveUntil<void>(
                  context,
                  MaterialPageRoute<void>(
                      builder: (BuildContext context) => const MyApp()),
                  (Route<dynamic> route) => false,
                ),
                child: Text('To My App'),
              ),
            ],
          ),
        ),
      ),
    );
  }
}

Hey, so name is only set but not watched? In that case, it is not disposed. Maybe I should add "or set" to this part:
It is added to the graph when firstly being watched **or set**.
It can be removed from the graph manually by Ref.dispose.
If it has watchers, it is automatically removed from the graph when losing all its watchers, unless keepAlive property is set.

Since name is not "losing all its watchers", so it is not disposed.

Yup. name is not being watched. So if there is a ref.set, then it has to be manually disposed. Then I guess we will also need to include ref.update because I just tested and it is not disposed too.
Pardon me, I made some minor amendments below.
It is added to the graph the first time it is being watched, **ref.set or ref.update**.
It can be removed from the graph manually with Ref.dispose.
If it has watchers **only**, it is automatically disposed from the graph when losing all its watchers, unless keepAlive property is set to true.

Just for knowledge purposes only. What's your view on auto-disposing ref.set or ref.update?

The library has no way to know when to dispose name. You can totally set name in page 1 and watch name in page 2.
Or we could choose to throw an exception if someone set/update a creator which is not in the graph. I feel (not strongly though) it is an unnecessary limitation.

Ah you are right, it makes sense.

Hi hi!
I have a quick question.
Why is it that ref.update<int>(counter, (int value) => value++) doesn't update the value but ref.update<int>(counter, (int value) => value + 1) does?
On a side note, here's my boring 2nd article for your reading pleasure.

// ref.update() docs
Set state of creator using an update function. See [set]. No-op if the state doesn't change.

in ref.update<int>(counter, (int value) => value++) value++ is a mutation on value, it does not return a result making the update a no-op since value remains the same.
Try:
void main() {
  int value = 0;
  print(value++) // prints 0
}

while ref.update<int>(counter, (int value) => value + 1) returns a new state.
Try:
void main() {
  int value = 0;
  print(value + 1) // prints 1
}

this also returns a new state
ref.update<int>(counter, (int value) {
  value++; // mutates value incrementing it by 1 without returning a result
  return value;
});

Ah. I missed this out. @irmhonde Thanks!


For "add deployment" page, images should be resized (while retaining originals)

Right now, images are uploaded and included on the map verbatim. We should auto-resize images down to a max height of 350, and store the originals in a separate folder.

cc @jeepurs something to consider in the new map work


Make our internal geocoder to use admin data from the DO

@talos what would it take for the DO to fulfill the cdb_geocode_admin* function signatures?

@rafatower I'm not sure, but I can do some research in the next sprint to give an estimate of feasability.

:+1: I'd appreciate it if we talked face to face about this on a broad sense in Malaga :)

That would be great! 👍 definitely.


Shlomi

I took first snapshot after page load.
Second snapshot after creating a lot of notifires. and when I do a compare I see a function that is not removed from memory.

sorry about the 2 commits...
it's my first commit to github :)


LAB_06-Implement_Network_Traffic_Management.md.pdf

English:
Next hop address
Current Translation:
adresse de tronçon suivant
Suggested Translation:
Adresse du tronçon

Hello contributor,
Thank you for your contribution! We are processing your suggestions and we will update you shortly.
Kind regards,
Microsoft Worldwide Learning Team

Run bugfix tool and waiting for result.


Dev

Coverage remained the same at 100.0% when pulling be89e72ac4352246ec19a1c83c660fe8c2669f79 on dev into 9fd9b8c700be166b5fb8fa66d5352cda22967fbb on master.


Use prebuilt docker images

the results are the same before and after using the docker image

I had compared the analysis files to what we had before and there are the same.


Typo on one of this repo's labels. "compiose" should be "compose"

Oops, updated. Thanks, @mkpazon!


Bug with hash function sipHash64

Hello.
I have bug with function sipHash64.
$sql = "SELECT sipHash64(toString('1ace54')) AS result";

$result = $client->query($sql);

var_dump($result);

You see this:
Array
(
    [0] => Array
        (
            [result] => -8921094594927452419
        )
)

Then run query in one of DB viewer:

This bug happens because there are numbers in the input string.
ClickHouse version: <IP_ADDRESS>

php does not support uint64.
Now uint64  changed to a string in 0.2.7

Thanks for fix.


#16350 ability to use SQL limit fetch size for Teradata added

Why not reuse existing one for SQL Server?


dvc: Remove vendored get_random_exp_name.

bump dvc>=2.58.0

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.02 :tada:

Comparison is base (5706bba) 96.16% compared to head (c7841fc) 96.19%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #577      +/-   ##
==========================================
+ Coverage   96.16%   96.19%   +0.02%
==========================================
  Files          43       43
  Lines        2872     2864       -8
  Branches      240      239       -1
==========================================
- Hits         2762     2755       -7
  Misses         65       65
+ Partials       45       44       -1

Impacted Files
Coverage Δ

src/dvclive/dvc.py
93.06% <100.00%> (+0.40%)
:arrow_up:

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Pagination issues and considerations

This is an omnibus issue covering the Pagination component, resulting from an accessibility review. In addition to the top items covered here, there is specific and more detailed material covered in commented PDFs of Usage and Style pages that should be reviewed.

The following sections are missing from the Usage: Formatting, Anatomy, Placement, Content, Behaviors, Related, References. Given the extreme relevance of at least data table and filtering patterns, this seems like a pretty big omission.
There is a whole pagination section in Data table. i wonder whether that information should be relocated here, or is at least harvested for what content is not unique to a table pagination interaction.
Note that the data table's indetermine version of pagination does not seem to perfectly align with that shown in the Live demo
The labelling is not great for a screen reader, and I think there could be ways of making it better. The simplest is:
"Page: [12 of 40]v" instead of "[12]v of 40 pages" I've used the "[ ]v" to represent where the input and down chevron is/could be. That would need to be tested, but with zero real difference to a sighted user could likely be a much better screen reader or magnified result. Note that this also works when the unknown variant is enabled

There are more holistic changes that could be made, but this would be a pretty easy one to do.
the current design also requires you to do something with the 'orphan' text when it comes to building a label. At the moment, Carbon has used a hidden aria label that is populated based on values on screen, but I think an aria-describedby is more elegant and also better supports internationalization
Page number, of 6 pages
They could just take the select itself and use aria-describedby to link it with an ID they assign to
of 6 pages
The speech output with Jaws is much smoother, IMO. I've made a small recording of current and improved screen reader behaviour. If combined with the above suggestion on labelling changes, this would result in real improvement.
the chunk of text after the first input ("1 to 10 of 103 items" in the image above) should be tested as a live region. The advantages of this: when a user incremented the prior or next pages, or when a user changed the number of records shown OR  potentially when the filtering was altered, this would be announced by the screen reader. Could be VERY useful.
seem to be unintended duplicates at the bottom of the Usage page
the page totals used in an illustration on the style page do not make sense
Speaking of putting "Page" in front of the right-side input, almost all the variations in Figma already show that, so it would result in a more consistent layout

Website docs:

[ ] Add a section for "Responsiveness" and how the pagination content should change and respond depending on the breakpoint. Only pertinent information should remain in the pagination component at smaller breakpoints.

Closing in favor of the following issues where the work for this will be tackled and cross-referenced:

Website: https://github.com/carbon-design-system/carbon-website/issues/4013
Website: https://github.com/carbon-design-system/carbon-website/issues/4021
Code: https://github.com/carbon-design-system/carbon/issues/16538


Update to use the latest version of the stack blur algorithm as it wa…

…s causing IndexArrayOutOfBoundsException.

Fixes this issue which we were also seeing with our clients:
https://github.com/tvbarthel/BlurDialogFragment/issues/36
Basically it's using a version of Stack Blur that was a little outdated
 // Stack Blur v1.0 from
-        // http://www.quasimondo.com/StackBlurForCanvas/StackBlurDemo.html
-        //
-        // Java Author: Mario Klingemann <mario at quasimondo.com>
-        // http://incubator.quasimondo.com
-        // created Feburary 29, 2004
-        // Android port : Yahel Bouaziz <yahel at kayenko.com>
-        // http://www.kayenko.com
-        // ported april 5th, 2012
...

Notice from the original code for Stack Blur, the IndexOutOfBoundsException was fixed in 08/2013:
19.08.2013: Added support for Alpha blurring

There was a library that just used that class now named (NativeStackBlur). We are now using that library.

@vbarthel-fr Could you review this? Thanks!

Tested with the sample app...everything works.

@vbarthel-fr Mind reviewing this? Thanks!

@tommytcchan sorry for the delay, I'm quite busy at the moment, I will definitely take a look at what you did as soon as I have some free time.
Thanks for your contribution =)

Okay no problem thanks!
On Wed, Oct 21, 2015 at 2:38 PM, Vincent Barthélémy <
<EMAIL_ADDRESS>wrote:

@tommytcchan https://github.com/tommytcchan sorry for the delay, I'm
quite busy at the moment, I will definitely take a look at what you did as
soon as I have some free time.
Thanks for your contribution =)
—
Reply to this email directly or view it on GitHub
https://github.com/tvbarthel/BlurDialogFragment/pull/48#issuecomment-150032775
.

@vbarthel-fr Hey there any updates on this?

Any update of this please?
I'm using version 2.1.5 but still crashing with ArrayIndexOut....

Hi @tommytcchan  (=
We are finally back~~~
We are going to look at your pull request very soon!
Could you use the tvbarthel:develop as branch target?
Thanks you.

@tbarthel-fr so this is not going in? Do you have a workaround?

@tommytcchan Could you make a PR targeting the develop branch instead? Would love this change going in as well.


(feat: addons Karpenter) requirements incorrectly Modelled and/or named.

Describe the feature
In Karpenter yaml:
  requirements:
    - key: "node.kubernetes.io/instance-type"
      operator: In
      values: ["m5.large", "m5.2xlarge"]
    - key: "topology.kubernetes.io/zone"
      operator: In
      values: ["us-west-2a", "us-west-2b"]
    - key: "kubernetes.io/arch"
      operator: In
      values: ["arm64", "amd64"]
    - key: "karpenter.sh/capacity-type" # If not included, the webhook for the AWS cloud provider will default to on-demand
      operator: In
      values: ["spot", "on-demand"]

In EKS Blueprints:
    provisionerSpecs?: {
        'node.kubernetes.io/instance-type'?: string[],
        'topology.kubernetes.io/zone'?: string[],
        'kubernetes.io/arch'?: string[],
        'karpenter.sh/capacity-type'?: string[],
    }

We use the correct naming for taints, therefore I think we should rename provisionerSpecs to requirements. Also, we should remodel this and not hardcode to the in operator here: https://github.com/aws-quickstart/cdk-eks-blueprints/blob/f7fba04f2488556366779e56ebb88d860747aa5a/lib/addons/karpenter/index.ts#L180
Use Case
Customers might want to use other operators or keys.
Proposed Solution

rename (this will be a breaking change!)
remodel so users can use key, operator and values.

Below are some options (pseudo code):
requirements?: [{
    key: string,
    operator: "In" | "NotIn" ,
    values: string[],
}]

The key itself could be an enum like:
enum Karpenter.Requirement {
  InstanceType = "node.kubernetes.io/instance-type",
  Zone = "topology.kubernetes.io/zone",
  Arch = "kubernetes.io/arch",
  CapacityType = "karpenter.sh/capacity-type",
}

We could also model the requirements into a It's own class. That way, we can use TS to do type-checking and leverage:

@aws-cdk/aws-ec2 » InstanceType
Default zones to cdk.Stack.of(this).availabilityZones
@aws-cdk/aws-ec2 » InstanceArchitecture
CapacityType

Something like:
export interface RequirementOpts {
  operator: "In" | "NotIn" ,
}

export interface InstanceType extends RequirementOpts {
  values: ec2.InstanceType[] ,
}

export interface Requirements {
  InstanceType: InstanceType;
  Zone: xxx;
}

Other Information
No response
Acknowledgements

[x] I may be able to implement this feature request

CDK version used
N/A
EKS Blueprints Version
1.2.0
Node.js Version
N/A
Environment details (OS name and version, etc.)
N/A

I have a PR that takes care of optional operator and naming to requirement. Actual restructuring types and interfaces is a breaking change, as you mentioned, and will probably have to be a followup.


Arenas not being recognised

After having more than 2 arenas the plugin has had some form of leak as no matter how many times I restore the previous working third arena via my backup arena.json I restart the server and still the plugin is sure that all arenas that previously worked don't exist
Using Spigot 1.16
comzombies-Universal-2.2.63.jar

Possibly linked to #50

Possibly linked to #50


Link error on Ubuntu 18.04 x86_64

My project fails on Ubuntu 18.04, but works on Arch Linux. It seems it fails on undefined reference cv::typeToString(int). The libopencv-* is up to 3.4.1 on Ubuntu. Unfortunately,  cv::typeToString(int) appears after 3.4.3. I could build my own OpenCV as workaround. That's a bit inconvenience.
The situation may happen as OpenCV rolls out new versions. I would suggest more verbose feature opencv-3.4.1, etc.  I see it implies refactoring work, but makes sense.
Here is the Cargo.toml config.
[dependencies]
opencv = {version = "~0.26", default-features = false, features = ["opencv-34", "contrib"]}

The cargo build --release log.
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.0.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.1.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.10.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.11.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.12.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.13.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.14.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.15.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.2.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.3.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.4.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.5.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.6.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.7.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.8.rcgu.o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.sensor_fuse.cxb4wpmz-cgu.9.rcgu.o" "-o" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/sensor_fuse-8becdab565d4bf06.48ngb55xj63f2cj2.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-Wl,-O1" "-nodefaultlibs" "-L" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps" "-L" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/build/backtrace-sys-0c599a93aa5e2ec5/out" "-L" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/build/intel-mkl-src-81bf0e6958f7a8ed/out" "-L" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/build/opencv-295eba84862408d2/out" "-L" "/usr/lib/x86_64-linux-gnu" "-L" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/build/opencv-295eba84862408d2/out" "-L" "/home/aeon/.cargo/git/checkouts/rust-rdkafka-d5d41801cb65ae75/0c8ab14/rdkafka-sys/librdkafka/src" "-L" "/usr/lib/x86_64-linux-gnu" "-L" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libpretty_env_logger-fddf6f9ce02df647.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libchrono-3678b0444d6dc09d.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtime-21a717d012171f32.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libenv_logger-32b2109851806eeb.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libregex-394dac9db0d1a1fd.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libthread_local-6ccd210474b044b7.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libregex_syntax-3aaf9eef3b6d9145.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libaho_corasick-fb4ea716940e3b63.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libhumantime-49aa1a3ec65e7cad.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libquick_error-b75d00e579033f1f.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtermcolor-627d0b674a8e7e99.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtoml-6a71481906c96d2d.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libclap-46218657d245b0dd.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libyaml_rust-89b455e86520b371.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libvec_map-d7c451ba84034fcb.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtextwrap-7371aec9a7991185.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libunicode_width-85bf94869f49794a.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libstrsim-51b58a85c15f4612.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libbitflags-bab1880ce150b936.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libatty-367fdb31671ef0b4.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libansi_term-74cf122b8ea78844.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librdkafka-9ed18ecd8a7ad19e.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librdkafka_sys-6ec5c5381cb73bc9.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/liblibz_sys-d9621bd3176d10db.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libserde_json-263ea3c85657922f.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libryu-0799e292eef906b3.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libitoa-6a210275de79f69c.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libprost-7690d58fb3c4c90b.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libfutures-4dc2167e14ffef7a.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libfutures_executor-115188042a3beb00.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libwayside_rust_common-d0ce335443fc711b.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtokio-a9a6cc509c0abecc.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtokio_net-9434ded6a6090e64.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libmio_uds-544ec06304840765.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libparking_lot-3d353faa1d44c778.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libparking_lot_core-543294cefe262d76.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libsmallvec-77539dd130b6b19c.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/liblock_api-380cd0aba9dfc12e.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libmio-5c003d0f51fb77d5.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libnet2-a9486e8a0b822d94.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtokio_fs-d7a2ef814da19e0f.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtokio_codec-d4453c86f6b51ed1.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtokio_io-e9765ee349ee1319.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libpin_project-8115be36f4b19213.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libbytes-2aa89d2410da7f34.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libiovec-961b4d00a471094d.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libbyteorder-5f24d2e030791579.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtokio_timer-462b66e45ff79940.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtokio_executor-6b624149120ca045.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libcrossbeam_channel-051c7f01a35200ea.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtracing-2f887fffe1092914.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtracing_core-f19c515af293c729.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libcrossbeam_queue-6c40557ff8e5eec0.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libnum_cpus-edd6c0c2dc87fbda.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libcrossbeam_deque-5d3769207058b1f1.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libcrossbeam_epoch-1c32f95a924b1215.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libscopeguard-5b23cdc493a082c5.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libmemoffset-8a5a10cf6bdf960d.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libarrayvec-08b777a2a06de4f6.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libnodrop-251866cbb2d3a397.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtokio_sync-65e665f033e8a341.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libfnv-2b210a221bcdda8b.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libfutures_util-cc384a2119e46ece.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libmemchr-4b9efba8bbeb614b.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libfutures_channel-502c146a55c2dd20.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libfutures_io-fa75c55968669699.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libfutures_sink-8a93772ec23f165a.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libpin_utils-fca5b1a96f5ab8f1.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libcrossbeam_utils-b99a7da0a112b2c4.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libfutures_core-1108c67bfcff3f99.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libopencv-edf4c0e52f0fb75f.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libslab-9259c9c11c5135cd.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/liblazy_static-6bb0a6a10fe6ce0a.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libspin-8dce5d4ab42ec0bb.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libnum-bda4985186a1c28e.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libnum_iter-6c936d0149bc4ffe.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libcpp-6c3a1262c75fd0d9.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/liblog-e6750c4275436627.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libserde-cd138e7fcf1811e8.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libnalgebra-a0da5a632f804b45.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libalga-5c6e677d5081765a.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librand-bb9398ee1bfa46e7.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librand_xorshift-e053966c3750826c.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librand_pcg-68cd9718b26a0781.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librand_hc-d7562e7563c3667e.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librand_chacha-fbf5a6a1d6ae48d6.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librand_isaac-85c58989af937e66.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librand_core-a06650b8d831b24f.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librand_os-c8d91eb500ab58b3.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librand_jitter-47e36cbfedef314f.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librand_core-5bd00e0630147a11.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libnum_rational-e3d5f713297ce899.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libnum_bigint-f669a5dce5888f01.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libnum_integer-86c5022b56228adb.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libnum_complex-142db8ba543dbe4b.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libmatrixmultiply-8afbf1e3c21bccaa.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librawpointer-f4b9088ab6c04a33.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libgeneric_array-b48c8be69e285e2c.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libtypenum-89b2295ecaa46b0b.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libapprox-601e91783b35df95.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libnum_traits-b90388dfa0642ea4.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libfailure-48e99f6dc4944d63.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libbacktrace-2fbf7f33a090729a.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libbacktrace_sys-19052482a8201aac.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/liblibc-a96ed4f438903f11.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libcfg_if-c033bbb683e5b601.rlib" "/home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/librustc_demangle-0add49438cfeeb71.rlib" "-Wl,--start-group" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-9fe6e5ab8761a09f.rlib" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-4160b298b1511baa.rlib" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-f39914d03b9648c8.rlib" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-2b552edea05fcfdb.rlib" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace-65ffb7a10f9ccc45.rlib" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace_sys-173c3454a42b324d.rlib" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-1ff1784dd499e805.rlib" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-6e64baefb5bb5a40.rlib" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-a51c2bb6d30a0a87.rlib" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-a19928c525e27c1c.rlib" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-095bdba6e94cee87.rlib" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-f0a732af4791588e.rlib" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-97b68efa568398cb.rlib" "-Wl,--end-group" "/home/aeon/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-9d67c5100af5ce1a.rlib" "-Wl,-Bdynamic" "-lz" "-lopencv_dnn" "-lopencv_ml" "-lopencv_objdetect" "-lopencv_shape" "-lopencv_stitching" "-lopencv_superres" "-lopencv_videostab" "-lopencv_calib3d" "-lopencv_features2d" "-lopencv_highgui" "-lopencv_videoio" "-lopencv_imgcodecs" "-lopencv_video" "-lopencv_photo" "-lopencv_imgproc" "-lopencv_flann" "-lopencv_viz" "-lopencv_core" "-lstdc++" "-lutil" "-lutil" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
  = note: /home/aeon/repos/wayside-portal/sensor_fuse/target/release/deps/libopencv-edf4c0e52f0fb75f.rlib(core.o): In function `cv_typeToString_int':
          core.cpp:(.text.cv_typeToString_int+0x20): undefined reference to `cv::typeToString(int)'
          collect2: error: ld returned 1 exit status

error: aborting due to previous error

error: could not compile `sensor_fuse`.

To be honest, supporting 3 major version is already too much, going even finer than that would be a serious burden :)
In your case you should regenerate the bindings to match your OpenCV version. To do that, set OPENCV_HEADER_DIR environment var and build with feature buildtime-bindgen enabled, this will regenerate the bindings from your exact headers.

I'm closing this issue, it can be worked around by using buildtime-bindgen.


changes required for Starling's render texture and stencil masking

Hey guys, can someone please review this pull request. it's been 28 days with all auto tests passing. I'm happy to make changes if need be, but need some feedback. Cheers

Could you make an example project that I can test with current version of OpenFL, see it not working -> apply this patch -> test and see it working?

No worries.
I've create two example projects. One with the updates and one without.
Source files can be downloaded from: http://peteshand.net/starling/openfl_context3d_masking/MaskIssueExamples.zip
Online example with updates applied can be viewed here:
http://peteshand.net/starling/openfl_context3d_masking/withUpdate/
Online example without updates applied can be viewed here:
http://peteshand.net/starling/openfl_context3d_masking/withoutUpdate/
Currently to get around this issue I'm embedding my own version of openfl.display3d.Context3D within the Starling library and overriding the standard one with a typedef. While this technically works, it's far from ideal as every time there are changes to Context3D in openfl I need to manually copy the changes across.

oh, forgot to mention. Once the link loads, click on "Masks"

Hey @DanielUranga
Let me know if you need anything else.

hello?

Sorry, I must have something misconfigured so I don't get mail notifications. Will test tonight.

The test works perfectly for html5, but for cpp I get:
duplicate symbol __ZN6openfl9display3D8textures11Texture_obj13__CreateEmptyEv in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures11Texture_obj6__bootEv in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures11Texture_obj10__registerEv in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures11Texture_obj40uploadCompressedTextureFromByteArray_dynEv in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures11Texture_obj23uploadFromByteArray_dynEv in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures11Texture_obj24uploadFromUInt8Array_dynEv in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures11Texture_obj24uploadFromBitmapData_dynEv in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures11Texture_objC2Ev in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures11Texture_objC1Ev in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures11Texture_obj5__newEN2hx9ObjectPtrINS0_13Context3D_objEEENS4_IN4lime8graphics6opengl13GLTexture_objEEEbii in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures11Texture_obj11__constructEN2hx9ObjectPtrINS0_13Context3D_objEEENS4_IN4lime8graphics6opengl13GLTexture_objEEEbii in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures33__Texture_objuploadFromUInt8ArrayEPN2hx6ObjectERK7DynamicS7_ in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures33__Texture_objuploadFromBitmapDataEPN2hx6ObjectERK7DynamicS7_ in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures49__Texture_objuploadCompressedTextureFromByteArrayEPN2hx6ObjectERK7DynamicS7_S7_ in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures32__Texture_objuploadFromByteArrayEPN2hx6ObjectERK7DynamicS7_S7_ in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures11Texture_obj14internalFormatE in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZN6openfl9display3D8textures11Texture_obj8__mClassE in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZTVN6openfl9display3D8textures11Texture_objE in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZTSN6openfl9display3D8textures11Texture_objE in:
    obj/darwin64/ae8d360f_Texture.o
duplicate symbol __ZTIN6openfl9display3D8textures11Texture_objE in:
    obj/darwin64/ae8d360f_Texture.o

....keeps going...

Maybe unrelated. Does it works for you on cpp?

Ok, thanks. Could you send me the source for the test and I'll look into it

The same test you posted.
lime test html5 worked excellent, but lime test cpp returns a linker error, but it happens with this patch or without it, maybe it is related to Starling not being tested on Mac cpp.
Also note OpenFL now has a "develop" branch, this PR should be merged there.

Oh yeah actually Starling isn't fully compatible with cpp. Flash/AIR and js are the main focus, so the errors outlined above are simply related to Starling and not the openfl patch.
I'm going to close this pull or request and make a new one on the development branch

moved to: https://github.com/openfl/openfl/pull/1035


Register 0.2.2

@JuliaRegistrator register
Updated Project entry for new Nemo.

Registration pull request created: JuliaRegistries/General/115559
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.2.2 -m "<description of version>" de58a37a1f4f5fc815fe653b44a7fa0c22d2f148
git push origin v0.2.2


Change password check logic to server side

Is your feature request related to a problem? Please describe.
Change password check logic to server side.
Describe the solution you'd like
Change password check logic to server side
Password check rules are as follows.

Length limit 10 ~ 20
At least 1 letter of the alphabet
At least 1 letter of the numeric
Can't include id(username)
No more than 4 repeated characters

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.

@minhyun2
It is necessary to change Frontend according to API change.

You must also add the content under the password rules.
Repeated characters are not allowed to exceed 4 characters.

Including the above case, it is necessary to handle the password-related exception.

When changing the Profle, you must add a parameter when changing the password.

AS-IS

{
  "password":"aaaaabb11!!"
}

TO-BE

{
  "password":"aaaaabb11!!",
  "confirmPassword":"aaaaabb11!!"
}


Implement a GUI interface using McCLIM

https://common-lisp.net/project/mcclim/excite.html

I think this doesn't make sense anymore


REFACTOR onBeforeWrite() to add defaults if needed

The Locator class should check if the page was a different ClassName and Locator defaults aren't set, set them.

is this still needed?

Honestly don't remember what it was. I think we're probably alright since we've gone through most all of the code for the last few updates.


No changes in config.yml

Describe the bug
Hi! Could you please help me?
I'm trying to use custom config.yml for security plugin, but i can't see any changes in UI
For example:
basic_internal_auth_domain:
description: "Authenticate via HTTP Basic against internal users database"
http_enabled: true
transport_enabled: true
order: 3
http_authenticator:
type: basic
challenge: true
authentication_backend:
type: intern
Order here is 3, but it's still 4 in UI

What am i doing wrong?
To Reproduce
Try to change something in config.yml
Expected behavior
Any changes in UI
Plugins
Default plugins
opensearch-alerting
opensearch-anomaly-detection
opensearch-asynchronous-search
opensearch-cross-cluster-replication
opensearch-index-management
opensearch-job-scheduler
opensearch-knn
opensearch-ml
opensearch-observability
opensearch-performance-analyzer
opensearch-reports-scheduler
opensearch-security
opensearch-sql
Host/Environment (please complete the following information):
Docker
imge - opensearchproject/opensearch:1.3.2

@Pythonov Would you please re-route the support request to the OpenSearch security forum, so everyone can have a reference.


Go - Add utility function to copy maps

In indexers or "navigation function with parameters" we need to copy the current path parameters, add to that the additional parameters for the current segment before we pass it on to the next request builder.
While the current solution works. It repeats a lot of code
// MessagesById gets an item from the github.com/microsoft/kiota-samples/msgraph-mail/go/utilities/.users.item.messages.item collection
func (m *UserItemRequestBuilder) MessagesById(id string)(*ItemMessagesMessageItemRequestBuilder) {
    urlTplParams := make(map[string]string)
    for idx, item := range m.PathParameters {
        urlTplParams[idx] = item
    }
    if id != "" {
        urlTplParams["message%2Did"] = id
    }
    return NewItemMessagesMessageItemRequestBuilderInternal(urlTplParams, m.BaseRequestBuilder.RequestAdapter)
}

Could be easily optimized to
// MessagesById gets an item from the github.com/microsoft/kiota-samples/msgraph-mail/go/utilities/.users.item.messages.item collection
func (m *UserItemRequestBuilder) MessagesById(id string)(*ItemMessagesMessageItemRequestBuilder) {
    urlTplParams := abstractions.CopyPathParameters(m.PathParameters)
    if id != "" {
        urlTplParams["message%2Did"] = id
    }
    return NewItemMessagesMessageItemRequestBuilderInternal(urlTplParams, m.BaseRequestBuilder.RequestAdapter)
}

since the id parameter can be multiple parameters and they can have a different type, and due to the limitation of generic types, optimizing further might require a significant effort.
depends on #2406

@baywet Submitted a PR with a slightly more generic name CopyStringMap so that it can be used in other sections of the code without causing confusion

@rkodev thanks for adding the necessary method, just to be clear, I'm expecting you to make the generation change after #2406 gets merged. You might want to reopen this issue.


Cognite test

Is this just a test PR @chandru4ni ?

Yes, this is a test PR. I need to verify the deployment of Cognite function as part of verification of environment setup on Windows.

Can you please approve the review?

Check out the README file and follow the instructions on how to make your own copy (basically just click "use this template"). Then you can make whatever changes you want.
This repo is the template repo itself, so I will not accept these changes to be made here.


Add pilot-ynwr extension

Description

Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

hi ! thanks for your review ! :)
i updated the extension to use a similar way to link databases from Notion as Hypersonic.
i understand that my extension have similarities with Hypersonic such as the taskmanager.
maybe my extension is less versatile but has more functionalities such as timers or keystones.
may you take a second look at it ? and thanks for your time :)

When I make the connection to Notion I end up in this view

If I go inside the command again I end with this failure toast

Could you look into this?

hi ! thank you for diving in my extension :)
yes, I had this problem bc my oauth authorization was been triggered twice sometimes.. I made sure that it will happen once now.
does it work correctly now ?

Works better now, some more feedback 🙂

Instead of the custom loader (List.EmptyView and toast) it might be better just to stick with isLoading={} property on the <List />

I would stay in isShowingDetails all the time since it flickers when data is being loaded

Only use style={Action.Style.Destructive} for destructive actions

Remember to add icons for all actions 🙂

Is there a way to either automatically insert the right elements or popToRoot() after authentication?

thanks again for this review ! :)
i think i correct all your changes requested
i also go for the useCachePromise instead of my custom hook

Awesome, let me know when you're ready 🙂

hi
i think it's all good and ready
if you have times to review my extension

The setup still feels veery clunky and it's very confusing, can the setup happening without setting a lot of fields up?
After setting it up I visited Task Manager but it feels like I'm stuck there?

i can hide the form with all the dbs and fill it automatically so there is no setup
i think you should at first add a new project from the Home view. and then you will be able to add keystones or tasks in taskmanager.

There is something with the flow that doesn't work well, I'm still lost after going to the home command - how can I create a new project?

hi !
i changed the configuration view with all the dbs to be 100% automatic, with no fill from the user.
to add a project, there is a green button in Home to add a project.

I'm still concerned that it's too complex for users to figure out how to use it. Even with all your guidance, I'm still not entirely sure how to use it and where to start. It feels pretty niche for your needs and I'm not sure its suited for the store

hi, thanks for all your reviews !
i understand that you have some guidelines and my extensions really suits my need haha !
thanks for your time :)

Will close for now 🙂


Nesterov Momentum

Fixes mila-udem/blocks#762

@dmitriy-serdyuk, there you go!

@dmitriy-serdyuk :-)

@dmitriy-serdyuk is it ok like this?

Looks good!


Suppress Prometheus Exporter errors

What?
Suppresses Prometheus Exporter errors in development and test environments
Before

⚠ This repo is Continuously Deployed: make sure you follow the guidance ⚠
Follow these steps if you are doing a Rails upgrade.

I'm keen to fix the underlying problem in govuk_app_config, so something like TODO: remove this workaround once GovukPrometheusExporter initialisation is fixed in govuk_app_config.

Also worth understanding that this doesn't really suppress the errors; it avoids them in the first place by starting that server that's supposed be listening on localhost:9394. So this is more accurately "force starting Prometheus exporter" rather than "suppress errors".
There are two underlying issues here: firstly govuk_app_config has some confusing logic about whether it starts the "exporter" and secondly finder-frontend seems to have grown some instrumentation code that behaves poorly when the exporter isn't reachable.

Just to be clear I'm not blocking this — but I do highly recommend adding the TODO so that others don't assume this workaround is normal or expected. It'd be unfortunate if this spreads to other apps.

Thanks Chris, I'll add the comment and update the commit message.


Cross-referencing to another project

Sphinx is the defacto standard documentation tool in the Python community. One of its awesome features is intersphinx. This allows you cross-reference exports from other projects that can be hosted somewhere entirely separate from your own documentation. I don’t think the JavaScript community has anything like it.
It would be awesome if remark-api could achieve this. I imagine for this to work, remark-api needs to write some JSON based manifest in addition to updating the readme. This manifest should be published to npm. If a dependant project uses remark-api, it could then read this manifest to create cross-project references.
The manifest needs to be a robust future-proof format, like .d.ts files. Some quick thinking:
{
  // Think about backwards compatibility in advance.
  "version": "1",
  "description": "Module level descriptions can exist if `declare module` syntax is used.",
  "exports": {
    // Keys map to package.json exports.
    ".": {
      // All exported members
      "members": {
        "valueToEstree": {
          "type": "function",
          // An absolute URL references link to.
          "url": "https://github.com/remcohaszing/estree-util-value-to-estree#valuetoestree",
          // This could be rendered as the title of a dependant’s link to it.
          // Also possibly other renderers could use this metadata.
          "description": "Convert a value to an ESTree node",
          "parameters": [],
          "returns": [],
        },
        "Options": {
          "type": "type",
          "url": "https://github.com/remcohaszing/estree-util-value-to-estree#options",
          "description": "options to pass to `valueToEstree`",
        },
      }
    },
    "./some-other-export": {
      // …
    }
  }
}

Wait, so this file format is generated by module-exports you mean?
Isn‘t this almost 90% of what TS is, with the exception of URLs from types to their docs? (so valueToEstree to https://github.com/remcohaszing/estree-util-value-to-estree#valuetoestree)?


lvtk: 1.2.0 -> unstable-2022-01-19; ams-lv2: remove; fmsynth: remove

Description of changes
This bumps lvtk2 to the latest on master (1.2.0 released 2014, 2.0.0rc1 released 2019) which rids us of another python2 usage. This PR also removes fmsynth and ams-lv2 as they haven't seen a commit in 2 and 3 years, respectively, and depend on GTK2 which is no longer supported by lvtk.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

The Python 2 removal part was done in #202766. As the merge conflict is huge, please rebase and open a new PR if you still want the bump.


Panicking at core client due to failed stream

Describe the bug
When running service it posts a panick error that I am not sure what's it for
dagger@pop-os:~$ sudo systemctl restart wield.service
[sudo] password for dagger:
dagger@pop-os:~$ tail -f config.log
2024-01-06T12:44:24.355423496-06:00 [INFO] dagger::p2p::join - Initialized endpoint
2024-01-06T12:44:24.355466006-06:00 [INFO] dagger::db::peers - Attempting to open existing rocksdb for peers
2024-01-06T12:44:34.517173091-06:00 [WARN] dagger_logger::metrics - run: submit status: 204
2024-01-06T12:45:24.510735525-06:00 [WARN] dagger::p2p::join - received invalid response for bundlehash from <IP_ADDRESS>:2030, trying next node
2024-01-06T12:45:59.550393786-06:00 [INFO] dagger_logger::metrics - datapoint: user_cpu_metrics num_logical_cpu_processors=16 cpu_speed=400 ram=65689416 total_storage_space=979188154 cpu_model="12th Gen Intel(R) Core(TM) i5-1240P" wield_version="0.7.1" node_id="AWBxXYiPCSaz8uUCaoeVhHbgsRQZetVuTBKKuNLX3tGE"
2024-01-06T12:45:59.551430994-06:00 [INFO] dagger::p2p::join - Obtained join config: JoinConfig { trusted_nodes: Some([<IP_ADDRESS>:2030, <IP_ADDRESS>:2030, <IP_ADDRESS>:2030, <IP_ADDRESS>:2030, <IP_ADDRESS>:2030]), node_config: NodeConfig { socket: 2030, keypair_file: "id.json" }, storage: StorageConfig { peers_db: "/mnt/dag/dbs/peers.db" }, genesis: None, dagger: JoinAndRetrieve }
2024-01-06T12:45:59.552184148-06:00 [INFO] dagger::p2p::join - Joining network as AWBxXYiPCSaz8uUCaoeVhHbgsRQZetVuTBKKuNLX3tGE on <IP_ADDRESS>
2024-01-06T12:45:59.554237536-06:00 [INFO] dagger::p2p::join - Initialized endpoint
2024-01-06T12:45:59.554297333-06:00 [INFO] dagger::db::peers - Creating new rocksdb for peers
2024-01-06T12:46:04.719533025-06:00 [WARN] dagger_logger::metrics - run: submit status: 204
2024-01-06T12:46:59.868360732-06:00 [ERROR] log_panics - thread 'dagger-toplevel' panicked at 'failed to join network: Daggerp2pError { err: FailedToOpenStream }': core/src/client.rs:605
2024-01-06T12:46:59.868658640-06:00 [ERROR] log_panics - thread 'main' panicked at 'shouldn't fail to recv Comms : RecvError(())': core/src/client.rs:626
2024-01-06T12:47:19.368102524-06:00 [INFO] dagger_logger::metrics - datapoint: user_cpu_metrics num_logical_cpu_processors=16 cpu_speed=816 ram=65689416 total_storage_space=979188154 cpu
_model="12th Gen Intel(R) Core(TM) i5-1240P" wield_version="0.7.1" node_id="AWBxXYiPCSaz8uUCa
oeVhHbgsRQZetVuTBKKuNLX3tGE"
2024-01-06T12:47:19.368872289-06:00 [INFO] dagger::p2p::join - Obtained join config: JoinConf
ig { trusted_nodes: Some([<IP_ADDRESS>:2030, <IP_ADDRESS>:2030, <IP_ADDRESS>:2030, 184.
154.98.119:2030, <IP_ADDRESS>:2030]), node_config: NodeConfig { socket: 2030, keypair_file:
 "id.json" }, storage: StorageConfig { peers_db: "/mnt/dag/dbs/peers.db" }, genesis: None, da
gger: JoinAndRetrieve }
2024-01-06T12:47:19.369790858-06:00 [INFO] dagger::p2p::join - Joining network as AWBxXYiPCSa
z8uUCaoeVhHbgsRQZetVuTBKKuNLX3tGE on <IP_ADDRESS>
2024-01-06T12:47:19.372252191-06:00 [INFO] dagger::p2p::join - Initialized endpoint
2024-01-06T12:47:19.372311578-06:00 [INFO] dagger::db::peers - Attempting to open existing ro
cksdb for peers
2024-01-06T12:47:24.536373261-06:00 [WARN] dagger_logger::metrics - run: submit status: 204

And then it stops there with no further logs
To Reproduce
I am not sure how to reproduce it. happened on a linux debian based. I have connected a external storage, gave access to disk, I see directories are made

It looks like your node may be behind a VPC, Firewall, NAT, or something else where its main network interface IP address is <IP_ADDRESS> is a private IP address. You need to figure out how to expose your server to the public internet is some way. Some users in our discord server have setups similar to this, and have figured out exposing their network publicly. I'd suggest asking there for further support.


Need a reindex after migrating to ocfl

Existing datasets aren't appearing in the search because they don't have a head/version info in elasticsearch, even after running the migration.
This also has implications for the migration plan: if we just cut over to release-2.0, everything will disappear from the interface until we've migrated and reindexed

related: the migration script doesn't give enough feedback as it is - it should report on when it's migrated each dataset, maybe

Fixed this with https://github.com/Weed-AI/Weed-AI/pull/659/commits/a1ecd46bddfeb5c7aadfe6b2725afedadfebd834


infra: move to PDM

Pull Request Checklist

[ ] New code has 100% test coverage
[ ] (If applicable) The prose documentation has been updated to reflect the changes introduced by this PR
[ ] (If applicable) The reference documentation has been updated to reflect the changes introduced by this PR

Description

Moves the development toolchain to use PDM with hatchling as the build backend

Close Issue(s)

This was done on my Windows desktop so I couldnt run pre-commit, im sure there are some issues but I will try to resolve them tomorrow.
p.s. Windows PATH sucks, installing things sucks, and I hate everything about it

Can I ask the motivations behind this decision?

Can I ask the motivations behind this decision?

Poetry speed issue and bugs were part of our frustrations. Dep. resolution being one of the big ones..
There are some Discord threads and GH Issue: https://github.com/litestar-org/litestar/issues/2219

Looks ready for full review aside from https://github.com/litestar-org/litestar/actions/runs/6401266320/job/17376143891?pr=2357 @provinzkraut


feat: display auto-implicits as inlay hints

Prototype developed with @nomeata at FRO retreat
TODO:

[ ] test usefulness/annoyance factor
[ ] test reactivity, especially during editing in long files
[ ] support more than def
[ ] fix def missing syntactic binders
[ ] review, refine, and move introduced types, copy over missing fields and docs from LSP spec

do we need a specific opt-out in the vscode-lean4 or is the generic one sufficient?

It definitely needs an opt out (I personally dislike inlay hints because of the effect they have on the cursor), but I think it should be possible to opt out only of certain kinds of inlay hints (assuming we get more in the future)


Properly cancel sorting

https://github.com/RubaXa/Sortable/issues/264#issuecomment-171225212

Apparently the current solution is the only working one, so closing this.


run dos2unix to fix line endings

Just to confirm that the docker tests now pass on my windows box.

Is the problem that a Docker image built on Windows contains (for example) .py files with Windows line endings?
Python doesn't mind having Unix line endings even on Windows, and any decent text editor can cope with this too. Perhaps we should use a .gitattributes file to force .py files to have Unix line endings?
This would avoid issues around my other comment: We may not want to change the line endings of every file in /home/ffig; consider the possibility that we may put binary files in there. A 0x13 0x10 pair in such a file is not necessarily meant to be interpreted as carriage return/line feed... nor is it meant to be replaced with 0x10 alone. Of course, changing the command to:
find . \( -name "*.py" -o -name "*.sh" \)

would also solve that problem.

I'd be happy with a parallel gitattributes PR.
Only @Matt can test it right now though.

@jbcoe The dos2unix is a little more robust (e.g. for Python files that have been added locally but not committed / checked out by git, yet).
Perhaps there's benefit in having both.

Is it only .py and .sh files we are concerned about? C++ doesn't care either way... maybe some other languages do.

I think it was just the Python files.
We could restrict the find or use .gitattributes. I weakly prefer a restricted find as funny editors won't then cause issues.

Ok, let's restrict the find for now. I have other reservations about .gitattributes, having seen it do weird things on Windows.


Chromebook display wrong

We had an instance of Navigator being displayed too wide (by like 10%) on a
Chromebook, obviously running Chrome. So, there was no way to get to
the rightmost time periods like the Pleistocene because it displayed
off the screen. On these devices there is apparently no way to
resize the window.

This is true on my Chromebook too. Looking into it.

@markuhen , is this still happening?

Val,
This was reported to me and I don’t have a chrome book so don’t know.
Sorry,
Mark
Mark D. Uhen
On May 14, 2018, at 7:10 PM, V. J. P. Syverson <notifications<EMAIL_ADDRESS>wrote:
@markuhenhttps://secure-web.cisco.com/1mg_Z6wgfRF_onKluyMXSJnydPLF3usannGwCUvEV0oHB6_sJAXjKLWkS_oFarboSpAOkNnpj5i_-la3dLO-SxNqRqZ8R3yvgNF4YWql1Hp1ITmiPlcI7V8cmBnAbZn_7JoOmrvitHNWpKhfPmKqG_97WqGygkY2K0WZeSGwk_Q6SavJz3QYWFbWzP9QZ89Rgj5PxUq0ONcgVBjVw73u-RsRRN8tf3ByVjXdokgQj_GQFv--LFkis1J_WDOwazfjAFb39UIhQQ0nK0BLKAZGepx7QDOBBhVQbVI1wA0CKp186FAsHf7b11V5N_xAJNyu-sOrpdNPaNlWBKyoAEooNXFHLmbDiPwLfSmvBl5RzFgKFnQJGd049R9L5TUzDp5EmgHdhF-aop4WicrGsjH2l2BALdtfM6EIoJykndJfQa147KnpeNrsV3DGZZ7oAq_l8/https%3A%2F%2Fgithub.com%2Fmarkuhen , is this still happening?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://secure-web.cisco.com/1T_qKTLzcoMcgHA2W_wmgcEaNe-lf3sU4HRMJXnqUM0-QcWRdqcmNMU-VTR4i_YZySev34U7PoOYQhjBQRKe0zzb9mRO3v3r_DzYhY23L-Cw81asV6_BTG_Xm5SbCeoKXVQnaKRbaESrY0eYsj2bDitzx97AT0s_JZYbYR3pT4lJ5urpYqWm5ee0-h9Y4K5GgJSDt7eFV3XdnynIfkfZMQW2aUbpTLP1JV4YxIqj6eKc-z5dwfHx9TAaTLfuvoFX0fqVE1RZqPSh9D56IN1w4ur34YUBNVXfjgJwAxpwl3vCG1eybsIztxE-Nv4nijTU_X9yH-lJvKLh56125u_MxYPXGE4O2-BW_8q8TzyQbvRdBmfd0H7_EQo2ZaYBufaee1KvnjqfXi4pU1WVtP-2fzf0E_usVo63w9bVO1DAS37Q7PFa3mM4Z27m1mfnWgsAI/https%3A%2F%2Fgithub.com%2Fpaleobiodb%2Fnavigator%2Fissues%2F88%23issuecomment-388991308, or mute the threadhttps://secure-web.cisco.com/17tmGhbpANTCCNc-dPhCi9P-HB474sMa1pCDDslf1j01BfMZ9ETcBLS5MyRPvs6zjbVLVdbbPcUZhNydD7T_AcCrdBRyDgLObqfPoNdac7WjpVhkZMJXDnQyi8gyluE0laDBnq9Sb83zc4On7ro-pRyAu6oTfeozpGRtd4z_1MxhFfyiWqJPyTo-1KF2I-RGTr_kXV4RI5Cq8eJkL0zPY6CnvYdyKoT8TG6I-IksDlJpZonp7hzqI9oXEYIDNOdsVEFpMsONcRBsd-ZVk6K7HPbct9TZfzWv6-1mdEoqfcDyHbPznpKXssPFMPLtXMWRzTYXPXdW8N_99jcyWy9zqR0V6tDOsPYCB44yfD_i6UTguPEzBtfyOERDYNJXv0-oLQO-0DMQHnWpduu20oXU-MqsTjLrjMc0NxyP76ABiSt4M-KcCcIuoKdhGA54jvGTX/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FASpsTKt3sLNUQL3_9jnaJaoYFqhTfDH0ks5tyg7egaJpZM4OkJYh.


Seeing if this will work

I've made lots of changes, is this going to work?

some files in tutorials
some files elsewhere

Hey @martyuiop—congrats on submitting a PR at the end of the git course—it did indeed work! I hope you enjoyed working through the course and learnt a lot doing it.
If you weren't already using git for your code, hopefully this has inspired you to do so. I hope that you enjoy the "Mastering Git" video course as well—you'll soon be able to get git to bend to your will :)
You can now wear this #GitWarrior badge with pride—and Tweet your historic victory!

sam


[Next.js] Preview Mode doesn't work with fallback: false on Vercel

Description / Motivation
Handle 404 error from Vercel when we use fallback: false

Testing Details

Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation update (non-breaking change; modified files are limited to the /docs directory)

For posterity,  see vercel/next.js#16681


Isabel Woodhouse

Good job on the flex-box.    It's a good habit for version control.