The Alchemist Guild’s Blog

The latest release 0.4 introduced some nasty bugs with all the changes that were made porting all the code to FPC and the code folding which really did a number on the syntax parser/text editor.  I didn’t really want to release this version but I felt if I didn’t you wouldn’t get a native Intel version that could run on 10.5 for many more months. Sorry guys!

Outstanding bugs since 0.4:

• Sometimes files open with garble. Don’t save! Just close the file and open it again. There is a problem with WASTE and loading files in a thread.
• Opening files while debugging crashes.
• The debugger still causes some leaking in the regex library which causes the application to parse files very slow after the debugger has been run. The only cure is to quit the debugging sessions.
• Breaks points are not synched properly after multiple debugging sessions. Quit the application and try again.
• In 0.4b Compile Syntax is crashing. Just open the files and they will be compiled and saved as you go along.

3 months after the first Intel native release and still I have not produced anything like I had hoped. I made a terrible mistake in deciding what the first new feature I should add was: code folding. This was a intensely complicated feature to implement and complicated the editor down to every detail from copy/pasting, saving/loading and typing/syntax styling. Let it be known, WebScripter does have a pretty nice implementation working but the system has put such a strain on the text editor API WASTE it has forced to remove it altogether. This was a long time coming considering the crippling speed issue and developer failing to provide support. He is btw basically quitting WASTE, I should have known this 2 years ago…

Next version preview (2.1)

I wrote about this headache before regarding PascalGladiator but the root is in WebScripter. This means before the next version I will be up-rooting the text editor and implementing the Cocoa system NSTextView using the new experiemental PasCocoa Objective-C runtime wrapper. I just can’t accept that I am developing programmer tools that rely on a text editor at the core but editing files around 1000 lines is too slow to use. Before code folding it was still a joke, but now it’s just silly.

However I still was able to create some new features that are in development but near the end.

First is the Reference Mode. I wanted this feature for a while now as I’m sick of switching back and forth between browsers and editors to get function arguments and the likes. What’s special about the system in WebScripter is it allows you to design search rules (using Regular Expressions) that can crawl and index a site like a search engine. There will be basics pre-loaded with the release but you can customize and add new web sites on your own. After a site has been indexed you can search the contents from the book mode pane (seen in the screen shot above) or contextual click on code and it will bring you right to the page you need in the reference library. Really useful feature and it’s totally customizable to the user.

Second is inline error checking. I felt the error checking process was intrusive (bringing down a list above the editor, however this will remain available) and that the information could be contained in the gutter using icons and floating help windows. In PHP which has great error handling you can see the stack trace in the gutter and the value of variables by dragging the cursor over them in the text editor. Additionally, real time syntax checks will be available as you type.

But the changes I really wanted to make are more towards user experience and simplifying the preview/run/error system which is just cluttered as of now.  This should have all happened by now if not for the the mistakes I made. Until next time…

It may have been well over a year now but when I heard the news about someone making a Pascal Objective-C bridge (then with no name) I just ignored it for some reason. Maybe because 10.5 had not be released and there was no real reason for unless I wanted to make an Cocoa application. I should have taken notice at least so I could replace my WebKit code with native Pascal. As of 10.5 we now have the HICocoaView API which lets us use NSView classes in Carbon windows, which means: Cocoa is open game for me now. Even if I have to write the wrappers in Objective-C I can use them in Carbon.

A few weeks ago and I have compiled and ran some of the example projects (in PascalGladiator) and started some simple tests with NSTextView and NSOutline/TableView, 2 API’s which there Carbon equivalent is terrible and I spent hours trying to mimic the Cocoa version which has become the standard.

I was thrilled to see in not too long I had the 2 API’s working in a Carbon window and I can say they are designed much better then their Carbon counter parts. WASTE requires at least 1-2 weeks of full time work to get a good HIView wrapper but NSTextView was working I would argue better after just a few.

However there have been the PasCocoa bindings are incomplete and some basic features like overriding a method in an existing NSObject class is not available. Adding methods to Objective-C runtime for delegates/controllers is also a kludge. I plan to start making contributions to the project as well as adding macro support and code generation utilities in PascalGladiator to aid the process.

At any rate this is a great start and something I fully support as the future of Mac development using Pascal.

With the release of 0.4 and what seems to be more bugs than fixes I have hit a cross roads. The text editor API I have been using for years instead of MLTE has proven to be obsolete and no longer suitable for development. The developer has more or less abandoned the project and there is an absolutely crippling speed bug which you have no doubt noticed. The single bug along with the terrible speeds when applying/retrieving attributes to text has cost be countless hours in the hundreds working around this and still the end result is typing in files larger than 1200+ lines is dog-slow.

The final nail in the coffin when code folding which put strain on the already fragile system and basically wrecked the editor. Even if I remove it all the hacks I made in my WASTE HIView have tampered with some basics like syntax coloring copy/pasting and the bugs are there to stay. Worst of all problems is that hidden objects had to be inserted into the text which MURDERED the editing process and was hacked to pieces to even work. I should have never implemented code folding if that was the only option.

I’m trying to release commerical grade development tools which have a text editor at the core and my system is totally broken and hundreds of hours have been poured into this obsolete technology. Depressing…

Unless I change now, I’m doomed. MLTE is just to primitive to handle what a good editor needs. Is that really all the Mac has to offer Carbon programmers? But there is one option…

With the release of 10.5 there is an HICocoaView API which allows the wrapping of a NSView into a Carbon application. I thought this was cool at first, but overlooked until my current crisis. NSTextView is a great API which is FAST and offers a great system for applying/retrieving custom attributes to text. I never considered it because it was Cocoa and thus I could not use it. My HIView WebKit view wrapper I use is based on Objective-C code that I slapped together (barely) and uses Carbon events, which works well enough. This is the only HIView based API that Apple bothered to bridge for Carbon. Shame…

I’m sorry to say the next version of PascalGladiator will not be anytime soon because I am committed to removing WASTE from my code once and for all and using HITextView, which I will be authoring using PasCocoa, all native. Also get prepared for PascalGladiator to be 10.5+ no exceptions. Code folding will need a serious overhaul which I may just omit for since I’m so sick of it. I wish the only Intel native version was more stable, next time!