There is a VB object interface, but if you use that to open and close a lot of Caché records as objects in a loop, it is going to be impressively slow.
Also using dynamic SQL through VB is possible, but the back end has to compile each query individually. This also could make things slow if used in a loop.
Basic client/server design methodology, really. Probably not Caché's fault.
I rid myself of a great deal of funkiness by getting the latest version (4.1.5 for Linux IIRC), making sure the client Windows ODBC drivers match, and judiciously using %UnSwizzleAt() when working with Caché lists (one thing I don't like about Caché is that when you %Close() an object, it may not really close if it's being referenced in a list, you have to unswizzle it manually)
It seems like your distress is analogous to those who see someone use the word "to" when they mean "too" and cringe. Or at the very least, reread the sentence.
I know it's semantics, but that's half of what you're talking about, isn't it?
I'll grant that it would help is if at least the 2.96 versions showed the patchlevel, because the later 2.96'es appear to be far better than the early ones.
My take on this is, recent 2.96es work and have athlon optimization, 2.95.3 doesn't AFAIK, and 3.0.x is slower.
It's a little sad to see people still whining about what happened in August 2000 when as far as I can tell, the reports of buggitude no longer apply.
I'm glad I learned about, for example, XF86Config through having to practically write the whole thing manually because Slackware 2.0 didn't know about my monitor and couldn't detect my video card. But once you get past the been-there-done-that stage, having an automated tool is a welcome relief.
Kind of like the front panel toggle switches somebody else mentioned today - yes I like the fact that I actually had a computer that had them, and that I actually entered a (very) trivial program by them and watched the address lights as the program looped around memory, but I'm happy to have BIOS ROMs do that sort of work now. . .
I did the package-only update with Beta1, and some stuff I had in modules.conf got eaten, but Beta3 and RC1 handled the subsequent updates OK after I copied the missing stuff back in.
Moral: I would back up my lilo.conf, modules.conf and devfsd.conf first to be absolutely sure, if there is anything in there special, but you may not need it.
All in all Mandrake 8.2 has been a lot smoother than 8.1 for me.
Um, I don't think DOS and Windows 3.1 was easy for beginners either - maybe some DOS and Windows 3.1 beginners, as long as they weren't also *computer* beginners.
I remember wrestling with WIN.INI and SYSTEM.INI to get sound to work on a buddy's PC way past midnight, turned out something ate his reference to mmsystem.dll. ..you don't wish that on people at large do you?
IMHO, some people can handle more abstraction than others. Those who can, can "get" computers the old fashioned way. Those who can't, need to be catered to in a way we think is superfluous, but that's beside the point.
Re:Summary of Tandy computer line
on
Tandys Never Die
·
· Score: 1
I had the model II and 16 confused, thanks for the memory refresh!
IIRC, most TRS-80's (the desktops) used Z-80 processors; my Model 200 (similar to model 100, but with clamshell case design/larger screen) uses an Intel 80C85 - somewhat similar to the Z-80 in that the Z-80 is also an enhanced 8080, but enhanced differently.
OTOH, the Model II used a 68000 (also?), but I think only like 3 people actually had one of those (list price was what, $6000?). You could get Xenix for them, which was a Microsoft clone of Unix (!), although I probably only ever saw it in those funky brown vinyl software cases on the shelf at the Radio Shack franchise where I used to work.
The CoCos used a 6809 I think
I guess the point is "TRS-80" (it is rumored, anyway) stood for "Tandy/Radio Shack for the Eighties", it didn't indicate any specific architecture or software. Back in those days there was less expectation for software to be compatible between different models, but it did help out that the Models I/III/4 were compatible at least.
True story: I just put together a rather modest system for a friend of mine, using Mandrake 8.1.
It's OK, but I would have liked to recompile XFree86 to take advantage of the K6-2's 3DNow extensions. Read somewhere using -O6 is cool too.
Problem is there was almost no disk space left, and
it would probably take a *long* time.
Now, I have an Athlon 800 at home, with more disk space.
What I would like to see is a way to more-or-less automatically tell an installer "Make a distro for a K6-2 with an Mbogo Heavy Industries video card", let it grind away all night, and in the morning spew forth a custom CD-R. I guess this is similar to the earlier suggestion to have a compile farm somewhere, but even in that case you still wouldn't
want to have to have *every* machine represented,
thus the cross-compile idea.
Actually the programming language for the HP-48, RPL, is supposed to stand for "Reverse Polish Lisp", although it actually is a lot more like FORTH. (Has a couple list processing commands like HEAD and TAIL, but it's very stack focused)
I use
Intersystems' Cache at work - under the
hood it's hierarchical, so it would seem to be a good fit for XML (I hear more XML stuff is coming for version 4.2), but it also projects
everything as relational tables through ODBC,
and simultaneously as objects, through ActiveX and Java. (They're dropping CORBA, not enough interest apparently.)
I find it a little tough to program natively in, but it's gotten a lot better with version 4.x.
And it runs quite well under Linux. That's the platform I use:-)
I wouldn't mind paying a penny a page for some things, as long as it didn't cost X dollars of my time (t) to set up.
Of course, that leads to Y different companies touting 'solutions' which only increase the hassle factor (Y*t). . . fear of the problems involved before the inevitable shakeout/standardization is probably what is keeping more companies from getting into that space.
FWIW, InterSystems' Caché (a version for Linux exists available here) lets you distribute a database over a number of computers, and they don't need any OS modifications.
Disclaimer: I'm using just a single server for development, and it's on the NT Workstation partition. Caché is supported on RH 6.1, I have SuSE, which is rumored to work with a few tweaks but I haven't gotten around to installing Caché on it yet - probably will though because the Linux version is also rumored to be very fast:-)
Slashdot Mirror
Let me guess, VB front end. . .
There is a VB object interface, but if you use that to open and close a lot of Caché records as objects in a loop, it is going to be impressively slow.
Also using dynamic SQL through VB is possible, but the back end has to compile each query individually. This also could make things slow if used in a loop.
Basic client/server design methodology, really. Probably not Caché's fault.
I rid myself of a great deal of funkiness by getting the latest version (4.1.5 for Linux IIRC), making sure the client Windows ODBC drivers match, and judiciously using %UnSwizzleAt() when working with Caché lists (one thing I don't like about Caché is that when you %Close() an object, it may not really close if it's being referenced in a list, you have to unswizzle it manually)
HTH
Sorry if this is a little OT
Because GRUB is more popular now?
Well, that's your choice, but you won't have any kids that way.
Maybe synapses are just network nodes and the real computation is happening at the molecular level (DNA, RNA or both)?
.
Would be funny if "junk" DNA is actually compressed data. .
Mandrake 8.2 is pretty impressive. . .
Now if they would get away from those icky blue and orange icons everywhere. . .
Should have been "the distress of those" ? But then, I'm a Windows programmer, and quite late on my current project :-)
It seems like your distress is analogous to those who see someone use the word "to" when they mean "too" and cringe. Or at the very least, reread the sentence.
I know it's semantics, but that's half of what you're talking about, isn't it?
See
= 28 0
http://www.planetpdf.com/mainpage.asp?webpageid
for some free (as in beer) tools - many more listed for cost
Also if you want to open a PDF doc programmaticaly and edit it try PDFLib 4.0
which has source code available for some versions,
http://www.pdflib.com/
That's what pgaccess is for. Looks a lot like Access 2.0 last time I looked, but that was a long time ago (1999?)
FWIW, I thought that LPRng in 7.2 was very easy to set up using the RedHat tool and had decent output.
:-)
Now if you mean easy for the RedHat guys writing that tool to set up, well that could be a different story
That is, the version from Mandrake 8.1.
I'll grant that it would help is if at least the 2.96 versions showed the patchlevel, because the later 2.96'es appear to be far better than the early ones.
My take on this is, recent 2.96es work and have athlon optimization, 2.95.3 doesn't AFAIK, and 3.0.x is slower.
It's a little sad to see people still whining about what happened in August 2000 when as far as I can tell, the reports of buggitude no longer apply.
I think you mean Fluosol
I'm glad I learned about, for example, XF86Config through having to practically write the whole thing manually because Slackware 2.0 didn't know about my monitor and couldn't detect my video card. But once
you get past the been-there-done-that stage, having an automated tool is a welcome relief.
Kind of like the front panel toggle switches somebody else mentioned today - yes I like the fact that I actually had a computer that had them, and that I actually entered a (very) trivial program by them and watched the address lights as the program looped around memory, but I'm happy to have BIOS ROMs do that sort of work now. . .
I did the package-only update with Beta1, and some stuff I had in modules.conf got eaten, but Beta3 and
RC1 handled the subsequent updates OK after I copied the missing stuff back in.
Moral: I would back up my lilo.conf, modules.conf and devfsd.conf first to be absolutely sure, if there is anything in there special, but you may not need it.
All in all Mandrake 8.2 has been a lot smoother than 8.1 for me.
It might be $89 for an /upgrade/, but /full/ versions of Windows have traditionally retailed for more like
$189. . .
Um, I don't think DOS and Windows 3.1 was easy for beginners either - maybe some DOS and Windows 3.1 beginners, as long as they weren't also *computer* beginners.
.you don't wish that on people at large do you?
I remember wrestling with WIN.INI and SYSTEM.INI to get sound to work on a buddy's PC way past midnight,
turned out something ate his reference to mmsystem.dll. .
IMHO, some people can handle more abstraction than others. Those who can, can "get" computers the old fashioned way. Those who can't, need to be catered to in a way we think is superfluous, but that's beside the point.
I had the model II and 16 confused, thanks for the memory refresh!
I think these were actually OEM'ed by Kyocera of printer fame. (Kyocera/MITA now I guess)
IIRC, most TRS-80's (the desktops) used Z-80 processors; my Model 200 (similar to model 100, but with clamshell case design/larger screen) uses an Intel 80C85 - somewhat similar to the Z-80 in that the Z-80 is also an enhanced 8080, but enhanced differently.
OTOH, the Model II used a 68000 (also?), but I think only like 3 people actually had one of those (list price was what, $6000?). You could get Xenix for them, which was a Microsoft clone of Unix (!), although I probably only ever saw it in those funky brown vinyl software cases on the shelf at the Radio Shack franchise where I used to work.
The CoCos used a 6809 I think
I guess the point is "TRS-80" (it is rumored, anyway) stood for "Tandy/Radio Shack for the Eighties", it didn't indicate any specific architecture or software. Back in those days there was less expectation for software to be compatible between different models, but it did help out that the Models I/III/4 were compatible at least.
True story: I just put together a rather modest system for a friend of mine, using Mandrake 8.1.
It's OK, but I would have liked to recompile XFree86 to take advantage of the K6-2's 3DNow extensions. Read somewhere using -O6 is cool too.
Problem is there was almost no disk space left, and
it would probably take a *long* time.
Now, I have an Athlon 800 at home, with more disk space.
What I would like to see is a way to more-or-less automatically tell an installer "Make a distro for a K6-2 with an Mbogo Heavy Industries video card", let it grind away all night, and in the morning spew forth a custom CD-R. I guess this is similar to the earlier suggestion to have a compile farm somewhere, but even in that case you still wouldn't
want to have to have *every* machine represented,
thus the cross-compile idea.
Actually the programming language for the HP-48, RPL, is supposed to stand for "Reverse Polish Lisp", although it actually is a lot more like FORTH. (Has a couple list processing commands like HEAD and TAIL, but it's very stack focused)
I use Intersystems' Cache at work - under the hood it's hierarchical, so it would seem to be a good fit for XML (I hear more XML stuff is coming for version 4.2), but it also projects everything as relational tables through ODBC, and simultaneously as objects, through ActiveX and Java. (They're dropping CORBA, not enough interest apparently.) I find it a little tough to program natively in, but it's gotten a lot better with version 4.x. And it runs quite well under Linux. That's the platform I use :-)
I wouldn't mind paying a penny a page for some things, as long as it didn't cost X dollars of my time (t) to set up.
Of course, that leads to Y different companies touting 'solutions' which only increase the hassle factor (Y*t). . . fear of the problems involved before the inevitable shakeout/standardization is probably what is keeping more companies from getting into that space.
So we're back to nothing. Foo.
Disclaimer: I'm using just a single server for development, and it's on the NT Workstation partition. Caché is supported on RH 6.1, I have SuSE, which is rumored to work with a few tweaks but I haven't gotten around to installing Caché on it yet - probably will though because the Linux version is also rumored to be very fast :-)