I try to make convex lense. But not using SVGimages or other things. I want to define it in a class But ı'll get a black screen image. What should ı do? Ok, ı can fix it like following: a=ArcBetweenPoints(ORIGIN, UP, self.rad) and b=ArcBetweenPoints(UP, ORIGIN, self.rad) then add self.add(a,b). Ok, there is no problem. But why the self.add() wasn't used in Circle(Arc) class that was defined in manim packages. How can it work?
Here is the code:
class YaşamÇiçeği(Mobject):
CONFIG = {
"rad" : TAU / 6,
}
def __init__(self, **kwargs):
Mobject.__init__(self)
ArcBetweenPoints(ORIGIN, UP, self.rad)
ArcBetweenPoints(UP, ORIGIN, self.rad)
All geometric figures are VMobjects, that is, Bezier curves. These VMobjects have a special method called generate_points, in the case of Arc is this.
The Circle class is a subclass of Arc (a particular case where Arc=360º), so you don't need to use the "add" method, both VMobjects and VGroups can also be containers, but the advantage of VMobjects is that you can explicitly define the shape of the paths. I recommend that you watch this video that I have already done so you can give yourself a better idea.
Recommendations: Do not use non-English symbols, it can bring you problems in the compilation. Also give a correct format to your code, learn the basics of Markdown in 5 minutes here.
Related
I'm making a health app, and thought it would be nice to create some custom HKUnit to represent some data by extending HKUnit, but HealthKit documentation says we shouldn't extend or subclass it, so I went to Measurements (Dimension) to try creating a custom Unit.
Basically, creating a custom unit generally means to use a basic unit type (unitduration, length, mass, energy, etc) and a coefficient (converter).
But how about when there isn't a type compatible with this unit?
Example: I want to create a BMI unit (kg/m^2 or equivalent) and BMR (Kcal/day), etc.
So maybe a MetabolicUnit class with class vars such as bmi, bmr, etc ... As for unit, hopefully using the dividedBy and multipliedBy to get translated units automatically.
Any advice, good practices or already solved code?
Being a fairly new framework with a too common name, it's hard to find anything meaningful.
Thanks
You can create an instance of HKUnit that represents BMI without subclassing or extending HKUnit. Here are two examples of how:
let bmiUnit = HKUnit(from: "kg/m^2")
Or
let meter = HKUnit.meter()
let bmiUnit = HKUnit.gramUnit(with: .kilo).unitDivided(by: meter).unitDivided(by: meter)
In stylus, when trying to make mixins with transform translate() - or any other multipart rules...
I get: "Maximum stylus call stack size exceeded at "
scale(n)
transform scale(n)
scale()
transform scale(arguments)
(tried a bunch of stuff...)
Here is an example CodePen
Yep, if you're trying to produce the value with the same function as the one you're calling, you should output it literally, like this:
scale(n)
transform 'scale(%s)' % n
This way it would output the ident entity and won't call the scale function, so there won't be any infinite loops.
This is what I found. I had made mixins for each, but I forgot that they override each other. So, this seems like the best option for me.
transform(value)
transform: value
.thing
background red
width 3rem
height 3rem
transform( translate(20%,20%) scale(1.2) rotate(98deg) )
if you define your mixin func name with a builtin css method, you may get this error. for example:
rotate($angular) // mixin func name
transform rotate($angular) // rotate is a builtin css method, but stylus treats this "rotate" as a mixin usage, which makes a dead loop.
My question is how to program in Python (2.6) a function that uses a namespace of an object, while the function is defined outside the object/class. In addition, that function should only change the variables in the object's namespace; it should not take over the namespace (because with multiple objects they will all use the same namespace).
My reason for pursuing this, is because I wish to write a very small class, where during construction all necessary functions for future use are already given and subsequent function calls (self.__call__) on the object itself can be directly applied.
I realize that this idea is not very pythonic (as they say), and I have thought of various other solutions (such as putting the functions in another class and connecting them), but I can't help but feel that each of these solutions is a lot more work than I would think makes sense.
One simple way that accomplishes what I want is the following:
class A:
def __init__(self, some_dict, func_a):
self.memory = some_dict
self.__call__ = func_a
def test_func(obj, some_input):
if some_input in obj.memory :
return obj.memory[some_input]
else :
obj.memory[some_input] = 0. # some default value
return 0.
first_object = A({}, test_func)
print first_object(first_object, '3')
This will work fine, but what aches me is that when I make function calls to the object, I will also have to give the object itself (see the last line). I hope to be able make calls as such:
print first_object('3')
So far, my ideas were unsuccesful to avoid this (e.g. copying the function method and link its namespace by self.__call__.memory = self.memory). I wish to find something to change the def __init__ part to 'adopt' a function and link their namespaces.
I have rigorously searched for an answer on the internet, but a definite solution has not yet been found. The following http://www.velocityreviews.com/forums/t738476-inserting-class-namespace-into-method-scope.html seeks the same, but is also not succesfull.
Anyone have a solution to tackle this?
Let's say I have the next groovy code snippet:
def weightArg = args[0]
class Box {
def width
def height
def double weight() {
//I want to return the value of weightArg here. How can I do that?
}
}
I want to let my class Box use some variables from its environment. What's the correct way to do it?
It seems that weightArg should be static and I should be able to get it from Box static initializer, but I cannot manage to overcome the compiler.
Regardless of whether it's "right" to do so or not, the way that you can access your weight variable from within the Box class is to simply remove the word "def". The reason why is described here.
Declaring a class in a middle of a script and making it dependent on scripts local variables is a definite sign of a bad design. If you can't design this whole system in OO way than stick to procedural programming. The main purpose of writing OO programs is factoring them to little independent pieces. In your case it's neither factoring, nor independent, and I'm pretty sure it has no purpose you could express in words.
In other words either don't declare a Box type at all or do it similar to this way:
class Box {
Box(weight) { this.weight = weight }
def width, height, weight
}
And use it like this:
def box = new Box(args[0])
Thus you get it abstracted from weightArg and args[0] and also become able to reuse it in different scenarios.
Otherwise you foredoom your program to be unmanageable and therefore dead after first revision. In decades of existence of OO programming it's been pretty much proven.
Another thing to note is that when you get a feeling that you need to introduce classes in your script it is a reliable sign that your program should be written as a normal application with packages and stuff - not as a script.
There are 2 reasons for me to ask:
1. I'd like a better code fragmentation to facilitate version control on per-function level
2. I struggle from some attention deficit disorder and it is hard for me to work with long pieces of code such as big class files
To address these problems I used to use include directives in C++ and partial class definitions and manually-definable foldable regions in C#. Are there any such things available in Scala 2.8?
I've tried to use editor-fold tag in NetBeans IDE, but it does not work in Scala editor unfortunately :-(
UPDATE: As far as I understand, there are no such facilities in Scala. So I'd like to ask: someone who has any connection to Scala authors, or an account on their Bugzilla (or whatever they use), please, suggest them an idea - they should probably think of introducing something of such (I was fascinated by C# regions and partial classes for example, and plain old includes also look like a convenient tool to have) to make Scala even more beautiful through laconicity, IMHO.
How about doing it with traits? You define it like this:
trait Similarity
{
def isSimilar(x: Any): Boolean
def isNotSimilar(x: Any): Boolean = !isSimilar(x)
}
...and then you use it like so:
class Point(xc: Int, yc: Int) extends Similarity
{
var x: Int = xc
var y: Int = yc
def isSimilar(obj: Any) =
obj.isInstanceOf[Point] &&
obj.asInstanceOf[Point].x == x
}
If the class Point were bigger, you could split it further into traits, resulting in the division that you want. Please note, however, that I don't think this is advisable, as it will make it very difficult to get a good overview of your code, unless you already know it by heart. If you can break it in a nice way, however, you might be able to get some nice, reusable blocks out of it, so in the end it might still be worth doing.
Best of luck to you!
//file A.scala
trait A { self: B =>
....
}
//file B.scala
trait B { self: A =>
....
}
//file C.scala
class C extends A with B
I suggest to read white paper by Martin at this link. In this white paper 'Case Sudy: The Scala Compiler' chapter will give you idea about how you can achieve component based design having code in several separate files.
Scala code folding works properly in IDEA.
The version control tools I work with (bzr or git, mostly) have no trouble isolating changes line-by-line. What use case do you have--that's common enough to worry about--where line-level isolation (which allows changes to independent methods to be merged without user intervention) is not enough?
Also, if you can't focus on something as large as one class with many methods, use more classes. A method generally requires you to know what the other methods are, what the fields are, and so on. Having that split across separate files is just asking for trouble. Instead, encapsulate your problem in a different way so you can work with smaller self-contained chunks at a time.