We added icons to the pattern library so that the pattern settings are more obvious.

Private/public is shown with folders - red folder stands for private pattern, green folder stands for public pattern.

Blackboard stands for pattern code - if the blackboard is blank, pattern code is hidden, if it has scribbles on it - pattern code is public.

Printer stands for export - you may allow other users to print out pattern blocks using your code (you don't have to actually show the pattern code if you decide so). If the pattern icon has a tiny red minus on it, export is not allowed to other users.

There are still some imperfections we are working on, but all in all it's practically there. 

One simple thing I find myself typing again and again is finding a midpoint, e.g.,

Also, there are times when a "floor" function would be more convenient than

"round".

Will add midpoint, no problem with that, will go live next week. I believe the syntax will be p3=midpoint(p1,p2)

Floor function will go live next week. :) The syntax will be floor(n)

I shall post the updates once they are live on facebook, and will edit documentation next week adding wave, magnet, floor, midpoint.... I guess that's it for now. 

I completely understand that not everything can be user accessible.  But since a template can only be called once, they help me more with organization, than really reusing code on the fly.  And even then there's a limitation, like if I write a template to collect all the steps for building a patch pocket, I still need two copies of that template if my jacket has two different patch pockets.   That's okay, at least with sewing it's not as if there's an unknown quantity of pockets.  And if somehow there were, foregoing a template and putting that code in a loop might take care of it.

But now that I know I can ask, I'm sure I'll have more requests :)

Actually one other thing, is there any thought to adding some sort of a "list" object?  Behind the scenes there seems to be one, e.g. the transformation functions act on a list, or the include line of the the pattern object is a list. There's no way to collect these under a single name.  This could be useful.

We released two new commands:

p3=midpoint(p1,p2)

and 

floor(float) - will return the largest integer.

For "list" there is group:

group1=group(object1,object2,....objectn)

For now you can use it in inc parameter in patterns, and we are working on making it work properly in commands like move, shift, rotate etc.

For trace etc I usually use path. :)

Thanks!

As for group, it is just a matter of time, as I, myself, find it useful sometimes to unite all elements refering to e.g. front into a group to mirror them at once, and not list them one by one.

Group contains the names of the elements, not the elements themselves, so the idea was to handle them at any given point of time, even if some of them have been recurved or changed.

However, for now I didn't ask the IT to think of a way to remove elements from a group. Adding them works as in group1=group(group1,newelement). Do you think this is something that needs to be added?

We also have another 'silent' function, which is ratio. It returns the integer after division, e.g. ratio(7/3) will return 2. I needed it to better place buttons for changing sizes.

Any ideas are truly welcome, so if there's anything else you need, just let us know :) We are now a bit busy finishing the visual tools, but we can also find a spare minute to make the lexer better.

Good to know about 'Ratio'.  I can put that to use.  I know there was one time I was looking for something like that.

I've started using the 'wave' function, and that works great.  Looks like the editor isn't highlighting it as a function at the moment.  I'm also unclear when I have to use named points and when I can make a reference to a point, like the end point of a path.

E.g. with wave, I wanted to draw a new armhole connecting (and perpendicular to) paths 'shoulder' and 'side' and passing through intermediate points: pointA, pointB, pointC, ....  I'd like to say:

armhole = wave((shoulder.p2, pointA, pointB, pointC, ..., armhole.p1), shoulder.a2-90, side.a1+90)

but I get a syntax error.  I have to instead name the initial and final points and pass the names.  So:

p_I = shoulder.p2

p_F = side.p1

armhole = wave((p_I, pointA, pointB, pointC, ..., p_F), shoulder.a2-90, side.a1+90)

Referencing the two angles outside the list doesn't cause an error.  I've run into this before, and I assume it's a restriction on the list.  It makes sense when the function has the option of renaming objects, since it wouldn't be possible to rename a referenced point, but here I don't see the reason.

I  will definitely think of more suggestions. Thanks.

I would like it if group could be a group of nothing as I could begin by saying button_marks = group()  and wouldn't have to check if it were defined.  I'd also like if the include line in a pattern call could be empty 

inc(),

because I would like to leave it as a stub to fill in.  Same for functions that act on a list, there are times when the syntax error for things like delete() annoy me.   Obviously completely avoidable, just not the sort of mistake I'm looking to be called on, I guess.

That's a bug, we'll fix it! Thanks for the headsup!

We have not included arrays in the available options, as there have been some limitations in lexer (or so I remember).

-----

ETA - On a second thought, what could help is creating the name of the next variable in a loop. E.g. you first announce an empty group

buttonmarks=group()

And then inside the group the syntax is something like

buttonmarks=group(buttonmarks,m_gs#i)

Which helps to handle variables depending on the final i, still using a group.

-----

OR

we do it as array

buttonmarks=array()

in loop

buttonmarks[i]=mark(gs,90)

-----

Are there any other cases aside from buttonmarks when you face a limitation like this?

I will have to discuss if this is easily done. We were looking to achieve a clear readability of code, so opted out of some stub options. Per se, it adds to the code, and doesn't have a practical meaning, so might be abundant for those who are not used to coding. As a roundabout, and a tool to avoid syntax errors, we have been adding buttons to the left vertical navigation that help to get the code right. Anyway, will discuss!

So, I know ultimately I would like to have arrays, but that's me.  If that's not possible or just not of much use, I still see some ways to use the function group in a ways that might be sufficient.  Since group can be used to collect snap shots of an object that is moved around.  The editor already does this since it leaves old copies sitting around, but this is a way to add those copies to a pattern.  This is most useful in a loop, like the button example.  It's just there's the question of initial conditions.  Do I place one object in the group before starting?  Sometimes that's reasonable--maybe calculate the first item before the loop, or group them with something else entirely like the placket notch--but other times, it might be more natural to come in with an empty group and do all the adding in the loop. (It was already possible to do something similar with path inside a loop, adding snippets successively, but of course a path has nothing to do with something like button markings.  So group is useful for these other situations.)

Your second example, how can the names of a variable be generated in a loop?  Isn't that the whole issue?  I can't do this now, can I?  Even if I had variables with these names made up before the loop, I wouldn't be able to get the loop index value concatenated into a string to reference a given variable.  That would be an array.  Maybe I've been missing something.

Anyway stubs and empty groups aren't essential, they just seem to come up for me. 

I put a toy program 'button example' up, #766.

Generating names is not available now, but this is a roundabout for a group in a loop... we are considering if we want to start with arrays or allow concatenating names as another option to make buttons and buttonholes.

Maybe it's an abuse to put group in a loop this way, but at the moment I think it's useful.  I don't know how 'group' works internally but at least when it comes to marks, if I add a mark to a group do something to the mark and then add it to the group a second time, both versions of the mark show up on the pattern when the group is included.

convex (point1,angle1,point2,angle2,radius)
Draws a round tip within the given vectors.

Function parameters

name of the first point

angle at the first point

name of the second point

angle at the second point

radius in cm 

If the name of a convex path is not set in code, the default name is formed as X_firstpoint_lastpoint. E.g. an unnamed convex path from points P1 and P2 will get name X_P1_P7. 

Names of points can be substituted with function point(x,y) etc. In this case it is mandatory to specify the name of the future arc, as there are no point names to create it automatically (second line of code). 

A convex path also has direction from first point to second point. 

Object properties

After a convex path is created, you can get its properties by using the following syntax:

.a1 - angle at the first point with the horizontal

.a2 - the angle at the second point with the horizontal

.l - the length of the path

.p1 - the first point

.p2 - the second point

.x1 - x coordinate for the first point

.y1 - y coordinate for the first point

.x2 - x coordinate for the second point

.y2 - y coordinate for the second point

.dx - difference of x coordinate values between the first and the second points

.dy - difference of y coordinate values between the first and the second point 

Usage

You can use mathematical equations, variables, and size constants in syntax, e.g. 

Anyway, with this code:

Syntax error(

I  was making pants with a back yoke, that could be cut as one piece with the leg and folded into place or cut as two pieces.  So I wanted to create the back leg patterns in if statement.  I had a flag yoke_cut_on, but for whatever reason I wanted to start with the negative case.  I just thought it would read better to say if(yoke_cut_on == false) instead of if(yoke_cut_on==0)  If I were starting with the true case, I'd just write if(yoke_cut_on).  Also there isn't a logical 'not' operator in Sewist (at least not that I've stumble on).  There doesn't need to be, just sometimes, I like code to read like a sentence.  And if(not yoke_cut_on) or if(yoke_cut_on == false) 

Anyway, I also don't really need 'true' and 'false' I just was surprised they were defined but not highlighted, which reminded me that I'd noticed 'magnet' wasn't highlighted either.

ETA and highlight them :)