traverse directories for project.toml

So @Irev-Dev talked about this but say you have a project dir with subdirectories like kcl-samples, you’d want that to be one project with many sub directories, so instead of setting the units based on just the top level directory we should set the units based on the one closest to the file and then traverse backwards to parents.
this is currently how the cli works and this works really well.
this also means I’d say you clone someone else files into yours in a subdirectory it would work for whatever project.toml they pushed to git
so this is like a huge win.
the other thing is and I can open a separate issue but we should split units setting out of project.toml and because you want to commit your units to git but you don’t wanna commit your theme etc. so we need two files.
When we get to imports and people sharing modules, it makes sense that modules can be unitless (nothing committed for units in the project.toml), so they will default back to the user importing the files base unit.
In this case where you export a unitless bit of configurable geometry (takes input dimensions to update the geometry), but you still need to guarantee the size of some parts of it, for example something that needs to mount on DIN rail, this is when you'll use the mm()/inch() functions. i.e. strategically opting into units for sections of the model.

Also just to note i think we should do https://github.com/KittyCAD/modeling-app/issues/3961 BEFORE we implement this issue, because we dont want all settings to change we literally only care about the ones in git, which currently are units :)

otherwise your theme could change in sub dirs and that seems like unnessary complexity and who the fuck even wants that, idk supporting that seems like insanity since we already have so many bugs with the theme changing and looking weird, so please dont do that until at least all the other bugs with weird theme thigns are fixed, if you absolutely want to, but i wouldnt do it at all

I think @franknoirot removed per-project theming.  It's all user-level themeing now.

I think we should be careful not add anything that could be considered a "preference" to the project.toml in future, units are needed for the model, theme is not haha.

Yeah 100% agree @Irev-Dev. I actually don't think we need any project-level preferences (other than possibly themeColor if we think that's worth it), and the only project-level (or dir-level) setting we need is units.

But I think we don't need even that if we implement proper unit types in KCL.
Currently, KCL files cannot fully define concrete geometry on their own. They represent abstract, unit-less geometry until either a unit standard library function (like mm()) is applied or an external unit setting is read in.
The fact that our standard library functions take raw number expressions is an implicit external dependency that makes any KCL file not properly stand on its own. This is exemplified by issues like this one, where generated text-to-cad KCL was only correct if it was accompanied by an external unit setting.
If types are a part of the KCL syntax, and therefore the default unit setting was just that, what unit gets written by default when using the UI, then the following becomes true:

we don't need any project-level settings at all, and therefor don't need to handle any kind of settings hierarchy
it becomes impossible to receive KCL code that breaks due to mismatched or missing settings
what is implicit today when you change the "default unit" setting can be made into a safe, explicit command to convert all the units in your file from one unit to another
we can provide UX to convert an expression of any unit to any other unit, in the code editor and elsewhere

I dont think it should be required, thats a huge burden in a file where most files are the same unit and we should push people to most files being the same units. I consider this the equivalent of the other unit functions we have which i think i should have made less easy to use because we don't want people uysing them.
Anyways my negatives are:

most files use the same units everywhere, this is a huge burden for that
it opens the door for the anti-pattern of mixing units, its a huge context burden to read code with mixed units and actually understand
we want to make mixing units hard since its a bad pattern, this makes it way too easy

i personally loive that the car wheel example breaks when the units are off, BECAUSE WE WANT TO FORCE people to not mix units, because if you dont it scales well and you get so many wins. I don't want to make mixing units easier. It is a terrible pattern and no one will ever use code cad if the file is unreadable.

also for libraries we will want "unitless" consider jordans letter library or the zoo logo, those would be unit less and that would work out of the box today!
PLUS for libraries like a car wheel, you could use the unit functions we have today to even make that unitless, anyways I am pro the paradigms we set up for today because they work great with the future paradigms as well

anyways I do not want to optimize for the anti-pattern, we need to stop feeling bad about the anti-pattern kinda sucking, BECAUSE IT SHOULD

most files use the same units everywhere, this is a huge burden for that
Is the huge burden having .in specified after each raw number? That doesn't seem like a huge burden, maybe I'm missing something.

we want to make mixing units hard since its a bad pattern, this makes it way too easy
Mixed unit parts are incredibly common though; even the category of adapter pipe fittings is massive. In shops that build assemblies, for example, it's really common to have the screw holes in whatever your locality is, but then the important dimensions in whatever your customer's dimensions are. We'd be expecting machine shops with access to metric hardware building for imperial to buy imperial

yes but if you mix units, its not that we don't support it today, it just takes more effort, which it should since we don't want people doing it unless super necessary

.in is three more characters to type EVERY TIME YOU WRITE SOMETHING thats insane to me

I don't think mixed units is an anti-pattern, it's a fact of life. There are many many parts that are built in the world and will that use different unit systems. That must be where I'm misunderstanding.

lets let @JordanNoone and @jgomez720 and @nicboone8 chime in but im super anti doing this
even just the context it takes the read the code has an overhead because usually I can look at code and grok it, but like now im like fuck are the units just going to switch somewhere, like i feel like the other is more readable but maybe im just biased

c makes no sense and is unreadable, yes you need more characters to understand shit sometimes

c makes no sense and is unreadable, yes you need more characters to understand shit sometimes

Yeah it's an extreme example, but I read angledLine({ length: 2, angle: 30 }) and think "2 of WHAT"?

yes but if you mix units, its not that we don't support it today, it just takes more effort, which it should since we don't want people doing it unless super necessary

I feel like you're not thinking big enough. What I hear you actually saying is that you don't want to degrade the experience when you're only using one kind of unit. I think we can do both.
By adding explicit units, we make the "difficult" case of mixed units easy because the language and tools can help you by providing better error messages (for when you use an angle when a function expects a length) or even automatically converting between inches and millimeters when appropriate.
Have you ever used uom for dealing with measurements in Rust? Compile time checking of units. It's amazing. So hard to go back once you've experienced them.
On the other hand, if everything is unspecified, the tool can't understand what anyone means and can't provide assistance.

everything is not unspecified tho, we literally know the units from the units file, and we use that at executor time, i guess you are saying to have it at parse time but im unsure what we gain from that since we do both at the same time in the app / cli anyways

I think this all comes down to what the MEs want tbh, if I was an ME i wouldnt want to type three extra characters everytime and have the mental overhead of reading files with units, but thats just me

Yeah totally fair, and I see your point. I don't want to optimize for the typing experience first, and I would weight having units of measure be absolutely explicit in one file over the increase in typing friction. I think it has huge implications for code generation.

heres another idea too, because I dont want to discount your assemblies have multiple units, yes they do , maybe you import something from mcmaster or whatever, BUT individual parts do not
so take the wheel thats actually an assembly, but if the lugs etc where seperate parts it would not be mixed units UNTIL the assembly file
you see where im going so THIS better supports the whole traverse directories thing. or per-file units. WHERE per-file YOU really DONT want to be mixing units UNLESS its an assembly. in which case yes mayeb in assemby files we make it easier to mix units BUT do you even need that... if they are all sepoerate parts with their own units being imported jsut being mated together?

to even your make the holes in inches to support the inches lugs if you import a varaibel from a file that is inches it would still be inches, so you COULD do that it would work out of the box with the directory stucture and be invisible to the whole units inlined thing, then when you open a file you dont have this awful context switching of units in the file, you are in one unit that entire time, i like not having that mental burden ya know, like oh i open the lug im in inches

having import would really make it easier to test all these thoeries 😇 i would like to say lets not close this discussion but let us instead wait until we have import so we can experiment and really see the workflow here, does that work, because i get your points, i do, i just want to make sure adding the mental overhead / typing overhead to every file IS A ABSOLUTE MUST first

BUT do you even need that... if they are all sepoerate parts with their own units being imported jsut being mated together?

Oh yeah with my "screws in metric, length in imperial" example, that would probably be covered by what you're talking about for the most part, like the screw files would be all-metric, but the diameter of those holes would be metric too (in this story they have access to metric hardware like screws and drill bits, I'm borrowing from this guy's video, but need a part that has critical dimensions), even if the whole outer dimensions of the assembly are in imperial

if you import a variable from a file that is inches it would still be inches

...regardless of the setting of the user who opened it. I think this point is crucial.

right but the diameter of the holes could be imported from the "imperial file" into a metric file AND IT WOULD WORK thats the coolness of it

exactly @jtran
now i really want import to mess around, but yeah maybe we end up realizing thats shit, listen im not always right, but its worth not doing a hiuge overhaul until we know it sucks

i like not having that mental burden ya know, like oh i open the lug im in inches

Yeah this is totally fine, and I think having a default unit setting and doing the change outlined in this issue is actually not mutually exclusive with having explicit units always in the file. I spoke too soon earlier, apologies. You could enforce the default unit on a per-directory level with these settings, which would simply dictate what the default selected unit would be when users go to perform actions in that directory, and have the file contain explicit units.

dont apologize i like the discussion it made me see a lot of things  and it makes us more aware going into import / assemblies on how to make it good and problems that might occur

So this traversal effort would still be fruitful. I just don't think it should be done to work around the fact that our geometry-producing standard library functions can take raw numerical values, forcing us to use an external setting to make the geometry concrete.

yeah also just to reiterate def push back on work if you see it going nowhere, so im glad you spoke up

okay also what would be really cool is if in the assembly files or just anytime you import a variable from somewhere when you hover over it, it told you the units, that would be dope and we could def do something like that in the lsp w the data

I realized that my face is blocking the dimensions in SketchUp. But sketching is asking for things like
2'36", 30", 2.32m with every single dimension. I used SketchUp professional with Spatial for about a year and did not like it.
https://github.com/user-attachments/assets/31609634-55e0-41ed-be68-b16c9c76c184

@jgomez720 I'm talking about requiring units in the KCL code, not in the command palette input or any other UI. Your settings would merely choose what units in this dropdown I show in the video gets selected by default. The KCL code generated by the extrude command would require a unit value, but your expression input in the UI would not.
Uploading Screenshare - 2024-09-27 5_27_56 PM-compressed.mp4…

Yeah my point was more that typing in the .in or .mm would get annoying to me after a while. So this

I think this all comes down to what the MEs want tbh, if I was an ME i wouldnt want to type three extra characters everytime and have the mental overhead of reading files with units everywhere, but thats just me

is what I agree with. I'm pretty confident that people are not going to want to add the units to every single dimension. I have a habit of writing my units on constants like so:

// Define constants
const mountingHoleDia = .625 // inches
const baseDia = 4.625 // inches
const pipeDia = 1.25 // inches
const thickness = .625 // inches
const totalThickness = 0.813 // inches
const topTotalDiameter = 2.313 // inches
const bottomThickness = 0.06 // inches
const bottomTotalDiameter = 2.5 // inches
const mountingHolePlacementDiameter = 3.5 // inches
const baseThickness = .625 // inches
const topTotalThickness = totalThickness - (bottomThickness+baseThickness) // inches
const holeLocator = baseDia - 8
const nHoles = 4

and some people would even think that is too much, let alone every number in the file.
The UI stuff you showed is tight btw

Totally hear that, but I really think we should have the KCL be the source of truth rather than leave it up to chance. As it stands today, your comments should really say this:
const mountingHoleDia = .625 // inches, hopefully

And when something like text-to-kcl starts consuming that code and producing kcl without a settings.toml associated with it, you get the car-wheel problem. Every tool that uses kcl will need to also understand settings.toml

The Text-to-KCL point is really good, because giving the user a toml file too would be difficult.
This was something I did wayyyyyyy back in the day, but maybe this crazy idea actually might be worth looking at? Where we have definitions within the KCL file itself. Forgive my psuedocode, I have no idea what to use for these definitions like units or material
// Bracket

!units = "in"
!material = "aluminum-6061"

// Define constants
const sigmaAllow = 35000 // psi
const width = 6
const p = 300 // lbs
const factorOfSafety = 1.2 // unitless
const shelfMountL = 5
const wallMountL = 2

A point that is also worth discussing is non-dimenions units and non-length units. What do we do with sigmaAllow, p, and factorOfSafety in the above example?

I still want to pull away from writing the units on every single number. I really don't think people are going to like that. And in other units, are we expecting them to write const sigmaAllow = 35000.psi ?

I still want to pull away from writing the units on every single number. I really don't think people are going to like that. And in other units, are we expecting them to write const sigmaAllow = 35000.psi ?

Yes. This becomes even more critical when we support other types of units. Imagine your safety checks being wrong because of some other external file!
Numbers would still be valid in this system, so your factor of safety constant would remain just a number, and could be used in expressions that resolve to a dimension.

I've read over everything and this is what I'm seeing as meeting all the above criteria.

We will always need implicit or "world" / "global" units.
We need a way to transfer these implicit units across individual KCL files.
We need a way to specify units at the source code level.
We need a way to specify units at the project level.

Why do we need all these ways? Convenience, in my opinion based on what I've read.

It has been explicitly stated writing the unit on every number is undesirable / tiring.
It has been explicitly stated it reads as noisier.

There is of course familiarity at play here too.

To reiterate, we can easily characterize our needs with:
"We need to be able to set units at directory, file, and content levels".

What do we need to achieve this?
Well we already have solutions (or partial solutions) to directory and content level units.
We have no solution for file level units. We need a way to put this information there. @jgomez720 has already shown a prototypical example.
So the reality is we are not far from where we want to be. A little re-org needs to happen on those 2 other levels (directory traversal and built-in KCL units as part of the syntax and not functions), and the file level needs a configuration thing.

This example code from above:
// Define constants
const mountingHoleDia = .625 // inches
const baseDia = 4.625 // inches
const pipeDia = 1.25 // inches
const thickness = .625 // inches
const totalThickness = 0.813 // inches
const topTotalDiameter = 2.313 // inches
const bottomThickness = 0.06 // inches
const bottomTotalDiameter = 2.5 // inches
const mountingHolePlacementDiameter = 3.5 // inches
const baseThickness = .625 // inches
const topTotalThickness = totalThickness - (bottomThickness+baseThickness) // inches
const holeLocator = baseDia - 8
const nHoles = 4

...screams out at me that units on every value are so useful that you would go to the trouble to write them in comments, even though the language completely ignores them. Imagine if the tool could actually read all the information in those comments and assist you in your work.
What Frank is trying to say is that we can come up with ways to make it implicit, definitely in the point and click UI, but potentially in the KCL as well. I've definitely thought about a file-level pragma that sets the preferred units. But it gets a bit more complicated if you want to deal with angles, pressure, percentages, etc.
I think we can do unit inference (the same way that type inference is done) so that they can be omitted in many places, and the information is seamlessly reconstructed. But we have to be careful in how we design it. If it's too implicit, it can't be meaningfully inferred.
I really think that this is one of those knee-jerk reactions because you're not familiar with it. But if you've ever actually used it, you'd wonder how anyone gets anything done with measurements without native support.

Units should be defined locally per file. There are times you would mix parts with different units in the same assembly. This should be a config setting, +1 to what @jgomez720 wrote above.
!units = "in"
!material = "aluminum-6061"
or similar
For me personally I would ideally want to start every file with
import jordan's_config_defaults
Then override as necessary. In the future this would be for units, tolerances, manufacturing settings (such as for a GLTF slicer, etc...).
I don't know what is the project.TOML, I don't know what is supposed to be in the project.TOML, I don't know how I'm supposed to know what is supposed to be in the project.TOML, I've never opened it, nor have I ever rev controlled it alongside side the rest of my KCL files that are in github. Before reading this I've been tempted to add it to my .gitignore. If we do use it for something, it needs to be obvious what to the user.
At this time I don't have a preference on individual lines having units as \ comments or as some sort of smart units object. If there is one better for Text-to-CAD training, I'd bias towards that.
I elaborate a bit below on "smart units" but I do think this is way out of scope now if not forever as it's a ton of complexity.
The extensibility of a "smart units objects" could be very advantageous to help guarantee the writer keeps unit/dimension consistency between sizing hand calcs. As an example, if they are adding lengths of dissimilar units, that perhaps the output is in the default unit (or some more well thought out behavior), perhaps to errors, perhaps it flags a warning.
Lots of the annoyance in writing code that sizes engineering features is unit consistency. Analysts will often convert ALL inputs to kg-m-s (kilogram, meter, second) units because they have the best dimensional consistency in units. This is done even if all inputs/outputs need to be in pounds, feet, inches, etc... For example this avoids the "random" *32.2 or /32.2 conversions that show up when dealing with ft-lb-s (feet, pound mass, second) units. There is the common joke/meme/confusion about the slug unit, which is part of the root of the 32.2 factor showing up (https://www.reddit.com/r/EngineeringStudents/comments/j8wl4g/still_have_no_clue_what_a_slug_is_tho/). It's not actually "random", but it often feels that way.

def dont over-rotate on text-to-cad needing per number units, it doesnt, it could tell us the units per file, and we could generate the settings for it. and we need multi-file text-to-cad for assemblies anyways, so i wouldnt do something just for text-to-cad if its the wrong paradigm for the app. In jordans example above i would consider what he wants the new and improved git pushable config.toml or whatever we decide upon and we can educate the user its just a key value store of their preferences, and they can change it per directory or whatever heirarchy they want. we will take the defaults from the closest we find, and traverse upwards
such that
/my/dir/file/thing.kcl
/my/dir/file/other.kcl
/my/dir/file/config.toml
thing.kcl and other.kcl uses config.toml
/my/dir/file/thing.kcl
/my/dir/file/other.kcl
/my/dir/file/config.toml
/my/dir/file/nested/main.kcl
main.kcl uses the parents config.toml since there is none in that dir
etc etc
anyways, this is a paradigm that most programming languages also use and thats why its my preference, but we will see when we get imports and mess around with files where yiou are importing things from different units just how bad or good it is
just lets not design weird paradigms for a user just because we think text-to-cad needs it, text-to-cad can understand multuple files and it can understand per-unit files.
i personally REALLY like not having the cognitive overload of changing units IN A SINGLE part, in an assembly thats different but we can integrate into the lsp on hover stuff like imported variables units and lessen the cognitive load. just my preference.

i'd also argue the file does not need units in it, if you can just move it to a nested dir with a different config. for simpliciy sake i say we start there, and see our limitations before we over complicate matters. this is already working great for kcl-samples.

once we add something we can never remove it, we can never get the time back etc etc so im just trying to keep this iterative, try it out, find limitations go from there

(Trying my best to make everyone here equally mad at me)
Managing multiple unit types within the same part is important, and it's going to keep coming up as we gain more and more users. Not just within the same assembly.
Having to go in and manually type *mm(), *in(), etc, to declare that a dimension differs from the base unit is a fair punishment for choosing to mix units. Having to type them in for every single number is tedious - even if it's done in smart ways through the UX there would still be instances where you have to go back in the code and change things, which could be annoying if there's a bunch of units everywhere. Maybe the unit inference scheme solves this
Josh's example of base units and other part properties living in the first lines of the kcl script is what makes the most sense to me. A decent number of MEs are going to have a difficult time dealing with multiple file types for one part. And people are always going to try and just copy and paste kcl from god knows where. Josh's idea avoids every version of the car wheel problem

I just want to say if we embed units and other config values in the top of the file I feel VERY STRONGLY it needs to be the same data structure as the config file itself.
this will help with maintainability, it uses the same config file parsing logic and passing said structure to the executor would be the same
if we add more values to the config file this would work both places without any need for custom code
it’s only one config file syntax people need to learn
not doing this would over complicate what the user needs to learn and our code, and adding a new config value each time should not be some one off parsing logic behavior it should just reuse the config parsing we already have.

I feel VERY STRONGLY it needs to be the same data structure as the config file itself.

Are you suggesting one of the two? If not, well, my imagination doesn't extend far enough for this one...

TOML inside KCL files?
A single KCL object is exported from a .kcl file and imported into other files?... (KCLO? KSON? lol.) Does the imported KCL object need to be assigned to a special global?

Which looks a lot like how rust is proposing it as well.

This https://internals.rust-lang.org/t/pre-rfc-cargo-script-for-everyone/18639

What a great resource! I will read through it all and report back. It is hard to image embedding TOML in a comment at the beginning of source files is an acceptable solution as it goes directly against Rust's ethos of being robust...

20 minutes later spongebob french narrator voice

Ok. The motivation seems to be there is no choice that it is TOML. Since all prior cargo data is TOML, there is no choice other than TOML to be embedded.
Additionally they are proposing a separate file extension, something like .rss, for "Rust script source". It is intended to be a self-contained Rust project pretty much. For us that's a problem. We want KCL to be usable with other KCL even with their own environment settings.

It kind of looks like that proposal was abandoned. https://github.com/epage/cargo-script-mvs/compare/1bf0dfec25b7543d03ab53765b39c1a40d2f32ef...main
Both the discussion and commits have stopped 2 years ago.

All in all it's hard for me to conclude if we want to execute on the idea of mixing languages (not that it matters since it's not my decision to make). It feels wrong when we have a choice right now to use KCL native data structures to express environment information. The Cargo crowd doesn't. I'm not really convinced by what I've just taken in... We don't have the same problems to deal with.

What I would love is to ask Ed Page what he thinks about our situation :) Seems like an absolute pro in this space, as they are the maintainers of winnow, toml and all the cargo stuff.
<EMAIL_ADDRESS>@orenpage

I'm super duper convinced we should focus on import like immediately after whatever language developments are going on right now.

Okay I have thought about this at length and I changed my mind, I'll explain.
TLDR; I am now PRO per-file units (& other git-pushable config settings) under the condition THERE IS NO OTHER WAY TO SET THEM
So basically my fear with per-file units was people are all just going to use that, between our samples, text-to-cad, etc theyd just use that and they'd be pervasive and no one would use any other setting, the other settings wouldnt work well since no one uses them and its be this weird code path we rarely hit and be shit. Well so then its like lets just get rid of every other setting and just make it per file or not at all.
 2.
Minor preference for using a KCL object, like @lf94 suggested. The GUI will write it, so most users won't care. But it has lots of other benefits.

Is it worth supporting unitless kcl files, vs just defaulting everything unspecified to mm? Setting a part to unitless and working with it would feel weird to me, but I'm not opposed to having that functionality if it makes it easier for things like import/export


Frontend : Create Html_Accessibility.md

Description 📜
In this commit I have created Html_Accessibility file which contain full detail explanation of topic accessibility in this i cover all the topic which this topic can contain and i also give code snippets and examples that explain the text in great detail.
Issue no. Closed : #2820

Type of change 📝

[x] Documentation (Content Creation in the form of codes or tutorials)

Domain of Contribution 📊

[x] Frontend Dev HTML/CSS/JS

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

Screenshots / Gif (Optional) 📸

Good job @Pranshu321 @code-reaper08 Have a look.

LGTM ✨
You can merge it @ipsitagoel


Yank pre-Rust 1.0.0 versions

I'm trying to compile crates with -Z minimal-versions, but num 0.1 is one of the crates that often gets pulled in, and won't compile due to being written for a prehistoric 0.x Rust version.
Could you yank all the releases older than Rust 1.0.0?
This should do it:
for v in 0.0.1 0.0.2 0.0.3 0.0.4 0.0.5 0.0.6 0.1.0 0.1.1 0.1.10 0.1.11 0.1.12 0.1.13 0.1.14 0.1.15 0.1.16 0.1.17 0.1.18 0.1.19 0.1.2 0.1.20 0.1.21 0.1.22 0.1.23 0.1.24 0.1.25 0.1.3 0.1.4 0.1.5 0.1.6 0.1.7 0.1.8 0.1.9; do
    cargo yank --vers "$v"
done

It looks like the main gap is commit 3ccb4bd6c5cfaa8287fb19bd2c4ebbdfb9d77025 that fixed things for RFC 1214, which took effect as an error in Rust 1.7. That commit is in 0.1.27, which also still builds in Rust 1.0.0 (if you don't enable "bigint"->"rand"), so I think it's fine to yank before that. This is also visible on docs.rs, which failed to build 0.1.26 and earlier.
It's done, hope that helps!


Update Composer dependencies (2023-05-17-00-10)

Visual regression test passed!
View the visual regression test report


Strange bug when integrating with react-router-dom: rfInstance doesn't seem to unmount?

When navigating using react-router dom, if I render a React Flow component, press the back button, and then go to a new React Flow component the new component will have the reactFlowInstance of the previous component.
I built a Code Sandbox to illustrate this:
https://codesandbox.io/s/sleepy-benz-1rbkl?file=/src/index.js

please view the output of the console while clicking between the two Networks by going back to the Table using the back button.
Hopefully the MWE is clear and self-documenting - I tried to make it as simple as possible.
I am not sure whether the issue is with React Flow or with React-Router-DOM.
It should be noted that if you type in the networks/0 directly into the URL, there is no issue - it is specifically with navigating using the back button.
The reason I came across this is because I am building an App that picks a React Flow Network to render at random as a "feature network" and a table of other networks beneath. When I click one of the networks in the table the rfInstance from the feature network is loaded into that network, which is undesirable.
Any insight would be appreciated.

When you have multiple flows you need to wrap each of them with the ReactFlowProvider component so that they have their own store. We will add this information to the docs!


AttributeError: 'NoneType' object has no attribute 'mode'

When running:
python3 -m netbox_agent.cli --hostname_cmd "hostname -f"  -c ../netbox_agent.yml -u --preserve-tags
i get
443 "GET /api/dcim/interfaces/?id=929&limit=0 HTTP/1.1" 200 52 Traceback (most recent call last):   File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main     return _run_code(code, main_globals, None,   File "/usr/lib/python3.8/runpy.py", line 87, in _run_code     exec(code, run_globals)   File "/opt/netbox-agent/netbox_agent/cli.py", line 54, in <module>     main()   File "/opt/netbox-agent/netbox_agent/cli.py", line 50, in main     return run(config)   File "/opt/netbox-agent/netbox_agent/cli.py", line 43, in run     server.netbox_create_or_update(config)   File "/opt/netbox-agent/netbox_agent/virtualmachine.py", line 108, in netbox_create_or_update     self.network.create_or_update_netbox_network_cards()   File "/opt/netbox-agent/netbox_agent/network.py", line 443, in create_or_update_netbox_network_cards     ret, interface = self.reset_vlan_on_interface(nic, interface)   File "/opt/netbox-agent/netbox_agent/network.py", line 222, in reset_vlan_on_interface     (interface.mode is not None or len(interface.tagged_vlans) > 0): AttributeError: 'NoneType' object has no attribute 'mode'

@cyrinux  this is a old bug ,
line 217 replace with self.nb_net

@KivraChristoffer Replace what to what? please give me the correct line here.

@devopstales
network.py
215        # For strange reason, we need to get the object from scratch
216       # The object returned by pynetbox's save isn't always working (since pynetbox 6)
217        interface = nb.dcim.interfaces.get(id=interface.id) <---- interface = self.nb_net.interfaces.get(id=interface.id)

this is still not merged to master :)

addressed in #232


Connecting to a IPython console

Description
What steps will reproduce the problem?

I'm trying to connect to a remote spyder kernel. I have downloaded the kernel json file to local. This error occurs when I tried to connect to an existing connection.
 I first logged in on the login node, then I ssh myself to the gpu node where I actually have my repository.
Solutions I tried

I added the proxy to my config file in ~/.ssh/config which looks like

Host gpu
  HostName gpu
  User username
  ProxyJump login
  IdentityFile ~/.ssh/id_rsa

Host login
  HostName login
  IdentityFile ~/.ssh/id_rsa
  User username

This fixed my problem with remote connection on VSCode, but I still prefer Spyder. I tried reconnecting following the steps: https://docs.spyder-ide.org/current/panes/ipythonconsole.html. Did not work for me.

I found a similar solution where I set up a ssh tunnel by ssh -L 8888:username@login:22 username@gpu https://stackoverflow.com/questions/68106564/spyder-connect-to-remote-kernel-via-proxy. I checked port 8888 is listening and ran the cmd as administrator. I logged into gpu, then I re-tried with connecting to an existing console with hostname as localhost, port as 8888. This is the error message I got.

I will keep looking into this. Please let me know what other methods I can try. Thanks!

Hey @sungengyi, thanks for reporting. You're using a very old Spyder version (5.0.5), which has the bug you reported.
Please update to Spyder 5.5.6 and try again. Also, don't forget to update to spyder-kernels 2.5.2 in your remote machine to correctly establish the connection.
Let us know if that solves the problem for you.

Closing due to lack of response.


Improve "API usage" section.

I had to dig in the source to figure out how to pass arguments that are not options.

:blush:


inconsistent behavior (crash) when state is lost due to code change

Some code changes such as adding members to a module will reset project.
Sometime the callback is called and sometime it is not, it seems pretty random.
When it is called, sometime Excel crashes and sometime it doesn't. Also seems pretty random.
Also the crash is not the same depending on init method.
If callback is InitByAddress, Excel freezes briefly then exit with ExitCode = 4 and restart.
If callback is InitByName, Excel becomes unresponsive and just hangs forever (will I never waited more than 5 minutes tbh).
I believe this different behavior depending on init type is the same when application crash at exit so might be related to #3 ?

Thanks @thefasquelle ,
There are quite a few issues raised lately. I am planning to work on this class in the next few weeks as currently am too busy. Not sure I will be able to find workarounds for some of these issues though.


Run make test to run tests, not python test.py

@b4hand -- Sorry about that -- git blame says it was my fault.

LGTM


feat: add ability to mock WebSocket connections in Cypress #949

Recreated from @visitskyworld's PR to resolve merge conflicts and rebasing issues.
Description

Add the ability to mock WebSocket connections for Cypress tests
Add mockWebSocketRequest and mockAllWebSocketRequests commands
Implement an example of a mock WebSocket server for transactions - WIP

Notice
Before submitting a pull request, please make sure you have answered the following:

[x] Have you followed the guidelines in our Contributing guide?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[x] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)
closes #949
Risk
Testing
run
yarn test:cypress
Screenshots (if applicable)

@0xApotheosis , I have made changes you requested.
Regarding intercepting websocket, I tried to research possible solutions but there were no ways to intercept it.
The only solution is to configure cypress environment, I think.

Also, I have no permission to push cypress-websocket branch so I made a new PR here.
https://github.com/shapeshift/web/pull/1099

@0xApotheosis , I have made changes you requested. Regarding intercepting websocket, I tried to research possible solutions but there were no ways to intercept it. The only solution is to configure cypress environment, I think.

Thanks @visitskyworld - we'll take what we have so far and move the final piece of the implementation in-house.
Appreciate your contributions on this one.


Feature/css grids

Adds CSS Grid helpers for current grid definitions
:cry: Ends further development on Singularity

👍 This is awesome, and a fitting end to further development on Singularity. With CSS grids it really does feel like this has come full circle.  Thanks @Snugug for your continued work on this long after my interest faded couldn’t have been anyone better to take over ❤

So happy to have had my own small part in this history. Looking forward to when the web continues to develop and we are able to sunset more projects that were at one point necessary.


Change no-leaflet library names to no.leaflet

http://libs.cartocdn.com/cartodb.js/v3/3.11.32/cartodb.noleaflet.js
versus
http://libs.cartocdn.com/cartodb.js/v3/3.11.32/cartodb_noleaflet.js

unless you have really strong reason we will not change it since there are people using those files

It's just that old versions use the '-' and some users were not able to
find this last version. @jmedina told me this was something to change,
close if not.
On Wednesday, February 4, 2015, javi santana<EMAIL_ADDRESS>wrote:

unless you have really strong reason we will not change it since there are
people using those files
—
Reply to this email directly or view it on GitHub
https://github.com/CartoDB/cartodb.js/issues/307#issuecomment-72804305.

Ok, let's keep it as it is. But I didn't change on purpose :(.


Memory requirements

How much memory is this supposed to use? Running this on a computer with 8GB RAM:
Traceback (most recent call last):
  File "./synet.py", line 56, in <module>
    main()
  File "./synet.py", line 47, in main
    syn.synthesize()
  File "/home/lucky/Dropbox/Term 8/cs-personal/synet/synet/synthesis3.py", line 484, in synthesize
    if solver.check() == z3.sat:
  File "/home/lucky/anaconda3/envs/cs-synet/lib/python2.7/site-packages/z3/z3.py", line 6626, in check
    r = Z3_solver_check_assumptions(self.ctx.ref(), self.solver, num, _assumptions)
  File "/home/lucky/anaconda3/envs/cs-synet/lib/python2.7/site-packages/z3/z3core.py", line 3702, in Z3_solver_check_assumptions
    _elems.Check(a0)
  File "/home/lucky/anaconda3/envs/cs-synet/lib/python2.7/site-packages/z3/z3core.py", line 1372, in Check
    raise self.Exception(self.get_error_message(ctx, err))
z3.z3types.Z3Exception: out of memory

The log also seems to indicate that it's stuck in a loop? After initialising the messages become a loop of:

SAT, reading inputs...
	Synthesized input SetAdminDist ['False']
	Synthesized input Route ['False']
	Synthesized input nonMinCostAD ['False']
##############################
Synthesizing for box 12 fwd01-0
Feeding desired outputs for fwd01-0...
	Feeding desired output fwd01-0 [ForAll([t0, t1, t2, t3], Route(t0, t1, t2, t3) == False)]
	Feeding desired output fwd01-0 [ForAll([t0, t1, t2], nonMinCostAD(t0, t1, t2) == False)]
	Feeding shortcut INPUT fwd01-0 [ForAll([t0, t1, t2], SetAdminDist(t0, t1, t2) == False)]
Checking SAT for box fwd01-0 ...
!!!!!!!!!!!!!!!!!!!!
UNSAT going back to 13 fwd01-1
##############################
Synthesizing for box 13 fwd01-1
Feeding desired outputs for fwd01-1...
Checking SAT for box fwd01-1 ...

debug_201905291451.log
Is this an issue of an infinite loop somewhere or my machine having insufficient RAM?

As we described in our evaluation we ran SyNET on a machine with 128G of RAM. I've not tried with less RAM before.
It's normal for SyNET to try multiple times, this part of the back tracking algorithm described in our paper.

Apparently I didn't read the evaluation closely enough. Thanks.
re: the backtracking, I expected it to contain different logging messages when it backtracks. Appreciate the clarification.


ci: run lunr-fixture-gen

Alright it looks like a few of the languages just don't work at all like they did when merged. Hopefully I have the energy to investigate this some day.


Lint json and yaml files

Description
We unknowingly merged an invalid translation json file in https://github.com/valora-inc/wallet/commit/a13f16b61f8a75f7ecea81b10bd89984da1c8a14#diff-e975964e274dbbd8ca524cb9a258ed3225508b3c6d0c4e2198f3566a78380bf4R1070 (see #1736) which caused the Crowdin sync to fail.
This PR now makes sure json and yaml files are linted so we don't merge invalid json and yaml files in the future.
Note: the translation file fix was actually merged earlier, that's why it's not present in the diff here.
Tested

yarn prettify:diff returns an errors with invalid json/yaml files

How others should test
N/A
Related issues

Discussed in Slack.

Backwards compatibility
Yes

Hey @MuckT since "How others should test has n/a" hence we are skipping this PR
CC : @jeanregisser


Add blockstack transaction generation support to blockstack.js

This PR adds support for transaction generation in blockstack.js:
Unit tests are in:
tests/unitTests/src/unitTestsOperations.js
integration tests are in:
tests/operationsTests/src/operationsTests.js
There are three main modules of concern here:

network.js: this interacts with APIs for blockstack lookups and bitcoin transaction lookups and broadcasts
txbuild.js: these functions will actually construct blockstack transactions
safety.js: these are safety checks which will allow a client to ensure that certain conditions are met before generating or broadcasting a transaction (see how they are deployed in, e.g., blockstack-browser: https://github.com/blockstack/blockstack-browser/blob/feature/js-transaction-generation/app/js/profiles/store/registration/actions.js#L99)

Network configuration and selection is done via the config key in the blockstack.js module. For example, to select a REGTEST default, and then modify the RPC port:
  bskConfig.network = bskNetwork.defaults.LOCAL_REGTEST
  bskConfig.network.blockstackAPIUrl = `http://localhost:${port}`

This can be tested by running the integration tests in this branch:
$ npm run integration-test-ops

It can be tested against the blockstack-browser by linking this branch into blockstack-browser, and following the instructions on the PR here: https://github.com/blockstack/blockstack-browser/pull/1218

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 3 committers have signed the CLA.:white_check_mark: yknl:white_check_mark: kantai:x: larrysalibraYou have signed the CLA already but the status is still pending? Let us recheck it.

Thanks for the review @larrysalibra! I'm working through the flow enforcements now.

These comments are addressed in the latest commit

Thanks for the reviews @yknl and @larrysalibra! Merging...


Using XLA JIT Compilation results in bad_alloc error

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): Yes
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Linux Ubuntu 16.04
TensorFlow installed from (source or binary): source
TensorFlow version (use command below): v1.0.1-0-ge895d5c-dirty 1.0.1
Python version: Python 3.5.2
Bazel version (if compiling from source): Build label: 0.4.5- (@non-git)
CUDA/cuDNN version: 8.0/5.1
GPU model and memory: NVIDIA TX2
Exact command to reproduce: python3 script.py

# Config to turn on XLA JIT compilation
config = tf.ConfigProto()
config.graph_options.optimizer_options.global_jit_level = \
    tf.OptimizerOptions.ON_1
with tf.Session(config=config) as sess:

Describe the problem
Bug in XLA JIT compilation. Script works as expected without assigning config with JIT optimizer option.
Source code / logs
Changing the following code:
with tf.Session() as sess:

To:
# Config to turn on XLA JIT compilation
config = tf.ConfigProto()
config.graph_options.optimizer_options.global_jit_level = \
    tf.OptimizerOptions.ON_1
with tf.Session(config=config) as sess:

Results in the following error at runtime:
nvidia@tegra-ubuntu:~/dev$ python3 script.py
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcublas.so.8.0 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcudnn.so.5 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcufft.so.8.0 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcuda.so.1 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcurand.so.8.0 locally
I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:873] ARM has no NUMA node, hardcoding to return zero
I tensorflow/core/common_runtime/gpu/gpu_device.cc:885] Found device 0 with properties:
name: GP10B
major: 6 minor: 2 memoryClockRate (GHz) 1.3005
pciBusID 0000:00:00.0
Total memory: 7.67GiB
Free memory: 4.32GiB
I tensorflow/core/common_runtime/gpu/gpu_device.cc:906] DMA: 0
I tensorflow/core/common_runtime/gpu/gpu_device.cc:916] 0:   Y
I tensorflow/core/common_runtime/gpu/gpu_device.cc:975] Creating TensorFlow device (/gpu:0) -> (device: 0, name: GP10B, pci bus id: 0000:00:00.0)
E tensorflow/stream_executor/cuda/cuda_driver.cc:1002] failed to allocate 4.03G<PHONE_NUMBER> bytes) from device: CUDA_ERROR_OUT_OF_MEMORY
I tensorflow/compiler/xla/service/platform_util.cc:58] platform CUDA present with 1 visible devices
I tensorflow/compiler/xla/service/platform_util.cc:58] platform Host present with 6 visible devices
I tensorflow/compiler/xla/service/service.cc:180] XLA service executing computations on platform Host. Devices:
I tensorflow/compiler/xla/service/service.cc:187]   StreamExecutor device (0): <undefined>, <undefined>
I tensorflow/compiler/xla/service/platform_util.cc:58] platform CUDA present with 1 visible devices
I tensorflow/compiler/xla/service/platform_util.cc:58] platform Host present with 6 visible devices
I tensorflow/compiler/xla/service/service.cc:180] XLA service executing computations on platform CUDA. Devices:
I tensorflow/compiler/xla/service/service.cc:187]   StreamExecutor device (0): GP10B, Compute Capability 6.2
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

Can you try different values for per_process_gpu_memory_fraction in the following code and try to reproduce your code?
The following code will allocate memory with   Total available GPU memory * per_process_gpu_memory_fraction
gpu_options = tf.GPUOptions(per_process_gpu_memory_fraction=0.2)
sess = tf.Session(config=tf.ConfigProto(gpu_options=gpu_options))

@printdhruv, doing so results in no CUDA OOM errors, but the process still mysteriously quits. See the error log below:
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcudnn.so.5 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcufft.so.8.0 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcuda.so.1 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library
I tensorflow/stream_executor/cuda/cuda_gpu_executor.cc:873] ARM has no NUMA node, hardcoding to return zero
I tensorflow/core/common_runtime/gpu/gpu_device.cc:885] Found device 0 with properties:
name: GP10B
major: 6 minor: 2 memoryClockRate (GHz) 1.3005
pciBusID 0000:00:00.0
Total memory: 7.67GiB
Free memory: 4.04GiB
I tensorflow/core/common_runtime/gpu/gpu_device.cc:906] DMA: 0
I tensorflow/core/common_runtime/gpu/gpu_device.cc:916] 0:   Y
I tensorflow/core/common_runtime/gpu/gpu_device.cc:975] Creating TensorFlow device (/gpu:0) -> (device: 0, name: GP10B, pci bus id: 0000:00:00.0)
I tensorflow/compiler/xla/service/platform_util.cc:58] platform CUDA present with 1 visible devices
I tensorflow/compiler/xla/service/platform_util.cc:58] platform Host present with 6 visible devices
I tensorflow/compiler/xla/service/service.cc:180] XLA service executing computations on platform Host. Devices:
I tensorflow/compiler/xla/service/service.cc:187]   StreamExecutor device (0): <undefined>, <undefined>
I tensorflow/compiler/xla/service/platform_util.cc:58] platform CUDA present with 1 visible devices
I tensorflow/compiler/xla/service/platform_util.cc:58] platform Host present with 6 visible devices
I tensorflow/compiler/xla/service/service.cc:180] XLA service executing computations on platform CUDA. Devices:
I tensorflow/compiler/xla/service/service.cc:187]   StreamExecutor device (0): GP10B, Compute Capability 6.2
Killed

@tatatodd, any ideas?

This issue is automatically closed due to lack of activity. Please re-open if this is still an issue for you. Thanks!


fix(more) Return a proper error message when no argument is provided

Fix #1509

Generally, the argument validation needs to happen later in the code after argument/flags processing

I will do the change for consistency

otherwise more -v or more -h won't work correctly.

I don't think it is correct: with -v or -h, args.len() == 2, so, the program works as expected

otherwise more -v or more -h won't work correctly.

I don't think it is correct: with -v or -h, args.len() == 2, so, the program works as expected

You're correct; I forgot that, in this case, args actually includes the utility name as the first arg.
But what about the piping? No ARGS (ie, args.len() == 1) should also work... but doesn't yet.
I reverted the change that I asked for and added a "FixME" comment for future work.
I'll merge this as soon as the test passes.

CI can't find it ... I pushed an identical commit under a new commit hash.
It's building again now.


Old eslint causing bug

https://github.com/ganeshrvel/npm-electron-is-packaged/blob/7ddf8e3458e942ce291c01ade747287cd613651f/package.json#L40-L42
You should remove this. Otherwise pnpm will always install old eslint. And this package is the only package that do such thing.

Anyway, I've copied the code to my codebase for a workaround.


relocation truncated to fit..

Hi,
I am trying to adapt the  Examples/Nek5000  in ppiclf to Nek5000/examples/NekExamples/turbChannel in Nek5000.
Presently, I am trying to copy the usrdat2 code from the former to the latter.
If I uncomment this block of code,
      call ppiclf_comm_InitMPI(nekcomm,      >                         nid    , ! nid already defined in Nek5000      >                         np     ) ! np already defined in Nek5000
I get the following error that I cannot make sense of.
/home/zd/ppiclF/source/libppiclF.a(ppiclf.o): In function ppiclf_io_writesubbinvtu_':
ppiclf.f:(.text+0xcf40): relocation truncated to fit: R_X86_64_PC32 against symbol ppiclf_opt_param_i_' defined in COMMON section in /home/zd/ppiclF/source/libppiclF.a(ppiclf.o) ppiclf.f:(.text+0xcf9f): relocation truncated to fit: R_X86_64_PC32 against symbol ppiclf_opt_param_i_' defined in COMMON section in /home/zd/ppiclF/source/libppiclF.a(ppiclf.o)
ppiclf.f:(.text+0xd112): relocation truncated to fit: R_X86_64_PC32 against symbol ppiclf_opt_param_i_' defined in COMMON section in /home/zd/ppiclF/source/libppiclF.a(ppiclf.o) ppiclf.f:(.text+0xd433): relocation truncated to fit: R_X86_64_PC32 against symbol ppiclf_opt_param_i_' defined in COMMON section in /home/zd/ppiclF/source/libppiclF.a(ppiclf.o)
ppiclf.f:(.text+0xd4d2): relocation truncated to fit: R_X86_64_PC32 against symbol ppiclf_opt_param_i_' defined in COMMON section in /home/zd/ppiclF/source/libppiclF.a(ppiclf.o) ppiclf.f:(.text+0xea91): relocation truncated to fit: R_X86_64_PC32 against symbol ppiclf_opt_param_i_' defined in COMMON section in /home/zd/ppiclF/source/libppiclF.a(ppiclf.o)
ppiclf.f:(.text+0xeb28): relocation truncated to fit: R_X86_64_PC32 against symbol ppiclf_opt_param_i_' defined in COMMON section in /home/zd/ppiclF/source/libppiclF.a(ppiclf.o) ppiclf.f:(.text+0xeb87): relocation truncated to fit: R_X86_64_PC32 against symbol ppiclf_opt_param_i_' defined in COMMON section in /home/zd/ppiclF/source/libppiclF.a(ppiclf.o)
ppiclf.f:(.text+0xf86f): relocation truncated to fit: R_X86_64_PC32 against symbol ppiclf_opt_param_i_' defined in COMMON section in /home/zd/ppiclF/source/libppiclF.a(ppiclf.o) ppiclf.f:(.text+0xfc11): relocation truncated to fit: R_X86_64_PC32 against symbol ppiclf_opt_param_i_' defined in COMMON section in /home/zd/ppiclF/source/libppiclF.a(ppiclf.o)
ppiclf.f:(.text+0x10405): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status`
Any help appreciated.

Some additional information:
-If I toggle the ldim = 2 or 3 in the SIZE file, it will compile succesfully for 2D but not 3D.

Hey David, sorry to be a pain.
I have remedied this by increasing the minimum number of MPI ranks.

@tzahtila I'm glad to hear this is working for you now. Sorry it took so long for me to see this. Usually the relocation compiler errors are due to not having enough memory as you found. One way you can decrease this regarding particles is by setting PPICLF_LPART in the H File to be smaller than its default value which is usually really large. I've found personally that going higher than even 5000 or so isn't necessary most of the time.


MaterialMenu needs mdlDowngrade to unbind event listeners

Doesn't the MaterialMenu object need a mdlDowngrade method in order to unbind the even listeners on all the child menu options?

You are correct, @kelsmj. This is an oversight.


Import client for Polygons and UPRNs

[x] import client for Polygons
[x] import client for UPRNs

@davidread please have a look but I think it can be merged because the new model structure didn't affect the rest import client


Outdated

The Module seems to be outdated considering that the last updated was over 7 years ago

seems like.

tested on 02-Nov and seems like Outdated


Constraints are not inherited

Hello,
I am encountering the same issue as in #3
$ devpi --version
devpi-client 7.0.2

current devpi server: http://localhost:3141
    devpi-constrained 2.0.1
    devpi-server 6.9.2
    devpi-web 4.2.1

http://localhost:3141/root/dev:
  type=stage
  bases=root/pypi-constrained
  volatile=True
  acl_upload=root
  acl_toxresult_upload=:ANONYMOUS:
  mirror_whitelist=
  mirror_whitelist_inheritance=intersection

http://localhost:3141/root/pypi-constrained:
  type=constrained
  bases=root/pypi
  volatile=True
  acl_upload=root
  acl_toxresult_upload=:ANONYMOUS:
  constraints=virtualenv==v20.24.5
  mirror_whitelist=
  mirror_whitelist_inheritance=intersection

http://localhost:3141/root/pypi:
  type=mirror
  volatile=False
  mirror_url=https://pypi.org/simple/
  mirror_web_url_fmt=https://pypi.org/project/{name}/
  title=PyPI

Unfortunately:
pip install -i http://localhost:3141/root/pypi-constrained --no-cache-dir virtualenv
--> install virtualenv 20.24.5

pip install -i http://localhost:3141/root/dev --no-cache-dir virtualenv
--> install virtualenv 20.24.6

From my understanding this issue has been resolved already and I see the tests are passing, is there something I misunderstood ?
Many thanks

Hello again @fschulze,
After a bit of investigation, it seems that devpi-constrained methods are not called at all when using an index that is not of type "constrained", even if it inherit a constrained one (as in my example above).
Also, if an constrained index inherits from another constrained index, the constraints are not propagated either.

I noticed there are also no tests for inherited indexes, which is an oversight on my part. I hope to look into it soon, but have no ETA.

This is indeed a bug. At first glance this seems quite hard to fix. I have to think about this. Most likely this requires a quite fundamental change in devpi-server.


v5.11.7

[x] I have followed (at least) the PR section of the contributing guide.

Release of v5.11.7

There is a couple of additional approved PRs you can merge and include in the release: https://github.com/mui/material-ui/pulls?q=is%3Apr+is%3Aopen+review%3Aapproved

I merged those with no open thread to be addressed and updated the changelog.


 However, after changing it to es5, we cannot use the new feature "automatically creates a modern ES2015 build with minimal polyfills and a compatible ES5 build for older browsers". Hopefully the developer of ngx-gallery can fix it as well.

This affects us as well after upgrading to Angular 8, which by default will update the target to es2015. Using es5 indeed works, but is undesirable in the long run.

me too. I met this issue after upgrading to Angular 8. Look forward the fix instead of changing target.

i can not change the target to es5, cause other dependencies do require es6, so for me itis pretty blocking :(

same problem here! has someone solved it without changing to es5?

Same issue, using Angular 8 and changing target is not something we can do

in ngx-gallery.umd.js, this code needs to be modified.
unfortunately my js skills are limited. maybe somebody can convert that ?
//var CustomHammerConfig = /** @class */ (function (_super) {
//    __extends(CustomHammerConfig, _super);
//    function CustomHammerConfig() {
//        var _this = _super !== null && _super.apply(this, arguments) || this;
//        _this.overrides = ({
//            'pinch': { enable: false },
//            'rotate': { enable: false }
//        });
//        return _this;
//    }
//    return CustomHammerConfig;
// ... blabla (platformBrowser.HammerGestureConfig;

Here is a es2015 compiled version that works with Angular 8.
THIS MIGHT NOT BE UPDATED!
change to this in your package.json:
"ngx-gallery": "git://github.com/onack/ngx-gallery-dist",

@PawelSpoon
A temporary fix that works 💯  for now :
in the file ngx-gallery.umd.js changes this lines of code :
var CustomHammerConfig = /** @class */ (function (_super) {
__extends(CustomHammerConfig, _super);
function CustomHammerConfig() {
var _this = _super !== null && _super.apply(this, arguments) || this;
_this.overrides = ({
'pinch': { enable: false },
'rotate': { enable: false }
});
return _this;
}
return CustomHammerConfig;
}(platformBrowser.HammerGestureConfig));
to :
class CustomHammerConfig extends platformBrowser.HammerGestureConfig {
constructor() {
super(...arguments);
this.overrides = ({
'pinch': { enable: false },
'rotate': { enable: false }
});
}
}

@onak, @Oussail , thanks a lot !

Oussail, thank you!
that saved the day. but honestly, looks like this is a good time to look for a new gallery solution, or to create one.

Thanks . it was work

@Oussail Thanks a lot

I have same issue

@lukasz-galka Please reopen this issue as switching the target back to es5 only because of one lib is not a desirable solution.

@Oussail
I don't know if it's a temporary solution, but it solved my job for now. Thank you so much.

@Oussail you saved my day! Thank youuuuuu

@Oussail Thanks, works like a charm!

google give webmaster tools error for es5

update from 5.7 to 5.10 still same error:

TypeError: Class constructor HammerGestureConfig cannot be invoked without 'new'
at new CustomHammerConfig (ngx-gallery.umd.js:1898)
at _createClass (core.js:26964)
at _createProviderInstance (core.js:26931)
at resolveNgModuleDep (core.js:26878)
at _callFactory (core.js:27002)
at _createProviderInstance (core.js:26934)
at resolveNgModuleDep (core.js:26878)
at _createClass (core.js:26968)
at _createProviderInstance (core.js:26931)
at resolveNgModuleDep (core.js:26878)

@PawelSpoon
A temporary fix that works 💯 for now :
in the file ngx-gallery.umd.js changes this lines of code :
var CustomHammerConfig = /** @Class */ (function (_super) {
__extends(CustomHammerConfig, _super);
function CustomHammerConfig() {
var _this = _super !== null && _super.apply(this, arguments) || this;
_this.overrides = ({
'pinch': { enable: false },
'rotate': { enable: false }
});
return _this;
}
return CustomHammerConfig;
}(platformBrowser.HammerGestureConfig));
to :
class CustomHammerConfig extends platformBrowser.HammerGestureConfig {
constructor() {
super(...arguments);
this.overrides = ({
'pinch': { enable: false },
'rotate': { enable: false }
});
}
}

The error fixed.... My issue with google not :|

Modify the providers in your app.module.ts with
export class CustomHammerConfig extends HammerGestureConfig  {
   overrides = {
       pinch: { enable: false },
       rotate: { enable: false }
   };
}

and add to the Providers
providers: [
{ provide: HAMMER_GESTURE_CONFIG, useClass: CustomHammerConfig }
]

@Oussail Thank you I tried your solution but got this error:
url is undefined in ngx-gallery.umd.js 159

you mean adding this instead of changing the code would work?

Modify the providers in your app.module.ts with
export class CustomHammerConfig extends HammerGestureConfig  {
   overrides = {
       pinch: { enable: false },
       rotate: { enable: false }
   };
}

and add to the Providers
providers: [
{ provide: HAMMER_GESTURE_CONFIG, useClass: CustomHammerConfig }
]

This actually worked for me. Thanks.

I revert my project due some work project, and i'm moving to another city, and i lost track of everything.
it compiled on es5, but i'm not in condition to change anything in my project currently...

I changed the build task in guplfile to use es2015 target and it works in my angular 8 app (made a pull request).
But I don't know if this kills any es5 app. Can anybody help me with this question?

@Oussail Thank you I tried your solution but got this error:
url is undefined in ngx-gallery.umd.js 159
Ran into same error. Did you find a solution?

Ran into same error. @desoga10 your solution seems to work just fine, thanks.

Modify the providers in your app.module.ts with
export class CustomHammerConfig extends HammerGestureConfig  {
   overrides = {
       pinch: { enable: false },
       rotate: { enable: false }
   };
}

and add to the Providers
providers: [
{ provide: HAMMER_GESTURE_CONFIG, useClass: CustomHammerConfig }
]

I have this error when I use ng serve --aot
Error during template compile of 'CustomHammerConfig'
 Class CustomHammerConfig in /home/jeires/Documents/Angular/Cool Mart/coolmart/src/app/app.module.ts extends from a Injectable in another compilation unit without duplicating the decorator
   Please add a Injectable or Pipe or Directive or Component or NgModule decorator to the class.

Error during template compile of 'CustomHammerConfig'

I added @Injectable() decorator like this and solved this issue:
@Injectable() export class CustomHammerConfig extends HammerGestureConfig  {    overrides = {        pinch: { enable: false },        rotate: { enable: false }    }; }


Ideas/suggestions

This is awesome. I've been able to use it successfully to convert a picture of the 2024 eclipse into an stl I can import to Fusion360. Hoping to machine it out, ebonize the wood, pour in translucent epoxy, then machine flat and obtain a cool gradient look.
Anyway, had some thoughts as I wrapped my head around the code.

what about adjusting parameters to be more objective vs. relative? reduction_factor and scale work, but I wasn't able to figure out what values to use except by trial and error. I could envision providing a scaled image dimensions instead, or having scale be the output object dimensions in mm.

super minor, but I think you can get away with this instead of the use of baselayer_height and subtracting 1 from num_layers. Also, right=True for digitize seemed to work better than right=False (default) and subtracting 1 from the height map result.

# Discretize the height map
discrete_heights = np.linspace(layer_height, layer_height * num_levels, num_levels)
height_map = np.digitize(img, bins=np.linspace(0, 1, num_levels), right=True)
height_map = discrete_heights[height_map]

I also used this, and didn't get any errors or issues... is there a reason to do range(0, height-1, 1) instead?

# Create the faces array
faces = []
for y in range(height):
    for x in range(width):

I noticed for every bottom face, you were connecting to a vertex at the lowest height. As this is primarily for 3d printing, maybe that's correct? For me, it seemed unintuitive why to do this. I changed it to this, which gives us a flat back at z=0 vs. at z=layer_height

# Bottom face (base of the lithophane)
v0_b = [v0[0], v0[1], 0]
v1_b = [v1[0], v1[1], 0]
v2_b = [v2[0], v2[1], 0]
v3_b = [v3[0], v3[1], 0]

lastly, I wanted my stl high res for a nice smooth gradient, so I'm currently using 100 levels. This slows things down quite a bit. If I'm not mistaken, I believe you are adding sides to every single set of vertices internally? I'm not sure how things would behave with 3d printing, but I had success commenting that bit out, and then adding 8 faces just to the perimeter (2 triangles per side). I also added an argument so one could specify to "fill" (internal sides, use your existing code) or not (just add exterior sides to complete the shell)

# Add side faces around perimeter if internal faces not created
if not filled:
    tl = vertices[0, 0]
    tr = vertices[0, width - 1]
    bl = vertices[height-1, 0]
    br = vertices[height-1, width - 1]
    faces.append([tl, bl, [bl[0], bl[1], 0]])
    faces.append([tl, [tl[0], tl[1], 0], [bl[0], bl[1], 0]])
    faces.append([tl, tr, [tr[0], tr[1], 0]])
    faces.append([tl, [tr[0], tr[1], 0], [tl[0], tl[1], 0]])
    faces.append([tr, br, [br[0], br[1], 0]])
    faces.append([tr, [br[0], br[1], 0], [tr[0], tr[1], 0]])
    faces.append([br, bl, [bl[0], bl[1], 0]])
    faces.append([br, [bl[0], bl[1], 0], [br[0], br[1], 0]])

If any of this is useful, I can do a PR. Happy to putz on some other ideas above, like how to scale to a set size. This would be awesome for my purposes. My image is 900px, so I get a 900mm image (I'm using reduction_factor=scale=1) and then scale to my target of 6x6in.

Oh, and just for reference... wanted to share the application. Both to say "Thanks" for enabling this (it's been an idea for many months, but hadn't figured out just how to convert the image to a depth map), as well as to potentially give others ideas.
Here's the image my buddy took:

I'll be making matching plaques for both of us. I'll machine out the eclipse using the stl generated by your code, ebonizing the wood, epoxy filling with translucent white, machining everything flat again and completing other features (picture recess and I'll have an lettering with our last names/dates below the pic), then add the outer frame.

Close up of machining path in Fusion:

I'm excited, thanks for sharing what you built for others to use!


Does not handle queries on document Ids in web case.

There is no mechanism for handling a query on the documentId field.
Using firebase/firestore I do the following:
fs.QuerySnapshot querySnapshot = await _settings.where(fs.FieldPath.documentId(), "==", id).get();

Please add this feature.
Thanks.

G'Day,
Thanks.
It is not working.
The following query does not respond:
import 'package:cloud_firestore_all/cloud_firestore_all.dart' as fsa;

print( 'Creating Query with id=$id');
    fsa.Query query = _tasks.where(fsa.FieldPath.documentId(), isEqualTo: id);
print( 'Attempting to get documents');

The console shows:
Creating Query with id=SU3lQD5dxfuZZNC1MndL

Application finished.

The Application finished. occurs because I give up and terminate the debug session.
So something is causing the system to hang.
I noticed that your code is:
class FieldPath implements intf.FieldPath {
  static dynamic documentId() => web.FieldPath.documentId;
}

But I think it should be:
class FieldPath implements intf.FieldPath {
  static web.FieldPath documentId() => web.FieldPath.documentId();
}

I tested this, and it still didn't work.
Cheers,
Phil.

G'Day,
Found the bug.
Please fix up the line 102 in web/query.dart from:
    if (isNull)

to:
    if (isNull != null )

My code is now working.
I will test in Android tomorrow.
Cheers,
Phil.

G'Day,
Happy New Year!!!
The merged Master does not work.
Please correct fieldValue.dart:
class FieldPath implements intf.FieldPath {
  static dynamic documentId() => web.FieldPath.documentId;
}

to:
class FieldPath implements intf.FieldPath {
  static web.FieldPath documentId() => web.FieldPath.documentId();
}

The pair of parentheses () at the end of web.FieldPath.documentId(); are crucial.
Also, your change in query.dart :
    bool isNull = false}) {

Does not work, if isNull is not used it needs to be null, so setting it to false causes other problems.
Please delete this back to:
    bool isNull }) {

and change:
   if (isNull != null) {
      assert( true == isNull );
      op = '==';
      value = null;
    }

With these changes, it works.
I have not tested Android yet, but I will once you make these changes.
Thanks for all your help,
Cheers,
Phil.

isNull is not used if it is false on the web

G'Day,
Everything is working now.
Thanks.
I still think that you should change:
    bool isNull })

and
  if (isNull != null) {
      assert( true == isNull );
      op = '==';
      value = null;
    }

But, it is working at the moment, so leave it for now.
Thanks again.
I have deleted my fork.
And have closed the issue.
Cheers,
Phil.


feat: update tail to handle complete lines

Close #385

@peterbarrow After hacking something tougher I have tried to fork the main repo and found out that there is a solution for that in the master branch........ I have tested it locally but It would be good if you can also test it before we merge this.


create your own nineslice in phaser 3

Since the Phaser 3 NineSlice plugin does not work in Phaser 3.60, and the built in game object only supports webgl, it would be nice to have a way to create nine slice game objects as a work around

In the video, include links to the phaser 3 nine slice game object video

Status: have the code example ready to go. Need to update the example image, documentation, and link to live code.

1:25 - card to phaser 3 nineslice
1:37 - Review nineslice scaling technique
2:43 - Link to starter source code
3:13 - Review source code
4:02 - Start of code
7:55 - Update image texture
13:31 - Add middle row frames
15:15 - Add bottom row frames
16:57 - Create image game objects
20:00 - Update image game object positions
24:15 - Modify image game object display size


DSA Problem (Graph) | Flood Fill in C++

I want to add a new problem named "Flood Fill".
I code the solution for this problem in C++ language.
@Kumar-laxmi  sir please assign me this issue.

This repository is for algorithms and not for DSA problems


Support event_types parameter on List Attempted Messages EP

Motivation
The motivation behind this Pull Request is to enhance the Svix Go SDK by expanding the functionality of the List Attempted Messages endpoint. Currently, the SDK lacks the capability to return messages filtered by event types, as stated in the documentation. Therefore, this PR aims to introduce an option within the SDK that enables filtering messages by event types.
Solution
EventType field of type *[]string has been passed as query parameter in the request to the List Attempted Messages endpoint. event_types parameter has been added to the List Attempted Messages in the openapi.json, and includes the
api_message_attempt.go file changes generated by generate_openapi.sh

Integrated within https://github.com/svix/svix-webhooks/pull/1027

I'm so sorry, I don't know how we missed your PR! We would have loved merging it instead of re-implementing it.
The code, btw, is mostly automatically generated.


Sync/cf209

Publish CF209

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 5 committers have signed the CLA.:white_check_mark: biancaluna:white_check_mark: sunilkn020:x: kevin.hendel@hcl.com:x: lynnemacabale:x<EMAIL_ADDRESS>seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


fix(sortable): propagare the context to the combined/wrapped callbacks

Closes #251

Coverage remained the same at 100.0% when pulling 3a8dff154acf2149fd73578cf87da6db62f563f0 on thgreasi:callbackContext into b5fb6fd0e8915b99621a36d72ab9f25ca730d6f2 on angular-ui:master.


feat(forge verify-contract): --guess-constructor-args

Motivation
Ref #6334
Solution

Added RpcOpts to VerifyArgs. If any valid eth_rpc_url is found in config and --chain is not specified, we are using explorer for chain_id from RPC. This should make UX cleaner (ref comment)
Added --guess-constructor-args parameter which uses Etherscan API and RPC provider to fetch creation code of contracts created directly with create transaction or directly with default CREATE2 deployer.
Added test for --guess-constructor-args. I wasn't able to run existing verification tests without some small updates to them (renaming --etherscan-key to --etherscan-api-key for example). Is there a chance that required env vars are not set in CI which leads to tests silently passing or I got something wrong?

The only way I can see to make --guess-constructor-args work for any contract is by implementing some kind of cast run with custom inspector which will be pretty long-running thing (some cast run's are taking several minutes on my machine). So not sure if such UX is really a best way to do it. Would be happy to get some ideas on how creation code for arbitrary contract could be fetched faster.

made guess_constructor_args a separate function
also did some more testing and it seems that in some cases compile_file results in different bytecode, so changed project.compile_file to project.compile, it shouldn't take long as it compiles with the same settings, and will probably just use cache all the time


Geometry_type_name validation is case-sensitive

On version 0.8.1 of your package, when exporting data as a GeoPackage and testing it with the validator, it is failing on RQ14: "The geometry_type_name from the gpkg_geometry_columns table must be one of POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, or MULTIPOLYGON. Found geometry_type_name: Point"
The geometry_type_name doesn't match due to the title case being used. Can the comparison used for RQ14 be made case insensitive to accommodate how this GeoServer extension handles gpkg exports?
I have attached a zipped example GeoPackage which is currently failing this validation
v_os_open_greenspace_allotment_centroids_april_2021.zip

Thanks @henrywild we will look into this and improve this in a future version.


mkpr

Applied mkpr on undefined
sed s/\/service": "^.*"/\/service": "^9.2.15"/

Codecov Report

Merging #1104 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1104   +/-   ##
=======================================
  Coverage   89.18%   89.18%
=======================================
  Files           7        7
  Lines         712      712
  Branches       77       77
=======================================
  Hits          635      635
  Misses         77       77

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f2cc0cc...f0b4adb. Read the comment docs.


PERFORMANCE: create_smoment_model_reaction_wise_with_sbml gets bogged down in recent cobrapy release

This is an issue I think is due to updates in cobra. With cobra version 0.21.0 create_smoment_model_reaction_wise_with_sbml() runs in a reasonable amount of time. However, once I use an environment with  cobra version 0.26.3, the same function consumed a prohibiting amount of time. After drilling into the details, I realized that the time was spent deepcopying metabolic reactions https://github.com/klamt-lab/autopacmen/blob/e115b914b5df20cb682660bffae87711efbaa786/autopacmen/submodules/helper_create_model.py#L186
From my understanding, the autoPACMEN code has not changed on this point, but cobra probably has changed its procedures for copying reactions, leading to a very slow recursive process. As a side note, I have experienced cobrapy to be slow and cumbersome for modifying models and their components. There exist an alternative metabolic modeling package named reframed which I have used to resolve such problems, but due to technological dept, replacing cobra with reframed would take a considerable effort.

I had the same problem, thanks for pointing this out. It helped me resolve the issue.


when will  the code release

when will the code release?

Sorry for the delay, the code is released now.


Load all tags at once instead of per team

Current coverage is 40.68% (diff: 0.00%)

Merging #210 into master will decrease coverage by 0.09%

@@             master       #210   diff @@
==========================================
  Files            33         33
  Lines          1307       1310     +3
  Methods         180        182     +2
  Messages          0          0
  Branches        167        167
==========================================
  Hits            533        533
- Misses          774        777     +3
  Partials          0          0

Powered by Codecov. Last update 53a1505...5bdc889

Coverage decreased (-0.1%) to 46.809% when pulling 5bdc889595bd1f8e8a23010476755cf67df311cb on load-all-tags into 53a15057d77c142157694c33e54da45316825a08 on master.

Coverage decreased (-0.1%) to 46.809% when pulling f70d3ff168f9e5228925fe40221cf6baf2a9b0f0 on load-all-tags into 53a15057d77c142157694c33e54da45316825a08 on master.


Refactor how we update controllers

Refactor so that we don't need to copy & paste code for updating each controller.

Not sure what happened, it seems I added a label while I was sleeping, weird.
@janetkuo is it ready for review+merge or are you still working on it ?

Thanks @janetkuo . Nice to see a generic update function for controllers. Shall we keep discussing to optimize convert function in order to look better ? It's simply too long.

Yes it's ready for review. Agree with Tuna, I'd love to optimize convert as
well.
On Sat, Jul 16, 2016 at 10:27 AM Tuna<EMAIL_ADDRESS>wrote:

Thanks @janetkuo https://github.com/janetkuo . Nice to see a generic
update function for controllers. Shall we keep discussing to optimize
convert function in order to look better ? It's simply too long.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/skippbox/kompose/pull/42#issuecomment-233141320, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEpqQx66tM1mFtCGEvljhRUlovCGzBPQks5qWRR8gaJpZM4JN33Z
.

@janetkuo @runseb I checked out the PR. It looks good to me.


Why do 3.11 doesn't appear in releases ?

3.11 appears in the tags: https://github.com/py-cov-action/python-coverage-comment-action/tags
but not in the releases: https://github.com/py-cov-action/python-coverage-comment-action/releases
No idea why and if it's something we need to solve.

Interesting point, I hadn't noticed that. Well, the release exists. So this seems more like a Github problem than a problem of our workflow.

It gets worse. Releases made via API (including CLI) don't appear in the Marketplace :( https://github.com/orgs/community/discussions/7941

Oh, that's pretty unfortunate. Well, I guess there's no way around manually adding them to the Marketplace :/

note: 3.11 now appears. It appeared when we deployed 3.12. No idea why.
And yeah, if we want our releases on the marketplace, we need to do it manually, it's a shame.


Switching is so slow...

Now, the switching works as full backup and restoration of ".vimrc and .vim".
This policy is so slow..So VIMSW needs more efficient policy or implementation.

Does "sharing of .vim folder" can be possible??
No problem in this way??


Script synthetic dataset

rerun tests

rerun tests

rerun tests

Adding also @benfred to see if he thinks we can put the code somewhere else so it can be reused

rerun tests

rerun tests

rerun tests


Folds only argument list, not the entire function

VSCode Version: 1.51.1
OS Version: Big Sur 11.0.1 (Darwin x64 20.1.0)
ms-python: v2020.11.371526539

VSCode folds only the argument list when closing parentheses have smaller indentation than the argument list.
Expected behavior: folds the entire function body.

Duplicate of #372; I believe the folding behavior seen in the gif above is just VS Code's default.
(Similar is #266.)


⚠ TROJAN 🇮🇩 Indonesia IDB 1 has degraded performance

In 8a5a344, TROJAN 🇮🇩 Indonesia IDB 1 (https://idt-1.opensvr.net/) experienced degraded performance:

HTTP code: 200
Response time: 23059 ms

Resolved: TROJAN 🇮🇩 Indonesia IDB 1 performance has improved in d0968df.


Migration django2

Coverage decreased (-0.05%) to 85.182% when pulling 559b338832eb1b48f15e5a93c96f30102fc147d6 on migration-django2 into<PHONE_NUMBER>c6f832ec18f6bb7cd0101dde8b8d62 on master.


usb: netusb: Add missing ethernet dependency

usb networking depends on Ethernet support (NET_L2_ETHERNET).
Signed-off-by: Loic Poulain<EMAIL_ADDRESS>

Duplicated of PR 4627


Integrating zino with apalis

I am the developer for apalis and am curious if you would be interested in integrating it as part of background processing.
Related:
#74

Thanks for your nice work no apalis.
Yes, we will integrate apalis with zino if we can impl the AsyncScheduler trait for apalis::prelude::Monitor (maybe the trait should be slightly modified). I am not sure whether the Monitor can run in tokio::runtime::Runtime::spawn or not.

I have updated the AsyncScheduler trait and implemented it for Monitor: https://github.com/zino-rs/zino/blob/main/crates/zino-core/src/schedule/mod.rs#L42
It should work as expected.

Hmm looks ok, let me give it a try and get back


Angular2 version?

Is there any plan to create a version of this component compatible with Angular2?
This is the best component for input mask. And unfortunately there is no component (with mask for money, phone, document) similar that is compatible with Angular2.

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/39308494-angular2-version?utm_campaign=plugin&utm_content=tracker%2F1022469&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1022469&utm_medium=issues&utm_source=github).

Duplicated of #150


Update VCX Maintainers

Adds @lukewli-anonyome as a vcx maintainer, and to the read-only list (is that right?), and removes nain & xprazak2 who no longer work on the project with us.
cc @JamesKEbert @Patrik-Stas

hey @ryjones , from the github UI of aries-vcx-maintainers, this successfully removed nain and xprazak2, however it didn't add lukewli-anonyome . is there something else i need to do? perhaps he doesn't exist in the hyperledger organisation itself so this governance change wasn't effective?

@gmulhearn they need to accept the invite


Bug: Only the last image will be renamed while pasting multiple images at the same time

Consider the situation of pasting multiple images at the same time. These images are compressed in the create event.
However, only the last image in the markdown file will be renamed to the compressed image name due to the replace logic using the same cursor position.
Log:

The first current line ! should be [[iShot_2022-07-17_03.31.42.jpg]].

Obsidian version: 0.15.6
Plugin version: 1.0.2

@kaiiiz
Sorry, recently too busy, really do not have time, I need to wait for the completion of the project in hand, in order to fix the bug


ModuleNotFoundError: No module named 'yaml'

import yaml

ModuleNotFoundError: No module named 'yaml'

Hi @chevonmdphillip, can you run pip install pyyaml and see if that fixes the issue?

Good to hear. Thanks for using the tool!


flow-bin NPM package not finding binary on Windows?

I'm trying to configure a Windows AppVeyor build for Jest, but it's resulting in the following error while running npm install:
><EMAIL_ADDRESS>postinstall C:\projects\jest\node_modules\flow-bin
> node lib/install.js
  × No binary found matching your system. It's probably not supported.
  × flow binary test failed

My understanding is that Flow v0.30 adds support for Windows, so this should be working now, right?

Flow requires a 64-bit version of Node to be running. Needed to update the AppVeyor config to use 64-bit Node.js:
environment:
  matrix:
    - nodejs_version: "4"
    - nodejs_version: "6"

install:
  - ps: Install-Product node $env:nodejs_version x64

That's weird, probably flow-bin incorrectly assumes that if node is 32 bit, than OS is 32 bit too

Yeah, bin-wrapper (which flow-bin uses) makes that faulty assumption. Filed a task at https://github.com/kevva/bin-wrapper/issues/48


Issue with WordPress trademark?

Hi Chingis,
did you know, the WordPress Foundation Trademark Usage Policy has a strikt regulation for the use of "WordPress" in domain names:

"Please do not use WordPress or WordCamp as part of a domain name."

Source: http://wordpressfoundation.org/trademark-policy/
I think, it is better if you rename your domain in: docker4wp.org. This is the normal way to name WordPress in domains.
Hope this was helpful :-)

Ohh.. wasn't aware of that, thanks for the heads-up

We dropped docker4wordpress.org, now using only http://docker4wordpress.readthedocs.io/en/latest/ and https://github.com/wodby/docker4wordpress

Great! :+1:
...and woooow, you are fast! :1st_place_medal:


Add Tags for appearance in topic

https://github.com/topics/directus-extension

Added the topic plus a few other topics that make sense


Don't add is_VARIANT when VARIANT is 'set' or 'clear' and width is 1

If a field enumeratedValues includes variants set or clear, and the field width is 1, then the generated Rust contains a duplicate is_set or is_clear method.
I think it's reasonable for an SVD file to have a Clear variant, in the verb sense, for clearing an interrupt flag in a Flag Clear Register. It gives you a clear() method on the field, rather than bit(false).
This patch skips generating is_VARIANT when this condition is met.

This sounds good to me in principle but I'd hate if this introduced a bug because a vendor decide to map, for example, SET to the value 0. Could you add an assertion to check that if the vendor used CLEAR / SET for the enumeratedValue name then its value must be 0 / 1?

About that...

I knew this would happen.
I think it'd be better to rename the bit-level set, clear, is_set, is_clear methods so they don't become ambiguous with the variant-level methods. Hmm, maybe ... set_bit, clear_bit, bit_is_set and bit_is_clear? At least the last two can collide with the is_$variant methods. Of course a vendor could name a variant SET_BIT or BIT_IS_SET but I think the best we can do is reduce the chance of name collisions.
cc @whitequark #92

@japaric seems really ugly but I have no better solution.

Another way I just thought is ... using another proxy struct. so you can do $bitfield().bit().set() for the bit-level method and $bitfield().$variant() for the enumeratedValue API. However, the vendor could name an enumeratedValue BIT and that would collide with the bit method that returns the proxy ...

I don't think collisions are an issue, we could simply deterministically rename anything that can collide. I.e.: SVD bit -> Rust bit_, SVD bit_ -> Rust bit__ etc.

I think svd2rust already skips automatic set and clear methods if an enum is provided, so you could do the same for is_set and is_clear (the opposite of this patch, which prevents is_VARIANT instead). Slight saving grace is that these particular fields are WO so you'll never be calling is_clear anyway, and that's probably true of most fields where the clear verb means "write a 1". It does mean you'd never actually generate a collision.
The confusion is you can't tell from reading the code if hifcr().modify(|w| w.cfeif7().clear()) is setting the bit to zero or clearing the flag... but it's a shame to lose the short and nice set() and clear() for undocumented single-bit fields, of which there are so many.
It's a pity there's no obvious way to have the proxies take an argument directly, like w.cfeif7(true).cfeif8(true) for the automatic single bit cases, but I guess you can't then upgrade to an enumerated description later. Perhaps set_bit() and clear_bit() are best, and just hope to get good enums for as many fields as quickly as possible?

I think svd2rust already skips automatic set and clear methods if an enum is provided

Err, does it do that? Because it shouldn't. Adding enumeratedValues information should not break existing code.

Perhaps set_bit() and clear_bit() are best

Either this or the bit proxy works for me.

I think so... Starting here:
https://github.com/japaric/svd2rust/blob/master/src/generate.rs#L1054-L1063
it then generates methods for the variants if they are specified, otherwise:
https://github.com/japaric/svd2rust/blob/master/src/generate.rs#L1242-L1256
For example https://docs.rs/stm32f30x/0.4.1/stm32f30x/gpioa/bsrr/struct._Br11W.html has a reset(), variant(), and bits methods, but no set() or clear().

I'd prefer to keep the set and clear methods for the write operation. They can be more readable than bit(bool) in some cases.

@japaric I would prefer set_bit and clear_bit, there is already way too much nesting in svd2rust output.

:+1: for set_bit() rather than further nesting. I'll do those and the conflicting-variant-renaming in a separate PR tonight. How does bit_set() compare to set_bit() and etc?

Elsewhere svd2rust goes for English word order, so set_bit seems preferable.


[macOS] error: unknown command at: 'platform'

Hey!
Found out that there is no ponyup platform command as stated https://github.com/ponylang/ponyup/blob/d450da7a65749a0a09c53bb91bbedc296753c1a9/ponyup-init.sh#L221
Perhaps it's meant to say ponyup default?

Thanks for reporting @Charlyzzz! A fix is on the way.


Consider binder for easy user evaluation without setting up local environment.

https://github.com/openjournals/joss-reviews/issues/6586
Here is a suggestion for hosting the tutorials at binder.
See the README.md at: https://github.com/curtcorum/pulpy-tutorials/tree/ccjoss
There is now a bare-bones requirements.txt as suggested in #1 but it is not tested beyond the adiabatic_pulse_design.ipynb notebook.
The badge and links needs to be updated to point to the main repository, not the fork.
Placing a brief description in README.md as suggested in #2 and linking to binder for each example would make it much easier for potential users to evaluate. References to or from the paper could be linked or noted here, or inside the notebooks.
In the notebooks %matplotlib notebook needs to be changed to %matplotlib inline or else other dependencies figured out.
The links are pointing to jupyterlab instances, not the default jupyter notebook, but whichever is used should be debugged.
See: https://github.com/binder-examples/jupyterlab

In going through the other notebooks, they seem to work on binder with %matplotlib inline or when the notebook does not specify, with a few (complex) warnings except:
Spokes demo.ipynb sens_file = sio.loadmat('data/b1maps_40.mat'), the file is not present in the https://github.com/jonbmartin/pulpy-tutorials repo.