[ANN] Website not updated to D6 ;-)
Chris Uppal
I've just managed to publish the changes to my website that have been
accumulating for about a year. There are lots of changes to just about
everything (but not the FMB -- sorry Bill) and some new stuff too.
The bad news is that the new version is all totally D5-based. I haven't even
tried to accommodate the changes for D6 -- I wanted to get D5 stuff out, and
frozen, there before getting properly stuck into what (I expect) will be a
rather tiresome porting/rewriting/redesigning job.
Some of the stuff there will "just work" with D6; some of it needs changes to
track the rather capricious changes made by OA; some of it needs changes to
track the very sensible changes made by OA; some of it has been totally broken;
some of it is now irrelevant; the status of the remainder is still "unknown"...
-- chris
Bill Schwab
> Well, despite the smiley, the subject line is true.
>
> I've just managed to publish the changes to my website that have been
> accumulating for about a year. There are lots of changes to just about
> everything (but not the FMB -- sorry Bill) and some new stuff too.
IIRC, after we batted it around, the main thing that I find missing is a
script-friendly version. I don't think it would be too hard to do, but
that's easy for *me* to say about *your* time. Here's hoping you will
keep it alive; it's been very helpful at times, and I think a scriptable
version would be all the more so.
Have a good one,
Bill
--
Wilhelm K. Schwab, Ph.D.
bi...@anest4.anest.ufl.edu
Blair McGlashan
news:439c69d2$0$253$bed6...@news.gradwell.net...
> ...
> Some of the stuff there will "just work" with D6; some of it needs changes
> to
Do you intend to substantiate that allegation Sir? :-)
(Now, i.e. post beta, is probably too late to revisit changes, but I'd
nevertheless be interested in knowing what you think fits into that category
for future reference).
Regards
Blair
Jason Shannon
<chris...@metagnostic.REMOVE-THIS.org> wrote:
>The bad news is that the new version is all totally D5-based. I haven't even
>tried to accommodate the changes for D6 -- I wanted to get D5 stuff out, and
>frozen, there before getting properly stuck into what (I expect) will be a
>rather tiresome porting/rewriting/redesigning job.
For what it's worth, I got your ListTree package working in D6. If you
want a copy, let me know.
Regards,
--
Jason Shannon
Chris Uppal
> For what it's worth, I got your ListTree package working in D6. If you
> want a copy, let me know.
Thanks for the offer Jason. I hope it didn't cost you too much effort.
I'll pass for now, all the same -- I prefer to introduce my own bugs wherever
possible, um, I mean I prefer to make my own changes wherever possible
(otherwise I end up owning code I don't fully understand).
But that'll have to wait until I really get stuck into D6 -- I'm still using
the beta for experiments, and D5 for "real" code. Should be soon[*], but no
dates...
(BTW, for Blair, I do intend to answer your question in this thread, but I want
to see what's in D6 final before doing so.)
-- chris
([*] my biggest worry, and what is holding me off moving to D6 already, is
whether the problems with corrupted STS databases that I was having with the
beta will show in the final -- I hope not, but there has been no news of any
fix)
David Gorisek
>
> ([*] my biggest worry, and what is holding me off moving to D6 already, is
> whether the problems with corrupted STS databases that I was having with the
> beta will show in the final -- I hope not, but there has been no news of any
> fix)
>
>
>
Which bug would that be? Can you give me the steps to reproduce it. The
beta newsgroup is now gone so I forgot what it was about.
Best regards,
David Gorisek
Chris Uppal
> Which bug would that be? Can you give me the steps to reproduce it. The
> beta newsgroup is now gone so I forgot what it was about.
I'll append a repeat of my last post about the corruption problem. The example
is still at the URL that post mentions. I'll also append a short post
describing another problem -- it may already be fixed, but I don't know (and I
don't want to touch STS or D6 until I'm willing to comit to switching all my
work to the new version). BTW, I sent you an email with some fixes (principly
about virtual method category handling) rather earlier in the beta, did you
incorporate any of that ?
-- chris
=========== 2005-10-21 ===============
STS 'compare changes' seems to think that any loose methods in a package have
changed in every edition. This seems to be because there are different
'versions' of the method in each edition with different timestamps but
otherwise identical. I'm not sure if that's an error in the versioning code,
or whether the compare editions code is supposed to ignore differences that are
only to the timestamp.
The old version of STS that I use with D5 does not have this problem.
-- chris
=========== 2005-10-20 ===============
David,
> could you first send me a walkback file so that I can see which error
> you are getting?
I'll attatch some extracts from the .errors file, but I doubt if they'll be
much use. The walkbacks happen as a response to the fact that the Omnibase
state is already trashed. And, as I mentioned, they don't always happen at
all -- sometimes everything seems fine until I disconnect and reconnect. There
have been a variety of failures but the most common one(s) seem to the be of
the 'unknown serial id(1)' variety.
> If this wont help I can then give you FTP access on our server for
> sending database files.
Shouldn't be necessary -- I've managed to put together a reasonably small
example respository and have posted it at:
http://ephemera.metagnostic.org/code/Repository.zip
1.8 Mb zipped.
Please note -- that repository was generated from my real one by stripping out
lots of stuff "by hand" (working at the OmniBase level rather than with STS
tools), that may mean that it isn't completely valid from the point of view of
STS's own semenatics. However it /is/ valid (I believe) as an OmniBase db.
Now to see the problem (detailed instructions in case anyone else wants to
follow along).
First connect STS to that repository:
StsManager startUpOn: 'somewhere'.
You should find that all the STS tools work OK (at least I didn't see any
problems despite the above caveat). My own scanner (which is also in that
download) finds no problems. All seems good.
Now run:
StsManager current fixup.
where #fixup is a loose method defined in the fixup.pac package (also in the
download). All that does is duplicates the versioning code in
StsManager>>install. That takes a while, and -- in the couple of times I've
tried it -- produces no apparent errors. (Remember that that sometimes happens
in the "real" case too). Assuming that there were no errors, then the STS
tools will still be working too, and my scanner:
STSScanner new scanWithProgress.
will not find any problems. If the versioning loop /did/ encounter errors then
the OmniBase state should already be corrupted.
Now disconnect:
StsManager shutdown.
close any browsers, etc, and then reconnect. If your system has done the same
thing as mine, we are now in difficulties.
Try (working just at the OmniBase level) looking at the data:
txn := StsManager current databaseConnection newTransaction.
txn root at: 'sts.packages'. "inspect it"
txn root at: 'sts.classes'. "inspect it"
"close the inspectors then: "
txn abort.
You'll probably encounter a lot of errors. If you open the package edition
browser then it'll throw lots of errors too, and may be difficult to kill.
If you inspect OmniBase's class manager:
StsManager current databaseConnection classManager.
then you'll see that many of the class definitions are corrupt.
Remember to:
StsManager shutdown.
before attempting to use any of the browsers!
Now it's possible that some of the errors in the above are because I have
mangled the database contents -- but the point is that nothing we've done
should have actually corrupted the OmniBase data. In my real image, exactly
the same kind of corruption happens.
The single package in the respository /may/ be connected with the problem, or
there again it may just be coincidence, but without that package I wasn't
seeing the same kind of corruption. The package is unusual in two ways. One
is that it has a global variable defined. The other is that that variable
holds an instance of one of the classes in the package. Indeed, because I've
changed the shape of that class a few times without creating suitable STB fixup
code, the STB-ed binary data for that global can only be reconstituted (without
errors) using the code in the same version of the package. I repeat that it
may just be coincidence, but if not then oddness of that package (and some
others like it in my real image) might explain why I'm seeing a problem when
you are not.
Anyway, thanks for looking into this. Please let me know when you want more
data.
-- chris