Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 12:42
    MAKolker starred angularsen/UnitsNet
  • 12:04
    duaned starred angularsen/UnitsNet
  • 08:15
    gavinharrison starred angularsen/UnitsNet
  • May 13 20:33
    chowarth starred angularsen/UnitsNet
  • May 13 20:14
    codecov[bot] commented #1084
  • May 13 20:06
    AndreasLeeb opened #1084
  • May 13 18:09
    codecov[bot] commented #1083
  • May 13 18:07
    codecov[bot] commented #1083
  • May 13 18:07
    codecov[bot] commented #1083
  • May 13 17:15
    AndreasLeeb edited #1083
  • May 13 17:08
    AndreasLeeb opened #1083
  • May 13 10:16
    Werbaer-bot labeled #1082
  • May 13 10:16
    Werbaer-bot opened #1082
  • May 13 08:46
    KZajdel commented #1077
  • May 13 08:22
    DanielBuchberger labeled #1081
  • May 13 08:22
    DanielBuchberger opened #1081
  • May 13 07:39
    codecov[bot] commented #1079
  • May 13 07:39
    codecov[bot] commented #1079
  • May 13 07:39
    codecov[bot] commented #1079
  • May 13 06:41
    codecov[bot] commented #1079
Tristan Milnthorp
@tmilnthorp
but those all fail
why is that?
Ohhh. It is using an old version of JSonNet, I see
what's the purpose of that?
I cant change the namespace if that's the case as it assumes the namespace in the built code
shouldn't that assembly be tied to the same version of UnitsNet?
Andreas Gullberg Larsen
@angularsen
Replied in the issue
Tristan Milnthorp
@tmilnthorp
I think those tests seem wrong :)
Andreas Gullberg Larsen
@angularsen
Sounds like it
Agree it should have deserialized some old strings of json, using new serializer, as well as deserialized new strings of json using old serializer
If the latter test breaks, then we need to bump the json lib major version, but we really should avoid that because that will be a pain in the ass for those who use it
Tristan Milnthorp
@tmilnthorp
Deserialize new strings? We want forward compatibility?
Tristan Milnthorp
@tmilnthorp
So I wrote some code to generate the overloads based on the BaseDimensons... oh boy...
Pressure = Acceleration AreaDensity
SpecificWeight = Acceleration
Density
Speed = Acceleration Duration
HeatFlux = Acceleration
DynamicViscosity
Irradiance = Acceleration DynamicViscosity
Speed = Acceleration / Frequency
SpecificEntropy = Acceleration / LapseRate
SpecificEnergy = Acceleration
Length
RotationalAcceleration = Acceleration / Length
ForcePerLength = Acceleration LinearDensity
Irradiation = Acceleration
LinearDensity
Force = Acceleration Mass
RotationalStiffnessPerLength = Acceleration
Mass
ForceChangeRate = Acceleration MassFlow
PowerDensity = Acceleration
MassFlux
PressureChangeRate = Acceleration MassFlux
Length = Acceleration / RotationalAcceleration
Speed = Acceleration / RotationalSpeed
LapseRate = Acceleration / SpecificEntropy
SpecificWeight = Acceleration / SpecificVolume
SpecificVolume = Acceleration / SpecificWeight
Frequency = Acceleration / Speed
RotationalSpeed = Acceleration / Speed
ApparentEnergy = AmountOfSubstance
MolarEnergy
Energy = AmountOfSubstance MolarEnergy
RotationalStiffness = AmountOfSubstance
MolarEnergy
Torque = AmountOfSubstance MolarEnergy
Entropy = AmountOfSubstance
MolarEntropy
Volume = AmountOfSubstance / Molarity
Mass = AmountOfSubstance MolarMass
Molarity = AmountOfSubstance / Volume
MolarEnergy = ApparentEnergy / AmountOfSubstance
Duration = ApparentEnergy / ApparentPower
ForcePerLength = ApparentEnergy / Area
Irradiation = ApparentEnergy / Area
SpecificWeight = ApparentEnergy / AreaMomentOfInertia
Mass = ApparentEnergy
BrakeSpecificFuelConsumption
ReactiveEnergy = ApparentEnergy Duration
ApparentPower = ApparentEnergy / Duration
Power = ApparentEnergy / Duration
ReactivePower = ApparentEnergy / Duration
VolumeFlow = ApparentEnergy / DynamicViscosity
ElectricPotential = ApparentEnergy / ElectricCharge
MagneticFlux = ApparentEnergy / ElectricCurrent
ElectricCharge = ApparentEnergy / ElectricPotential
Temperature = ApparentEnergy / Entropy
Length = ApparentEnergy / Force
Area = ApparentEnergy / ForcePerLength
ApparentPower = ApparentEnergy
Frequency
Power = ApparentEnergy Frequency
ReactivePower = ApparentEnergy
Frequency
ReactiveEnergy = ApparentEnergy / Frequency
Area = ApparentEnergy / Irradiation
MassFlow = ApparentEnergy / KinematicViscosity
Force = ApparentEnergy / Length
RotationalStiffnessPerLength = ApparentEnergy / Length
ElectricCurrent = ApparentEnergy / MagneticFlux
SpecificEnergy = ApparentEnergy / Mass
KinematicViscosity = ApparentEnergy / MassFlow
RotationalAcceleration = ApparentEnergy / MassMomentOfInertia
AmountOfSubstance = ApparentEnergy / MolarEnergy
Duration = ApparentEnergy / Power
Volume = ApparentEnergy / Pressure
Frequency = ApparentEnergy / ReactiveEnergy
RotationalSpeed = ApparentEnergy / ReactiveEnergy
Duration = ApparentEnergy / ReactivePower
MassMomentOfInertia = ApparentEnergy / RotationalAcceleration
ApparentPower = ApparentEnergy RotationalSpeed
Power = ApparentEnergy
RotationalSpeed
ReactivePower = ApparentEnergy RotationalSpeed
ReactiveEnergy = ApparentEnergy / RotationalSpeed
Length = ApparentEnergy / RotationalStiffnessPerLength
Mass = ApparentEnergy / SpecificEnergy
AreaMomentOfInertia = ApparentEnergy / SpecificWeight
Entropy = ApparentEnergy / Temperature
Pressure = ApparentEnergy / Volume
DynamicViscosity = ApparentEnergy / VolumeFlow
Frequency = ApparentPower / ApparentEnergy
RotationalSpeed = ApparentPower / ApparentEnergy
HeatFlux = ApparentPower / Area
Irradiance = ApparentPower / Area
MassFlow = ApparentPower
BrakeSpecificFuelConsumption
ApparentEnergy = ApparentPower Duration
Energy = ApparentPower
Duration
RotationalStiffness = ApparentPower Duration
Torque = ApparentPower
Duration
ElectricPotential = ApparentPower / ElectricCurrent
MagneticFlux = ApparentPower / ElectricCurrentGradient
ElectricCurrent = ApparentPower / ElectricPotential
Frequency = ApparentPower / Energy
RotationalSpeed = ApparentPower / Energy
TemperatureChangeRate = ApparentPower / Entropy
Speed = ApparentPower / Force
Length = ApparentPower / ForceChangeRate
KinematicViscosity = ApparentPowe
It truncates the list... hahaha
Tristan Milnthorp
@tmilnthorp
Had to delete :) small bug in code
Andreas Gullberg Larsen
@angularsen
Haha wow

Deserialize new strings? We want forward compatibility?

If we can, that would be nice. Otherwise we need to bump major version of serialization lib too, and it just introduces pain for those who actually use it for any kind of persistence

Tristan Milnthorp
@tmilnthorp
Right now it hasn't changed. The issue is the fact it references an old converter with the latest UnitsNet. What should we do?
Andreas Gullberg Larsen
@angularsen
I'm on a workshop this weekend and don't have all the pieces in my mind, but I would think something like this:
  1. A test that uses v3 dll of JSON serializer to serialize "current" quantities and can deserialize again
  2. A test that uses "current" JSON code to serialize "current" quantities and can deserialize again
  3. A test that deserializes a "v3" JSON string into "current" quantities using "current" JSON code
Andreas Gullberg Larsen
@angularsen
Also, I bumped json serializer major version (alpha), but unless we need to I think we should not actually bump the major version on it
Andreas Gullberg Larsen
@angularsen
@tmilnthorp This was posted recently, a lot of good stuff there, but I was surprised to find the recommendation is to use strong name signing (and not offer a UnitsNet.Signed package). I'm thinking maybe we should address this in v4.0? It's not a breaking change though, I think(?), so we can possibly do it later.
https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/
Tristan Milnthorp
@tmilnthorp
I think that's a good idea
Andreas Gullberg Larsen
@angularsen

Just realized in #561 :
I wonder if we should change from prefix to suffix on unit variants.
GallonsUsPerMinute vs UsGallonsPerMinute
KilogallonsUsPerMinute vs KilousgallonsPerMinute
FootUsSurvey vs UsSurveyFoot
etc..

Pros: Works better with prefixes like kilo and mega
Cons: Does not read as naturally

Thoughts?

Tristan Milnthorp
@tmilnthorp
Generally they are for imperial so not even sure why a kilo/mega prefix would apply but
UsGallonsPerMinute is definitely more readable
Andreas Gullberg Larsen
@angularsen
Right, let's just keep it then
Andreas Gullberg Larsen
@angularsen
@/all 4.0.0 stable nuget is now out. Merged v4 branch and updated README.
Andreas Gullberg Larsen
@angularsen
It's quiet in here, but Merry Christmas anyway! :-)
Tristan Milnthorp
@tmilnthorp
Merry Christmas!
Been quite busy. Hoping to get more involved again after the new year! Hope all is well!
Andreas Gullberg Larsen
@angularsen
Same her, I'm doubling down on a VR game project. Originally aimed for a Christmas early-access, but failed miserably.
The forever curse of too few hours in a day and not in touch with the reality of my own capabilities and how long things take.
I wonder if it would be worth investigating? Not sure if it would even give us any benefits over AppVeyor but interesting.
Andreas Gullberg Larsen
@angularsen
I like Azure DevOps and its pipelines, but I'm honestly not sure if it's worth switching. AppVeyor works pretty good I think, build times are reasonable and it's free.
I also got a Beta invite to GitHub's shiny new CI/CD solution named "Actions". It can solve the same thing, but again, I'm not sure it's worth switching just for the sake of switching to a newer, shinier thing.
If you want to give it a try and see how it works and compare it against AppVeyor, please do, and if it does bring something new to the table we can benefit from I'm happy to switch.
@tmilnthorp Not sure if I need to mention you or not, but I replied above.
Rafael Gomez
@rgomez90

@angularsen is there a way to get a list of culturized UnitInfos names?

Calling ' ToString()' on a quantity will give me, the culturized abbreviation, but how can I get the culturized Unit name (if possible)?

If not possible, I suppose best way would be to create dicctionaries containing the unitInfos names as keys and the culturized names as values?

Andreas Gullberg Larsen
@angularsen
Hi @rgomez90 I don't believe we have this capability right now. There have been some discussions about adding it, but no one is currently championing it. If you would like to give it a go, create an issue with a short summary of the changes you would like to make then we'll review and discuss a bit before you do a pull request. I'm happy to assist if you have any questions.
@rgomez90 Here is the discussion I recalled:
angularsen/UnitsNet#397
Rafael Gomez
@rgomez90
@angularsen thank you, will take a look at the conversation. If I can handle it, I'll give it a go.
Arnt Emmanuel Berge
@ArntB
Hi, I have a question about QuantityType. I Se that it is generated code. And that the enum starts at 0. Will the numbers for the enums change if a new UOM is added?
Andreas Gullberg Larsen
@angularsen
Hi, yes there is no guarantee that numbers won't change. Don't use it for serializing values and expect to be able to read it back later.
There is a UnitsNet.Serialization.JsonNet nuget that tries to offer a robust package for serializing to JSON.
But I generally recommend you roll your own types for persistence.
Skeferstat
@Skeferstat
Hello, if I want to parse a string "5 см" (Russian) and convert it to millimeters, how can I do it?
Thanks!
Andreas Gullberg Larsen
@angularsen
@Skeferstat Hi, try Length.Parse("5 см", CultureInfo.GetCultureInfo("ru-RU")).ToUnit(LengthUnit.Millimeter)
it seems culture "ru" does not work, so it is currently a bit picky about specifying the exact culture-region
Alex Hadar
@hadar_alex_twitter
Hello ! Do I have any chance to extend this library ? I want to implement IXmlSerializable in order to parse the units using XmlSerializer from Microsoft. It is enough for me to have something like 5V for 5 volts