Preventing ACE posting

It has long been known that posting up ACE and/or CASE alternatives may have unintended consequences when the parent/child alternatives have records that are in conflict. If you ever want to prevent all users from posting an ACE alternative, you can use this code I wrote to do that.

This code snippet has been written in a patch format. You can read more about how to create your own patches here.

The define_method_synonym() approach is described here. Note that because the core method database_view.post() source code is not shipped with the product, we need to use the define_method_synonym() approach to wrap our own custom functionality around it without modifying the core restricted functionality.

#% text_encoding = iso8859_1

_package sw

$

sw!patch_software( "ds_src", 1 )

$

# use define_method_synonym() to wrap some of our behavior

# around the core method without redefining the core behavior.

_if database_view.method(:original!post|()|) _is _unset

_then

database_view.define_method_synonym(:original!post|()|,:post|()|)

_endif

$

_pragma(classify_level=restricted, usage={redefinable})

_method database_view.post(_gather args)

## Post changes in this alternative to the parent,

## performing an implicit commit() if any updates are

## outstanding.

##

## Returns _true if there were changes to post, _false

## otherwise.

##

## If the data dictionary has been modified, then the modified

## version must have been allocated a datamodel version first.

##

## External databases are checked to ensure that if they are

## updated, that they are prepared to commit (i.e. they are

## running). An error is raised if one is not prepared to

## commit.

##

## THIS REDEFINED VERSION OF THE METHOD HAS BEEN MODIFIED TO

## DISALLOW POSTING ACE ALTERNATIVES.

_if _self.name.canonical _is :ace

_then

condition.raise(:cannot_post_ace_database)

_endif

_return _self.original!post(_scatter args)

_endmethod

$

_pragma(classify_level=restricted, usage={redefinable})

## raised by database_view.post() when database_view is named

## :ace.

condition.define_condition(:cannot_post_ace_database,:user_error,{})

$

read_message_patch(:condition,_unset,:en_us)

$

:cannot_post_ace_database Posting ACE alternatives is not safe and has been disabled.

$

sw!declare_patch(1000000001,"1cst","Prevents posting ACE alternative.")

$

Map View vs Application vs Trail Coordinate System

In setting up the iFactor Virtual Earth Connector™ product for a few customers (both actual and evaluation), I have seen the flexible Smallworld projection functionality take more of a front-and-center role for a customer.

Typically customers have set up their SWAF application to use a particular application coordinate system and then they forget about it.

With the VE Connector, rendering can happen in any coordinate system but as you can probably appreciate, the fastest and highest quality rendering can happen if the current map view's coordinate system is the same as the coordinate system that Microsoft's Bing Maps (formerly Virtual Earth) were cached at. So the VE Connector comes with a pre-defined coordinate system (we call it "Virtual Earth") that switches the mapview coordinate system to the same one used by Bing Maps.

Changing the mapview coordinate system has typically caused our customers two "surprises".

The first surprise is that their trail measurements are now different than they used to be. The second surprise is that their application coordinate system is different that it used to be.

Both these "surprises" indicate that the trail coordinate system and the application coordinate system have been "locked" to the mapview coordinate system.

You can change these settings by choosing Tools -> Options from the menu bar.

To change the application coordinate system so that it is always what you want it to be regardless of the current mapview coordinate system, select Geometry Calculations in the Options panel.

To change the trail coordinate system so that it is always what you want it to be regardless of the current mapview coordinate system, select View Defaults in the Options panel and "unlock" the trail coordinate system from the mapivew coordinate system.

That's all there is to it. Remember that changes to the Options panel are typically saved in the ACE so for your changes to be set for all users, you will need to take the usual steps involved with propagating ACE changes down the ACE alternative structure.

View Microsoft Virtual Earth data in Smallworld

I'm very excited to share with you all that the company I work for (iFactor Consulting) earlier this week released Version 1 of the Virtual Earth Connector for Smallworld. You can read the official announcement here.

The VE Connector makes use of Smallworld Core Spatial Technology Spatial Object Manager (SOM) functionality to render landbase and aerial imagery tiles served up by Virtual Earth on your Smallworld map view.

The product page has a demonstration video that shows the functionality. If you want to try it out for yourself, you can get a full version evaluation release here.

It seems like all the big players (ESRI, MapInfo, Oracle Spatial) are going in this direction and now iFactor presents this capability for Smallworld.

I would like to acknowledge Brad Sileo (iFactor VP Business Development by day and mclib master by night) for getting the original product code going. All of the iFactor executives are also master coders!

We used alot of standards-based functionality to get this to work. Let's see how many buzzwords I can remember :) : Source Forge mclib, C#, SOAP, Web Services, SWAF, SOM, ACP.

Incidentally, from the Magik Components Source Forge library, we made good use of:

• sw_dotnet_acp (thanks to Pedro Miranda for making this code available in mclib!)
  
• mclib_package
• mclib_http_interface (thanks to Tony Sileo and Brad Sileo for contributing to this!)

So, here's a plug for Magik Components: It can greatly help you with your own projects, too!

We are operating under an agile "release early, release often" model. So, once you have the product loaded, you can check for updates regularly in the "About" dialog and download the latest revision as soon as it becomes available.

Modifying core method behavior without touching core code

The other day I was writing some patches for a custom product (see Developers: patch it yourself). One of the requirements is that the product code needs to be supported at 4, 4.1 and 4.1.1. The change is to add a new dynamic variable to the beginning of map_view.int!do_render().

Originally, I thought I would have to make three different versions of this patch file (one for each CST version that the product supports). That would seem to make sense because at each of the versions, the contents of the method could have changed slightly. As it turns out, the contents had changed between two of the versions.

Having three version-specific patches for a single method ends up being an administrative nightmare because each time a new TSB is released, I need to review all the changes in the TSB for conflicts with my patch code. In some cases this might be necessary because the patch makes significant changes in the middle of the method. But in many cases, the changes we want to put in are at the top or the bottom of the method. In those cases, I discovered that I could use method :define_method_synonym() to wrap my new code around the core code without touching any of the functionality in the core code...

# use define_method_synonym() to wrap some of our behavior
# around the core method without redefining the core behavior.
_if map_view.method(:original!int!do_render|()|) _is _unset
_then
map_view.define_method_synonym(:original!int!do_render|()|,:int!do_render|()|)
_endif
$
_pragma(classify_level=restricted)
_method map_view.int!do_render( _optional post_render_set )
##
## Draws the current visible set in the render thread.
##

_dynamic !ve_connector_current_map_view! << _self

_return _self.original!int!do_render(post_render_set)
_endmethod
$

And if you use the _gather/_scatter keywords, your wrapper does not even need to worry about whether the arguments for a method change from version to version.

This technique is also useful for putting debug code into unshipped source code. Let's say I want to get a traceback every time I get a user_error dialog with the word "coordinate" in the dialog message. The dialog is actually activated somewhere in basic_window.show_alert(). This method code, however, is unshipped so your test code might look like...

_if basic_window.method(:original!show_alert|()|) _is _unset
_then
basic_window.define_method_synonym(:original!show_alert|()|,:show_alert|()|)
_endif
$
_pragma(classify_level=restricted, usage={redefinable})
_method basic_window.show_alert(message, _optional yes_message, no_message, default, mode)

_if message.canonical.index_of_seq("coordinate") _isnt _unset
_then
 !traceback!()
_endif

_return _self.original!show_alert(message,yes_message,no_message,default,mode)
_endmethod
$

NOTE: the method comments on :define_method_synonym() say that it is "severely deprecated." But until the time that this method is removed from the core code, I find it a very useful tool.

NOTE NOTE: While this technique does minimize the touch points of your code with the core code, you still need to be aware of the classifications (basic,advanced,restricted) of a method to understand how/if you should modify the method.

Exposing hidden data from Smallworld to FME

A member of the sw-gis group recently posted a question asking how to export join attribute information from Smallworld via FME. I responded to the group but thought the answer might be worth sharing here as well.

Question:

I'm using FME with Smallworld 4.0. How can I export join attributes (e.g., export transformer bank id with the transformer)? I coudn't find it in the FME workbench.


Answer:

I think the easiest way to do this is to use the fme_pseudo_field_factory.

For example...

If you’re your record exemplar is :transformer and the transformer_bank ID attribute is called :transformer_bank_id, then you can define a new FME Pseudo Field...

_pragma(classify_level=basic, usage={redefinable})
## used by FME SWAF interface to allow a customizer to add
## pseudo fields to the schema for Smallworld tables to be
## passed to FME.
transformer.define_shared_constant(:fme_pseudo_fields,
                                 {fme_pseudo_field_factory.new_derived_field(:transformer_bank_id,:extdb_string)},
                                 _false)
$

You can actually define more than one fme_pseudo_field for a given record exemplar if you want to.

Declaring :transformer_bank_id as a new derived field will make this "field" available to the FME feature. When FME asks a "transformer" for its :transformer_bank_id, it will simply call transformer_bank_id and use that value in the workspace.

There is nothing special about the naming convention of the pseudo field. The only thing to keep in mind is that the class on which you define :fme_pseudo_fields must respond (either as a method or field call) to the name of the derived field.

So you could actually accomplish the same thing as above with...

_pragma(classify_level=basic, usage={redefinable})
## used by FME SWAF interface to allow a customizer to add
## pseudo fields to the schema for Smallworld tables to be
## passed to FME.
transformer.define_shared_constant(:fme_pseudo_fields,
                                 {fme_pseudo_field_factory.new_derived_field(:bank_id,:extdb_string)},
                                 _false)
$

As long as you also have defined a method...

_method transformer.bank_id
      ## bank_id : integer
      ##
      ## returns self’s transformer_bank_id

      _return _self.transformer_bank_id
_endmethod
$

The FME fme_pseudo_fields concept is very powerful because it allows you to send data to FME that is not stored in a single attribute in Smallworld.

I have used it in the past for exporting data from Physical Network Inventory (PNI). If you are familiar with that datamodel you will know that there are many layers of relationships. Some of the records have geometries and some do not. A customer wanted to export all underground and aerial routes (these are the features with geometry) but wanted to label the features in the exported format with data from a related non-RWO record. Using the fme_pseudo_fields approach made it very easy to create a Magik method that created a suitable labelling string based on the related records but expose the results to FME as a feature attribute.

Dialog Designer v1.5 now available

Graham Garlick over at iFactor Consulting has uploaded v1.5 of the open source Dialog Designer. You can get the latest version from the SourceForge Magik Components community or from a zip file at iFactor Consulting.

Here are the release notes:

• updated Documentation file.
• fixed issue with hanging plugin action selection gui when a raster image was missing in CORE.
• fixed issue with non-refresh of Magik/XML code when first going to the Magik/XML tab
• added input mechanism to add extra slots to dialog Base Class
• added input mechanism for setting pragma statement code settings
• added input mechanism for adding additional slots to the base gui class
• added input mechanism for setting the package for the dialog
• es_es language edited (thank you Alejandro Cañas [alexcaas at gmail dot com])
• added unit_text_item widget
• fixed :select_directory (open_file_dir widget) incompatibility with SW4.
• fixed internationalization issue with the :top_dock,:bottom_dock (etc.) messages
• added date_time_input widget

Smallworld/FME Configuration Tips and Tricks (part 2)

I recently received a number of questions from a colleague that had recently upgraded to FME 2007 as part of the CST 4.1 upgrade. It seemed to me that the questions and answers were actually a continuation of the original Smallworld/FME Configuration Tips and Tricks so I present them here as "part 2". By the way, there is a growing list of Smallworld/FME FAQs at http://www.fmepedia.com/index.php/Category:GE_Smallworld_Format_FAQ

Question: I previously used the Scale function in my fme files to adjust coordinate values between database units (mm) and coordinate system units (m). The factor would be 0.001 or 1000 depending on if I was exporting or importing.

FACTORY_DEF SWORLD SamplingFactory     \
INPUT FEATURE_TYPE *                   \
@Scale(0.001)                          \
SAMPLE_RATE 1 

I used the Workbench for the first time to create an fmw file for exporting objects. I used the Scale Transformer which appears to work. Is this the right approach or should I create an FME coordinate system that matches our Smallworld database coordinate system? This must be a common problem for Smallworld/FME users.

Answer: I typically create a custom FME coordinate system that matches the Smallworld application coordinate system and then let FME do all the unit conversions. That way you don’t need to mess around with the scale transformer.



Question: Below is code based on the example in your FME presentation. Would it be better to rewrite this to include a loop and to execute the fme command for each table or run it as it is?

_block
_global fme_tics_server
_local current_server

# start the fme_tics_server if not already running
_if (current_server << fme_tics_server.current_server) _is _unset _orif
 _not current_server.acp_running?
_then
fme_tics_server.start(_unset,_unset,:gis)
current_server << fme_tics_server.current_server
_endif

# indicate which records to prepare for export
_local vc << gis_program_manager.cached_dataset(:gis).collections
_local export_records << rwo_set.new_from(vc[:table1])
export_records.add_all(vc[:table2])
export_records.add_all(vc[:table3])

current_server.set_output_rwo_set(export_records)
# run the command line FME
_local command << {"\\gis\FME\fme","\\server\mapping\FME\sworld2mapinfo.fmw",
  "--DestDataset_MAPINFO",'"\\server\mapping\FME\fme2007"',
  "--PORT_SWORLDSWAF", current_server.port_number.write_string}

system.do_command(command)
_endblock
$

Answer: If all of your export collections are processed by the same FMW file (which I see it is; which I also think is a good thing) then I do not see a reason to have to put the code in a loop.



Question: Is there a way to create a log file that can be examined during and/or after the translation? I run the code above and have no feedback whether the translation is running or not.

Answer: Probably the best way to get feedback from FME about the progress of the migration is to modify your FMW file to specify a Log File:



If you want to be more flexible, then Publish the Parameter…



... and then you can modify your Magik code to dynamically set the LOG_FILE value at export time ...

   _local command << {"\\gis\FME\fme","\\server\mapping\FME\sworld2mapinfo.fmw",
  "--DestDataset_MAPINFO",'"\\server\mapping\FME\fme2007"',
  "--PORT_SWORLDSWAF", current_server.port_number.write_string,
"--LOG_FILE","\\server\mapping\FME\fme2007\mapinfo.log"}

Question: I could previously export objects with mapped geometries by only specifying the mapped geometry field in the fme file. I found that nothing gets written in the new version unless I add each geometry field into the Workbench. Is this correct?

Answer: You are correct that each mapped geometry must be accounted for in your FMW file. The way you have shown your data features...



... is valid. If you want to make your workspace a bit cleaner-looking, you can use a “merge filter” ...



... and then you can flow all your data from that single “Merged” feature to your transformers ...

Profiling a dynamic enumerator problem with XPRF

A recent post on the sw-gis Yahoo! Group made me think that this might be a good example to demonstrate how to use the XPRF Magik class to profile your Magik code and help you find potential bottle necks in it.

Because the post did not say so explicitly, for the purposes of this exercise I am assuming the "dynamic enumerator" referred to is the one that makes use of the methods :can_match?() and :match_string(). (Sometimes people use the term "dynamic enumerator" to refer to the core extensible enumerator functionality or the PNI "dynamic enumerator" functionality.)

The first thing I would do would be to do a profile analysis on the :match_string() method on that particular object. An analysis will tell you if you have an issue with database access or maybe some code inefficiencies in your match_string() method.

You could do that as follows...

temporarily rename your subclassed some_object_name.match_string() method to some_object_name.debug!match_string()

create a new method...

_method some_object_name.match_string(_gather args)
   _global x_profile
  _local  ok?, result
   (x_profile,ok?,result) <<  xprf.new_from_send(:debug!match_string|()|,_scatter args)

   _return  result
_endmethod
$

Then try to open the some_object_name's editor again in such a way that your match_string() code is called. Likely it will take longer now than before because all the match_string() code is being run through the XPRF profiler. When the list is populated in the editor you will be ready to investigate the performance profile.

First, make sure that the global x_profile was populated...

MagikSF> x_profile
$
a sw:xprf

If it is populated, you can use various interfaces to review your profile. The least user-friendly is to call x_profile.basic_report(). This will give you potentially hundreds of lines of output at the Magik prompt... a bit overwhelming if this is the first time you have done this.

Another option is to use the :xprf_dialog class. By default it is not loaded into your image, so you need to load the :profiler_magik_gui module into your current image. Use the sw_module_dialog.open() to load the module or...

MagikSF>  sw_module_manager.load_module(:profiler_magik_gui)
$

Once the module is loaded you can use the following Magik command to give you a more user-friendly GUI that will show you expandable lists of all the methods that were called within the context of your profiler.

MagikSF>  xprf_dialog.open(x_profile)
$

Use that tool to see where the bulk of your time on the match_string() is being spent.

Possible problems you might have in your match_string() code...
- inefficient code in loops
- select predicates on non-indexed fields

Things that you could investigate to improve performance include:
- make your code more efficient
- index any columns that you are writing a predicate against.
- if the table contents are not changing very often you might consider caching the strings you get from the table in a reusable rope (eg., shared_variable) and only read the data from the table once per session in order to populate the cache

If all those things do not improve the performance to the degree that you would like, then you may want to consider using the CASE tool to configure that field as a "catalogue mapping". That will provide a different field editor but still give you the control over what goes into that field.

FME SOM Demo is now online

A Flash video of the Smallworld FME SOM Demonstration is now online. Click here to view it. The flash file size is about 9MB so it might take a few minutes to download.

(Unlike my attempts at the demo at the Smallworld Users Conference this presentation does not include any blue screens :) )

ACEs, ACEs, everywhere

I recently tried to make a copy of an ACE in the Physical Network Inventory (PNI) product. The out-of-the-box ACE is called "Physical NI User". So I thought that all I needed to do was make a copy of that ACE, call it something like "Physical NI User New", and then modify the application registration code to include...

:ace_name,"Physical NI User New"


Apparently that was not enough. If you want to have two user groups use different ACEs, you definitely need to change the application registration :ace_name. But you also need to change the ACE name in the following XML configuration files:

in a suitable application config.xml file

• verify config/framework_data/map_type[@ace_name] has the name you are expecting
• verify config/plugins/plugin[@class_name="pni_editor_manager"]/property[@name="ace_name"]["value"] has the name you are expecting
• verify config/plugins/plugin[@class_name="document_manager"]/document/document_properties/property[@name="ace_name"]["value"] has the name you are expecting

In addition, if you have specified any bookmarks for an ACE, they are "hardcoded" for the ACE in which they were originally created.

The typical symptom which indicates that some of the above-mentioned ACE settings are incorrect is the one where you look at the object control plugin and notice that the v/h/s settings are not what you thought you had set them to in the current ACE. Most likely you did set the v/h/s settings correctly but one or more of your application configurations are still pointing to an ACE that you are not expecting it to.

FME 4.1 Translator DLL problem

[Update: 07Sep2007 - see the comments below about additional information about where to find sworldswaf.dll files and which one to use where.]

I tried to use the FME 4.1 SWAF interface today and ran into a problem where the FME clients (eg., Universal Viewer) could not recognize any of the data dictionary information queued up in Smallworld for export to FME. I contacted GE Help Desk and they were very quick (on the order of minutes) to send me a new sworldswaf.dll file that must be copied into the FME root folder (eg., c:\program files\fme). This fixed the problem with the FME 4.1 interface but then introduced the problem for the FME 4.0 SWAF interface. Not that big a deal unless you are running two versions of SWAF with the same FME clients.

Interesting notes about the DLL versions. The FME 4.1 documentation says that you need to be running FME 2006 GB build 2651 at a minimum with version 1.1.0.0 of sworldswaf.dll. The version of the DLL that shipped with my version of FME build 2651 was 1.0.1.0. Either the documentation has a typo or Safe Software does not have the latest version of the DLL. Anyways, the version of the DLL that the GE Help Desk sent me was 1.0.0.11 (that's right, it seems like an earlier version number). Apparently this DLL is still too new to have made it onto either GE or Safe Software's web sites. You will need to log a case with the GE Help Desk to get the correct DLL.

On a related note: One of my Smallworld-FME presentations was accepted to the 2007 Americas Smallworld Users Conference in Colorado this year. I hope to see alot of you there. More about that later.

CST 4.1 allows single-quote strings

CST version 4.1 now allows single-quote strings.

Here's an example. Let's say you wanted to put in the short-hand notation for inch in a string. So you might try...

MagikSF> length << "5""
$
**** Error (parser_error): on line 1
length << "5""
           ^
Missing end of statement

The Magik compiler gets confused by your use of the double-quote character as a string delimiter and an inch unit.

To get around that in Magik, you would have to do something like...

MagikSF> length << write_string(5,%")
$
"5""

But as of version 4.1 you can use single quotes for strings...

MagikSF> length << '5"'
$
"5""

And if you wanted to do something similar with the short hand for feet units, you could do...

MagikSF> length << "5'"
$
"5'"

Incidentally...

MagikSF> '5' = "5"
$
True

goodbye VMDS/Magik, hello Oracle/Java?

Well, not quite.

Earlier this week, GE issued a press release "GE Energy to Introduce New Oracle-Based Product Portfolio for Electric Disturbition Utilities". I had heard rumblings of such an announcement in the days leading up to the release and was very anxious to understand what GE Energy would be announcing.

At first glance, this announcement seems to suggest another significant paradigm shift in the Smallworld application. The most recent significant paradigm shift was the move to the Smallworld Application Framework (SWAF). Some customers are still preparing for the SWAF upgrade. To be faced with an announcement like this (Smallworld on Oracle/Java) might come as a bit of a shock. But if you read the press release carefully, you will see that this announcement is geared to small- and mid-sized electric utility companies.

If you are a larger utility company that has invested considerably in VMDS and Magik technology, Bob Gilligan states that this new product line will complement the current Smallworld offerings. I find it significant that Mr. Gilligan used "complement" and not "replace".

Clearly GE Energy needs to grow more license sales and it seems to me that offering Smallworld in an Oracle/Java environment will make the sale more appealing to smaller users who do not have the resources to commit to learning another database and programming language. Having said that, I suspect that as some of the mid-sized utilities start asking the Oracle/Java application to do greater and greater things (especially around long transaction management and customising the data model), it might be a more natural step to direct them to VMDS/Magik. I think VMDS/Magik will go away at GE Energy's peril. I am of the opinion that the current VMDS/Magik package provides better solutions for some of the Smallworld user's business requirements than Oracle/Java is capable of.

GE Energy may spend more energy developing the Oracle/Java side of things because that is where the revenue growth may be, but I would strongly urge them to continue to support VMDS/Magik either directly or via some Open Source framework so that the Smallworld user community can service it.

I have included some highlights (with my comments) of the press release. I have formatted direct quotes from the press release in Georgia font. All other comments are mine.

The highlights of the announcement include:

• GE Energy is collaborating with Oracle to expand GE’s geospatial product portfolio by developing a network design and maintenance application based on Oracle® Database 10g, Oracle Spatial 10g and Oracle Fusion Middleware.
• This solution is designed specifically to meet the needs of the small- to mid-size North American electric distribution market.
• One can take a half-full or half-empty view of this press release. The statement above makes me lean towards the half-full view. It seems that GE Energy is trying to increase its market share and trying to offer something that the smaller utilities are asking for. My half-full view continues when I realize that there are opportunities in this approach for current Smallworld customers. Let's say your large utility acquires a small- to mid-size utility. Would you rather integrate your GIS system with another Smallworld platform or with an entirely different GIS vendor? I think that any move that keeps Smallworld viable in the market place and does not take away the product that already works for current customers can only be good for the entire Smallworld user community.
  
• GE Energy has been working with selected customers in the development of the application and expects beta testing to commence later this year.
• I'm looking forward to seeing how beta testing goes.
  
• As a result, companies increasingly seek products to meet their needs with minimum customization, ease of install/upgrade and low maintenance.
• said Bob Gilligan, general manager of GE Energy’s transmission and distribution business. “Our new approach will complement our current offerings and result in products that leverage Oracle’s spatial software."
• GE Energy’s Smallworld Core Spatial Technology* remains a key technology for large utilities and telecommunications customers with complex solution needs. No existing products will be retired as a result of this new offering. The addition of applications based on Oracle Spatial will provide more options for companies with specific IT requirements.
• This is an important statement that no existing products will be retired. I think it is very important that GE Energy repeat that statement until it becomes very clear to all of its current customers. I have frozen this statement in time as a PDF file. In my view this is a very import statement and I will do what I can to hold GE Energy to it.
  

What is not included in the announcement:

• VMDS/Magik will be retired.
• Actually, the press release states the current CST will continue to exist for customers with complex networks.
• GE Energy’s Smallworld Core Spatial Technology* remains a key technology for large utilities and telecommunications customers with complex solution needs. No existing products will be retired as a result of this new offering.

I would be interested in your comments.

Cheers,

Alfred

Where is that error coming from? (an update)

Roger Neal posted a helpful comment to my original post about how to force a traceback on User Errors for debugging purposes.

If you have CST v4.1 you can use the Development Tools application option to "Show User Tracebacks". If find this Development Tools toolkit very helpful. (For day-to-day code profiling, I use the xprf_dialog class alot. This is probably another useful topic to post about later.)

If you are already at v4.0, you could upgrade to 4.1 to get these development tools or you might try loading the product\modules\sw_dev_tools product from the 4.1 CD into your 4.0 image.

If you are at version 4.0, you can do this from Magik...

MagikSF> model.enable_user_error_tracebacks? << _true
$

The method :enable_user_error_tracebacks? was only introduced at version 4.0. If you have an earlier version you will still need to do something like the hack I described in my original post.

Smallworld version 4.1 Feature Review

I recently had the opportunity to install and review the new Smallworld Core Spatial Technology version 4.1 release. The documentation refers to many improvements and I wanted to highlight some of them here.

Incidentally, I created an internal briefing document for my coworkers that "summarizes" the changes in 4.1. I say "summary" because it is about 17 pages long but is itself only a snapshot of the very descriptive documentation that accompanies the 4.1 release. If you would like a copy of this summary (it is not a polished document, but contains good details about new features) please feel free to contact me at one of the following e-mail addresses and request the "Smallworld CST 41 Upgrade Features Review" PDF file.


The following is a list of feature enhancements in version 4.1 for Users, Administrators and Application Developers. This list is not exhaustive, but it does include those features that I consider especially noteworthy.

Improvements that Users will see:

• Enhancements to layouts and layout facilities including:
• Customized legends
• better control over the exact position and size of layout elements on the page.
• New text formatting properties
• Linked view ports
  
• Performance improvements to the Smallworld Datastore.
• Improvements to Short Transaction Manager performance.
• Smallworld Explorer performance improved with large data volumes.
• Plotter driver enhancements
  
• New user interface facilities for an interactive application.
• A new TINs editor and Constructions and Reference Origin plugins are provided.
  
• Field editors for raster geometry are updated to be consistent with other geometry field editors.
• Keyboard interaction with object editors is improved
• System bookmarks are introduced, available to all users of an application. In addition, bookmarks are assigned to bookmark groups which can be shared by different applications.

Improvements that Administrators will see:

• New plotting system configuration tools
• The Set Up Smallworld Printer Wizard provides an easy-to-use GUI for configuring new plot filters.
• The Smallworld Printer Properties dialog box can be used to modify plot filters.
• The Print Test Plots dialog box can be used to test newly-configured plot filters.
• Oracle
• Extended and updated Smallworld on Oracle® facilities for use with Oracle 10g data types and Oracle Real Application Clusters.
• Extension of the Smallworld Authorisation system to use LDAP user authentication.
• Changes to the Smallworld Datastore Server.
• These improve the consistency of facilities on UNIX® and Windows® servers and allow increased tolerance to network failure.
  
• New tools for administrators and configurers
  
• The Administration application is extended to give access to additional facilities.
• A remote_cli exemplar is added, to allow one Smallworld session to run a command line interface on a second session. This is intended for development and debugging only.
• The new utilities swmfs_monitor and swmfs_lock_monitor are added to allow improved monitoring by a Smallworld Datastore Server (swmfs).
• new ds_transfer module version and Datastore Transfer dialog
• The key features introduced by ds_transfer version 3 are:
• Graphical user interface for starting and monitoring an operation.
• Online compression. This enables incremental transfers to be made after an initial one, and as these simply transfer changes they should be much faster, minimising the window when the dataset is unavailable for use.
• Progress reporting, and more controllable logging information.
• Tests show that ds_transfer version 3 is generally slightly faster than version 2, but not significantly so. However, online compression should dramatically reduce the downtime required for a transfer.

Improvements that Application Developers will see:

• simple areas can now contain holes. This means that simple areas are now more compatible with other area geometry.
• 64-bit UVA values
• New tools and enhanced facilities for application developers who need direct access to the Magik prompt of a Smallworld session.
  
• A remote_cli exemplar is added, to allow one Smallworld session to run a command line interface on a second session.
  
• Development Tools including:
• object inspector
• profiler
• system monitor
• and many more useful tools.
• Keyboard shortcuts for map actions can now be configured. [my note: this should make it easier to revert zoom/pan actions back to what users were comfortable with in earlier versions]
  
• progress counter enhancements.
• The Rate and Estimated Time to Completion (ETC) are now calculated over a number of recent samples and exclude outliers. This should give a much more accurate ETC.
  
• Incrementing the counter manually, instead of doing next(), is now treated correctly.
  
• When processing records in batches using get_upto_n(), report output is at more consistent intervals.
• There is now a reset() interface, so a counter can be set back to 0 after a potential wait while other things were done while it was created.
• total slot is now writable, so a progress counter can be supplied to a piece of code which can populate the total itself.
• workspace layouts
• This functionality has been used by Physical Network Inventory (PNI) for some time. Now it can be used in other applications as well.
• A remote version of the sw_databus class called sw_remote_databus is implemented. This class allows multiple computers to talk to each other using protocols based on the databus communication channels. with the limitation that only strings can be passed.
• [my note: this remote databus behaviour could spawn a whole new set of distributed GIS applications in Smallworld. It reminds me of the GeoRSS protocol]
  

As mentioned before, this list is not exhaustive but it does give you a sense of the enhancements that caught my attention. If you want a more detailed summary, please send me a note and I will forward it to you. And if you want a really detailed treatment of the enhancements, you can look at the Documentation that accompanies the SW 4.1 CD. The documentation is well laid out and very informative.