Buttons and blockquotes

Integrate UW style buttons and blockquotes
https://brand.wisc.edu/uwmadison_templates/

This should have been addressed by the inclusion of the default UW template styles.  See the blog post "default UW template styles" for details:
http://<IP_ADDRESS>:4000/uw-jekyll-theme/blog/2024/default-styles/

Nice, thanks! The example post is all written in html. I'm curious how one would indicate this styling in a more markdown oriented syntax.
This might be relevant:
https://boringrails.com/tips/jekyll-css-class

we might want to add a special liquid tag for blockquotes

For reference, the source is here:
https://github.com/UW-Madison-DSI/uw-jekyll-theme/blob/master/_posts/2023-05-28-default-styles.md

ok, so this works:
## Test h2 and blockquote style with markdown syntax
{: .uw-mini-bar}

> "All models are wrong but some are useful"
George Box

>   “Whatever may be the limitations which trammel inquiry elsewhere, we believe that the great state University of Wisconsin should ever encourage that continual and fearless sifting and winnowing by which alone the truth can be found.”
The Board of Regents, 1894
{: .uw-stylized-quote}


Feature Request: add actual link to "Not found (did you mean... ?)" page

Describe the problem
This is related to the 404 "did you mean...?" page added to fix #2838 which displays when you have a base path and run the dev server without the base path after the address.
That page is very helpful but it still requires you to actually copy and paste the base path after the address.
Describe the proposed solution
I would like to see the /base-path/? part just turn into a clickable link which would take you to the correct place (not sure if this is actually possible though)
Alternatives considered
No response
Importance
would make my life easier
Additional Information
No response

this was added at some point — closing


[Scenario] Santuário das Mazelas

What kind of mission do you want to add (mark with an X, e.g. [X] Descent)?

[X] Mansions of Madness
[ ] Descent

Please enter the GitHub Url to your scenario here
https://github.com/Bigdadd1/santuariodamazela

Have you renamed your repo? The link above is a dead link.
I can see this in your GitHub, is this it?
https://github.com/Bigdadd1/mapa_mom_oresgatesombrio

sry, I thought that I had to create another repository. I transferred the
new scenario to the original folder that you previous mentioned:
https://github.com/Bigdadd1/mapa_mom_oresgatesombrio
Hope it is right!
Em ter., 8 de set. de 2020 às 03:35, scrubbless<EMAIL_ADDRESS>escreveu:

Have you renamed your repo? The link above is a dead link.
I can see this in your GitHub, is this it?
https://github.com/Bigdadd1/mapa_mom_oresgatesombrio
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/NPBruce/valkyrie/issues/1354#issuecomment-688649815,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQZYY2CD53QMEIDWI5LC4SLSEXGERANCNFSM4Q7A26QQ
.

Hi @Bigdadd1
We can't upload scenarios that have spaces in their folder paths. The easiest way to fix this is to open:
%appdata%\valkyrie\mom\editor
Find your scenario and rename it to a name that does not contain any spaces of special characters (avoid accents too please).
Once renamed, open Valkyrie editor, enter your scenario and create a package. Upload your new package to your GitHub.

I did not know that, sry. Uploaded again, now fixed special characters and
spaces.
Em ter., 8 de set. de 2020 às 08:41, scrubbless<EMAIL_ADDRESS>escreveu:

Hi @Bigdadd1 https://github.com/Bigdadd1
We can't upload scenarios that have spaces in their folder paths. The
easiest way to fix this is to open:
%appdata%\valkyrie\mom\editor
Find your scenario and rename it to a name that does not contain any
spaces of special characters (avoid accents too please).
Once renamed, open Valkyrie editor, enter your scenario and create a
package. Upload your new package to your GitHub.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NPBruce/valkyrie/issues/1354#issuecomment-688812200,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQZYY2BXU66OIIERFXONFALSEYJ5NANCNFSM4Q7A26QQ
.

Great, thanks @Bigdadd1
The scenario has been added, it should be listed within the hour.

thank you for creating a amazing software and let us enjoy even more MoM!!
Em ter., 8 de set. de 2020 às 09:52, scrubbless<EMAIL_ADDRESS>escreveu:

Great, thanks @Bigdadd1 https://github.com/Bigdadd1
The scenario has been added, it should be listed within the hour.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/NPBruce/valkyrie/issues/1354#issuecomment-688845300,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQZYY2BHDWOIEOZ73UPAZF3SEYSIJANCNFSM4Q7A26QQ
.


Some comments

So far I just looked at the things you've done in the complex subdirectory, because I pretty much believe that without any generic types like Complex<T> or Vector<T> there would be no major hitch in doing things along these lines. I can't yet say that it will or won't work even so, but here are the concerns I see with the ones you have done so far:

In isReal.ts you have defined the generic function type IsReal, using up that generic. But undoubtedly we would want to have an isReal implementation for number that would always return true. How would that be typed, since you can't "extend" a generic? It's also slightly misleading/inconsistent in that elsewhere in the code, if I want to get the function type of add on arguments of type Foo I do Add<Foo> but if I do IsReal<Foo> I don't get the function type of isReal on an argument of type Foo, I get the function type of isReal on an argument of type Complex<Foo>. How do I remember that? I am worried about not having a uniform way to obtain the function type of the operation with a given name on a given tuple of parameter types...
I really don't like that to specify the dependencies on add and equal, you have to mention the name of each one three times: once in the argument, again in the type of the argument, and again in the template that gives the specific type of the dependency. I worked really hard to avoid such redundancy in typocomath. The first scheme had none, but when I couldn't get it to work, I accepted for now a doubling of the mention of the name of an operator, but only where it is defined: once in the name of the function and once in the template that checks its type. There is still only one mention of the operator name in each use as a dependency, so that's not as bad as it could be because there are many more uses than definitions. And I'd still like to get rid of the doubling of the name at definition time, but haven't quite figured out how to do that yet (there are more pressing problems like just getting the whole thing to compile).
Then in arg.ts yet a third way to obtain the function type of an implementation is introduced: ArgComplexNumber (as opposed to Arg<Complex<number>> or Arg<number>, which I might guess it would be one of from the first two examples of Add and isReal. And if later other implementations of arg are added for other parameter types, it seems like we've started down the road of combinatorial explosion of type names; we might end up with an ArgComplexBigint and an ArgFoo and an ArgQuaternionNumber etc. etc.
Also I thought we wanted to do away with the extra layer of function call if there are no dependencies?  In other words, the definition of arg there should just be infer: z: Complex<Number> => Math.atan2(z.im, z.re), shouldn't it? Certainly in typocomath I have been leaving the dependencies off altogether when there are none, and I do think we can get Dispatcher (typed-function) to handle that.
In complex.ts, not sure what I would do with the ComplexFn<T> generic -- there's not much TypeScript can do with unions of function types, sadly. And this introduces a fourth mechanism for finding the function type of an implementation: never mind the Fn suffix for now, since surely we can work out a naming convention that avoids that, but I now have to know/remember that to get the unary function type I use a 1 suffix and the binary I use a 2... I have a real worry that along these lines it will become a constant pain to look up/remember how to get the function type for each different dependency of a new operation I am writing. I am strongly in favor of a single minimally redundant notation for dependencies, based on my experience with writing current mathjs operations.
Incidentally (this is a minor point), as far as I can tell there is no way to actually make zero() a nullary function. Remember at runtime it is going to have to actually return the correct zero value, at least among number 0 and bigint 0n, which are different entities, and all type information is gone at runtime, so it has to have something it can use to tell what zero to return, so it needs to take an argument of the type of thing that the zero is wanted for...
In quaternion.ts, since you used the ComplexFn<T> function type that is completely ambiguous between the unary and binary complex(), there could be no way for the Dispatcher (typed-function) to tell whether to supply the dependency as the unary or binary version of complex. So this would really need to be ComplexFn2<T> for there to be any hope for the typed-function to get built properly.

OK, hopefully that makes some of the issues I have been grappling with clearer.  I will add another batch of things to typocomath and then you can have a go at getting all of that working.

Thanks for the feedback Glen! I've added some commits addressing your points.

Ok I've extended isReal.ts to implement two signatures: isReal(number) and isReal(Complex<T>). Of course we can organize it in different files if we want.

Yes agree. The name repetitions remind me of the years I worked with Java 😂 😢 . I've extended generic/absquare.ts with a couple of different approaches:

One cause is using destructuring or not: { square, abs } in the header, or dep.square and dep.abs in the usage. I personally prefer destructuring, since that way the actual logic is cleanest. But I think we do not perse need to enforce this, both can be fine.

The other cause is writing dependencies as an object or as an intersection type:
// object
deps: {
  square: Square<T>,
  abs: Abs<T>
}

// intersection type:
export type AbsDep<T> = {
   abs: Abs<T>
}
export type SquareDep<T> = {
   square: Square<T>
}
// ...
deps: AbsDep<T> & SquareDep<T>

This is personal preference too I think. At this moment I have a slight preference for the first: it is a bit more verbose, but it is so easy to understand, and interfaces like Square<T> are more powerful than the more specific SquareDep<T> which is usable only in one specific case.

Huh? It is not a new way, to me it is just the same as all other functions. I just literally translated the implementation of arg.mjs, which is an implementation for Complex<number> and not a generic implementation. The interface just matches the function. If we want to introduce a generic interface, we can, just like the other functions:
// we should move Arg and ArgComplex into /interfaces/
export type Arg<T, U> = (z: T) => U
export type ArgComplex<U> = Arg<Complex<U>, U>

// now, we can write out ArgComplexNumber and ArgComplexBigint.
// this is probably redundant though
export type ArgComplexNumber = ArgComplex<number>
export type ArgComplexBigInt = ArgComplex<bigint>

Now, arg may be a bad example, but I was thinking about a function that has a very specific interface that is only implemented by a single function, like say polynomialRoot(constant, linearCoeff, quadraticCoeff, cubicCoeff). In that case it makes sense to me to put the interface alongside the implementation.
So the general pattern that I have in mind here:

we can just use bare bone TypeScript types without any magic. We can reuse them everywhere, we can put them wherever we want. We have all freedom.
When there is a (generic) interface that has multiple implementations, we can put the interface in a shared place and reuse it everywhere.
when we have a very specific interface that has only one implementation, we can put it alongside the implementation itself.

Yes agree, it will be nice to omit dependencies if empty. I have to say, they do not add too much clutter, but it would be nice I think. In the pocomath approach, I can remove the {infer} wrapper object, then you get:
// with {infer} object and empty dependencies
export const add = {
    infer: (): AddNumber => (a, b) => a + b
}

// without
export const add: AddNumber = (a, b) => a + b

This pattern is very similar to typocomath:
export const add: ImpType<'add', [number, number]> = (a, b) => a + b

However, in both cases, we still have to somehow make clear to mathjs that this is a function that should be inferred from the TypeScript types. How do we do that? We could wrap the function in a call infer(...):
export const add: AddNumber = infer((a, b) => a + b)

Ow, there was indeed an issue with the type of ComplexFn<T>, you could not use it with one parameter. I changed it to type ComplexFn<T> = ComplexFn1<T> & ComplexFn2<T>, now you can use it both as complex(re) and complex(re, im), for example in quaternion.ts.
Your other point is an important one: how to figure out what dependencies are available? In typocomath there is a clear unified way to write things: you use ImpType<'add', [T, T]> and Dependency<'add', [T, T]>. In my pocomath+ts experiment, you define a Add<T> = (x: T, y: T) => T and use Add<T> at both implementation and dependency, but you could use different function namings like ComplexFn<T>, so a clear naming convention will be useful. In both cases you have to know the name of the function. In both cases you need to know whether the function actually exists. In typocomath you can enter any non existing dependency like Dependency<'foobar', [T, T]>. In pocomath+ts you can only use defined interfaces. Still, in both cases it could be that there is no runtime implementation available.
I do not understand what you mean with "this introduces a fourth mechanism for finding the function type of an implementation", can you explain that? To me there is only one, which works like:

I want to use a new dependency add in my function
In my IDE, I start typing "add", I press Ctrl+Space to open autocompetion
The autocompletion of the IDE presents me with two interfaces: Add<T> and AddNumber
I decide I want to use the generic one, and press Enter to insert the interface
Since the interface exists, I know for sure that the function exists and the name and parameters are correct. It could still be that a runtime implementation is missing though.
That's it...

How will actual usage work in typocomath? Right now I do not see a way to verify whether some function can actually exist. There is no autocompletion or anything when I'm typing Dependency<'add' ..., I have no idea about whether the function name exists at all or what arguments it would expect. I have the feeling that pocomath+ts gives more compile time guarantees and help then typocomath at this point.

Ahh, yeah good point. I'll change zero to how it was in pocomath, with one argument

I do not fully understand how quaternion should work ideally, and I just translated your implementation of quaternion.mjs straight into quaternion.ts. Why whould the former work and the latter not? (Also: maybe we do not need to spent to much time on quaternion and see it as an edge case).

B) I feel the syntax TypeScript chose for typing destructuring parameter lists is simply broken as it alway simply  forces redundant typing of property names, and hence it should simply not be used. And I feel we should strive very hard to avoid boilerplate repetition needed in the code; that's why I am pretty upset that right now typocomath is mentioning the operation name twice in each implementation definition, I do hope to fix that someday, but at first it was more important just to get it all compiling. And I don't see any difference in "power" between writing the Dep types or the implementation types: the dependency type, the implementation type, and the return type of an implementation are all intertranslatable with simple type operators. That's why typocomath provides ImpReturns<Name, Params>, ImpType<Name, Params> and Dependency<Name, Params> so you can obtain any of the three that you want, in a completely uniform way. But it feels to me like these type operators are uncomfortable to you, even though your pocomath+ts poc is using lots of generics, which is all type operators are...

D) I guess IDEs don't show you valid operation names in the first parameter position to the Dependency<> operator. I guess because syntactically that parameter is only bounded by string. (But the compiler definitely knows, it won't accept a typo in the name...) I guess I could try writing a narrower type bound on Name in the definition of that operator, to restrict it to just the valid keys, and see if that helps the ide. But personally I think that should be icing that comes after, and ide behaviors should not influence our choice of scheme, since people use all sorts of IDEs or none at all, and more importantly they do lots of reading of code without an IDE. So the more the code can stand on its own without IDE features, the better.

E) I am more worried about uses of implementations than definitions of them, since there's a lot more of the uses. That's why I am willing to accept the admittedly unfortunately complicated typing of implementations in the current typocomath scheme, although I have eased it somewhat in the latest version, because it supports totally uniform usage. I definitely would have preferred for TypeScript to deduce all the type info it needs from the definitions themselves; unfortunately I just couldn't get that to work, I think because of TypeScript's limitations in dealing with generic function types, but maybe just because I wasn't clever enough. I did verify on stack exchange that it's impossible in typescript to get the return type of the specialization of a generic function that matches a given call signature and that others have asked for that same feature. Also the current type scheme in typocomath is extremely close to the "workaround" that typescript type expert jcalz presented. So that's why I am not putting more effort into the first nicer-looking attempt, at least not at the moment -- I worry it simply can't be made to work. And anyway, even in your pocomath+ts you are defining types for implementations separately from the definitions of those implementations, so the current typocomath isn't worse in that basic way. As far as I see it, the only really substantive difference between the current typocomath and pocomath+ts is that the former trades off more intricate typings of the implementations for more uniform dependenxt specifications.

F) I guess there is one more difference: your solution to my concern about isReal was to create one overarching generic that should work for all types. But I think that should be avoided: in typocomath I have been careful that the typing of each implementation only types the instances of that operation that that implementation handles. Since isReal has different implementations for number and for Complex<T>, it should not assume a signature for all types T. The number implementation should provide just the typing for number parameters and the Complex implementation should provide just the typing for Complex<T> parameters, etc.
For example in typocomath nowhere is there any assumption or assertion that for all types T, multiply of a T and a T yields a T. Thus it should work if we wanted multiply on a Vector type to be the dot product so that multiply of two Vectors returned a number, everything should still work... we might or might not use that option but I bet there are places where the desired return types of operations do vary more than isReal so the "escape" of just making one general template won't be available. And I have tried to make the case that it's ill-advised even when available, as it's constraining future behavior in a way that may or may not turn out to be desirable.

Ok, that's all the thoughts I have at this round. So are you willing to try to type the latest version of typocomath (branch signature_scheme) completely according to how you envision so that the whole thing compiles and runs the dummy registration? Then we will really have two directly comparable versions for evaluating which way to go. Sorry that's some repeated work for you, sorry I didn't get more done on typocomath before you had the opportunity to jump in on pocomath. But it has been quite a struggle to support my goal of one clear syntax for specifying a dependency. Let me know if you're OK with doing that process again on typocomath. Thanks.

👍 I'll read up tomorrow and see if I can create a typocomath variant based on the second approach.

I think it will be helpful to schedule another video meeting to talk things through after that.

@gwhitney OK I've pushed two new branches to typocomath. I think it is time to try compare the different approaches, see what their pros and cons are, and understand how important these features are for both of us (that differs :) ).
I think it will work best to plan another video call to discuss the pros and cons, instead of typing more, we'll understand each other more quickly then I think.
I've named the approaches as follows:

approach1: pocomath (JS)
approach2: ImpType/Dependency (TS), branch signature_scheme
approach3: plain types (TS), branch appraoch3_plain
approach4: typealias (TS), branch approach4_typealias

I've started an Excel sheet where we can list features and compare how they work out:
https://docs.google.com/spreadsheets/d/1RWIOddTsaUpakJ0W0cQfFyr8WaVMphiTwXWkijzlwvc/edit#gid=0
I'm sure some of the "features" I list are not clear to you, and I'm sure the features are currently biased towards my viewpoint. Can you please add missing features that you think are relevant, fill in what features you find important, and if features are unclear, just ask me?

OK, I checked, and true, both approach3 and approach4 branches do compile and run all the dummy registrations. But they are not actually yet ready/appropriate for feature comparison with approach 2 as represented by branch signature_scheme or pocomath: in just the one test case I tried, they do not correctly type absquare (of course that's the one I tried first because I know from experience that it is a real typing challenge). To see this, add the following code to index.ts; it is a mockup of instantiating absquare for quaternions. (Please hold off a moment on your reaction that quaternions are an edge case that we don't "really" need to support; I believe they are actually an excellent probe as to whether we have gotten the typing "right", and all of the problems that show up there will be reflected lower in the hierarchy like at just Complex<Fraction> say and with all other templates that we want to do like Matrix<T> especially nested instances like Matrix<Complex<number>> which we definitely do want. So please grant for the moment that they are actually a very good laboratory/window into whether the typing is working. Then yes it is just icing on the cake that when the typing is all correct, we get quaternions with no additional code via Complex<Complex<number>>.)
import {Complex} from './Complex/type.js'
import {absquare as absquare_complex} from './Complex/arithmetic.js'

const mockRealAdd = (a: number, b: number) => a+b
const mockComplexAbsquare = (z: Complex<number>) => z.re*z.re + z.im*z.im

const quatAbsquare = absquare_complex({
   add: mockRealAdd,
   absquare: mockComplexAbsquare
})

const myabs = quatAbsquare({re: {re: 0, im: 1}, im: {re:2, im: 3}})
const typeTest: typeof myabs = 7 // check myabs is just a number

console.log('Result is', myabs)

Indubitably mockComplexAbsquare produces the square of the absolute value of a Complex<number>, and indubitably mockRealAdd adds up two results of mockComplexAbsquare. So I should be able to pass them as the dependencies of the absquare defined in the Complex subdirectory to get an absquare function that works on quaternions. And indeed, when I add the above lines to index.ts in branch signature_scheme, it compiles and console.logs the correct result of 14 = 0² + 1² + 2² + 3². And we know the analogous thing works in pocomath because of the unit tests. But the above code doesn't compile in branches approach3_plain or approach4_typealias.
So pardon me for being blunt but I am feeling like the only reason that you feel the typing can be done so "easily" as it appears in approach 3 or approach 4 is that you haven't yet had the opportunity to really grapple with getting a consistent core of a revised mathjs all working actually the way it needs to, in order to build up to a large-scale, consistent system. There are real typing challenges that neither approach3 or approach4 yet addresses. And once again, please don't dismiss quaternions as irrelevant; even if we don't actually care about providing quaternion functions, they are an analogy for any nested generic -- just the easiest analogy accessible in a core of number and Complex. We will definitely want nested generics, Matrix<Complex<number>> at the very least, but I assume once generics have really been integrated into mathjs there will end up being plenty of other examples.
So how do you want to proceed? Do you want to try to get one approach or the other or both to actually type this core of functions accurately? Or would you like me to try to get something like approach4 working plausibly well?
The difficulty is that for me, approach 3 is a complete non-starter for an actual direction for mathjs; as far as I can see, it means reiterating the entire type of every implementation every place it is used, which as far as I can see will be a complete non-DRY disaster as we scale up to mathjs-size, not to mention super-tedious. So as long as I am in blunt mode, I'm personally not really interested in putting any effort into approach 3.  Approach 4 is more plausible, but it still appears to have one flaw I see as key, which I will mention in the next comment.

My worries concerning approach 4: As far as I can see, it attempts to provide universal generic typings for all operations. I am anxious about this in two ways:

I am not convinced based on experience that TypeScript's type operations are suitable for all of the actual general relationships between input and output types of actual mathematical functions we want mathjs to comprise, if we go about it this way.
It represents a real shift in the typing philosophy of mathjs. So far, if you look at the implicit typings of current mathjs, or at the pocomath prototype, there is nowhere an assertion that the type of multiply on two entities of the same type is again the same type. There is just the conjunction of the assertions that a number times a number is a number, a BigNumber times a BigNumber is a BigNumber, a Fraction times a Fraction is a Fraction, etc. I am very worried that abandoning this approach for the sweeping generic approach of enforcing a T times a T to be a T will put a straitjacket on us that will not actually allow us to model the mathematical realities properly. For example, it certainly means we could never have a NegativeNumber type, since a negative times a negative is a positive. Of course, maybe we would never have a Negative type, but making this choice means we couldn't. And we couldn't make the product of two vectors be a number. Again, maybe we'd always have a different operator like dotProduct, but with a decision like this we are tying our hands. And there are dozens and dozens of operators. Any one of them might run into typing issues where they don't "fit" the generic. For just one more example that comes to mind, take floor. From floor of a number being a number, and it being the trivial identity operation on bigint, we might conclude that type FnFloor = <T>(x: T) => T. But then maybe we actually want floor(BigNumber) and/or floor(Fraction) to be a bigint, to capture at the type level that the result really is an integer. I think from a typing perspective, those would be good typings. But we can't just make type FnFloor = <T>(x:T) => bigint because I think we want a floor(Matrix<number>) to be either Matrix<Number> or Matrix<bigint>. You've talked about having implementation freedom; I think we want the freedom to just type only the specific return types of specific implementations, and not have to worry about conforming to generic typings that are going to constrain lots of implementations. Writing (and typing) just one implementation at a time seems much more in the spirit of mathjs as it stands.

And so that is what has led me to something like approach 2: it seems to me there needs to be a way to collect up individual "pieces" of the overall typing of a multi-way, run-time-dispatched operation 'foo' and combine them into some assembly from which TypeScript is then able to extract the typing for a specific instance of 'foo' and check it is being used consistently. And the only mechanism I could find in TypeScript for "collecting up" types like that is to extend an interface using the "declare module" syntax. So that's how I've ended up at approach 2. I agree that we/I should continue to try to simplify/polish how the types of implementations are specified, but that's the only hitch I see. Using a properly typed implementation of an operation is super easy and clear.
(I guess I can think of one other possible approach, namely to decide on a name mangling of operations and input signatures, and try to supply types for all of them, like add_number_number and absquare_complex_number. And then we will need some scheme that will give generic type operations for things like add_T_T or absquare_complex_T. I haven't yet seriously tried to get something like this to work because it seems to me like it needs a compile-time translation from types to literal string names, i.e. deriving 'number' from number. The other direction from strings to types is not too bad but types to strings, I don't really know if that can be done. But if we are absolutely at loggerheads on other approaches I could maybe give something like this a try.)
Anyhow, I want to make it absolutely clear that I am not being obstructionist here or trying to insist that approach2 is the only way. Remember, I previously had a scheme that extracted types directly from the implementations, and it worked at first, but I couldn't extend it to more complicated functions either because of inherent limitations in TypeScript or my lack of cleverness. And I would love it if you or me or anyone is able to come up with a DRY "direct" typing of all of the implementations of all of the operations. I just haven't seen or thought of any simpler scheme to actually do it than approach 2.

Ok I've pushed type fixes to both branches to make the test code pass, good point. There are a couple more similar cases, we can fix that in the same way. They output 14 though, not 7, but that is an implementation issue and not related to the types.
The thing was that for abssquare (and similar functions), the output does not necessarily is the same type as the input (like is the case for say type FnAdd<T> = (a: T, b: T) => T. That can be solved by adding a second generic type FnAbsSquare<T, U> = (a: T) => U. When having an implementation, you can use that like FnAbsSquare<number, number> and FnAbsSquare<Complex<number>, number>, etc.

OK, I will take a look.

you must not have pushed approach4, still doesn't compile for me.

you must not have pushed approach4, still doesn't compile for me.

Sorry, done now

At this moment I (still) do not see the added value of approach2 over a simple approach like 3 or 4, whilst it introduces a lot of complexity. The main difference I see is that return types are automatically inferred, but in practice I found that to be a drawback too: when refactoring to approach 3 and 4, it was difficult to figure out what a dependency was supposed to return, you can't easily see that. So I doubt if that really is a positive thing.
I like approach 4 quite a lot: it is simple and straightforward, and in the spirit of TypeScript. It prevents entering dependencies wrongly (you can't enter parameters wrongly, you can't enter a non existing function, you immediately see the types of parameter and return type, at least in an IDE 😁). And it is much more DRY than approach 2 and 3, where you have to enter full signatures again and again for every dependency (like (a: T, b:T) =>T or Dependency<'add', [number, number]>).
I hope my Excel sheet can clarify some of the pros/cons.

Shall we plan for a video call to discuss further? I think we'll understand each other faster that way.

It represents a real shift in the typing philosophy of mathjs

That is a good point, I'll give that some thought.

We can certainly do a video call next week sometime if you like. Send me some options.
But we can forget about approach 3, right? We are certainly not going to write out the full signature for each dependency every time it is used, right?
There is nothing non-DRY about the selection of a dependency in approach 2: you specify only the name of the operation you want to depend on, and the tuple of types that you want to be able to invoke that operation on. The Dispatcher needs the latter information to be able to supply your implementation with dependencies  as direct, non-dispatching functions -- that is exactly where the ~9x speedup of pocomath over current mathjs comes from. And let's be honest, the only reason that you can currently get away with the FnAdd<T> in current approach 2 is that we are still doing a toy example. Actually add should be able to take just one argument, which it returns directly, and also a whole sequence of arguments, which it adds up and returns the best common type that they can all be added up/converted into. Approach 2 at least has a fighting chance to capture all that, whereas I literally have no idea how you would couch that in approach 4 (although as I said, I am willing to give it a try).
Moreover, current approach 4 with the latest update captures no relationship whatsoever between the input and output types of absquare. It will be just as happy being given an add that takes two strings to a string and an underlying absquare that takes the real type T to a string, and it will give you an absquare that takes a Complex<T> to a string, which is nonsense. And as I said, I just looked at the one example of absquare itself. The typing of the dependencies of sqrt is still wrong. It says absquare takes a Complex<T> to a T, but that isn't right; absquare takes a Complex<Complex<number>> to a number, not to a Complex<number>, and the code won't work if the underlying absolute value is complex, the formulas rely on the absolute value being real.
In other words, the current typing of absquare, with an arbitrary type U in the return position, is just about equivalent to saying that it returns any. We're not getting any additional type safety from it. And pretty much as soon as we make return types be any, then all of the functions will have to take any, and we won't be getting any advantage from TypeScript internally at all, and so we might as well revert to approach 1, a slightly revised version of pocomath. (Which frankly would be just fine with me; I feel like TypeScript is broken in a lot of ways and the pain it is causing us is not worth whatever internal safety it may eventually give us; I am happy to create a system that provides correct, reliable external TypeScript typings for mathjs for others' use, but I am really not interested in coding in TypeScript, I have only learned as much as I have about TypeScript solely for the sake of trying to move the mathjs project forward and get to the point where we can comfortably extend it to bigint, which it sorely needs I think.)
In other words, I think a big part of the reason approach 4 still feels "easy" to you is that now it is not really much constraining the implementations, so we are not really getting much type safety, the TypeScript is mostly just added baggage.

I sense a bit of frustration 😉 . Maybe good to let this rest for the weekend
I know you would be happy with just a JS pocomath implementation.  Because of that, I am surprised that you're trying so hard coming up with a "perfect" TypeScript solution. I have the feeling we're over-engineering this. I would love to see a simple, pragmatic TS solution that handles like 80% of the cases. In the end, the JS pocomath core is what matters, and this will throw a runtime exception when a function signature cannot be resolved. Both for JS functions and functions inferred from TypeScript. All extra type safety we get on top of that is bonus to me. From that point of view, I would already be happy with the "dumb" approach 3, that API is a more verbose than the JS pocomath API, but not that bad in my opinion.

As far as I can see, the only added complexity in approach 2 over 1, 3 or 4 is the intricacy of typing the implementations so TypeScript can deal with them. But that complexity is because getting those typings right is actually hard, as I am hoping you will eventually see in trying to get approach 4 to be both correct and usefully constraining (which it is neither of at this exact moment). It is sufficiently hard that TypeScript wasn't able to do it directly from the implementations themselves (even though all of the information really is there, and TypeScript is a reasonably "mature" language). So we have to spell out how to figure out the return type of an operation from its input types for it manually, and it should be no surprise that for some operations that relationship is intricate, and hence tricky to specify. Let's be clear that for the bulk of "ordinary" operations that take specific concrete types, like 'combinations', the specifications of the type will just be Signature<Params, [number, number], number> for the number implementation and Signature<Params, [bigint, bigint], bigint> for the bigint implementation. The tricky specifications are just for the complicated ones, and also (at least right now) for many generics like lsolve because TypeScript generics can't take generic parameters, so unless a better way of typing is found, lsolve will have to be something like the following, where I am currently assuming we just have a single matrix type that can have any number of dimensions like mathjs does at the moment)
type MatrixAndElement<T> = [Matrix<T>, T]
declare module "./type" {
   interface MatrixReturn<Params> {
    lsolve: Params extends MatrixAndElement<infer T> ? Matrix<T> : never
  }
}

I totally understand and admit that's pretty intricate. I just don't at the moment know how else to capture the relationship between the input parameter types and the output types of a generic function. I mean, it should be something like
[implementation of lsolve goes here, let's say it's the function lsolve_imp for clarity]

declare module "./type" {
   interface MatrixReturn<Params> {
    lsolve: typeof lsolve_imp<infer T> extends ((...args: Params) => any) ? typeof lsolve_imp<T>
   }
}

but TypeScript can't infer in that position, and the current "main" branch in typocomath tried something automatic more or less along those lines and I couldn't get it to work; it was coming up with "unknown" types in places where it really seemed like it should be able to infer a more specific type. I think I tracked it down to places where TypeScript was deliberately punting on type inference by design for "pragmatic" reasons, but maybe I should revisit that scheme and try harder?

I sense a bit of frustration

Absolutely. The frustration is entirely from my inability to communicate to you the real difficulties with something like approach 4. I keep hoping that as you grapple with trying to get approach 4 actually correct, you will reach that aha moment that to get correct typings that neither over or underconstrain the implementation really requires a mechanism at least roughly along the lines of approach 2.  But as I said, I am willing to branch from approach 4 and make a shot at "Suppose we say that for each operation, there is going to be one overarching generic typing that all implementations will have to comply with. Then what could the typing look like?" I remain worried about that typing philosophy as I expressed above, but I am willing to give it a shot. Should I try that?

I would love to see a simple, pragmatic TS solution that handles like 80% of the cases.

I don't think I really know what you mean by that. As soon as you TypeScript type an implementation so that it usefully constrains that implementation, then all of its dependencies have to be typed to that same level of constraint, and all of the implementations that use it have to accept that level of constraint (or else discard the constraints with 'as' typings, but then why in the world use TypeScript if you're going to do that?)  So in the "tree" (it's not quite a tree) of all implementations you need to fully type any connected component.
And if we don't TypeScript type all implementations, then we are back to also needing a pocomath-style signature typing in the names of the implementations we don't TypeScript type, and if we are going to use that, why not just use it everywhere and avoid the trouble of two systems? After all, we could enhance pocomath to have a mode in which types are continuously checked throughout, and use that for unit testing, and just have it compile away in the published bundle to avoid the overhead. That would provide every bit as much type safety internally as using TypeScript -- it would just act as a type-checking processor for our JavaScript code, which is all TypeScript is anyway. So I don't understand what an 80% solution here is. I literally am struggling my absolute hardest to get anything that compiles and correctly and usefully constrains implementations, and so far approach 2 is the only thing I have been able to come up with.

I would already be happy with the "dumb" approach 3, that API is a more verbose than the JS pocomath API, but not that bad in my opinion.

All right, I will be the bluntest yet: I am very happy to

give approach 4 my best shot
try to continue to hone and simplify approach 2
give the predecessor of approach 2 one more try (where the type information would come directly from the implementations)
do a slight revision of pocomath to make the return type specification more "natural" in most cases and go JS-only except for emitting .d.ts files
try to brainstorm an "approach 5" like the name-mangling one I mentioned in a comment way above

but I am not interested in putting in significant hours coding in a scheme where every time you want to have a dependency on  'parse' called on a string and a ParseOptions object, returning a Node, you need to write something like (dep: {parse: (expr: string, options: ParseOptions) => Node}) => ...blah blah... That would feel totally like having made no progress from the redundancy inherent in the current mathjs, and I just won't be able to do it. Really sorry. The exact information you should need to specify is the name of the operation you want to call (parse) and the list of types you want to call it on (string, ParseOptions). I don't care what syntax that's specified in: parse(string, ParseOptions) in a object key, or Dependency<parse, [string, ParseOptions]>, or ParseImp<string, ParseOptions> or parse_string_ParseOptions_type etc. etc. But specifying the whole function type over and over again redundantly in a way that has to be consistent in every copy is unfortunately unacceptable to me as a place I am going to devote the kind of time I have been investing into mathjs. (Note this doesn't mean you shouldn't adopt such a scheme if in the end that's the way you think mathjs needs to go; I can of course move on to other projects/options, and you need to judge what's the best for your package.)
Thanks for understanding.

@gwhitney I'm still thinking about whether we can come up with an approach5.
The complexity of approach2 comes from automatically inferring the return type. Suppose that we would be willing to enter the return type too in the dependency, then the solution can be as follows (without need for declare module sections):
export type Implementation<
    Name extends string,
    Params extends unknown[],
    Return extends unknown
> = (...args: Params) => Return

export type Dependency<
    Name extends string,
    Params extends unknown[],
    Return extends unknown
> = {
    [N in Name]: (...args: Params) => Return
}

export const sqrt =
   (dep: configDependency
     & Dependency<'complex', [number, number], Complex<number>>
   ): Implementation<'sqrt', [number, number], Complex<number> | number> => {
      if (dep.config.predictable || !dep.complex) return conservativeSqrt
      return a => {
         if (isNaN(a)) return NaN
         if (a >= 0) return Math.sqrt(a)
         return dep.complex(0, Math.sqrt(unaryMinus(a)))
      }
   }

export const multiply =
   <T>(dep: Dependency<'add', [T, T], T>
       & Dependency<'multiply', [T, T], T>
       & Dependency<'subtract', [T, T], T>
       & Dependency<'conj', [T], T>
   ) : Implementation<'multiply', [Complex<T>, Complex<T>], Complex<T>> =>
      (w, z) => {
         const mult = dep.multiply
         const realpart = dep.subtract(mult(w.re, z.re), mult(dep.conj(w.im), z.im))
         const imagpart = dep.add(mult(dep.conj(w.re), z.im), mult(w.im, z.re))
         return complex_binary(realpart, imagpart)
      }

Would that be worth thinking through in more detail?

thanks for continuing to try to brainstorm! Not sure why we are discussing the current state here, though. I just opened https://code.studioinfinity.org/glen/typocomath/issues/6 with how I see the status of things, including a new possibility I would like to raise.


Not Implemented - Error

See error below:
https://imgur.com/a/p8g7X9P
Using the latest version of Visual Studio 2017 Pro. It's a .Net / C# project. The path looks like this:
...\ProjectName\ProjectName\ProjectName.csproj (trying to rename this one)
...\ProjectName\ProjectName.Integration\ProjectName.Integration.csproj (integration tests project)
...\ProjectName\ProjectName.Unit\ProjectName.Unit.csproj (unit tests project)
I guess the problem could be that there is a folder above with the same name?

@kuanysh-nabiyev
The solution has 100+ projects. But that was never a problem before, when I recall correctly.

@MPasadu the exception was thrown in VSIX API. I have one above assumption of the exception, because one of the users had the same exception as I remember. His solution had SSIS project. Please, check if there is(are) such projects in your solution

No, but there are also WiX setup projects in the solution (these are unloaded though)

@MPasadu try to install the following version of the extension. I hope it helps
https://expirebox.com/download/49684fcf9b5a31d12ed8061e9ece0cd7.html


Title: Screenshot Generator

Describe the project
I would like to build a Screenshot Generator using an API. This project will generate a screenshot of the provided website URL and it can be downloaded as well. And I would like to make a documenation for this project.
Issue Type:

[X] Documentation
[X] New Project

@Vanshiii203 Please check this issue.


Remove self from closures in dask.dataframe

Previously the dataframe object contained tasks that closed over the
dataframe itself.  This made certain tasks very costly to serialize.

Hi,  just dropping a note here since I was the one who replaced dill with cloudpickle.   In multiprocessing.py,  I take care of some of the issues with serialization of standard library objects by defining the functions _loads and _dumps as follows:
from sys import version

if version < '3':
    import copy_reg as copyreg
else:
    import copyreg

def _reduce_method_descriptor(m):
    return getattr, (m.__objclass__, m.__name__)

# type(set.union) is used as a proxy to <class 'method_descriptor'>
copyreg.pickle(type(set.union), _reduce_method_descriptor)

import pickle
import cloudpickle

def _dumps(x):
    return cloudpickle.dumps(x, protocol=pickle.HIGHEST_PROTOCOL)

_loads = pickle.loads

With those definitions,  then serialization works for methodcaller:
In [10]: from operator import methodcaller

In [11]: f = methodcaller('sum')

In [12]: import numpy as np

In [13]: x = np.ones((2,2))

In [14]: f(x)
Out[14]: 4.0

In [15]: _loads(_dumps(f))(x)
Out[15]: 4.0

Hi @PedroMDuarte I wish you had brought that up earlier.  I repeated this work almost exactly in cloudpickle a little while ago.  https://github.com/cloudpipe/cloudpickle/commit/ce99eee4bf159985018bdf50ab363408e74ac07c
If you're interested, that project could use contributors like yourself.  There are a lot of people now depending on it and only a few people adding fixes like this from time to time.

@mrocklin That is cool!  I am by no means an expert in serialization, but I will look into helping out with cloudpickle.   I found the solution to this issue in the standard library itself, under multiprocessing/forking.py.   It was hard to find though!

Merging soon if no additional comments.


Enhance resource configuration service

Enhance resource configuration service

Ability to update resource scoped value
A change event that is resource and lang aware

Added following:
updateValue
https://github.com/microsoft/vscode/blob/6d6461718e54434a31c68b1d46f2e9612a7ef6cf/src/vs/editor/common/services/resourceConfiguration.ts#L48-L60
IResourceConfigurationChangeEvent
https://github.com/microsoft/vscode/blob/6d6461718e54434a31c68b1d46f2e9612a7ef6cf/src/vs/editor/common/services/resourceConfiguration.ts#L14-L30
@jrieken FYI


BUG: EdgeTerminal.product_solver_names(database.ProductIdType.HFSS_3D_LAYOUT) failing

🔍 Before submitting the issue

[X] I have searched among the existing issues
[X] I am using a Python virtual environment

🐞 Description of the bug

📝 Steps to reproduce
NA
💻 Which operating system are you using?
Windows
📀 Which ANSYS version are you using?
No response
🐍 Which Python version are you using?
3.10
📦 Installed packages
NA

missing conversion from enum to underlying int


gh-394: Save Theme images in the database

This is the backend work required to allow Theme Images to be uploaded. Resolves gh-394.

Thanks for this @NigelPalmer, looks good! As there's quite a few changes I'm still having a look but have an additional comment:

When I tried to upload an SVG image through the API property endpoint, it stored it fine, but when I tried to retrieve it, the content-type header was wrong which meant the browser couldn't display it. I think it should be possibly to allow SVGs by adding to getContentType in CatalogueFile.groovy.


kvmfr: Update kvmfr 6 10 [Issue 328643]

Description of changes
Resolves Issue 328643 with cherry picked patch from LookingGlass
https://github.com/gnif/LookingGlass/commit/7305ce36af211220419eeab302ff28793d515df2
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Duplicate of https://github.com/NixOS/nixpkgs/pull/331206


Assumes Julia is installed

The registry update step assumes julia is installed and fails the job if it's not.
cc. @giordano

Weirdly it seems that macOS GitHub runners don't seem to have julia pre-installed but others do, as expected.
But either way we shouldn't fail because self hosted runners might not also.

Example: https://github.com/JuliaMath/QuadGK.jl/actions/runs/10640418662/job/29500338448
Registries directory exists and is non-empty. Updating any registries
/Users/runner/work/_temp/76e2caee-c42d-4eab-a2b1-ac350daddc95.sh: line 3: julia: command not found
Error: Process completed with exit code 127.


Cannot build iOs package with error "Using bridging headers with module interfaces is unsupported"

Plugin Version
2.2.0
Steps to Reproduce

Upgrade the package to 2.2.0 in pubspec.yaml
Run flutter pub get
Run flutter build ipa on macOS

Expected results: Can build iOS package normally
Actual results: build commande exit with this error:
...
 While building module 'GoogleMobileAds' imported from /opt/homebrew/Caskroom/flutter/2.5.3/flutter/.pub-cache/hosted/pub.dartlang.org/google_mobile_ads-2.2.0/ios/Classes/FLTMobileAds_Internal.h:15:
Swift Compiler Error (Xcode): Using bridging headers with module interfaces is unsupported
...

[✓] Flutter (Channel stable, 3.3.6, on macOS 12.6 21G115 darwin-arm, locale en)
    • Flutter version 3.3.6 on channel stable at /opt/homebrew/Caskroom/flutter/2.5.3/flutter
    • Upstream repository git@github.com:flutter/flutter.git
    • Framework revision 6928314d50 (6 days ago), 2022-10-25 16:34:41 -0400
    • Engine revision 3ad69d7be3
    • Dart version 2.18.2
    • DevTools version 2.15.0

[✓] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
    • Android SDK at /Users/username/Library/Android/sdk
    • Platform android-33, build-tools 31.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.13+0-b1751.21-8125866)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 14.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 14A400
    • CocoaPods version 1.11.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2021.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.13+0-b1751.21-8125866)

[✓] VS Code (version 1.72.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.50.0

[✓] Connected device (3 available)
    • iPhone 5s (mobile) • B5B1BD16-7665-4725-BF78-C25BA5D36083 • ios            • com.apple.CoreSimulator.SimRuntime.iOS-12-4
      (simulator)
    • macOS (desktop)    • macos                                • darwin-arm64   • macOS 12.6 21G115 darwin-arm
    • Chrome (web)       • chrome                               • web-javascript • Google Chrome 107.0.5304.87

[✓] HTTP Host Availability
    • All required HTTP hosts are available

• No issues found!

Hi @minhdanh Please check this StackOverflow answer if it can help: https://stackoverflow.com/a/60658142/5921933

Hi @huycozy, yeah I found that answer but could not follow it. There was no such settings (Build Libraries for Distribution) in my project.

@huycozy my bad, I checked the answer above again and can confirm the solution worked for me. Thank you!


[Feature Request] Update Issue Template

Does your feature request address a specific issue? Please elaborate.
Update Issue Template to account for Subcategories (Implementations)
Outline your desired solution
Updated Issue Template
Discuss any alternative solutions or features you've considered.
No response
Additional information.
No response

@rpsene -

Merge Design Tools and Compilers to "Design Tools + Compilers" (match Landscape)
Update Developer Boards to match a category on the Landscape (or remove)
Update Processors to read Chips + Processors (match Landscape)
Remove Implementations > Other from Sub-Category

@rpsene - looks like these updates to the New Issue form are outstanding. Thanks!


Data deletion sometimes fails and there is no easy way to retry

In our testing, data deletions always worked, but in every production install I've upgraded, data deletion has failed and I have no idea why. It'd be nice to have a force that runs https://github.com/getodk/central/blob/master/files/postgres/upgrade-postgres.sh#L42.
root@ip-xx-xx-xx-xx:~/central# docker compose up postgres
[+] Running 1/1
 ⠿ Container central-postgres-1  Recreated                                                                                0.1s
Attaching to central-postgres-1
central-postgres-1  | Tue 16 May 2023 08:32:00 PM GMT [upgrade-postgres.sh] Checking for existing upgrade marker file...
central-postgres-1  | Tue 16 May 2023 08:32:00 PM GMT [upgrade-postgres.sh] Upgrade has been run previously.
central-postgres-1  | Tue 16 May 2023 08:32:00 PM GMT [upgrade-postgres.sh] !!!
central-postgres-1  | Tue 16 May 2023 08:32:00 PM GMT [upgrade-postgres.sh] !!! WARNING: you still have old data from PostgreSQL 9.6
central-postgres-1  | Tue 16 May 2023 08:32:00 PM GMT [upgrade-postgres.sh] !!!
central-postgres-1  | Tue 16 May 2023 08:32:00 PM GMT [upgrade-postgres.sh] !!! This is taking up disk space: 311MB
central-postgres-1  | Tue 16 May 2023 08:32:00 PM GMT [upgrade-postgres.sh] !!!
central-postgres-1  | Tue 16 May 2023 08:32:00 PM GMT [upgrade-postgres.sh] !!! Continue with the instructions at https://docs.getodk.org/central-upgrade/
central-postgres-1  | Tue 16 May 2023 08:32:00 PM GMT [upgrade-postgres.sh] !!!
central-postgres-1  | Tue 16 May 2023 08:32:00 PM GMT [upgrade-postgres.sh] Complete.
central-postgres-1 exited with code 0

root@ip-172-31-18-74:~/central# touch ./files/postgres14/upgrade/delete-old-data \
   && docker compose up --abort-on-container-exit postgres
[+] Running 1/1
 ⠿ Container central-postgres-1  Recreated                                                                                0.1s
Attaching to central-postgres-1
central-postgres-1  | Tue 16 May 2023 08:32:08 PM GMT [upgrade-postgres.sh] Checking for existing upgrade marker file...
central-postgres-1  | Tue 16 May 2023 08:32:08 PM GMT [upgrade-postgres.sh] Upgrade has been run previously.
central-postgres-1  | Tue 16 May 2023 08:32:08 PM GMT [upgrade-postgres.sh] Deleting old data...
central-postgres-1  | Tue 16 May 2023 08:32:08 PM GMT [upgrade-postgres.sh] !!!
central-postgres-1  | Tue 16 May 2023 08:32:08 PM GMT [upgrade-postgres.sh] !!! ERROR: file missing: delete_old_cluster.sh
central-postgres-1  | Tue 16 May 2023 08:32:08 PM GMT [upgrade-postgres.sh] !!!
central-postgres-1  | Tue 16 May 2023 08:32:08 PM GMT [upgrade-postgres.sh] !!! Upgrade may not have completed successfully.
central-postgres-1  | Tue 16 May 2023 08:32:08 PM GMT [upgrade-postgres.sh] !!!
central-postgres-1  | Tue 16 May 2023 08:32:08 PM GMT [upgrade-postgres.sh] !!! Old data will not be deleted.
central-postgres-1  | Tue 16 May 2023 08:32:08 PM GMT [upgrade-postgres.sh] !!!
central-postgres-1 exited with code 1
Aborting on container exit...
[+] Running 1/0
 ⠿ Container central-postgres-1  Stopped

In this case, I can log into Central fine, I can also run docker exec -it central-postgres14-1 psql -U odk -W odk -c "select version();" to confirm I'm running 14.7.
The logs from a Central migration that where delete worked looks ends like this:
Tue 16 May 2023 08:27:38 PM GMT [upgrade-postgres.sh] Upgrade complete.
Tue 16 May 2023 08:27:38 PM GMT [upgrade-postgres.sh] Complete.

The logs where the delete failed looks like  this:
Sat 25 Mar 2023 05:28:40 AM GMT [upgrade-postgres.sh] Upgrade complete.

It seems like maybe delete_old_cluster.sh is somehow not available? And maybe it doesn't matter? Rather than check delete_old_cluster.sh, maybe if /postgres14-upgrade/upgrade-successful exists, we do the delete.
https://github.com/tianon/docker-postgres-upgrade/issues/11#issuecomment-445133700 seems to suggest that the delete_old_cluster.sh is created in a work directory in the container which is not persisted and might go away.
It seems like the best solution is to check to see if the upgrade has completed and delete the data then.

Closed by #431.


Fixed typo of links

Fixed two typos of links and one extra space.

@daviddwlee84 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Hi @daviddwlee84 - Would you take a moment to sign the Contributor License Agreement (CLA)? Then, we can merge the PR. Thanks!
@cynthn This PR fixes broken links in your article. It's ready to merge after the CLA is signed.

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@daviddwlee84 Thanks! We'll merge the PR.


Not able to get datarow value in TestContext

Description

Describe the issue you've observed
I am trying to get the datarow values from TestContext.DataRow[0] but DataRow is always coming as NULL.

Steps to reproduce

What steps can reproduce the defect?
Please share the setup, sample project, target platform (desktop, core, up)
[TestClass]
public class TestFrameworkTest
{

	static TestContext TestContext;

	[ClassInitialize]
	public static void OneTimeSetUp(TestContext testContext) {
		TestContext = testContext;
	}

	[DataTestMethod]
	[DataRow(1, 2, 3)]
	[DataRow(2, 2, 4)]
	[DataRow(3, 2, 5)]
	[DataRow(5, 2, 7)]
	public void RowTest(int a, int b, int result)
	{
		if (TestContext.DataRow[0] != null){ }

		Assert.AreEqual(result, a + b);
	}
}

Expected behavior

Share the expected output
TestContext.DataRow is not null

Actual behavior

What is the behavior observed?
TestContext.DataRow is Always null

Environment

Please share additional details about the test environment.
Operating system, Build version of vstest.console, Package version of MSTest
framework and adapter

@ylnkancheti : What you are observing is expected. I believe there is some confusion in TestContext.DataRow object and [DataRow] attribute.
TestContext.DataRow is used to consume test data when data is provided using [DataSource] attribute. However, when you provide inline data by using [DataRow] attribute, then you should use the TestMethod parameters to access test data(i.e. variables a, b, result in your case).
Adapter will not populate TestContext.DataRow object in case of [DataRow] attribute and the data should only be consumed from TestMethod parameters only.

@jayaranigarg Got it. Thanks

@ylnkancheti : What you are observing is expected....
...Adapter will not populate TestContext.DataRow object in case of [DataRow] attribute and the data should only be consumed from TestMethod parameters only.

@jayaranigarg isn't that extremely unintuitive though? Wouldn't it make sense to always populate the DataRow property whenever data is available, no matter from where?
I think this might be an outdated discussion since I can't even find the DataRow property on TestContext anymore (let me know if I'm missing something there), but it doesn't hurt to ask.

@jayaranigarg, this should not be expected behavior. In my case, the test setup is dependent on the parameter values and there is absolutely no way to access them if they are not available in TestContext.
PS: I'm using MSTest v1.4.0.

@zendu : In case of testmethods having datarow, testmethods has to take method parameters and you should use those method parameters to access datarow values and should not depend on testcontext.

Test method uses parameters but what about test setup method?

@zendu : Can you please your scenario(maybe a code snippet explaining your expectation)? Which values is your test setup method dependent on? DataRow values are specific to your test methods and not make much sense in case of test setup/clean up as such.

I have several entities saved as JSON files. Test case is executed for each entity. Test setup needs to initialize another object using the entity.
[TestSetup]
public void Setup(){
    var entityFileName = this.TestContext.DataRow["fileName"];
    var entity = JsonDeserialize($"TestData\{entityFileName}");
    ...
}

@zendu : Can you please share a repro project with us?
How does your test method look like? How are you passing DataRow values to the testMethod? It would help if you can share snippet for that as well.

@zendu Afaik mstest does not have a [TestSetup] attribute. May i know what test framework you are using?

@ylnkancheti
	static TestContext TestContext;

	[ClassInitialize]
	public static void OneTimeSetUp(TestContext testContext) {
		TestContext = testContext;
	}

	[DataTestMethod]
	[DataRow(1, 2, 3)]
	[DataRow(2, 2, 4)]
	[DataRow(3, 2, 5)]
	[DataRow(5, 2, 7)]
	public void RowTest(int a, int b, int result)
	{
		Assert.AreEqual(result, a + b);
	}
}

This would be your code snippet to achieve the same thing. Since an int can't be null. The adapter would throw much earlier if you passed a data row similar to
[DataRow(null, 2, 3)]
Let's say the first param was an object then
	static TestContext TestContext;

	[ClassInitialize]
	public static void OneTimeSetUp(TestContext testContext) {
		TestContext = testContext;
	}

	[DataTestMethod]
	[DataRow(null, 2, 3)]
	public void RowTest(obj a, int b, int result)
	{
		if (a != null){ }

		Assert.AreEqual(result, b);
	}
}

you can do the above. The TestContext.DataRow is reserved for something else entirely and not for basic Data driven tests such as the one you are authoring.

@zendu @ylnkancheti any updates here?

Closing due to no response. Please reopen a new issue if your problem still persists. Locking the conversation here as the issue has started branch out into more than one query.


/edit-chants/{id} leads to 404 when source has no chants

A source created that has as of yet no chants has a 404 error when attempting to reach /edit-chants/{source_id}.
This url can be accessed by clicking the "Edit chants (Fulltext & Volpiano Editor)" link on the home page or the source page.
NewCantus:

OldCantus (accessed at /edit-volpiano/{source_id}:

To fix this, we need to do two things (or maybe just one of them):

Make sure this link is not displayed when there are no chants to edit (I thought we already fixed this? we should check again)
make sure that this page can load even if there are no chants (and if we implement this, maybe we don't need to do the first of these. Even better, we should check what OldCantus does in terms of displaying links, and then copy that)

NewCantus does seem to display the link, as @dchiller noted, on the my sources page; this is in parallel with what OldCantus does, where the "Fulltext and Volpiano editor" option always displays, even for empty sources.
(I don't mind the idea of not having it show for empty things, if that is easier to implement than loading the page--there's nothing you can do in the full-text editor if there are no chants. But OldCantus does let you go look at the form, as in the screenshot above.)

The fastest way to fix this, I think, will be to hide links to the page.
The more robust fix will be to have the page be able to load even if it doesn't have chants, and hide links to the page. This will account for situations where people have bookmarked Edit Chants pages, as well as for the end of the chant-delete process (otherwise, it's not clear where we should redirect users afterwards - maybe to the source detail page?), as well as any links we may have somehow missed.

The more robust fix will be to have the page be able to load even if it doesn't have chants, and hide links to the page. This will account for situations where people have bookmarked Edit Chants pages, as well as for the end of the chant-delete process (otherwise, it's not clear where we should redirect users afterwards - maybe to the source detail page?), as well as any links we may have somehow missed.

Talking through this a bit more with @lucasmarchd01, we've had some thoughts. From a user-experience point of view, instead of sometimes hiding edit-chants links (in the situation where the source has no chants), it would probably be best to always show these links, and when the user tries to visit the page, display a message explaining that there are no chants available to edit, and give them a link to create a new chant.

This way, no user is confused when they can't find an edit-chants link where they expect to find one.
It would also more closely match where/how these links are currently displayed on OldCantus

I'm not 100% certain this is the best approach - we should probably check in with Debra about what she'd prefer. In any case, this is low-priority for the time being.


Create filter search component

Do all work for this task in a branch called issue-22

Filter by Name
Filter by Subject
Filter by title


Stringify all the things!

Change all char lists to strings.

Hrm, Travis CI failed. Looking into it now.

Thanks for the PR! Looks like the specs are failing because of a couple of things:

I added a build matrix on Travis to check for compatibility across various versions
In order for the hex package to work out of the box I committed the generated *.erl files from the lexer and parser. This probably isn't a good idea as it may be generated with a different version of OTP than the user is on.

See https://github.com/philss/floki/pull/26 and https://github.com/philss/floki/issues/24

Added issues #12 and #11

Have merged https://github.com/joshprice/graphql-elixir/pull/13 can you please rebase?

Closing in favour of the rebased and passing #14

Sorry, I didn't see your comments until just now. Looks like you sorted it all out :+1:

No worrries, figured you were offline and was keen to see whether I'd solved the problem. All good!


Fix double padding on camera when setting bounds

This fixes a configuration like
// Map height: 800
setCamera({
  bounds: ...,
  padding: {
    paddingTop: 0,
    paddingBottom: 400,
  },
})

producing the warning

Unable to calculate camera for given bounds/geometry, padding is greater than map's width or height

due to the center and zoom already including the calculated padding, and then the padding being reapplied in the camera configuration.
I believe this has always been an issue, but it's become problematic in Mapbox 11, as the internal camera now fails to move if total padding exceeds the map size.
I also went ahead and added a condition that scales down the padding so it doesn't ever exceed the map size. What do you think about this? My thinking is: when working with the native Mapbox SDK, you can easily check e.g:
if padding.top + padding.bottom >= map.bounds.height { ... }

but it's not as easy in JavaScript to get the current map height, so that kind of check is more brittle.
Ideally, this sort of overflow would be compensated for in the Mapbox SDK, but I'm not sure if I would consider it a bug vs. just a design choice I don't like. :)

@mfazekas I left a couple of comments on the code.
On another note, there's some idiosyncratic behavior depending on the combination of padding and min/max zoom limits. This exists in the native SDK, so it's probably not something we need to deal with here, but I wanted to check.
Basically, with no minZoomLevel defined, increasing the padding can result in a massive zoom out, as the bounding box gets "squished" to a single point. But with minZoomLevel set, it becomes possible to increase the padding such that the bounds move completely offscreen. I think a reasonable expectation would be for the map to always show the provided bounds, scaling down padding if needed. This seems like a bug, but I'm not actually sure it would be considered one.
The video should help clarify. Thoughts?
https://github.com/rnmapbox/maps/assets/2423291/1868a97a-b3c0-4be2-b6fe-5592a828202a

@naftalibeder  ci needs a fix here

@naftalibeder pls merge the PR as CI was broken on main

CI error:
| Error: src/examples/V10/CameraAnimation.tsx(1,43): error TS6133: 'color' is declared but its value is never read.


Unable to open project in multiple windows

Does this issue occur when all extensions are disabled?: Yes

Version: 1.63.2 (user setup)
Commit: 899d46d82c4c95423fb7e10e68eba52050e30ba3
Date: 2021-12-15T09:40:02.816Z
Electron: 13.5.2
Chromium: 91.0.4472.164
Node.js: 14.16.0
V8: 9.1.269.39-electron.0
OS: Windows_NT x64 10.0.19044
Steps to Reproduce:

Open a Visual Studio Code extension project.
Start the extension host, resulting in a second Visual Studio Code window.
Try to open your extension project in the second Visual Studio Code window. (File → Open recent, File → Open folder)

When I attempt this, apparently nothing happens or the initial Code window receives focus.
I see #2686 has long been shut down So I must be missing something.

Duplicate of https://github.com/microsoft/vscode/issues/2686, which is still open.


Chartjs 1 - NEVER MERGE, keep opened, keep synced

This is placeholder for https://github.com/jenkinsci/report-jtreg-plugin/commit/953ad9baedb7bedf43f9e15e5e6a4ec1b3971003
Never merge to master, keep synced from master, and see redme:https://github.com/jenkinsci/report-jtreg-plugin/blob/chartjs-1/README.md

surpassed by https://github.com/jenkinsci/report-jtreg-plugin/pull/3
thsi oen will be closed


[,LEAKED-Videos,] Sophie Rain Spiderman Xx Xxx Sex Videos and xxx Porn News

[,SEX-Videos,] Sophie Rain Spiderman Xx Xxx Sex Videos and xxx Porn News
Where Can I Watch New Latest Viral Leaked Video Discover videos related to Where Can I Watch New Latest Viral Leaked Video on TikTok. WATCH HERE!  New Latest Viral Leaked, a young and talented digital creator, recently became famous thanks to this interesting video.
New Latest Viral Leaked video instagram New Latest Viral Leaked video oficial twitter
Tutorial on How to Watch The New Latest Viral Leaked Video related to Tutorial on How to Watch The New Latest Viral Leaked Video on TikTok. See more videos about How to Watch New Latest Viral Leaked VIRAL Video.
New Latest Viral Leaked Hot Pictures: 5 Times ‘VIRAL Video Tutorial Fame’ Girl Raised Temperatures and Sent Hearts Racing in Sexy and Sizzling Outfits
New Latest Viral Leaked, rose to prominence after a controversial video featuring the model in it, was leaked online. Though she received backlash for the video, and rules Instagram with hot and sexy photos in sizzling outfits. View New Latest Viral Leaked’s hot pictures below.
Trending!!! New Latest Viral Leaked MMS VIRAL Hot heck out 's official video ! Dive into the action and excitement with her latest thrilling adventure. Don't miss out on this exclusive.
New Latest Viral LeakedFull Official Video Leaks on  is a creative young digital artist widely known for her amazing Spider-Man videos. Initially shared on TikTok, the video quickly
New Latest Viral Leaked, rose to prominence after a controversial video featuring the model in it, was leaked online. Though she received backlash for the video, and rules Instagram with hot and sexy photos in sizzling outfits. View New Latest Viral Leaked’s hot pictures below.
Trending!!! New Latest Viral Leaked MMS VIRAL Hot heck out 's official video ! Dive into the action and excitement with her latest thrilling adventure. Don't miss out on this exclusive.
New Latest Viral LeakedFull Official Video Leaks on is a creative young digital artist widely known for her amazing Spider-Man videos. Initially shared on TikTok, the video quickly
SEX video Leaked!!)**


fix incorrect gpu parameter handling in pipeline parser

What changes were proposed in this pull request?

How was this pull request tested?

Developer's Certificate of Origin 1.1
   By making a contribution to this project, I certify that:

   (a) The contribution was created in whole or in part by me and I
       have the right to submit it under the Apache License 2.0; or

   (b) The contribution is based upon previous work that, to the best
       of my knowledge, is covered under an appropriate open source
       license and I have the right under that license to submit that
       work with modifications, whether created in whole or in part
       by me, under the same open source license (unless I am
       permitted to submit under a different license), as indicated
       in the file; or

   (c) The contribution was provided directly to me by some other
       person who certified (a), (b) or (c) and I have not modified
       it.

   (d) I understand and agree that this project and the contribution
       are public and that a record of the contribution (including all
       personal information I submit with it, including my sign-off) is
       maintained indefinitely and may be redistributed consistent with
       this project or the open source license(s) involved.

/kind bug

@wenjun93 How about CPU, should we leave it as request_cpu? or should we use cpu_limit (see docs)

@lresende gpu limit is mandatory, while cpu_limit is optional. BTW I agress we should expose cpu/mem requests options to front end.


Documentation should illuminate the drop-in capability of this over webpack-dev-server

Operating System: n/a
Node Version: n/a
NPM Version: n/a
webpack Version: n/a
webpack-serve Version: n/a

This issue is for a:

[ ] bug
[ ] feature request
[x] modification request

Expected Behavior
Decided to give webpack-serve a try over webpack-dev-server due to an oustanding bug with Webpack4 and noticed that webpack-serve can be used as a pure drop-in replacement within my current configuration (which uses webpack config's devServer option to handle some configuration).
Searched all through the README to see if this was possible and there was no mention.
Actual Behavior
I think it's very well worth noting that the minimum required setup to migrate from webpack-dev-server to webpack-serve is to simply replace the reference from one to the other in your npm scripts that use it.
If this is inaccurate for some reason or another, I believe the README should try to elaborate on any relevant steps one might need to follow to migrate, though from my experience this was not the case.
With that said, well done on creating a seamless migration experience (at least for me)! Thanks!

Thanks for the issue :beer: and the kinds words.
It's rad that you're digging the module, but I'm not sure that it's doing what you think it is. webpack-serve doesn't support nor look for the devServer option and uses the serve option property instead (or a host of other configuration location options). If you're positive that your scripts are running webpack-serve, then it's likely running with the default configuration, which is rather opinionated.

Ah -- interesting. Yep, everything seemed to be working as expected. I was fooled!
Tested out historyApiFallback and can confirm devServer is not the config being read.
Is there an equivalent to that with the serve option?

Yessir, check out the Add-ons section of the README.


Would be nice to provide Basic NLU data in other languages too

What about other languages?

Thanks for the issue, @rgstephens will get back to you about it soon!
You may find help in the docs and the forum, too 🤗

@EmmaWightman what do you think?


Error running create-proton-app on<EMAIL_ADDRESS>

create-proton-app fails in NodeJS version 11.9.0 but runs successfully in version 8.11.4
The end of a VERY verbose stack-trace:
In file included from ../src/EventLoop.cc:1:
In file included from /Users/tmorrow/repo/proton-native/node_modules/libui-node/src/includes/event-loop.h:6:
In file included from ../../nbind/include/nbind/nbind.h:8:
In file included from ../../nbind/include/nbind/noconflict.h:8:
In file included from ../../nbind/include/nbind/BindDefiner.h:24:
../../nbind/include/nbind/v8/Int64.h:151:35
: warning: 'Uint32Value' is deprecated: Use maybe version [-Wdeprecated-declarations]
                if(argc > 0) storage = args[0]->Uint32Value();
                                                ^
../../nbind/include/nbind/v8/Int64.h:193:58: note: in instantiation of function template specialization 'nbind::Int64Converter<8>::int64Init<long long>' requested here
DEFINE_INT64_BINDING_TYPE(signed long long, int64ToWire, int64Init);
                                                         ^

/Users/tmorrow/.node-gyp/11.9.0/include/node/v8.h:2571:3: note: 'Uint32Value' has been explicitly marked deprecated here
  V8_DEPRECATED("Use maybe version", uint32_t Uint32Value() const);
  ^
/Users/tmorrow/.node-gyp/11.9.0/include/node/v8config.h:326:29: note:
expanded from macro 'V8_DEPRECATED'
  declarator __attribute__((deprecated(message)))
                            ^
In file included from
../src/EventLoop.cc:1:
In file included from /Users/tmorrow/repo/proton-native/node_modules/libui-node/src/includes/event-loop.h:6:
In file included from ../../nbind/include/nbind/nbind.h:8:
In file included from ../../nbind/include/nbind/noconflict.h:8:
In file included from ../../nbind/include/nbind/BindDefiner.h:24:
../../nbind/include/nbind/v8/Int64.h:152:58: warning: 'Uint32Value' is deprecated: Use maybe version [-Wdeprecated-declarations]

                if(argc > 1) storage += static_cast<uint64_t>(args[1]->Uint32Value()) << 32;
                                                                       ^
/Users/tmorrow/.node-gyp/11.9.0/include/node/v8.h:2571:3: note:
'Uint32Value' has been explicitly marked deprecated here
  V8_DEPRECATED("Use maybe version", uint32_t Uint32Value() const);
  ^
/Users/tmorrow/.node-gyp/11.9.0/include/node/v8config.h:326:29: note: expanded from macro 'V8_DEPRECATED'

Have you tried cding into the directory and do npm i? I use node 11 and create-proton-app failes, but doing npm i successfully creates the project
나의 iPhone에서 보냄

오전 9:06, Lacy Morrow<EMAIL_ADDRESS>작성:

create-proton-app fails in NodeJS version 11.9.0 but runs successfully in version 8.11.4
The end of a VERY verbose stack-trace:
In file included from ../src/EventLoop.cc:1:
In file included from /Users/tmorrow/repo/proton-native/node_modules/libui-node/src/includes/event-loop.h:6:
In file included from ../../nbind/include/nbind/nbind.h:8:
In file included from ../../nbind/include/nbind/noconflict.h:8:
In file included from ../../nbind/include/nbind/BindDefiner.h:24:
../../nbind/include/nbind/v8/Int64.h:151:35
: warning: 'Uint32Value' is deprecated: Use maybe version [-Wdeprecated-declarations]
if(argc > 0) storage = args[0]->Uint32Value();
^
../../nbind/include/nbind/v8/Int64.h:193:58: note: in instantiation of function template specialization 'nbind::Int64Converter<8>::int64Init' requested here
DEFINE_INT64_BINDING_TYPE(signed long long, int64ToWire, int64Init);
^
/Users/tmorrow/.node-gyp/11.9.0/include/node/v8.h:2571:3: note: 'Uint32Value' has been explicitly marked deprecated here
V8_DEPRECATED("Use maybe version", uint32_t Uint32Value() const);
^
/Users/tmorrow/.node-gyp/11.9.0/include/node/v8config.h:326:29: note:
expanded from macro 'V8_DEPRECATED'
declarator attribute((deprecated(message)))
^
In file included from
../src/EventLoop.cc:1:
In file included from /Users/tmorrow/repo/proton-native/node_modules/libui-node/src/includes/event-loop.h:6:
In file included from ../../nbind/include/nbind/nbind.h:8:
In file included from ../../nbind/include/nbind/noconflict.h:8:
In file included from ../../nbind/include/nbind/BindDefiner.h:24:
../../nbind/include/nbind/v8/Int64.h:152:58: warning: 'Uint32Value' is deprecated: Use maybe version [-Wdeprecated-declarations]
            if(argc > 1) storage += static_cast<uint64_t>(args[1]->Uint32Value()) << 32;
                                                                   ^

/Users/tmorrow/.node-gyp/11.9.0/include/node/v8.h:2571:3: note:
'Uint32Value' has been explicitly marked deprecated here
V8_DEPRECATED("Use maybe version", uint32_t Uint32Value() const);
^
/Users/tmorrow/.node-gyp/11.9.0/include/node/v8config.h:326:29: note: expanded from macro 'V8_DEPRECATED'
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


Update texture for G3, FN FAL and Makarov

📝 Description
In this PR it only rescues the texture improvements for some weapons, in this PR not a single FACTORY file is modified.
NOTE: in this PR no factory files will be modified until the head developers give permission
modifies textures like:

FN FAL texture by Vic4Games(not require modifying the factory)
G3 texture by Braiam23(not require modifying the factory)
MakarovPM and PB texture by Vic4Games(required modifying some files)

🎯 Goals

Texture update for FN FAL by Vic4Games (no factory modification required)

Texture update for G3 by Braiam23 (no factory modification required)

Texture update for MakarovPM and PB by Vic4Games (required modifying some files)

❌ Non Goals

Do not break the mod

🚦 Testing
For weapons like the G3 and FN FAL it is not necessary to modify models, but for the MakarovPM(PB) pistol it was necessary to modify the models so that the textures load correctly
⏮ Backwards Compatibility
1.12.2
📚 Related Issues & Documents
nothing
🖼 Screenshots/Recordings

📖 Added to documentation?

[ ] 📜 README.md
[ ] 📑 Documentation
[ ] 📓 Javadoc
[ ] 🍕 Comments
[X] 🙅 No documentation needed

@Desoroxxx To prevent conflicts, merge it after 450

Will go back to this after the thing


How i access my docs as superuser???

I am running the system but when i go to /docs and i need to try the endpoints i need to add O2auth it's written:
Token URL: please login by supabase-js to get token
how i do that? if i uncomment the lines:
await super_client.auth.sign_in_with_password(
    {"email": settings.SUPERUSER_EMAIL, "password": settings.SUPERUSER_PASSWORD}
    )

i got error await can't be used with None Type

did you mean that do not understand how to test endpoint with \doc manually?

token are captured by endpoint dependency automatically

what's kind of token did you use?

more code examples or your repo?

the token which captured by dependency is the user's access_token, so i thinks we can test it in docs after sign in manually with super_client.auth.sign_in_with_password

response = await db_client.auth.sign_up(
        {"email": fake_email, "password": fake_password}
    )
    assert response.session.access_token is not None

the response.session.access_token is the token dependency love,which it may work in doc

the doc form looks wired

Thank you so much,


Shift the backend from Appwrite to Node.js and MongoDB

We are shifting the backend from Appwrite to Node.js
This transition to Node.js will bring us more flexibility, control, and improve the overall performance and scalability of Project Vibey. Here are the key points:
Improved Flexibility: With Node.js, we'll have a wide range of libraries and tools to customize our backend according to our needs.
Increased Performance: By leveraging Node.js's event-driven, non-blocking architecture, we'll see a significant boost in Project Vibey's performance and responsiveness.
Easier Integration: Node.js offers extensive support for frameworks and modules, making it a breeze to integrate with other systems and services seamlessly.

Can I work on this issue under gssoc23?

@suzy-g38 I have assigned the issue. Please enjoy working on the issue and let's make some good improvements to the project.


Honor isPrimaryAction

'isPrimaryAction' which says whether action needs to be highlighted to the user is not honored currently.

Hello @dptejas
The property you mention does not exist on the current http://adaptivecards.io/schemas/adaptive-card.json ; can you share where you've found it documented?

@ignacionr the property is indeed not documented. It will be introduced in the HTML renderer only, not in the schema (at least not for now.) Hosts who want to support this property will have to do so via extensibility (e.g. by custom parsing it.) THis property will make it possible to give a different visual treatment to the "primary".
I have updated the title and will add a slittle spec.

This makes sense. Can you guys make sure that when rendered on HTML, pressing “enter” while the focus is on a control will execute this action?
It could be convenient.

Yes, we can do that. I just opened https://github.com/Microsoft/AdaptiveCards/issues/1517

For reference, we have a few related issues on this topic: #861 and #272

https://github.com/Microsoft/AdaptiveCards/issues/861 is obsolete IMO, I no longer believe the solution I proposed in there is the right one. I think we should close it.

Implemented solution in #1521


[WIP]INTLY-7282 Allow GrafanaDashboard CRs to be reconciled by more than 1 grafana-operator

Jira
Main issue : https://issues.redhat.com/browse/INTLY-7282
Sub-task (makes sense to include this change in this PR) :  https://issues.redhat.com/browse/INTLY-5821
Description
To accommodate the move to cluster monitoring from the Application Monitoring Operator for Integreatly we need to ensure that dashboardCR's can be reconciled by more than 1 grafana operator
Verification
TBA

@pb82 As of now, the logic works although only on certain loops, the grafana CR gets the dashboard list from all namespaces, but the following reconcile sets it back to just the namespace in which it is located, and the status dashboardlist keeps alternating between just having the dashboards from it's namespace and all namespaces, any ideas as to why?

Example
Loop : 1

Loop : 2

The status block alternates between these two states

Adding folder support as described in https://issues.redhat.com/browse/INTLY-8371 to this PR, will prevent problems with dashboards getting overwritten by others from different namespaces.
currently all dashboards are added to the General folder, with the cross-namespace reconile support added in this PR this means that dashboards that share names will conflict and overwrite each other, this can be mitigated by separating dashboards into namespace-named folders ie Grafana > simpleDashboard and OtherNamespace > simpleDashboard

:eyes:

everything looks good to me

@R-Lawton @HubertStefanski the --scan-all flag is not set by default. By default the operator only scans for dashboards in its own namespace.

Verified following the steps, lgtm.


Fixes for unique_together, caching and autofield

Hello,
I created this PR to remove incompatibilities with the recent version of Django (5.1).
I hope this can be merged and released.
Thanks!

@jorenham  I understand this project is abandoned, but would it be possible to transfer it to another maintainer? Thanks!

That would, at the very least, require the current maintainer to respond to issues or other attempts to contact him/her. But that hasn't happened so far.

@jorenham Thanks for your reply! If that's the case I will create my own fork and release it in pypi under another name.

@em1208 you could also use my fork, which includes a similar fix for this issue.

@jorenham Is your fork available on pypi? If not are you able to release it?

it isn't, but you can install it with e.g. pip (and most other package managers) either way:
pip install git+https://github.com/jorenham/django-cron.git

Thanks, pip install via git works but doesn't handle well the caching of requirements so, ideally, would be nice to have the version released on pypi with a specific version number. Thanks a lot again!


Crash when trying to animate with transform props

Hey! I've been playing with the lib, awesome work!!
I noticed that whenever I try to animate the transform props according to the docs the app crashes, on both iOS and Android.
But on the other hand, animating imperatively with TransformManager seems to work great!
Here's a minimal reproduction on a new bare RN app: https://github.com/thiagobrez/filament-crash-repro
It's a very trivial scene:
export default function BalloonsScene() {
  const translate = useSharedValue<Float3>([0, 0, 0]);

  const renderCallback: RenderCallback = useCallback(() => {
    'worklet';
    const newY = translate.value[1] + 0.01;
    translate.value = [0, newY, 0]; // Commenting this line will stop the app from crashing
  }, [translate]);

  return (
    <FilamentView style={styles.filamentView} renderCallback={renderCallback}>
      <DefaultLight />
      <Model source={BalloonModel} transformToUnitCube translate={translate} />
      <Camera />
    </FilamentView>
  );
}

Xcode logs
In the debugger: filament.render.queue (20): EXC_BAD_ACCESS (code=1, address=0x88)
In the console:
Running application filamentTranslate ({
    initialProps =     {
        concurrentRoot = 0;
    };
    rootTag = 1;
})
nw_socket_handle_socket_event [C4.1.1:1] Socket SO_ERROR [61: Connection refused]
nw_socket_handle_socket_event [C4.1.2:1] Socket SO_ERROR [61: Connection refused]
nw_connection_get_connected_socket_block_invoke [C4] Client called nw_connection_get_connected_socket on unconnected nw_connection
TCP Conn 0x60000337aee0 Failed : error 0:61 [61]
Unbalanced calls start/end for tag 19
Running "filamentTranslate" with {"rootTag":1,"initialProps":{"concurrentRoot":false}}
[RNF/Dispatcher]: Installing global Dispatcher Holder...
[RNF/WorkletRuntimeCollector]: Registering WorkletRuntime 0x600002609c98
[RNF/HybridObject]: (MEMORY) Creating FilamentProxy (#1)... ✅
Loading react-native-worklets-core...
Worklets loaded successfully
[RNF/FilamentProxy]: Creating Worklet Context...
Incorrect NSStringEncoding value 0x8000100 detected. Assuming NSASCIIStringEncoding. Will stop this compatibility mapping behavior in the near future.
[RNF/FilamentProxy]: Successfully created WorkletContext! Installing global Dispatcher...
[RNF/Dispatcher]: Installing global Dispatcher Holder...
[RNF/WorkletRuntimeCollector]: Registering WorkletRuntime 0x600003505ef0
[RNF/FilamentProxy]: Successfully installed global Dispatcher in WorkletContext!
[RNF/FilamentProxy]: Creating Engine...
FEngine (64 bits) created at 0x10da97e00 (threading is enabled)
FEngine resolved backend: Metal
Selected physical device 'Apple iOS simulator GPU'
Backend feature level: 2
FEngine feature level: 1
[RNF/FilamentProxy]: Display refresh rate: 60.000000 Hz
[RNF/HybridObject]: (MEMORY) Creating EngineWrapper (#1)... ✅
[RNF/FilamentProxy]: Creating Choreographer...
[RNF/HybridObject]: (MEMORY) Creating ChoreographerWrapper (#1)... ✅
[RNF/HybridObject]: (MEMORY) Creating TransformManagerWrapper (#1)... ✅
[RNF/HybridObject]: (MEMORY) Creating RenderableManagerWrapper (#1)... ✅
[RNF/HybridObject]: (MEMORY) Creating SceneWrapper (#1)... ✅
[RNF/HybridObject]: (MEMORY) Creating LightManager (#1)... ✅
[RNF/HybridObject]: (MEMORY) Creating ViewWrapper (#1)... ✅
[RNF/HybridObject]: (MEMORY) Creating CameraWrapper (#1)... ✅
[RNF/HybridObject]: (MEMORY) Creating RendererWrapper (#1)... ✅
[RNF/HybridObject]: (MEMORY) Creating NameComponentManagerWrapper (#1)... ✅
[RNF/HybridObject]: (MEMORY) Creating EntityWrapper (#1)... ✅
[RNF/FilamentProxy]: Loading asset RNF_default_env_ibl.ktx...
[RNF/HybridObject]: (MEMORY) Creating FilamentBuffer (#1)... ✅
[RNF/FilamentProxy]: Loading asset http://localhost:8081/assets/src/balloon.glb?platform=ios&hash=a8264637d75085ee73683ccc41a3e40f...
[RNF/AppleFilamentProxy]: Fetching http://localhost:8081/assets/src/balloon.glb?platform=ios&hash=a8264637d75085ee73683ccc41a3e40f...
[RNF/FilamentProxy]: Finding FilamentView #13...
[RNF/HybridObject]: (MEMORY) Creating FilamentView (#1)... ✅
[RNF/HybridObject]: (MEMORY) Creating SurfaceProvider (#1)... ✅
[RNF/HybridObject]: (MEMORY) Creating Surface (#1)... ✅
[RNF/SurfaceProvider]: Surface created!
[RNF/HybridObject]: (MEMORY) Creating Listener (#1)... ✅
[RNF/Listener]: Creating Listener...
[RNF/SurfaceProvider]: Adding "surface created" listener
[RNF/HybridObject]: (MEMORY) Creating Listener (#2)... ✅
[RNF/Listener]: Creating Listener...
[RNF/SurfaceProvider]: Adding "surface destroyed" listener
[RNF/HybridObject]: (MEMORY) Creating Listener (#3)... ✅
[RNF/Listener]: Creating Listener...
[RNF/EngineImpl]: Setting surface provider...
[RNF/PointerHolder]: Manually releasing FilamentBuffer... (PointerHolder::release())
[RNF/HybridObject]: (MEMORY) Creating Listener (#4)... ✅
[RNF/Listener]: Creating Listener...
[RNF/EngineWrapper]: Creating swapchain for surface ...
[RNF/EngineImpl]: Creating swapchain ...
[RNF/HybridObject]: (MEMORY) Creating SwapChainWrapper (#1)... ✅
[RNF/EngineImpl]: Setting swapchain...
[RNF/ChoreographerWrapper]: Adding frame callback listener
[RNF/HybridObject]: (MEMORY) Creating Listener (#5)... ✅
[RNF/Listener]: Creating Listener...
Starting choreographer
[RNF/HybridObject]: (MEMORY) Creating FilamentBuffer (#2)... ✅
[RNF/HybridObject]: (MEMORY) Creating FilamentAssetWrapper (#1)... ✅
[RNF/PointerHolder]: Manually releasing FilamentBuffer... (PointerHolder::release())
[RNF/HybridObject]: (MEMORY) Creating AABBWrapper (#1)... ✅
[RNF/HybridObject]: (MEMORY) Creating EntityWrapper (#2)... ✅
[RNF/HybridObject]: (MEMORY) Creating FilamentInstanceWrapper (#1)... ✅
[RNF/HybridObject]: (MEMORY) Creating EntityWrapper (#3)... ✅
[RNF/HybridObject]: (MEMORY) Creating EntityWrapper (#4)... ✅
'Setting up camera lens with aspect ratio:', 0.4612676056338028
Warning: sample comparison not supported by this GPU

I guess I can continue with TransformManager for now, but just wanted let you know 👍🏻

same issue


Workaround empty image in JSON response

Fix for recent error:
Traceback (most recent call last):
  File "hcloud.py", line 50, in <module>
    main()
  File "hcloud.py", line 22, in main
    hostvars[server_name] = fill_host_vars(server)
  File "hcloud.py", line 31, in fill_host_vars
    'hcloud_image': server['image']['name'],

Thanks a lot.


Getting gemmPlugin error for mixtral model on v0.8.0 while hosting on triton server

System Info

GPU:  2 x Nvidia A100 80GB

Who can help?
No response
Information

[X] The official example scripts
[ ] My own modified scripts

Tasks

[ ] An officially supported task in the examples folder (such as GLUE/SQuAD, ...)
[ ] My own task or dataset (give details below)

Reproduction
a
Expected behavior
a
actual behavior
a
additional notes
a

This is caused by version mismatch of trtllm for engine building and runtime. Please check the trtllm version.