Tested and improve the original Kaggle mode

We have been working on the "auto" Kaggle mode for a while, we need to make sure the previous Kaggle mode is still working and fix any bugs.
Some of the procedures can be improved as well

The current interactive Kaggle mode still works, but now the agent's chat history is more likely to exceed the context length limitation of gpt4o. https://github.com/MLSysOps/MLE-agent/issues/251

Should we add a limit to the size of the chat history (a.k.a. window memory): https://python.langchain.com/v0.1/docs/modules/memory/types/buffer_window

The current interactive Kaggle mode still works, but now the agent's chat history is more likely to exceed the context length limitation of gpt4o. #251

Could you take a look at the input prompt to see what information took so many tokens

The current interactive Kaggle mode still works, but now the agent's chat history is more likely to exceed the context length limitation of gpt4o. #251

Could you take a look at the input prompt to see what information took so many tokens

I can find that the most costly prompts occur when calling the read_file function. The mle-agent usually calls this function to view CSV and Python files during debugging. For example, when data preprocessing fails, the mle agent always calls the read_file function to see all CSV data instead of calling preview_csv_data. We should set a limitation to the language model to call read_file to avoid exceeding the maximum context length.

The current interactive Kaggle mode still works, but now the agent's chat history is more likely to exceed the context length limitation of gpt4o. #251

Could you take a look at the input prompt to see what information took so many tokens

I can find that the most costly prompts occur when calling the read_file function. The mle-agent usually calls this function to view CSV and Python files during debugging. For example, when data preprocessing fails, the mle agent always calls the read_file function to see all CSV data instead of calling preview_csv_data. We should set a limitation to the language model to call read_file to avoid exceeding the maximum context length.

Let's first at a limit parameter to the read_file function (similar to the preview data functions) @leeeizhang. And then we should think about using RAG to search the reference


Update directory-assign-admin-roles.md

clarifying desktop Analytics administrator role

@iceorbital : Thanks for your contribution! The author, @curtand, has been notified to review your proposed change.

Hi @iceorbital
Your additions say
“Can manage the Desktop Analytics and Office Customization & Policy Service.” And also says “For Office Customization & Policies Services, this role...”
My questions:
Should Service be singular or plural and should it be capitalized? What I think you’re saying is (and I can’t find “office customization & policy” at all in search) is
“Can manage the Desktop Analytics and Office Customization & Policy services.” And “For Office Customization & Policy services, this role...”  is this correct? branding is crucial in documentation. Can you help determine what the proper branding is for this? I’ll ask my PM as well. FYI, Office  Customization seems to be branded as “Office Customization Tool” most places.

hi @iceorbital
I'll run your content by my roles PM and publish ASAP. Thanks!

HI @iceorbital
I'll publish this out of our repo and follow up on the naming as we discussed.
#please-close


Missing metadata.json

Icon Prince is missing metadata.json

Just adding a link: https://github.com/microsoft/fluentui-emoji/tree/main/assets/Prince

Fixed as part of  https://github.com/microsoft/fluentui-emoji/pull/73


Dot alignment does not work in Arabic (._.)

Hi
Please add HTML View button in the application to align points at the end of dialogues in Arabic.
After version 1.14, the dots were no longer aligned after the end of words in the Arabic language. I tried to modify the application myself, but I could not😅😭

Please help and add a solution so I can enjoy reading

it's a known issue with RTL languages, the current fix is to apply a custom CSS to the text as mentioned in https://github.com/LNReader/lnreader-plugins/issues/959
* {
   direction: rtl;
}

(if it doesn't work try to go to beta 2.0)

thank you soo much it work♥♥♥


Add script to detect and install libraries needed by Python packages

Only on Alpine Linux for now

/ # install-py-pkg-deps.sh
Found 0 libraries that are not installed:
Nothing to do...
/ # pip install Pillow
Collecting Pillow
  Downloading https://alpine-3.wheelhouse.praekelt.org/packages/Pillow-3.3.0-cp27-cp27mu-linux_x86_64.whl (821kB)
    100% |████████████████████████████████| 829kB 41kB/s
Installing collected packages: Pillow
Successfully installed Pillow-3.3.0
/ # install-py-pkg-deps.sh
Found 4 libraries that are not installed: so:libjpeg.so.8 so:libwebp.so.6 so:libwebpdemux.so.2 so:libwebpmux.so.2
Searching for packages...
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
v3.4.2-2-gd037d87 [http://dl-cdn.alpinelinux.org/alpine/v3.4/main]
v3.4.1-50-gd7c21d4 [http://dl-cdn.alpinelinux.org/alpine/v3.4/community]
OK: 5966 distinct packages available
Found 2 packages to install: libjpeg-turbo libwebp
(1/2) Installing libjpeg-turbo (1.4.2-r0)
(2/2) Installing libwebp (0.5.0-r0)
OK: 15 MiB in 22 packages
All dependencies installed :-)
/ #

Looks good, but needs to be documented in the README.

:+1:


Source for Web Inquiries

Any inquiry (general/child specific) that are entered through website by web bot should default to MARE web as the source.

can this be done retroactively as well?

@n-devr Is it possible to verify the email of<EMAIL_ADDRESS>on the backend for testing purposes. I am having difficulty testing this as both of the test accounts I use (the other one is daveandbridget@gmail which is real email but can't get verified either.)  thanks.

You should be all set to test @bchiaruttini , both accounts are verified and the latest is up in development.  If you ever run into this issue again it's actually a pretty quick fix in the admin ui:

Find the Family/SW/Site Visitor you want to verify.
Uncheck the has active database account checkbox
Save the model
Re-check the the has active database account checkbox
Save the model

The save hooks will automatically verify the user when an admin manually activates them.  Always happy to take care of it on my end as well if this doesn't seem to be working.

@n-devr great, thanks for that reminder that I can just do manually.  Tested this story and all looks great.  So I think whole batch ready to push to production tonight?

Yep - I'll push in a couple hours 👍


Add Session ID to Baggage

The frontend service currently sets a Session ID on frontend spans as an attribute. It would be good for this to be propagated down thru baggage in order to use it for feature flag targeting.

I would like to work on this. Please assign this issue to me if possible. I am an Outreachy 24 Applicant.

We may want to rename this attribute while doing this effort as well. If I'm not mistaken, the spec for this will be that the attribute be called session.id (no app. prefix).
In the not-too-distant future, the Otel Web SDK will automatically generate this attribute for us, so good to align with what that name will be right now.

We may want to rename this attribute while doing this effort as well

SO do you want to rename them to session.id instead of current app.session.id ?

We may want to rename this attribute while doing this effort as well

So do you want to rename them to session.id instead of current app.session.id ?

Yes


Update Generic Pages “focusing”

Automatically generated by Netlify CMS

👷 Deploy Preview for shimmering-marigold-4f5b4a processing.

Name
Link

🔨 Latest commit
eb2405f2e79dfd5c3c11709a8ca22e973a6c2061

🔍 Latest deploy log
https://app.netlify.com/sites/shimmering-marigold-4f5b4a/deploys/6338316d83fa7e00096a1008


[Question] Parameter type "body" crashes API

Currently all my API endpoint parameters are from the type "query", however, I would like to send the parameter in the body of a POST. So I tried:
paths:
  /login:
    post:
      tags: [WebApp]
      operationId: app.post_login
      summary: Authenticate an user
      parameters:
        - name: username
          in: body

Everytime I change the type from "query" to "body" the API crashes, showing this error:
swagger_spec_validator.common.SwaggerValidationError: {'name': 'username', 'in': 'body'} is not valid under any of the given schemas

Failed validating 'oneOf' in schema['properties']['paths']['patternProperties']['^/']['properties']['post']['properties']['parameters']['items']:
    {'oneOf': [{'$ref': '#/definitions/parameter'},
               {'$ref': '#/definitions/jsonReference'}]}

On instance['paths']['/login']['post']['parameters'][0]:
    {'in': 'body', 'name': 'username'}

Isn't "body" not supported anymore? How to get parameters in the body of a POST?

That's expected behavior, you need to define a body schema. Example: https://github.com/hjacobs/connexion-example/blob/master/swagger.yaml#L58

Thanks for the reply @hjacobs, I saw this example before I ask this question but I don't get why I need to define a schema. I'd like to send a HTTP POST with a json on the body, and on this body will have the field "username", but the field username is a string, not a json schema. How should I declare this with swagger?

@ernanirst you simply define the schema as type object with a property username:
- name: this_name_is_irrelevant
  in: body
  schema:
    type: object
    properties:
      username:
         type: string

You can also use a string as the body directly:
- name: this_name_is_irrelevant
  in: body
  schema:
    type: string

Please note that you would need to add JSON quotes here:
curl -X POST -H 'Content-Type: application/json' -d '"a string"' http://localhost:8080/my-path

@hjacobs thanks, now I got it.


Selecting a tab doesn't animate anymore

Selecting a tab manually doesn't animate the change anymore

The reason is void selectTabAtPosition(int position) calls void selectTabAtPosition(int position, boolean animate) but with "animate" set to false. @roughike any reason for that?

@ened #457 should fix this.


With Renderer=HarfBuzz, \fontname output has no quotes

Description
With Renderer=HarfBuzz, \fontname output has no quotes.
Check/indicate

[ ] Relevant for XeTeX
[x] Relevant for LuaTeX
[ ] Issue tracker has been searched for similar issues?
[ ] Links to <tex.stackexchange.com> discussion if appropriate

Minimal example demonstrating the issue
\documentclass{article}

\usepackage{fontspec}

\begin{document}

\fontspec{TeX Gyre Termes}

\small

\edef\foo{\fontname\font}

\fontspec[Renderer=HarfBuzz]{TeX Gyre Termes}

\edef\bar{\fontname\font}

\ttfamily

\foo

\bar

\end{document}
% Local variables:
% TeX-engine: luatex
% End:

Further details
I am using \small because without it, the second line in output ends with at 10pt and I wanted to exclude that it may have to do with missing quotes.
For background I hit againts this while updating a mathastext work-around to also take care of Renderer=HarfBuzz.  Due to missing quotes, an error arose later when using the transmogrified output of \fontname.
It may be that this has nothing to do with fontspec and does not belong here.
However for non-expert the world of LuaLaTeX font is simply too complex to try to disentangle what belongs to fontspec, what belongs to luaotfload and what belongs to LuaTeX proper or perhaps again something else.

EDIT.  Only after posting I made the link with a problem I had encountered some time ago where I was forced to use TeXGyreTermes and not TeX Gyre Termes.
here is the MWE.
\documentclass{book}% no (immediate) problem with article class
\usepackage{fontspec}
\defaultfontfeatures{Renderer=HarfBuzz}
%\usepackage{luaotfload}% does not solve the problem anything
\setmainfont{TeX Gyre Termes}[% no issue with TeXGyreTermes
    Numbers={OldStyle},%
]
\begin{document}
0123456789
\end{document}
% Local variables:
% TeX-engine: luatex
% End:

One gets:
$ lualatex other_fontspec_fontname
This is LuaHBTeX, Version 1.18.0 (TeX Live 2024)
 restricted system commands enabled.
(./other_fontspec_fontname.tex
LaTeX2e <2024-06-01> patch level 2
L3 programming layer <2024-05-27>
 (/usr/local/texlive/2024/texmf-dist/tex/latex/base/book.cls
Document Class: book 2024/02/08 v1.4n Standard LaTeX document class
(/usr/local/texlive/2024/texmf-dist/tex/latex/base/bk10.clo))
(/usr/local/texlive/2024/texmf-dist/tex/latex/fontspec/fontspec.sty
(/usr/local/texlive/2024/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
(/usr/local/texlive/2024/texmf-dist/tex/latex/l3kernel/expl3.sty
(/usr/local/texlive/2024/texmf-dist/tex/latex/l3backend/l3backend-luatex.def)))
 (/usr/local/texlive/2024/texmf-dist/tex/latex/fontspec/fontspec-luatex.sty
(/usr/local/texlive/2024/texmf-dist/tex/latex/base/fontenc.sty)
(/usr/local/texlive/2024/texmf-dist/tex/latex/fontspec/fontspec.cfg)))
No file other_fontspec_fontname.aux.
(/usr/local/texlive/2024/texmf-dist/tex/latex/base/ts1cmr.fd)

luaotfload | db : Reload initiated (formats: otf,ttf,ttc); reason: Font "TeX" not found.
! Font \TU/TeXGyreTermes(0)/m/it/10=name:TeX not loadable: metric data not foun
d or bad.
<to be read again>
G
l.10 \end{document}

? X
 700 words of node memory still in use:
   5 hlist, 1 vlist, 2 rule, 1 local_par, 6 dir, 8 glue, 3 kern, 2 penalty, 11
glyph, 9 attribute, 63 glue_spec, 9 attribute_list, 6 temp, 3 if_stack, 1 write
 nodes
   avail lists: 1:1,2:9,3:2,4:1,6:1,7:14,9:1

warning  (pdf backend): no pages of output.
Transcript written on other_fontspec_fontname.log.

I am attaching the full log.
other_fontspec_fontname.log

See https://github.com/latex3/luaotfload/issues/285

@khaledhosny ouch, I should have minimally checked. Does look like a duplicate indeed.


Future add-ons

Leaving a clear way to add functionality to object-path without having to hack it (like in cases #30, #22, #21, #18), so it can be extended like lodash does. it has a lot of utility built-in, and you can for example, extend it to use fast.js using internally through _.mixin, like this for example https://github.com/marklagendijk/lodash-deep
var _ = require("lodash");
_.mixin(require("lodash-deep"));

so whenever someone come up with a new functionality, he can just snap it in object-path without hassle. it would expose the internal functions of objectPath to the mixin constructor (like get, del, set, isEmpty, etc)
The point is, the library managed to get 164.000 downloads in a month, which is pretty nice and people are actually using it, so the argument is based on the number of people that could improve it without adding it to core

I was thinking of something like this. You can extend objectPath and receive an "object environment" when you pass in a decorator function (like angular does):
objectPath.extend(function(internalStuff) {
    // internalStuff.get / set / del / has / isEmpty / isNumber / etc
    return {
       setPromise: function(obj, path, setValue){
           var self = this;
           if (internalStuff.hasOwnProperty(setValue, 'then')) {
                // assume promise
                return setValue.then(function(value){
                    return self.setPromise(obj, path, value); // keep solving promises
                });
           }
           return Promise.resolve(internalStuff.set(obj, path, setValue));
       },
       get: function(obj, path, defaltValue){ // decorate original objectPath.get
          defaultValue = defaultValue !== undefined ? defaultValue || Number.NaN;
          return internalStuff.get(obj, path, defaultValue);
       }
    };
});

does it make sense @mariocasciaro? (not sure if the examples are functional, created them from the top of my head). the internalStuff is kept intact, while direct functions on objectPath global can be redefined / decorated

Yes, I like this method for creating plugins. However I have a concern about bad quality plugins playing with the main instance of object-path. I know that people like to have everything in one place, but I'm wondering if we should just facilitate the wrapping of different instances of object-path rather than the extension of the main one?

yeah, a (new objectPath()).extend could work, make it a prototype function instead of a static member of the objectPath global.
but we IMHO can't stop people from writing up bad plugins (see NPM and Bower, full of them), so that's out of our control, as long the core is solid is solid :)

I'd love to have the green light to go hack and happy to make it to a 1.0.0 version :facepunch:

What do you have in mind exactly? Complete rewrite? Breaking changes? Let's discuss the major implications...

the current global won't change. the objectPath global will be an instanced version of the internal objectPath class with default options. under the hood, the average library consumer won't notice anything different, and it will continue to work as it should in 0.x. so no breaking changes in this aspect. The only breaking change is that the "binding" to object would have to be made to a method, like fromObject.
every current public method (get, del, empty, set, ensureExists, etc) will be just a reflection of internal functionality, that will be kept intact regardless of how much you change those public methods. and to ensure that it's kept intact, the extend call will always receive a deep copy of the 'base' objectPath class, so you can only append and never remove core functionality.
so, thinking in a pseudo code:
const defaultOptions = {
   someDefaultOption: true
};

function hasOwnProperty(obj, property){
   return Object.hasOwnProperty.call(obj, property);
}

function isEmpty(){
}

function get(){
}

function del(){
}

export class objectPath {
   constructor(options) {
      this.options = Object.assign({}, defaultOptions, options); // deep copy
   }

   del(){
     return del();
   }

   get(){
      return get();
   }

   fromObject(obj) {
      /* what objectPath({}) does today */
   }

   extend(extender) {
     var deepCopy = {
       get,
       set,
       ensureExists,
       coalesce,
       del,
       isEmpty,
       hasOwnProperty
       /*...*/
     };
     Object.assign(this, extender(deepCopy)); // instance assign
  }
}

var instance = new objectPath(defaultOptions);
export default instance;

// can be instantiated "from scratch
import objectPath from 'object-path.js';

var myObjectPath = new objectPath({myOptions: true});

myObjectPath.extend(function(base){
   return {
       doesntMatter: function(){
          if (base.options.myOptions === true){
              // blow up
          }
       },
       get: function(obj, path){
          return base.get(obj, path, Number.NaN);
       }
   };
});

we can then split the library in smaller helpers (but keep the less used ones for backward compatibility, like coalesce), without compromising the solid core. things like throwing exceptions on not found paths, dealing with functions, binding stuff to contexts, decorating existing methods, like the decoration of get I included in my example, could be made into plugins.

Interface-wise I was thinking we should have something like this:
var op = require('object-path')

//normal usage
op.get({}, ...)

//bind
var myObj = op({})
myObj.get(.....)

//extend the global object, not create a new one
op.extend(
  'plugin1',  // the common.js module name of the plugin
  plugin2,   // a function reference (e.g. from a plugin)
  function extender(base) {  //a function defined in place
})

A few notes:

There are no options, different behaviours are obtained by using different functions. This removes any doubt about what a function does and doesn't.
We extend the core rather than creating a new object. I know I was suggesting the opposite, but thinking about it, the real advantage of extending object-path is having all the functions together in the same place. If I wanted another object-path object I can do it already today by copying all the functions in a new object and modifying it as I want. To increase robustness and limit conflicts between plugins, I think that extend should simply prevent overriding existing functions. If someone wants a different behaviour for one particular function they are free to create a function with a different name.
I would not be comfortable with introducing any breaking change at this point, unless it introduces a really big improvement.

Those are all proposals, let's iterate and reach a sound design.

Well, I'm thinking ahead, when ES6 is the norm. The way I proposed, you can still use extend once and it will be global (since you are modifying an instance, that is a global, in this sense). and since we are using semver, it should be fine to push it to a major version which means a breaking change of some sort, the Javascript ecosystem is used to that, mainly because of bower, component and npm.
in ES6, doing a class myClass extend objectPath is a good example of good design that encourages composition instead of singletons, which objectPath is at the moment.
I liked the automatic you presented in extend, passing strings and automatically require the needed modules, the problem is that, in the browser and in AMD they might not behave the same they do in a node.js environment with common.js. It's a shortcut for extend(require('some'),require('other')), but saving a few require typings is really worth it?

Your reasoning makes perfect sense, you are free to create a 1.0 branch and start working on the new implementation you proposed but at one condition :stuck_out_tongue: . I like the current interface where the default exported function binds the library to an object, it makes perfect sense and it's a pattern used by other libraries like lodash and underscore. Changing this particular interface is like going in the wrong direction, besides introducing a breaking change. It's simply not worth changing it IMO. What do you think?

there's a fundamental flaw in keeping objectPath({}), that is the anti-pattern of returning from inside a constructor. the "wrapping" (if we may call it that) is (ab)using the fact that functions are instantiable with the new operator, and can act as objects.
lodash / underscore, backbone, jquery, aren't actually good examples of good patterns nowadays, they are "too big to fail", that means they are used by so many people that removing something is outrageous. objectPath({}) was added in January 29 on version 0.9.0 which shouldn't be a widespread panic lol. if people know semver, they will understand that nothing will change if they want to stick with 0.9.x and there will be no drawbacks / refactoring / recoding at all, and still have their projects working fine.
for example, the change from #27 really screwed me, and I'm stuck with 0.7.x in my project, because there's no easy refactoring from objectPath.get(object, ['type', where, 'something.dotted'].join('.')), if there's no options coming for 1.x, I'm stuck with 0.7.x forever.
some posts to shine some light on the discussion about globals and the (near) future that's upon us (ES6):
http://discuss.emberjs.com/t/best-practices-shimming-libraries-which-use-global-variables/7922
http://benmccormick.org/2015/04/07/es6-classes-and-backbone-js/
http://ludovf.net/reactbook/blog/reactjs-es6-classes.html
Extendable ES6 class MUST be defined as "class ObjectPath" and have a constructor and a prototype. If we want to be able to do class MyObjectPath extend ObjectPath { }, it must be instanceable. That's the main reasoning why I'm favoring the rewrite towards a base class and a global instance of this base class

I guess 300 lines of code are not worth all this back and forth of opinions. In short, let's go ahead with what you have in mind :), I trust your judgement otherwise I would not have given you write access to the repo :). Let's go ahead with the 1.0.0 branch.

alright, I'll be using the 1.0.0 branch I created. I'll try to do the benchmarks and the 1.0.0 this weekend.
I can also document the code using jsdoc if you are fine with it (IDE users would be grateful)

Sounds great!

Preliminary rewrite done (the basic funcionality). Extend not done yet
https://travis-ci.org/mariocasciaro/object-path/builds/62853434
Tests weren't changed, only for objectPath({}). I'll then comment the code, add the rest of the tests and get 100% coverage, then you may review it @mariocasciaro

Looks good so far! Good job! It's nice you took into account most of the open issues.

:+1:
pushed the "release candidate" to the 1.0.0 branch. all tests passing including, but I'm missing the prototype inheritance using the objectPath.Class.call(this, options) when constructing your own class derived from it

Could you give me a quick overview of how the typescript file relates to the .js one? Are they 2 totally different sources (2 different sources to maintain manually and keep in sync) or the .js is the result of a compilation step?

hey @mariocasciaro. Typescript is a superset of Javascript that allow strict variable types to catch program errors before it's transpiled to plain javascript. By defining a function with fn(variable: string), you'll never, at compile time, be able to call it as fn(10). Typescript also forces you to plan all the library behavior upfront, so you won't be caught in weird use cases.
Typescript is valid Javascript when it's not annotated (using the variable types), and Javascript is 100% valid Typescript, unlike other transpilers like Coffeescript. The only thing that need to be kept is the .js. The .ts serve as the base that will always be kept in sync with the JS when it receive patches, so the typings (the .d.ts file) is kept up-to-date. To understand why the typings is such a big deal, check this short post: http://www.johnpapa.net/intellisense-witha-visual-studio-code/

I don't have anything against Typescript itself, but the fact that we have to maintain 2 sources in sync is not optimal. That's why I was asking if the two files were linked in some way (e.g. compilation step). What are the practical downsides of using the js version of object-path from a Typescript file? By 'practical' I mean things that gets broken, lack of features or non negligible loss of productivity. What I'm really asking is: is it really worth the effort? I prefer a library super easy to read and maintain than something that I will hate to even look at in 2 years from now because I have other things to do and no time to keep 2 files manually in sync.

Well, I've been using typescript for almost 2 years now, and it helped me imensely to write quality code. But don't worry, I can keep the Typescript on my repo only, and never push it to this repo. I'll need to maintain the typings up-to-date anyway, regardless if this repo keeps the .ts version or not.
To compile the typescript, use npm install typescript -g then tsc inside the cloned folder, no other step is needed, if you are curious how big would be the impact of compiling.
Typescript will always be 1 step ahead the current Javascript version, so it won't be "hateful" to look at it in the future. Angular 2.0, the biggest upcoming front end framework is done with Typescript, so you can measure how big it will become.

As I said, I don't have anything about Typescript, I just don't want to maintain in sync 2 files, it's just unpleasant, error prone and discourages contributions from the community. I vote for keeping the .ts file out of this repo, let's focus on a pure JavaScript implementation here, let's keep it simple. Besides this, is the 1.0 ready to go for you? I checked the source and it looks good to me.
After this, I think we are good to update the docs and release.

Yeah, I was just waiting for your feedback on my post above. Should I implement the JSCS to keep format consistent? (including PRs)

Yes, it's a great idea

@mariocasciaro Revisiting this issue, the new Typescript 1.6 version can create typings that doesn't need to include the original typescript file. Also, it favors typings encapsulation instead of declaring global modules (like Typescript =< 1.5 did), so I guess it won't need to rely on the code generated by it, unless we go full ES6 (or SystemJS hybrid for example). Still want to release 1.x :)

Hi @pocesar I also want to go ahead with 1.0 :smile: , my only prerequisite is that we keep this library as simple as possible. For the size of this lib I don't see any advantage in using Typescript or ES6  + a compilation step. I don't have anything against TypeScript or ES6, I just feel that a small library as this should stay small and simple. Adding more features, streamline the internals, improving performances, splitting the library in many submodules and things like that are far more important in my opinion, than debating if we should use Typescript or ES2015 or plain ES5. We agree on this?

Yup, totally agree. Standing in the shoulder of giants (like lodash / underscore and now their merge) the focus is on splitting the internals into separate exports, so people using ES6 style imports can use only some parts directly like
import {del} from 'object-path';

del(obj, 'path');

I'll refactor it, keep the backport to Typescript and do the typings, while keeping object path JS-only.

hey @mariocasciaro here's the upcoming version. disregard the typescript files for now, and it's missing the global objectPath inside the UMD. the tests are passing, support for Symbol() is nearly done, and I've updated the README
Also, I'm proposing the following plugins that might or not ship as soon 1.0 is out:

object-path-as-promised

Adds objectPath.then, a getter that returns a promise, and can deal with plain values and promises (thenables)
object-path-concat
Adds `objectPath.concat`, concat if the path is an array

object-path-tryget
Adds `objectPath.tryget`, throws if the path doesn't exist

object-path-wildcard-set
Adds `objectPath.wildcardSet`, can set paths like `some.*.path`

object-path-immutable
Overrides all `objectPath` functions, make it so object-path don't modify the passed objects, but always create a new object or array

I saw that you created a separated version of object-path-immutable to have a clone function, it can now be a plugin and extended into object-path, what do you think? ;)

Hey Paulo, that's an amazing job, I think we are on the right path, however there are a couple of things I wanted to discuss first.
Object-path functions should ALWAYS be consistent in behaviour across and within projects. This is not always true if we allow the user to create a new 'customized' instance with different options. Imagine having a project that uses object-path extensively, if every member of a team starts creating their own instance which can behave differently from other instances in the same project it would be a complete mess. It's even hard to document it, imagine explaining the set() method: if you specified option x then you will have this, if option y and z then that. Plugin creators might easily abuse of this. I think this is the wrong way to do it.
I thought about this a lot, and I think the right approach would be to create a completely different function for each variation in behaviour, each function should do only one thing and well and state clearly and without ambiguity what is its behaviour, for example we would have set() to treat numbers as array and setObject to always treat the path components as object properties. This philosophy is in line, for example, with what gulp considers a good plugin (a gulp plugin that tries to do many things and accepts many options is considered a bad plugin)
Each object-path function would be distributed in its own package (as lodash does) and we will then provide an aggregated library for convenience (object-path which will import all basic functionality). Each individual function will be distributed only as a commonJS module for simplicity, while the main library will be also built with browserify to support those stuck in the 20th century (AMD and browser globals).
Let's start by:

creating the Github organization
splitting the current lib into different github projects
Creating the aggregated main lib

Object-path-immutable fits perfectly with this approach as well as the many plugins you suggested. If the users wants a 'customized' version of object-path they can always do:
var myObjectPath = {
  set: require('object-path-set')
  get: require('object-path-get'),
  getPromise: require('object-path-get-as-promised')
}

This is much simpler and clearer for the user than passing an options object to a constructor and it also gives more flexibility.
Let's create a unix-style ecosystem of utilities around object-path, small, simple and powerful at the same time, people will love it.

hey @mariocasciaro, while I understand your point of view, I disagree with it.
Lodash functions itself have many different outputs for the same function (see reduce, debounce, throttle or clone for example). Even the _() is a factory for an internal class, while it might not appear to be one class for the simplicity of the interface, it is, while all the bells-and-wristles of a prototyped class (and a really useful one, I use the chained class all the time) or through _.runInContext, which I also use in Node extensively. Also, besides the split (and not very popular versions on NPM) for lodash-* functions, the main lodash file encapsulates everything most programmers use and love.
Gulp is a 'one time' build step, and it's expected to be executed once, and do something well, aka process files and output useful modifications. That's not the case with object-path. It's a server and client side runtime utility, that's used extensively within code, over and over.  All functions in objectpath do what they are named after, they either get, set, delete, push or empty objects. Using configuration flags won't change drastically the way they work, it will affect non-existing paths mostly, pre-defined objects will behave as expected regardless of flag. Having setObject, setArray creates unnecessary complexity. That's the reason I wanted to use Typescript, the code is really well documented, the parameters are safe guarded, and won't let you commit simple programming mistakes, if you see the base interface for object-path, it's straight forward, and IDE support is superb (even without JSDoc, which I plan to do before releasing 1.0).

Also my proposal tries to abide within the S.O.L.I.D. principles, while maintaining some backward compatibility with object-path through exporting each function like it was doing in version 0.x, allows transparent extension for instances, while keep the modifications at bay.
That's why besides objectPath.get, which behaves exactly the same every time, there's objectPath.instance.get, that will behave exactly per configuration, the same every time as well.
ES6/ES2015 (see big frameworks like Angular and React) now provides inheritance, decorators and everything to create maintainable code. class MyComponent extends React.Component { } is much easy and maintainable than defining a "singleton" object that will have to be instantiated later somewhere (which objectPath.instance is, a global instance of objectPath that behaves like the original one). For your "roll your own", you can simply use class ObjPath extends objectPath.Class { } and hack away. Providing ways for programmers to do this is the best.
Otherwise object path will never take advantage of progress that were made in newer versions of Javascript.
What I said was that extra behaviors should become plugins, it's because we provide plugin authors with a straight forward way to create code without even having to require object-path inside their plugins the first place:
// no need require('object-path') here
module.exports = function tryGet(base, options) {
   return {
      tryGet: function(){
         base.get() // don't need to worry, because get is ALWAYS objectPath.get, no matter what modification was done to either objectPath.get or ObjectPath.instance.get
        // closed for modification, open for extension
      }
   }
}

check the readme for examples

@pocesar unfortunately we clearly have different opinions on the matter and it seems difficult that we could ever find a compromise. Your arguments make completely sense, but they don't apply to a simple library like object-path. Using a class and keeping a state (the options) is completely overkill for a library that is meant to be intrinsically stateless, simple and made of simple functions.
There are a lot of people who argue that classes and in particular inheritance are harmful and should be avoided. Personally, I'm not completely against the use of classes and inheritance, but if there is a simple way to avoid them then I will.
I won't stop you to continue to work on your own version of object-path, you can always fork it permanently, change name, do whatever you want, however I would hate to see you go, I would prefer to join forces towards a common goal instead of splitting forces to reach the same goal but through two different paths. Remember that this is just a small library, let's not overthink it, ultimately we should focus our time on far bigger and more important things.

@mariocasciaro I don't plan to fork object-path, it would do nothing good doing so. I'll do as you say, I'll remove anything that is related to classes and state, but I need to ask about the extra parameters added to the functions. numberAsArray isn't as useful as the ownPropertiesOnly, so I can remove numbersAsArray. Like set has doNotReplace, ownPropertiesOnly as a parameter is a powerful one thinking on plugins implementation. It's not stateful, it just indicates that you want to go BEYOND own properties (including symbols and prototype non-enumerables) and you know you can break things, but some plugin authors might find this useful. If the parameter option isn't implemented, then a person that wants a new 'isEmpty' for non-enumerables will have to write his own code. (definition in https://github.com/pocesar/object-path/blob/1.0.0/object-path.d.ts#L29 and subsequent set, ensureExists, del, etc). all ownPropertiesOnly parameters defaults to true and it is the current behavior for object-path


Update 13_trotterQRTE.ipynb

Summary
It is a simple typo for the order of the trotter formula
Details and comments

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

it is a simple typo for the fourth order of trotter formula

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
6464

Relevant Lines:
7137

💛  - Coveralls

The docs are now live with this fix - thanks!


How to handle underwater lon/lat for SeaExplorer?

In my recent trials with pyglider+seaexplorer, I noticed that the underwater positions for the most recent missions are a bit funky, and after some digging I realized it's because of a (somewhat recent) firmware change that writes the dead-reckoning determined positions into the data file, along with an extra column to indicate whether the location was measured (GPS) or calculated (Alseamar dead reckoning algorithm).
Below is an example from a recent mission, showing how the dead-reckoning positions are propagating through the processing, but because they don't account for the depth-averaged current, the final position of a dive cycle ends up being discontinuous with the start of the next dive cycle.

It seems that excluding dead reckoned lat/Lon would make sense.

Yes, I agree. The same should probably apply even for older missions which didn't have dead reckoning, because IIRC all they did was repeat the last measured values over the entire dive, until updating again at the surface.
What are you doing for the slocum in this case? Would be nice to be consistent.
In past attempts at processing I have done various things to try and filter out the "good" locations, e.g. by NaNing everything that doesn't correspond with NavState == 116 (transmitting at surface), but even that can be problematic at times because sometimes when it first goes into that state, the GPS hasn't actually received a fix and it still just repeats the old values ...

Yes I agree that makes sense. I guess my question was how do you determine the Lon/lat to average for the profile for a slocum? Is it from the slocum flight model or just an interpolation if the dive start/dive end locations?

deployment.yml says what data stream to use.  For the slocums I've been using m_lon/m_lat.  I don't recall the provenance of those data streams, but the resulting track looks close to what we asked the glider to do ;-)

Not sure if this is helpful or not, but Adam C at OTN gave me this documentation for the slocum:
doco/water-velocity-calculations.txt
This document describes how the Webb Research Glider
infers the water velocity (currents) from differences
between dead reckoned (x,y) locations and gps (x,y)
locations.
26-Jan-02<EMAIL_ADDRESS>   Initial
04-Feb-02<EMAIL_ADDRESS>   Added M_initial/final_WATER_Vx/y
21-Sep-07<EMAIL_ADDRESS>Updated M_DR_FIX_TIME to
                    M_DR_POST_FIX_TIME on line 83
ABSTRACT
While underwater, the glider dead reckons it's position relative
to the water.  When surfaced, the glider receives a precise location
from its gps.  ASSUMING THAT THE DEAD RECKONING AND GPS ARE PERFECT,
any errors between the gps fix and the final dead reckoned position
must be due to water movement (currents) while the glider is underwater.
The glider can use the measured water current in its next underwater
segment to navigate better.
This scheme strongly depends on the accuracy of the dead reckoning.
Any error in the dead reckoning (or the gps) will cause an erroneous
water current to be computed.
DEAD RECKONING OVERVIEW
While underwater, the glider navigates by measuring its vertical
motion thru the water column, its pitch, and its heading.
The vertical speed adjusted by the tangent of the pitch angle
gives a horizontal speed (relative to the water).  The heading
from the compass gives a horizontal velocity (relative to the
water).  Integrating this horizontal velocity over time provides
a series of (x,y) fixes.  These values are stored in (M_X_LMC, M_Y_LMC).
COORDINATE SYSTEM
A note on coordinate systems,  most of the work in the glider is
done in the LMC (Local Mission Coordinates) coordinates.  (0,0) of
the LMC coordinate system is defined as the glider's location when
the mission starts.  The LMC Y axis is defined to point magnetic north.
There are various routines to translate back and forth between
latitude/longitude and LMC.
GENERAL DESCRIPTION
Please refer to doco/figures/water-velocity-calculation-fig1.*
[The figure is available in pdf, jpg, and fig formats.  fig
is the proprietary output format of the Linux Xfig program.]
Variables below in ALL CAPITOLS represent sensor values that are
stored in the glider and transmitted in a *.dbd file.
At time Ta, the glider dives and surfaces at time Tb.
The dotted line between Ta and Tb represents the actual path the glider
took underwater.  The solid line between Ta and Tb represents the
dead reckoned trajectory of the glider, i.e. where it thought it
was.  The glider thinks it surfaces at point:
      (M_DR_SURF_X_LMC, M_DR_SURF_Y_LMC)
The red vector connecting the two Tb points represents the error in
dead reckoning.  That vector divided by the time underwater (Tb - Ta)
will produce the average water velocity vector.
Unfortunately, the actual glider position at Tb can't be measured.
It typically takes the glider a minute or two to receive it's first
gps fix.  During this time, the wind drives the glider in a completely
different direction on the surface.  At time Tc, the glider receives
it's first gps location on the surface:
    (X_GPS_FIX_X_LMC, X_GPS_FIX_Y_LMC)
The blue vector (M_DR_X_INI_ERR, M_DR_Y_INI_ERR) represents the
initial difference between the dead reckoning and the gps.  The
glider divides this initial error by M_DR_TIME (Tb-Ta) to produce
(M_WATER_VX, M_WATER_VY).  This initial estimate of water velocity
includes the surface drift error when the glider is drifting
on the surface for M_DR_FIX_TIME seconds while waiting for it's
first gps fix.
To correct for this error, the glider waits M_DR_POST_FIX_TIME
seconds and takes another gps fix at time Td producing location
(M_GPS_POSTFIX_X_LMC, M_GPS_POSTFIX_Y_LMC).  The green vector
represents how much the glider has drifted during this post fix
time.
Assuming a constant surface drift velocity and if M_DR_POSTFIX_TIME
were exactly the same as M_DR_FIX_TIME, then the desired red vector
is the blue vector minus the green vector:
    (M_DR_X_ACTUAL_ERR,    M_DR_Y_ACTUAL_ERR)        =
        (M_DR_X_INI_ERR,       M_DR_Y_INI_ERR)       -
        (M_DR_X_POSTFIX_DRIFT, M_DR_Y_POSTFIX_DRIFT)
In actual practice, the green vector is "time adjusted", i.e.
it is shrunk or expanded by M_DR_POSTFIX_TIME/M_DR_FIX_TIME before
being subtracting from the blue vector.
The red vector (M_DR_X_ACTUAL_ERR, M_DR_Y_ACTUAL_ERR) is divided
by M_DR_TIME to produce the final estimate of (M_WATER_VX, M_WATER_VY).
Each of the computed water velocities are "clipped" by U_MAX_WATER_SPEED
to provide a reasonableness check.  If the magnitude of
(M_WATER_VX, M_WATER_VY) is greater than U_MAX_WATER_SPEED, the resulting
water velocity vector is "shrunk" without changing its direction.
When the the water velocity is calculated, the glider needs to know whether
the water velocity was being used as part of the dead reckoning navigation.
If it was, the water velocity calculated must be added to the water velocity
used for navigation (X_PRIOR_SEG_WATER_VX, X_PRIOR_SEG_WATER_VY).
To make it easier for host side post-processing, the initial
M_WATER_Vx/y is published as M_INITIAL_WATER_Vx/y.  The second
M_WATER_Vx/y is published as M_FINAL_WATER_Vx/y.
THE CODE DETAILS:
All of these calculations are done in:
    code/sensor_processing.c/compute_water_velocity()
This function is called every cycle and implements a state
machine.  The current state is reflected in X_DR_STATE:
        wvs_mission_start(0)
        wvs_underwater(1)
        wvs_awaiting_fix(2)
        wvs_awaiting_postfix(3)
        wvs_awaiting_dive(4)
When the glider dives:
     remembers the time of the dive in an internal variable, time_a.
     --> state wvs_underwater(1)
When the glider surfaces, it:
    remembers the time in time_b
    M_DR_TIME = time_b - time_a
    M_DR_SURF_x/y_LMC = M_x/y_LMC
    state wvs_underwater --> state wvs_awaiting_fix
When the glider gets its first gps fix:
     remembers the time in internal variable time_c
     M_DR_FIX_TIME = time_c - time_b
     X_PRIOR_SEG_WATER_Vx/y = M_WATER_Vx/y
     M_GPS_FIX_x/y_LMC = M_GPS_x/y_LMC
     M_DR_x/y_INI_ERR = M_GPS_FIX_x/y_LMC - M_DR_SURF_x/y_LMC
     M_WATER_Vx/y = M_DR_x/y_INI_ERR / M_DR_TIME [see note below]
     M_INITIAL_WATER_Vx/y = M_WATER_Vx/y
     state state wvs_awaiting_fix --> wvs_awaiting_postfix
After drifting for M_DR_FIX_TIME seconds (or whenever it dives):
     remember the time in internal variable time_d
     M_DR_POSTFIX_TIME = time_d  - time_c
     M_GPS_POSTFIX_x/y_LMC = M_GPS_x/y_LMC
     M_DR_x/y_POSTFIX_DRIFT = M_GPS_POSTFIX_x/y_LMC - M_GPS_FIX_x/y_LMC

     ; timeadjust and flip sign
     taf = M_DR_FIX_TIME / M_DR_POSTFIX_TIME
     M_DR_x/y_TA_POSTFIX_DRIFT = - M_DR_x/y_POSTFIX_DRIFT * taf
     ; Compute final error
     M_DR_x/y_ACTUAL_ERR = M_DR_x/y_INI_ERR + M_DR_x/y_TA_POSTFIX_DRIFT
     M_WATER_Vx/y = M_DR_x/y_ACTUAL_ERROR / M_DR_TIME [see note below]
     M_FINAL_WATER_Vx/y = M_WATER_Vx/y
     state wvs_awaiting_postfix --> wvs_awaiting_dive
Note:
    When computing the water velocity, the glider examines
    U_USE_CURRENT_CORRECTION to determine if the prior segment
    dead reckoning was using M_WATER_Vx/y in navigation.
    if U_USE_CURRENT_CORRECTION is non-zero, integrate:
      M_WATER_Vx/y = X_PRIOR_SEG_WATER_Vx/y + M_???_ERROR/M_DR_TIME

    if U_USE_CURRENT_CORRECTION is zero, don't integrate:
      M_WATER_Vx/y = M_???_ERROR/M_DR_TIME

I think what this is saying is that for the slocum the m_lon/m_lat positions are the combination of the glider dead reckoning AND the dead-reckoning current correction (e.g. from the "Note" and when U_USE_CURRENT_CORRECTION is non-zero). So it makes sense that those positions are "right enough" to use for the average to determine profile locations.
In the SX case (at least for the post-DR firmware) it is only storing the DR positions, not the DR corrected for the depth-averaged current. Which I have to say is really annoying, since the data files themselves don't even contain the DR-estimated currents!

Hi Clark, I am have started to use pyglider recently for a set of mission and I have the same issue. SX positions are not great because they use dead-reckoning. Ideally, DR position should be used to derive depth-average currents at surfacing when getting new GPS position, and lon/lat arrays should be corrected. Since you noticed the issue some time ago already, did you or anyone make any progress on this issue? cheers

Just to clarify the goal of pyglider (in my mind) - it is to get the data out of whatever the glider stores the data in, and into a netcdf file that a scientist can read.
After it is in Netcdf, it is a matter of processing, which I don't think is something we want pyglider to get into directly.

Hi Jody, I understand. The netcdf timeseries has everything needed to further process and correct the position and regrid data by the user. However, gridded netcdf containing dead-reckoning position averaged for each profile does not have enough information (due to profile averaging) to correct for DR. Good to keep in mind, and it was useful to read about this here.


Apply should be before SortBy in RedissonSearch.class

Apply should be before SortBy in RedissonSearch.class ?
For example I use command:
FT.AGGREGATE public_place_parking_idx "@enableStatus:[1 1]" load 2 $ location apply "geodistance(@location, 114.058663,22.543096)/1000" as distance sortby 2 @distance asc limit 1 10

Can you share the code to reproduce the issue?

I'm sorry, I don't remember what it was about? Nor do I remember what website or software it happened on. So I can't reproduce the code for you
获取 Outlook for iOShttps://aka.ms/o0ukef

发件人: Nikita Koksharov @.>
发送时间: Friday, August 23, 2024 2:40:48 PM
收件人: redisson/redisson @.>
抄送: distance @.>; Mention @.>
主题: Re: [redisson/redisson] Apply should be before SortBy in RedissonSearch.class (Issue #6107)
Can you share the code to reproduce the issue?
―
Reply to this email directly, view it on GitHubhttps://github.com/redisson/redisson/issues/6107#issuecomment-2306396752, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AM6BE2437OSFJBYD6724CALZS3KPBAVCNFSM6AAAAABM3RBMX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBWGM4TMNZVGI.
You are receiving this because you were mentioned.Message ID: @.***>

unable to reproduce


Is it possible to use default param values in routes.js

I have
routes
.add('page', '/page/:slug')

Which directs pages such as /page/about-us to /pages/page.js with param slug equal to about-us
I want to also add a route for /contact-us which also routes through /pages/page.js with a slug of contact. Is there a way of achieving this?

I solved this with a hack:
I used this as the route:
.add('contact-us', '/contact-us', 'reroute|/page|{"slug":"contact-us"}')

and then in server.js I added a custom handler
const handler = routes.getRequestHandler(app, ({req, res, route, query}) => {
  if (route.page.substring(0, 8) === '/reroute') {
    const routeParts = route.page.split('|')
    app.render(req, res, routeParts[1], JSON.parse(routeParts[2]))
  } else {
    app.render(req, res, route.page, query)
  }
})

I would be great if it was possible to send a customization object through for the custom handler so this could be less hackish. I can't be the only one who has SEO requirements that make direct url to filename conversions harder than they should be!
If this is welcome I'll put a pull request together.  Essentially just a fourth parameter in the route definition that gets passed through.


on:connect isn't working as intend to

Describe the Bug
I'm trying to make a detector to new edge connections, I tried several methods, but the on:connection method isn't working for svelte case, in react version I saw people using it with success however for svelte it isn't working directly, the goal is simple, update the edge's storage with the new edge created with the connection, and possible handle edge deletions too
Your Example Website or App
No response
Steps to Reproduce the Bug or Issue
This is the setup that is causing the problem, below is the code of the entire page of the network:

        <SvelteFlow
            {nodes}
            {edges}
            {nodeTypes}
            {colorMode}
            fitView
            connectionLineType={ConnectionLineType.SmoothStep}
            defaultEdgeOptions={{ type: "smoothstep", animated: true }}
            on:connect={(event) => handleConnect(event)}
            on:nodedragstop={(event) => {
                console.log("Node drag stop event triggered", event);
                handleNodeDragStop(nodes, event);
            }}
            on:nodeclick={(event) => {
                console.log("Node click event triggered", event);
                if (event.detail.node.data.type === "handler") {
                    // handleNodeClick(event.detail.node.data)
                } else {
                    console.log("Normal node click:", event.detail.node);
                }
            }}
        >
            <Controls />
            <Background variant={BackgroundVariant.Dots} />
        </SvelteFlow>

When running it we can see that the edge's storage isn't updated because when a new edge is created in the graph the on:connect doesn't trigger the function
Expected behavior
The expected behavior is to the edge store be updated with the new edges
Screenshots or Videos
No response
Platform

OS: Windows
Browser: Chrome, Firefox
Version: latest

Additional context
This method really exist, or I'm trying to do something that isn't possible with the svelte version, is this really a bug or a bad implementation? I will appreciate any feed back, tks in advance! Since I don't know if this is a bug or not I'm putting here as an issue instead of putting in the discussion session as a question, sorry if here for some reason isn't the correct place for this.

You don't need to apply any updates in Svelte Flow by hand. That is only required in React Flow.
on:connect will notify you when a user has connected two handles successfully.
If you create a stackblitz with your code I can help you out.

Hello @peterkogo thanks for the speed in reply! I've created the stackblitz with all the required code to the graph page, exactly how I'm trying to do here. Here is the link for the code, let me know if you are able to access t, I never had used stackblitz before so I don't know if I configured it correctly...

I also forget to mention that I don't have the stackblitz plan, so I don't know if I can add you to the project, in the case that you can't modify it directly you don't need to wait, simple to a fork, since you already know how to use the platform it will be more simple, then we continue here to solve this particular thing, if possible. Let me know if you need something else in the svelte setup  ;)

Hey @peterkogo, got any updates? I just need to know how to capture new links when a user connects nodes. I know we can use an approximation similar to the 'node approximation connection' example in the Svelte docs, but I need something to trigger a function to save a new connection or to auto-sync with the variable when changes occur in the graph. I've got 2 projects depending on this that I'm kinda late to finish, and I can't find a clear explanation in Svelte in any place. If you know how, could you use the source code I uploaded on StackBlitz? Feel free to fork it and implement a basic example, or just explain how it works in Svelte, you know just a simple example nothing too elaborated, just a simple example of a node edge update using callbacks or a reference link intenally. That would be super helpful and would allow me to continue with the Svelte implementation of the graph that i'm kinda. Without this functionality, I might have to switch everything to React, which has better documentation for this. Any feedback you can provide would be greatly appreciated. I'm waiting for any updates.

Hey @letalboy
there is no "on:connect" handler, but an "onconnect" (and also "onconnectstart" and "onconnectend"). Svelte Flow creates edges automatically for you. As Peter pointed out there is no need to do it on your own. However, you can use the onconnect handler or the onedgecreate handler if you want to adjust the id.
Svelte Flow adds new edges to the edges writable as you can see in the onconnectend handler: https://stackblitz.com/edit/svelte-flow-ts-pbp7xu?file=src/Flow/index.svelte

Thanks @moklick this does exactly what I want. I saw this method before but think it will not work because of the missing : standard of the on:connect and other events notation in svelt but I copied what you uploaded in the Stackblitz to my code here, and it does exactly what I was looking for. This completely solves my issue. Thank you!

I am glad you could solve it :)


nixos/nextcloud: Move database options into freeForm settings

Description of changes
As a continuation of https://github.com/NixOS/nixpkgs/pull/212430 and to meet RFC42 requirements, move several database configuration options from services.nextcloud.config into services.nextcloud.settings:

config.dbtype -> settings.dbtype
config.dbname -> settings.dbname
.config.dbuser -> settings.dbuser
config.dbpassFile -> settings -> dbpass
config.dbhost -> settings.dbhost
config.dbtableprefix -> settings.dbtableprefix

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)
[x] 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

[ ] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[x] (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

[x] Fits CONTRIBUTING.md.

fwiw we may want to consider putting them into extraOptions as well.
I did some research and it seems possible with a little bit of patching in Nextcloud to drop most of the stuff for maintenance:install and make it read everything from the config instead which is what I'd like to explore further. With that, most of the options - including these - can be placed into extraOptions (which should be renamed to settings eventually).

@Ma27 Did some work on this, what do you think?

All tests are working now :) Changed default value for dbtableprefix to oc_, according to my tests this value was always used and the default. At least for Mysql changing this didn't work for me.

How about setting default = if dbtype == "sqlite" then null else "nextcloud"; and a defaultText to make sure the manual doesn't depend on the system configuration?
See also https://github.com/NixOS/nixpkgs/pull/286172 as inspiration.

Thank you @Ma27, totally forgot about this :) Added some conditions to the default values 👍

I am using notify_push on the same machine and connect to postgres via unix socket 😅

Why are the options copied from Nextcloud then if it's not possible to use it on a remote machine (at least that's my assumption based on what I've written above). Then it should be made sure with an assertion that both services do run on the same machine.
Anyways, nto sure if reusing the secret file here is sensible: it's designed to contain any kind secret for Nextcloud and those shouldn't be made available to other services like notify_push unless necessary (otherwise we could just store all our credentials in the store and skip the secret file pattern entirely).

if it's not possible to use it on a remote machine (at least that's my assumption based on what I've written above).

Looking at the notify_push README, I would assume that it's not needed to pass the config.php. And I can't find anything indicating, that notify_push should indeed run on the same machine.
I mean it probably makes sense to have it on the same machine, but I don't think we should enforce that here (but instead remove the dependency on the nextclouds config.php).

Looking at the notify_push README, I would assume that it's not needed to pass the config.php. And I can't find anything indicating, that notify_push should indeed run on the same machine.

OK, interesting. In that case I'd consider it a bug that this depends on Nextcloud configuration.
Anyways, then I'd suggest we define all database options for notify_push a second time in this module including dbpasswordFile rather than copying these from the Nextcloud module. And dbpasswordFile should only contain the db password because we shouldn't advertise an approach where notify_push can read all of Nextcloud's secrets. WDYT @SuperSandro2000 @onny ?

Agreed for everything except the db password which is part of the secretFile in the nextcloud module.

I still like the PR but I think dbpassFile cannot be just "moved" into secrets. Maybe dbpassFile has to remain together with a deprecation warning?

I still like the PR but I think dbpassFile cannot be just "moved" into secrets

Because of notify_push?
IMHO dbpassFile suffers from the same issue: as soon as both are on different machines, you cannot expect to have the same secret file available there anymore. For scalar values this was OK, but with secrets this isn't.
My suggestion is to still redefine all options for notify_push.
What defaults make sense is up to @SuperSandro2000 now, I don't care anymore, I'm not even a maintainer of that :shrug:


Force running an alias

By deleting all of its alias files from the store. I think this turned out to be quite simple unlike what diml predicted in #84. Therefore, I think we should prefer this implementation because it doesn't change the execution of build rules at all.
cc @rdavison

An immediate question that pops is whether we should extend this flag to all aliases by allowing it in jbuilder build? I think we can err on the conservative side for now and omit it for now.

So it looks like if a force flag is passed then it will rerun tests. Does it have the ability to rerun any arbitrary aliases?
Also how is this behavior affected by recursive and nonrecursive aliases?

So it looks like if a force flag is passed then it will rerun tests. Does it have the ability to rerun any arbitrary aliases?

Yes. We just need to allow this flag in jbuilder build and detect which of the targets passed were aliases. We might also need to look at the dependencies of some non alias targets and see if any of those are aliases. So I'm a bit worried of just extending it like that.

Also how is this behavior affected by recursive and nonrecursive aliases?

There are no recursive aliases. All aliases are non recursive. Therefore this has no effect.

It is simple and reasonable but I'm worried that I don't understand why @diml was not confident

I think diml's comments were made before he refactored the entire alias situation to get rid of recursive aliases. I think now the implementation is a little simpler - not that it was very complex before either however.

@bobot I have the time but I'm just not sure how to add such a test. We can't really control how jbuilder is invoked in any of our tests, and to test this setup we need to execute the same test command twice (repeating with --force).

@bobot I've added such tests. thanks.

@bobot. Agreed, I renamed the PR. I think the commit should stay the same because it does introduce a general purpose alias forcing mechanism. Though in that case, I should separate the commit that introduces the --force option.

I just squashed everything and wrote a decent commit message.


Unclear instrusctions

hello I see on the documentation you guys use const spotify = new Client("NO TOKEN"); what am I supposed to put in the strings because what ever I try I keep getting undefined from token

Hey there, thanks for joining us today.
It seems like the documentation is unclear to some users, I apologize for it.
But I will try my best to help you out with this issue,
While getting a token you can keep the token as anything rather it would be your previous token.
Here is an example of getting Spotify access token - >
const {Client} = require('spotify-api.js')
const client = new Client('any')
client.oauth.get({
  client_id : "238fa6ea7adb4c4da04f35265d74d121",
  client_secret : "f403a4a5f6e44db09311671738585808"
}).then(token=>console.log(token))

And also I would like to suggest you to use the latest version spotify-api.js version from the npm but incase you need the version number here it is - 3.0.2.
If you need more help free feel to comment down below.
I would be happy to help you out :)

Hey there, thanks for joining us today.
It seems like the documentation is unclear to some users, I apologize for it.
But I will try my best to help you out with this issue,
While getting a token you can keep the token as anything rather it would be your previous token.
Here is an example of getting Spotify access token - >
const {Client} = require('spotify-api.js')
const client = new Client('any')
client.oauth.get({
  client_id : "client id",
  client_secret : "client secret"
}).then(token=>console.log(token))

And also I would like to suggest you to use the latest version spotify-api.js version from the npm but in case you need the version number here it is - 3.0.2.
If you need more help free feel to comment down below.
I would be happy to help you out :)

I prefer you to watch the readme docs first and then move up with the docs...
The readme will give u a clean way to move up
Client is nothing but require('spotify-api.js').Client

I guess he has solved this issue...
Incase if you are back, reopen this issue...


Fix usage of ref text role

A ref role can only reference anchors, not implement references. Besides, the _ is not part of the anchor name, but part of the syntax to define an anchor.
Fixing the syntax in the test case shows that references work as expected using escape characters, but there is an issue in the rendering of the section title in the reference when using named phrases. I can look into this next week, if needed.

Hm, this is closed but it should not, could you please change the base branch so we can merge this.

see https://github.com/phpDocumentor/guides/pull/779


Color update: title, activity bar, status, tabs, panel

Changes:

custom title bar on mac to get same color as activity bar and status bar
status bar to get the same color as activity bar and status bar (unless debugging, empty workspace)
activity bar gets a VS-Light theme coloring
less borders around tabs
panel to get same background color as viewlet and a slight border to the left as separator to distinguish from the editor area

Try Out:

Open settings and configure "update.channel": "none" to disable automatic updates
Mac: Download
Linux: Download
Windows: Download

Dark Theme

Light Theme

HC Theme

+1, although I personally liked the blue band at the bottom.

:-1: for the light theme. too much grey

Here is what works well for me

less borders for tabs (across all themes)
background color of panel in dark theme being same as sidebar
I am not so much opposed anymore to the title bar color being the same as activity bar, though I like the current color better. I am not sure about the added value of having both parts use the same background

And here is what does not:

overall light theme does not work for me
I really like our blue status bar color because for me it is a way of recognise the VS brand and distinguish from other editors

I pretty much subscribe to @bpasero's opinion.

Atom's light theme was really good if i remember correctly. More 'soothing'.

Same as @bpasero with the exception that I would prefer the panel to be the background color of the editor due to:

It is an editor-like content most of the time and it should be as similar to the editor as possible. We already got a comment that it shuold be indented the same way as the editor so it is easier for the eye to swtich from one to the other (same holds for color)
If it is the viewlet color then the background is not customizable through themes, and that just looks bad in some crazy themes

I think removing the lines from the tabs is a good change and removes some subtle distractions, although I would like to see what it looks like with multiple tab groups, especially in horizontal layout.
I agree with the comments about the dark borders with the light theme but I wonder if the rest of the proposal should just be something that people can configure or set with a theme? For example, @isidorn makes a good case for why he would like the panel background to be the same colour as the editor background but personally I would like it to be different. Many other editors and IDEs have an integrated terminal UI that has a different background to the editor and I like the feeling of being somewhere 'different' when I switch between the terminal and the editor.

@stevencl the purpose of the download links was so that you can play around with these changes 👍

D'oh! Completely missed that.
I can confirm that I like the way that horizontal layout looks :-)

Dark theme looks pretty slick this way, and frankly I like the status bar change on the light theme as well, gives the editor a more polished and streamlined look if you ask me.
It deviates from the Visual Studio brand, but not by that much imho. The VS 'brand' thing for me is primarily the activity bar showing the mode, not a specific color. Or to put it another way, the brand is in specific little details in functionality, not theming details.
Agree with @isidorn though that this should be open to theming, people can be very picky about stuff like this, honestly I'll probably be a bit bummed myself if the dark and light themes don't land in the next update exactly as shown now that I've seen it ;-)

Thanks for your feedback on the light theme.
Here are some proposed revisions.
(@bpasero I updated the PPT deck I sent earlier with the new color values).
NEW

vs. OLD

I lightened up the colors for the Activity Bar, statusbar and titlebar

@bgashler1 I am not seeing a new color for the activity bar background (and title, status) in light theme so I went ahead and copied it out of the deck. Please verify:

E6E6E6 for background of activity bar, title and status in light theme
SVGs get a fill of #000000 in light theme

@bgashler1 It does seem to get better, but there's still something off about the whole big picture. The more I think about it, the more I come to the conclusion that it's the status bar. It just doesn't feel right if it blends in with the rest.
Also, it's hard to get a feeling for it with the screenshots, builds would be much better. 👍

I ran new builds with latest changes:

Mac
Linux
Windows

Having tried out the light theme in those builds:

The hover feedbacks from the status bar are all gone.
The status bar background colour doesn't seem to be the same as the activity bar
I have the overall feeling I'm looking into the negative of the original design. This is especially noticeable in the status and activity bars' icons.

It does feel better than just looking at the screenshots thought.

Tried it out and overall I do not feel like this is an improvement of the current design. Some details:

Git status in the status bar now feels brokenly positioned because of all the grayness - it feels like it should be central beneath the activity bar
Lot's of notifications in light blue seem like they are screaming for attention now. Before they blended more nicely due to blue status bar and now since everything is gray the blue is very strong. Example: open workspace with no git and open git viewlet
I like the black activity bar icons - they look smother then our current gray ones
Feedback from before: it feels like everything is in the frame. Panels feel to me like they should be the color of the editor - more details in the comment above

Bottom line: changing the default theme will be a shock for a lot of users. Even in the case that we improve the looks which IMHO is not the case now. Due to that we should just leave the default as it is and invest in making the workbench themable.

Per our discussion today, we will not modify the default themes, but we will ship these modifications as UI themes later on.  See #16245


CLI misinterpretation of the first tool argument as combined short options - e.g. ide java -version

Actual behavior

if the first argument of a tool starts with "-", then CliArgs wrongly interprets it as combined short options. E.g. -version is interpreted as -v -e -r -s -i -o -n

Steps to reproduce
For example in java, but it's the same for other tools as well (like mvn):

Note: the bug is just for ide java -version, all the other cases work fine:

ide java --version
 java -version
 java -- -version

Might be a feature, and not a bug, considering the following design choice:
https://github.com/devonfw/IDEasy/blob/5a5c2abf0702cb5fbdbc14d7a2be36fe8eb00529/cli/src/main/java/com/devonfw/tools/ide/cli/CliArgument.java#L174

Seems to be a bug because running this: ide mvn package -DskipTests lead to:
Running command 'D:\Projects\ideasy-dev\software\mvn\bin\mvn.cmd' with arguments 'package' '-D' '-s' '-k' '-i' '-p' '-T' '-e' '-s' '-t' '-s' failed with exit code 1!

@jan-vcapgemini Let me take over this issue and try to create a test and fix for it.

I've not managed to reproduce this issue with a test yet. Possible solution could be in AbstracIdeContext/apply.
if (property.isMultiValued()) {
  trace("Property is multivalued, prevent short options");
  arguments.endOptions();
}


State where to open the linked document.

The current implementation opens the link on _self but I have a need to open the link on _blank - as per these values.
This PR modifies the Polymer to enable this, whilst still defaulting to _self to prevent change of behaviour to any current consumers of the component.

Nice one @cgourlay! Thanks for the contribution and Happy first time contributing 🎉


config.toml: update releases with the latest patches.

This will bump the versions of the config.toml according to the latest release patches for each individual version.
It also replaces the master branch with main
/assign @jimangel @irvifa @sftim

/cc @reylejano

/lgtm
/hold

we can go ahead and merge this now, since it's targeting the dev branch.
/hold cancel


Stripping line comments

Hello!
Is jcpp capable of lexing and removing C++ style line comments?
// This is a comment

I can't see anything in the API to do this, and there doesn't seem to be a Feature value that would enable it. I'm seeing line comments in the output of the preprocessor, so presumably it doesn't do it by default, either.

If Feature.KEEPCOMMENTS is off, they should be removed.


Wrong tensorflow rosdep key

package.xml:
<depend>tensorflow</depend>

but:
$ rosdep resolve --rosdistro foxy tensorflow
ERROR: no rosdep rule for 'tensorflow'

This has the consequence that tensorflow is not automatically installed for the user if he doesn't already have it and runs rosdep install --from-paths ., which is expected to install all required dependencies.
There is a pip alternative available in rosdep:
$ rosdep resolve --rosdistro foxy python-tensorflow-pip
#pip
tensorflow

This has the disadvantage that it autoinstalls the non-GPU version via pip.
Or you can use
$ rosdep resolve --rosdistro foxy python-tensorflow-gpu-pip
#pip
tensorflow-gpu

Which automatically installs the GPU version. But that has (again) the unwanted effect of installing the GPU version even if the user doesn't want it.
Package format 3 brings conditional dependencies. You could for example install the CPU version by default, and let the user choose the GPU version by setting an environment variable, e.g.
<depend condition="$TF_GPU != 1">pyhton-tensorflow-pip</depend>
<depend condition="$TF_GPU == 1">python-tensorflow-gpu-pip</depend>

That seems to me like the best solution, but it needs to be mentioned in the readme when implemented.
Aside from that, <depend> is too "strict". As this is a pure pyton package, <exec_depend> should be enough.

Thank you!
I'm going to update the package xml files.
Actually from Tensorflow 2.2.0, there is a single package for both CPU and GPU versions, see here
https://www.tensorflow.org/install/pip#tensorflow-2-packages-are-available
so  using pyhton-tensorflow-pip is enough.
Tested using
import tensorflow as tf
print("tensorflow built with GPU -----> ", tf.test.is_built_with_cuda())


Change access control to internal for isValid(index: Int) -> Bool from Array extension function

Fixed with this pull request.


Build failures in RAC/Rx framework targets due to prefix-less type names

Hi guys. Today I pulled master and tried building all targets on all platforms in the project, to make sure all was gooby. I noticed that ReactiveMoya and RxMoya targets have incurred some errors as a result of the prefix-less type name changes.

Errors like this are happening on uses of types like Moya.Completion because Moya is only actually the module name in the "base" Moya, and the base source is shared. The reason this can't work is because Swift doesn't currently provide a way to reference things by the "current module." A lot of the decls in the source don't actually require the prefix where we use it, but some do, due to ambiguity, etc.
From what I can see, here are a few ways to fix this:

Convert the Rx/ReactiveCocoa additions be extension frameworks that themselves link against Moya
Revert type names back to having the Moya prefix
Change the reactive framework targets' module names to Moya (though this would be kinda weird, linking to RxMoya.framework but using import Moya)

I had previous said I saw no drawbacks to moving to this naming convention, so I apologize 🙁 but I'd like to hear thoughts on what the best option for resolution is.

Hey, no problem! The third option sounds appealing; it's how CocoaPods works anyway. We can also use preprocessor directives cleverly somehow maybe.

I may have spoken too soon about that option. It seems that Xcode for whatever reason won't let you alter the module name setting.

It appears this was already brought up in the description of #310. Definitely something we should fix before doing a release with all of these new changes lest we break Carthage support.

Ya. I am unsure of how to solve this. If you change the module name and the framework name it works. The problem with that is that it build 3 frameworks but overwrites the previous one since it is also called Moya.framework. Im gonna try to rename them in the post build phase. Maybe that will work.

I believe I found a solution to this problem. I still need to test out if works with Carthage but it works fine in Xcode so I don't see why it wouldn't work.


Does I❤LA have comments?

Does it already?
If not, should it?

Only for parameters now.
edge weight matrix are the comment for w
w: ℝ^(n×m): edge weight matrix

I wonder if we should allow comments throughout the code. For example:
given
n ∈ ℤ : size of graph
E ∈ {ℤ²} : directed edges

A_ij = { 1 if (i,j) ∈ E : adjacency matrix
D_ii = ∑_j A_i,j : degree matrix
L = D⁻¹( D - A ) : normalized Laplacian

where
A ∈ ℝ^(n × n)

Colons (:) seem like a really awkward choice for a comment delimiter. We already use it for Frobenius inner product (FroProduct). On the chalkboard, I might not write anything (obviously problematic) or I might write a long dash (e.g., emdash – not to be confused with -). Another reasonable option might be " (.vimrc and probably others use this as a comment symbol

For reference, here's what that example looks like with emdash
given
n ∈ ℤ – size of graph
E ∈ {ℤ²} – directed edges
A_ij = { 1 if (i,j) ∈ E – adjacency matrix
D_ii = ∑_j A_i,j – degree matrix
L = D⁻¹( D - A ) – normalized Laplacian
where
A ∈ ℝ^(n × n)
and with `"`

given
n ∈ ℤ "size of graph"
E ∈ {ℤ²} "directed edges"
A_ij = { 1 if (i,j) ∈ E "adjacency matrix"
D_ii = ∑_j A_i,j "degree matrix"
L = D⁻¹( D - A ) "normalized Laplacian"
where
A ∈ ℝ^(n × n)

Another argument is that we shouldn't have comments at all. In this universe, all comments appear outside the I❤LA blocks in the containing language or in the literate programming environment. I'm hesitant to recommend this. I❤LA code is not just a chunk of data (like .json which doesn't have comments IIRC)

Currently in the paper we write: "I❤LA allows comments for type declarations, but not comments
in general. I❤LA is designed to support notation-heavy expressions and type definitions in papers, not entire papers. It is a future goal to turn I❤LA into a literate programming environment."
I think we should address this at some point. I don't love the comments at the end of a statement. I read the variable declarations comments as an approximation of "where t ∈ ℝ is the time at which the ball is launched, x ∈ ℝ^n is the initial position of the ball". We currently use ":" instead of "is" and require newlines. I think of it like a dictionary list:

dog: a domesticated wolf
cat: a domesticated lion

For the statements, I think any textual description should be on separate lines, as if the formulas were display math in latex interspersed among prose. We once mentioned in passing the idea that any line that doesn't begin "identifier ∈" or "identifier =" should be treated as a comment. That idea would make for a very markdown-like syntax in that it is no syntax. My only concern is that it could constrain future additions or lead to accidental errors (such as a comment of the form: "Anything ∈ ℝ^n can be projected to ...").

"any line that doesn't begin ..." sounds great to me. I think it's worth introducing that and seeing what happens.


MB-12919 weight ticket integration

Jira ticket for this change
Summary
Is there anything you would like reviewers to give additional scrutiny?
this article explains more about the approach used.
Setup to Run Your Code

💻 You will need to use three separate terminals to test this locally.
Terminal 1
Start the Storybook locally.
make storybook

Terminal 2
Start the UI locally.
make client_run

Terminal 3
Start the Go server locally.
make server_run

Additional steps

Access the
Login as a

Verification Steps for Author
These are to be checked by the author.

[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

Verification Steps for Reviewers
These are to be checked by a reviewer.

Frontend

[ ] User facing changes have been reviewed by design.
[ ] There are no aXe warnings for UI.
[ ] This works in Supported Browsers and their phone views (Chrome, Firefox, IE, Edge).
[ ] There are no new console errors in the browser devtools
[ ] There are no new console errors in the test output
[ ] If this PR adds a new component to Storybook, it ensures the component is fully responsive, OR if it is intentionally not, a wrapping div using the officeApp class or custom min-width styling is used to hide any states the would not be visible to the user.

Backend

[ ] Code follows the guidelines for Logging
[ ] The requirements listed in Querying the Database Safely have been satisfied.

Database
Any new migrations/schema changes:

[ ] Follows our guidelines for Zero-Downtime Deploys
[ ] Have been communicated to #g-database
[ ] Secure migrations have been tested following the instructions in our docs

Screenshots

Messages

:book:
:link: MB-12919

  Generated by :no_entry_sign: dangerJS against 7ac3dade3a0ebd9193630fb23550f7f1a419d172

@ronaktruss One thing is we don't remove and of the existing uploads if the user changes their answer on trailer ownership/meets criteria.  I guess it's good they could change their mind and the uploads would still exist.  Maybe on them actually completing closeout we could remove them otherwise we'll have to filter them out in the fetcher backend so the office user doesn't review them.

@ronaktruss One thing is we don't remove and of the existing uploads if the user changes their answer on trailer ownership/meets criteria. I guess it's good they could change their mind and the uploads would still exist. Maybe on them actually completing closeout we could remove them otherwise we'll have to filter them out in the fetcher backend so the office user doesn't review them.

Yeah that's definitely one situation that we don't "gracefully" handle. I was under the impression that we would still be sending that information and have the counselor modify/reject it if needed. Personally I'd probably advocate for preventing the user from submitting with a proof document if they have no, but I recall that being not part of the initial roll out.

You can also probably delete this hardcoded data I added for review screen acceptance testing https://github.com/transcom/mymove/blob/227fbf14bd906ca9dd1383ac1fa83c002c26826e/src/pages/MyMove/PPM/Closeout/Review/Review.jsx#L65-L79


psr/http-message 2.x support

I would like to use this package with psr/http-message v 2.x. I could easily provide PR with update to composer.json to allow it, but there is a problem with neomerx/cors-psr7 which seems to be no longer maintained.
In my projects i use my fork which replaces the original package, so adding |^2.0 to composer.json would be enough for me, but keeping the neomerx/cors-psr7 dependency would mean that this package will be never tested against psr/http-message v 2.x.
What are your thoughts about this package future? Are you willing switch to some neomerx/cors-psr7 fork or fork it yourself?

I am currently doing more Kubernetes stuff than programming so I do not want to maintain any new libraries. But if neomerx/cors-psr7 is dead and someone (you) are willing to start maintaining a fork, I am ok switching to it.

Thank for the reply. I created an issue in the neomerx/cors-psr7 repository.
As for maintaining my fork, I have no problem with that, I would just have to sort out some infrastructure stuff (for now it's just a mirror from a private Gitlab repository) to ease accepting the PRs and issues.
In the meantime, I submitted #90, feel free to close it if you don't want an untestable code in your repository.


Add GPT-NeoX "coming soon" to README

We at EleutherAI are going to integrate the TransformerEngine into our GPT-NeoX library, and wanted to go ahead and indicate this in the README.
Look forward to completing full support within the next month!

Thanks @Quentin-Anthony, this is great! Could you sign-off your commit?

Tired of wrestling with git commit histories. I'm just going to open a new PR with these changes on a clean branch.


feedly theme not shown in TT-RSS 18.12 preferences

Hi
I have running tt-rss 18.12 in docker with last version linuxserver/tt-rss :
# docker inspect -f '{{ index .Config.Labels "build_version" }}' tt-rss
Linuxserver.io version:- 18.12-ls2 Build-date:- 2019-02-12T14:36:56+00:00

I have copied css files to tt-rss/themes.local/ dir following README.md :
$ ls -lhF /config/www/tt-rss/themes*
/config/www/tt-rss/themes:
total 12K
-rw-rw-r-- 1 abc abc  328 Nov 30 22:02 compact.css
-rw-rw-r-- 1 abc abc  192 Nov 30 22:02 default.php
-rw-rw-r-- 1 abc abc 4.0K Nov 30 22:02 night.css

/config/www/tt-rss/themes.local:
total 64K
drwxr-xr-x 3 abc abc 4.0K Feb 14 13:31 feedly/
-rw-r--r-- 1 abc abc  60K Feb 14 13:31 feedly.css

$ md5sum /config/www/tt-rss/themes.local/*.css
471016e09edef84ee934f7d179689237  /config/www/tt-rss/themes.local/feedly.css

$ find /config/www/tt-rss/themes.local
/config/www/tt-rss/themes.local
/config/www/tt-rss/themes.local/feedly.css
/config/www/tt-rss/themes.local/feedly
/config/www/tt-rss/themes.local/feedly/fonts
/config/www/tt-rss/themes.local/feedly/fonts/texgyreheroscn-bold-webfont.woff
/config/www/tt-rss/themes.local/feedly/fonts/texgyreheroscn-regular-webfont.ttf
/config/www/tt-rss/themes.local/feedly/fonts/texgyreheroscn-regular-webfont.woff
/config/www/tt-rss/themes.local/feedly/fonts/texgyreheroscn-bolditalic-webfont.woff
/config/www/tt-rss/themes.local/feedly/fonts/texgyreheroscn-italic-webfont.woff
/config/www/tt-rss/themes.local/feedly/fonts/texgyreheroscn-italic-webfont.ttf
/config/www/tt-rss/themes.local/feedly/fonts/texgyreheroscn-bolditalic-webfont.ttf
/config/www/tt-rss/themes.local/feedly/fonts/texgyreheroscn-bold-webfont.ttf

There was no feedly theme in TT-RSS preferences :

Same here...

Strange... I have no explanation. Have you tried putting the files into themes instead of themes.local? This would be the old way.
Also, can you ensure that the dockerized ttrss version is 18.12 and not older?

Already tried. Putting the files into themes/ doesn't work either.
I'm not using the Docker version, but my test installation is quickly set up via Softaculous, footer states Tiny Tiny RSS v18.12

I just ran into the same issue. Have confirmed that it is not a file permission issue.

Adding the following line to all css files got the themes to show in the Preferences:
/* supports-version:18.12 */
However, this was the result:

Hi @levito
TT-RSS v18.12 was no lib/flat-ttrss/ dir :
https://git.tt-rss.org/fox/tt-rss/src/4db888c7c281d13d9e2d0a5b9f0fb3aa063e8842/lib
lib/flat-ttrss/ dir was only in current master branch :
https://git.tt-rss.org/fox/tt-rss/src/master/lib/flat-ttrss
feedly.css first line @import url(../lib/flat-ttrss/flat_combined.css); imported a not existing file.

Sorry for the inconvenience, ttrss versioning is kind of broken. There was a short period of time when everything was changing rapidly and the version was already at 18.12. If you are not seeing this theme in the preferences, you are probably using this state of ttrss code. Please update from ttrss master then. Since ttrss uses rolling release, that's the official way to go anyway.


[Feature Request] Add some sort of helper/demos in the python modules

Current Behavior

Currently, no demos or anything.
Desired Behavior

Inspired from here: https://twitter.com/willmcgugan/status/1553643438909915136
Add some demos/helper strings/documentation when running the module through this command python3 -m robyn.class_name

Try adding a documentation walkthrough(maybe an interactive TUI) when someone would run python robyn.


I can't figure out what internal error is

Same here 🤔

guys, do opencommit config set OPENAI_API_KEY=<your_api_key> and update the lib with npm i -g opencommit

Also, remember to add a payment method in OpenAI folks 💸
It would make sense to make this section in the docs a bit more clear about this.

@mikkelhartung is it necessary to add a payment method? If the answer is yes, that's my error I guess

@brunoricardosecco OpenAI is a pay-as-you-go service, so I would expect that the account that the API key is attached to should have a payment method in order for it to work 😄
I got the same error initially, but then added payment information and after a few minutes I was up and running.

Thank you so much!

I already setup the config, I try to commit another code with short feature and it works. It's show "Internal Error, try again" even when I forgot to pull from remote. But here is another error and i still don't know what error is.

there is some error handling, update the package npm i -g opencommit

Now I can see the error. Because of causing too many request so it can't generate the commit. I add 1 package in project but open ai can't summary. Hope Open AI can do it better or you can do it better. If there are no more argument about the issue, I will close this.

@GuardianOfGods close pls <3


🔧⚙🔩 [Breaking Change] (code + test) Parameterize all options in crawler module implementation.

Target

Parameterize all options in crawler module implementation.

Modify Code Scope

Source Code

module crawler
module model.__init__

Effecting Scope

Nothing, just parameterize options in implementation.

Description

Parameterize all options in implementation.

wait_time in function wait_for_task.
wait_time in function ** wait_and_standby**.
threshold of reset timeout record if it doesn't time out several straight times in function ** wait_and_standby**.
wait_time in function ** wait_for_to_be_standby**.
update_time, update_timeout, heart_rhythm_timeout, time_format in function ** register_heartbeat**.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

31 of 33 (93.94%)  changed or added relevant lines in 2 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage increased (+0.2%) to 94.411%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

smoothcrawler_cluster/crawler.py
21
23
91.3%

Files with Coverage Reduction
New Missed Lines
%

smoothcrawler_cluster/crawler.py
3
88.52%

Totals

Change from base Build<PHONE_NUMBER>:
0.2%

Covered Lines:
1098

Relevant Lines:
1163

💛  - Coveralls


a few questions

Is it possible to make a mercator projection map? the current one kind of messes up the terrain a bit in the north and south of the map.
it it possible to make the map wider and move the far eastern edge of siberia to next to russia instead of on the other side of the map?
How does the mountain generation work and can it be fixed? from what i saw especially in greece and norway the mountains are just jagged spikes and not smooth at all.

Probably from a height map in worldpainter. You should try it, its fun! Ive done it before (Im not the creator)
Definitely. It dpends on the height map of the map.
It works from the height map. The height map shows the heights of each block. It gets better as the scale gets more detailed because theres more to work with. Its meant to be accurate ,not nescesarily specifically for survival.


Non-English literals are rendered with escape sequence

Hi, Thank you for a nice library.
I tried latest Kuma setup with wasm enabled and found a bug.
For an input component, If I pass string literal to the value prop like
<Input type="text" value="コメント" width="250px" />

The rendered text is escaped.

I also noticed the same behavior for other props like placeholder and title.
I'm using  "@kuma-ui/vite": "1.3.1" and have plugins: [react(), KumaUI({ wasm: true })] in vite.config.ts.
It works correctly when I remove { wasm: true } from the config.

@yahiro07
Thank you for the report! You are right, this is indeed a bug. I'll look into it!