text:
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. Settings for stuff that you want in git and user specific shit

Here’s the issue for separating the two https://github.com/KittyCAD/modeling-app/issues/3961

Another thing we talked about somewhat related, putting it here so it doesn't get lost.
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 theming now.

oh thank fucking god

less features I LOVE IT

Given I know who you are and how you express yourself I figured :rofl:

okay i jjust looked tho and the rust side still has those settings for projects so we should clean that up https://github.com/KittyCAD/modeling-app/blob/main/src/wasm-lib/kcl/src/settings/types/project.rs#L64

since we'd be renaming files and migrating shit anyways its a good change to clean up what actually can change app level vs. project level vs. dir level

Aside: I think @franknoirot removed per-project themeing. 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.
@epage@hachyderm.io
@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.
My constraints were:

preferably there should only be one place that stores your git-pushable settings, lessens the cognitive load
if we must have 2 places for git-pushable settings THEY MUST USE THE SAME SYNTAX
you should be able to open a file anywhere and it should just work
kcl-samples the repo should work at the root, meaning like it should be a "project" even tho i really want to get away from projects but whatever, today you cant just open kcl-samples at the root and have it work you need to point your whole app there and its fucking stupid, this is why people keep copy pasting into those files and no one is using git and opening the directory in the app and testing the actual fucking workflow we are trying to create
you should be able to import/use another kcl file and it keeps the units for that file or is unitless
assemblies should be able to import files of various units and keep their units
josh should stop commenting on every const that its in inches, it should be easily apparent what the file is in
scripts should be easily sharable with a single file if it imports nothing

So 1. this solves all those. 2. it lessens the cognitive load there is only one place for units settings its in the fucking file and users will know if outside the app to just look there, 3. its at the top of the file so josh wouldn't need to comment those variables anymore since its right fucking there
So my proposal is this:

we add it to the top of every file, if unspecified we consider it unitless if its being imported or mm if not (which is the default today), you can also explicitly set a file as unitless/mm/etc
as a migration path on fmt we move the git-configurable settings from the project.toml to the top of the file

as far as syntax goes i have the following constraints but other than that im like whatever:

dont make it fugly
it should parse easily into a struct we can add more things to EASILY as in you dont modify the parser every time you only add something to the struct and it just fucking works
it should self document itself like everything fucking else we have
it will come after the shebang if there is one
lets not reinvent the wheeel either make it look like existing kcl or something users can just get.

anyways, these are now my thoughts.

oh the other win is, this becomes part of the programs AST, making use/imports/assemblies so much easier

After a discussion with @lf94, this relieves many of my concerns 👍
I'm also PRO per-file units, no matter how we do it.
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


text:
Fixes issues with layer reordering

This addresses the issue https://github.com/Kitware/minerva/issues/423.
This basically implements a new logic for calculation the 'stack' value of datasets when reordering.
Issue reproduce:
Add more than three datasets to session layer, reorder layer freely, the map and panel will start to behave unexpectedly.

Fix result:

Sample datasets:
(Any dataset will do, These three are provided for convinience. Rename .txt to .geojson before uploading)
buffer.geojson.txt
intersect.geojson.txt
within.geojson.txt

Screen records added. 🖼

@dorukozturk Thanks 😃

source: gharchive/pull-request

repo: Kitware/minerva

license_type: permissive

license_source: bigquery


text:
Latest release 1.3.4 does not support C++20

Hello,
The latest release does not compile with C++20. It has been fixed in the master for almost 2 years now (see https://github.com/KjellKod/g3log/pull/392). Are you planning to create a release with this support? I am asking because we are using g3log in our software and we work in a regulated environment. We need to have full traceability in the pieces of software we use. And it is difficult to use the master at a given date. A defined version would be much preferred.

Thanks for letting me know. COVID years put a wrench in so many things, including keeping track of g3log releases. I can absolutely do that. I'll create a release with g3log and g3sinks that is based on master and with the full description of the changes since 1.3.4. It should be out before Monday, Nov 7th.

Resolved with: https://github.com/KjellKod/g3log/releases/tag/2.0.1 and https://github.com/KjellKod/g3sinks/releases/tag/2.0.2

source: gharchive/issue

license: unlicense


text:
[Date] Need to be able to deactivate the automatic time zone conversion

Current behaviour
Automatic time zone change : a date is supposedly saved as GMT in the database and converted to all users time zones.
Expected behaviour
I want to be able to deactivate this behaviour.
The Trackit database dates from long before Focus, and all dates are Paris time in the database without any info enabling us to know what time zone the user who entered the date was in.
Users know that dates are Paris time.
So it's kind of a big problem that these dates are converted : it actually makes no sense since the system had been created with fixed dates for Paris time zone.
This change will just puzzle users.
Versions
Focus-core: 0.12.3
Focus-components: 0.8.6

:+1:

@sgoretti https://github.com/KleeGroup/focus-components/blob/develop/src/components/input/date/index.js#L16

Isn't it enough https://github.com/KleeGroup/focus-components/blob/develop/src/components/input/date/index.js#L88

Or this props https://github.com/KleeGroup/focus-components/blob/develop/src/components/input/date/index.js#L19

If any of this works, I'll buy you some cheesecake (or rather, the Trackit team will, since this is not yet a Linkit problem)

@sgoretti Is it working ?

@sgoretti I close it if you disagree don't hesitate to comment this issue.

authors: pierbrisson pierr sgoretti

repo: KleeGroup/focus-components

license: mit


text:
support for typescript

does vue2leaflet support typescript, i don't seem to find any topic about it?

heres a random assortment of types I started yesterday when I started using the library, Ill try make a pr when im finished
`declare module 'vue2-leaflet' {
import Vue from 'vue';
import L from 'leaflet';
interface Control {
position: 'topleft' | 'topright' | 'bottomleft' | 'bottomright';
options: L.ControlOptions;
}
class LCircle extends Vue {}
class LCircleMarker extends Vue {}
class LControl extends Vue implements Control {
position: "topleft" | "topright" | "bottomleft" | "bottomright";
options: L.ControlOptions;
}
class LControlAttribution extends Vue {}
class LControlLayers extends Vue {}
class LControlScale extends Vue {}
class LControlZoom extends Vue implements Control {
position: "topleft" | "topright" | "bottomleft" | "bottomright";
options: L.ControlOptions;
zoomInText: string;
zoomInTitle: string;
zoomOutText: string;
zoomOutTitle: string;
}
class LFeatureGroup extends Vue {}
class LGeoJson extends Vue {}
class LIconDefault extends Vue {}
class LImageOverlay extends Vue {}
class LLayerGroup extends Vue {}
class LMap extends Vue {
// props
// default: () => [0, 0]
center: L.LatLng | [number, number];
// default: null
bounds: any[] | {} | null;
// default: null
maxBounds: any[] | {} | null;
// default: 0
zoom: number;
// default: undefined
minZoom?: number;
// default: undefined
maxZoom?: number;
// default: null
paddingBottomRight: any[] | null;
// default: null
paddingTopLeft: any[] | null;
// default: null
padding: any[] | null;
// default: false
worldCopyJump: boolean;
// default: L.CRS.EPSG3857
crs: L.CRS;
// default: 0
maxBoundsViscosity: number;
// default: {}
options: L.MapOptions;
// data
ready: boolean;
lastSetCenter: L.LatLng | null;
lastSetBounds: any | null;
lastSetZoom: any | null;
layerControl?: any;
layersToAdd: any[];
// methods
registerLayerControl(lControlLayers: any): void;
addLayer(layer: any, alreadyAdded: any): void;
removeLayer(layer: any, alreadyRemoved: any): void;
setZoom(newVal: any, oldVal: any): void;
setCenter(newVal: L.LatLngExpression, oldVal: L.LatLngExpression): void;
setBounds(
newVal: L.LatLngBoundsExpression,
oldVal: L.LatLngBoundsExpression
): void;
setPaddingBottomRight(newVal: any[], oldVal: any[]): void;
setPaddingTopLeft(newVal: any[], oldVal: any[]): void;
setPadding(newVal: any[], oldVal: any[]): void;
fitBounds(bounds: any): void;
}
class LMarker extends Vue {}
class LPolygon extends Vue {}
class LPolyline extends Vue {}
class LPopup extends Vue {}
class LRectangle extends Vue {}
class LTileLayer extends Vue {}
class LTooltip extends Vue {}
class LWMSTileLayer extends Vue {}
type findRealParent = (firstVueParent: any) => any;
type propsBinder = (
vueElement: any,
leafletElement: any,
props: any,
options: any
) => void;
export {
    findRealParent,
    propsBinder,
    LCircle,
    LCircleMarker,
    LControl,
    LControlAttribution,
    LControlLayers,
    LControlScale,
    LControlZoom,
    LFeatureGroup,
    LGeoJson,
    LIconDefault,
    LImageOverlay,
    LLayerGroup,
    LMap,
    LMarker,
    LPolygon,
    LPolyline,
    LPopup,
    LRectangle,
    LTileLayer,
    LTooltip,
    LWMSTileLayer
};

}
`

@HIMISOCOOL Thank you very much! Please take a look at the current master after the refactor it should be easy to define types starting from the mixin :)

wanted to help but it seem he has done everything

its not 100% right now, I only put proper types to the components I am using, the rest are just extending Vue. If you have time you can make types for all the other mixins and post the updated version here

ok, i will get on it tomorrow if i can.

@walidsebai Are you still on this? Would love to see this aswell.

yeah but i'm busy at the moment i will take care of it in 2 week

here is a my file with complete mixins and some component
ps: i received an email with saying @HIMISOCOOL  is making a pr but can't see any of the comment here github bug maybe
`declare module 'vue2-leaflet' {
import Vue from 'vue';
import { PropsDefinition } from 'vue/types/options';
import L, {
PointExpression,
LatLngExpression,
ControlOptions,
LatLngBoundsExpression,
LatLngTuple,
LatLngBounds,
PathOptions,
Layer as LeafLayer
} from 'leaflet';
// borrowed from https://github.com/vuejs/vue-class-component
type VueClass = {
new (...args: any[]): V & Vue;
} & typeof Vue;
function Mixins(CtorA: VueClass): VueClass;
function Mixins<A, B>(CtorA: VueClass, CtorB: VueClass): VueClass<A & B>;
function Mixins<A, B, C>(
CtorA: VueClass,
CtorB: VueClass,
CtorC: VueClass
): VueClass<A & B & C>;
function Mixins<A, B, C, D>(
CtorA: VueClass,
CtorB: VueClass,
CtorC: VueClass,
CtorD: VueClass
): VueClass<A & B & C & D>;
function Mixins<A, B, C, D, E>(
CtorA: VueClass,
CtorB: VueClass,
CtorC: VueClass,
CtorD: VueClass,
CtorE: VueClass
): VueClass<A & B & C & D & E>;
function Mixins(...Ctors: VueClass[]): VueClass;
class LayerGroup extends Mixins(Layer){
/**
* @default null
/
public layerType:string|null;
//doubts
public addLayer(layer: LeafLayer, alreadyAdded: boolean): void;
public removeLayer(layer: Layer, alreadyRemoved: boolean): void;
public setLayerType(newVal: string, oldVal?: string): void;
}
class TileLayer extends Mixins(GridLayer){
//props
/*
* @default false
/
tms:boolean;
/*
* @default false
/
detectRetina:boolean;
/*
* @default ()=>({})
/
options:any;
/*
* @default undefined
*/
layerType?:string;
}
class GridLayer extends Mixins(Layer){
    /**
    * @default 'tilePane'
    */
   pane :string;
    /**
    * @default 1.0
    */
   opacity :number;
    /**
    * @default 1
    */
   zIndex :number;
}
class TileLayerWMS extends Mixins(TileLayer){

   /**
    * @default ''
    */
   layerType :string;

   /**
    * @default ''
    */
   styles :string;

   /**
    * @default 'image/jpeg'
    */
   format :string;

    /**
    * @default undefined
    */
   transparent? :boolean;

    /**
    * @default '1.1.1'
    */
   version :string;

    /**
    * @default false
    */
   upperCase :boolean;
    /**
    * @default null
    */
   crs:any|null;

}

class ImageOverlay extends Mixins(Layer){
    //props
    /**
    * @default undefined
    */
    bounds? :LatLngBounds;
    /**
    * @default undefined
    */
    url? : string;
    /**
     * @default 1.0
     */
    opacity:number;
    /**
     * @default ''
     */
    alt:string;
    /**
     * @default false
     */
    interactive:boolean;
    /**
     * @default false
     */
    crossOrigin:boolean;
    /**
     * @default ''
     */
    errorOverlayUrl:string;
    /**
     * @default 1
     */
    zIndex:number;
    /**
     * @default ''
     */
    className:string;
    setOpacity(opacity: number): this;
    bringToFront(): this;
    bringToBack(): this;
    setUrl(url: string): this;

    /** Update the bounds that this ImageOverlay covers */
    setBounds(bounds: LatLngBounds): this;

    /** Get the bounds that this ImageOverlay covers */
    getBounds(): LatLngBounds;

    /** Get the img element that represents the ImageOverlay on the map */
    getElement(): HTMLImageElement | undefined;

}

class Polyline extends Mixins(Path){
    //props
    /**
     * @default 1.0
     */
    smothFactor: number;
    /**
     * @default false
     */
    noClip: boolean;
    /**
     * @default false
     */
    ready: false;
    setStyle(newVal:PathOptions,oldVal?:PathOptions):void;
    setSmoothFactor(newVal:number,oldVal?:number):void
    setNoClip(newVal:boolean,oldVal?:boolean);
    addLating(latlng: LatLngExpression | LatLngExpression[])
}

class Polygon extends Mixins(Polyline){
    //doubts should return geojson.MultiPolygon or no
    getGeoJSONData():geojson.Polygon | geojson.MultiPolygon ;
}
class Control extends Vue {
    position: 'topleft' | 'topright' | 'bottomleft' | 'bottomright';
    options: ControlOptions;
}
class LayerInteractive extends Vue {
    /**
     * @default true
     */
    interactive: boolean;
    /**
     * @default true
     */
    bubblingMouseEvents: boolean;
}
class Layer extends Vue {
    // props
    /**
     * @default 'overlayPane'
     */
    pane: string;
    /**
     * @default null
     */
    attribution: string | null;
    /**
     * @default null
     */
    name: string | null;
    /**
     * @default true
     */
    visible: boolean;

    // methods
    setAttribution(val: any, old?: any): void;
    setName(newVal: any, oldVal?: any): void;
    setVisible(newVal: any, oldVal?: any): void;
}
class Path extends Mixins(Layer, LayerInteractive) {
    // props
    /**
     * @custom
     * @default null
     */
    lStyle: object;
    /**
     * @custom
     * @default true
     */
    stroke: boolean;
    /**
     * @custom
     * @default '#3388ff'
     */
    color: string;
    /**
     * @custom
     * @default 3
     */
    weight: number;
    /**
     * @custom
     * @default 1.0
     */
    opacity: number;
    /**
     * @custom
     * @default 'round'
     */
    lineCap: string;
    /**
     * @custom
     * @default 'round'
     */
    lineJoin: string;
    /**
     * @custom
     * @default null
     */
    dashArray: string;
    /**
     * @custom
     * @default null
     */
    dashOffset: string;
    /**
     * @custom
     * @default true
     */
    fill: boolean;
    /**
     * @custom
     * @default '#3388ff'
     */
    fillColor: string;
    /**
     * @custom
     * @default 0.2
     */
    fillOpacity: number;
    /**
     * @custom
     * @default 'evenodd'
     */
    fillRule: string;
    /**
     * @custom
     * @default null
     */
    className: string;

    // methods
    setStroke(newVal: any, oldVal?: any): void;
    setWeight(newVal: any, oldVal?: any): void;
    setOpacity(newVal: any, oldVal?: any): void;
    setLineCap(newVal: any, oldVal?: any): void;
    setLineJoin(newVal: any, oldVal?: any): void;
    setDashArray(newVal: any, oldVal?: any): void;
    setDashOffset(newVal: any, oldVal?: any): void;
    setFill(newVal: any, oldVal?: any): void;
    setFillOpacity(newVal: any, oldVal?: any): void;
    setFillRule(newVal: any, oldVal?: any): void;
    setClassName(newVal: any, oldVal?: any): void;
}
class Circle extends Mixins(Path) {
    /**
     * @default null
     */
    radius: number;
}
class Popper extends Vue {
    // props
    /**
     * @default ''
     */
    content: string;
    /**
     * @default {}
     */
    options: any;
    /**
     * @default false
     */
    dynamic: boolean;
    // data
    /**
     * @default false
     */
    ready: boolean;
    // methods
    setContent(): void;
}

//missing
class LGeoJson extends Mixins(LGeoJson) {
}

class LImageOverlay extends Mixins(ImageOverlay) {}

class LLayerGroup extends Mixins(LayerGroup) {
    /**
     * @default false
     */
    public ready:boolean;
}
class LIconDefault extends Vue {
    //props
    /**
     * @default ''
     */
    public imagePath:string;
    public setImagePath (newVal:string , oldVal?:string)
}

class LFeatureGroup extends Mixins(LayerGroup) {
    /**
     * @default false
     */
    ready:boolean;
}
//
//
class LCircle extends Mixins(Circle) {
    // props
    /**
     * @default []
     */
    latLng: L.LatLngExpression;
    // data
    /**
     * @default false
     */
    ready: boolean;
}
class LCircleMarker extends Mixins(Circle) {
    // props
    /**
     * @default []
     */
    latLng: L.LatLngExpression;
    // data
    /**
     * @default false
     */
    ready: boolean;
}
class LControl extends Mixins(Control) {}
class LControlAttribution extends Vue {}
class LControlLayers extends Vue {}
class LControlScale extends Vue {}
class LControlZoom extends Mixins(Control) {
    public zoomInText: string;
    public zoomInTitle: string;
    public zoomOutText: string;
    public zoomOutTitle: string;
}

class LMap extends Vue {
    // props
    /**
     * @default [0, 0]
     */
    public center: LatLngExpression;
    /**
     * @default null
     */
    public bounds: any[] | {} | null;
    /**
     * @default null
     */
    public maxBounds: any[] | {} | null;
    /**
     * @default 0
     */
    public zoom: number;
    /**
     * @default undefined
     */
    public minZoom?: number;
    /**
     * @default undefined
     */
    public maxZoom?: number;
    /**
     * @default null
     */
    public paddingBottomRight: any[] | null;
    /**
     * @default null
     */
    public paddingTopLeft: any[] | null;
    /**
     * @default null
     */
    public padding: any[] | null;
    /**
     * @default false
     */
    public worldCopyJump: boolean;
    /**
     * @default L.CRS.EPSG3857
     */
    public crs: L.CRS;
    /**
     * @default 0
     */
    public maxBoundsViscosity: number;
    /**
     * @default {}
     */
    public options: L.MapOptions;
    // data
    public ready: boolean;
    public lastSetCenter: L.LatLng | null;
    public lastSetBounds: any | null;
    public lastSetZoom: any | null;
    public layerControl?: any;
    public layersToAdd: any[];
    public mapObject: L.Map;
    // methods
    public registerLayerControl(lControlLayers: any): void;

    public addLayer(layer: any, alreadyAdded: any): void;

    public removeLayer(layer: any, alreadyRemoved: any): void;

    public setZoom(newVal: number, oldVal?: number): void;

    public setCenter(newVal: LatLngExpression, oldVal: LatLngExpression): void;

    public setBounds(
        newVal: LatLngBoundsExpression,
        oldVal?: LatLngBoundsExpression
    ): void;

    public setPaddingBottomRight(newVal: any[], oldVal?: any[]): void;

    public setPaddingTopLeft(newVal: any[], oldVal?: any[]): void;

    public setPadding(newVal: any[], oldVal?: any[]): void;

    public fitBounds(bounds: any): void;
}
class LMarker extends Mixins(Layer) {
    // props
    /**
     * @default false
     */
    public draggable: boolean;
    /**
     * @default null
     */
    public latLng: LatLngExpression | null;
    /**
     * @default new L.Icon.Default()
     */
    public icon: L.Icon;
    /**
     * @default null
     */
    public zIndexOffset: number | null;
    /**
     * @default {}
     */
    public options: any;
    // data
    public ready: boolean;
    // methods

    public setDraggable(newVal: boolean, oldVal?: boolean): void;

    public setLatLng(newVal: LatLngExpression): void;
}
class LPolygon extends Vue {}
class LPolyline extends Vue {}

class LPopup extends Mixins(Popper) {
    // props
    /**
     * @default []
     */
    public latLng: LatLngTuple;
}
class LRectangle extends Mixins(Polygon) {}
class LTileLayer extends Vue {}
class LTooltip extends Vue {}
class LWMSTileLayer extends Vue {}
function findRealParent(firstVueParent: Vue): LMap;
function propsBinder(
    vueElement: Vue,
    leafletElement: L.Map,
    props: PropsDefinition<Record<string, any>>,
    options?: any
): void;

export {
    findRealParent,
    propsBinder,
    LCircle,
    LCircleMarker,
    LControl,
    LControlAttribution,
    LControlLayers,
    LControlScale,
    LControlZoom,
    LFeatureGroup,
    LGeoJson,
    LIconDefault,
    LImageOverlay,
    LLayerGroup,
    LMap,
    LMarker,
    LPolygon,
    LPolyline,
    LPopup,
    LRectangle,
    LTileLayer,
    LTooltip,
    LWMSTileLayer
};

}`

If you want to contribute you need to fork the repo and do a branch there and then create a PR :)

this is so scuffed github has really destroyed this thread O_O yeah I tried
to make a pr but it seems to be a ghost just like my replies
On Mon, Oct 22, 2018 at 4:26 PM walidsebai notifications@github.com wrote:

here is a my file with complete mixins and some component
ps: i received an email with saying @HIMISOCOOL
https://github.com/HIMISOCOOL is making a pr but can't see any of the
comment here github bug maybe
`declare module 'vue2-leaflet' {
import Vue from 'vue';
import { PropsDefinition } from 'vue/types/options';
import L, {
PointExpression,
LatLngExpression,
ControlOptions,
LatLngBoundsExpression,
LatLngTuple,
LatLngBounds,
PathOptions,
Layer as LeafLayer
} from 'leaflet';
// borrowed from https://github.com/vuejs/vue-class-component
type VueClass = {
new (...args: any[]): V & Vue;
} & typeof Vue;
function Mixins(CtorA: VueClass): VueClass;
function Mixins<A, B>(CtorA: VueClass, CtorB: VueClass
): VueClass<A & B>; function Mixins<A, B, C>( CtorA: VueClass
, CtorB: VueClass, CtorC: VueClass ): VueClass<A & B & C>; function
Mixins<A, B, C, D>( CtorA: VueClass, CtorB: VueClass, CtorC: VueClass,
CtorD: VueClass ): VueClass<A & B & C & D>; function Mixins<A, B, C, D, E>(
CtorA: VueClass, CtorB: VueClass, CtorC: VueClass, CtorD: VueClass, CtorE:
VueClass ): VueClass<A & B & C & D & E>; function Mixins(...Ctors:
VueClass[]): VueClass; class LayerGroup extends Mixins(Layer){ /* *
@default https://github.com/default null / public layerType:string|null;
//doubts public addLayer(layer: LeafLayer, alreadyAdded: boolean): void;
public removeLayer(layer: Layer, alreadyRemoved: boolean): void; public
setLayerType(newVal: string, oldVal?: string): void; } class TileLayer
extends Mixins(GridLayer){ //props /* * @default
https://github.com/default false / tms:boolean; /* * @default
https://github.com/default false / detectRetina:boolean; /* * @default
https://github.com/default ()=>({}) / options:any; /* * @default
https://github.com/default undefined / layerType?:string; }

class GridLayer extends Mixins(Layer){ /** * @default 'tilePane' / pane
:string; /* * @default 1.0 / opacity :number; /* * @default 1 / zIndex
:number; } class TileLayerWMS extends Mixins(TileLayer){ /* * @default ''
/ layerType :string; /* * @default '' / styles :string; /* * @default
'image/jpeg' / format :string; /* * @default undefined / transparent?
:boolean; /* * @default '1.1.1' / version :string; /* * @default false
/ upperCase :boolean; /* * @default null / crs:any|null; } class
ImageOverlay extends Mixins(Layer){ //props /* * @default undefined /
bounds? :LatLngBounds; /* * @default undefined / url? : string; /* *
@default 1.0 / opacity:number; /* * @default '' / alt:string; /* *
@default false / interactive:boolean; /* * @default false /
crossOrigin:boolean; /* * @default '' / errorOverlayUrl:string; /* *
@default 1 / zIndex:number; /* * @default '' / className:string;
setOpacity(opacity: number): this; bringToFront(): this; bringToBack():
this; setUrl(url: string): this; /* Update the bounds that this
ImageOverlay covers / setBounds(bounds: LatLngBounds): this; /* Get the
bounds that this ImageOverlay covers / getBounds(): LatLngBounds; /* Get
the img element that represents the ImageOverlay on the map /
getElement(): HTMLImageElement | undefined; } class Polyline extends
Mixins(Path){ //props /* * @default 1.0 / smothFactor: number; /* *
@default false / noClip: boolean; /* * @default false / ready: false;
setStyle(newVal:PathOptions,oldVal?:PathOptions):void;
setSmoothFactor(newVal:number,oldVal?:number):void
setNoClip(newVal:boolean,oldVal?:boolean); addLating(latlng:
LatLngExpression | LatLngExpression[]) } class Polygon extends
Mixins(Polyline){ //doubts should return geojson.MultiPolygon or no
getGeoJSONData():geojson.Polygon | geojson.MultiPolygon ; } class Control
extends Vue { position: 'topleft' | 'topright' | 'bottomleft' |
'bottomright'; options: ControlOptions; } class LayerInteractive extends
Vue { /* * @default true / interactive: boolean; /* * @default true /
bubblingMouseEvents: boolean; } class Layer extends Vue { // props /* *
@default 'overlayPane' / pane: string; /* * @default null / attribution:
string | null; /* * @default null / name: string | null; /* * @default
true / visible: boolean; // methods setAttribution(val: any, old?: any):
void; setName(newVal: any, oldVal?: any): void; setVisible(newVal: any,
oldVal?: any): void; } class Path extends Mixins(Layer, LayerInteractive) {
// props /* * @custom * @default null / lStyle: object; /* * @custom *
@default true / stroke: boolean; /* * @custom * @default '#3388ff' /
color: string; /* * @custom * @default 3 / weight: number; /* * @custom
@default 1.0 / opacity: number; /* * @custom * @default 'round' /
lineCap: string; /* * @custom * @default 'round' / lineJoin: string; /*
@custom * @default null / dashArray: string; /* * @custom * @default
null / dashOffset: string; /* * @custom * @default true / fill: boolean;
/* * @custom * @default '#3388ff' / fillColor: string; /* * @custom *
@default 0.2 / fillOpacity: number; /* * @custom * @default 'evenodd' /
fillRule: string; /* * @custom * @default null / className: string; //
methods setStroke(newVal: any, oldVal?: any): void; setWeight(newVal: any,
oldVal?: any): void; setOpacity(newVal: any, oldVal?: any): void;
setLineCap(newVal: any, oldVal?: any): void; setLineJoin(newVal: any,
oldVal?: any): void; setDashArray(newVal: any, oldVal?: any): void;
setDashOffset(newVal: any, oldVal?: any): void; setFill(newVal: any,
oldVal?: any): void; setFillOpacity(newVal: any, oldVal?: any): void;
setFillRule(newVal: any, oldVal?: any): void; setClassName(newVal: any,
oldVal?: any): void; } class Circle extends Mixins(Path) { /* * @default
null / radius: number; } class Popper extends Vue { // props /* *
@default '' / content: string; /* * @default {} / options: any; /* *
@default false / dynamic: boolean; // data /* * @default false / ready:
boolean; // methods setContent(): void; } //missing class LGeoJson extends
Mixins(LGeoJson) { } class LImageOverlay extends Mixins(ImageOverlay) {}
class LLayerGroup extends Mixins(LayerGroup) { /* * @default false /
public ready:boolean; } class LIconDefault extends Vue { //props /* *
@default '' / public imagePath:string; public setImagePath (newVal:string
, oldVal?:string) } class LFeatureGroup extends Mixins(LayerGroup) { /* *
@default false / ready:boolean; } // // class LCircle extends
Mixins(Circle) { // props /* * @default [] / latLng: L.LatLngExpression;
// data /* * @default false / ready: boolean; } class LCircleMarker
extends Mixins(Circle) { // props /* * @default [] / latLng:
L.LatLngExpression; // data /* * @default false / ready: boolean; } class
LControl extends Mixins(Control) {} class LControlAttribution extends Vue
{} class LControlLayers extends Vue {} class LControlScale extends Vue {}
class LControlZoom extends Mixins(Control) { public zoomInText: string;
public zoomInTitle: string; public zoomOutText: string; public
zoomOutTitle: string; } class LMap extends Vue { // props /* * @default
[0, 0] / public center: LatLngExpression; /* * @default null / public
bounds: any[] | {} | null; /* * @default null / public maxBounds: any[] |
{} | null; /* * @default 0 / public zoom: number; /* * @default
undefined / public minZoom?: number; /* * @default undefined / public
maxZoom?: number; /* * @default null / public paddingBottomRight: any[] |
null; /* * @default null / public paddingTopLeft: any[] | null; /* *
@default null / public padding: any[] | null; /* * @default false /
public worldCopyJump: boolean; /* * @default L.CRS.EPSG3857 / public crs:
L.CRS; /* * @default 0 / public maxBoundsViscosity: number; /* *
@default {} / public options: L.MapOptions; // data public ready: boolean;
public lastSetCenter: L.LatLng | null; public lastSetBounds: any | null;
public lastSetZoom: any | null; public layerControl?: any; public
layersToAdd: any[]; public mapObject: L.Map; // methods public
registerLayerControl(lControlLayers: any): void; public addLayer(layer:
any, alreadyAdded: any): void; public removeLayer(layer: any,
alreadyRemoved: any): void; public setZoom(newVal: number, oldVal?:
number): void; public setCenter(newVal: LatLngExpression, oldVal:
LatLngExpression): void; public setBounds( newVal: LatLngBoundsExpression,
oldVal?: LatLngBoundsExpression ): void; public
setPaddingBottomRight(newVal: any[], oldVal?: any[]): void; public
setPaddingTopLeft(newVal: any[], oldVal?: any[]): void; public
setPadding(newVal: any[], oldVal?: any[]): void; public fitBounds(bounds:
any): void; } class LMarker extends Mixins(Layer) { // props /* * @default
false / public draggable: boolean; /* * @default null / public latLng:
LatLngExpression | null; /* * @default new L.Icon.Default() / public
icon: L.Icon; /* * @default null / public zIndexOffset: number | null;
/* * @default {} / public options: any; // data public ready: boolean; //
methods public setDraggable(newVal: boolean, oldVal?: boolean): void;
public setLatLng(newVal: LatLngExpression): void; } class LPolygon extends
Vue {} class LPolyline extends Vue {} class LPopup extends Mixins(Popper) {
// props /* * @default [] / public latLng: LatLngTuple; } class
LRectangle extends Mixins(Polygon) {} class LTileLayer extends Vue {} class
LTooltip extends Vue {} class LWMSTileLayer extends Vue {} function
findRealParent(firstVueParent: Vue): LMap; function propsBinder(
vueElement: Vue, leafletElement: L.Map, props:
PropsDefinition<Record<string, any>>, options?: any ): void; export {
findRealParent, propsBinder, LCircle, LCircleMarker, LControl,
LControlAttribution, LControlLayers, LControlScale, LControlZoom,
LFeatureGroup, LGeoJson, LIconDefault, LImageOverlay, LLayerGroup, LMap,
LMarker, LPolygon, LPolyline, LPopup, LRectangle, LTileLayer, LTooltip,
LWMSTileLayer }; }`

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KoRiGaN/Vue2Leaflet/issues/213#issuecomment-431731527,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABpTdC9j1kCJOBimG68r6TDWu5jS-Dw9ks5unTrpgaJpZM4WWyrN
.

yeah I have a fork, and I branched off next, and then I pushed it up and
github refused to acknowledge it existed. The button to make a PR is
showing now but now that I've made the pr I cannot see it in the list so
idk whats up with Github right now.
On Mon, Oct 22, 2018 at 9:20 PM Nicolò Maria Mezzopera <
notifications@github.com> wrote:

If you want to contribute you need to fork the repo and do a branch there
and then create a PR :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KoRiGaN/Vue2Leaflet/issues/213#issuecomment-431765890,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABpTdNFstDD3noFU0Rwjg0H9al7EcTa_ks5unX-xgaJpZM4WWyrN
.

turns out there was a github outage, just my luck.
anyway #258 is up and ready to review.
@walidsebai has had a quick look, am I missing anything from your types?

@HIMISOCOOL  no i don't thinks so other than more precise type, but we can do that as an enhancement.

fixed by #258

authors: HIMISOCOOL kevcodez lordfuoco walidsebai


text:
Proper Error Handling for Url Parse

See: https://github.com/KodrAus/elasticsearch-rs/blob/master/codegen/src/api/gen/mod.rs#L50

Just use the Chomp ParseError type

repo: KodrAus/elasticsearch-rs


text:
Create 0000-01-02-Kofi91.md

Add Kofi91's file

Merged pull request and deleted branch Project1

license: MIT

license_source: github-api


text:
[kong] add controller to service monitor

What this PR does / why we need it:
Adds the controller metrics port to the controller container template and Prometheus ServiceMonitor template. The port only appears if the controller's major version is >= 2.
Which issue this PR fixes
Part of https://github.com/Kong/kubernetes-ingress-controller/issues/1497
Special notes for your reviewer:
This change imposes new requirements on values. The controller image tag must be semver-compliant. The template will completely fail to render if it is not.
This does not pose issues for our stock image tags, but may affect users who use custom controller images. If they do not currently use semver tags, they must make them semver compliant. IMO this is a reasonable ask: they can use the base image version and include any additional info relevant to their build using semver metadata.
The helper output is annoyingly considered a string, with no available function to convert it to a boolean. Go templates are cumbersome.
Checklist

[x] PR is based off the current tip of the next branch and targets next, not main
[x] New or modified sections of values.yaml are documented in the README.md
[x] Title of the PR and commit headers start with chart name (e.g. [kong])

Bah, yeah, main and next won't work with this.
For custom builds, the ask is that you use semver metadata. If you want to distinguish your custom build in the tag, and not just by using your registry, you'd have something like 2.0.0+foobar to denote that it's a 2.0.0 build that also includes your foobar modification.
We could use something compatible for our bleeding edge tags also (2.1.0-next or whatever), but it doesn't look like there's any simple way to do that with the docker-meta action.
I don't want to add toggles for individual version-dependent features that we want to have on by default on compatible versions. You shouldn't have to cross-reference the chart feature set against controller release notes, and shouldn't have to walk through all the values.yaml settings to toggle on things that you'd expect to be on by default.
I can add an optional user-set value for the controller semver version. If you provide it, we use that for the semver input instead of the tag. You'd only set it if you are using something like next or main. Those should be the minority of deployments by far, and probably mostly only at our instruction (we want someone to test an unreleased feature and ask them to use next in an issue). Not ideal, but it'd allow us to still use version gates without individual feature toggles.

After 98e50e6:
$ helm template ex /tmp/symkong --set serviceMonitor.enabled=true --set ingressController.image.tag=v2.2 --set ingressController.image.effectiveSemver=v2.5.0 | grep -A2 cmetrics
        - name: cmetrics
          containerPort: 10255
          protocol: TCP

$ helm template ex /tmp/symkong --set serviceMonitor.enabled=true --set ingressController.image.tag=vdfgfdgdfg1.2 --set ingressController.image.effectiveSemver=v2.5.0 | grep -A2 cmetrics
        - name: cmetrics
          containerPort: 10255
          protocol: TCP

repo: Kong/charts


text:
Create LICENSE

Add license file from uptream's upstream.

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

I think we can ignore the CLA check in this case; I opened the PR and the Apache license content isn't secret. :)

authors: CLAassistant dannysauer

repo: Kong/docker-pulp


text:
[Fix] KIC: Allowing Multiple Authentication Methods

Description
Update existing Kong Ingress Controller guides for consistency and readability. Audit that all guides work as intended by copy/pasting the instructions.
Testing instructions
Netlify link: https://deploy-preview-6074--kongdocs.netlify.app/kubernetes-ingress-controller/latest/guides/allowing-multiple-authentication-methods/
Checklist

[ ] Review label added
[ ] PR pointed to correct branch (main for immediate publishing, or a release branch: e.g. release/gateway-3.2, `release/deck-1.

AllowingMultipleAuthentication.txt
AllowingMultipleAuthenticationMethods-revised.txt

This is looking much better too. I think the structure could use some rework.
We currently have the following flow:

Install Kong, Configure HTTPBin, Configure Ingress (this is all fine)
Create consumers
Create plugins
Test requests
Create secrets for auth plugins
Add request termination plugin
Test configuration

I think it would be easier to understand in the following format:

Install Kong, Configure HTTPBin, Configure Ingress (this is all fine)
Create consumer-1 secret and KongConsumer
Create consumer-2 secret and KongConsumer
Create plugins
Test requests (show that no-one can authenticate, even with valid credentials)
Create anonymous consumer
Test requests (Show that all requests are allowed, even invalid auth)
Add request termination plugin
Test requests (Show that things work as expected)

Incorporated the new flow in the docs.


text:
feat: Injection Protection plugin for 3.9

Description

Adding the new Injection Protection plugin docs.

DOCU-4148
Testing instructions
Preview link:
Checklist

[x] Review label added
[x] Conditional version tags added, if applicable.

Hi @brentos !
I started drafting some docs for the Injection Protection plugin, but had a few questions:

To what degree is the plugin compatible with DB less? Completely, not at all, or partially?
How do I collect the logs? Where can I view the logs? Are there multiple log types (in the eng brief, I see the log serializer, analytics proto, and Kong error logs)?

To what degree is the plugin compatible with DB less? Completely, not at all, or partially?

Assuming full compatibility unless proven otherwise. I currently can't see any reason that this plugin would have issues in DB-less or hybrid mode.

How do I collect the logs? Where can I view the logs? Are there multiple log types (in the eng brief, I see the log serializer, analytics proto, and Kong error logs)?

I think your list in the intro is currently sufficient. I wouldn't mind seeing a sample log entry, but it shouldn't be an issue if we can't get that for release time.

authors: cloudjumpercat lena-larionova


text:
Official snap on snapcraft.io should be published by Insomnia team/Kong

Expected Behavior
Official snap built on snapcrat.io should be published by the Insomia team/Kong. The publisher should be verified.
Actual Behavior
Snap built is being published by gschier1990, who is not verified.

Reproduction Steps

Go to snapcraft.io
Look for the official snap built

Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
Having an official/verified publisher gives more confidence in the app being downloaded and in the support that could be given.
Insomnia Version
2021.7.2
What operating system are you using?
Ubuntu
Operating System Version
21.10
Installation method
Snap
Last Known Working Insomnia version
2021.7.2

Hi @santiagofn, thank you for reporting this issue!
In the meantime this was fixed, and it's now pointing to getinsomnia as publisher (link).

Feel free to report any other issues you may find on Insomnia, in the meantime we'll also try to update you on the other issues you've raised in the past 👍

authors: filfreire santiagofn

repo: Kong/insomnia


text:
Auto update installs a version unsupported by OS

Expected Behavior
Automatic updates will not be offered if they require an OS version greater than the current one.
Actual Behavior
Insomnia gave me a popup to auto-update to 8.4.0 but then once installed I could no longer open the app since it requires a higher version of MacOS than I am using.
Reproduction Steps
No response
Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
No response
Insomnia Version
8.4.0
What operating system are you using?
macOS
Operating System Version
10.14.6
Installation method
Download originally, auto-update through the app since
Last Known Working Insomnia version
8.3.0

We did update the Electron version to 27.x and it seems like older version of Mac are not supported anymore by Electron itself (well, by Chromium specifically): https://www.electronjs.org/blog/electron-27-0#removed-macos-1013--1014-support
While we would like to have Insomnia run on every version of the OS, we also cannot run on outdated versions of Electron.

That’s fine, but what I’m suggesting is that it should not auto update to a version that is unsupported on the current OS because then there is no way to open the app or revert.

Ah I see what you mean. We are using the auto-updater capability of Electron which determines the updated based on the version alone.
To keep using an older version on an older OS you can manually download the specific version that you want from our releases and disable the auto-updates in the preferences.

authors: dvandersluis subnetmarco


text:
how to remove nested json element using request-transformer

Discussed in https://github.com/Kong/kong/discussions/7863

Originally posted by RahulRdec September 21, 2021
I am able to remove the top level element("kind") but can't remove nested. I want to remove namespace from the below request. I am trying 'spec.namespace' in remove body but isn’t working. any help will be appreciated. Thanks.
"kind":"update"
"spec": {"namespace": "teamname",}

No news about this issue ? I have the same problem, it's not possible to change a nested value in a json body.

Dear contributor,
We're closing this issue as there hasn't been any update to it for a long time. If the issue is still relevant in the latest version, please feel free to reopen it. We're more than happy to revisit it again. Your contribution is greatly appreciated!
Please have a look at our pledge to the community for more information.
Sincerely,
Kong Gateway Team

@RahulRdec @alpes-developpement You could try using https://docs.konghq.com/hub/kong-inc/pre-function/configuration/ or write a custom plugin.
Hope this solves your problem. Please feel free to reopen the issue if you have further concerns.

repo: Kong/kong


text:
fix(plugins) don't call redis:select when not necessary

Summary
In plugin rate-limiting and response-ratelimiting, a redis:select is
called when connection is reused, even though the current configured
redis database is 0, to clear the previously selected database. This
will be problem for some use case like twemproxy where select is
not supported, and sending select call will cause the connection to
be closed.
The patch used a host+port+database based redis connection pool, so that
we always know the current connection is using correct database. The
behaviour of redis:auth only once is not changed.
Full changelog

Use database-based redis connection pool to reduce unnecessary select call

Issues resolved
Related to #3293

Nice catch :) Meant to request some changes, but mis-clicked. Additionally, note that the linter is failing in CI.

@thibaultcha Thank you for reviewing this, I've addressed the comments and CI is green now. Could you take another look when you got chance?

LGTM, however we should wait until our Travis CI issues are resolved before merging this.

@fffonion It should be fine if you rebase this branch on the latest master.

Running green on master!

authors: fffonion hishamhm thibaultcha


text:
feat(balancer) healthcheck uses ip+port+hostname combo

Changes needed for lua-resty-healthcheck 1.0.0 which requires that hostnames
are used combined with IP and port to know exactly which host is being checked.
lua-resty-healthcheck version bumped in rockspeck.

You can squash 6b9d8ec to the commit that is fixes, to avoid adding broken states to the git history (makes it easier to use git bisect later).

minor: in the commit message for 10a0e60: fix(balancer.lua) -> fix(balancer)

note to the team: let's hold merge until the merge-commit above is removed

authors: hishamhm locao


text:
fix(ca_certificates) add digest field for ca_certificates table

Summary
Fix issue for ca_certificates table index which occurs when certificate
is uploaded which index length is more than 2704, index btree supports
only up to 2704 char length.
Solution: Introduce a new field cert_digest and store SHA256(cert) which
should meet btree limitations when records are indexed by this field.
Full changelog

add additional field cert_digest to ca_certificates schema
modify tests

It would help us to hide the digest field from the end-user API.
@bungle How hard is it to have a field defined in the schema but hide it from the API?
@artomal Can you add a check in the code (and a test-case) to reject any request that specify the digest value as part of the request?

@hbagdi Personally I don't think echoing the digest inside the Admin API is a huge issue, it is very customary to use digest as a way of uniquely identifying a certificate. e.g. when viewing certificate details from browsers, certificate digests are usually shown.
That we want to avoid is using attempting to change the content of the field through APIs. As long as we produce a validation error when the field is included inside the request payload it should not hurt to return the value inside the response.

I have another PR with a feature proposal to hide selected fields from API consumers.
https://github.com/Kong/kong/pull/5770

Ping @hishamhm.

Is this defined properly for PATCH and PUT behaviour?
What if I PATCH the calculated cert_digest field without touching the source cert field?

@artomal @kikito I still insist we should at least error out when user attempts to provide the cert_digest field inside Admin API. Silently overriding it makes the field's meaning ambiguous.
Also in the Admin API doc we should emphasize that the field is readonly.

Restoring this branch because I need it for something. Appologies / ignore the noise ;)

authors: Tieske artomal dndx hbagdi hutchic


text:
ci: skip e2es if no GOOGLE_APPLICATION_CREDENTIALS set

Should solve https://github.com/Kong/kubernetes-testing-framework/issues/547.

Codecov Report
Base: 53.73% // Head: 12.34% // Decreases project coverage by -41.40% :warning:

Coverage data is based on head (96f7ada) compared to base (5e7d22e).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff             @@
##             main     #548       +/-   ##
===========================================
- Coverage   53.73%   12.34%   -41.40%
===========================================
  Files          50       50
  Lines        3904     3904
===========================================
- Hits         2098      482     -1616
- Misses       1546     3360     +1814
+ Partials      260       62      -198

Flag
Coverage Δ

integration-test
10.31% <ø> (-48.39%)
:arrow_down:

unit-test
3.27% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

pkg/utils/kubernetes/generators/jobs.go
0.00% <0.00%> (-100.00%)
:arrow_down:

pkg/utils/kubernetes/generators/containers.go
0.00% <0.00%> (-100.00%)
:arrow_down:

pkg/utils/kubernetes/generators/deployment.go
0.00% <0.00%> (-100.00%)
:arrow_down:

pkg/utils/kubernetes/generators/services.go
0.00% <0.00%> (-96.78%)
:arrow_down:

pkg/clusters/addons/istio/builder.go
0.00% <0.00%> (-89.66%)
:arrow_down:

pkg/clusters/addons/registry/builder.go
0.00% <0.00%> (-81.25%)
:arrow_down:

pkg/utils/networking/http.go
0.00% <0.00%> (-75.00%)
:arrow_down:

pkg/clusters/addons/kuma/builder.go
0.00% <0.00%> (-75.00%)
:arrow_down:

pkg/clusters/addons/knative/knative.go
0.00% <0.00%> (-66.42%)
:arrow_down:

pkg/clusters/addons/registry/addon.go
0.00% <0.00%> (-65.27%)
:arrow_down:

... and 27 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

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

authors: codecov-commenter czeslavo

repo: Kong/kubernetes-testing-framework


text:
"Connection Refused" should be caught in "iffailure" chain

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Typically, this is how I would write my request.
Unirest.get("http://localhost:8080/mydata")
                .asJson()
                .ifSuccess(response -> someSuccessMethod(response))
                .ifFailure(response -> {
                    log.error("Oh No! Status" + response.getStatus());
                    response.getParsingError().ifPresent(e -> {
                        log.error("Parsing Exception: ", e);
                        log.error("Original body: " + e.getOriginalBody());
                    });
                });

However, I've noticed that, in the event that there is a "connection refused" exception, probably because the service on 8080 isn't running, or 8080 isn't open, the exception isn't caught in the iffailure chain.
I expect this should happen. Plus, it keeps our codes cleaner. The alternative is to start wrapping the whole thing in try-catch, which can be very messy.

We do have a solution to this problem but it might not be immediately apparent. a little background first:
Unirest has traditionally always thrown request failures as UnirestExceptions. I imagine there are already lots of code out there with Unirest in a try/catch so changing that by default would be a breaking change (maybe not a terrible one but one nonetheless)
ifFailure processes a failed HttpResponse, in the case of a connection failure we don't have a response, we have a failed request. We could construct a failed response that that would be a lie or we can just pass null but that gives you no information. So...
Unirest has an interceptor starting in 3.2.00 that can handle a failed request. You can choose to either return null, throw (the default) or return a FailedResponse which would then also be processed if ifFailure.
I've considered exposing config options for these options with the default interceptor but right now you need to configure your own.
see https://github.com/Kong/unirest-java/blob/master/unirest/src/test/java/BehaviorTests/InterceptorTest.java#L170-L175

You're absolutely right. I just went through the post you put up and tested it myself. Works like a charm. Thanks!

authors: ryber teamlead-agbaje

repo: Kong/unirest-java


text:
Upgrade UI - Screen Account / Add

Design: https://www.figma.com/file/2nYhrm0rlJtfJoMwrT51Ep/SubWallet-Apps?node-id=842%3A53042&t=QB7ZXiO1e8uOeewa-4

Version test: https://file.cdmteck.com/s/4oimk9zDJ8R5Aai/download?path=%2F&files=./1047-merge-build-0.8.1-1677006965970.zip
Please check:
Select account screen

[ ] Upgrade UI follow by Design

On the create new account

[ ] Still enable button confirm when do not select account type

Expected: If do not select account type -> Disable button Confirm

[ ] Sequence number of seed phrase

Version test: https://file.cdmteck.com/s/4oimk9zDJ8R5Aai/download?path=%2F&files=./1055-merge-build-0.8.1-1677562303221.zip
Please check:

[ ] Disable button in case don't select account type

[ ] Add checkbox Import multiple accounts from this seed phrase in Import from seed phrase screen

[ ] Upgrade UI for design

Version test: https://file.cdmteck.com/s/4oimk9zDJ8R5Aai/download?path=%2F&files=./upgrade-ui-build-0.8.1-1678083121116.zip

[ ] Update format account after enter address

Version test: https://drive.google.com/drive/folders/1T4V5FUrgmeSGKiQdlQ6yGbDK0wxIh4LF?usp=share_link
Please check:
Handle cases related to Ledger account:

[ ] Do not show more than 20 account when attach account
[ ] Do not display tokens other than those that Ledger account is supporting:
List token on the token tab
Receive: automatically show the QR code screen of the supported token
Transfer: fixed the supported token
Buy token: fixed the supported token
Staking action: fixed the supported token

Version test: https://file.cdmteck.com/s/4oimk9zDJ8R5Aai/download?path=%2F&files=./1083-merge-build-0.8.1-1678780061728.zip
Please check:

[ ] Update UI incase import single account by JSON file follow by design:  https://www.figma.com/file/2nYhrm0rlJtfJoMwrT51Ep/SubWallet-Apps?node-id=2406%3A66561&t=7YfOwmefFI5o4Th8-4

Version test:

[ ] Handle case attach Ledger account on the first time when user standing on the popup extension

[ ] UI bug

[ ] Still show error message when back to the previous screen

[ ] Incorrect color of the Scan button (update design system, need update in library)

Version test:

[ ] Navigate to the incorrect screen in case create new account from Welcome screen
Actual: Navigate to the Create new account
Expected: Navigate to the Select account type popup

Version test: https://file.cdmteck.com/s/4oimk9zDJ8R5Aai/download?path=%2F&files=./1090-merge-build-0.8.1-1679055190508.zip

[ ] Update style on the Imported account list when import multi account by JSON file

Version test: https://file.cdmteck.com/s/4oimk9zDJ8R5Aai/download?path=%2F&files=./upgrade-ui-build-0.8.1-1679306339002.zip

[ ] Re-check attach account Connect Keystone device
Actual: Do not show message Invalid QR

repo: Koniverse/SubWallet-Extension


text:
Handle the case of auto lock after importing multi account

Describe the bug
Handle the case of auto lock after importing multi account
Version test: v1.1.0(220)
Device test: IP 11
To reproduce the bug
Pre-condition: Setting Require unlock = Always
Steps:

Go to Import account screen
Perform import multi-account by Polkadot{js}
In Apply master password step, forget 1 account
Perform derive account and observe the displayed screen

Actual: Do not require master password after import multi account
Expect: Auto lock after import multi account

Version test: https://file.cdmteck.com/s/DB9JLAnjJczopcC/download?path=%2F&files=SubWalletMobile-build-220-1036-merge-2023-09-21T11-04-16.ipa
Device test: IP 11
Validation passed.

repo: Koniverse/SubWallet-Mobile


text:
Mobile - Show incorrect tokens on the balance screen in case an account with the type 'ed25519' is imported

Describe the bug
Show incorrect tokens on the balance screen in case an account with the type 'ed25519' is imported
To reproduce the bug
Actual: Import an account with the type 'ed25519' and then check the balance screen. Ethereum tokens still show.
Expect: Hide Ethereum tokens on the balance screen

Version test: https://file.cdmteck.com/s/DB9JLAnjJczopcC/download?path=%2F&files=SubWalletMobile-build-311-1443-merge-2024-02-03T08-33-37.ipa
Device test: IP 11
Validation passed.


text:
Håndter DB-schema mere generisk i test-situationen

Closes #257

Jf. min kommentar under #257: Løsningen er fin, men titlen er ikke dækkende.

men titlen er ikke dækkende.

foreslå gerne en bedre titel

foreslå gerne en bedre titel

Brug klasseglobal variabel til styring af tabel-præfiks?

Global er jo ikke ganske korrekt og klassevariabel kan være pr. instans. Så i mangel af bedre: Klasseglobal. Har du bedre betegnelser?
... jeg er lidt i tvivl om PEP8 her, men for mig ser _exe_opt ud som en konstant og burde vel derfor hedde _EXE_OPT? Det er vel i hvert fald ikke meningen at man skal kunne pille ved den. I så fald: Brug klassespecifik konstant til styring af tabel-præfiks

Nåh jo - jf ovenstående er jeg naturligvis heller ikke enig i at "#258 closes #257". Der er lang vej til. Men #258 repræsenterer et alternativt udgangspunkt ifht #256.

Har du bedre betegnelser?

Nej, så lad os bare køre med den. Jeg synes det er til at forstå, også selvom det måske ikke er 100 procent korrekt

jeg er lidt i tvivl om PEP8 her

Det forstår jeg godt. Jeg tror ikke der er et helt rigtigt svar her, så det må være bedste skøn. Jeg skrev den må små bogstaver fordi er muligt, men frarådet, at ændre værdien. Jeg kan godt forestille mig at det kunne blive aktuelt i forbindelse med tests af nye databaseopsætninger, hvor noget lige hurtigt skal bekræftes vha af et stand-alone script. Det vil ske yderst sjældent, men meget lækkert lige at kunne når behovet er der.

jf ovenstående er jeg naturligvis heller ikke enig i at "#258 closes #257".

Det har du ret i. Det var egentligt også bare tænkt som en henvisning, jeg skulle bare have undlast "closes" (gammel vane).

authors: busstoptaktik kbevers

repo: Kortforsyningen/FIRE


text:
Right to left support

How do I support RTL layouts?

consider this layout:

verticalLayout {
    textView {
            text = "whatewer"
            textSize = ...
        }
}

set android:supportsRtl="true" in the manifest in application tag.

go to developer settings on the device and check "force RTL layout direction". The textview should be aligned on the right, but it's not and documentation doesn't mention anything about supporting RTL.

@cuddlecheek check this post: http://yaronvazana.com/2015/10/29/adding-rtl-support-to-your-android-app-tutorial/
All you need to do is set marginStart, marginEnd, paddingStart, paddingEnd etc.
where:
start is a position left on the phones with RTL support enabled.
end is a position right on the phones with RTL support enabled.

@piotrek1543 This isn't what I meant. I know how start/end properties work. I was talking about the Android layout mirroring. It is mentioned in your post too:

Android automatically mirrors your layout, just make sure you’re satisfied with the result. In case something went wrong, try to replace elements with other supported and newer once. I found the LinearLayout and the RelativeLayout to work perfectly.

However, I didn't realize that the layout mirroring in LinearLayout won't work when orientation vertical is set. Which means I'll close this issue anyway.

repo: Kotlin/anko


text:
Spartan Weaponry was updated to 1.18.2 [SUGGESTION]

Hey. So I just found out that Spartan Weaponry has been updated to 1.18.2. Along with that, Ice and Fire are also updated to 1.18.2. So with that information, I would like to ask if there are any plans to update this mod to 1.18.2? It would be really awesome if that happened.

I will definitely update all of my Spartan Weaponry addons to 1.18.2 but it probably won't be soon.

authors: GhostLupine KreloX

repo: KreloX/SpartanFire


text:
merge package from arlac77/npm-package-template

package.json

chore(package): esm@^3.2.4
chore(scripts): cover@#overwrite c8 --temp-directory build/coverage ava && c8 report -r lcov --temp-directory build/coverage
chore(package): add nyc from template
chore(package): set $.ava.require='esm' as in template
chore(package): set $.ava.files='tests/-test.js,tests/-test.mjs' as in template
chore(package): set $.ava.extensions='js,mjs' as in template

:tada: This PR is included in version 2.20.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


text:
Add sounds from 2023.06.10 folder

I have a series of dated folders in which I collected clips, but kept procrastinating.  This is one of them.  Maybe making this issue will kick me in the ass and get me to finally do it.

I took 24 separate raw clips from the audio I collected on this date.  Whether they all make it into the pack or not is anybody's guess...

repo: Kuoxsr/fhb-villager-sounds


text:
Use react-navigation-parser in web

Hey @Kureev the project is great, you have set a good point here.
When react-navigation was released I played for a while doing react-navigation-web as an experiment to see if possible develop missing built in views for web.
Now I find this library could be great to parse and identify everything related to the scene/card.
Do you have an starting point or suggestion on how should that be done?

Hi @agrcrobles! Thanks for the warm words!
What exactly do you want to parse? Configuration for the routes etc?

exactly, any information I can get on runtime of how routes are configurated on web ( ie, title or path ) I should say that is a great start

This can currently not supported, but I'd like to implement it. If you want to make a PR, the best place to implement it is here https://github.com/Kureev/react-navigation-parser/blob/master/src/parser/resolveRoute.js. Otherwise, just let me know and I'll try to do my best implementing it asap

authors: Kureev agrcrobles

repo: Kureev/react-navigation-parser


text:
Display futures position indicators on chart

Description

When no position open it will display potential position of entry and liquidation with dashed line as the user adjusts the amount
When a user has a position open it will display the entry and liquidation points for that position
Modifying a position when there is already a position open will update the indicators to show new liquidation and the potential average entry

Related issue
https://github.com/Kwenta/kwenta/issues/693

@el0x1 Thank you!  Could you resolve the conflicts?
Once done it gets my stamp of approval 👍

@platschi conflicts now resolved

repo: Kwenta/kwenta


text:
Strange tensor flow error due to an argument

Hello,
First of all, thank you for your effort with the open-source TTS projects.
As summary, I'm trying to create a TTS of Spanish language using your open-source dc_tts.
To do that, I want to train in my laptop the net that you uploaded as "pre-trained net" in order to know if I will be able to train my own network for spanish (once I have the spanish database correctly), but I get an error of tensorflow due to an argument. I have all the libraries correctly installed and the LJ database downloaded.
The only thing that I did was to download the repository, fix correctly the database paths (LJ) and run the train script with parameter "1".
C:\tf_jenkins\home\workspace\rel-win\M\windows\PY\36\tensorflow\core\framework\op_kernel.cc:1192] Invalid argument: TypeError: a bytes-like object is required, not 'str'
Thank you!

Hello, I'm encountering the same issue !
I'm on Windows 7 working with conda.
The synthetize script worked like a charm on the first try, but I'm still struggling with the same error as @alvaroromerosc .

A quick update,
I can't get tensorflow working on windows with python 27, @Kyubyong, could you point me in the right direction to update your code so it would be compatible with python 3.6 ?
Thanks a lot !

Hello,
I had the same issue with linux in python 3.
In my case, it comes from data_load.py (https://github.com/Kyubyong/dc_tts/blob/master/data_load.py)
Following your link that explain the issue, I searched how to convert bytes to string in python 3:
https://stackoverflow.com/questions/606191/convert-bytes-to-a-string
I replaced:
mel = "mels/{}".format(fname.replace("wav", "npy"))
mag = "mags/{}".format(fname.replace("wav", "npy"))
by
mel = "mels/{}".format(fname.decode("utf-8").replace("wav", "npy"))
mag = "mags/{}".format(fname.decode("utf-8").replace("wav", "npy"))
And it seems to work.
(Maybe it would be better to use try: ... except TypeError: ...)

authors: Sladix alvaroromerosc noetits


text:
Keybinds are system wide

🐞 bug report
Describe the bug
The default hotkeyfor "Evaluate Translate Settings" conflicts with Chrome's new tab hotkey. PoE-Overlay should release hotkeys if Path of Exile is not focused to allow other applications to receive these hotkeys.
Additionally, it does not appear possible to unbind a default hotkey. For features that won't be used some junk hotkey must be used, reducing the total number of available hotkeys for other functions. This may seem like a non-issue, but the number of times I've accidentally activated nVidia recording for accidentally bumping into its junk hotkey is too damn high.
To Reproduce
Use PoE-Overlay bound hotkeys in other applications.
Expected behavior
Other application should receive the key event.
🌍  Your Environment

OS: Windows 10 x64
Version: 0.6.14
PoE: release tags/3.10.1 (standalone)

Hi, thanks for creating an issue. This is related to #485 . A fix will be provided with the next version.

0.6.15 (2020-03-27)

fix poe overlay does not recognize if poe is no longer active (#485, #486)


text:
Add conda env setup

Adding two files to help setting up a conda environment setup that will run all of the fMRI notebooks:  environment.yaml and setup.sh.
Example usage (added to README):
conda create -n medical-v1 python=3.10
conda activate medical-v1
conda env update -f environment.yaml
# this one must be run individually since it uses git
pip install git+https://github.com/openai/CLIP.git

The setup.sh script list the conda and pip commands to create this environment.

Looks good, thanks for adding this!!

authors: PaulScotti jimgoo

repo: LAION-AI/medical