Subscribe to this thread
Home - General / All posts - Script problem, install error?
hugh
200 post(s)
#14-May-17 16:58

Trying scripts in scripts-throughput-b.map with 161.0, script 1 - write numbers/strings, I get this:

[14:21] The type 'Manifold.Schema' has no constructors defined

[24:5] The type or namespace name 'Values' does not exist in the namespace 'Manifold' (are you missing an assembly reference?)

[24:25] The type or namespace name 'Values' does not exist in the namespace 'Manifold' (are you missing an assembly reference?)

Same result for 161.0 with the earlier version of scripts-throughput-b.map

Script runs OK in 160.4 1130 ms, both versions of scripts-throughput-b.map

I did earlier have when installing the "There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run" problem.

Got 161 to install by turning off Bitdefender but tried updating .NET first -- may have caused script problem

tjhb
10,094 post(s)
#14-May-17 20:05

Quite a bit has changed in the object model for 9.0.161.0 (release notes). Among other things:

The former Manifold.Values class has become Manifold.ValueSet.

Previously Values and Schema objects were obtained via a constructor using 'new' syntax:

M.Values vals = new M.Values();

M.Schema schema = new M.Schema();

Now ValueSet and Schema are returned by methods on the Application object:

M.ValueSet vals = Manifold.Application.CreateValueSet();

M.Schema schema = Manifold.Application.CreateSchema();

(I think these changes are at least partly in connection with point 250 in the release notes, automatic cleanup. A bit less OO and more functional.)

Here is a version of Adam's script [1 - write numbers / strings] revised for 9.0.161.0 (with changes noted).

// $reference: System.dll

//

using M = Manifold;

using System.Diagnostics;

class Script {

    static Manifold.Context Manifold;

    static void Main() {

        M.Database db = Manifold.Application.GetDatabaseRoot();

        // create table

        // M.Schema schema = new M.Schema(); // 9.0.160.x

        M.Schema schema = Manifold.Application.CreateSchema(); // 9.0.161.0

        schema.AddField("num""int32");

        schema.AddField("str""nvarchar");

        string inserted = db.Insert("test""table", schema);

        M.Table table = db.Search(inserted);

        Stopwatch sw = new Stopwatch();

        sw.Start();

        // add records

        // M.Values vals = new M.Values(); // 9.0.160.x

        M.ValueSet vals = Manifold.Application.CreateValueSet(); // 9.0.161.0

        vals.AddValue("num");

        vals.AddValue("str");

        vals = vals.CreateLocked(); // added in 9.0.160.4

        int recordCount = 500000;

        for (int index = 0; index < recordCount; ++index)

        {

            vals[0].Data = index;

            vals[1].Data = (index * 100).ToString();

            table.Insert(vals);

        }

        sw.Stop();

        Manifold.Application.MessageBox(string.Format("Elapsed: {0} ms", sw.ElapsedMilliseconds), "Script");

    }

}

hugh
200 post(s)
#14-May-17 21:31

Thank you, that works, I was mistakenly using the script in the last example file for 9.0.160.4 and did not realize the change in the object model took place in the final build after that. Normally I would have just tried to figure it out but I was afraid I had messed something up in installing 161 and version of .NET

adamw


10,447 post(s)
#16-May-17 11:21

(I think these changes are at least partly in connection with point 250 in the release notes, automatic cleanup. A bit less OO and more functional.)

The reason is somewhat different - we want to be able to pass information from the Application object to the new Schema / ValueSet object in the future, should we need it (there is a good chance we will need it at least for Schema). The only custom objects with public constructors should be primitive types.

tjhb
10,094 post(s)
#17-May-17 00:28

That makes sense, thanks Adam.

To me it does also feel more functional, like a lot of the new object model. Very tight and clean. Maybe a side effect for great good.

Same with ValueSet.CreatedLocked() by the way. I'd be intrigued to know what this does under the hood, and why it speeds things up. Does it make the ValueSet into a struct? Does it allow the compiler to assign data on heap instead of stack?

tjhb
10,094 post(s)
#17-May-17 02:43

...I meant stack instead of heap!

adamw


10,447 post(s)
#17-May-17 10:28

ValueSet.CreateLocked() preallocates a mirror object in the unmanaged code which can then be reused over and over because it is never changed. There is some synchronization involved, but it is very light (you will get optimal performance when the locked value set is used in a single thread, but you can use it from more than one thread as well, the worst that is going to happen in that case is that the performance will be as if the value set was not locked).

tjhb
10,094 post(s)
#17-May-17 11:08

Thanks for kind explanation Adam. Well out of my depth as you know, but hopefully learning.

I think this helps too: Copying and pinning--especially the section about pinning memory for reference types that have only blittable members. (I think I'm probably a bit wrong but again hopefully learning.)

Thanks again.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.