[Openmcl-devel] [info-mcl] MCL 6.0 preview

[Paul Krueger]

Well, as I said, I'm a month or so away from feeling good enough about it to check things in. The vast majority of the individual pieces of functionality have been tested in isolation and work, and the GUI that pulls everything together is designed in IB and implemented in Lisp. I'm just now starting to test that code/GUI combination. Assuming that goes reasonably well I'll then want to pull together examples that demonstrate how to use it. I have a couple mostly done now that I previously used to test some of the functionality (like the lisp NSDocument subclass with undo/redo/save/slot-binding, etc.), but they will probably need additional work to be totally complete examples. Then I'll want to do documentation and if you've seen the IB/CCL tutorial that is already in my contrib directory then you know that I try very hard to make that as complete and comprehensible as possible. I may make an exception this time and check things in before the documentation and examples are totally ready, but there just has to be SOME sort of documentation for all this.

I am retired and I get easily distracted by what my wife calls "bright and shiny objects". Yesterday it was over 60 degrees here in Minneapolis, so I HAD to go play golf. This morning I actually got distracted by your blog and one particular link from it that I found pretty interesting. Assuming that the weather turns as ugly as we expect in Minnesota this time of year, I should make fairly good progress going forward.

All that's a long way of saying I hope it's 1-2 months.

Paul

On Nov 9, 2010, at 10:20 AM, Ron Garret wrote:

> Wow.
> 
> When do you think you'll have something ready for others to try?
> 
> On Nov 9, 2010, at 6:33 AM, Paul Krueger wrote:
> 
>> Ron,
>> 
>> I'm within a month or so (hopefully) of checking in a BUNCH of new code to improve app development under CCL. The biggest time factor here might be all the new documentation required; about 99% of the functionality is complete (I'm leaving 1% for things I have yet to discover I need) and about 80% is completely tested. I'm in the process of testing the final integration of all the pieces that have been individually tested. I'm not replacing IB in CCL because I think that is a WAY more complex task than you might imagine and would be doomed to almost immediate obsolescence by the next Apple release. What I HAVE done is make integration between CCL and IB much better so that you can relatively easily integrate IB into a CCL workflow.
>> 
>> My general objective is to make it possible to build up gradually from nothing to a complete stand-alone application bundle. To that end, I've done the following:
>> 
>> 1. Created the concept of a Lisp Application Document which is defined using a subclass of NSDocument. I suppose you could think about this as the Lisp analog to an Xcode project file. This is like any other type of application document but contains all the information needed to build a stand-alone lisp application. Like any other document, it can be saved, opened, etc. To support this I also have a bunch of new classes and functionality that make new Lisp apps with their own document types easily supportable. That includes friendly native lisp support for things like "undo" and "redo" functionality and turning ordinary Lisp objects into data of the sort needed to save and restore a document. It will be trivially easy to save and restore a document that is defined by an ordinary Lisp instance. You can either just save all the slots in the document object (default) or provide a function that specifies what slots should be saved. Slots can contain pretty much arbitrary Lisp objects, including other instances. Right now the code does assume no circular dependencies between saved slots. You can manage that by being careful about what slots get saved. I'll probably work on that little problem at a later date. The functionality that I provide takes care of all conversion back and forth and assures that the slot contents get put back with exactly the same type that they had when the document was saved. It also makes it easy to either run the new app under the CCL IDE or as a stand-alone app when you're ready to do that, with little or no change to the application class necessary. There is some fairly tricky code required to make that relatively easy for developers.
>> 
>> 2. Added a GUI for managing lisp application documents that lets you specify pretty much everything you need to create a full-blown application. It also has menu items for doing things like creating bundles and outputting .h files that correspond to Lisp classes that can be loaded into IB to make it easy to integrate IB with Lisp. And if you prefer to create and describe the class in IB first and import that into your Lisp code, you can do that too. It will convert the .h files output from IB into corresponding Lisp code.
>> 
>> 3. Added much better Lisp support for binding between interface objects defined in IB and Lisp slots. By doing a little metaobject magic I made it REALLY easy to specify that a lisp slot (not necessarily a foreign slot) is bindable by a specified name. You do have to bind via an intermediate controller object that I created, but that idea is fairly straightforward and would be familiar to anyone who used controllers in IB for Objective-C code. That controller has to be installed into IB. It's an extension of the lisp-controller functionality that is already checked into my contrib directory.
>> 
>> 4. I created the concept of a LISP bundle and added code to create and manage it. This is a proper subclass of NSBundle with added functionality to do things like loading Lisp source and making the application defined by the bundle loadable under the CCL IDE. You can also store a lisp application document in the bundle so that if you move the bundle to a new architecture you can easily open the application from within the bundle and install a new executable within it.
>> 
>> 5. I've replaced CCL's build-application functionality with my own (although my code builds on top of many of the same functions that underly build-application). This is now just another thing you can do to your application bundle via the gui (i.e. install an application into the bundle).
>> 
>> 6. Although most of the commonly modified Info.plist values are directly editable in the GUI, there is support for opening the Info.plist in Apple's Property List Editor and then merging the new version of it back into the application document automatically whenever a new version is saved on disk from the editor. I looked seriously at completely replicating the property list editor in Lisp, but in the end decided that this was neither the easiest or best solution.
>> 
>> 7. There is support for opening up IB with a particular NIB file just as you might do from Xcode.
>> 
>> 8. Added the ability to "load" an application under the IDE. This provides as much support as possible for the app short of modifying CCL's bundle. It allows you to toggle back and forth between CCL and application main menus or see both at once if you want. Or before you have your own main menu it will automatically add a few additional menuitems to CCL menus to allow you to open and save instances of your application's documents. About the only thing you can't do under the IDE is double-click on one of your documents in the finder and have it open in CCL. You really need to have a complete application bundle (or modify CCL's) in order to do that.
>> 
>> I was hoping that I'd get all this checked in in time for 1.6, but it's not looking like I'll quite make that.
>> 
>> This may not be exactly what you wanted, but it'll be free.
>> 
>> Stay tuned ...
>> 
>> Paul
>> 
>> On Nov 8, 2010, at 1:03 PM, Ron Garret wrote:
>> 
>>> 
>>> On Nov 8, 2010, at 10:43 AM, Terje Norderhaug wrote:
>>> 
>>>> On Nov 8, 2010, at 7:54 AM, Ron Garret wrote:
>>>>> I'd say it's freakin' amazing that MCL is still alive.  This is a 25 year old development system.  Not only is it still usable, but it even has at least one feature (interface builder) that is still unmatched in contemporary systems AFAIK.
>>>> 
>>>> MCL still stays strong for experimenting with user interfaces and prototyping. It continues to amaze me how easy it is to modify the internals of MCL to create new user experiences. 
>>> 
>>> BTW, I would love to see Interface Builder reproduced in CCL.  It would be particularly cool in this day and age to be able to build a UI using an IFB workalike, and then be able to render that interface as a web form.  I don't have time to work on this myself, but I'd be happy to pay someone else to do it.  So if there's anyone out there looking for contract work who wants to tackle this please contact me.
>>> 
>>> rg
>>> 
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>> 
>