Are the following libraries / projects of interest?

[sancarn]

Hi folks,

Below I have some open source projects which I feel may be appropriate stored in this repository instead of my own profile as I'm not really maintaining these anymore...

InfoWorks ICM Ruby Documentation in Markdown format

I spend a good few months writing and updating the existing ICM ruby documentation to Markdown format so it could be maintained on Github. The documentation isn't as good as it could be but it is much improved from the existing PDF version provided by Innovyze.

You can find this documentation on the below link:

https://github.com/sancarn/Innovyze-ICM-Libraries/tree/master/docs/Infoworks-ICM

Transportable Database JavaScript library

A few years ago I got fascinated by the transportable database format and speant a good week reverse engineering the format. I created the following article about this on my website.

The Javascript Source code: https://github.com/sancarn/InnovyzeTransportableJS

Export flag definitions with Ruby [uses exploits]

This ruby class provides a way for software engineers to get at the definitions of flags in an Infoworks ICM super numbat database. The ruby script explores the binary format of the database assuming the user has access to the raw database files themselves.

At the time of writing there was no other way within ICM to perform this exercise. I definitely believe ICM should be given this capability if it hasn't already.

Cross script data sharing [uses exploits]

Obtain a unique container which can be used by your plugin to store data which won't conflict with other plugins.

InfoLab

Execute UI Ruby scripts from their own UI, ruby scripts are injected via the UI. This project is written in Autohotkey. Last tested in ICM 8.5. This is definitely the most obscure software and is unlikely to work in the latest version of the ICM...

Ruby Console

A REPL for Ruby (equivalent of IRB).

[dfmore]

@sancarn this is absolutely amazing, thank you! There's a lot to chew here, including running this past the developers who maintain Ruby for when it comes to the exploits. I'll process this over time and keep you updated.

[sancarn]

@dfmore I would strongly suggest you migrate the Exchange docs to markdown and away from a word doc. I started here or rendered. Not sure what's updated in the document since it's original release though, and you would likely want to review the sancarn's notes section too.

It'd have a number of benefits:

1. Being able to view it on github
2. Code highlighting
3. Git version control
4. Should be easier for your devs to maintain/generate also

[dfmore]

@sancarn I completely agree, I'm in the process of getting approval.

[dfmore]

Hi @sancarn 👋🏽 a bit of an update. @DaveFace has been doing great progress exploring options on how to expose the Exchange documentation in a more digestable way. This is still very much early days, but I hope this screenshot makes you happy.

[sancarn]

Looks great! :D If the community can suggest changes to the documentation to help the effort that'd be really useful since there are many aspects missing from the documentation (e.g. how to use WSApplication.open() on super numbat servers)

Edit: Also suggest that you put the minimum ICM version in there. As some methods like net.model_object are only available past a certain ICM version.

[DaveFace]

That's definitely something we'd like to expand upon: providing more detail about the exact inputs and outputs of methods, as well as how / where they might be used with some better examples.

We'd have to look into how we could determine minimum versions for methods, if this is relatively simple for us to check we can add it to the tags where required e.g. "ICM > 2021.4". The tags from the screenshot are actually W3.CSS tags, so there are some customisation options (the documentation is still predominantly markdown, but we're using bits of HTML/CSS to add interactivity where it helps)

[sancarn]

We'd have to look into how we could determine minimum versions for methods, if this is relatively simple for us to check we can add it to the tags where required

I have a script for that.

The tags from the screenshot are actually W3.CSS tags, so there are some customisation options (the documentation is still predominantly markdown, but we're using bits of HTML/CSS to add interactivity where it helps)

Sounds good to me! 😊 MDX is another option, which is also very powerful, but a little harder to setup. Didn't know about W3.CSS tags! Very nifty!

[DaveFace]

That's great, will take a look! MDX looks powerful and more intuitive to write, but I'm not sure how much work it would be to integrate. We're planning on using mdBook to serve the documentation via Github Pages (that's what the screenshot is demonstrating), which is easy to customise via .CSS, but implementing an alternative backend is a bit more involved.

[sancarn]

Yes, MDX is probably very much outside of MVP 😊

[dfmore]

@sancarn https://innovyze.github.io/

[sancarn]

Looks great so far @dfmore !