Writings from the sticks

Xojo can return arrays from method calls like

Function foo() as String()

Now what happens if you leave such a function without a return statement ?
Xojo will happily return a NIL array – not one that has no members but one that IS NIL

For instance, if you create the function as

Function foo() as string()
End Function

and then call it later like

dim arr() as string = foo
break

The debugger will show you that arr is NIL; not a valid array with no elements (some Xojo documentation conflates these two things but they are NOT the same)

If your code was

dim arr() as string = foo
arr.append "123"

You will get a NilObjectException (yes internally arrays are objects)

So how DO you check which it is ?

1. use Is Nil to test if you got a NIL array
2. use the count property if the array IS NOT NIL

dim arr() as string = foo
if arr is nil then
  // ok now how do I deal with this ?
  // how can I make it so I can add items ?
else if arr.count = 0 then
  // ok we got back an array with no items in it
  // appending items will work !
else 
  // ok we got back an array with items in it !
  // appending items will work !
end if

Notice that if we get back a NIL we cant do much since there is NO array. Trying to append will raise an exception. So what can I do to make it NOT be a nil array ?

At first you might try the Redim function to create an array like

Redim arr(-1)

in API 2 this is arr.ResizeTo like arr.ResizeTo(-1) which will also fail

The right thing to do is use the Array FUNCTION to create one with some elements then resize it to 0 like

arr = Array("")
redim arr(-1)

The resulting code then looks like

dim arr() as string = foo
if arr is nil then
  // ok got a NIL array
  // but thanks to norm we know how to fix this
  arr = Array("")
  redim arr(-1)
else if arr.count = 0 then
  // ok we got back an array with no items in it
  // appending items will work !
else 
  // ok we got back an array with items in it !
  // appending items will work !
end if

// and now here you can append items
// regardless of what the function gave you back 

Have a great day

In the last 2 years I’ve taken up golf more seriously than ever before. Like so many others I’ve played an occasional game here and there for many years but there have been very long stretches between where I played none at all.

Two years ago my wife got me a membership at a local course & I decided that in order to make it worth while I had to play at least 20 times. Thats probably more games of golf in one year than I have ever played in total.

But it was a great distraction from work and life in general and a nice activity for the spring, summer, and fall activity in addition to skiing in the winter.

I’ve made a few friends on the golf course and one this year helped me out a lot in improving my game. (Thanks Mike !)

And he felt good enough about my improvements to invite me to be his partner at a tournament at another local course.

We played and I thought we had played well. But both of us had said all weekend that we believed we were just in it for fun and didnt expect to win anything.

AND HOLY CRAP ! We came in first in our group !

Nice surprise to end a fun weekend !

Well I’ve narrowed my issue down to DISPLAY SLEEP

If I set my monitors to NEVER sleep and only run the screen saver than my monitor madness doesnt happen

So something about letting them sleep screws thing sup to the point when I log back in it can take up to 10 minutes for me to get them, back under control

Lord I hate these things

So here’s a little droplet, in AppleScript, to remove them

Yes I thought about writing it in something else
But the AppleScript is 213 K and just about everything else would be quite a bit larger

Some, many megabytes

The ENTIRE text is as follows

-- This droplet processes files dropped onto the applet 
on open these_items
  repeat with i from 1 to the count of these_items
    set this_item to item i of these_items
    set the item_info to info for this_item
    if folder of the item_info is true then
      process_folder(this_item)
    else
      try
        set this_extension to the name extension of item_info
      on error
        set this_extension to ""
      end try
      try
        set this_filetype to the file type of item_info
      on error
        set this_filetype to ""
      end try
      try
        set this_typeID to the type identifier of item_info
      on error
        set this_typeID to ""
      end try
      if (folder of the item_info is false) and (package folder of the item_info is false) and (alias of the item_info is false) then
        process_file(this_item)
      end if
    end if
  end repeat
end open

-- this sub-routine processes folders 
on process_folder(this_folder)
  set these_items to list folder this_folder without invisibles
  repeat with i from 1 to the count of these_items
    set this_item to alias ((this_folder as Unicode text) & (item i of these_items))
    set the item_info to info for this_item
    if folder of the item_info is true then
      process_folder(this_item)
    else
      try
        set this_extension to the name extension of item_info
      on error
        set this_extension to ""
      end try
      try
        set this_filetype to the file type of item_info
      on error
        set this_filetype to ""
      end try
      try
        set this_typeID to the type identifier of item_info
      on error
        set this_typeID to ""
      end try
      if (folder of the item_info is false) and (package folder of the item_info is false) and (alias of the item_info is false) then
        process_file(this_item)
      end if
    end if
  end repeat
end process_folder

-- this sub-routine processes files 
on process_file(this_item)
  -- NOTE that during execution, the variable this_item contains a file reference in alias format to the item passed into this sub-routine
  -- FILE PROCESSING STATEMENTS GO HERE
  set thePathToFile to POSIX path of this_item
  log thePathToFile
  
  set theresult to do shell script "/usr/bin/xattr \"" & thePathToFile & "\"" as text
  --  log theresult
  
  set theParagraphs to paragraphs of theresult
  repeat with i from 1 to length of theParagraphs
    set theCurrentListItem to item i of theParagraphs
    -- Process the current list item
    -- log " line" & (i as text) & " = [" & theCurrentListItem & "]"
    
    do shell script "/usr/bin/xattr -d " & theCurrentListItem & " \"" & thePathToFile & "\""
    
  end repeat
  
end process_file

Well there’s a bummer

MS is ceasing development of VS on macOS

Too bad

And some would have you believe that this is the end of C# on macOS.

Not true
Unlike other proprietary tools that have a single IDE & compiler from one company C# has alternatives that can read & write VS projects and compile them on the Mac. It’s open sourced. Heck MS even made Roslyn, their compiler infrastructure open source.

Rider, from the JetBrains folks, works just fine.

Yes its not free like VS was – unfortunate.

But its not exactly expensive either

And if you REALLY want their super duper “do anything in any language we support” package

Still VERY affordable

Will I miss VS ? yeah a bit – but I’m sure I’ll manage to carry on on my mac

A little over a year ago Xojo switched to using a new issue tracker
IMHO this was a good move.

Not only does it seem to be more capable it lets them quit spending time on something they can buy and just use the heck out of. It lets them focus on their core product rather than ancillary things like bug trackers.

That said, a little after they did this switch I started watching some of the numbers that were publicly visible. Things like open case count, open bug count, etc.

A GIANT caveat. The numbers I see are NOT the same as what you see. From what I can figure out this is because it will depend on what cases are confidential and I might see a different set of those than you do. So the numbers should be close – but unless you’re me you will likely see different values.

That said here’s what I found :

The day I started tracking things there were 6313 open reports of all types (bugs, feature requests, etc), 29787 closed and a total of 36100 reports
As of this writing there are 6960 open reports, 31924 closed and 38884 in total.
2784 new reports (note not necessarily BUGS – just reports)
Thats an average of 7.6 new reports per day

Also the day I started there were 2018 open bug reports and 24769 closed.
Today there are 2276 open and 26054 closed.
Xojo has closed a lot of bug reports in the interim.
But, as you can see, they are slowly falling behind.
Perhaps why archiving reports was even started.

The day I started recording numbers the # of archived bug reports was 4154.
Today that number is 4286
Note that it did creep up for some time but has halted since Xojo is no longer having their bot auto-archive old reports.
So even after closing many reports, and archiving many, the # of open reports has still crept up quite steadily from release to release,

The other thing I have watched is the first public case #. This is the first report that I can see on any given day. It seems to be a purely sequential number applied to any report.
That day the first # was 69400.
Today its 73040.
This suggests in total over the one year time frame there have been 3640 reports (feature requests, bugs, and whatever other categories) It also suggests there are many confidential reports that cant be seen. What type they are or what those might constitute I wont speculate about.

But it does suggest the average number of reports per day is some where between 10 and 11.

Having a years worth of data lends itself to some analysis.
The average # of new reports (not specifically bugs) is about 11 per day.
Of those, just under 50% end up being bug reports.

As well since we know the release date of every release during that period we can see how many reports, and bug reports there are from the last release to the next.

Release 2022r2 to 2022r3 (78 days) there were 868 reports (381 bug reports)
2022r3 to 2022r3.1 (6 days) there were 97 new reports (48 bug reports)
2022r3.1 to 2022r3.2 (19 days) there were 307 reports (130 bug reports)
2022r3.2 to 2022r4 (34 days) there were 475 reports (181 bug reports)
2022r4 to 2022r4.1 (5 days) there were 45 reports (28 bug reports)
2022r4.1 to 2023r1 (98 days) there were 983 new reports (318 bug reports)
2023r1 to 2023r1.1 (13 days) there were 196 new reports (85 bug reports)

As of today 2023r2 has not shipped.
From the last release to now there have been 963 new reports & 334 bug reports.

Every release Xojo fixes many bugs, adds some new features, and makes other changes.

What their own issue tracking system says though is the the # of bugs fixed is quickly outpaced by the number of new bugs. You’ll notice on the graph that FIXED never exceeds BUGS which means there are more new bug reports than are being fixed.

So the number of open bug reports continues to grow over time. To the point they fall so far behind in fixing bugs that they archive bugs that they haven’t analyzed, reviewed, or fixed.

It seems clear from their own numbers that staying the course and doing the same things they’ve always done and in the same way they’ve always done is a losing proposition and eventually there will be so many open bugs that archiving simply has to start again. Or bug reports will simply be left to languish forever. Neither of these are great prospects.

A change in process that focuses on creating quality software from the outset, well before ANY code has been written, and extending to the point it’s released that includes extensive unit testing, REQUIRING unit tests for every piece of code, and expanding the unit tests as bugs are reported & fixed would be a great start.

Expanding the team so developers have the time to create all this is necessary. Not just nice, but necessary.

And someone needs to be “the code god” and have few development duties & more oversight and review every last check in and make sure they do meet all standards of code (format, unit tests, integration tests, etc)

And an expansion of the internal QA team is needed

The other thing I followed was the beta releases as far as possible.
What I observed is that, for every beta release the # of participants starts out relatively high. If thread reads is an indicator of the actual # of downloads of a beta release. Since Xojo posts expiring download links it seems thread reads is a reasonable proxy for actual download. It should at least trend in the same direction as actual downloads.

Most betas seem to start with somewhere between 200 and 300 reads (downloads?) of the initial beta release. The one outlier here is Android which started with > 500 reads. However they all trail off and end up with somewhere around 150 or so.

There are supposedly hundreds of Testers yet the actual number that seem to test is a fraction of the total (about 1/6th)

Many testers haven’t even logged in during the latest betas. About 50% of all members of the testers group haven’t logged in since the beta for 2023r2 started.

The same trend was true for Android testing where about 20% of the entire testers group hadn’t logged in for the entire time Android was in beta (560 days)

Now you might ask yourself “if Norm can see this from outside surely someone at Xojo is watching these trends as well ?”

To be honest I have no idea if they are. Or arent.
Either way the #’s done paint a picture of a process that is getting better, or of a very involved & engaged testing process.

However, there are things I am sure of.
I’m sure this will get read.
I’m sure I’ll get an email about it and how it violates some rule Xojo has never posted or has just invented for me.
And nothing will change 🙁

Declined to initially update to Ventura because of my monitors flickering like mad

Installed it and tested each new update on an external and eventually YAY the flicker was gone ! Time to update

So I did – a few things broke (no surprise there)

But now the flicker is back – every time the monitor go to sleep, I sign out, the machine reboots, just about any time the monitors shut off.

And to top that off the Displays Preference pane often crashes as they do this

ARG !!!!!!!!!!!!!!

In the increasingly badly named Enum Extender project I’ve added a way to take a bunch of text defining properties and make it possible to paste into the IDE

see this conversation for why

Now a bunch of text like

Public setting_Username As String
Public setting_Password As String
Public setting_PortNumber As Integer
Public setting_HostName As String
Public setting_MaxConnections As Integer

can be put into Enum Extender and it will set the correct pastable data onto the clipboard

See the new Property Paster window in the project

*NB : at this time the app does not accept

Public Property setting_Username As String

the PROPERTY word is NOT actually correct

An update soon will fix this

MBS released a Scintilla based text editing plugin some time ago

And I’ve been working on adding a Xojo specific Lexer to it in C++

How fast is it ?

Well dont blink or you’ll miss that I paste 19500+ lines into it and in the moment it takes to redraw its marked all the fold points, and colorizes the entire document. And watch how fast it scrolls !

OF NOTE there is this newly discovered capability

And I fixed my Scintilla lexer/parser to handle it