Refactor nbJs

As has been discussed in #118, the gensym-logic of nbJs is too complicated for the basic use-cases. Karax needs this advanced logic though, as each karax component must be compiled in its own file.
So the goal for this PR is to make the normal nbJsFromCode only use blocks instead gensym-logic. I have already started and I am getting nice behavior for simple cases. I need to check many more examples, though.
This PR will introduce several breaking changes:

nbJsFromCode will put the code inside a block so imports will not be allowed in them. Instead, you must use nbJsFromCodeGlobal which will be put at the top of the final script.
nbJsFromCodeInit, addCodeToJs will be deprecated as we are limiting ourselves to isolated blocks. If you want interop between multiple nbJs blocks, define a global variable using nbJsFromCodeGlobal.

Now I'm going to try and fix the docs.

I have tested this new slim nbJs on our documentation and our NimConf slides now and it seems to work. Tomorrow I'll go through your nblog posts which uses nbJs. Specifically there was one which needed exportc to work. Will be interesting to see how it works out

I checked nblog now and everything seems to work if we just move the imports to a global block :partying_face:

Documentation and tests have been updated now. It's actually quite impressive how short jsutils.nim is now that we have thrown away all the gensym logic :exploding_head:
I actually think this PR might be ready for review :o @pietroppeter

Have you tried running the three_js example in nblog?

I am thinking that we might want to have also a block for when you plan to have a single (nim derived) script in the entire page.
We could have a template that does not require a separate global block. Should be easy to add, right? name?  nbJsFromCodeSingle? nbJsFromCodeOnlyOne?

I don't quite understand what you mean. We have nbJsFromCodeOwnFile which karaxCodeBlock uses internally which compiles a code block the old way into its own file. Is that what you mean?

Without Gensym so that a case like threes_js works without a separate global section

Nothing uses gensym anymore. So for this case you could either use nbJsFromCodeOwnFile or nbJsFromCodeGlobal and just put all your code in there directly. Both ways you won't put the code inside a block.

ah ok, not even karax block use gensym? so two identical karax blocks will not run into issues of sharing variables?
anyway yeah I did not realize that I could just use nbJsFromCodeGlobal for everything.
and I need still to actually review code and understand for real this time how all this js stuff works. 🙄
in the back of my mind I still have the old question: why can't I just write code in a separate nim file, compile with js backend and put the output in a script tag in the document? I know it is wrong for many reason, but I still not really understanding where the different pieces of current complexity come from (I know about colliding identifiers when using more than one script,  issue that become even worst when the script is basically the same - e.g. a widget, karax based or not, I know of captured variables requiring effort, not sure if there is other stuff).
thanks for all the gentle explanations! ❤

ah ok, not even karax block use gensym?

No, the bumpGensym I talked about yesterday in #118 is implemented and solved the problem :D It is gone forever! Look at the diff for jsutils.nim and enjoy all the red B)

and I need still to actually review code and understand for real this time how all this js stuff works. roll_eyes

The code has never been as comprehensible as it is now, so now is a good time to dig in. Keep shooting questions at me, I'm not merging this until you understand it ;)

in the back of my mind I still have the old question: why can't I just write code in a separate nim file, compile with js backend and put the output in a script tag in the document? I know it is wrong for many reason, but I still not really understanding where the different pieces of current complexity come from (I know about colliding identifiers when using more than one script, issue that become even worst when the script is basically the same - e.g. a widget, karax based or not, I know of captured variables requiring effort, not sure if there is other stuff).

Most of the complexity is gone now thanks to the removal of all things gensym. So this is basically what we are doing now. Except that we are baking all the scripts into a single file (for ordinary nbJsFromCode) separated by blocks. This should improve build-times compared to compiling each nbJsFromCode as its own file (remember how slow cornerImage was in the nimConfSlide? It was exactly for this reason).
And the old complexity came basically solely from the colliding identifiers problem. So now that we have solved it (bumpGensym + blocks), it's not needed anymore. In theory, we could just use bumpGensym and keep the old behavior that all code blocks are totally isolated from each other and compile them one by one as you suggest. But the blocks are simple enough and allow us to have interop between code blocks, so I think it is the superior way forward.
Capturing variables is probably the most complex part that we have left, but it is "only" ordinary typed macro stuff to generate the correct code to serialize and deserialize the variable on the different sides.

Ok, I have read the rest and I can go on with comments and questions, it seems I understand now most of the code except the stuff in nimToJsString. Correct me on the statements below if I am wrong.
In nimib.nim we define basically 4 api to add js code generated from nim code:

jsFromString: consists of 4 templates (nbJsFromStringInit, nbAddStringToJs, nbAddToDocAsJs and nbJsFromString). This is the easiest to understand as it does what one would guess: put the content in a nim file, compile it to javascript and then add it in the document in the place where the block was placed. The only piece of complexity here is the bumpGenSym that we are doing and we will do for every nim own file that compiles to javascript. This is though an api that I think is never used in the documentation (correct?) as you would need to put nim code in a string which is kind of ugly. There is no capture of variables (you can do it manually by interpolating strings). Not sure where this api should be used in place of the others but it is a sort of escape hatch in case the other have bugs for some reasons...
jsFromCodeOwnFile: this is a first extension of the one before, you are now able to write nim code without putting it into a string AND you are also able to capture variables. Being an OwnFile you do the bumpGensym to avoid collisions of identifiers.
nbKaraxCode: this the Karax api, build on jsFromCodeOwnFile without the boilerplate (and adding the Karax id for multiple Karax blocks in the same file). It also captures variables.
nbJsFromCode: this is the one that uses the new intuition of a global js file. It assumes we have a single global script for every document. You can add stuff in the global scope or you can add stuff in a block scope. Great advantage is that all code in here gets compiled in a single script (so less time to compile and less duplicate js at the end). We are capturing variables of course. We do not actually add a block until there very end, currently this is put inside nbSave. Some thoughts about changing stuff here (besides the comments already done in the in code review):

what if instead of of nbJsFromCodeGlobal and nbJsFromCode we call them respectively nbAddJsFromCode and nbAddJsFromCodeInBlock? we are indeed adding js to a global script that has been initialized (as empty) during nbInit.
it is a bit weird that the block is added during nbSave. already in the in-code-review I propose to extract a proc. I would propose that we call it addJsGlobalCodeBlock or something similar. it could be called by the user as nb.addJsGlobalCodeBlock. Indeed we probably might want to add another field to NbDoc: isJsGlobalCodeBlockAdded: bool. So that in nbSave we check it and we add it only if it is false.
in this way we can add more html after this js code block (not sure if it would matter or not). But in particular something that we can do is to show the original code for js global code block with nbCodeToJsShowSource (should this template and the name of the command should be renamed from nbCodeToJs to nbJsFromCode? or maybe it is better like this since this block is actually shared also with the first api fromString?). I think currently we are losing the originalCode in nbJsFromCode blocks, we probably could add a new field to NbDoc to track "original" code.

On capturing variables:

it seems that nimToJsString is the only big piece of complexity in jsutils (probably we could move compileNimToJs from renders into jsutils?), since nbKaraxCodeBackend is rather transparent. You confirm that this complexity is only for the captured variables? if this is the case could we in principle check with a when len(args) == 1 (directly in nbFromCode blocks) and NOT call nimToJsString?
regarding capturing variables and nimToJsString could you explain better what that code does? probably it would help if you show the original vs transformed nim code to see how it would look. The code is really complex with two stages, a cache, a call to degensym...

Finally I think, having understood a bit more, we probably could improve the interactivity document:

the first example we show should not probably be one with a captured variable
we should mention the multiple apis and what are the sources of complexity, which should be essentially two: nim gensyms identifiers when compiling to js, we want to capture variables.
regarding the multiple api the global js script api it seems to me is a novel and smart idea on how to solve the sources of complexity, so it should be given a bit more appreciation.
also on capturing variable it is now evident to me (especially looking at the examples of two counters) that it is important for passing ids and have reusable widgets that contain both rawHtml and Js code. At first I thought its main use case was to pass complex objects generated from C, but I guess that is an additional (cool) use case (on which I do not think I have really seen examples, I mean in principle we could train a neural network with arraymancer and translating to a easier structure where we could do the inference on js... you know just to start with simple ideas :D).

Ok, with the in-code-review and last comment, I think I have exhausted my review on current code. Hey I am taking this literally 🤣:

Keep shooting questions at me, I'm not merging this until you understand it ;)

(probably we could move compileNimToJs from renders into jsutils?

Sure, will do :+1:

You confirm that this complexity is only for the captured variables? if this is the case could we in principle check with a when len(args) == 1 (directly in nbFromCode blocks) and NOT call nimToJsString?

The complexity is mainly due to the capturing of variables, but there still is logic in there that we need all the time. We still need the degensym to clean varName`gensym32 and the logic to put the code inside of a block. So I don't see any way of avoiding calling nimToJsString. If we really wanted to, we could perhaps make it so it didn't have to call the second stage macro in these cases, but I don't see why we would do that. It would only make the code more fragmented and harder to follow.

regarding capturing variables and nimToJsString could you explain better what that code does? probably it would help if you show the original vs transformed nim code to see how it would look. The code is really complex with two stages, a cache, a call to degensym...

The fact that we have two stages is that we want the body to be untyped. This is because typed code has been transformed and isn't the code that we wrote originally. Here's an example:
# untyped
let a = 1
let b = 2
echo a + b

# typed
let a = 1
let b = 2
echo [a + b]

As you can see, if we compiled the typed code in a file, it would echo out an array instead of an int. So having the body be untyped is very important. But we also want to get the type of the variables we want to capture, so that we can unserialize them to the correct type on the javascript side. So we need a typed macro to get those types. The question that is, how do we pass the untyped body to a typed macro without making it typed? The answer is putting it in a cache table! In the typed macro (second stage), we can then get the untyped AST of the body from the cache table. The key to the element in the table, key: static string, is passed as an argument to the typed macro.
So this should hopefully bring some light on why we need the two stages, the cache table and degensym.

Now for the actual capturing of variables!
let captureVars = toSeq(captureVars)

Here we save the symbols to the captured variables in a seq. Next we get the type of each symbol:
let captureTypes = collect:
  for cap in captureVars:
    cap.getTypeInst

Here we fetch the untyped body from the cache:
var body: NimNode
if key in bodyCache:
  body = bodyCache[key]

Next up we generate the assignments and deserialization of the captured variables:
# 1. Generate the captured variable assignments and return placeholders
let (capAssignments, placeholders) = genCapturedAssignment(captureVars, captureTypes)

If we for example have this code:
var x: int = 123
var y: string = "hello world"
nbJsFromCode(x, y):
  echo x, y

What genCapturedAssignment will give us is the following code:
let x = parseJson(placeholder`gensym1).to(int)
let y = parseJson(placeholder`gensym2).to(string)

and the list of placeholder-symbols it has generated. Now what's up with placeholder`gensym you might ask? We don't know the value of the variables at compile-time, so we create placeholders which we can then replace with the serialized values at run-time.

Next up we combine these new assignments and the body, degensym it, put it in a block (if specified) and turn the code into a string:
# 2. Stringify code
var code = newStmtList(capAssignments, body).copyNimTree()
code.degensymAst()

if putCodeInBlock:
  code = newBlockStmt(code)
var codeText = code.toStrLit

So We will basically have this string in the end:
let codeText = """
let x = parseJson(placeholder`gensym1).to(int)
let y = parseJson(placeholder`gensym2).to(string)
echo x, y
"""

Now we have come to the most complex part of it all: generating the replacements of the placeholders with the serialized json. We start off with assigning the codeString to an actual variable:
let codeTextIdent = genSym(NimSymKind.nskVar, ident="codeText")
result = newStmtList()
result.add newVarStmt(codeTextIdent, codeText)

So this will generate the following code:
var codeText = """
let x = parseJson(placeholder`gensym1).to(int)
let y = parseJson(placeholder`gensym2).to(string)
echo x, y
"""

Then we loop over each of the capture variables:
for i in 0 .. captureVars.high:

and for each one we do the following:
# Get string literal of the placeholder (e.g. "placeholder`gensym1")
let placeholder = placeholders[i].repr.newLit
# Get the variable symbol
let varIdent = captureVars[i]
# Generate the call to serialize the variable
let serializedValue = quote do:
  $(toJson(`varIdent`))

So the serialized value is basically obtained like this:
$(toJson(x))

The last thing we do in the loop is to do the actual string replacement of the placeholder with the json:
result.add quote do:
  `codeTextIdent` = `codeTextIdent`.replace(`placeholder`, "\"\"\"" & `serializedValue` & "\"\"\"")

This basically generates this code:
codeText = codeText.replace("placeholder`gensym1", &"{$(toJson(x))}")

And that is basically it. This final code on the C-side is:
var codeText = """
let x = parseJson(placeholder`gensym1).to(int)
let y = parseJson(placeholder`gensym2).to(string)
echo x, y
"""
codeText = codeText.replace("placeholder`gensym1", &"{$(toJson(x))}")
codeText = codeText.replace("placeholder`gensym2", &"{$(toJson(y))}")

the first example we show should not probably be one with a captured variable

Good point :+1:

we should mention the multiple apis and what are the sources of complexity, which should be essentially two: nim gensyms identifiers when compiling to js, we want to capture variables.

WIll add it to the Internal Workings section :+1:

regarding the multiple api the global js script api it seems to me is a novel and smart idea on how to solve the sources of complexity, so it should be given a bit more appreciation.

Do you have any concrete examples in mind? (I don't :rofl: )

also on capturing variable it is now evident to me (especially looking at the examples of two counters) that it is important for passing ids and have reusable widgets that contain both rawHtml and Js code. At first I thought its main use case was to pass complex objects generated from C, but I guess that is an additional (cool) use case (on which I do not think I have really seen examples, I mean in principle we could train a neural network with arraymancer and translating to a easier structure where we could do the inference on js... you know just to start with simple ideas :D).

Haha yes, it has many use-cases :) I haven't tried it out with any complex datatypes yet tbh, might be a good excuse to test its limits and do something cool with it as you say :sunglasses: In your planned Machine learning tutorial on SciNim for example, if we trained some simple machine learning model and provided an interactive way of testing it using nbJs somehow. Basically training it in the C-side and making predictions on the JS side with user inputs.

Ok, with the in-code-review and last comment, I think I have exhausted my review on current code. Hey I am taking this literally rofl:

Haha that's good! :smile: Didn't expect to sit nearly 2h answering :rofl: But that time will be well spent if it means I can save more hours in the future now that you know how this all works and can cover for me ;)

Thanks a lot for the answer and the great write up!
I have been reading and thinking about this stuff, and I have had some interesting thoughts (some outside of scope of this PR). Before doing that, I will like first to list stuff that is undecided, to do or needs more discussion:
from in-code review:

[ ] first 4 remarks are action to be taken, small details, when we close them we resolve the conversation
[ ] decision to take: do we interleave global scope and blocks or not?
[ ] change logic of bump gensym, likely adding a counter and looping inside the macro. 👍

rest of conversation.

[ ] decision to take: do we rename nbJsFromCodeGlobal and nbJsFromCode to nbJsFromCode and nbJsFromCodeInBlock (agree that we should skip add)?
[ ] decision to take: should we allow to add a final js block outside of nbSave?
[ ] decision to take: should we do something about possibility of showing code in JsFromCode?
[ ] move compileNimToJs from renders.nim to jsutils.nim
[x] light on why we need the two stages, the cache table and degensym

the explanation looks very convincing to me, still need to understand details, will do it on my own time trying stuff when I am in the mood

[x] explanation of variable captures

again here good explanation, thanks, will need to work more on it on my own

[ ] first example will not be with capture variables
[ ] will add a internal working sections on sources of complexity
[x] not really have concrete example on how to show appreciation about single js script with global and block sections.

first off, did I miss something? I intentionally did not quote here, but I tried to go with order of appearance.

now onto more discussions on decisions to take.
do we interleave global scope and blocks or not?
quoting you:

order of execution changes. So it depends on what we want the global code to be able to do. I like the global-at-the-top approach because it allows us to do customizations of global variables defined by other blocks.

honestly on this I would be to keep the flow as is given by how the user added the blocks. It feels really odd to me to put them in another order than what appears in the source, I am not sure if the reordering might have unintended side effects (I cannot think of any at the moment). the use case we would not support maybe can be done in other ways.
do we rename nbJsFromCodeGlobal and nbJsFromCode to nbJsFromCode and nbJsFromCodeInBlock?

I think that the most recommended one (the block version) should have the shortest name, though...

I do disagree on this one too (sorry!). It seems to me the real essential one, the one that you for sure will use will be the global one. you will likely import stuff and I can imagine that most of the time you might have a single block of JsFromCode and nothing else. It can be that in library work (e.g. a widget), you need to use most often a InBlock one, but that's because you want to make sure not to have conflicts and stuff, so it is an expected change. I can understand that the block version is "safer" (and in this way it is more in line with how templates by default are not dirty), but naming the block version InBlock is also consistent with the name of nbCode and nbCodeInBlock.
should we allow to add a final js block outside of nbSave?
on this one I have a new idea. it has to do with the fact that I do not like to much the fact that as they are now, the nbJsFromCode blocks are not really blocks (they do not add a NbBlock!). this prompted me to come up with a new type of block that I am calling the "collector" block. In this case we go back to have that nbJsFromCode (and nbJsFromCodeInBlock) that add NbBlock (with command as in their names and we could use codeandoutputas holders oforiginalCodeandtransformedCode). Those block will NOT have a render function (we might check if this generates a warning and find a way to turn it off. But we add a block at the end (nbJsFromCodeCollect? probably we might find a better name) that looks at the blocks in NbDoc(hey nothing forbids a block to look at the full doc when rendering! it has access to it!) and puts together the pieces of code in a single string. This would have other benefits: 1) we should not need anymore the additional fields inNbDoc` (I think); 2) in principle we can change the behavior of the collect block to implement the alternative flow (all globals and then all in blocks); 3) also for showing source code of JsBlock we can do as we were doing before (and granted it might not make to much sense to show it, indeed we should not care too much about this).
What do you think of this option?
It leaves me incidentally without the last point to discuss (and the discussion on the first one is also defused).

finally, just to give an idea on something out of scope. I think I am realizing that we should probably refactor again the NbBlock and embrace inheritance and use methods. I never thought about it because I was kind of suspicious of oop approaches and I also have never used them but in Nim's context (and frankly, scarcely also elsewhere) the more I think about it, the more it makes perfect sense. extending or customizing a block should be just inheriting from it. the base block should have just the (new) data: JsonNode field (or possibly even nothing), and every block would have its natural fields (just nbCode will keep the code and output fields, the other would change). Having natural fields would mean we do not need to put stuff in a context/data object and have a bad api taking them out. Container blocks could be easier to implement. Even NbDoc could possibly inherit from NbBlock and we might have a container block for the head part of the document...
Ok, I might be pushing it to far, especially considering that I have very limited experience with method and stuff, but I got very excited today thinking about this (so be gentle to communicate to me if there are some evident reason why this would not work 😝). Anyway, this is not something decided or soon, I have to digest the idea, make experience with inheritance and methods in Nim (and the vegalite/etamin project I mentioned in science chat is likely a good place to experiment with that, it actually was likely the reason I am thinking about this stuff) and will open an issue when I am ready to give more explanation. It came up though while thinking about this PR and I cannot avoid giving a preview here.

And I do agree that it would be very cool to use interactive stuff in the ML tutorial!

first off, did I miss something?

I think you got everything :+1: Nice to have it all listed out :D School is starting again tomorrow so we'll see when I'll manage to finish this :rofl:

honestly on this I would be to keep the flow as is given by how the user added the blocks. It feels really odd to me to put them in another order than what appears in the source, I am not sure if the reordering might have unintended side effects (I cannot think of any at the moment). the use case we would not support maybe can be done in other ways.

It's only odd if it's not what you expect from it. But I propose a compromise: we have 3 templates, nbJsFromCode (not in block, is interleaved with blocks), nbJsFromCodeInBlock (in block), nbJsFromCodeGlobal (not in block, placed at the top of the file). This way you get your naming scheme (which I agree with it the most consistent with our current naming of other blocks), and I get my global block. This way the user can decide for themselves how they want their code to be structured.  How does this sound?

It can be that in library work (e.g. a widget), you need to use most often a InBlock one, but that's because you want to make sure not to have conflicts and stuff, so it is an expected change. I can understand that the block version is "safer" (and in this way it is more in line with how templates by default are not dirty), but naming the block version InBlock is also consistent with the name of nbCode and nbCodeInBlock.

I agree with you on this one. I'm coming in from a very library-centric viewpoint, so good that you made me realize that :smile:

on this one I have a new idea. it has to do with the fact that I do not like to much the fact that as they are now, the nbJsFromCode blocks are not really blocks (they do not add a NbBlock!). this prompted me to come up with a new type of block that I am calling the "collector" block.

I actually like this idea :) Will try and implement it :+1:
Point 1 and 3 are good. But point 2 is not a good idea imo. We shouldn't change the semantics of the nbJs blocks like that, that could really screw up the ordering of blocks. Especially if two different libraries want to use different orderings :sweat_smile: But if we go with the nbJsFromCode/InBlock/Global route, we wouldn't have to care about this.

finally, just to give an idea on something out of scope. I think I am realizing that we should probably refactor again the NbBlock and embrace inheritance and use methods. I never thought about it because I was kind of suspicious of oop approaches and I also have never used them but in Nim's context (and frankly, scarcely also elsewhere) the more I think about it, the more it makes perfect sense. extending or customizing a block should be just inheriting from it.

That makes a lot of sense now that you mention it :o The only problematic thing I can come up with is if you wanted to inherit multiple blocks. For example if we want to inherit from both nbText and nbCode. I don't think Nim supports multiple inheritance. Or would we keep the renderProc/Plan as well?
I'm not that experience in OOP either tbh, but if we could make it work and make it easy to extend blocks, then it's definetly a route worth to investigate :)

I propose a compromise: we have 3 templates, nbJsFromCode (not in block, is interleaved with blocks), nbJsFromCodeInBlock (in block), nbJsFromCodeGlobal (not in block, placed at the top of the file) ... How does this sound?

sounds great, I like the idea! indeed it also solves the bad design of having
I think we are mostly aligned now! 🚀 when you start working on this you could take the bullet list and update the initial thread.

School is starting again tomorrow so we'll see when I'll manage to finish this 🤣

take your time! 😃

I am realizing that we should probably refactor again the NbBlock and embrace inheritance
That makes a lot of sense now that you mention it :o

right? happy that I am not completely off the mark! 😅

The only problematic thing I can come up with is if you wanted to inherit multiple blocks. For example if we want to inherit from both nbText and nbCode. I don't think Nim supports multiple inheritance. Or would we keep the renderProc/Plan as well?

yep, there are plenty of stuff we need to find out on this route. on multiple inheritance there is an interesting RFC thread (in particular macro approaches would be possible). Anyway even with single inheritance situation seems better than what we have now.

sounds great, I like the idea! indeed it also solves the bad design of having
I think we are mostly aligned now! rocket when you start working on this you could take the bullet list and update the initial thread.

Nice! :D Will do!

take your time! smiley

Thanks :) I'll aim at having it done next weekend...

right? happy that I am not completely off the mark! sweat_smile
yep, there are plenty of stuff we need to find out on this route. on multiple inheritance there is an interesting https://github.com/nim-lang/RFCs/issues/262 (in particular macro approaches would be possible). Anyway even with single inheritance situation seems better than what we have now.

Haha, you might definitely be on to something. A superweird, but kinda related, idea: using ECS and Polymorph instead of inheritance :rofl: It's not a serious proposal, but it would be a good exercise if one wants to learn Polymorph for something that isn't game-related. To implement a nimib-like API on top of it, just for fun.

A superweird, but kinda related, idea: using ECS and Polymorph instead of inheritance 🤣

haha, thought about that also when I read the thread. honestly I know even less about ECS than OOP so it might be for the next iteration. I do have in mind to play with polymorph though (e.g. https://github.com/pietroppeter/nblog/issues/13), it really looks great!

haha, thought about that also when I read the thread. honestly I know even less about ECS than OOP so it might be for the next iteration. I do have in mind to play with polymorph though (e.g. https://github.com/pietroppeter/nblog/issues/13), it really looks great!

Yes that seems like a more reasonable thing to start with :)

The refactoring of the code was easier than I expected. The collector proc was really convenient :D Now I just have to update the docs with better examples and more explanations.

I have a draft of the new interactivity document now. Would appreciate a review of it as I'm feeling it is a bit too technical in the first part. But I don't see a good way of explaining it without mentioning the nim common file all blocks will be put inside

Had a look at the preview docs and had a few more remarks:

first JsFromCode code is not shown in the document but it should
we could mention at the end of nbKaraxCode section of interactivity.nim that we have another example of using nbKaraxCode in caesar

in index.nim short description of caesar we refer to it as being built with nbJsFromCode while it uses nbKaraxCode

I think with this I finally completed the review. Sorry for the delay and again great work on this!

first JsFromCode code is not shown in the document but it should

Not sure I understand what you mean :/

we could mention at the end of nbKaraxCode section of interactivity.nim that we have another example of using nbKaraxCode in caesar
in index.nim short description of caesar we refer to it as being built with nbJsFromCode while it uses nbKaraxCode

Will fix!

first JsFromCode code is not shown in the document but it should

Now I found it. Changed nbCode to nimibCode and it worked.

I think with this I finally completed the review. Sorry for the delay and again great work on this!

:partying_face:
No worries :smile: Hopefully I shouldn't have to update the nbJs stuff in  a while now that it's so simple, so the question is what I should do now :rofl:

the question is what I should do now

well, there is plenty of open issues... 😆

ready to merge, right?
I guess after merging we should also bump version and release, right?
if you want to make the preparations (bump version, finalize changelog for release, ...) in this PR, otherwise I'll do it later

🤣 very true, 51 open issues should have something yummy in them.
I can bump the version and changelog when I get home 👍 I think this is my first time making a new release on my own? 😯

I think this is my first time making a new release on my own? 😯

then go ahead and enjoy the release! 🚀

Versions are bumped, hope I didn't forget anything now...
Will have a look through the preview before merging this.

ah, maybe add a line about the new nimibCode in changelog?

Good point :+1 Looked through the docs before pushing the last commit and everything seems to work fine. So I'll merge this after dinner unless we find something else until then.

looks good to me.
the more I think about it the more stuff it pops to mind. we probably should link the NimConf 2022 presentation (and slides) in the readme/index? not sure in the minimal way we did for 2021 or showing the video thumbnail (would look more attractive). to be honest this could all be separate PRs but since we are here...

It would be nice with a thumbnail, but we'd just have to get a better thumbnail where we both are in it. I have uploaded one such example. But I think it is better if we merge this first so we can get a static link to it in the main branch instead before linking to it. So I'll merge this and create a follow-up PR for that.


Installation guide

The project has 2 direct dependencies tqdm and matplotlib. And these packages have a few other dependencies.
I have captured the dependencies with pip freeze > requirements.txt inside a venv.
Also added .gitignore file.

thanks for pointing this out. I have added the version prints of Python, matplotlib and tqdm in demo.ipynb.


NativeWind doesn't seem to support custom spacing

Hey folks 👋 thanks for bringing Tailwind to Native!
I currently have the tailwind.config.js below. While the custom colours are working, the custom spacing is not.
When I'm using the className bottom-18 or mt-18 I don't get see any increase in offset or margin.
For builtin values like bottom-16 or mt-16 it is working fine. Any idea what might be causing this?
If it helps, I can also set up a repository that reproduces the issues.
module.exports = {
  content: ["./App.{js,jsx,ts,tsx}", "./src/**/*.{js,jsx,ts,tsx}"],
  theme: {
    extend: {
      spacing: {
        '18': '4.5rem',
      },
      colors: {
        coffee: {
          50: "#f5f4f1",
          100: "#e7e2da",
          200: "#d0c5b8",
          300: "#b5a28f",
          400: "#9f8570",
          500: "#907562",
          600: "#806456",
          700: "#644c44",
          800: "#56413d",
          900: "#4b3a38",
        },
      },
    },
  },
  plugins: [],
};

rem are not valid React Native units, so it is being ignored. However, you may want to switch to the next (#308) branch which now supports rem

@marklawlor I'm having a similar issue. I have a custom spacing config and it doesn't work.
I'm using the latest version and my tailwind.config.js looks like:
const colors = require("./src/layout/theme/colors");

/** @type {import('tailwindcss').Config} */
module.exports = {
  content: ["./App.{js,jsx,ts,tsx}", "./src/**/*.{js,jsx,ts,tsx}"],
  theme: {
    extend: {
      colors,
      fontSize: {
        xs: ['10px'],
        sm: ['12px'],
        base: ['14px'],
        md: ['16px'],
        lg: ['18px'],
        xl: ['20px'],
        '2xl': ['22px'],
        '3xl': ['24px'],
        '4xl': ['26px'],
        '5xl': ['28px'],
        '6xl': ['30px'],
        '7xl': ['32px'],
      },
      fontFamily: {
        regular: 'mulish-regular',
        italic: 'mulish-italic',
        medium: 'mulish-medium',
        'medium-italic': 'mulish-medium-italic',
        'extra-light': 'mulish-extra-light',
        'extra-light-italic': 'mulish-extra-light-italic',
        'light': 'mulish-light',
        'light-italic': 'mulish-light-italic',
        'semi-bold': 'mulish-semi-bold',
        'semi-bold-italic': 'mulish-semi-bold-italic',
        'bold': 'mulish-bold',
        'bold-italic': 'mulish-bold-italic',
        'extra-bold': 'mulish-extra-bold',
        'extra-bold-italic': 'mulish-extra-bold-italic',
        'black': 'mulish-black',
        'black-talic': 'mulish-black-italic'
      },
      spacing: {
        1: '6px',
        2: '12px',
        3: '18px',
        4: '24px',
        5: '30px',
        6: '36px',
        7: '42px',
        8: '48px',
        9: '54px',
        10: '60px'
      },
    },
  },
  plugins: [],
}

Basically I want to change the scaling from 4px to 6px. So using mt-1 instead of applying marginTop: 4px should apply maringTop: 6px. Right now, even with the custom config it doesn't work. The colors, font sizes and font families works as expected.
Should I open a new issue or you want to reopen this one?


Update sessions usage info

URL, if applicable
https://docs.quantum.ibm.com/guides/execution-modes#sessions-versus-batch-usage
https://github.com/Qiskit/documentation/blob/main/docs/migration-guides/sessions.mdx
Describe the new content you are requesting.
In qiskit-ibm-runtime 0.30.0, we added a new Session.usage() and Batch.usage() method that can be used instead of session.details()["usage_time"]
If this new content request is accepted, do you want to write the content?
I will write a draft of the proposed content

Thanks @kt474 !

Hi @kt474 - do you have a timeline for this issue, so we can categorize it in our sprints? Thanks!

Hi @kt474 - do you have a timeline for this issue, so we can categorize it in our sprints? Thanks!

Just made a PR! https://github.com/Qiskit/documentation/pull/2078 Thanks!


Can i use it without appDir?

Hey @haramishra, great question.
Yes you can. Just setup middleware.ts according to the readme and then use getTokensFromObject from either API Routes or getServerSideProps. I've added some basic examples here: https://github.com/awinogrodzki/next-firebase-auth-edge/blob/main/README.md#api-routes-or-getserversideprops
Let me know if you're missing something, cheers!

@awinogrodzki  Thanks for the help.


Create a "ceda-wps-assets" repository

Create a repo called "ceda-wps-assets", with properties:

MOLES links
Datasets covered
roocs.ini config files for datasets
parameters for each dataset in the WPS
code to parse/interact with these

https://github.com/cedadev/ceda-wps-assets


security_group.py: check cidr unstrictly to accept cidrs like <IP_ADDRESS>/24

Description

When I add a security group rule with cidr like <IP_ADDRESS>/24, the rule is not applied on kvm hypervisor.
Ths issue does not exist in <IP_ADDRESS> and previous versions.
Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[X] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Screenshots (if appropriate):
How Has This Been Tested?

It has been tested in advanced zone with security group.
It can be verified very easily in python3, see results below.
# python3
Python 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> import ipaddress
>>> ipaddress.ip_network("<IP_ADDRESS>/28")
IPv4Network('<IP_ADDRESS>/28')

>>> ipaddress.ip_network("<IP_ADDRESS>/24")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/ipaddress.py", line 74, in ip_network
    return IPv4Network(address, strict)
  File "/usr/lib/python3.6/ipaddress.py", line 1519, in __init__
    raise ValueError('%s has host bits set' % self)
ValueError: <IP_ADDRESS>/24 has host bits set

>>> ipaddress.ip_network("<IP_ADDRESS>/24", False)
IPv4Network('<IP_ADDRESS>/24')

@rhtyd Yes, we have that in the RPM/DEB dependencies.
Python 3 is however also present by default on both CentOS and Ubuntu.

Manually tested against python3, BO doesn't run test against SG env so I'll merge this based on reviews and manual testing.


fix arg order

I was trying to use the language flag, -lJavaScript, to take advantage of the new JXA support in Yosemite. Because the file path was being unshifted on to the front of the args, it wasn't working, so I switched to push.

Thanks!

Snap.  This change might allow you to add an osascript flag but it breaks the ability to pass variables to Applescript.

why still this PR is not applied? U+1F914


"&" not working

As Keyboard input "&" is not working. Since in C++ it is required for passing parameter as reference to function.

Sorry, I might not be understanding this correctly.
Do you mean you can't type & in the code editor?

@vineetmhapsekar can you clarify please? If you can't get the & character in the editor, can you let us know:

your operating system
your browser and version
can you open the javascript console and see if there are any errors there?

Thanks!

Closing this as there has been no followup from @vineetmhapsekar. If this pops up again, feel free to reopen


Adding Cerebe-Base64 to List

Awesome. Thanks for contributing.
Just a couple issues:

I don't know if the commit name was intentional, but using the plugin name would be better.

Full stop at the end of the line please :)


Support input unions

Perceived Problem
User wants an interface like this:
Case 1:
foo

Case 2:
foo -i

Case 3:
foo -i yarn
foo -I npm
foo -i pnpm

Case 1, when nothing given, means, don't do -i thing.
Case 2, when given as boolean, means, do -i thing with some default behaviour
case 3, when given, means, do -i thing with this
Ideas / Proposed Solution(s)
How could this be represented in the Zod types?
z.boolean().or(z.enum(['a','b','c'])).default(false)

Should do it.
The internal type would be:
true | false | 'a' | 'b' | 'c'

The false case is because 1) its the default and 2) the user could do this explicitly:
foo --no-i

Currently Mold Command does not know how to parse based on an input union. Nor does it know how to generate docs for an input union.
For parsing there are few rules:

If the union includes string literals AND a boolean those string literals CANNOT be false or true since that would make it impossible to properly parse/cast the environment input.

Looking at the above example for a concrete example: When parsing the flags, we assume that this -i --something-else means the user is intending to pass as the boolean union member. When they pass -i yarn --something-else we assume the enum.

This kind of zod expression would be unsupportable by Molt: z.boolean().or(z.enum(['a','b','c']).default('b')).default(false). A default on a member within the union is not parsable.

~The above leads me to believe that we shouldn't support zod unions but instead roll our own, like we did with .mutuallyExclusive. We could have .union or .or or even simpler could just be accepting an array as the second parameter to .parameter:~
Ignore examples below and see comment below.
Command.parameter('i install', [z.boolean(), z.enum(['a','b','c'])])

Ah, but the problem with this is we lose the ability to express the concept of a default for the parameter. Ok, try again with a builder function then:
Command
  .parameter('i install', __ =>
    __.value(z.enum(['a','b','c']).description('...'))
      .value(z.boolean().description('...'))
      .default(true)
  )

Maybe the approach of supporting zod unions is actually best...
Its just that we need to have some limits:

No defaults on inner union members (only ok top level)
No optionals on inner union members (only ok top level)

Then we can support this:
Command
  .parameter('i install', z.boolean().or(z.enum(['a','b','c'])).default(false))

How should the help be rendered for this? Example of some current docs:

Here is an example sketch where we just stack the type/description cell with additional entries for each union member. This sketch assumes descriptions have been given for each member:
PARAMETERS

  Name       Type/Description                              Default

  move       boolean                                       false
  m          Delete the original file after it has be
             en converted.

  install    boolean                                       false
  i          Run dependency install after setup. Use
             the system-detected package manager.

             yarn | pnpm | npm
             Force use of a specific package manager.

  filePath   string                                         REQUIRED
             Path to the file to convert.

  from       json | yaml | toml                            undefined
             Format to convert from. By default infer
             red from the file extension.

Here's the sketch where no descriptions were given:
PARAMETERS

  Name       Type/Description                              Default

  move       boolean                                       false
  m          Delete the original file after it has be
             en converted.

  install    boolean | yarn | pnpm | npm                   false
  i

  filePath   string                                         REQUIRED
             Path to the file to convert.

  from       json | yaml | toml                            undefined
             Format to convert from. By default infer
             red from the file extension.

Here is an example where description was given at the union and member levels:
PARAMETERS

  Name       Type/Description                              Default

  move       boolean                                       false
  m          Delete the original file after it has be
             en converted.

  install    union                                         false
  i          Run dependency install after setup.

             boolean
             Use the system-detected package manager.

             yarn | pnpm | npm
             Force use of a specific package manager.

  filePath   string                                         REQUIRED
             Path to the file to convert.

  from       json | yaml | toml                            undefined
             Format to convert from. By default infer
             red from the file extension.

Maybe we can take some inspiration from how mutually exclusive parameters are rendered:

Idea:
PARAMETERS

  Name       Type/Description                              Default

  move       boolean                                       false
  m          Delete the original file after it has be
             en converted.

  install    ┌─union                                       false
  I          │ Run dependency install after setup.
             │
             ◒ boolean
             │ Use the system-detected package manager.
             │
             ◒ yarn | pnpm | npm
             │Force use of a specific package manager.
             └─
  filePath   string                                         REQUIRED
             Path to the file to convert.

  from       json | yaml | toml                            undefined
             Format to convert from. By default infer
             red from the file extension.

Maybe we can take some inspiration from how mutually exclusive parameters are rendered:

Idea:
PARAMETERS

  Name       Type/Description                              Default

  move       boolean                                       false
  m          Delete the original file after it has be
             en converted.

  install    ┌─union                                       false
  i          │ Run dependency install after setup.
             │
             ◒ boolean
             │ Use the system-detected package manager.
             │
             ◒ yarn | pnpm | npm
             │ Force use of a specific package manager.
             └─

  filePath   string                                         REQUIRED
             Path to the file to convert.

  from       json | yaml | toml                            undefined
             Format to convert from. By default infer
             red from the file extension.

I really like this approach. To me, it makes it the most clear that there are multiple potential input types and the scenarios each covers.

I wonder if we should render it that way even when no descriptions are given. My thinking is that if you're not giving descriptions you probably don't care about the expanded rendering.

Made some more progress tonight, this time on help rendering. Here's how its looking:

Its not perfect but I think this iteration of work has been long enough, its got value now, could ship.


ET-4800

Have the ET-4800 and added it as described in the readme. When running "Detect Access Keys" I end up with this error:
[ERROR] More than one pattern appears to be a serial number:
[ERROR] - found pattern "X8GT011188" at address 793
[ERROR] - found pattern "X8GT011188" at address 1604
[ERROR] Could not detect serial number.
I am able to analyze EEPROM values by pressing "Detect Configuration".
Looks like Reset button also work:
[NOTE] Current EEPROM values for Raw waste reset: 28: 19, 52: 209, 53: 15, 54: 94, 55: 94, 255: 94, 47: 0, 48: 147, 49: 11, 50: 89, 51: 0, 252: 110, 253: 0, 254: 0.
[NOTE] Current EEPROM values for Main waste: 48: 147, 49: 11, 47: 0.
[NOTE] Current EEPROM values for Borderless waste: 50: 89, 51: 0, 47: 0.
[NOTE] Current EEPROM values for Third waste: 252: 110, 253: 0, 254: 0.
I do not know the values for the ET-4800 and do not know how to double check if these are correct. Do you think it is safe to go ahead and reset or can I brick it?

[ERROR] - found pattern "X8GT011188" at address 793
[ERROR] - found pattern "X8GT011188" at address 1604

Version 5.1 should not show an error when a set of serial number patterns is found, provided they are the same, as in the above case.
I have not tested that model, but I guess it is safe to go and it should be possible to reverse the operation in case of problems.

Ok thanks!
When running "Detect Configuration",  the following appears in a CMD window after a while:
Exception in Tkinter callback
Traceback (most recent call last):
File "tkinter_init_.py", line 1967, in call
File "tkinter_init_.py", line 861, in callit
File "ui.py", line 2439, in
File "ui.py", line 2541, in detect_configuration
IndexError: list index out of range

Traceback (most recent call last):
File "tkinter_init_.py", line 1967, in call
File "tkinter_init_.py", line 861, in callit
File "ui.py", line 2439, in
File "ui.py", line 2541, in detect_configuration
IndexError: list index out of range

Strange, I simulated your pattern occurrence and I do not have this error; can you please double-check you have the latest code? Please reinstall the application. Can you repeat the operation and check that you exactly pasted all Traceback data? Which OS are you using?

Yes using the executable exe file v.5.1.0 on Wiundows 11 Pro, Tried to reinstall the app and the same happens again.
Exception in Tkinter callback
Traceback (most recent call last):
File "tkinter_init_.py", line 1967, in call
File "tkinter_init_.py", line 861, in callit
File "ui.py", line 2439, in
File "ui.py", line 2541, in detect_configuration
IndexError: list index out of range

Now the following issues should be solved:

Exception in Tkinter callback......File "ui.py", line 2541, in detect_configuration...IndexError: list index out of range

[INFO] Found data: {}.

Could you please check? Thanks

"Printer configuration": {
"serial_name[0]": "X8GT011188",
"serial_number[0]": range(793, 803),
"serial_name[1]": "X8GT011188",
"serial_number[1]": range(1604, 1614),
"po_time": None,
"Maintenance required level[0]": [54],
"Maintenance required level[1]": [55],
"Maintenance required level[2]": [255],
"Maintenance required level[3]": [1680],
"wifi_mac_address[0]": range(1920, 1926),
"read_key": [74, 54],
"write_key": b"Maribaya",
}
Thanks!
Seems to be working now. Does the "Maintenance required level" has anything to do with the ink waste pads and what does the values mean?

Seems to be working now. Does the "Maintenance required level" has anything to do with the ink waste pads and what does the values mean?

They refer to the maximum percentage of waste level to require maintenance.
It is all ok now, thanks; I'll add the configuration of ET-4800.


Introduce useLoopbackInterface to config

In hopes of tackling https://github.com/jitsi/jitsi-videobridge/issues/1709, this is a patch that introduces a couple new config variables. Not sure this would be the right way though, as it's kinda superfluous in hindsight, having org.ice4j.ice.harvest.ALLOWED_INTERFACES and org.ice4j.ice.harvest.BLOCKED_INTERFACES in place. Nonetheless, here's the patch.

Hi, thanks for your contribution!
If you haven't already done so, could you please make sure you sign our CLA (https://jitsi.org/icla for individuals and https://jitsi.org/ccla for corporations)? We would unfortunately be unable to merge your patch unless we have that piece :(.

Thanks for the contribution! Looks good to me with a couple of small changes:

Remove the org.ice4j.ice.harvest.USE_LOOPBACK_INTERFACE option (we don't want to add more options to the legacy file)
Add a default value (false) for ice4j.harvest.use-loopback-interface in reference.conf with a short explanation of what the option does.
Nit: rename to use-loopback-interfaces (plural)

You'll also need to sign the CLA as Jenkins pointed out.

Hey,
can you tell me how this ice4j project gets bundled into jitsi-videobridge, and how reference.conf (or any similar configuration) gets picked up by ice4j?
I see no reference.conf in the freebsd package (much less in the jitsi-videobridge.jar file where ice4j is packed into. Hence, I'm quite unsure how I can get this working on FreeBSD eventually.

Also because of this, I'd rather leave the 'old' configuration option in place, since FreeBSD might take a while to catch up with the new configuration file, should that be the issue.
I can contact the maintainer of the FreeBSD package, but I can't expect to have a timely reply from him to change the config file to the reference.conf format. A lot of deployments use the old format already.

Alright, I've made the discussed changes.
As for the CLA, I don't want to sign anything. However, I hereby declare this contribution under a WTFPL license. Sorry but I'm just not the kind of guy who signs random CLAs.

a humble bump

LGTM, but we can't merge it without a CLA.

You can close this request then and submit the patch under your name, I really don't mind.

reference.conf contains the defaults and is included in the ice4j.jar file. Applications use a different file with configuration overrides. For example, jitsi-videobridge ships with overriden default ice4j configuration in application.conf (this is not meant for users of jvb to change). On debian jvb also ships with /etc/jitsi/videobridge/jvb.conf for configuration overrides provided by the user. This file is loaded by adding -Dconfig.file=/etc/jitsi/videobridge/jvb.conf to the java command line.

reference.conf contains the defaults and is included in the ice4j.jar file. Applications use a different file with configuration overrides. For example, jitsi-videobridge ships with overriden default ice4j configuration in application.conf (this is not meant for users of jvb to change). On debian jvb also ships with /etc/jitsi/videobridge/jvb.conf for configuration overrides provided by the user. This file is loaded by adding -Dconfig.file=/etc/jitsi/videobridge/jvb.conf to the java command line.

Thanks, I'll let this information be known to the package maintainer. In the meanwhile, we gotta keep the old option, because currently there is no such configuration passed to the packaged videobridge.

Hey @bgrozev,
Out of curiosity I went ahead and compiled a videobridge with using my modifications on the ice4j project. When I copied it over to my server and tried to start it up, it didn't even start to bind on any UDP port, much less emitting logs about initializing SinglePortUdpHarvesters.
I'm just looking into the code right now, and besides the SinglePortUdpHarvester.java and its test, don't find any reference to SinglePortUdpHarvester. It seems to me that the new ice4j code doesn't even use it.
Can you doublecheck please if this is the case? I'm confused as to why the code therein doesn't even run.

Hey @karolyi
The bridge initializes SinglePortUdpHarvesters on its own here: https://github.com/jitsi/jitsi-videobridge/blob/master/jvb/src/main/java/org/jitsi/videobridge/ice/Harvesters.java#L83

Interesting, then I have no idea as to why it's not initializing any harvesters.
That said, the videobridge in FreeBSD seems pretty old (still uses jitsi-jitsi-videobridge-2.1-183-dbddd16_GH0.tar.gz from github), a lot of changes have happenes since.
I just want to get my changes working so it can end up in FreeBSD already.

jitsi-jitsi-videobridge-2.1-183-dbddd16_GH0.tar.gz

This is very old, it might not even be compatible with ice4j master.

That shouldn't be a problem, as when I get in touch with the maintainer, we'll update the whole shebang.
I have compiled from the latest videobridge and didn't get ant SinglePortUdpHarvesters started up, that's the problem. Until I don't get it working, it makes no sense the contact the maintainer to have it updated in the ports tree as well, because it's not guaranteed to work.


Idea: simplify api

Hey,
I like what you did but would like to add suggestion (I actually wanted to create a similar crate in the first place).
It should be possible to extract the MatchedPath and Engine in the FromRequestParts Trait by introducing a Trait to extract the engine from the state (ideally the trait can be applied like FromRef via a macro).
This allows to render the tenplate via a simpler simpler function call and also it requires only 1 parameter instead of 2 for each handler.
I haven't tested if it works but it shoud simplify the api drastically for users.

I am thinking of something like this as a minimal api:
async fn get_name(
    engine: TemplateEngine,
    Path(name): Path<String>,
) -> impl IntoResponse {
    let person = Person { name };

    engine.render(person)
}

// Define your application shared state
#[derive(Clone, FromRef, TemplateEngine)]
struct AppState {
    engine: TemplateEngine,
}

Hi @Alken0, thanks for your feedback!
TemplateEngine does not implement FromRequestParts because it would coerce user to use Axum's state. It was a deliberate design choice to make explicit where the engine is coming from. Users are free to choose their preferred shared state technique. For example, a user might want to use Extension or a global static once cell.
Key and TemplateEngine doesn't mix for similar reasons. The library doesn't enforce the use of Key, and is another deliberate design decision. Some examples use it, others use custom keys and lastly you may want to call the same template no matter what the current route path is. Render accepts anything that can be coerced to &str.
If your application doesn't benefit from these design decisions, you can always do any of the following and enforce it yourself across your application:

Extend the TemplateEngine trait

pub trait TemplateEngineExt {
  // TODO
}

impl <EXT: TemplateEngine> TemplateEngineExt for EXT {
  // TODO
}

Use type aliases

pub type AppTemplateEngine = State<TemplateEngine<minijinja::Environment>;

Create your own FromRequestParts extractor, based on the Key and TemplateEngine implementations. See axum docs.

I mean it would still be possible to implement a "CustomKey" more or less the same way it's done right now.
Also to support fixed-template-paths it's possible (and very senseful as it is a completly different usecase) to provide a different method with a path-parameter.
I just want to point out that the current approach requires lot's of repetitive and unnecessary code that could be reduced in every single handler.

Just to make things clear, the API change you are proposing looks something like this:
// Using MatchedPath (Key). It renders the template whose name is the current path
async fn foo(engine: Engine<Handlebars<'static>>) -> impl IntoResponse {
	engine.render(())
}

// Using a custom key. It will render the template whose name is whatever CustomKey generates
async fn baz(engine: Engine<Handlebars<'static>, CustomKey>) -> impl IntoResponse {
	engine.render(())
}

// Using dynamic/static key. It will render the template named "bar"
async fn bar(engine: Engine<Handlebars<'static>>) -> impl IntoResponse {
    let name = "bar";
	engine.with_key(name).render(())
}

As I stated earlier, this would add runtime overhead to the third case (bar). The key would be extracted from the request even if it won't be used. So this can't be added to Engine.
The alternative I would be to define another extractor that leverages both the Key and the engine (second suggestion). Something like this:
pub struct Renderer<E, K = Key> {
	engine: E,
	key: K
}
// impl FromRequestParts for Renderer
impl<E,K> Renderer<E,K> {
	pub fn render<D>(self, data: D) -> Render<E,K,D> {
		Render(self.key, self.engine, data)
	}
    // TODO add render_html method
}

// Both Key and CustomKey can leverage this new Renderer extractor
async fn foo(renderer: Renderer<Engine<Handlebars<'static>>>) -> impl IntoResponse {
	renderer.render(())
}
async fn baz(renderer: Renderer<Engine<Handlebars<'static>>, CustomKey>) -> impl IntoResponse {
	renderer.render(())
}

// For dynamic/static keys, the raw engine is used to avoid the overhead
async fn bar(engine: Engine<Handlebars<'static>) -> impl IntoResponse {
    let name = "bar";
	Render(name, engine, ())
}

I'm not sure of the usefulness of this approach as it increases API complexity. In my experience, less is more. The moment you add more ways of doing the same thing, people start to get confused. On the other hand, I agree that this would reduce boilerplate for users who mostly render templates based on keys.
What do you think? Would Renderer suffix your needs?

Yes indeed this would create an overhead. I am sorry, I overlooked it in the last comment.
And sorry for not formatting it correctly, yours looks so pretty :D.
Your suggestion is exactly what I meant.
What do you think about tweaking the code a little bit. This does not change any functionality but may be less confusing (even though a better wording than renderer.render is still needed):
// this was called Engine before
pub struct StaticRenderer<E> {
	engine: E //e.g. Handlebars
}
// impl FromRequestParts for Renderer
impl<E> StaticRenderer<E> {
	pub fn render<D>(self, key: String, data: D) -> Render<E,D> {
		Render(key, self.engine, data)
	}
}

// this was called Renderer before
pub struct DynamicRenderer<E, K = Key> {
	renderer: StaticRender,
	key: K
}
// impl FromRequestParts for DynamicRenderer
impl<E, K> DynamicRenderer<E, K> {
	pub fn render<D>(self, data: D) -> Render<E,K,D> {
		self.renderer.render(self.key, data)
	}
}

// Both Key and CustomKey can leverage this new DynamicRenderer extractor

type DynRender = DynamicRenderer<StaticRenderer<Handlebars<'static>>>
async fn foo(renderer: DynRender) -> impl IntoResponse {
	renderer.render(())
}
type DynRenderMyKey = DynamicRenderer<StaticRenderer<Handlebars<'static>>, MyKey>
async fn baz(renderer: DynRenderMyKey) -> impl IntoResponse {
	renderer.render(())
}

// For dynamic/static keys, the StaticRenderer is used to avoid the overhead
// For a user they seem very similar because of the
type StatRender = StaticRenderer<Handlebars<'static>
async fn bar(renderer: StatRender) -> impl IntoResponse {
	let name = "bar";
	renderer.render(name, ())
}

And I don't want to push you to change your library.
I just want to suggest, feel free to say no at any time.

Changing Engine to StaticRenderer is a no, at least for now, as It is a breaking change.
I've slept on this and I'm still not convinced there are enough benefits to do this. However, I would like to leave this issue open and allow anyone to propose new ideas.


Auth: add callback URL parameter to authorize.

This makes it easier to update the callback URL for each request without resetting the default global callback URL.

Looks good! Can you update the docs please?


feat: git tag prefix

How about<EMAIL_ADDRESS>instead of vike-react-v1.2.3? That's what Vite does: https://github.com/vitejs/vite/releases.

Good point and actually the CLI parser needs to be fixed more, because I discovered that some places in the code assume we support some --force and --dev flags and they are (already before this PR) broken. I'll rework this PR

fixed :)


Render aBSREL results page and add some developer tooling

Closes #4 and #7
Loads a vision page with results from the HyPhy analysis (note: this was working more consistently before but has been having some issues where the vision page loads but doesn't have any data. This will be addressed in a future PR when other changes are made.)
Adds linting with ESLint using the airbnb style guide with a few rules turned from error to warning. We can adjust the .eslintrc.json to fit our needs as we go.
Also adds react developer tools. I'm not sure if there is a way to get the react developer tools functioning universally (I current'y have the path to my chrome extension hard coded into main.js)...

@stephenshank this is ready for your review. No rush.

These changes are all incorporated in #10 so I'm closing this for now. Feel free to re-open if you would rather review/merge these two PRs separately.


Indent guides extend beyond border when broken across pages and inset is smaller than row-gutter

For both algo and code, if the figure is broken across pages and inset is smaller than row-gutter, indent guides will extend beyond the element's borders.
// push element to bottom of page

#code(
  row-gutter: 15pt,
  inset: 3pt,
  indent-guides: 1pt + black,
  breakable: true,
)[
  ```py
  def floyd_warshall(G):
    # let G be an adjacency matrix
    dist = G

    for k in range(len(G)):
      for i in range(len(G)):
        for j in range(len(G)):
          if dist[i][j] > dist[i][k] + dist[k][j]:
            dist[i][j] = dist[i][k] + dist[k][j]

    return dist
  ```
]

The reason this issue occurs is that indent guides extend by row-gutter / 2 in both directions. However, when a block is broken across pages, the padding next to the pagebreak is determined by the block's inset.
This issue has an experimental solution in https://github.com/platformer/typst-algorithms/tree/tablex, but there are various bugs that prevent this branch from being merged.
This issue is pretty low priority since it's unlikely for a user to want to typeset breakable figures anyway. Though resolving this issue could make this package a viable option for typesetting entire programs with Typst.
Potentially related to https://github.com/typst/typst/issues/735.


chore!: rename leverage message types

Description
closes: #1101

Old Name
New Name

MsgWithdrawAsset
MsgWithdraw

MsgBorrowAsset
MsgBorrow

MsgRepayAsset
MsgRepay

MsgAddCollateral
MsgCollateralize

MsgRemoveCollateral
MsgDecollateralize

The associated grpc services are also renamed (e.g. WithdrawAsset -> Withdraw)
Note that MsgSupply and MsgLiquidate are unchanged in this PR.

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[x] included the correct type prefix in the PR title
[x] added ! to the type prefix if API or client breaking change
[x] added appropriate labels to the PR
[x] targeted the correct branch (see PR Targeting)
[x] provided a link to the relevant issue or specification
[x] added a changelog entry to CHANGELOG.md
[x] included comments for documenting Go code
[x] updated the relevant documentation or specification
[x] reviewed "Files changed" and left comments if necessary
[x] confirmed all CI checks have passed

Codecov Report

Merging #1122 (ae8e0e6) into main (c1a31c0) will not change coverage.
The diff coverage is 39.86%.

@@           Coverage Diff           @@
##             main    #1122   +/-   ##
=======================================
  Coverage   43.82%   43.82%
=======================================
  Files          65       65
  Lines        8393     8393
=======================================
  Hits         3678     3678
  Misses       4472     4472
  Partials      243      243

Impacted Files
Coverage Δ

x/leverage/client/cli/tx.go
0.00% <0.00%> (ø)

x/leverage/keeper/msg_server.go
0.84% <0.00%> (ø)

x/leverage/types/tx.go
0.00% <0.00%> (ø)

x/leverage/types/codec.go
41.93% <50.00%> (ø)

x/leverage/simulation/operations.go
92.66% <90.69%> (ø)

x/leverage/client/tests/tests.go
100.00% <100.00%> (ø)

x/leverage/keeper/keeper.go
43.92% <100.00%> (ø)

x/leverage/keeper/validate.go
51.61% <100.00%> (ø)


JavaScript

JavaScript
User Story
As a boot camp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
Acceptance Criteria
GIVEN a Prework study guide website
WHEN I visit the study guide
THEN I can see the four topics I learned listed along with a suggestion on what I should study first

All issues in the JavaScript file have been identified and updated in the Prework Study Guide application.


builder-jammy-tiny need support LANG environment

Describe the Enhancement

support environment
--env BPE_LC_ALL=en_US.utf8
--env BPE_LANG=en_US.utf8 \
Motivation

i have a springboot project,The configuration is as follows
bootBuildImage {
    imageName = "registry.cn-shanghai.aliyuncs.com/metafusion/rta-data-statistics:$version"
    builder = "paketobuildpacks/builder-jammy-tiny:latest"
    runImage = "paketobuildpacks/run-jammy-tiny:latest"
    environment.put("BP_JVM_VERSION","17")
    publish = true
    docker {
        host = "tcp://<IP_ADDRESS>:2375"
        tlsVerify = false
        publishRegistry {
            username = "***"
            password = "***"
            url = "***"
        }
    }
}

tiny image Unsupported utf8

The current documented behavior is to not set a locale, see https://paketo.io/docs/howto/configuration/#configuring-locale. It doesn't mean you can't set one, you just need to do it.
Having a default locale that's set in the image would be difficult because there's not one locale for everyone (that's kind of the purpose of a locale), so regardless of what we'd pick it's not going to be correct for some set of people. Not setting one provides some basic support through POSIX, but requires you to pick a locale that makes sense for you.

The problem is that the builder jammy tiny does not have a UTF-8 local


ArcRotate progressive restore state

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

Snapshot stored with reference name:
refs/pull/15248/merge
Test environment:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15248/merge/index.html
To test a playground add it to the URL, for example:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15248/merge/index.html#WGZLGJ#4600
Links to test babylon tools with this snapshot:
https://playground.babylonjs.com/?snapshot=refs/pull/15248/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/15248/merge
https://gui.babylonjs.com/?snapshot=refs/pull/15248/merge
https://nme.babylonjs.com/?snapshot=refs/pull/15248/merge
To test the snapshot in the playground with a playground ID add it after the snapshot query string:
https://playground.babylonjs.com/?snapshot=refs/pull/15248/merge#BCU1XR#0

Visualization tests for WebGPU (Experimental)
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15248/merge/testResults/webgpuplaywright/index.html

WebGL2 visualization test reporter:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/15248/merge/testResults/webgl2playwright/index.html


Doctrine metadata cache driver APC problem

Hi,
When I'm using doctrine metadata_cache_driver with APC, sometimes when I deploy to production my app kick me out and then when I try to login again it says me "User account is disabled". Sometimes I have to restart php two timer and hit apc cache clear many times until I can login again.
I change metadata cache driver to memcached and problem is solved.
Has someone this issue?
I'm using PHP 7 with APCu and opCache.

Try configuring your APC cache differently (may be a dynamic memmory problem).
Also it's supposed that if you restart php, apc cache is auto cleared. So after a php restart you have to get this issue fixed.

Closing as there's no activity in the thread (and the issue doesn't seem to be directly related with ODM)


Chart updates

How can i update every chart? And do updates work on Candlestick charts too?

https://apexcharts.com/docs/methods/#updateSeries
Yes, updateSeries() method works on candlestick charts too

https://apexcharts.com/docs/methods/#updateSeries
Yes, updateSeries() method works on candlestick charts too
chart.updateSeries([{
  data: [{
    x: new Date(2016, 01, 01),
    y: [51.98, 56.29, 51.59, 53.85]
  },
  {
    x: new Date(2016, 02, 01),
    y: [53.66, 54.99, 51.35, 52.95]
  }]
}])

Awesome, thank you!


Remove babel requirement for npm-vendor

Also fixes visdiff, which is currently breaking due to no babel-node installed.
:eyeglasses: @keybase/react-hackers

if the flow check passes 👍

👍


#705 add tags data to result of _get_points_for_series

This would change the behavior of get_points and will cause problems to people that have tags and fields with the same name.

@clslgrnc Yeah, i was mistaken. Thanks for your clarification!


Java Collection : LinkedList

Type
Collection
Directory
Collection => LinkedList => LinkedList.java
Description
Just declare the data structure, take the input dynamically, demonstrate some inbuilt methods.
Programming Language

[ ] java

Assign it to me Sir  i will do it in java.

Please assign it to me.

I can do in java

Can you please assign it to me? I can do it elegantly in java.

JAVA => 2 hours.


Why was this abandoned?

Yes, I wonder too. I am looking for something exactly like this. I will try using it but it feels a little worrying that the last commit was so long ago.

I didn't really work for me without minor adjustments. I'm trying to find the closest thing to https://www.servant.dev/ in TS.

Hey guys, thanks for the concerns. @joaomilho wondering what types of changes you had to make? Thanks!


Think about how to filter by audio across any lane

For example, Knut Hake wants to ONLY show audio clips that belong to a specific role. How would this work?

This will be addressed in the next beta.


softwrap not supported

Currently if you have soft-wrap active and set the language to "language-log", lines that exceeds the window are not wrapped.

I set this as default because I was under the impression most users do not want wrapping in log files. I was apparently wrong :smiley:. You can still set this either with the Editor: Toggle Soft Wrap command or through Settings -> Packages -> Language Log.
'.source.log':
  'editor':
    'softWrap': false

Great, that worked fine. Very nice.
Didn't mind the settings of a single package.


The accuracy on the dataset version-2

Hi, thanks for you amazing work.
I find you release an update dataset with only noncompound images. So can you tell us the accuracy on this new version-2? I think the accuracy reported in the your paper is evaluated on version-1?

For the model pre-trained on the version-2 dataset, the accuracy on the multiple-choice task is 0.587, and on the open-ended blanking task is 0.343.

I am gettting the"Caption" Keyerror when downloading the data from HuggingFace and running the PMC_VQA_dataset.py file. Can you provide the newer version of the dataset and how to download it.

For the model pre-trained on the version-2 dataset, the accuracy on the multiple-choice task is 0.587, and on the open-ended blanking task is 0.343.

Hi, could you tell us the model architecture details about these metrics like Table 3 in your paper?

For the model pre-trained on the version-2 dataset, the accuracy on the multiple-choice task is 0.587, and on the open-ended blanking task is 0.343.

Hey, this evaluation result is for  which model variant, the MedVInt-TE or  MedVInt-TD?


feat: adding flux executor

Signed-off-by: vsoch<EMAIL_ADDRESS>Description
This will add the Flux Executor to snakemake. Flux is a very programmatic job manager (maybe that's too limited a term) but it can be run in the context of HPC or cloud! I've written a containerized tutorial so reviewers can test it out. Also pinging @trws and @grondo to take a look.
@johanneskoester since this requires a new executor backend, let me know how you'd like to test. We do have a container so we could try a strategy that uses that.
QC

[x] The PR contains a test case for the changes or the changes are already covered by an existing test case.
[x] The documentation (docs/) is updated to reflect the changes or this is not necessary (e.g. if the change does neither modify the language nor the behavior or functionalities of Snakemake).

@johanneskoester since this requires a new executor backend, let me know how you'd like to test. We do have a container so we could try a strategy that uses that.

Would be nice to set up a flux instance in some github action before the actual snakemake tests.

I'm going to need the wisdom of the flux folks here - @grondo when you have time can you share what a flux start start.sh script might look like? @trws mentioned this could be something to try so it doesn't go into interactive mode! So far my GHA tricks to allow it haven't worked.

woooo @johanneskoester 38th time is the charm!! I got the flux workflow running in the test!! :partying_face:

Sorry for using all the CI cycles :laughing:

Nice!

So, @vsoch anything still missing here or is it ready for a final review?

Ping @grondo and @trws see above - is this ready or anything missing?

Sonarbot be like "stop pushing @vsoch I was already running your tests!"

I think Windows was a transient error - triggered a re-run to test that.

@johanneskoester I think this is ready to go, @trws said yesterday it looked good.

okay @jameshcorbett you were right that we don't need the import there - I'm not sure if it was something about the job formatted, but it's gone now so moving to the top works!
I also removed a huge chunk of code that we needed before futures (but no longer need). I've tested the updates locally and all is working.

oh no snakemake why you doing these random failures!! I'll try a re-run a bit later.

@johanneskoester we are updated and green!!!

Was there any progress with this? I still would like to get rid of this repetition of superclass code.

@johanneskoester I don't feel super strongly about this - if you just want it moved to the init I'd be happy to do that!

Oh wait, this was different:
    def format_job_exec(self, job):
        """
        We don't want a python -m to run.
        """
        prefix = self.get_job_exec_prefix(job)
        if prefix:
            prefix += " &&"
        suffix = self.get_job_exec_suffix(job)
        if suffix:
            suffix = f"&& {suffix}"
        return join_cli_args(
            [
                prefix,
                self.get_envvar_declarations(),
                "snakemake",
                format_cli_arg("--snakefile", self.get_snakefile()),
                self.get_job_args(job),
                self.general_args,
                suffix,
            ]
        )

I couldn't get this to work without this function because we can't be sure that the Flux Python is installed to the same python install as snakemake. With the way Flux is installed now, it's more likely to be installed to a system python (and the user will be using their own Python environment). If we do python -m then (from my testing) the job is going to fail. By just calling snakemake directly, we don't require the python where the flux is installed to be the same as where the snakemake binary is.
I tried to get this working the other way and failed multiple times.

I don't really get this. So there is the flux python bindings, which apparently you can install in the same env as snakemake (and have to, since otherwise your executor code would not even work). But the job which is executed by flux, is just called from the environment where flux itself (like their core system, whatever) is installed into? And there is no way to tell flux about the execution env the job shall run in? Or configure that somehow?

The only way I could get this to work (in the CI and the container) is to install snakemake to the same python as flux, having them separate never worked. I'll prepare you an example that shows the error (or proves me wrong and it works) and then maybe you can make a suggestion as to what to try next.

So, is the problem indeed just the test setup with the container? Then, we could probably just install flux into the github actions, thereby more closely mimicking a real setup?

I've never tried this, but I'd advocate to use the container so 1. a user can reproduce, and 2. we can always be sure to use the latest flux container provided (and not fall out of sync / require updating two things).
More ideally we'd have a GitHub action that installs flux (akin to the container) but I haven't made that yet.

I think this might be an issue with the Python install - let me test something out and see if it resolves the issue - I forgot that these containers have python3 (but not python). Be back in a bit!

Okay just pushed a change without it - I think the underlying issue was not having python exposed (and I didn't interpret the error message correctly the first time). I'm also thinking it would be hugely useful to have native flux install actions - going to work on that soon in case we want to use here instead of the container!

Thanks @johanneskoester ! And apologies if the docs aren't clear - it's good feedback indeed.

Not that I know of, if it covers what snakemake needs I'm good.


Allow SSL TSI to recognize URI and email SAN fields in X.509 certificates

URI recognition is needed for SPIFFE support and email address recognition is requested from community (https://github.com/grpc/grpc/issues/15700).

I haven't had a look yet at the details but we need a test for that, don't we?

+1 adding a test is very reasonable.

Thanks Julien and Jiangtao for the quick review.  I added a unit test to validate the change.

https://github.com/grpc/grpc/issues/19726
https://github.com/grpc/grpc/issues/19170
https://github.com/grpc/grpc/issues/19819
https://github.com/grpc/grpc/issues/15245


Update members.adoc

I'm keeping an eye on FAPI for work, but my company did not give me official mandate to answer in their behalf (I work for a major retailer using RedHat SSO with millions of users, daily connecting). Going in as Independant if you do agree.

Welcome, @gilbert-fernandes !


two level adding element not working

adding two level element dynamically is not showing.
here is plunker
http://plnkr.co/edit/7WUcBhOm0SvTEVprVP91?p=preview

I'm getting this message in the console:
Imported resource from origin 'http://element-party.xyz' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://run.plnkr.co' is therefore not allowed access. The response had HTTP status code 404

I don't think your demo is going to work due to Cross Origin rules on plunkr.

yes. Sorry I don;t know how I  tested earlier on plunker. But I don;t see to run it locally. Issue still persist for two level addition.


Progress4 storage tracker

This pull request didn't trigger Jenkins as its author isn't in the whitelist.
An organization member must perform one of the following:

To have this branch tested by Jenkins, use the "ok to test" command.
To have a one time test done, use the "test this please" command.

Those commands are simple Github comments of the format: "jenkins: COMMAND"

@joelhockey, this branch needs a rebase. :)

jenkins: test this please

@brauner I've been dealing with the rebases for those branches as I merge the previous one

@stgraber, cool!

@joelhockey hmm, you just broke the branch with that force push as you didn't rebase on master before doing that. I'll fix it again for you.

jenkins: test this please

Sorry, I thought I did rebase from upstream/master, but I'm not very experienced with github.

The relevant functions are ContainerCreateFromImage and ImageCreate.  I created https://github.com/lxc/lxd/pull/5461 to show what it looks like.
I chose this approach first since I thought adding the setter field on Storage interface might be better than changing the existing API.  I think either approach is fine.
I guess longer term, you either expect that many of the Storage functions will get a ProgressTracker added to them, or the idiom is that callers set a tracker onto storage prior to calling it, which does have the potential for it to be overridden.


[Question] Best practice to change the default color for button, text, focus status, etc.

I want to know what is the best practice in materializecss to change all widget default color(light green).
Do I need to put some css to my custom.css like below, or there is some better and simple way?
.btn, .btn-large {
color: xxx;
background-color: xxx;
}
xxx:focus{}
...
Want your ways to change the default ones.
Thanks.

Use Sass and it will be easy
On Jan 13, 2016 7:43 AM, "Yole"<EMAIL_ADDRESS>wrote:

I want to know what is the best practice in materializecss to change all
widget default color(light green)
Do I need to put some css to my customcss like below, or there is some
better and simple way?
btn, btn-large {
color: xxx;
background-color: xxx;
}
xxx:focus{}
Want your ways to change the default ones
Thanks
—
Reply to this email directly or view it on GitHub
https://github.com/Dogfalo/materialize/issues/2648.

I will be nice if materialize have some mechanism can change the default color.

Yea, if you use Sass you can change the primary color
On Wed, Jan 13, 2016 at 5:58 PM, Yole<EMAIL_ADDRESS>wrote:

I will be nice if materialize have some mechanism can change the default
color.
—
Reply to this email directly or view it on GitHub
https://github.com/Dogfalo/materialize/issues/2648#issuecomment-171500300
.

--
Doggy sends his greetings from Mars.

Does anyone know what does the below meta used for. Did not find the usage in docs.

It's hard to change chrome Tab color

FOR FOLKS LOOKING FOR THE SOLUTION:
Download the sass files - in components/_variables.scss you'll find the default colors around line 40. You can change these colors and compile your sass into css or whatever fits your project's needs and be good to go.

fwiw, I appreciated how MDL did it by simply producing all the color combinations from the color wheel into separate css files for download (see the Color Palette section of https://getmdl.io/styles/index.html).
It kept me from having to build out the CSS myself but I understand it should be easy to set something up to have sass build out those files and include them in our project.
Do you think it would be out of the question for contributors on this project to consider integrating a similar process into the existing build?  I'd love to migrate over to materialize but this is one slight barrier for me at this time.

Alternatively, you can use their color names and insert them directly into the class of the widget, like so:
class="btn waves-effect waves-light cyan darken-2"


The farmer's job doesn't work.

Sponge Version:  spongeforge-1.12.2-2838-7.3.0.jar
Forge Version:  spongeforge-1.12.2-2838-7.3.0.jar
Total Economy Version:  Latest
When a player collects, for example, carrots or potatoes that were planted in the base world, he does receive the money. But if that player or another player plants carrots and legs and picks them up later, they get nothing.

Are you getting any error messages in the console?

No. I'm going to try to explain myself as best I can.
When someone mines an ore he receives the money and the experience, but if he chops that ore with silk touch and then places it in the world and tries to mine it again, he receives nothing. That's fine.
But if someone breaks carrots, potatoes, etc., which were not based in the world, he does not receive anything. And that should not be so, because then the farmer's work is useless.

Bonjour j'ai aussi le même problème avec ce job de fermier malheureusement. Je n'ai aucun message d'erreur de la console.
Il se pourrait que cela vienne de notre version de forge ou de sponge car nous utilisons les mêmes versions...


Migrate from bintray to Maven Central

Migrate from Bintray to Maven central

Add gpg sign plugin
Sign artifacts during release (achieved by before-deploy.sh and deploy.sh)
Fix javadoc in Element.java and ElementType.java to replace deprecated  to

I confirm that this contribution is made under the terms of the license found in the root directory of this repository's source tree and that I have the authority necessary to make this contribution on behalf of its copyright owner.

@lafa please review


Even more prop fixes

🤔 What type of PR is this? (check all applicable)

[ ] 🍕 Addition
[ ] ⌨ Productivity
[x] 🐛 Bug Fix
[ ] 🔥 Optimization
[ ] ⚙ Configuration
[x] 🌟 Quality Of Life
[ ] ✨ Enhancement
[ ] 📝 Documentation

📝 Description
Fixes the hitboxes for

Hanging Body
Office Chair
Office Chair 2
Home Chair
White Desk Middle

🧐 The Rationale
See other pr's
🎯 Key Objectives
Fix the props
⏮ Backwards Compatibility
1.12.2
📚 Related Issues & Documents
N/a
🖼 Screenshots/Recordings
N/A
📖 Added to documentation?

[ ] 📜 README.md
[ ] 📓 Javadoc
[ ] 🍕 Comments
[x] 🙅 no documentation needed

Note: The Duel Flood lights hitbox has been modified again to be more exact. Its already in the change log.


Feature/update structural tests

Checklist

[x] I tested the changes and all related features on the test server https://artemistest.ase.in.tum.de.
[x] I documented my source code using the JavaDoc / JSDoc style.

Motivation and Context
Programming Exercises in Java: Improve the structural tests by allowing to define annotations in the test.json structural oracle.
Improve the oracle generator:

Add the detection of annotation changes
Take more properties of attributes, methods and constructors into account when comparing template and solution files to detect more changes.

Description
I updated the structural tests and the test.json generator.
Steps for Testing

Log in to Artemis
Navigate to Course Administration and into a Test Course
Create a new programming exercise with Java as programming language
Add some annotations into the solution repository for a class, attribute, method and/or constructor (make sure that the retention policy of the annotation is runtime: the easiest is to define your own custom annotation)
Commit and push the changes into the solution repository
Navigate into the programming exercise detail page, e.g. course/10/programming-exercise/660/view
Click on Update Structure Test Oracle. This takes a few seconds and should then automatically trigger a commit + push in the test repo (Look for a green or red alert at the top of the page.)
Check if the annotations are recognized correctly in the changes in the test repos test.json file (in the new commit)
Check if the template build (0%) and solution build (100%) are still as desired
Delete the programming exercise with all participations after finishing the test

This PR is ready to merge. Would be great if @thilo-behnke and @ungaralex could have a look and approve this today so that we can merge it before the release tomorrow. Thank you!

This PR is ready to merge. Would be great if @thilo-behnke and @ungaralex could have a look and approve this today so that we can merge it before the release tomorrow. Thank you!

I will check it today and give feedback.


[Question] multiple gpu seting: Check failed num_running_rsentries <= engine_config_->max_num_sequence (81 vs. 80) :

setting
server command: mlc_llm serve mlc-llama2-7b-q4 --overrides "tensor_parallel_shards=2" --mode server
requst: request rate is 20 request/s
gpu: a40
❓ General Questions
10 request/s is ok,  20 request/s rate  had the  problem below, can change some param setting make 20 request/s rate  improve performance?

tvm.error.InternalError: Traceback (most recent call last):
4: mlc::llm::serve::ThreadedEngineImpl::RunBackgroundLoop()
at /workspace/mlc-llm/cpp/serve/threaded_engine.cc:182
3: mlc::llm::serve::EngineImpl::Step()
at /workspace/mlc-llm/cpp/serve/engine.cc:619
2: mlc::llm::serve::NewRequestPrefillActionObj::Step(mlc::llm::serve::EngineState)
at /workspace/mlc-llm/cpp/serve/engine_actions/new_request_prefill.cc:35
1: mlc::llm::serve::BatchPrefillBaseActionObj::GetRequestStateEntriesToPrefill(mlc::llm::serve::EngineState)
at /workspace/mlc-llm/cpp/serve/engine_actions/batch_prefill_base.cc:107
0: mlc::llm::serve::BatchPrefillBaseActionObj::CanPrefill(mlc::llm::serve::EngineState, int, int, int, int, int, int, mlc::llm::KVStateKind, bool)
at /workspace/mlc-llm/cpp/serve/engine_actions/batch_prefill_base.cc:216
File "/workspace/mlc-llm/cpp/serve/engine_actions/batch_prefill_base.cc", line 216
InternalError: Check failed: num_running_rsentries <= engine_config_->max_num_sequence (81 vs. 80) :

Thank you @aaronlyt for reporting. We will look into this issue.

This issue is likely fixed previously. Gonna close this issue first. You're more than welcome to open new issues if the problem persists. Thanks!


Add dry run parameter to flow run and deploy

@rudyardrichter is this PR ready for review (in spite of the merge conflict)?

@jimPruyne it is now, yes

@rudyardrichter can you take care of the merge conflict? I think my only other ask is that the dry-run help options on the CLI have their text updated with more info on what the dry-run is doing.

@rudyardrichter @urimandujano I went ahead and attempted a fix for the merge conflicts here. But, I haven't tested or anything. So, it is at least worth a re-review of the code and possibly a checkout and test to make sure things work as expected.

@rudyardrichter @urimandujano Anything still waiting on this PR?

@rudyardrichter @urimandujano One more bump on this so we could get it off the CH board. Seems a conflict has arisen in the meantime...


Improved installation instructions

This PR refines the installation instructions with more intermediate steps. I believe that I am a good test case for this.
Unfortunately, there is still a tiny bit missing at the end. With these instructions, everything seems to work (catkin build succeeds), but something with Android Studio / gradle is not yet right. Nevertheless, I guess that these instructions are already a better starting point.
If somebody has suggestions, this is the error I'm seeing:

I think I have a clue about your error @juergensturm . Were you able to generate the apk file? As #152 is still not merged, catkin build won't generate it, so you will still need to build it using gradlew build or Android Studio's tools. Probably you won't be able to do so as long as this error persists.
Take a look at #163, that should fix it.

@jubeira Thanks, this fixed it!

@jubeira @adamantivm PTAL, I addressed your comments.


Make header title link inline

Fixes #2665
Sometimes users want to select a visualization and they open it instead because the whole red area (where the title is placed) is clickable:

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

@CartoDB/frontend: can you review this fix, please?

retest this, please

Frontend tests were OK :+1: (details)

Have you checked "affected-visualizations" items as well?

Frontend tests were OK :+1: (details)

@xavijam: you mean the links in the dialog that appears when you delete a dataset. Yes, this works there too.

Frontend tests were OK :+1: (details)

Frontend tests were OK :+1: (details)

I just came across this same issue:

@javierarce I think it's not fixed yet.

Oh, I just realized you reverted the fix...

You're totally right. It was reverted because I merged when they were making the onpremise build and then I forgot about it. I'll deploy it next monday.


Post Install script causing error

When installing the package as a dependency, the post install script runs trying to build ts files.

Fixed in #102a9bce


⚠ Bofrost.lu has degraded performance

In aa51845, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 2523 ms

Resolved: Bofrost.lu performance has improved in d966ae8 after 20 minutes.