Coding
Conditional Loading
Prior to SW5, load_file_stop() could be used to stop a file from being loaded. It could be put at the beginning for testing if an exemplar is included, or at the end to not create a magikc file. In SW5, load_file_stop() stops the loading of everything. This is due to the fact when you compile things to a JAR the whole file is saved there, so it can't really support this easily.
So if you need to load file based on if an exemplar is loaded, or something like that, you can leverage the !module_file! dynamic. This is available when you compile, load module, load_file_list, or F2-b (load_file) the file individually. The only "gotcha" is that in SW5 !module_file! is a sw_module_file, and in 4.3, it is a string. So you need to handle it appropriately.
_dynamic !module_file!
_if smallworld_product.release_version < 5
_then
load_file(!module_file! + "/../streetview_acp.magik")
_else
# notice as_charvec()
load_file(!module_file!.as_charvec() + "/../something_else.magik")
_endif
$System.do_command()
Prior to Smallworld 5, you could do something like system.do_command("set") to display all environments. In Smallworld 5 you must prefix the command with "cmd /c". I believe this is a Java thing that you need to call external commands with cmd /c. So this will work in SW5: system.do_command("cmd /c set")
HTTP Connections Behind Proxy
If you have created java code that does any type of connection to the web like HttpURLConnection, you may run into issues connecting behind a Proxy Server.
You can add code to incorporate proxy code like:
Proxy proxy = new Proxy(Proxy.Type.HTTP, new InetSocketAddress("10.0.0.1", 8080));
conn = new URL(urlString).openConnection(proxy);Or you can use the -D options http.proxyHost and http.proxyPor to start the Smallworld Java session. This way you don't have to add the proxy to all of your code.[1]
This could also be used by ACPs
Method Existence
The method table on mixins are a little different than 4.x. To determine if a method exists locally on a mixin you can do this:
dd_record_mixin.define_method_target.local_method?(:is_valid?)Threading
Smallworld 5 appears to be more susceptible to thread collision and resulting in application or session unresponsiveness. Try to make your code as thread safe as possible. This is very true with GUI interactions.
Information
- Tracebacks have the thread name in the header. Here are some examples. Alchemy-REPL & queued_work are the thread names
---- traceback: Alchemy-REPL (light_thread 95837890) ----
---- traceback: queued_work (heavy_thread 1039948739) ----- Look at naming your threads when you create them.
- sw_gui_task_owner - this is a singleton exemplar that controls all GUI threads
Coding
- lock directive. Note the _lock or _protect _locking directives do not work outside a single thread. I initially thought by having these statements a thread would wait on another thread to release the lock before accessing. That is not the case. If a second thread calls lock on an object which another thread has a lock, you will freeze the two threads. I believe this is "deadlocking?". Use atomic_queue to ensure different threads do not touch same objects.
Messages
The message handler works a little different in SW5. The PRODUCT.SER file holds information on all MSG files to be loaded. This has a draw back of when you add a new MSG files after the product is serialized, it will not be read. Note that you can change existing MSG files and they will be compiled to new MSGC files as before.
Patch MSG files
FCSI has developed code to load MSG files anytime and anywhere…
