111205:
The new version has a few nice new features. The revision and
enhancement of CUDA support comes directly from the Multicore and GPU
programming course that I am involved in right now. I had to fix the
shortcomings to run interesting demos, especially linking with OpenGL
and GLUT.
But QuickRef is also revived. It wasn't really gone, just not included
in the uploads, but the interest for this useful tool has been small,
and it is pretty big so I felt I shouldn't include it in every upload.
The move to Cocoa is stalled again, this time after finding some
obscure bugs in TransEdit (in TransSkel 5). I have to fix that before I
can make an editor for the IDE.
One more thing... You still need sleep(1) at the end of Hello World and
similar WriteLn-ouput programs. I hope to fix it but stability comes
first.
111123:
I am moving the editing of these pages from good old Home Page to
the pretty ugly and buggy KompoZer, but KompoZer works natively under
OSX, while Home Page only works under Classic or OS9. I also have Flux,
which I will probably phase in as soon as possible.
Some new things have happened with Lightweight IDE. Block identation is added, indent in/indent out in the Edit menu. I also made some enhancements to the CUDA support, so CUDA programs now work with double-click in the Finder, and can auto-link with frameworks.
I am also working on eliminating as many .frameworks files as
possible from the demos. Using the "linkframework" feature in FPC and
the auto-framework feature for C/C++, we rarely need it. The less we
need to mess in global settings and settings files, the better.
These changes will appear in 0.9.3.
One more thing: Process management in 0.9.2 is indeed quite stable.
You need sleep(1) at the end for WriteLn/printf() statements to work
reliably, due to Apple's "Leopard bug", which is still there in 10.6.
Also, there are some other bugs that can crash the program. Multi-file
search is unreliable, sometimes works quite well but may also crash the
IDE.
111007:
After several weeks with 0.9.2, I must say that it makes a difference. I don't think it has locked up a single time since I built it. I won't go back, but the Leopard bug is still in the OS so I need to work around it again.
However, some of my ambitions have been somewhat obsolete. The latest Xcode is quite a bit simpler, at least in the "front". The menus may be as complex as ever, they probably are, but the project window is pretty elegant, which was not the case before. So Xcode has actually moved pretty close to the look I have been aiming for in my (not yet completed) drafts.
Still, I don't think Xcode can work without a project the way Lighweight IDE can.
110923:
After a while, I noticed a weakness with 0.9.2, and it was fairly expected: The "Leopard bug" surfaces again. If you run "Hello world", you see it immediately, you get no output. This is a bug that first surfaced in 10.5, and that is why I call it "the Leopard bug". The bug causes data loss upon closing pseudo terminals. I did a workaround in the past, the "LittleLeopardReader", and I will have to plug that in again, but if it makes the process management shaky again, I don't know what to do. I have done some work on a different "reader", but it isn't working correctly yet.
Another thing: Today I noticed that a new FPC variant has been relesed, FPC for Java! Quite interesting, being able to write FPC code that produces Java bytecode. I strongly dislike Java, it is against everything I believe in (performance, well-designed syntax, the make-tools-not-rules principle) but targeting the same virtual machine with FPC code would make two out of these wrongs right. (Performance would still be subpar.) Now I ask myself if this is important enough for me to support it in Lightweight IDE. I can hack that quickly, but my own need in the short term is limited to say the least. I think I would be interested in using it for writing on-line programs. The idea of writing the same code for on-line use and local installation use, while not sacrificing performance for the latter, with a nice language, that sounds kind of right.
110919:
5-year anniversary upload!
Yes, it is pretty exactly 5 years since I slapped together the very first Lightweight IDE. Ironically, it is pretty unchanged on the surface, but that is because it doesn't have much surface. Well, some parts have changed a lot even there.
The big change today is that I think that I have finally mastered the irritating process management problems, that made compilations and executions stop working after some time. The tests I have ran indicate that the problems might be totally gone, or at least severely reduced. I have ran stress tests, running lots and lots of processes after each other. Before, those stress tests could fail after 30 runs, but now they work at 10000 runs!
If this holds, it calls for celebration. The process problems are so central that they have kept me from reworking other parts, I just have to make this work reliably or there is no point. Now the situation seems different.
Ironically, the old Leopard Reader bug fix could be removed. I found out how the Leopard bug works. As long as I collect my data within 0.6 seconds, I don't lose any data, so now I do it and all is well.
More iPhone support is a bonus, and I am considering uploading TransSkel for iPhone. It really is getting quite nice.
110916:
I have done even more work on process management, not enirely without success. Maybe I have a working model to work from now, but there is still some work to do to make it fit the needs.
I have also done some work on the iPhone support, figuring out how to support the iPad. That seems fairly easy.
110911:
The papers are full of anniversary articles of the 11th september attacks, but I have had my mind on TransSkel for iOS. It has progressed fast this weekend, adding most of the core TransSkel, including SkelViews, view handlers with data couplings (very important and convenient feature of the Mac version), creation calls and other support for a number of view types. The biggest omission now, IMHO, is QDCG, but otherwise it is really becoming a usable framework. (And like the OSX version, I insist that I have a framework with a muuuch nicer learning curve than Cocoa.)
On the negative side, I have worked on making the process management work, and it just won't. Some problems even look like new OSX bugs. I want to get over this problem so I can focus on making the Cocoa version, which was "almost there" amost a year ago! This is frustrating, but there is just one thing to do: find yet one more angle to the problem. Maybe I should find a way to get rid of the pseudo-terminals after all... or package them some way that lets me reset them without quitting the IDE.
110901:
My attempts to fix the process management problems seem to have failed. I have to put it aside for other work. The same goes for the much wanted Cocoa version. My focus now in on education, my engagement in three university courses and a number of master theses. But not only that. I will also work on a few other things:
My uDevGames submission. I intend to participate in this year's competition. I don't expect to get a very high position, there is only a month left and I will not develop full time or even close to it, but I hope to finish a new game that at least should be playable and a little fun. If I don't end up last, I will be happy.
If I do manage to finish, it willl be the second time this year I enter a game development competition. The previous was the 1PGDmC, the PGD mini challenge, where I ended up at third place with my racing game. I did so with mixed feelings since the ratings from one of the judges was less than encouraging (probably there was some kind of bug surfacing on his Mac but not otherwise) but I did finish my entry and it is playable. That is good enough.
In the meantime, SAT, TransSkel, QDCG and the rest will not more a lot. I did improve my 3D library (most of it not public) quite a bit for the 1PGDmC, and I am using QDCG and TransSkel in the new game (at least for now) which means that some development may go into these too.
110824:
Still not OK... The problem is somewhere else. But I have one more idea of what can be wrong, and I am testing it.
110823:
Let it whip!
That is the title of a funk/disco tune from the early 80's by the Dazz Band. It isn't even one of my favourites (a bit too synth-based) but the title fits today's release. The reason is that I have worked on the process management, which, as anyone using Lightweight IDE seriously knows, has had problems for a long time. Up to now, Lightweight IDE will sooner or later fail to create new processes, so you must quit and re-lauch it to get rolling again. This is irritating. Recently, I got some hints about what to do, I improved the detection of whether a process runs or not, and that didn't help. Then I realized that I assumed that a SIGKILL would always kill a process, and I found that that isn't true!
So I tried again and again, sending several SIGKILL, and it seems to improve things! These experiments showed that I often needed several SIGKILL until it worked! Usually half a dozen would do it, but I have seen higher numbers on rare occasions.
So while older versions of Lightweight IDE only would ask a process to terminate twice, once nicely (using SIGTEM) and once in a sharper tone (SIGKILL), this version will, if needed, bash on the persistant process up to one thousand times! This is hilarious, from whjat I know of SIGKILL once should be enough, and that is why I only tried once before! It also report errors better about it, if you should ever see more than one thousand tries. So it takes out the SIGKILL whip and starts whipping away.
That's why it is the "Let it whip" version.
110821:
New uploads are coming... I added some info pages in order to expand these pages to more than Lightweight IDE, but here is also a new Lightweight IDE coming. I have been working on the process management problems and maybe I can reduce or eliminate them. I really hope so.
110530:
Even more news! The first version of TransSkel for iOS is implemented and working! This is a small subset of the full TransSkel, partially because some of the TransSkel library, like TransEdit, is irrelevant on iPhone, but also because many features are not yet implemented. Still, TransSkel for iOS can do all this right now:
Much is missing, but I would say that the hardest part is past me. The following are planned:
Some of this is really easy, some will require some research to figure out the best method.
The number of iOS demos has been growing steadily the past week, I have several new to upload and some corrected ones.. Now, however, I will depend more and more on TransSkel, to make my code as simple as possible.
110524:
I uploaded a preliminary version of my iPhone installation instructions, now together with the sigcpuscript that I forgot in the Lightweight IDE 0.9.0 archive. (Nobody noticed anyway.) If it helps anyone, nice.
I have also made some important changes to Lightweight IDE and the iPhone demos, bug fixing etc. New uploads will come (sooner if someone wants it). Lightweight IDE will now do codesigning of final builds, so they can be uploaded to an iOS device, it builds more correctly, and the demos have some important bug fixes.
So now it is this nice:
Yes, the classic old Mac demo Skel, now running in the iOS simulator as well as on an iPod Touch, all written in FPC! That and some more. I claim no perfection, not that it is finsihed or debugged or anything, but it runs, it works!
110516:
So now the new version is here. And what is it? Most of it looks the same, but here are the big things:
iPhone support, working, with demos! Well, it isn't quite complete, since there is no codesigning yet, so you can't upload to the device, but it will compile and run in the simulator.
TransSkel has fewer changes, but if everything as good as it seems now, this can be a big step, namely that I have finally tracked down the bugs that prevented me from starting to build the new Cocoa-based Lightweight IDE on TransSkel/TransEdit!
Finally, I included my installation guide for FPC 2.5.1, that is Objective Pascal for OSX as well as iPhone. There are quite a few steps and pitfalls, but I hope I have covered all the ones of interest today. I know that guide will get old quickly but maybe it can help someone. It was written with help from Jonas Maebe and Phil Hess. I know that Jonas asked me to add this information to the ObjP wiki, but... sorry, I just can't. I can't stand wikis. Sorry again.
One more thing: I need help testing! Tell me if it works or not.
110511:
So what am I doing? When will Lightweight IDE for iPhone be uploaded? At least that's what I want you to wish for, as well as new and better IDE and TransSkel.
Well, I have done some progress. Lightweight IDE can now build for iPhone from Objective C as well as Objective Pascal. So what is keeping me?
First of all, I have not yet tested in the device, and I'd like to do that. But also, I have some serious problems with TransSkel that I want to sort out. Recent versions have problems with crashing modal dialogs, and we can't have that. Text editing and document handling was so good until I upgraded to a newer FPC, and now nothing works any more. No, not "nothing" but there are some problems that muist be fixed.
I really want to get going with the Cocoa version of Lightweight IDE. It might become very different from the old version, at least as some experimental GUIs, but that should only end up better. But to do that, I must get TransSkel back on track, make it fully reliable. I could downgrade FPC, but that's hardly the right way to go.
110420:
iPhone/iPad/iOS support... would that be nice? What if I have it all up and running, FPC for iPhone, iPhone support in Lightweight IDE, launching the simulator with the program you develop... What if it looks just like this?
Yes, it is true, an all-different approach to iPhone programming! No Objective C, no Xcode, and examples for nibless development exist and will be included.
And there is more. Lightweight IDE will now automatically switch between three different compilers (in a way four) and that is for FPC alone! If you use CocoaAll, it will use the Objective Pascal compiler (the 2.5.1 compiler), if you use iPhoneAll it will use the iPhone compiler, "build" and "run" will build for the simulator and "final build" will build for the iOS device. Finally, with neither CocoaAll nor iPhoneAll, the default FPC will be used. This auto-switching scheme makes the new double default buttons in 0.8.10 obsolete already.
This is tested with the iArkanoid demo as well as some test programs of my own (like the one shown above).
Futhermore, I have written a complete guide on how to successfully install the iPhone compiler and its interfaces.
So what is not there? A few things:
I have not yet implemented codesigning, which is needed to run on the device. I don't quite understand how it works yet. Before I have that, it will not be possible to do serious development.
I have not implemented any support for building Objective-C for iOS yet. I beleive that will be rather easy, but it is not my primary goal at this time.
There is, of course, a big pile of possible software projects to move to the iPhone, like SAT, TransSkel and QDCG. All would be very nice on the iPhone. SAT is the easiest of these, since hardly uses neither Carbon nor Cocoa. But TransSkel on iPhone would really complete the "all-different" development system, hiding Cocoa Touch altogether just like it hides Cocoa on the Mac.
I have some problems with incorrect sizes on the iPad. The iPhone (in the simulator) is correct every time, but the iPad sometimes is right, sometimes gives a small area in the middle, and sometimes a small area in the corner.
There is even more in my pipeline. I have been writing some code on top of OpenGL with Ryan Joseph, and although I want a QD-like interface and Ryan a CG one, I think that can be pretty nice. Furthermore, I have plans for even more language options in Lightweight IDE... some time. Well, if I feel we need them. On the other hand, I consider ditching Ada and GPC, maybe even Java, simply because nobody use them with Lightweight IDE as far as I know, and therefore they are not updated and may work really badly. They need someone to look after them. I like Ada and GPC but I don't use them myself. Java, I consider a necessary evil... if it is necessary. Maybe it is just evil. It was part of my plan to find funding by supporting languages used in education, but that hasn't worked out anyway.
Back to the fun new stuff! When will I upload it? Fairly soon. I would like to solve the codesigning problem. I have to decide whether this is version 0.8.11 or 0.9.0. I think it is 0.9.0, since the change is so big. It is kind of logical with my overall plan: to let 1.0 be based on the current design, and let that live side-by-side with the Cocoa/TransSkel5-based design, which will be version 2, and is where I want to experiment more with the user interface.
110404:
Big spring upload! Spring-time is here and it is time to grow!
Lightweight IDE has some improvements, especially in the ObjP support. The info.plist produced in the application bundles had some flaws that are now fixed (I hope).
TransSkel has so many changes that they can't be listed here, but the two big parts is better text support in QDCG and synchronizing with the latest Objective Pascal, which I havn't done in a long time. (The old version simply worked so well so I didn't need to!)
110325:
As mentioned below, 0.8.10 is coming soon, as well as an update of TransSkel5, and possibly even an update to TransSkel4. Why update TransSkel4? Because that is the last Carbon version, and I have just made a dylib (shared library) out of it, with C interfaces. The dylib support of Lightweight IDE is an important step, improving cross-language possibilities a lot. I plan to make dylibs out of more packages, like SAT. The C interface and dylib of TransSkel4 was remarkably easy to do. I have tested it with several of the standard demos (MiniSkel, Skel, DialogSkel) and it works just great.
Richard Ward has been testing all my demos in a recent version of the Objective Pascal capable version of FPC. I am still a bit confused about the changes, which are sometimes not as visible for me, but in any event the result will soon be integrated in TransSkel5 and uploaded. I will also be much more strict about specifying Pascal dialect in the source, avoiding unnecessary errors caused by bad defaults.
110322:
0.8.9 is not old, and still 0.8.10 is coming up pretty soon. There are some good things there, in particular support for .dylib libraries and thereby proper mixing of C and FPC code, something that has been particularly painful for a long time. Now it works just fine, and the task of using an FPC library from C is just a matter of writing interface files.
As noted below (110130) I have had to re-evaluate my project a lot. In the past, Lightweight IDE was totally superior to Xcode as an FPC IDE. Xcode didn't even have code navigation or proper error reporting! Now I have to ask myself if it is worth the trouble to work on debugging, code completion etc to catch up. And I ask myself if I should really insist on making my C-using partner use Lightweight IDE, or if he would be better off in Xcode. He is used to CodeWarrior and has a hard time grasping how the main source file can be the project file.
On the other hand, I can imagine the hassle configuring Xcode projects for things that Lightweight IDE either does automatically or can get support for for less work.
Maybe my focus simply has to change. Someone said that you should fight one battle at a time. Should I really try to make Lightweight IDE a good FPC IDE and a good C IDE at the same time? And does it have to be good at big projects, isn't student project a better focus?
I insist that I have the best educational IDE I have ever seen, possibly with the exception of Turbo Pascal. And I will keep insisting for yet some time and try to find its niches.
110112:
I presented Lightweight IDE on a local conference last thursday, but I was a bit disappointed by the lack of interest from teachers. I was, of course, happy about the small audience I had, but the subject of improving teaching should be slightly more interesting for the teachers. Anyway, this is the second academic publication about the project.
Every upload is important, but this one feels particularly important, not only since the list of changes is relatively long. With the release of Detlef Schulz C programming book ("C-Programmierung auf dem Mac") (also here), featuring Lightweight IDE as tool, every improvement of the C support is important. A particularly important change is the ability to check modification dates on header files.
Yesterday, too late for this update, I also added support for building shared libraries from FPC code. This will make it much easier to build C projects using FPC code. For a long time, the only recommendation I had about FPC code in C programs was the "fake main" method, which has severe problems with link errors.
For ObjC users, I ported the "minimal animation demo" to ObjC. Otherwise I don't touch ObjC much, so I depend on user feedback if I will improve ObjC support in the near future. That is even more true for Java, which I personally dislike and avoid. I can improve Java support but only if people interested in Java can help me with the Java technicalities. The same goes for Ada, although I like that language a lot better.
110130:
I have been thinking about future directions, how important each project is etc. Quite often, the world changes around us and we must be aware of it, aware of how our competitive position changes.
TransSkel was, only a year ago, something potentially super hot. An open source cross-platform framework would be something very strong. Today, that has lost much of the punch, after Qt turned Open Source and also no longer C++-only.
The situation for Lightweight IDE has changes several time since I started. I wrote in it Carbon since it was the only feasible way at the time, and Carbon was still a prime citizen at the time. Right after it got fairly complete (for using with FPC) Apple pulled the plug on Carbon. Since then I have had more and more focus on moving to Cocoa. Also, Xcode was worse than worthless for FPC when I started. Now, the FPC kit for Xcode is a lot better, with both acceptable debugging and code navigation (neither of which was in sight in the past). This means that Lightweight IDE isn't as obviously a better choice. Rather, it needs some work on debugging to catch up. However, it still has its distinct niche in being code focused, without confusing project management. I will continue pursuing it as research topic and for its niche. But its role as FPC IDE might be tones down compared to its C/C++ support, where its advatnages are even more obvious.
It is disturbing when you have a good lead and lose it, but it is a natural result for projects with little or no funding. The projects are not dead, not by a long shot, but they do require rethinking and re-evaluating. In the near future, I will make seminars and publications about Lightweight IDE as well as TransSkel, apply for funding and offer diploma thesis project concerning them. And, of course, the Cocoa move will happen.
101223:
I have been silent for a while, but today I decided to make a "Christmas upload", even if it is modest. The big deal is that this should no longer need changes to NSApplication.inc.
Still, the last weeks, I have been back working on Lightweight IDE/TransSkel related things. I have moved a big leap closer to making a Cocoa version of Lightweight IDE, and I have, as part of that process, started making GUI experiments and consider various new things to try. I have been holding back on Lightweight IDE changes for a whole year now, trying to get TransSkel5 mature enough to move the whole project to Cocoa, and we are getting there. I have made a simpler IDE prototype, which only uses a simple interpreter (BASIC, of all languages), but it will still serve well as a base.
So it is not just words, things are happening. At least some things.
101013:
The new TransSkel version isn't changed so much in the code (although there are some significant things), but the big change is the organization. I assume that we are all using fairly new Objective Pascal versions, so my fix for NSApplication is no longer needed.
I want to spend more time on the project now, to get the Cocoa-based Lightweight IDE going, add many new features and start testing interesting GUI variants. However, other things take precedence, as so often. Still, the recent advancements are pretty nice. In particular, I can safely claim that Lightweight IDE has acceptable C++ and ObjC support, not quite matching Xcode in features yet (esp. when using ObjC) but not missing the most vital code navigation any more.
101008:
The latest Lightweight IDE makes only a few changes, but they improve the C++ and ObjC support significantly. C++ navigation was clumsy and there was no support at all for code navigation of ObjC. Now it is pretty OK IMHO.
Another recent development moves us a lot closer to a Cocoa version of Lightweght IDE, which would open the door to a lot more experiments with the GUI, planned additions to evaluate. Those experiments are perfectly doable with Carbon, but Carbon is dead so I really don't want to make any more development with it. With a Cocoa version, any successful experiments produce code that can have a decent longevity. But not only is TransSkel pretty much finished (I can upload b3 any day, which I consider close to final), I have also started working on color coding for the new editor module. From there, I can soon start phasing over code from the old code base to the new.
Also, I am happy about the recent discussions with my diploma thesis student Frida, who tested LWP and gave me some "fresh eye" comments, of the constructive kind. In particular, she pointed out the lack of "recent items". That should be considered. I also very strongly consider some "re-open" feature, which I often feel I need myself. (Additions are mostly put on hold waiting for the Cocoa version but I am still collecting ideas.)
I should really be happy about this, but I feel a bit disoriented for the moment. Should I persist in making TransSkel in FPC or convert the whole thing to ObjC just to reach a bigger audience faster? Linking FPC with C is a tiresome task, and the process is far too unreliable to integrate it in LWP. Should I continue in my ambition to modernize and make my code as elegant as possible or go for a straight Carbon interface in Cocoa?
Well, in any case, we now have a Lightweight IDE that I think has a more acceptable ObjC support. That may be a futile ambition, since Xcode is optimized for ObjC and hard to beat at that, but maybe I can make a niche even there. I still believe in the "lightweight on your mind" concept. I only have to research how it can be implemented in the best possible way to create the perfect beginner/casual programmer tool.
100912:
After accidentally posting to the Pascal list about the sneak peek (which was primarily made for Richard and Vic to see at this point), too much of the discussion was counter-productive and I got irritated by "don't-think-different" comments. I can mail it the file anyone who wants it, but with the nonsense being written about my draft (and nobody seeming to be interested in expanding interesting parts like the ObjC-ObjP porting guide), I spend my time better writing a solid tutorial for TransSkel. Sorry for getting angry but this wasn't amusing.
100911:
Today, TransSkel 5.0b2 got uploaded (with a bunch of improvements and bug fixes), but maybe even more significant is the sneak peek at my Objective Pascal tutorial page. It is just a first draft, so please don't get upset by incomplete sections and debatable or incorrect statements. Instead, suggest improvements. Some sections are just placeholders at this time.
100905:
No news for a few weeks, but that has its reasons. I have been busy updating one of my course books, which is now in print. I have also started up the course in question, my course on advanced game programming techniques, so right now I'd better get back to the next lecture, on bump mapping and high dynamic range.
But I have not completely ignored Lightweight IDE, TransSkel and all that. Lightweight IDE has had its very first academic publication, in the form of a poster at the IHCI conference at Freiburg this summer. A poster paper is a minor one, but still a publication, and I did get some attention from other researchers. Otherwise, LWP is waiting for me to take it on the big leap to TransSkel 5.
TransSkel 5 is where I have done most programming lately. The second beta is imminent, and will feature things like RTF/RTFD support in TransEdit, and most recently I have worked on activation and resizing callbacks, whcih will enable TransEdit to handle menu synching automatically. Finally, I am looking for students who would like to work on TransSkel for Linux or Windows.
So, expect b2 to show up fairly soon. Well, give it a week, that's when my lecturing schedule gets a break.
100723:
"Big summer upload", which means that I have made some progress recently. Lightweight IDE is progressing slowly, simply waiting for TransSkel 5 to move in, but this version is particularly nice. Startup is faster and it never locks up on launch. TransSkel 5 is now officially "beta", since the last planned component, a list management unit, now works and is included. NSStandardFile, which is part of TransSkel, now has support for file type lists and presents very nice sheet-based file dialogs.
Finally, for those of you who want to learn Objective Pascal from simple examples, I also upload a package with Objective Pascal demos that is much bigger than before. It includes menus, toolbars, tables etc. All this code has been developed as experiments when writing TransSkel, but most of it is stand-alone.
100705:
Summar, it is hot, and I spend much time with my family. However, I also do some development. I have a mostly working Cocoa version of Toolbar Manager, making it a lot easier to work with toolbars (even though I don't like them much myself). However, developing with the NSToolbar is weird, even horrible. It is too much hit-and-miss programming, where subtle changes give strange errors. On the positive side, I will be able to upload not only my Toolbar Manager wrapping (similar to the Carbon one, really really easy to use) but also at least two demos, one of them much simpler than Apple's ones.
We all did some handpainted plates recently, and I made this:
I think it came out rather nice. :)
100621:
I have been silent here for a while. That is not for lack of progress, but since I have taken a fairly big leap with TransSkel recently, and now I think it is stable enough to justify another upload.
The big step today is TransEdit, the missing part from old TransSkel and one that is essential for using TransSkel for Lightweight IDE. The only visible thing that is notable is the line numbers in the DumbEdit demo, and that may not seems like much. However, many sources on the net will agree with me; adding line numbers (and thereby also breakpoints etc) is remarkably hard with NS. But now it seems to work well.
Another change is the improved support for sheets (namely in NSStandardFile). Now open/save dialogs can look quite modern.
There are also several interesting but not as important demos. There are demos for using the accelerometer in MacBooks (a.k.a. the SMS, Sudden Motion Sensor), and there are also two new demos showing how to put an OpenGL context in a SkelView.
100609:
Breakthrough in TransSkel opens the door for the Cocoa/NS rewrite of Lightweight IDE!
For many months, I have had one unsolved problem, namely to make a complete editor with certain customizations, namely a breakpoint field that follows the text just as it does in the Carbon version of today. That same field can be used for line numbers and whatever. This was a surprisingly hard problem, and I had to wade through several demos and write many experimental programs until I found something that works and is stable. (This was the problem I mentioned on 100527, below.)
Another, less problematic problem that I have solved recently was to support sheets in save dialogs, and implement that in the StupidEdit demo. Only very small changes were needed to TransSkel to make this elegant.
This means that I can, finally, start moving the Lightweight IDE project from Carbon to NS. I have wanted to do that for almost three years (ever since Apple officially scrapped 64-bit Carbon) and now all the essential tools are in place. And those changes also means that the official, complete TransSkel 5.0 is getting closer. It is hardly an alpha any more. It looks more like a beta.
100530:
Today I uploaded an installer that installs FPC 2.5.1 and the Cocoa interfaces as one single standard installation. If you have had problems getting started with Objective Pascal, this reduces the problem to two simple steps:
Note that Apple's developer tools are a prerequisite. I have tested the installer under OSX 10.5 only, on an Intel Mac.
I am also working on the problem of making a base installation of the developer tools, that is the open sources parts, as a separate installer. I can't redistribute the whole SDKs without Apple's permission, but the open source parts should be no problem, and that would be a smaller download and a single installer for GCC, FPC and the vital components.
100527:
I have been doing teaching and some research work mostly unrelated to the projects here, but also done some work on the Lightweight IDE related topics. Most importantly, I have been tracing town a strange problem that caused my applications to crash on exit. The problem turned out to be the inclusion of some built-in units, interfaces to C libraries, and what bothers me a bit was that I got the crash even when not calling anything, and the problem was the order of the units in the "uses" statement! But it is solved now.
A harder problem is to figure out why my custom NSTextViews crash on pasting in large amounts of data. I have some very nice NSTextView demos running, which will be perfect for replacing the old TXN editor - once they stop crashing!
Finally, I have been drafting some possible reorganizations in Lightweight IDE. I am not sure if it is worthwhile to make Lightweight IDE fully customizable, so you can add support for new languages without recompiling. Face it, Xcode is so horribly complex that it is a big task to add incomplete, awkward and totally insufficient support for a new language. Well, you know that; that's why I got started with LWP in the first place. But by working a bit on the modularity on LWP, I could make it really easy to add support for a new language, with a recompilation. It is not bad at all, but you have to make changes in 3 or 4 separate places, and that could be improved.
Now I will spend some time reading the students' project reports. Some of it will be fun reading, since my students (in computer graphics) have done some very nice projects. I only wish some would consider working with LWP, and with FPC.
100510:
Today I upload the second alpha for Sprite Animation Toolkit 3, with a nice and useful point-in-sprite function. It is likely to be very useful, but I know there is a likely bug, namely when the window is scaled. But I will get to that.
Recently, TransSkel 5 reached its seventh alpha, incluing QDCG version 1.3 with some nice arrow/end cap routines that go way beyond anything CG can do. The new demo for that functionality is quite fun to use. :)
And on top of that, I decided that Lightweight IDE should have a re-open functionality, to remember what files were recently open and give the user the option to re-open them. This is not implemented yet, but it is likely to be fairly soon. It would be a good work-around for the well-known but elusive bug that makes process launching fail sometimes.
The set of projects has grown a bit large. On top of this, I have work and family. I'm not complaining, rather I am quite fond of these projects (Lightweight IDE, TransSkel 5, QDCG and SAT 3). I just worry about the speed of progress. Of course, they have much in common. TransSkel is a foundation for Lightweight IDE, and QDCG is a tool for the same work. Only SAT is relatively separate. So in a way it is two projects, I guess.
I take one thing at a time and try to move on ahead.
100426:
TransSkel 5.0a6 with QDCG 1.2.
The big deal here is that QDCG is given a version number. It had a 1.0 at the last Carbon version, then I updated for Cocoa, no numbers, but after a whole bunch of additions I think it is worth numbering. So 1.2 it is (1.1 is the one in TS5a5).
And this is a pretty big QDCG update! PDF loading, saving and recording! GWorlds! Shadows! The PDF support is the big thing, making it almost a full replacement of PICTs (and some more).
100425:
First alpha release of SAT 3!
This is pretty big to me, Sprite Animation Toolkit is back on-line! It isn't finished, there are several important features left to add (collision detection global phase, scrolling worlds etc) but this should be usable. Anyone who feels like being alpha tester is welcome. As before, it is free as long as I get credited for my work, but now it is also open source! (FPC of course.)
100420:
A minor Lightweight IDE update, but there is a lot more coming. I have done more work on QDCG, and now it is getting close to "full featured". How about PDF loading and creation? Clip regions? There are some design choices to get right, but it all works nicely, so well that I feel I should consider C interfaces too. TransSkel is also moving. I have preliminary code running for lists, toolbars and better text editing. I only have to make the API for them. That, however, is not entirely trivial.
100415:
New upload today, of an updated TransSkel and much more updated QDCG!
I have decided to abandon Carbon in the QDCG code. It will reduce the number of Y flips, and it takes a few already.
And with the new TransSkel, I also release a little game, TransSnake. It is a very basic Snake game, could use better graphics as well as sound, but it works! And it shouldn't be more complex as a TransSkel demo.
100404:
Much work right now, quite a bit at the university, but I have also managed to spend some time on ObjPascal. More specifically, I have been working on text editing. I have been through all possible ways to add a field to the left of the text view, just like LWP has now, and there are so many gotchas and complications... It is even worse than TXN! But on the positive side, I hope that the final resuilt will be a lot better than TXN.
I have also made some other tests, new demos using lists, and a demo for scrolling an arbitrary NSView. The latter is very useful and I think it will be easy to use, especially if you use a SkelView.
Finally, I am now phasing in QDCG as primary drawing API. The API is great, as simple as QD but can do so much more. A few things are still missing, like patterns. On the negative side, I really wish Apple would have made the coordinate systems a bit less messy. CG has Y-up, QD has Y-down, Carbon HIViews has Y-down, and NSViews are a bit of both, and sometimes is such a mess that you really don't know how to avoid getting the text upside-down.
As mentioned below, I should release 0.8.6 soon, but I don't know if anyone is really asking for using GLSL and OpenCL with LWP at this time, except myself, so I take it easy and maybe I'll add something more.
100322:
Two new demos. I made my own version of GlutGears last winter (based on a classic demo) but didn't upload straight away. ToolbarSample is brand new, ported from ObjC, part of my ambition to get a more complete set of functionality through ObjP and eventually TransSkel. What comes next? 0.8.6 will come any time, with improved GLSL and OpenCL support (for color coding and code navigation - compilation is no problem). Maybe new demos too.
100308:
No release at all in february, for good reasons. But now I'm back! With CUDA support! I am particularly proud of the two included CUDA demos, both written by myself: One is the simplest CUDA demo I ever saw, and the other is a real "Hello World" for CUDA, the only I know that deserves the name. There are several simple demos posing as "Hello world" but that are neither minimal nor focused on what "Hello world" should do.
100129:
Lightweight IDE/TransSkel development is slow now, due to much work at the university. Today's upload is a minor one, fixing one bug that could make some C code fail. Source-code uploaded too. I will get back to my FPC projects when I have more time.
091230:
Second alpha of TransSkel 5. This is improved a great deal, with functions for accessing and re-assigning menu items, graphics (through QDCG), and more. I believe this is now getting close to what is needed for full applications. It still needs more text editing features in order to handle line numbers and breakpoints.
091228:
Important! You need a slightly modified NSApplication.inc to make my Cocoa code work. The change is the declaration of setAppleMenu, at the bottom.
A second alpha is coming soon. The window clobber callback now works properly, and I have added menu item lookup functions that makes it easier to work with nib-based menus.
091224:
Christmas special, TransSkel 5.0a1! So what? What is TransSkel?
It is getting future safe the easy way! TransSkel 5 is a NS/Cocoa-based application framework which makes the task of building a GUI application much simpler, without having to learn the complexity of a full OOP framework with all its special rules and, not least, incompatible object models. Unlike Cocoa, it is code-centered, avoiding to hide other functionality than the layout in nib files.
TransSkel is a callback-based framework, which is an intuitive and flexible way to work. The code gets structured in a very natural way, but doesn't force more rules on you than is has to. And as if that wasn't enough, it includes replacements for some missing calls like NewWindow, Standard File and menu building. They are not identical, since backwards compatibility was not the primary goal, but porting should be a lot easier anyway.
Eventually, I hope to make TransSkel cross-platform as well as cross-language. Unlike Cocoa, it can fulfill both these.
So, to summarize in a point list:
Interesting? I think so. A bunch of features are still missing, so if you want to help, there is a list of things that needs solving.
Merry Christmas!
091220:
0.8.2 is uploaded today, which is a rather small change compared to what I have been spending most time on lately. The new feature is that the Target settings include command-line arguments for the target program, when run (not debugged). Big deal? Well, to some. Yes, it was easy to add.
But the big thing is that TransSkel 5 is getting really close to a first public (preliminary) version. That means a procedural, callback-based API that covers quite a bit of NextStep/Cocoa. It greatly simplifies nibless app building as well as supports loading of layouts from nibs. It has a simplified API for handling many controls (menus, buttons, sliders, text boxes, radio buttons, checkboxes, image wells, basically any NSControl) plus custom views. There is also a standard file dialog unit similar to CarbonStandardFile.
Not all is done yet though. The biggest things yet to solve include:
There are several goals here: To get a nice, intuitive and simple API, to ease porting of old TransSkel- or Carbon-based code, cross-platform compatibility (i.e. Linux, MS Windows and Solaris), cross language compatibility (i.e. C). Supporting nibless NS apps is not a major goal but comes for free. I think we get it all just by following the design ideas of the original TransSkel, but extend it into parts that were left to the Mac Toolbox in these days. Paul did it right back then so why do it wrong? TransSkel and FPC is two big right in my view.
While I have developed TransSkel 5, I have also produced a few new independent ObjP demos. You will see them soon. In some cases, I have written a demo both in ObjC, ObjP and TransSkel5, to compare the results. And of course TransSkel 5 comes out the winner. If it doesn't in some way, I know I must redesign something or add some missing feature. And I do.
Everything great? Well, except for one thing: I think the project needs renaming. At least one time too many, I have seen LWP being ignored in discussions as if people just don't notice that it is mentioned. Maybe I am over-reacting on it, and in a way I like the name, its sales pitch ("Lightweight on your mind") and its reference to Lightspeed Pascal, but it seems to me as if the term "lightweight" a bit too often is interpreted as nothing at all.
091011:
The preliminary Ada version has been up for a while. I indended to make a "real" 0.8 by modernizing the file management, but that turned out to be troublesome. We can't move to FSRefs if that means a lot of work and the result has more problems instead of less. So now I turn my eyes towards moving to Cocoa faster. I thought I might polish up the currrent LWP and make that 1.0, and aim for 2.0 as the Cocoa version, but maybe that is not the best plan.
As mentioned below, a Cocoa-based TransSkel prototype already exists. That is made with PasCocoaKit, which is a nice Cocoa layer working with the old FPC. However, PasCocoa(Kit) is a dead end, an intermediary solution that is being rapidly phased out.
Yesterday, I got the new solution, Objective Pascal, running. The demos worked with LWP with very little changes. However, I had to put back some settings that were removed inb the past since they never changed. Those changes now go in an extra "advanced preferences" box, for preferences that are rarely changed.
So if you want to try Objective Pascal, you should:
1) Download and install the new, preliminary FPC with Objective Pascal support: http://www.thealchemistguild.org/objp.php
2) Ask be for the upcoming LWP 0.8.0, with new settings,
3) Set the path to the compilers in the advanced settings.
4) In the demos, move resources to "Main Resources". Rename the MainMenu.nib til main.nib.
That's all. Then the demos compile and run! I am now working on moving the PasCocoaKit TransSkel to Objwective Pascal. From there, I hope the path ahead will get better. So far, the Objective Pascal demos don't have the nice feel that the PasCocoaKit code has, but I hope I can get around the Cocoa coding style and find something better.
090919:
The new release fixes a number of things in the current IDE. No big changes, except if you have problems with any of the shortcomings being fixed.
Several things are in the pipeline:
I have spent some time recently on PasCocoa/PasCocoaKit. This is somewhat tricky, things are changing fast. I have settled on PasCocoaKit for now for its completeness and relative ease of use. In the long run, we will probably move to a new FPC version with built-in Cocoa support, but PCK works quite well and is pretty complete out of the box.
090907:
Currently, I spend my LWP development time into making groundwork for converting the whole thing to Cocoa. This is rather challenging, but I think it can be done. I have some basic demos running and am trying to build the first start to a brand-new variant of TransSkel. And if I do that right, very little of the application code will need rewriting, except the editor.
I will most likely rewrite the file handling code first, before LWP gets Cocoa-based.
090827:
I am busy with course work and similar things, but:
090811:
New demos (game/graphics rlated), yet another 0.7 release, and new and better pictures in "about". That's plenty for one day.
As mentioned below, two major things are ahead. First, rewriting the file handling code. Then, looking into a full or partial move to NextStep/Cocoa, or at least replace the text editor with something better. It sound to me like if 0.8 will be the better file handling and 0.9 will be a better editor.
I also started to think about class browsers again. I presonally prefer to keep my code so straight and tidy that you don't need that kind of extra tools just to manage a poor design (!), but I fear that something like that will be necessary, because so many people learn bad software design these days. Well, disregarding whether complexity and featurisis are bad things or not, the students of today are encouraged to design that way so I might have to adapt - in some way. I ask myself how to make that fit in a tight GUI. Adding a bad class browser (or similar kind of code analyzer) is easy. Making an elegant one is hard. It always is that way. (And unfortunately you don't always get more pay by making it elegant.)
090802:
Third release in theree days, but this time it isn't just bug fixes but some serious news. The custom settings for frameworks and paths can now be put in "all" files, affecting all projects in the same folder (good for those demo folders with many demos), and you can also specify custom options with ".options" files. So "all." and ".options" are the biggest news.
And as if that wasn't enough, I fixed a bug in the editor that affected 10.5 only. Up-arrow seems to behave much better now.
Unless some vital bugs surface, I consider this the final 0.7, and it is time to look at a more significant step to 0.8. There are some needed rewrites, to improve file handling (should be fairly easy), to improve graphics (mostly done), to replace the text editing engine (pretty hard) and to move the GUI to NextStep/Cocoa (should be possible but doesn't look very nice). And there are a bunch of interesting features to add, too (especially those who do not clutter the interface).
090801:
Ooops! Again!
In 0.7.7, a weird bug appeared for no apparent reason, which made "save as" fail miserably. It seems to be fixed in 0.7.8, but the reason still puzzles me. I will continue testing CarbonStandardFile to make sure there are no more lurking problems.
090731:
The summer has passed, and I noticed that I had some bugs fixed that weren't uploaded. Of course, it is all too obvious that I have few C/C++ users so far, otherwise they ought to have reported the bugs. ANyway, they are fixed. The most annoying one was the inability of 0.7.6 to include .a libraries properly.
As a bonus, I also upload a few dew demos that I think are useful.
One more thing: I have found that FPC 2.2.4 doesn't work well on my old Pismo. I had to downgrade to 2.0.4. So if you get strange errors, referring to line numbers way outside the code, and you use 2.2.4 on PPC, then it is not a problem with Lightweight IDE but with FPC 2.2.4.
090625:
Midsummer has passed, and I have been busy with other things than Lightweight IDE for a while. I'll make some notes here to let you know what I think and work with.
My old game library, Sprite Animation Toolkit (SAT) has been successfully revived during the spring, completely rewritten as a library on top of OpenGL and OpenAL. Some demos and one fully working game exists, which means that although it is not exactly finished, it is already useable. It is developed entirely using Lightweight IDE. When I will release it? Well, I guess it will go to interested "early adaptors" first.
What about Lightweight IDE? I have done some work on a formal report, analyzing what I have done and why, debating the merits of minimalism compared to the conventional ways. For future versions, I have the following things considered or planned:
090516:
After some well needed discusssion in the MacPascal list, the idea to make a file list window as next step is strengthened. But the problems in the process management is even more important. And Ryan Joseph's Cocoa-based text view might be a well needed shortcut to a better editor.
090515:
Agony! Am I getting close to finished, or should I rewrite the GUI to Cocoa as next move, or is it so infinitely much left (code folding, documentation search, code completion...) that I should better give up and do something else?
On the positive side, I think Lightweight IDE is pretty unique. So tight GUI, and still it can do so much. I am particularly proud of the smart C/C++/ObjC building capabilities, despite that they are not my own favourite languages. But when I need to use them, they are handled well. (Except for some object parsing that is needed to improve navigation.)
Considering Cocoa, I got Ryan Josephs PasCocoaKit demos to compile and run under Lightweight IDE. That can be a significant step forward. Unfortunately, it is a lot of work just to get into the essentials of Cocoa, so I don't know if I have that time to spend. But for what it is worth, I might be able to include PasCocoa demos real soon now. Tell me if you want help with using PasCocoaKit with LWP.
For the new version today, 0.7.6, the updates are fairly modest. The option to have color coding applied when idle or on newline might be a fun new feature. I am used to color coding on "save" but if it feels cheap, there you are.
I am having some trouble with timeouts. Is that the same for all or is it just my MacBook?
090511:
I've been busy with LWP lately! The new version is the next milestone for C builds, since the auto-framework feature is added, making it more automatic than ever (and with the option to disable it when needed). Alas, I don't see any way to do the same thing for Pascal.
It also has some nice fixes for all users, most noticably that the icons for popup menus are hidden when they don't contain anything.
The next focus in on finding the problems in the process management, ProcessUtils. The problems have become more frequent with recent versions, with timeouts already when checking version numbers, and later process launches that fails, and once it has failed it seems I can't start any at all.
In the longer run, I know that I must look closer into a transition to Cocoa. The PasCocoa project has made much progress, and is surely the right way. To begin with, their demos look a lot nicer than the Objectional-C ones. (Sorry for the pun but it fits so well.) I have kept the GUI strict, and that will pay off twice. It not only gave us a simple-to-use GUI, a good thing in itself, it also makes it fairly easy to rework. At least that's what I hope.
090503:
Version 0.7.3 was not good. The debugger doesn't work well. Also, I have found some problems with some 0.7 additions. With 0.7.4, I hope it will work better. My tests so far are promising.
090428:
New version again, fixing the most obvious bugs of the new features in the previous version, but also has some work on the debugger. The most apparent change is that the function to run beyond the start if there are breakpoints set now seems to work better. It also has better security in some ways (much needed and we need more). The debugger startup "..." is no longer visible, which I think is a pity. I will try to put that back.
Also, this is probably the last version with QuickDraw graphics. I have a nice new unit re-implementing QuickDraw on top of Core Graphics, making it (almost) as easy to use CG as QD.
090423:
I do a big upload today, two versions of Lightweight IDE and complete sources and demos. Two versions? Yes, there are important changes (scrollbar bug for big files fixed) that I want to deliver independently of more experimental changes (custom controls for making the pop-up menus visible for newcomers).
So the situation is this: Updating to 0.7.1 is recommended and will only make things better as far as I can tell (and my test runs show). The big file bug is gone, and nothing seems to have gotten worse in any way. 0.7.2 has a few revisions in the editor, and since the editor is where we work the most that is sensitive. Do you like the new controls? The extra margin to the right? (You most likely like that extra margin.) And is it stable? I have noted some glitches in the controls, but nothing serious. And yes, the white boxes are dull, but the icons I made for them were horrible so they should not be there until they have been made much nicer.
090420:
I tried PasCocoa with Lightweight IDE today, and althought not all demos ran perfectly, it compiles and runs just fine. This should mean that some PasCocoa demos can be added soon. I can't say I am teribly enthusiastic since Cocoa primarily means reworking things that work well already, but it is a comfort to see that FPC as well as Pascal has a brighter future on the Mac now.
090419:
After making the 0.7 upload, I have started spreading the word about Lightweight IDE a little bit more. I know that the looks (icons, colors etc) need polishing, but considerable functionality is in place so it is now technically a pretty good tool. A pretty good tool with a somewhat unfinished look.
This has lead to several opinions and suggestions. Of course not everybody are enthusiastic right away, but I don't worry about that. The exchange of information is the important thing. I have recently added color coding for shell scripts, which effectively makes Lightweight IDE a development system for yet one more language!
Meanwhile, Richard Ward has added even more new functionality in color coding as well as the debugger.
090416:
And now I have uploaded it, version 0.7. The "middle" version number change is mainly due to the new, smarter C builder, but there are also changes in color coding (a new color scheme plus many new symbols being recognised) and in debugging.
This version is not a major change for Pascal users, but for C/C++/ObjC it is a huge step, making the IDE a viable tool for other things than small demos. That means that it is meaningful to find beta testers/contributors among the C/C++/ObjC users! More users, more opinions, more test situations, more demos, more publicity, then this whole work gets a whole lot more meaningful. Maybe we can even get the Linux port started... Oh well, let's not dream too far yet.
090415:
This is a big day for Lightweight IDE! It is a big day because two the really vital improvements have taken off, the second one today and the first just a day or two ago.
The first one is debugger features. Richard Ward has been busy improving the debugger (after some work on the color coder which will also appear soon). Most importantly, the problem of displaying global variables seems to find its solution.
The second problem, solved today, was to make it build C programs as smart as Pascal programs. I do prefer Pascal but I want the IDE to be useful for C/C++/ObjC too. Actually, it was useable before, but only for small projects, since it always recompiled everything. Not any more. :-)
This means that it is time to move up to 0.7. What is then left for 1.0? Well...
That's quite some list, but note that we are moving into luxuary land. :-) Fewer things are absolutely necessary.
090406:
Really long time since the latest update. The IDE itself has few changes, the change back to cmd-R to run without debugger being the most noticable. "Replace all" is also nice, and the bug fixes are important too.
But the biggest news is the "OpenGL" demo folder. During the computer graphics course I run now, which had its lectures mostly in january and february, I was a bit more productive that usual, and created several new OpenGL demos. What you find in the distribution now are some selected demos that I find mature enough to release. Most demos are in C only, but there are also two Pascal demos.
091228:
I step up to 0.6, by adding GPC support. That support is highly preliminary and not tested much, but at least it worked for my limited tests. But even more important is the timeout in some command that were before assumed to return immediately, which saves us from many lockups.
081221:
Merry Christmas, here comes the Christmas release!
Surprise, surprise, there were some problem left. (As if I didn't know.) With 0.5.2, a few more are fixed.
Here are some problems that are not fixed yet, except as noted below:
Still, the 0.5.2 improvements are not too bad. The up-arrow bug is nice to get around, and I hope search/replace will work better now. There has been some particularly elusive bug in the search/replace code, which I now avoid by using the built-in search feature in TXN.
081203:
0.5 is released!
After this major step, which has been the main focus for the project for the last year or so, it is time to look at where to go next. Here are my thoughts on that subject:
It is pretty good, but the Light Bugs window is pretty crude. It needs tidying up, probably with tabs plus some more parsing of the data. Also, editing while debugging makes no sense.
Here are my primary ideas:
It is necessary for using the IDE for larger C/C++ projects, and
This is too easy to ignore. It is mostly a question of changing some compilation options, and parsing the errors with the GCC parser.
Note for 10.5 users: Changing the debug build preferences to -gw (Dwarf debugging info) should be an advantage, and is likely to be default in the future.
081130:
Lightweight IDE 0.5 is now at its first tests outside my house! I just sent a copy to Richard Ward. It is still unpolished in many ways, but you can now:
Notable limitations:
This means that the basic functionality is there! It is still far from 1.0, but I think this can be a big leap forward for LWP, especially for Pascal development.´
081128:
Whoosh, and a whole month went by, again with work that took all available attention.
But now I am back at the debugger development and integration, and it is rolling along well. I made a lot of the integration yesterday. The debugger unit, editor and main unit have most connections established, and new options are added. "Final build" options as well as debugger build options are added. I am getting optimistic. This just might work, and 0.5 is coming up. Real soon now? Well, when it is usable.
081025:
Yet another minor update, but fixing the text encoding was pretty important so it is not quite that minor after all. No more warnings or crashes when you have a non-7-bit-ASCII character in the path.
But this is the last 0.4 version. I have renumbered my local folder "0.5" because now I start the revision to get the debugger in.
081014:
I have been busy the last weekend and following days! Not only have I done good progress on some paid work, but I also made some very significant progress on the debugger prototype! This means that 0.5 leaped a lot closer. The debugger prototyped (hard wired for debugging a single program at this time) can single-step, it can set breakpoints, and inspect local variables. And so far it does not feel particularly slow either!
My biggest concern now is the GUI for the debugger. The prototype is too crude, but I guess a crude debugger GUI is quite enough for its first version.
081009:
Back on track again. Not that I can spend all my time on LWP, but at least I am back in the code. Some bug fixes have been made, and the window placement seems to work.
I also added a link to Ryan Joseph's related project, Pascal Gladiator. The two projects share some code as well as knowledge, and the fact that he makes an IDE that uses project files is only for the better of Lightweigt IDE. That means that nobody must be forced to work with my heavily simplified concept. I am very fond of the project-less situation and the resulting extremely simple user interface, but everybody's need are different.
Pascal Gladiator is what I would call "more coventional", tabbed editor, single-window, with lots of visible controls. Since that is a popular style, I don't in any way claim that Ryan is doing something wrong. I also claim that nothing is wrong with my approach either. All in all, LWP and Pascal Gladiator are very different approaches to the problem, which should mean that a larger number of people will find an IDE that they like.
080904:
Three months since last update here. Yes, I have been busy, very busy. I have written the second part of my computer graphics and game programming coursebooks, and it was a lot of work. That means that I have had to avoid LWP work almost completely for three months! And I can't do much work on it for yet some time. Today, I uploaded 0.4.2 with Saabino D'Elia's latest changes.
I really wish I could spend some time on LWP, and fix that debugger interface (which the last major changes I did were preparing for) but I am overloaded with more or less paid work that I need to do.
080606:
A little big move is done today! I take the step to 0.4.0, which means that things have happened to the editor that opens the door to a lot more (e.g. setting breakpoints!). What I am talking about is significantly better flexibility. As a small start, you will find a line number field and a small left margin. As a bonus, there are also bug fixes, some other new features and new demos.
A more visible new thing in 0.4.0 is the Quick Ref. If you ever longed for a fast tool for looking up functions, like Think Ref, this just might be a first step towards such a tool. It gives you lightning fast searches in FPCMacOSAll.pas, on function names only.
080626:
Today, I release 0.3.13, which should be the last one before 0.4. This is an important release, since it is the first time someone other than myself, namely Saabino D'Elia, have made changes in the code. And they are quite significant. In my opinion, the most important one is the feature to select font, but the color scheme selection is also significant.
So, why will the next be 0.4? The reason can be found in the Demos folder. The demo "Custom TXN" is my first result with the modification to the text editor that will open the door to many important features (like line numbering and breakpoints). And this is not all. Important new things are coming, and in the next version a few of them will roll in.
080613:
Oh, that dreadful ReadLn/termios problem... Today, i tried hacking around it, and I belieae things are better. Not perfect, but better. There is a strange extra CR for input in PPC, which I havn't figured out yet, but that is a minor annoyance comparing to the problems that were fixed. At least, that's what I think.
080530:
I have been sitting with a termios bugfix for a while now, so I release 0.3.11 with that fix. This is very minor for most of you, but if you use terminal input functions it is vital. It feels like about time to move to 0.4 now, after the "bugfix" level went to two digits, but I have my plan for what 0.4 means and stick to it.
Sadly, my tests on PPC shows that we still have a "termios" problem; if I make it "readln friendly" it works just fine on Intel, but then the PPC lockups are back! So it seems 0.3.11 is "Intel only" at this time. Sorry about that.
080514:
Oh, those bugs...
0.3.9 seems a lot better than the 0.3.3 to 0.3.7 range (which should be avoided), but I found some new bugs. In particular, the "uses" pop-up stopped working (which I use all the time), which was due to an error in the revised FindOrOpen function. So by supporting full paths, I accidentally un-supported most others. Now, 0.3.10, it works better. I will not promise that there are no bugs, but it has worked through my tests.
Also, the font handling revision was meaningless until now, when I figured out that the font numbers are only sometimes compatible with the QuickDraw Text call I was using. Now I see Monaco on both Intel and PPC.
080511:
Reluctantly I must admit that the latest versions of Lightweight IDE have serious problems running on PPC, at least under Tiger. I have mostly tested on Intel, where things seem to work very well, but since Richard Ward alerted me of the problem, I first found the font/color bug fixed in 0.3.8, but then I have found even more serious problems. So if you arte working with PPC you may need to back down to something like 0.3.2 for now. (Before the Leopard fix. It must have happened there.)
Later same day:
I have found some kind of fix for the lockups, but I can't say this is necessarily rock-solid. I have tested it a bit and all seems well, so it should help, but let me know if things got worse on Intel Macs.
080509:
Oops! One of these bugs, a simple little mistake in 0.3.7, which made it pretty useless. I hope 0.3.8 will be better. As a bonus, the need for separate Tiger and Leopard versions is eliminated.
080503:
Second release in two days! And this is a pretty significant one!
Yeaterday, Adriaan van Os and I had a discussion about the benefits of supporting makefiles. My biggest concern is to avoid to complicate the IDE by adding new menu items, settings or, worst of all, demand new mandatory operations by the user. It did cost one setting, for save format of text files, but otherwise nothing changed for the user who doesn't need makefiles! This is good! The change is totally transparent for the quick hack usage that LWP is so good at, while anyone who really needs a makefile has that support. Power and simplicity! An open question is whether there should be some kind of mechanism for running make with other targets than default or "run", but that is irrelevant for now.
Let me stress this: makefiles are supported as an option for advanced users, not for the average user. Anyone who doesn't need makefiles (and LWP is mighty good at making makefiles superfluous) can keep skipping them! But with them, LWP might be of interest for users of GPC and GNAT even without any specific support for these compilers. I would like to add that support, but this opens the door with little effort.
080502:
Time for a new version. This time, I include two versions, one for Tiger and one for Leopard. The Leopard version should work on Tiger too, but the Tiger version has better performance. Sabino D'Elia's demos are back, and a bunch of new demos by myself are also added.
080408:
List time! I just felt like making these two lists, so I did.
I may change this list when I think of more, because there are so many reasons. Also read Owen Hartnett's similar list on Pascal Central.
What about C# or D then? Well, first of all, I havn't tried them, but as I understand, they are designed to be C-like and that is a warning sign. On the other hand, I understand that the mind behind C# is the same guy that wrote Turbo Pascal. A sign of decline or hope?
080330:
After two weeks of work, I think I have found a solution. I run a pthread polling the input, which then forwards the data though an extra pipe. I tried many other approaches and finaly I fond one that works. Beware that 0.3.3 might introduce bugs. Thus, I primarilty recommend it for Leopard at this time.
080324:
"Real soon now" is often longer than you want it to be, and that is all too true in this case. I have searched for information and tried everything, but it still does not work. There is a major difference in process communication between Tiger and Leopard, and everyone who has tried making a GUI front-end to a CLI app must experience this, but very little is written about it. I have Googled on dozens of sets of related terms (forkpty, SIGIO, SIGCHLD, ioctl, fcntl...), and although I have found one or two people with similar problems, there are no answers.
Anyway, I have not given up. There is a simple solution somewhere. But if you can help, please contact me. For now, I hope that the Darwin-Dev mailing list can help me. I posted a question there today.
080322:
I have some good results with the process management under Leopard! There are indeed differences, but I think I have nailed down the important differences. I hope to have a fix ready real soon.
080321:
After reports of erratic behavior under Leopard (error messages were not displayed) I have now tested under Leopard, but still see no problems. For now, my guess is that the problem appears when using old FPC versions. As soon as I know more, I will report it.
080308:
Things are happening, and it is soon time for a minor release. Well, semi-major. 0.3.2 will sport a multi-file search feature, an improvement almost big enough to call it 0.4 (but I won't). It will not be perfect in its first version, but it is a big step for the editor. Apart from that, debugger interface and new text engine are long-term plans that have came a bit closer. Also, the startup time, which got quite a big longer in 0.3.0, is now back at its old lightning fast speed.
080303:
No new release for a month, but not for lack of progress. I am working on very important modules, that will make the upcoming 0.4 and/or 0.5 quite significant. The current plan is:
0.4 will include a crude but not totally unworking debugger interface. (This is more or less working already.)
0.5 will sport a revised text editor, opening the doors for just about any feature we have been missing. (I have a draft running.)
0.6 will integrate the two into a debugger interface somewhat along the lines of Think/CodeWarrior.
And then, of course, the path ahead from 0.6 to 1.0 (if I ever get there) is full of bug fixes and other improvements, but I have not made any version plan for those.
080202:
Today, I decided to upload version 0.3.0, with a number of fixed that I have done from time to time during the winter.
Why 0.3.0? Not because I couldn't call it 0.2.10, and not because it is much different (like the 0.1-0.2 step) but since I added support for Java. I doubt that Java will ever be a high priority, but adding this much was a fairly small thing. Pascal is still top priority, with C/C++ coming second, mixing C and Pascal a good third.
During the spring, I will make further improvements, and some time there will be a 0.4, which should be the first version with some kind of debugger. Beyond that, I look into a major revision of the editor, replacing MLTE with WASTE. That's the big things in the plan. There are more things to wich for, like some simpler form of auto-completion, various things that will be possible with a better editor (code folding?) and smarter ways to build (optimized C compilation, adding frameworks based on C #includes, checking for .a when .c is missing and so on). But first things first.
080118:
No updates in some time. I have not dropped the project, not at all, I am using LWP myself all the time, but I have not had time to work on new features. I have written a course book, plus some other work. Some fresh LWP users have been communicating with me lately, which is very good; they remind me of needed improvements and help me plan the work. Expect new updates in february.
071128:
November has not been the best month, but now at least I have released 0.2.9 with some fixes and new demos. I thought I should have a debugger interface ready by now, but the number of problems have piled up and paid work must be done. The debugger problem is not at all impossible, my process management unit is quite good.
The list of things to fix is long (debugger, replace MLTE, more work on smart C builds, smarter multi-language builds, multi-file search, more editor features...) but on the positive side, it still is a fully usable development system, so let's use it and add features now and then. If you want to help me developing it, please let me know.
071020:
I upload version 0.2.7 today. That is a very promising version. As far as testing has shown, it works very well, and is a major improvement for Lightweight IDE as a C/C++/ObjC development system. Pascal users get their share in a smarter "run" command and support for an entire resources folder to be copied into the bundle.
I like it! If we don't find any alarming bugs, I will return to the debugger problem.
071018:
Lightweight IDE has been moving pretty fast the last weeks. 0.2.6 feels very nice for Pascal development, and C/C++/ObjC work for small projects. The first Objective-C demos have been added to the Demos folder. However, I have found a problem with GCC that has to be solved before it is usable for medium-sized projects. For now, C programs must have all source files in the main folder or they will not work. (Lightweiht IDE will find source files that GCC does not find.)
0.2.7 will be uploaded soon. An important new feature is that it now properly tests all source files on "run" before deciding whether to rebuild or not (point three on the list below). This will make quite a difference. It will now be possible to do "run" with more confidence. You will still have to "build" on resource changes, though. A smaller improvement is that the #include menu now seems to work correctly with C code (point 2 below).
071015:
And now I've found a bug that caused much trouble. 0.2.6 seems very nice so far. I am sure I will find more bugs, but this feels like a good leap foward. Of course, there are still many things to do:
Nevertheless, it is becoming more and more powerful, still without losing its simple interface.
071012:
I am fighting bugs, callbacks that disappear mysteriously (causing the spinning wheel to keep spinning after the process has terminated), and crashes. I am not happy with 0.2.5, it will have to be replaced soon.
071010:
No debugger yet, just a few fixes, but I like the new additions. The error window popup menu means that you can skip all warnings and notes, handy when you are still hunting compilation errors. The expansion of the selection is also nice. I always had problems seeing what line I ended up to.
071008:
I am drafting a first try for a debugger interface. I have some progress, but it is not entirely trivial. Debugging in the editor windows seems a bit too tricky, at least for the first attempt. On the other hand, I really want a tight, uncluttered solution. There are also a few old bugs in Lightweight IDE that will need attention, but nothing that renders it useless. The most irritating one is that the process wheeel often stays on when it should stop.
071004:
Version 0.2.3 will be short-lived! It has some stupid bug that nullifies the color coding. It will be fixed ASAP!
071003:
Version 0.2.3, first universal binary, and a few other minor improvements. And working on debugging. I am also studying alternatives to MLTE.
070902:
I got inspired and implemented a hash table for syntax highlighting, which speeds it up a bit, and most of all allows more identifiers with no loss of speed, also making it possible to make it customizable. And now I am working on a better check for the compilation need at "run", using the same code that builds the file list when compiling C code. This will also be the base for multi-file search.
If the date format confuses you, it is YYMMDD, a common format here.
070831:
New version! I didn't really plan to work on Lightweight IDE during august, but I ran across a bug that needed fixing.
070803
I have been away for over a week, and will not do much work on Lightweight IDE during august, since other work needs priority. But in september, I plan to be back to Lightweight IDE, and work on:
070719
Second update in two days. Fixed the menu bug, and the problem that the nib file was not updated, but most importantly I added security checks for strange paths. Some paths could make the IDE crash, like if you have an Ä in the path, but even more importantly, all characters that can trick a command line to navigate to strange places are disallowed. So thereby there should be no risk for loss of data in other places of the disk, even if you use the strangest folder names.
070718
Rollout time! Today I fixed several problems, and after working on a strange editor but I decided to release a PPC only binary (usable on Intel of course, and fully capable of making universal builds).
This is the first "real" release in three months, but that's not because I havn't worked on it, but because there were so many new and heavily revised components.
070716
The Sourceforge name, and thereby the link, is changed.
More news:
070712
Now the fourth and (for this release) final C/C++ strategy added and working. Only some debugging and fixes and it is ready. As noted below, this will be a major upgrade for C/C++ and Pascal alike. C/C++ gets the much needed support for multi-file builds and Pascal gets universal binary support.
070711
Progress has been good lately.
Some debugging and one more build strategy and it is ready for release.
070706
Great news!
New version of Lightweight IDE is coming real soon now! I have been busy porting the framework underlying Lightweight IDE to "modern Carbon", and now it works. Not only that, I have also made a new build procedure for FPC which means that both Pascal and C can build Universal binaries! And I mean with no effort on the user!
So here are the news in a bullet list:
070608
Lightweight IDE has been in development since last autumn. I have almost completely stopped writing about it in the Pascal list, since I get almost no response from there. It is sad to see that the Pascal community doesn't seem to be intertestedin an IDE written in Pascal with Pascal in mind, but that's the way it is.
But I keep developing, for myself and for the few who wants it, widening the scope to give GCC higher priority.
I made much progress in the autumn, but had to stop development during the late months of 2006. In 2007, I have continued, and made releases every month from february and on. The april release was qute good and I use it for all my development now.
One more thing: My trusty old Pismo is getting phased out. Linking OSX code on a G4 is quite slow, while buidling is lightning fast on my MacBook. At last I have a portable Mac that is truly better than the Pismo! I can wholeheartly recommend an Intel Mac as primary platform for compiling your FPC programs.
Currently, I am working on a modernized version of TransSkel. TransSkel is not a "skeleton program", but a very nice application framework. At first look, it may appear that its callback-based architecture is obsolete in the days of Carbon Events... until you realize how much code it saves. So I have made, and am getting close to finished, what will be TransSkel 4, a fully Carbon Event-savy TransSkel that will work well with modern Carbon.
The new TransSkel will primarily be applied to Lightweight IDE itself, removing the time-wasting WNE loop, and making it easier to plug in other modern technologies, and look a bit better.
Once LWP works in its new "dress", three things have top priority:
- Debugger interface
- Smart building of C/C++.
- Universal builds for Pascal programs
The first is necessary to make it a complete IDE, and the other is what will make it something special to C/C++ users. It should eventually also include smooth integration of mixed-language applications. The third point is important for Pascal compilation; for C, it is already solved.