SRL Archive - Development

So, I have been thinking about how we do the whole branching thing in Simba.

Currently, new, big features are on a separate branch:

$ git branch
  cts-rework # CTS rework + fixes. Ideally, we'd split this up into several branches.
  dgby/mem-clean
  lape-integration
* master
  mem-clean # Memory clean ups in here. (Dgby fixed most of the existing ones!)

Obviously, master is the ``release'' branch. Current tags:

$ git tag
cts-normal
cts-sub-inline
simba-0.92
simba-0.93
simba-0.94
simba-0.95
simba-0.96
simba-0.97-rc1
simba-0.97-rc2

Where the 0.9X (with X an even number) are meant to be stable releases.
Although I think we'll just call 0.97 stable as I want a few more releases till we hit 1.0. :p But starting from 1.0 I think we will use .N as stable when N is even, unstable if odd. I'm somewhat starting to wonder if we really need unstable releases though.

Now, I was thinking that it would be time for a new Simba release in a few weeks. However; the only branch I really think is for merging in the stable release (That would be 0.97 or 0.98) is mem-clean. I figured it wouldn't lead to a lot of changes, but I was pleasantly surprised:

$ git shortlog simba-0.96.. --no-merges|cat
John P (Dgby714) (13):
      Simba: SSL Support for GetPage.
      Extension: Paster Update
      Extensions: Paster Update
      Extension: Paster Update
      Extension: Paster Update
      Extension: Paster Update
      Extenstion: Paster update and version change.
      Extensions: Update to Paster, Updater, and SRL
      Extension: Paster Update, Deleted wrong line.
      MML (ocr): Free old Fonts on Copy.     Simba: Free OCR_Fonts on Close.
      ExtensionManager: Free'd a few objects that got left in memory.
      Simba: USE_EXTENSTIONS Define. (Missed a file)
      Simba: USE_EXTENSTIONS Define.

Merlijn Wajer (58):
      libMML: Some bugfixes + started changing indent.
      libMML: Vim-ized. Fixed a lot of errors.
      Documentation: Fix sentence.
      Documentation: Spelling fixes.
      Simba: Completed USE_RUTIS compiler directives.
      Windows Installer; Update version number.
      Doc: Update version number.
      Simba: Changed version to 820.
      Simba/PS: Add/Fix include_once support.
      Simba/PS: Added extra directive ``FIXME''.
      Simba/PS: Added ERROR directive. Renamed FIXME
      Simba: Cleanups in several units.
      Directives: WARNING directive change.
      Simba: Few more cleanups.
      Commits: Initial support for external editor.
      Simba: Added file information.
      Simba/ReadOnly: Some additional changes.
      Simba: Fix tab closing using 'x' on the tab.
      Simba: External editor now works.
      Simba: Updater only shows when required.
      Documentation: Move outdated documentation.
      Documentation: Add Read-Only mode documentation.
      Simba: Fix tab closing depending on the Sender.
      Documentation: Small fixes.
      Simba/PS: Add Log10.
      Documentation: Added initial colour conv doc.
      Documentation: Add initial header.
      Documentation: Add initial socket doc.
      Documentation: Clean up web documentation.
      Documentation: I accidentily the web.
      Documentation: ... Fix web.
      Simba: Fix spelling.
      Documentation/Web: Web documentation by ``Echo_''!
      Documentation/Web: Small addition.
      Simba: Add global keybindings for Linux.
      Simba: Switch to UK English.
      Simba: Keybinder: bind -> unbind.
      Simba: Start cleaning and memory management work.
      Simba: Add directives file. Clean up hotkeys.
      Simba: Further clean up keybinding code.
      Simba: Some more cleanups.
      Simba: Change handbook URL to villavu.
      Simba: Change handbook URL to villavu.
      Simba: StrToInt raises an exception now.
      Simba: StrToInt raises an exception now.
      Simba: Allow CTS2 for Bitmap searches.
      Simba: Allow CTS2 for Bitmap searches.
      Simba: More keybindings on Linux.
      Simba: Update and add TODO files.
      Simba: More TODO fiddling.
      Simba: Bump version to 830.
      Simba/Documentation: Add *Sound documentation.
      Simba: Fix compilation under Linux x64.
      Simba: Update lape head.
      Simba: Changed the TODO file a bit.
      Simba: Add TODO's.
      TODO changes for script manager.
      TODO changes for script manager.

Raymond (10):
      RUTIS define for Wizzup...
      Added few Gaussian related functions and ConvoluteMatrix for bitmaps :-).
      Added example file which Blurs a given image, using a Gaussian Matrix.
      Should compile with latest LCL, donno if it works, but meh, just graphic components.
      Some minor changes.. Revert if you dislike.
      Temporary fix.. It's ugly.
      Added [url]http://villavu.com/forum/showthread.php?t=62348[/url]
      Hide console by default & make disguise change the name of the application as well.
      Compile windows!
      Windows binding.

That is since the last Simba release. Merging cts-rework adds an additional 12 commits, but that branch is far from finished. Merging lape-integration would bring in a LOT of changes; but this branch also is not yet ready to be in mainline.

However, I think that we may want to add another branch, called simba-next, in which we'd merge somewhat unstable branches. I know Linux does this. I'm not actually completely sure this is a good idea, but I mainly want to keep master clean, as several third parties rely on it. (Moparisthebest for example, bases his nightly builds on Simba master)
simba-next would be out ``unstable'' head to which we can commit more unstable changes. Once it feels more stable, we can merge it into the master branch.

To conclude (nope, no TL;DR here), I'm not sure if the simba-next branch is a good idea but I hoped you enjoyed the read regardless, I know I would have. :p

Branches to come soon:

script-manager
cts-jit
cts-3

I think simba-next is a good idea. =)

Merging lape-integration wouldn't change anything for the end user (Except add a disabled menuitem)
Tho I think we should finish it before merging still.

I think it's a good idea to have a "pre-release" so-to-speak branch. Would be good for testing and making changes till it's ready to be merged to master.

Do eet.

I'm not sure what to say about simba-next other than it sounds like a good idea, but I hope that the cts 3 branch gets some work done :D I've been wanting to play with CTS 3 even though I know it's slow because of the XYZ color space conversion.

Alright, I added the simba-next branch.

From: TomTuff
I'm not sure what to say about simba-next other than it sounds like a good idea, but I hope that the cts 3 branch gets some work done :D I've been wanting to play with CTS 3 even though I know it's slow because of the XYZ color space conversion.

Actually, CTS 3 uses CIE-L*a*b, not XYZ (even though CIE L*a*b is based on XYZ). But yeah, it'll get some work soon enough. :)

I thought my nightly/hourlies were supposed to be unstable or cutting edge, so it helps you see how your last change affects other platforms?

Either way, would you like me to run the same thing for the simba-next branch in a different folder or something?

Also, if you switch to something for tags that I can parse, then I can automatically set the stable versions. (either every tag is a stable version, or anything not ending in -rc*, or whatever, just let me know)

From: moparisthebest
I thought my nightly/hourlies were supposed to be unstable or cutting edge, so it helps you see how your last change affects other platforms?

Either way, would you like me to run the same thing for the simba-next branch in a different folder or something?

Also, if you switch to something for tags that I can parse, then I can automatically set the stable versions. (either every tag is a stable version, or anything not ending in -rc*, or whatever, just let me know)

I'm still not sure whether to make odd numbers testing versions and even numbers stable versions or just use -rc to mark a version as testing. Suggestions?

lol.. Is this cuz scar titan was just introduced or is this real? Anyway simba-nx is fine I guess and for betas just use
simba x.y -b#

So simba 1.15-b3 for beta 3..

From: ggzz
lol.. Is this cuz scar titan was just introduced or is this real? Anyway simba-nx is fine I guess and for betas just use
simba x.y -b#

So simba 1.15-b3 for beta 3..

This thread is over a month old… SCAR 4 was released yesterday

From: ggzz
lol.. Is this cuz scar titan was just introduced or is this real? Anyway simba-nx is fine I guess and for betas just use
simba x.y -b#

So simba 1.15-b3 for beta 3..

IP lol'ed… You should feel pretty dumb right about now ;p

From: Wizzup?
I'm still not sure whether to make odd numbers testing versions and even numbers stable versions or just use -rc to mark a version as testing. Suggestions?

From a parsing standpoint, in Bash it would be easier for me to see if it had '-rc' in it than to try and check if it was an odd or even number. So that's what I'd suggest. :D

From: moparisthebest
From a parsing standpoint, in Bash it would be easier for me to see if it had '-rc' in it than to try and check if it was an odd or even number. So that's what I'd suggest. :D

Alright, we'll stick to -rc for unstable and others for stable. (With no -XXX postfix)

Ok great, I'll update my script when I get some time to automatically tag stable and unstable builds.

From: moparisthebest
Ok great, I'll update my script when I get some time to automatically tag stable and unstable builds.

And I think for bugfix-releases I'll just append a .<digit>, so the first bugfix release for simba-0.97 would be simba-0.97.1.

Ok, I'll just treat those as stable versions.

Also, mopar, it might indeed be cool to autobuild several branches too. For now we're keeping the master the ``stable'' branch, simba-next will get all the features for 0.98 (or generally just next version) and lape-integration might personally interest you since it adds an interpreter that works wonders already (IMO) on Linux.

Perhaps it would make more sense to create a -0.97 branch and use master for all the development, but it feels more dirty to me; and we've already kinda agreed on using this for now.

From: Wizzup?
Also, mopar, it might indeed be cool to autobuild several branches too. For now we're keeping the master the ``stable'' branch, simba-next will get all the features for 0.98 (or generally just next version) and lape-integration might personally interest you since it adds an interpreter that works wonders already (IMO) on Linux.

Perhaps it would make more sense to create a -0.97 branch and use master for all the development, but it feels more dirty to me; and we've already kinda agreed on using this for now.

And OS X, or just Unix based in general I assume.

From: Bobarkinator
And OS X, or just Unix based in general I assume.

Yep. ;)

I didn't write that script with multiple branches in mind, but I can probably adapt it.

How far is LAPE from production-ready? Also, have you put any more thought in supporting python scripting in Simba? That's what I'd really like to have. :D

From: moparisthebest
I didn't write that script with multiple branches in mind, but I can probably adapt it.

How far is LAPE from production-ready? Also, have you put any more thought in supporting python scripting in Simba? That's what I'd really like to have. :D

Well, I wouldn't call lape production ready just yet, but it's making rapid progress, I think it mainly just needs more testing before we can decide whether it is production ready or not. (Or does that make it not yet ready for production ;D )

As for the lape integration in Simba, I'm sure some things are lacking. Eventually I'd like lape to take over all pascalscript features, which includes the code completion/hints and extensions. But that's not done yet in Simba. Running scripts with most of Simba's functionality is, though. In theory SRL should nearly compile, as well.

As for python support, I still think the main thing that'd need to be finished is pyMML. Once that is done we can simply launch a python interpreter if it is installed, but I wouldn't count on codehints/completion any time soon, if ever with python. Just launching an interpreter would also have the downside of making it hard to actually interact with the Simba GUI, but I'm wondering if that is really necessary.