I just read the “Kudos” thread posts from last night. Talking to Geoff is like talking to a wall: “I know best”.
2 Likes
Don’t you see? They’ll just keep adding a thousand years every time you’re naughty. You’re never going to get back in at this rate
1 Like
I first thought this was a post on TOF about this forum and someone had found a way to talk about ifnotnil.com 
3 Likes
Me too 
oh you can just post a link to here that goes through bitly or some other url shortner
but DONT make it obvious you’re talking about INN 
Which guideline would you break if you posted in the official forum a link to a thread in this forum discussing something relevant to the thread in the official forum? For example if I went to the official forum and posted that the OP can find additional information on “Xcode 12 experiences?” in a certain link (which would bring them to the thread running in parallel here).
Would it be the following rule?
“Discussion of or links to blogs or websites that share privileged or internal Xojo company information (financials, personnel, etc.) is not permitted.”
I don’t see how that rule could be applied to that situation.
Xojo has made it so you cannot post inks that include the word ifnotnil in them
Its literally not possible to post a direct link to this forum
So ifnotnull is on their naughty(word) list!
hence why I said if you use an URL shortener that points here it works since it no longer says if not nil in it 
na… don’t use URL shorteners… they are ugly and btw. banned in every better firewall…
but regarding the “testing for nil” thread I bareley could resist not to write something 
But… let’s move on… look to the future, how Swift runs on Windows… the area of cross-development systems is moving…
What the heck did I do to deserve this fate? From Geoff:
I do want to thank @Beatrix_Willius for her excellent bug reports. She writes concisely and usually provides a sample project or steps to reproduce. This makes it far easier for the engineers to fix the bugs she reports and as a result, her bugs tend to get fixed faster. She also as a result has a reputation amongst the engineers such that when they see a report from her, they know ahead of time it’s likely to be very well-written and complete which, as you can imagine, makes them only wish to tackle those reports more quickly.
I worked for 20 years in a company where ALL Dilbert comics were true.
2 Likes
ha !
now yer special
There are some users who consistently wrote really good reports over the years
Yours were usually pretty good
@bkeeney often wrote good ones as well
@jotter often wrote good ones
2 Likes
No idea who Juyoun Park is on the TOF, but he is starting to get on my hero list. No matter the smooth talking from Geoff, he keeps getting back correcting him and staying on the points that really matter instead of Geoff’s side-‘stories’. And in a very civilized and argumental way, I must add…
4 Likes
I tried to write good bug reports because, from my own experience, that reproducible bug reports are crucial to getting shit fixed.
2 Likes
Absolutely true! Hate it myself if I get a ‘It doesn’t work and that is it’ report. But I would be surprised if the majority of the cases in feedback are such reports. They tend to close those very quickly if they don’t get additional info, don’t they?
most of the bug reports coming from my accounts were issues that Xojo IDE decided that it needed to report but I had no clue how we got there. just coding along and poof the IDE goes away then says it MUST report the error. and it would keep harassing me about it until I let it go, or I went in and deleted the crash/report details from under the hood.
I wish I knew more about why stuff broke, so I could give Norm & Company better bug reports…
Watch out!
Before you know it you’ll be designated as the new Xojo MVP. 
reports that outline a bug in a way its reproducible usually got looked at quicker than other because - well it was easy to find & see the bug since you could reproduce it
which bothers the heck out of me given I know I and others have long lists of reproducible bugs now 
Event those were useful in many cases because they were exceptions - not outright crashes
Unfortunately crash logs arent as useful because symbols get stripped out and then you have stiff like
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x00007fff6597bfce __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff658d830a abort + 127
2 libsystem_c.dylib 0x00007fff658a0360 basename_r + 0
3 XojoFramework 0x000000010ca2fa79 _Z29ShowDebuggerConnectionFailurev + 0
4 SpawnCompiler.dylib 0x000000011262b260 REALPluginMain + 934808
5 SpawnCompiler.dylib 0x0000000112694dfb REALPluginMain + 1367859
6 Xojo 0x0000000107a430cb DebuggerMap.LookupLineAddress%b%o<DebuggerMap>si8&i8 + 107
7 Xojo 0x000000010a207ac5 StudioDebuggerUI.StudioDebuggerUI.LookupBreakpointAddress%i8%o<StudioDebuggerUI.StudioDebuggerUI>si8 + 421
Note the absolutely enormous offsets in Frame 4 and 5
REALPluginMain + 934808
REALPluginMain + 1367859
Those are offsets from the main entry point of the routine that the crash reporter THINKS is relevant
But those entry point names could be entirely wrong !
If symbols get stripped out the crash reporter hunts backwards for the last symbol it can find assuming that it MUST be the right one
But if some intervening symbols have been stripped out then it might hunt back way past the actual entry point and finds something else
Not great but there’s not a lot Xojo can do about that since this component that hunts things down isnt part of Xojo
So crash logs arent quite always useful
Someone needs to send that Jayoun Park a private message with the a bitly link to here