export scope

billy2

Reading the manual trying to figure out manipulators, it talks about replaceFace.fs as an example. Being lazy, I went to the std library and copied the replaceFace.fs code into my own featurescript.

FeatureScript 307;
import(path : "onshape/std/geometry.fs", version : "307.0");
/*
// Imports used in interface
export import(path : "onshape/std/query.fs", version : "");
export import(path : "onshape/std/tool.fs", version : "");
// Features using manipulators must export manipulator.fs.
export import(path : "onshape/std/manipulator.fs", version : "");
// Imports used internally
import(path : "onshape/std/evaluate.fs", version : "");
import(path : "onshape/std/feature.fs", version : "");
import(path : "onshape/std/surfaceGeometry.fs", version : "");
import(path : "onshape/std/valueBounds.fs", version : "");
import(path : "onshape/std/vector.fs", version : "");
import(path : "onshape/std/string.fs", version : "");
*/

Question #1:

We use version 307, you use 316. Copying code from library could create problems?

We use "onshape/std/geometry.fs", why don't you? Instead of loading the individual libraries, why don't you use the global definition?

So to get replaceFace.fs to work, you just comment out your imports and use the global import.

annotation { "Feature Type Name" : "Replace face", "Manipulator Change Function" : "replaceFaceManipulatorChange", "Filter Selector" : "allparts", "Editing Logic Function" : "replaceFaceEditLogic2" }
export const replaceFace2 = defineFeature(function(context is Context, id is Id, definition is map)
    precondition
    {
        annotation { "Name" : "Faces to replace",
                     "UIHint" : "SHOW_CREATE_SELECTION",
                     "Filter" : (EntityType.FACE) && ConstructionObject.NO && SketchObject.NO }
        definition.replaceFaces is Query;

Question #2:

Some functions have to be renamed, replaceFace had to change replaceFace2. I suppose because you create a "builtin" named replaceFace and now I can't use it? Your stuff supersedes myself?

What's the scope of export? Is it everything in: Onshape, the document, the part studio, the featurescript module, the defineFeature function. How far reaching is export?

"Editing Logic Function" : "replaceFaceEditLogic2"

I had to rename the edit logic function but didn't have to rename the manipulator change function, why? Seems to me both should need changing.

"Manipulator Change Function" : "replaceFaceManipulatorChange"

Anyhow, this works, my own replaceFace function:

So the plot thickens. Since I can redefine replaceFace, let's update transformCopy.fs using the same hacking techniques.

export enum TransformType2
{
    annotation { "Name" : "Translate by line" }
    TRANSLATION_ENTITY,
    annotation { "Name" : "Translate by distance" }
    TRANSLATION_DISTANCE,
    annotation { "Name" : "Translate by XYZ" }
    TRANSLATION_3D,
    annotation { "Name" : "Transform by mate connectors" }
    TRANSFORM_MATE_CONNECTORS,
    annotation { "Name" : "Rotate" }
    ROTATION,
    annotation { "Name" : "Copy in place" }
    COPY,
    annotation { "Name" : "Scale uniformly" }
    SCALE_UNIFORMLY
}

Turns out my enum can't live with your enum so I had to rename mine.

// Note that transform() is also defined in transform.fs
// with different signatures.  This is written as a wrapper around defineFeature to keep overloads working.
annotation { "Feature Type Name" : "Transform",
             "Manipulator Change Function" : "transformManipulatorChange",
             "Filter Selector" : "allparts" }
export function transform2(context is Context, id is Id, definition is map)
{
    fTransform(context, id, definition);
}

This transform2() always has an error which I can't eliminate and I'm not sure why.

Question #3:

I understand that featurescript is nothing more than a bunch of feature functions in some scope that execute with Onshapes build() function. How big is this pool of stuff? 

When you export a function, where does it go? 

export const replaceFace2 = defineFeature()
export function transform()
function reportCoincident()

Obviously reportCoincident() doesn't end up with the export functions, but are the 2 export functions in the same namespace?

Some times you have to rename an export and other times no problems=confusing.

I'm struggling trying to understand the scope of featurescript and how everyone will play with one another. Could you clarify this?

Thanks,

ilya_baran

You're hitting a mixture of stuff we want to improve and stuff we haven't documented.  There are hints about how export works in https://cad.onshape.com/FsDoc/toplevel.html but not enough for a coherent picture.  Let me try here.

FeatureScript lives in modules.  A module is a Feature Studio or a Part Studio or even a tab with something uploaded.
Each module has a number of "top-level" constructs, such as functions, imports, constants, predicates, types, enums, etc.  These constructs define new symbols all of which are visible at least within the module.  For instance

enum Foo { ONE, TWO }

creates the symbol Foo visible within the module.  Importing module B into module A causes some of the symbols visible in B to become visible in A.  The specific symbols that are imported into A are those whose top-level constructs in B are marked with "export".

So to answer your third question first, when you write "export function foo() {}" in your module, that function becomes visible to any module that imports yours.  In particular, in the standard library, we have a bunch of modules.  One of them is transformCopy.fs.  There, we write "export enum TransformType { ... }", which makes TransformType visible to anyone who imports transformCopy.fs.  Another module in std is geometry.fs.  There we have:

export import(path : "onshape/std/transformCopy.fs", version : "");

That takes the symbols in transformCopy.fs and makes them visible inside geometry.fs.  Because the import is marked with an export, it also makes the symbols (including TransformType) visible to your feature studio that imports geometry.fs

To answer your second question, you cannot have duplicate symbols within a module, so you can't have two enums named TransformType.  It's not that our stuff supersedes yours, it's that you're importing our stuff (and therefore getting the duplication) and we are not importing yours.  If you were to not import the whole geometry.fs, but just the stuff transformCopy imports (with an explicit version -- more on that below), then you could in fact define your own TransformType and not have to do TransformType2.

To answer your first question, this is something we want to improve -- right now standard library imports use a special syntax (because of our own development process) that we would like to move away from.  One problem is that right now we allow version to be the empty string, which is what you got when you copy-pasted.  That tries to bring in a later FS version than you want -- the correct thing to do is to explicitly set the std version (in your case to 307.0 unless you need more recent functionality in which case you'd need to upgrade your whole document).

For specific errors, like:

This transform2() always has an error which I can't eliminate and I'm not sure why.

it's hard for us to diagnose without seeing the whole picture.  A possible workflow is that when you see an error you'd like to ask us about, commit your feature studios and save a version.  Then you can make your document public or share it with support and ask about specific versions in it.

Let me know if I can clarify stuff here further.

billy2

Thanks for the clarity. Re-read the manual and strangely I think I'm starting to get it.

I'll go through my code and take out any duplicates. I should be able to use your enum TransformType by deleting mine. There's no reason to redefine it. With this knowledge I'll go back through transformCopy.fs and try to get my own version to run.

I totally forgot that I have to update my document to match versions. The only way I know to do this is to make a copy of my document:


Sure enough that worked:


I thought our documents were suppose to auto update with enough time. Not sure this is happening. Is there a better way to update a document without copying?  

Once again, thanks for your help,

ilya_baran

Auto upgrades are something we haven't really talked a lot about yet (because FeatureScript is not yet public), but here's the relevant info:
1. After a functionality update, we start going through the document and updating the FS version on all part studios that are not referenced by feature studios.
2. The most important upgrade goal is to not change how part studios regenerate.
3. We do not update the feature studios (because it would be impossible to avoid breakage)
4. After the upgrade runs on a document, new part studios and new feature studios created point to the latest FS version.
5. There is no way for the user to control when the upgrade runs.  Copying will not cause an upgrade in the testing that I have done -- not sure why it did for you.

This time around, due to some operational issues, the upgrades are running later than usual (but your documents should likely be updated by now).

billy2

I'm glad it did update to the latest, makes it easier for me to play around with std lib code.

wayne_jayes

After being part of yesterday's webinar on featurescript I wanted to use the Fill Pattern feature on this document https://cad.onshape.com/documents/b25ddc3f636144caa65fa175/w/466ea2eadf365480effc836a/e/034b05a63ec747cebb940609 but the document needs to be upgraded to allow featurescripts, can you make this happen please.

cody_armstrong

@wayne_jayes Can you please clarify what is happening?  I just added the Fill Pattern feature and used it as a test and it worked fine?

wayne_jayes

cody_armstrong said:

@wayne_jayes Can you please clarify what is happening?  I just added the Fill Pattern feature and used it as a test and it worked fine?

Problem solved thank you