Menu
▾
▴
zoolib-dev — Development list for the ZooLib cross-platform application framework
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(2) |
Feb
(13) |
Mar
(3) |
Apr
(9) |
May
(5) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(6) |
Oct
(2) |
Nov
(3) |
Dec
|
| 2002 |
Jan
(5) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(13) |
Jul
(2) |
Aug
(3) |
Sep
(8) |
Oct
|
Nov
(1) |
Dec
(3) |
| 2003 |
Jan
(13) |
Feb
(9) |
Mar
(4) |
Apr
(5) |
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
(8) |
Dec
(9) |
| 2004 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(3) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
| 2005 |
Jan
|
Feb
(7) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michael D. C. <cra...@go...> - 2002-12-28 23:49:19
|
I have decided that my New Years resolution is that I will finish writing The ZooLib Cookbook. I got a good start on it, but things got kind of crazy in my consulting business. But despite being busy, I really think I should be able to find time to write regularly. If I can write only a chapter a month, I should have a respectable book by the end of the year. I emailed a technical book publisher a while back and asked if they'd be interested in publishing the Cookbook in dead tree format. They were interested, but said that they didn't think ZooLib had a big enough user base that they could expect to sell out a printing (they said they'd need to sell 10,000 books). But I think if I can get the Cookbook complete, it will go a long ways towards popularizing ZooLib, as the usual resistance I meet from people who I propose it to is that it is poorly documented. For that I must accept full responsibility, and I am determined to change that. Yours, Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ cra...@go... Tilting at Windmills for a Better Tomorrow. |
|
From: Michael D. C. <cra...@go...> - 2002-11-19 03:27:15
|
Y'all may be interested to read and comment on "Threads Considered Harmful" at: http://www.kuro5hin.org/story/2002/11/18/22112/860 The author raises some valid points, but I don't agree with him that threads are best avoided. What I think is that threads are a powerful tool that appears deceptively simple. Beginners probably shouldn't try to do threads until they fully understand the consequences of what they are doing. But used well I think threads are a good solution to a lot of problems. I mention state machines in the comment that I have posted so far. It's a lot easier to use threads than state machines. Regards, Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ cra...@go... Tilting at Windmills for a Better Tomorrow. |
|
From: Michael D. C. <cra...@go...> - 2002-09-16 18:41:17
|
A friend of mine I used to work with is interested in building Mac OS X Mach-O executables with ZooLib. He thinks he knows how he can do it himself, but wanted to know whether anyone had done this already? Classic PowerPC as well as Carbon executables that can run on both OS X and back to Mac OS 8.6 use the Code Fragment Manager format. This works on OS X, but actually is a disadvantage because Apple's implementation of CFM on OS X loads the executables with a user program rather than directly with the kernel, so there's a slower startup time. There's probably some other advantages to using Mach-O, but I'm not sure what they all are. Of course using Mach-O means an executable won't work under Mac OS 9, but that's OK for many people these days. Some people could also supply separate builds. Best, Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ cra...@go... Tilting at Windmills for a Better Tomorrow. |
|
From: Michael D. C. <cra...@go...> - 2002-09-16 18:36:26
|
I'll make some Visual C++ 7 projects for the two demo programs and put them into CVS. I'm not sure when I can do this but I'll try to do this withing the next week. But if you can possibly get CodeWarrior, you should, it's a much more ISO-compliant C++ compiler, and has a much more pleasant UI in the IDE. I think Andy or someone got ZooLib to work with Visual C++ 6 but I'm not sure we should really try to support it. Visual C++ 6 has a lot of problems with standards compliance that encourages one to write broken code. Visual C++ 7 is much better than 6 in that way. I think I know now how to get ZooLib to work with Windows gcc, I just need to find the time to spend dealing with it. Stricly speaking, it will be a MingW build, which compiles with gcc but uses the Microsoft libraries that come with Windows. When you compile with the Cygwin DLL, you have to use a Unix API and then your app can't run as a Win32 application (although you can run it on Windows using X11). There is some arcane requirement about how the runtime libraries for g++ need to be built in order to allow one to compile an application that uses Windows COM. COM is needed for the clipboard and drag 'n drop. It's also fairly hardwired into the existing ZooLib Windows platform support - I experimented with removing the COM code just to see if I could make it work, but it was a terrible hatchet job, commenting off the base classes of a bunch of stuff. I've been told that the version of gcc which is distributed at http://www.mingw.org/ has what I need to make COM work. The gcc from http://www.cygwin.com/ includes MingW, but the runtime libraries aren't built the way I need them. I tried to do a custom build once using Cygwin's GCC sources, but I couldn't figure out how to configure it in the build. The thing COM needs is a certain API for C++ virtual function calls. What happens if you don't do the right thing is that the first time you make a virtual call your code jumps to someplace entirely unexpected! I should be able to make it work. Using Cygwin, I've gotten ZooLib as far as displaying a window and drawing some stuff in it, but then it has this crash I could never figure out. I should be able to get it eventually. Best, Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ cra...@go... Tilting at Windmills for a Better Tomorrow. |
|
From: Andrew G. <ag...@em...> - 2002-09-16 17:49:28
|
On 03 Sep 2002 12:31:36 +0200, Martin wrote: > Hi, > > I would really like to use the zoolib framework in some of my apps. But I > couldn't find how to compile apps under windows. And I don't have enough > documentation and/or sample code to write complex applications. > > Hope you can help me, Martin First off, please try checking out the source from CVS -- the ZooLib 0.8.1 source is nearly two years old. Second you'll really need to be using CodeWarrior if you're building on/for windows. Although ZooLib does build with Visual C++ (or at least has in the last year) there are no VC projects or makefiles provided -- perhaps someone else would be able to do so? Some progress has been made by Mike in using cygwin and gcc -- but I think there's an issue with callback thunking that makes it difficult to get windowprocs and other stuff running. As far as docs are concerned, I've been gradually augmenting bits of ZooLib with doxygen tags. I've probably done so for less than 10% thus far. Michael Crawford has put together some other prose docs, but I know we're falling short of having useful docs. Ho hum. I'd love to put together more detailed documentation, but we really need help. I can answer questions, and I can write up bits and pieces, but the process of knitting that into a coherent whole is something I have not had the time for and don't know when I ever will. Perhaps if there are people lurking on the list who have questions they'd like answered they could post them to the list, we can then all answer/discuss, and in the process perhaps generate the raw material for some more formal docs, or get a sense of just where to be able to make a start. ZooLib is 165,000 lines and growing by 20,000 lines a year. There's a lot of territory to cover. Where to start? A+ -- Andrew Green mailto:ag...@em... Electric Magic Co. Vox/Fax: +1 (408) 907 2101 |
|
From: Andrew G. <ag...@em...> - 2002-09-16 17:49:22
|
Zoolib actually got its start for exactly this kind of thing -- I was writing plugins for HyperCard and Director, as well as Mac control panels. In each case the window was created and owned by the host application and events passed to the plugin via some main entry point. This is quite different from the normal application model of polling for events. You'll notice that ZWindow inherits not only from ZMessageLooper but also from ZFakeWindow. You'll further notice that none of the pane classes reference ZWindow -- they only know about ZFakeWindow. ZFakeWindow's API has a number of methods. Some of them *must* be overridden (GetWindowLock, GetWindowOrigin, GetWindowSize, etc etc). If you provide implementations of these methods then any ZSubPane (or descendant) instance will be able to work. The trickiest thing to manage is ensuring that coordinate systems are handled correctly, there is the notion of 'window' coordinates vs coordinates handled by any particular pane. Window coordinates are (0,0) at what the ZFakeWindow and and ZDCCanvas it returns consider to be (0,0). If you look at ZWindoidPane and ZWindoid, the latter which implements the ZOSWindow interface by mapping it on to the ZSubPane/ZFakeWindow interface, you can see how GetOrigin for a particular ZWindoid does not return (0,0) -- it returns the origin of the windoid within the ZWindoidPane mapped to the real window, thus taking in to account any scrolling that may have occurred. Similarly GetWindowVisibleContentRegion, InvalidateWindowRegion etc all operate in the window coordinate system. In the simplest cases there won't be anything to worry about. But if you wanted to put ZooLib panes inside (say) dialog manager user controls then the window origin would have to take account of the user control's location if it were to use a tweaked override of ZDCCanvas_QD to do its drawing. Anyway -- ZFakeWindow provides the API that panes require to be able to do their thing. Injecting events into panes is pretty straightforward, mostly a matter of calling the same methods that ZWindow::DispatchMessage calls. It's late, so this is very cursory, but in summary ZooLib retains the design features I put in place to support use in plugins. It's possible that there are some gotchas, but probably not if you restruct yourself to operating within a single window. If you need to be able to spawn new windows there may be issues in their interation with the hosting environment. It would also be possible to make this work by implementing the ZOSWindow interface, but I'd probably avoid it -- it brings in issues of message queues and so forth that shouldn't be needed. A+ -- Andrew Green mailto:ag...@em... Electric Magic Co. Vox/Fax: +1 (408) 907 2101 |
|
From: Michael D. C. <cra...@go...> - 2002-09-16 00:49:01
|
I've been thinking of writing some custom photoshop plug-ins for my wife, who has been working with Photoshop a lot lately. Sometimes she wants to do something that she can't figure out how to do with Photoshop's existing filters, and I tell her it wouldn't be hard if I wrote a photoshop plugin. It occurred to me that it would be nice to use ZooLib for this, at least for the UI. Also the threading would be cool if we got a multiprocessor machine, which we plan to do at some point. Of course it would make it easy to run the plug-ins on both Mac and Windows. I haven't looked at the photoshop API in a long time, but plug-ins in general do not own the event loop they're running in, the host application gets the even from the OS and then dispatches it to the plug-in. At least that's the way it used to be on the Mac OS, I think in Windows every window has its own thread. So what I'm asking is how hard do you think it would be to make ZooLib work for a photoshop plug-in? I think if I could get it working it would be a popular application for ZooLib. When I first started working with ZooLib I discussed writing a netscape browser plug-in in Zoolib with Andy. He thought it was possible but would require quite a bit of work. Best, Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ cra...@go... Tilting at Windmills for a Better Tomorrow. |
|
From: Martin <iem...@xs...> - 2002-09-15 12:35:29
|
Hi, I would really like to use the zoolib framework in some of my apps. But I couldn't find how to compile apps under windows. And I don't have enough documentation and/or sample code to write complex applications. Hope you can help me, Martin |
|
From: Michael D. C. <cra...@go...> - 2002-09-02 05:29:24
|
I'm going to buy a used Corel Netwinder from a guy I met on the debian-arm mailing list. You can buy them new from http://www.netwinder.net/ Netwinders are these tiny little Linux servers. The older ones like I'm getting and the 2100's they still sell at netwinder.net are based on ARM microprocessors. Mine will be a 275 Mhz StrongARM. I'm getting this specifically so I can learn ARM assembly code. I've been fortunate to get a contract I will start soon doing some embedded programming on an I/O chip that has an onboard ARM microprocessor. I have spent a lot of time in my career debugging C and even some C++ by looking at disassembled machine code (particularly with MacsBug). So what this is all about is that I can do a ZooLib port to gcc/Linux/ARM. I don't think it will be very difficult. I never did get ZooLib to run correctly with Cygwin's gcc on Windows. I could get it to build and even display a window with some widgets but it would always crash. But I think I know what I need to do. I think the gcc that is provided by default with cygwin is built with options that don't support what I need (like OLE) so what I will do is use the gcc distributed by the MingW folks which apparently should work. http://www.mingw.org/ . I'll be giving that a try at some point too. -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ cra...@go... Tilting at Windmills for a Better Tomorrow. |
|
From: Michael D. C. <cra...@go...> - 2002-09-02 05:20:20
|
It seems that sourceforge.net is blocked by China's national firewall. I'm not at all clear why the government of China should care, but I know that Linux developers in mainland China have been finding it difficult to access source code on sourceforge. I do have a mirror of some of ZooLib's stuff at http://www.goingware.com/zoolib/ It's not a complete mirror, for example it doesn't have the CVS code, but I plan to redesign ZooLib's website in some manner and when I do I plan to make it easy for anyone to download a tarball of the website to run their own mirror. There could be some automated way to offer CVS snapshots from mirrors. Andy, for the time being a workaround for this would be to also offer a link at http://www.zoolib.org/ that one can click on if the meta-refresh to the sourceforge site gets blocked. It would also help to slow down the meta refresh to maybe 10 or 15 seconds so people have time to read about their options. Ever Faithful, Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ cra...@go... Tilting at Windmills for a Better Tomorrow. |
|
From: Michael D. C. <cra...@go...> - 2002-08-02 00:12:03
|
I expect to do some work to make sure that Zoolib works on at least x86 before we make the next official release. I've thought some about the filesharing problem. The problem andy refers to is that there is a bug in BeOS R5's SMB (windows file sharing) client that causes GCC builds to break. So you'll find that at least up through 0.8.1, Andy had been maintaining the BeOS support for BeOS R4.5. Or that's what I dimly recall. However, there are a couple other ways to handle this that I've thought of. A straightforward one, but a little obnoxious, is to just FTP a tarball over to a BeOS machine, then FTP it back after making the needed updates. That's what I'll do if I can't find another solution. The other option is to use some other kind of filesharing. I'm not sure, but there may be other filesharing options available now. http://www.bebits.com/ should list them all - I'm specifically thinking of NFS, but there may be others - there are many different fileservice protocols in existence, we just need to find one that allows one to compile on BeOS while serving from linus. A big help would be for someone to try building the code on BeOS using various file protocols, and then post the results to the list as to which protocols or clients work and which don't. I have a Mac which can run BeOS R5. It's an 8500. Unfortunately, the PowerLogix G4 CPU upgrade I put in it won't boot BeOS. I can put the old CPU back in (a 150 Mhz 8500) and will do so if that's what it takes, however what I would like to do is find a CPU upgrade, preferably a G4, which works with BeOS. I have heard Newer Technology CPU cards will work. While Newer is sadly out of business, it is still possible to buy their CPU cards, either as brand-new, never used cards, or working and tested used ones. Some hardware vendors bought out Newer's inventory and are still selling it. Best, Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com cra...@go... Tilting at Windmills for a Better Tomorrow. "I give you this one rule of conduct. Do what you will, but speak out always. Be shunned, be hated, be ridiculed, be scared, be in doubt, but don't be gagged." -- John J. Chapman, "Make a Bonfire of Your Reputations" http://www.goingware.com/reputation/ |
|
From: Paul S. <pa...@st...> - 2002-08-01 13:40:23
|
On Thursday, August 1, 2002, at 02:21 AM, Andrew Green wrote: > > I looked at the Pro 8 headers prior to the release and had anticipated > some problems with the various vector and string implementations that > the new MSL provides, but didn't actually do anything about it. > > A quick workaround that will preserve the semantics ZooLib is = expecting > from the STL -- define _MSL_RAW_ITERATORS in your project's .pch file > (or in zconfig.h for that matter). That will make all iterators be > typedefed pointers, just as they have been up till now. FYI, MetroWerks told me that the best way of handling this would be theTrail.AppendTrail( &*(iDest.begin() + matchUntil), They recommend avoiding _MSL_RAW_ITERATORS except as a quick fix, and=20 politely deprecated my ".base()" workaround. "&*" looks a little strange, but it probably optimizes well. I haven't=20= actually tested this in ZooLib yet but it worked in another project. Thanks for the prebuilt zac. Paul > >> MetroWerks has changed the STL part of MSL (see the release notes for >> the details.) I spent a morning on this one in my company=92s = product >> already this week. >> In ZFileTrail::sTrailFromTo(): >> if (matchUntil < iDest.size()) >> theTrail.AppendTrail((iDest.begin() + = matchUntil).base(), >> iDest.size() - matchUntil); >> >> Adding =93.base()=94 fixes the problem, which seems to involve = getting a >> pointer to data out of an iterator. This shouldn't be necessary and=20= >> the >> |
|
From: Andrew G. <ag...@em...> - 2002-08-01 06:21:23
|
Sorry I was away when this flurry of messages came in -- I was in the UK
and without regular access to the net. However I'm back home now.
I looked at the Pro 8 headers prior to the release and had anticipated
some problems with the various vector and string implementations that
the new MSL provides, but didn't actually do anything about it.
A quick workaround that will preserve the semantics ZooLib is expecting
from the STL -- define _MSL_RAW_ITERATORS in your project's .pch file
(or in zconfig.h for that matter). That will make all iterators be
typedefed pointers, just as they have been up till now.
We do have a problem with this recent change to MSL. In several places
ZooLib has APIs that take a pointer to an entity and a count. This style
of API allows one to use the same entry point to pass no entity at all
(nil pointer, zero count), a single entity (address of that entity,
count of one), or an arbitrary number (address of an entity in an array,
distance to the end of that array). With vector iterators being
typedefed pointers we're able to pass vector contents through the same
API. If vector iterators are real objects then we need an additional API
taking such an iterator, that's easy. But if iterators sometimes are
and sometimes aren't typedefed pointers then we can't simply have this:
void SomeAPI(vector<T>::iterator iStart, size_t iCount);
void SomeAPI(T* iStart, size_t iCount);
because when typeeof(vector<T>::iterator) == typeof(T*) then we've got
two methods with identical signatures.
I think the real solution to this is to look at the problematic entry
points and determine which ones need the full generality and which
don't. The ones that always take vector iterators can just take vector
iterators. The ones that allow for pointers or iterators can be split
into two entry points thus:
void SomeAPI(size_t iCount, vector<T>::iterator iStart);
void SomeAPI(T* iStart, size_t iCount);
or
void SomeAPI(vector<T>::iterator iStart, size_t iCount);
void SomeAPI_Pointer(T* iStart, size_t iCount);
creating distinct signatures regardless of how vector iterators are
defined.
Note that this same issue applies to places which use strings -- and I
think there are a lot of them and it's been a real boon to be able to
treat string iterators and char*s interchangeably.
With regard to the CW SDK plugin API.
For the moment you might just download zac.hqx (binhexed binary) I put
in CVS (zoolib/tools/zac/zac-build-cw) earlier in July.
Slightly longer term, I need to put together the mac file implementation
that uses the FileRef-based APIs -- it's been on my list to do for a
while, but it hasn't been a high priority in my own work -- and then
we'll be able to convert between the revised CWFileSpec and ZFileSpec
properly.
A+
On 01 Jul 2002 07:46:15 +0200, Conrad Weyns wrote:
> Hi all,
> Installed my new CW v8 some days ago and in the process of updating projects.
> Just finished making changes to Whisper2 and thought I'd give zoolib a go.
> Working on zac right now.
>
> >The current projects (I've only gotten as far as zac so far) won't
> >compile as CVS-ed.
> >
> >MetroWerks has changed the STL part of MSL (see the release notes for
> >the details.) I spent a morning on this one in my company's product
> >already this week.
> >In ZFileTrail::sTrailFromTo():
> > if (matchUntil < iDest.size())
> > theTrail.AppendTrail((iDest.begin() + matchUntil).base(),
> >iDest.size() - matchUntil);
> >
> >Adding ".base()" fixes the problem, which seems to involve getting a
> >pointer to data out of an iterator. This shouldn't be necessary and the
>
> AppendTrail requires a const string* as its first param.
> iDest is const vector of string, compiler seems happy with:
>
> theTrail.AppendTrail(&(*(iDest.begin() + matchUntil)), iDest.size() -
> matchUntil);
>
> Alternatively, I try writing several lines when in doubt/trouble:
>
> vector<string>::const_iterator it = iDest.begin();
> it += matchUntil;
> string tmp(*it);
> theTrail.AppendTrail(&tmp, iDest.size() - matchUntil);
>
> (Actually, I am surprised this worked pre v8. Is there supposed to be an
> implicit conversion from a vector<string>::iterator to the string*, I
> would have thought that to be a reference only, but then I have to admit,
> the stl often baffles me, and particularly std::vector seems to have many
> different faces across stl implementations)
>
> >Pro8 also seems to have tightened the rules about implicit casting (saw
> >this at work too.)
> >Two errors are in ZASCompilerCW.cpp:
> >static ZFileSpec sFromCWFileSpec(const CWFileSpec& inSpec)
> >and
> >static CWFileSpec sFromZFileSpec(const ZFileSpec& inSpec)
> >Involve casting between ZFileLoc, CWFileSpec, and ZFileLoc_Mac_FSSpec.
>
> The Plug-In SDK has changed in CW v8. It seems to turn on the use of long
> file names now - allways. (Do a diff between the CWPlugins.h files of v7
> and v8)
> Casting is not possible anylonger between a CWFileSpec and an FSSpec when
> CWPLUGIN_LONG_FILENAME_SUPPORT is turned on, see CWPlugins.h:
>
> #if CWPLUGIN_LONG_FILENAME_SUPPORT
>
> #define CWPLUGIN_FILENAME_LEN 256
> typedef struct CWFileSpec
> {
> FSRef parentDirRef; /* parent directory */
> HFSUniStr255 filename; /* unicode file name */
> } CWFileSpec;
>
> typedef char CWFileName[CWPLUGIN_FILENAME_LEN];
>
> #else
>
> #define CWPLUGIN_FILENAME_LEN 32
> typedef FSSpec CWFileSpec;
> typedef char CWFileName[CWPLUGIN_FILENAME_LEN];
>
> #endif
>
> Pre v8, CWFileSpec was typedefed to differ between Win and Mac only, now
> it allso caters for OS X where an FSSpec doesn't even come into it any more!
> Zoolib will have to change. If you are using an old zac with cw v8, this
> may be why you get an unknown error.
> I'll give this some thought.
>
> nb: none of my projects that make moderate use of templates and the stl
> made it through this upgrade without changes - so, once again, I have had
> to adjust my understanding of the language....
>
> Cheers,
> Conrad Weyns.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ZooLib-dev mailing list
> Zoo...@li...
> https://lists.sourceforge.net/lists/listinfo/zoolib-dev
--
Andrew Green mailto:ag...@em...
Electric Magic Co. Vox/Fax: +1 (408) 907 2101
|
|
From: Andrew G. <ag...@em...> - 2002-07-13 10:50:30
|
We've had reports of assertions tripping in ZAssetRep_Std_XX when used under load. First some background on ZRef and ZRefCountedWithFinalization. ZRef is a template, and thus must be parameterized by some type. An instance holds a pointer to an object of that type. Currently the type is always a subclass of either ZRefCounted or ZRefCountedWithFinalization. However, any class that has implementations of the static methods sIncRefCount, sDecRefCount, sCheckAccessRef, sCheckAccess and sCheckAccessEnabled can be used as the type parameter to a ZRef. [Ultimately, or sooner, I plan to allow for ZRef-ing of arbitrary types, eg CTabHandle, through the use of traits templates.] When a ZRef<X> is constructed, copy-constructed, destroyed or assigned the refcounts on the object or objects involved are manipulated appropriately. So the key methods for our purposes are sIncReCount and sDecRefCount. For ZRefCounted-derived classes, sIncReCount and sDecRefCount call ZThread_SafeInc and ZThread_SafeDecAndTest respectively. Those methods are themselves defined in terms of ZAtomic_XX on platforms/runtime environments where preemption may occur, and expand to simple ++ and -- operators otherwise (classic MacOS basically). If sDecRefCount's call of ZThread_SafeDecAndTest returns true this indicates that the refcount has hit zero and so the pointed-to object is deleted. For ZRefCountedWithFinalization-derived classes, sIncReCount and sDecRefCount are a little trickier because they have to do slightly more than just atomically increment/decrement a count. On non-preemptive platforms they can just use regular arithmetic operations. On preemptive platforms they acquire a static mutex. For sIncRefCount if the resulting refcount is 1 (one) then the pointed-to object's virtual Initialize method is called. The increment is protected by the static mutex, but the call to Initialize is not. For sDecRefCount if the resulting refcount is zero then it is changed back to one (hence the need for the mutex, there's no equivalent atomic-op) and the object's virtual Finalize method is called -- again the call is not protected by the mutex, just the funky subtract-one-if-not-already-one-and-return-true-if-it-was-one operation. You'll note that the result is that the object now has a refcount of one but we *know* that there are no extant ZRef's to it. There may however be pointer(s) to the object, and in fact this is the crux. If some other entity keeps pointers to objects that are ZRefCountedWithFinalization descendants we have a way to cleanly find out when the last ZRef to each of those objects goes away and can take an action other than simple deletion when that occurs. We use this technique in ZBTreeNodeSpace to cache nodes. Because the now non-ZRefed object has a refcount of one, any other thread that might somehow acquire a ZRef to it (in the example I'm using by calling ZDBTreeNodeSpace to get a node) will take the refcount from one to two -- it thus will not call the object's initialize method. And that's fine, because we haven't actually finished finalizing it. If the fetch of such an object (potentially taking the refcount from one to two) does so under the protection of some shared mutex, and if the Finalize method of an object acquires the same shared mutex, then checking GetRefCount's result against one tells us if some other thread ducked in front of us and effectively revived the object. So the finalization action should acquire this shared mutex, and only if the refcount is one should the finalization action(s) occur (in our example move it off the in-use nodes list and on to the recently-used nodes list). Hopefully that all makes sense. What's happening with ZAssetRep_Std_Data_XX and ZAssetRep_Std_Union? Well there are several situations, but they all boil down to the fact that the asset reps are all created when the ZAssetTree is first opened -- the parse of the asset tree's table of contents builds a tree of ZAssetReps, and that tree is what is walked to locate an asset given some path. We don't actually load the data for the assets -- the idea is that we only keep in memory data that's actually in use. You'll remember that ZAssetTree itself is derived from ZRefCountedWithFinalization, but that you as the user do not need to keep a ZRef to it. Simply having a ZAsset (containing a ZRef<ZAssetRep>) will keep the asset tree loaded. When the last asset from the tree goes out of scope the tree itself is unloaded (un-mmaping it, or releasing it's file or streamer depending on its implementation). So a ZAssetRep with a greater-than-zero refcount must have a ZRef to its asset tree, but a ZAssetRep with a zero refcount must not. This is where the Initialize/Finalize stuff comes in. When a ZAssetRep's refcount goes from zero to one it assigns the pointer to its asset tree that it was constructed with to its field fRef_AssetTree (of type ZRef<ZAssetTree>). When a ZAssetRep's refcount goes from one to zero it un-assigns its fRef_AssetTree field, thus taking the refcount on the asset tree down by one. Additionally some ZAssetRep derivatives have additional data that they need to keep loaded whilst they're in use, but should unload when they're no longer being referenced. A ZAssetRep that's had its GetData method called may have loaded its data from an underlying file or stream -- so long as the rep is in use that data should stick around, so that callers of GetData can rely on the data staying in the same place. (ZAssetReps that come from trees that are memory-mapped of course don't need to do this). A ZAssetRep that is a union when asked for a child must walk the list of asset reps that it references and build an overlay asset rep. It's relatively costly to do this resolution, so it does it the first time it needs to and then holds on to the result. As you can see, asset reps may need to take several steps when they're Initialized or Finalized (when their refcount goes from zero to one, or from one to zero). And those steps need to be atomic with respect to another potential Initialization/Finalization on the same object that may be happening in another thread, or atomic with respect to the fetch of data or resolution of unioned assets. That atomicity is provided by the ZMutex returned by the asset's asset tree's GetMutex method. The ZRefCountedWithFinalization sIncRefCount and sDecRefCount methods provide the basic mechanism for ensuring that a single object can transfer protection of its lifetime from the refcount value to some arbitrary protection mechanism, without requiring that that mechanism be a mutex accessible to ZRef itself. There does need to be a mechanism visible to the refcounted objects themselves, and that mechanism must be shared by all refcounted objects that participate in the same scheme of overall ownership The key here is that anytime a pointer to such an object is converted to a ZRef to that object there is the potential that it's being taken from a refcount of zero to one and *that* occurrence must be protected by the same mechanism that the protects finalization of the object. And that's what's *not* happening in ZAssetRep_Std currently. The shared mutex is acquired in Finalize, which is okay, but it is also being acquired in Initialize, which is not correct. The mutex needs to be acquired by the code that is doing the pointer-->ZRef assignment before the assigment actually happens. I'll be checking in new code that does this shortly -- hopefuly in time for use on Monday. A -- Andrew Green mailto:ag...@em... Electric Magic Co. Vox/Fax: +1 (408) 907 2101 |
|
From: Conrad W. <we...@on...> - 2002-07-01 05:44:57
|
Hi all,
Installed my new CW v8 some days ago and in the process of updating projects.
Just finished making changes to Whisper2 and thought I'd give zoolib a go.
Working on zac right now.
>The current projects (I've only gotten as far as zac so far) won't
>compile as CVS-ed.
>
>MetroWerks has changed the STL part of MSL (see the release notes for
>the details.) I spent a morning on this one in my company's product
>already this week.
>In ZFileTrail::sTrailFromTo():
> if (matchUntil < iDest.size())
> theTrail.AppendTrail((iDest.begin() + matchUntil).base(),
>iDest.size() - matchUntil);
>
>Adding ".base()" fixes the problem, which seems to involve getting a
>pointer to data out of an iterator. This shouldn't be necessary and the
AppendTrail requires a const string* as its first param.
iDest is const vector of string, compiler seems happy with:
theTrail.AppendTrail(&(*(iDest.begin() + matchUntil)), iDest.size() -
matchUntil);
Alternatively, I try writing several lines when in doubt/trouble:
vector<string>::const_iterator it = iDest.begin();
it += matchUntil;
string tmp(*it);
theTrail.AppendTrail(&tmp, iDest.size() - matchUntil);
(Actually, I am surprised this worked pre v8. Is there supposed to be an
implicit conversion from a vector<string>::iterator to the string*, I
would have thought that to be a reference only, but then I have to admit,
the stl often baffles me, and particularly std::vector seems to have many
different faces across stl implementations)
>Pro8 also seems to have tightened the rules about implicit casting (saw
>this at work too.)
>Two errors are in ZASCompilerCW.cpp:
>static ZFileSpec sFromCWFileSpec(const CWFileSpec& inSpec)
>and
>static CWFileSpec sFromZFileSpec(const ZFileSpec& inSpec)
>Involve casting between ZFileLoc, CWFileSpec, and ZFileLoc_Mac_FSSpec.
The Plug-In SDK has changed in CW v8. It seems to turn on the use of long
file names now - allways. (Do a diff between the CWPlugins.h files of v7
and v8)
Casting is not possible anylonger between a CWFileSpec and an FSSpec when
CWPLUGIN_LONG_FILENAME_SUPPORT is turned on, see CWPlugins.h:
#if CWPLUGIN_LONG_FILENAME_SUPPORT
#define CWPLUGIN_FILENAME_LEN 256
typedef struct CWFileSpec
{
FSRef parentDirRef; /* parent directory */
HFSUniStr255 filename; /* unicode file name */
} CWFileSpec;
typedef char CWFileName[CWPLUGIN_FILENAME_LEN];
#else
#define CWPLUGIN_FILENAME_LEN 32
typedef FSSpec CWFileSpec;
typedef char CWFileName[CWPLUGIN_FILENAME_LEN];
#endif
Pre v8, CWFileSpec was typedefed to differ between Win and Mac only, now
it allso caters for OS X where an FSSpec doesn't even come into it any more!
Zoolib will have to change. If you are using an old zac with cw v8, this
may be why you get an unknown error.
I'll give this some thought.
nb: none of my projects that make moderate use of templates and the stl
made it through this upgrade without changes - so, once again, I have had
to adjust my understanding of the language....
Cheers,
Conrad Weyns.
|
|
From: Paul S. <pau...@mi...> - 2002-06-27 00:23:58
|
> MetroWerks has changed the STL part of MSL (see the release notes for > the details.) I spent a morning on this one in my company's product > already this week. MetroWerks is working on this and their engineer promised to get back to me. Meanwhile, the .base() fix will get things working if anyone needs to. I got ButtonMessage to build and run! I had to heavily modify the Carbon target (libraries, several missing files, etc.) PainterTest went much easier, but I can't get zac to work (I'm getting "unknown error" when it tries to run) so I can't actually run it. I'm planning to switch over to OS9 and try it there, or on a Win box. I should have said that I'm mainly interested in Carbon + Windows (I need OS X, can't quite justify the cost of Qt with no OS 9 support.) CPLAT makes me nervous in that its RAD tool is still unusably buggy 3 years after it was first released. What exactly is missing in ZooLib on Carbon? Paul |
|
From: Paul S. <pa...@st...> - 2002-06-25 01:19:24
|
I recall someone saying they were getting Pro 8 soon.... The current projects (I've only gotten as far as zac so far) won't compile as CVS-ed. MetroWerks has changed the STL part of MSL (see the release notes for the details.) I spent a morning on this one in my company's product already this week. In ZFileTrail::sTrailFromTo(): if (matchUntil < iDest.size()) theTrail.AppendTrail((iDest.begin() + matchUntil).base(), iDest.size() - matchUntil); Adding ".base()" fixes the problem, which seems to involve getting a pointer to data out of an iterator. This shouldn't be necessary and the reason isn't obvious from the MSL source. I 'm working on a bug report for this one: I'm no STL expert and I'd rather theirs figured it out. My fix may affect CW7 and earlier (haven't tried it.) #defining _MSL_RAW_ITERATORS to disable the change also works but requires recompiling MSL. Pro8 also seems to have tightened the rules about implicit casting (saw this at work too.) Two errors are in ZASCompilerCW.cpp: static ZFileSpec sFromCWFileSpec(const CWFileSpec& inSpec) and static CWFileSpec sFromZFileSpec(const ZFileSpec& inSpec) Involve casting between ZFileLoc, CWFileSpec, and ZFileLoc_Mac_FSSpec. Still playing with this (don't have the classes completely figured out yet.) If I can get this going I'm going to try building the examples tonight. Stand by. Paul |
|
From: Michael D. C. <cra...@go...> - 2002-06-18 22:42:33
|
Friends, The ZooLib website (http://zoolib.sourceforge.net/) has always been quite spartan. One reason for this is that I wrote the original site in something of a hurry, using handcoded HTML. Also at the time I didn't really know how to do much fancy markup. I also wanted the website to download quickly and work well with text-only browsers like Lynx, but I don't think it's necessary to be as plain as it is. I think it would help ZooLib's acceptance if we had a more attractive website. I think that a good time to post a new website would be when we announce the upcoming release. I'm happy to do the work of creating it, but I'm not all that imaginative a web designer. What I am asking of you is to give me ideas for how our new website should look. You can email me descriptions of proposed pages, send me sample HTML, or send the URL's of web pages that you think I should draw inspiration from. You could also write up information for me to post on the site. I've always wanted ZooLib to have a logo. I just asked my wife, an artist, to design us a logo, and she agreed to give it a try. Bonita's not a graphic artist though, and neither of us has a clear idea of what a logo might look like. It would be OK to just have the word "ZooLib" in some interesting font. Maybe we could get a mascot. Of course it would be natural to have a bunch of zoo animals. Maybe we should incorporate the word "C++" in it somehow. One logo idea that did come to mind would probably be a bad idea - I was imagining a graphic showing the logos for all the different platforms being stuffed into a blender or meat grinder! Unfortunately any company which has a trademarked logo also has strict requirements for how it is to be presented, and some logos (like the Windows compatibility logos) require expensive compliance testing before one can get permission to use them. Of course since we are cross-platform developers it is important that the website be completely interoperable, and even look attractive, in all the browsers. One way to ensure this is to write "valid HTML" - that is, HTML which is completely compliant with the W3 Consortium HTML file format specifications. One must write valid HTML in order for it to work with web browsers for visually impaired users. You can test a web page for validity by submitting its URL to the W3C validator: http://validator.w3.org/ (There is also a page there where you can upload HTML files from your hard drive for validation.) Unfortunately, most of the WYSIWYG HTML editors do not produce valid HTML, as they concentrate on having fancy layout and appearance capabilities and often produce really strange markup that's designed to work around bugs in different browsers. I'm a big fan of handcoded HTML. I would also like to continue supporting terminal-based (text-only) browsers. That means we should not format columns with tables, and should avoid frames. In general it's a bad idea to use frames on web pages because users can't bookmark a frame. Using tables that aren't too big is generally OK with current text browsers I think. I'd like to continue having a fast downloading website. We shouldn't rely heavily on graphics except maybe for screenshots of sample ZooLib applications (this is also important for text browsers). It is reasonable to use small graphics for things like navigation buttons, and other objects with such a straightforward purpose that we can write sensible ALT attributes for them. I'm starting to become a fan of Cascading Stylesheets. Doing all your decoration with CSS helps a site work well with text browsers. Unfortunately, old versions of Netscape don't work too well with CSS, but with the recent release of Mozilla 1.0, and the Mozilla-based Netscape 6 having been available for a while I think it is reasonable to design a site with CSS nowadays. In order to avoid link rot, it's important that all of the existing web pages continue to exist at their original URLs with at least some meaningful content in them (it would be OK to move some of the content to new pages). There are likely a number of other web pages around that link to pages within ZooLib's site, as well as people out there who have some of our pages bookmarked, and its important all those links continue to work. It would also be helpful if the website were coded in such a way as to make it really easy to create mirror sites (maybe by running the HTML through a filter). Sometimes sourceforge has problems, and mirrors can keep our site available to users. I have a kind of mirror at http://www.goingware.com/zoolib/ but it's not complete. A mirror would have to link to both local and sourceforge's file downloads. It would be really cool if complete mirrors were available as download tarballs. Here are some websites that give some really sound advice on writing really attractive, usable and interoperable websites (some of these have good advice for GUI application interface design too): http://useit.com/ Jakob Nielsen's Website http://www.jnd.org/ Don Norman - author of The Psychology of Everyday Things http://www.asktog.com/tog.html Tog was the founder of Apple's Human Interface Group http://nngroup.com/ The Nielsen Norman Group - their design consulting firm I have an article that discusses how to use validators, as well as stress-test web server applications, at http://linuxquality.sunsite.dk/articles/ Here are the websites for some of our competition - other cross-platform application frameworks. Some of these sites are very good: http://www.gtk.org/ The GIMP Toolkit (GTK+ isn't just for Linux anymore) http://www.mozilla.org/ Mozilla isn't just a web browser, it's a very featureful C++ cross-platform application framework, and there are a number of other applications. http://www.abisource.com/ AbiWord is also built on a cross-platform framework, although as far as I know, no one has built any other applications with it. http://www.wxwindows.org/ wxWindows - this seems to be the most popular toolkit for Linux/Windows crossplatform development. http://www.trolltech.com/ Trolltech, the publishers of the QT library. Linux' KDE desktop is based on QT - the Unix version of QT is Free Software, but proprietary versions of QT are available for other platforms. http://java.sun.com/ The 800 pound gorilla of cross-platform devevelopment. http://www.halcyon.com/www3/jesjones/Whisper/Home.html Whisper, a Mac/Win C++ framework. It has a pretty spartan website too, but Whisper itself is very well done. http://www.cs.wustl.edu/~schmidt/ACE.html The ADAPTIVE Communications Environment, for cross-platform networking http://www.boost.org/ The Boost C++ Libraries. Boost isn't a cross-platform framework, but a set of libraries for a variety of purposes that are highly portable across compilers and platforms. There are a number of other application frameworks available, some are cross-platform but some run only on a single platform. Some are open source, some not. A pretty complete list can be found at: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html Finally, my personal favorite for website design. It is suprisingly simple and attractive: http://advogato.org/ Thank you for your thoughts on this. Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ cra...@go... Tilting at Windmills for a Better Tomorrow. |
|
From: Michael D. C. <cra...@go...> - 2002-06-18 21:18:39
|
Someone just pointed out that the website had conflicting information about whether or not ZooLib was available in SourceForge CVS. It wasn't for a long time, but has been now for at least a couple months. The instructions for accessing it are here: http://zoolib.sourceforge.net/doc/cvs.html However, I previously neglected to update the other parts of the website where I said CVS wasn't available. I've fixed that now. Sorry for taking so long. I think I fixed each of the places it was needed, but if you find another let me know the URL. You can get the very latest source code via anonymous CVS. The ZooLib developers are now submitting their updates to sourceforge's archive, rather than the private server where ZooLib was stored before its open source release. It's been a long time since ZooLib was last released. A tremendous amount of really good work has been done on ZooLib since the 0.8.1 version was posted. I'd like to recommend that you use the version of the source that is in CVS, it's in pretty good shape. There are some build problems with the demos, but I'm going to try to fix those soon. Note that there are some source code incompatibilities between the current code and the 0.8.1 release. Among these are a brand new resource file format called ZAsset. You will need to rewrite your resource file sources into the ZAsset syntax and use the new ZAsset Compiler to build them. The compiler is available as a CodeWarrior plug-in and I think also as a command-line program. I'm not real sure when we'll roll a new release, but it won't be too long. Neither Andy and I are able to prepare for it right at the moment, but hopefully after we each get home from our travels we'll be able to post a release. Regards, Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com/ cra...@go... Tilting at Windmills for a Better Tomorrow. |
|
From: Michael D. C. <cra...@go...> - 2002-06-18 19:28:35
|
Hi Everyone, I saw a note where someone expressed hope that I would be able to help. I can probably answer some questions, but it's going to be a little while before I can do much of substance. I am away from home visiting relatives in Newfoundland for a month, and while I have two laptops with me (a Compaq and an iBook), I didn't get a chance to put CodeWarrior on my iBook before I left and I don't think I have the installation CD with me. I have CodeWarrior for Windows on my Compaq though, and I also have Linux on the Compaq. Unfortunately Andy Green is also traveling, visiting relatives in England (where he's from). He has development machines with him, but he also has other work to do for Learning in Motion, and may not have the time to help out with ZooLib until he gets home. I'm not sure if he has regular email access. (I do at least). If I get a chance to tinker more with ZooLib during my trip, I will likely devote my time to writing more of The ZooLib Cookbook (http://www.goingware.com/zoolib/cookbook/ ) or writing more demo code. I will try to help make sure all the demos build and run cleanly on all the platforms using current CVS code. Unfortunately things are going to be even more hectic for me than usual for at least another month because of my day job. While I'm on a trip, I was only able to take time off during the drive up here from Maine. Someone mentioned that it wasn't clear whether ZooLib was available in CVS yet. In fact it has been for a couple months, and so much work has been done on it that I would recommend anyone wanting to use ZooLib fetch it from CVS. When a little more doc and demo programs are written, and a few kinks worked out of the source in CVS (like ensuring that it builds right everywhere) we are going to roll up a new release. There are probably small hitches with the code in CVS at this point, but in general it is so much better than the 0.8.1 release that I think you're best off using it. You can find out how to access CVS at: http://zoolib.sourceforge.net/doc/cvs.html I realize there are some pages at the website that still say it's not available via CVS yet. I'll go fix those right now. Sorry for not doing that before. I'm always in too much of a rush. Tell your children not to grow up to be consultants! Best, Mike cra...@go... http://www.goingware.com/ Tilting at Windmills for a Better Tomorrow. |
|
From: Conrad W. <we...@on...> - 2002-06-18 16:55:08
|
Ok Dario, here comes: I actually found my CW Pro 7 SDK in the Reference directory. I moved the whole shablong called (CodeWarrior SDK) - yes parantheses are part of it - into the Metrowerks CodeWarrior root directory because that's where the zoolib zac project expects it. I build the zac carbon target. Got lots of warnings which I neglected. It build a "ZooLib Asset Compiler-carb" straight in the correct plug--in directory but you need to restart CodeWarrior for it to be recognized (bummer). Now I build the carbon Paintertest project without problems. You should see a console output when the zac compiler kicks inn: Generated ZooLib asset object file: "Geni:Develop Tools:Zoolib CVS:zoolib:samples:paintertest:painte rtest_build_cw::NPainterStd_Assets_en.zao" Generated ZooLib asset object file: "Geni:Develop Tools:Zoolib CVS:zoolib:samples:paintertest:painte rtest_build_cw::PainterTest_Assets_en.zao" I got a series of link warning but just neglect them. The carbon paiter test app runs fine - nice actually. NB: I build this on a 260 MHz G3 runnning 9.2.2. I have a 500 MHz iBook running 10.1.5 but to be honnest I am fed up with it, it is just toooooo slow! Dual G4 750 MHz++ is needed for OS X! We have a lightning storm comming inn right now, I am closing down! Cheers, Conrad- >Hi Conrad, > >> It's been a while, but I should be able to get you on the right track. >> Observe that there are .zas files in the project workspace (they are >> "xml-ish"). >> If you look at the File Mappings in a project Settings Dialog you'll see >> that .zas files require the Zoolib Asset Compiler. > >yep, that's what I thought. > >> The source and xml export file for ZAC is in src_other:tools:zac: >> You are going to need to build this one first and it requires the >> CodeWarrior Plug-In SDK. Right now I don't have that available on my >> system, and my CD's are burried in some cardboard box somewhere (I should >> be getting the CW 8 upgrade any day now) so I can't verify but I may have >> a go at this, just for fun, if none of the zoolib gurus here take over. > >last week my CD drive died so I cannot install the Plug-In SDK. >Is it available somewhere on the Net? > >> Perhaps the ZAC compiler could be distributed as a binary. > >that would be an excellent idea -- I'd really appreciate it >if someone could post it or mail it to me directly... > >> I expect that once you have got the zac compiler build and in the proper >> CW plug-in directory the PainterTest project will build without errors. > >I'm sure it'd build if I had all the right components... > >Thanks and ciao, >Dario > > >---------------------------------------------------------------------------- > Bringing you mounds of caffeinated joy > >>> http://thinkgeek.com/sf <<< > >_______________________________________________ >ZooLib-dev mailing list >Zoo...@li... >https://lists.sourceforge.net/lists/listinfo/zoolib-dev > > |
|
From: Conrad W. <we...@on...> - 2002-06-18 16:10:48
|
>Hi Conrad,
>
>> It's been a while, but I should be able to get you on the right track.
>> Observe that there are .zas files in the project workspace (they are
>> "xml-ish").
>> If you look at the File Mappings in a project Settings Dialog you'll see
>> that .zas files require the Zoolib Asset Compiler.
>
>yep, that's what I thought.
>
>> The source and xml export file for ZAC is in src_other:tools:zac:
Oops my eyes were crosswired, it's in:
zoolib:tools:zac:
>> You are going to need to build this one first and it requires the
>> CodeWarrior Plug-In SDK. Right now I don't have that available on my
>> system, and my CD's are burried in some cardboard box somewhere (I should
>> be getting the CW 8 upgrade any day now) so I can't verify but I may have
>> a go at this, just for fun, if none of the zoolib gurus here take over.
>
>last week my CD drive died so I cannot install the Plug-In SDK.
>Is it available somewhere on the Net?
I tried at metrowerks.com and found it downloadable at:
<http://www.metrowerks.com/support/api/>
It's close to 5 Megs.
>
>> Perhaps the ZAC compiler could be distributed as a binary.
>
>that would be an excellent idea -- I'd really appreciate it
>if someone could post it or mail it to me directly...
>
>> I expect that once you have got the zac compiler build and in the proper
>> CW plug-in directory the PainterTest project will build without errors.
>
>I'm sure it'd build if I had all the right components...
I'll see what I can do later this evening. If I get it together I'll post
my findings here. Perhaps Michael D. Crawford will step in in the mean
time. But judging from the noise on this list that could take a while. :-)
Conrad.
>
>Thanks and ciao,
>Dario
>
>
>----------------------------------------------------------------------------
> Bringing you mounds of caffeinated joy
> >>> http://thinkgeek.com/sf <<<
>
>_______________________________________________
>ZooLib-dev mailing list
>Zoo...@li...
>https://lists.sourceforge.net/lists/listinfo/zoolib-dev
>
>
|
|
From: Dario A. <ad...@so...> - 2002-06-18 16:06:41
|
Hello, as I wrote earlier the PainterTest project won't build because I lack the ZAS compiler and at the moment I can't build it (don't have the CW Plug-In SDK). I've tried the build at least ButtonMessage just to take a look at the library (Carbon debug target under CodeWarrior Pro 7.2 on OS X 10.1.5), but I got a lot of errors, reported below. Besides the obvious ones, there are more subtle problems regarding the MSL and possibly order-of-inclusion inconsistencies across different CW versions -- I suspect the project was exported from CW Pro 6.x and not 7.x I'd really like to take a look at ZooLib and how (whether?) it performs in Carbon builds. Thanks and ciao, Dario |
|
From: Dario A. <ad...@so...> - 2002-06-18 15:54:25
|
Hi Conrad, > It's been a while, but I should be able to get you on the right track. > Observe that there are .zas files in the project workspace (they are > "xml-ish"). > If you look at the File Mappings in a project Settings Dialog you'll see > that .zas files require the Zoolib Asset Compiler. yep, that's what I thought. > The source and xml export file for ZAC is in src_other:tools:zac: > You are going to need to build this one first and it requires the > CodeWarrior Plug-In SDK. Right now I don't have that available on my > system, and my CD's are burried in some cardboard box somewhere (I should > be getting the CW 8 upgrade any day now) so I can't verify but I may have > a go at this, just for fun, if none of the zoolib gurus here take over. last week my CD drive died so I cannot install the Plug-In SDK. Is it available somewhere on the Net? > Perhaps the ZAC compiler could be distributed as a binary. that would be an excellent idea -- I'd really appreciate it if someone could post it or mail it to me directly... > I expect that once you have got the zac compiler build and in the proper > CW plug-in directory the PainterTest project will build without errors. I'm sure it'd build if I had all the right components... Thanks and ciao, Dario |
|
From: Conrad W. <we...@on...> - 2002-06-18 15:31:51
|
>On Tuesday, June 18, 2002, at 12:58 , Conrad Weyns wrote: > >> Here are my MacCVSPro 2.5.1 PPC settings of interest for zoolib: >> >> Checkout and Update Options >> Default Module: zoolib >> Default Revision: (blank) >> >> >> Remote Host information >> Server Hostname: cvs.zoolib.sourceforge.net >> CSB Root: /cvsroot/zoolib >> >> CVS Usaer Name: anonymous >> CVS Password: (blank) >> CVS Command: cvs > >I have checked out the sources from CVS and imported the >PainterTest project, assigned the required source trees, >and attempted a build of the Carbon debug target on OS X >using CodeWarrior Pro 7.2, which results in: >--- >Couldn't find compiler "ZooLib Asset Compiler". >[repeated twice] > >Error : illegal token >zconfig.h line 70 >[repeated a few times] > >Error : error during open of "PainterTest=5FAssets=5Fen.zao" >PainterTest=5FResources.r line 1 read 'ZAO=5F' (20000, >"PainterTest=5FAssets=5Fen") "PainterTest=5FAssets=5Fen.zao"; >[repeated twice] > >Error : illegal token >zconfig.h line 70 >[repeated about a hundred times] >--- >Any help would be appreciated. It's been a while, but I should be able to get you on the right track. Observe that there are .zas files in the project workspace (they are "xml-ish"). If you look at the File Mappings in a project Settings Dialog you'll see that .zas files require the Zoolib Asset Compiler. The source and xml export file for ZAC is in src=5Fother:tools:zac: You are going to need to build this one first and it requires the CodeWarrior Plug-In SDK. Right now I don't have that available on my system, and my CD's are burried in some cardboard box somewhere (I should be getting the CW 8 upgrade any day now) so I can't verify but I may have a go at this, just for fun, if none of the zoolib gurus here take over. Perhaps the ZAC compiler could be distributed as a binary. I expect that once you have got the zac compiler build and in the proper CW plug-in directory the PainterTest project will build without errors. hope this helped a bit, Cheers, Conrad Weyns. > >Thanks and ciao, >Dario > > >--------------------------------------------------------------------------= -- > Bringing you mounds of caffeinated joy > >>> http://thinkgeek.com/sf <<< > >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >ZooLib-dev mailing list >Zoo...@li... >https://lists.sourceforge.net/lists/listinfo/zoolib-dev > > |
383 messages has been excluded from this view by a project administrator.
