157 posts,
7 writers,
79 readers,
started 85 months ago
This post is reply to #15
posted 69 months ago (Tuesday, August 28) by Sewist
We have just uploaded a fix - caught a couple of bugs there. When you first save a pattern it will save it but won't notify, as the browser redirects you from /new to /patternnumber - we shall see if we can make it show anyway. For all other cases should work fine. We have also fixed the "Syntax error" notification that could appear when saving a pattern. :)
posted 69 months ago (Sunday, September 16) by jne4sl
How does 'end' work when it's inside an 'if' statement? I find the code only ends when the if statement is entered., which makes sense. But all the code in the if block executes even after 'end.' Which I wasn't expecting.
So, both these examples execute the info statement
flag=1
if(flag){
end
info("hello")
}
flag=1
if(flag){
info("hello")
end
}
I'm just trying to walk through code and couldn't come up with anything better than commenting to isolate a problem inside an if statement. 'break' is only allowed in 'for' statements.
This post has replies: ( #29 )
This post is reply to #28
posted 69 months ago (Monday, September 17) by Sewist
End ends execution of a script completely, but may not work within if statements.
If you are trying to get a notification of a problem, I would suggest using else, e.g.
flag=1
if(flag)
{
info(flag)
}
else
{
info("0")
}
in this case the system will return either 1 or 0 depending on the situation. Hope this helps!
posted 69 months ago (Monday, September 17) by jne4sl
Ok, just wanted to make sure I wasn't missing something. I just needed something to temporarily to walk through some code, and I can just comment out the if statement instead. 'end' does work within an if statement, it just seems it happens after all the code in the statement, so it didn't help me isolate the line that was the problem.
posted 69 months ago (Tuesday, September 18) by jne4sl
Messing around with line styles. It's annoyed me that sometimes, styles are lost with transformations, sometimes preserved, but I hadn't paid too much attention to when. It looks like dash is preserved with copy, shift, mirror, but not crop. Seems like dot usually isn't preserved. Also, it seems it's not possible to apply dot to a path that has been dashed? Finally, it might be useful to have a function 'solid' that turns a path to the default line.
This post is reply to #31
posted 69 months ago (Tuesday, September 18) by Sewist
We shall fix the dot and dashed being preserved with the actions that only move an object, and probably copy.
Crop - the resulting object is actually a new object, it doesn't equal the original one. E.g. you may crop a curve and receive a shorter curve or a longer path. Hence, the dot and dash are not carried on, though we may change opinion on this and preserve the style.
I will also check if scale preserves the style, may be we should keep it there as well.
Solid is a great addition, will add that one. :)
This post has replies: ( #33 )
This post is reply to #32
posted 69 months ago (Tuesday, September 18) by jne4sl
Sounds good. I guess, wasn't thinking of crop as a new object, because I hadn't thought to save the results to a new name.
I haven't tried:
object4 = crop(object1, object2, object3)
I'd just done:
crop(object1, object2, object3)
In which case object1 is over written with the result and the line style is back to solid.
I'll have to go back and try the other way, makes sense.
If styles can be preserved enough, that transforming a pattern (in a reasonable way) doesn't replace all the lines with solids, that's probably what I'm looking for--since at that point there's no way to go back and correct individual lines.
posted 69 months ago (Tuesday, September 18) by jne4sl
This might be overkill, but I wouldn't mind a function like 'rename' which is nothing but copy followed by deleting the first argument sent to copy.
copy((object1, object2, ...), (A, B, C,...))
delete(object1,object2,...)
Obviously, I can just do it this way, especially if copy preserves all line styles. But I do find myself doing this repeatedly. If drafting instructions start with a previous construction as a base, often the first step is to relabel the handful of points that are of interest.
Another thing that would be helpful is 'reverse' which would just go through a list of items and reverse the direction of any paths included. I often have to do this after using 'mirror' to take front patterns to back.
Right now I use a leading underscore to remind myself the orientation isn't what I prefer and do something like this:
mirror((neck_front, shoulder_front, armhole_front,...), (_neck_back, _shoulder_back, _armhole_back,...))
neck_back = path(-_neck_back)
shoulder_back = path(-_shoulder_back)
armhole_back = path(-_armhole_back)
...
delete(_neck_back, _shoulder_back, _armhole_back,...)
But this is cumbersome because I have to write out each element and can't work in a loop.
This post has replies: ( #36 )
This post is reply to #33
posted 69 months ago (Tuesday, September 18) by jne4sl
I went back and checked. Crop may create a new object internally, but it doesn't return a value and it overwrites the first object that's passed in. In which case, I'd prefer that it preserve the line style, but maybe that's a personal preference.
This post is reply to #33
posted 69 months ago (Wednesday, September 19), edited 69 months ago by Sewist
Re crop as a new object - crop either makes an object shorter, or longer.
For example, if the original object is a curve and it is made shorter, it is still a curve and you can recurve it, reshape it, etc.
If it became longer, it turned into a path. E.g. there was a curve, and you cropped it against a line that was not crossing the curve. The corresponding end of the curve was prolonged by adding a straight line to it, as in meet(curve.p2,curve.a2+180,....// the vector of the cropping line//)
If it was this way, this is a different type of object, and you can't reshape and recurve it, as it lost the coefficients of the curve, it only has the points and the angles, as a path.
Nevertheless, I believe you are right in saying that since the original object was overwritten, it would be logical to preserve the style. This I shall discuss, and most probably we shall do it this way, but I'll update by a separate post :)
This post has replies: ( #39 )
This post is reply to #31
posted 68 months ago (Thursday, September 20) by Sewist
Solid is live - http://www.sewist.com/spl/#run/749
The syntax is the same as for dash and dot - simply solid(object1,object2,...objectn)
Enjoy!
posted 68 months ago (Monday, September 24) by jne4sl
Another function idea. I'm just not sure the best name, or exact format. It's something I'm doing routinely, and can manage without a special function, but possibly it would help others with the transition from paper drafting to using Sewist. Most drafting books contain instructions to square out a fixed distance from the line between two points.
So, given two points, p1 and p2, and a distance d
p3 = apply(midpoint(p1,p2), d, [p1:p2].a1 + 90)
So, I'm proposing a point function that given p1, p2, and d, plots a new point on the perpendicular bisector of p1 and p2. Looking from p1 to p2 a positive value of d would be to the right of the line and a negative value would be to the left (zero would be the midpoint). This is consistent with the orientation of the x and y directions in Sewist given a positive y value is to the right of a line that has a positive x orientation. In the context of walking clockwise around a pattern contour, p3 would be inside, so it's a point that can be used to "hollow" the straight edge [p1:p2]. (If x is negative, p3 is outside the contour and bumps out the edge.) So I'd suggest calling the function "Hollow."
In paper drafting this would be followed by creating a curve through the three points. But often this is done to successive edges and only then is the curve matched. So the points are necessary as an intermediate step, as the desired curve angles at the the end points my not be known. So even though the ultimate goal is a curve, what's needed first is a point function.
So I'd suggest calling the function "Hollow" as that's the primary way it's used, even though this leads to a bit of a double negative where if you wanted a function "Bump" it would be using "Hollow" with a negative value. Maybe using a parameter 1 or 2 to specify which side of the line the point is on, would be more consistent with other existing functions like "Compass". But in this case allowing a negative parameter makes sense geometrically and it's easier to give the function a colloquial name when this choice has been made.
The other issue is, very rarely, drafting instructions place the new point somewhere other than the midpoint. (One time it was at two thirds.) This is probably best just left to be plotted in two steps without a function. But there could be a hidden fourth parameter that is a positive number between 0 and 1 and defaults to 0.5, that specifies the fractional distance along the line to place the perpendicular.
The final concern is that these "hollowing" steps in drafting instructions are the most ad hoc part of the whole process. They really are just reporting data on a single curve that was drawn and this will break down at other sizes. So the second order correction would be to scale these little bit's by an appropriate size measurement or plot the curve directly. But anyone who's working through these instructions needs to see these points as a starting point.
So that's my suggestion, I think it could be useful, but maybe it's particular to my interests :)
This post has replies: ( #46 )
posted 68 months ago (Wednesday, September 26) by jne4sl
I found another construction that is easy to do on paper without a calculation using drafting tools, but I isn't available as an elementary function in Sewist. At least, I couldn't think of a way to do it.
The instruction was to place a set square or triangle through two points, such that the right angle is a given distance, d, from one of the points. So, construct the final point, p3, of a right triangle with hypotenuse between points p1 and p2 and one leg of length d. As long as d < [p1:p2].l it's possible and there are two solutions.
So the method I used was to calculate the length of the second leg (sqrt([p1:p2].l^2 - d^2) and use 'compass'
p3 = compass(p1, d, p2, sqrt([p1:p2].l^2 - d^2, 1)
Which is fine except when using a square it's not necessary to make a calculation, so it would be nice to have a function that takes care of this.
I also tried constructing a circle of radius d at point p1 and using the function 'tangent'. This at least is intuitive and doesn't require a calculation, but the result wasn't very accurate. The resulting angle was closer to 91 degrees. I put this in a draft, 'Set Square', #756.
This post is reply to #43
posted 68 months ago (Monday, October 1), edited 68 months ago by Sewist
That's an interesting problem, thanks for bringing it up.
Is it a common case, i.e. do we actually need a function for this and what would be the name?
Meanwhile, we are investigating if there are any round ups in sqrt,^,compass - tangent uses a loop at a certain precision, will report which exactly.
This post is reply to #44
posted 68 months ago (Monday, October 1), edited 68 months ago by Sewist
Re tangent to circle - there is a certain accuracy, but my feeling is that the not too exact placing of p3_ is rather due to the fact that the circle is perpendicular to its center in any given point.
ETA: And also, you might have wanted to find not a tangent line to the circle, but rather a normal drawn to it from point P1 so that at P3 the angle of the split object is perpendicular to P1-P3? Just in case you sometimes need just that, there's a silent function normal:
p1=normal(p2,object,newobject1,newobject2) - the latter two parameters are optional
This still won't work correctly in the given example as any point at the circle will comply with the condition, but might be useful in other cases.
This post is reply to #42
posted 68 months ago (Monday, October 1), edited 68 months ago by Sewist
I have a feeling that we might introduce some 'bump' - but I am not sure about the fractional optional parameter from 0 to 1 defaulting to 0.5. Sometimes it is not just 0.3, but some length in cm (or inches), so this is rather a length. Sometimes it is a length that is tied to size measurements, or a complex formula.
As for the names - in math this is midperpendicular - but this is not practical, neither is perpendicular.
This may be called foot - but such a name will conflict with the more common name variables.
I am thinking plumb. :) Not too straightforward, but short, is a synonym to perpendicular by Webster and is not likely to conflict with the existing pattern scripts.
As for the sides - when working with vectors we choose sides in a different way, as their direction may be not the same as those of the axes. If one stands at the starting point of a vector and look towards its end, then we have two sides, numbered as 1 - and 2. 1 is thus on the left, and 2 on the right.
1 
2
We'll have to think about the syntax. We could make it
p3=plumb(p1,p2,length,side,fraction)
where side is on the left by default and fraction equals 0.5 by default
This post has replies: ( #47 )
This post is reply to #46
posted 68 months ago (Monday, October 1) by jne4sl
Plumb is a good name. The only disadvantage is it's not a word that's used at all in garment drafting instructions. But for a very common construction there's no consistency in language at all, it's usually just 'raise by x' or 'slope out x' or 'measure in x'. One book had a table of 'extensions' for drawing a curve. Another book did use the word 'hollow' which is about the only candidate for intuitive language I saw. And it did make me realize most curves are concave in sewing. (The other issue with plumb, in practice, it's never a perpendicular to an arbitrary line, it's the gravitationally vertical defined by a bob on a string, and perpendicular to 'level', the gravitationally horizontal.)
The key thing is that the default be to place a point on the perpendicular bisector of the two points as that's what's wanted nine times out of ten. If there is an optional argument, there's no need for that to be fractional. You're right, it may as well be a length that defaults to [p1:p2].l/2. But once the point isn't being placed on the bisector, it may as well be free to be placed anywhere on the line parallel that the length and the segment define, so specifying a distance is best.
Side should definitely be used in the way that is consistent with the other functions and convention. I was confusing myself because I was thinking of standing on a unit vector pointing in the positive x direction, I would expect the first side to be in the positive y direction, to the right, not, to the left which is the negative y direction. (Perhaps this is an artifact of the coordinate system that has an orientation contrary to math texts where counterclockwise is a positive angle, etc.) No matter, it's convention and it's actually more natural, because then it's a sort of bumping out of the segment, not a hollowing. That's another advantage of plumb, it doesn't suggest a side.
Would specifying a negative 'length' be allowed? It's not necessary given the option of using 'side'. But for example plotting a sleeve head involves perpendicular points on either side of a line. I'd be more inclined to consider some of the values negative than to use the 'side' parameter. I'd be more likely to use 'side' if i was somehow coming at the segment in the 'wrong' way and I wanted to reverse the logic. That's probably just me :)
This post is reply to #47
posted 68 months ago (Monday, October 1) by Sewist
I agree about the gravitation thing about plumb, and I had doubts myself. What if we use raise?
p3=raise(p1,p2,distance,side,length)
As for sides - we were thinking mainly on how we can explain it in not too complex way, and 1 - 2 seems more intuitive. Still is, when I work with compass, for example :)
We might include both negative distance and sides, I don't see a problem with that... in fact, if you 'apply' a negative distance it will actually be applied in the opposite direction than the one suggested by the angle parameter.
This post has replies: ( #50 )
This post is reply to #47
posted 68 months ago (Monday, October 1) by Sewist
And then as an afterthought - I understand the reasoning re drafting curves, but in fact I usually just use angles in such a way that they are perpendicular to other elements. Sometimes the books may refer to quadratic curves (arc in Sewist) and not cubic curves (curve in Sewist). Though of course it is possible to draw bot a curve and an arc to a raised point.
This post has replies: ( #54 )
This post is reply to #48
posted 68 months ago (Monday, October 1) by jne4sl
I think 'raise' is fine. And, I dunno, in that case 1 being to the left makes intuitive sense. If you walk around a pattern and raise each of the midpoints (and draw a new pattern) you get something bigger. If instead you set the parameter to 2, you get something smaller, which would be an anti-raise.
I don't see any reason to require a positive value, my preference would be the same as 'apply'.