However, the real reason I found that I could not (possibly ever) use Prevayler is becuase it seemed the approach was for one machine and one machine only. There were no distributed mechanisms at all. Or at least, not how I'm used to working.
Having looked at the architecture back in the v1 days, I'd say its key strength is its simplicity. It might not have any distributed features, but you can add them yourself fairly easily.
First level of distribution: separate data storage from business logic (easy; just use RMI to pass your transactions / fetch requests to a simple back end that interfaces pretty much directly to your object storage).
Second level of distribution: too many queries to handle in a single server? Implement object caches that communicate directly with the server. The object caches can have the same RMI interface as the original data storage server, so this can be transparent. Transactions are forwarded to the actual data storage server, which can be arranged to invalidate modified objects on the caches through simple updates to your command classes.
Third level of distribution: need failover? Have multiple data storage servers and make them pass transactions retrieved to all the others. They'll have to agree on the order to execute them which will slow things down a litte, but probably not horrendously.
Anything I've missed?
Of course, I reckon it'd be almost as easy to start this from scratch as to use their architecture. Last time I looked at their code (back when the last/. article was posted), it was something like 200 LOC. And the idea's very easy to understand.
What's the transaction API like? Do I lock objects then update them? What about deadlock? (Easy enough to avoid by anyone smart enough to know any of the algorithms like having to sort the order in which you lock resources, but still a hassle.)
Its pretty simple. You create command objects to represent each kind of transaction you can perform. They all implement a fairly simple interface. You present them to the persistence layer, which executes them 1 at a time. No locking is necessary. No deadlocks are possible.
In fact, its so simple I see no need to use their code to do it. In fact, in one of my applications I have recently used the same model with my own implementation. I used my own implementation because I didn't want to use Java's serialization API (I find using a self implemented system that doesn't rely on reflection is generally much faster).
Actually, not a race condition. I looked at the architecture a while ago, and all updates are pushed through a single thread (don't know if they've changed this at all). So rather than race conditions you get a bottleneck that won't scale with additional processors...
You obviously don't know me, so please refrain from making comments like that.
It seems from your posts that you're an anti-xml and anti-java zealot. I can't tell much more than that, but you only seem to consider the negative problems that these technologies have and not the positive (hint - no technology is perfect for every application: XML is designed for open interchange of complex structured data in a human readable format, Java is designed for rapid development of long-lived applications).
From my posts you somehow determine that I am a "luser". This is despite the fact that I have clearly demonstrated a deep understanding of system level concepts, such as the fundamental differences between just-in-time and ahead-of-time compilation, the fact that I/O time is probably more critical than processor time in handling XML data, knowledge of alternative data formats that aren't current buzzwords, and appreciation of the critical differences between an application and a shell utility, and why just-in-time compilation is not suitable for the latter but is generally acceptable for the former.
Most non-graphical editors don't feature page break lines, which, really only ought to matter when you require to start a new page for a new chapter etc.
When I use emacs for such things (rarely, but I do sometimes), I find M-x quoted-insert ^L often does the job.
Re:Stop the XML madness
on
Practical RDF
·
· Score: 1
Dunno what world you live, but when I start an application I generally use it for about 10 minutes to an hour, some for several hours at a time.
Only incredibly small & simple shell type utilities have typical lifespans of the order of seconds or less. And I'll agree that Java is not a suitable technology for those. Unless you use an ahead-of-time compiler, of which there are plenty available now, at which point startup times will be on a similar order to those you'd expect from C code (ie milliseconds for a small and simple program).
Re:Hold the front page : MS-DOS faster than XP
on
Practical RDF
·
· Score: 1
Yeah, but an order of magnitude over stuff that we had _many years ago_; so nothing like 4GHz.
I'm interested. I understand the complaint against MS Word, no need to go into that in any depth, but what precisely do your friends have against OpenOffice?
I don't believe it has any annoying "get in the way" features like the Office Assistant that are enabled by default, does it?
I guess there's autocompletion on by default, but that just pops up suggestions and does nothing if you ignore them (unlike the MS word version), so I would have thought that about 5 minutes is all it takes for anyone to get used to that.
Wouldn't recommend using notepad for novel work, as a novel typically runs to 70 or 100 k-words, which is more than notepad can handle easily.
But its fine for short stories, I guess.
I think the key is to discipline yourself not to use the fancy word processor features. You shouldn't want to anyway, fancy stuff in a manuscript for a novel makes it less likely to get published, according to most research into the subject.
I must admit that I've started to find completion from words you've typed before (which is what I assume is meant by 'completion from buffer') quite useful in my writing. It probably adds about 5% to my typing speed, which is handy.
I would not call vi particularly intuitive, but it does cut down on pointless formatting decisions that seem to endlessly arise.
OK, I'm going to jump in here. I thought the point was particularly daft when the original author wrote it, and I think its daft now.
There are no formatting choices when you write a novel. Well, pretty close to zero, anyway.
Lets see:
Typeface: Courier (or nearest equivalent). Market research shows that manuscripts that are made to look as close to traditional typed text as possible are more likely to be picked up by a publisher. That's the end of that one. Easy.
Font size: 11 or 12 pt double spaced Doesn't really matter a huge amount which one, some think 12pt is easier to read, some prefer the slimmer feel of a manuscript with slightly fewer pages. You'll choose it when you sit down first time and won't change it. Ever.
Page layout: A4 or Letter, whichever you normally use, 1" margins The only size of paper you'd ever consider
Special effects in the text Underline for emphasis. Anything else is generally accepted to be offputting to editors.
Chapter headers, etc Start a new page. Underline them if you feel like it. It doesn't really matter anyway, they'll be reformatted when the book gets published.
Headers and footers Your name, book title, page number.
And that's pretty much everything you need to know. It'll take, what, about 2 minutes to set up if you know the application, about 10 minutes if you don't.
Oh, and how do I print my vi output in the right format (paginated with the right margins, headers and footers, any necessary sections underlined, double spaced)? I'm sure there's a nice little Unix utility to do it, but it'd probably take me about 10 minutes with man to find it and work out how to use it.
I'll stick with OpenOffice for my novel writing requirements, thanks.
Counter to the counter: Car companies could have made much better and more profitable cars if they switched away from gasoline a decade ago.
No they couldn't. The car market was (is) resistant to change. Even now, LPG fuelled vehicles are more efficient, cleaner and cheaper to run than traditional petroleum spirit vehicles, and have little if any performance difference, but does anybody buy them?
Re:Stop the XML madness
on
Practical RDF
·
· Score: 1
(or who want to do a lot of work on ).
Err, that was meant to read "or who want to do a lot of work on <your-favourite-distributed-computing-project-here > but I forgot to quote the start and end, so it got stripped out as an invalid html tag.
Note to self: use Preview.
Re:Stop the XML madness
on
Practical RDF
·
· Score: 4, Insightful
java + XML = demand for 4+ghz CPUs
Err.. OK.
1. Java runs perfectly adequately for me on my 400 MHz machine. Typical application startup times are ~1 second which is generally acceptable, and once the application is running there's not normally a noticeable difference between it and a 'native' application (whatever that might mean for you...). (Note the distinction between noticeable and measurable, also please bear in mind that I'm not talking about AWT/Swing apps here, those really are slow, but that's the library not the language that's responsible, IMHO).
2. XML might be a little slower to process than other similarly expressive data formats (eg s-expressions, ASN.1 and similar). Maybe by a factor of 10, even. However, the data formats I am comparing it to were considered acceptable for use on 4 MHz processors, and even then the I/O time was a lot more significant than processor time for such operations. Processor speed growth has substantially outpaced IO speed growth over that period.
AFAICT the only people "demanding 4 GHz CPUS" are the "I've got a better PC than you" crowd, serious gamers, and people who are doing really demanging applications, like video editing or scientific applications (or who want to do a lot of work on ).
Actually, most of my equipment here has a flat side at the top, except for Microsoft mice which seem to have a ridge on the round barrel of their connector pointing towards the top, which isn't as easy to use but works OK. Different suppliers, I guess, using different cheap OEM manufacturers end up with different results... wonder what the ratio is?
Oh, I see what you mean. Yeah, you can't put em in upside down. I thought you meant they're keyed differently to one another so you can't put the keyboard in the mouse socket or vice versa, which would be a smart addition...
So any "technical effect" on the user, such as saving mouse clicks by using cookies when shopping online, for example, can be patented.
Yes. It only covers you for performing data format conversions (like say decoding or encoding GIF images or any other patent encumbered format that you might need to use for interoperability's sake) or network protocols to allow two different types of system to communicate (eg CIFS or anything else MS reckons they have the right to stop you making your own implementation of...).
By adding to the language, you've allowed them to do things in ways we pure C guys object to.
I can write (and in fact have written) object oriented programs in C.
C++ makes it easier to write object oriented programs, but just because it makes something you don't like easier doesn't mean it has to be bad. It means that when somebody does write an object oriented program in it, you can probably at least understand what its doing.
last time I checked, there weren't very many web pages being written in C++.
Oooh, Oooh, I've done that.
Not going to do it again though. 'twas nasty.
For reference: I needed a CGI system that could run be compiled and dumped onto a server on a variety of OS's without the hassle of installing a script interpreter, such as perl, on those that don't have them. That's when you write a web site in C++.
Another thing: the first part of the project is making a suitable template expander. Any other way is just daft.
Are the moderators all 14 years old? Informative? It was obviously a joke guys.
You expect better? Bullshit articles that don't have a fragment of truth in them are generally mod'd 5 Informative. 'I for one welcome our new Sith overlords' will be rated 5 Funny. Even 'In soviet russia light saber own you' will get 3 points.
I heard about that one too. Only the way I heard it, the problem was that the training set with tanks was taken on a sunny day, and the training set without them was done on a cloudy day. The neural net that was doing the processing obviously learnt the easiest difference it could find between the two sets, and they therefore ended up with the worlds most sophisticated sunny-day-in-a-forest detector.
Jeez MS! Why not get the bugs out of Windows first THEN start all these kinds of projects?! The simple fact is - you don't have time for this AND trustworthy computing.
Nice sentiment, but probably impossible. If they didn't do this kind of research, they wouldn't be able to attract top class employees. These people probably couldn't work on fixing the security issues in other software, because (a) they don't know that software (b) they aren't security programmers, they're research programmers, (c) there are already lots of people working on the other software and the old metaphor of "too many cooks spoil the broth" applies particularly well to software engineering.
Slashdot Mirror
However, the real reason I found that I could not (possibly ever) use Prevayler is becuase it seemed the approach was for one machine and one machine only. There were no distributed mechanisms at all. Or at least, not how I'm used to working.
/. article was posted), it was something like 200 LOC. And the idea's very easy to understand.
Having looked at the architecture back in the v1 days, I'd say its key strength is its simplicity. It might not have any distributed features, but you can add them yourself fairly easily.
First level of distribution: separate data storage from business logic (easy; just use RMI to pass your transactions / fetch requests to a simple back end that interfaces pretty much directly to your object storage).
Second level of distribution: too many queries to handle in a single server? Implement object caches that communicate directly with the server. The object caches can have the same RMI interface as the original data storage server, so this can be transparent. Transactions are forwarded to the actual data storage server, which can be arranged to invalidate modified objects on the caches through simple updates to your command classes.
Third level of distribution: need failover? Have multiple data storage servers and make them pass transactions retrieved to all the others. They'll have to agree on the order to execute them which will slow things down a litte, but probably not horrendously.
Anything I've missed?
Of course, I reckon it'd be almost as easy to start this from scratch as to use their architecture. Last time I looked at their code (back when the last
What's the transaction API like? Do I lock objects then update them? What about deadlock? (Easy enough to avoid by anyone smart enough to know any of the algorithms like having to sort the order in which you lock resources, but still a hassle.)
Its pretty simple. You create command objects to represent each kind of transaction you can perform. They all implement a fairly simple interface. You present them to the persistence layer, which executes them 1 at a time. No locking is necessary. No deadlocks are possible.
In fact, its so simple I see no need to use their code to do it. In fact, in one of my applications I have recently used the same model with my own implementation. I used my own implementation because I didn't want to use Java's serialization API (I find using a self implemented system that doesn't rely on reflection is generally much faster).
Actually, not a race condition. I looked at the architecture a while ago, and all updates are pushed through a single thread (don't know if they've changed this at all). So rather than race conditions you get a bottleneck that won't scale with additional processors...
Excuse me?
You obviously don't know me, so please refrain from making comments like that.
It seems from your posts that you're an anti-xml and anti-java zealot. I can't tell much more than that, but you only seem to consider the negative problems that these technologies have and not the positive (hint - no technology is perfect for every application: XML is designed for open interchange of complex structured data in a human readable format, Java is designed for rapid development of long-lived applications).
From my posts you somehow determine that I am a "luser". This is despite the fact that I have clearly demonstrated a deep understanding of system level concepts, such as the fundamental differences between just-in-time and ahead-of-time compilation, the fact that I/O time is probably more critical than processor time in handling XML data, knowledge of alternative data formats that aren't current buzzwords, and appreciation of the critical differences between an application and a shell utility, and why just-in-time compilation is not suitable for the latter but is generally acceptable for the former.
Welcome to my ignore list.
Most non-graphical editors don't feature page break lines, which, really only ought to matter when you require to start a new page for a new chapter etc.
When I use emacs for such things (rarely, but I do sometimes), I find M-x quoted-insert ^L often does the job.
Dunno what world you live, but when I start an application I generally use it for about 10 minutes to an hour, some for several hours at a time.
Only incredibly small & simple shell type utilities have typical lifespans of the order of seconds or less. And I'll agree that Java is not a suitable technology for those. Unless you use an ahead-of-time compiler, of which there are plenty available now, at which point startup times will be on a similar order to those you'd expect from C code (ie milliseconds for a small and simple program).
Yeah, but an order of magnitude over stuff that we had _many years ago_; so nothing like 4GHz.
I'm interested. I understand the complaint against MS Word, no need to go into that in any depth, but what precisely do your friends have against OpenOffice?
I don't believe it has any annoying "get in the way" features like the Office Assistant that are enabled by default, does it?
I guess there's autocompletion on by default, but that just pops up suggestions and does nothing if you ignore them (unlike the MS word version), so I would have thought that about 5 minutes is all it takes for anyone to get used to that.
Is there anything else?
Wouldn't recommend using notepad for novel work, as a novel typically runs to 70 or 100 k-words, which is more than notepad can handle easily.
But its fine for short stories, I guess.
I think the key is to discipline yourself not to use the fancy word processor features. You shouldn't want to anyway, fancy stuff in a manuscript for a novel makes it less likely to get published, according to most research into the subject.
I must admit that I've started to find completion from words you've typed before (which is what I assume is meant by 'completion from buffer') quite useful in my writing. It probably adds about 5% to my typing speed, which is handy.
I would not call vi particularly intuitive, but it does cut down on pointless formatting decisions that seem to endlessly arise.
OK, I'm going to jump in here. I thought the point was particularly daft when the original author wrote it, and I think its daft now.
There are no formatting choices when you write a novel. Well, pretty close to zero, anyway.
Lets see:
Typeface: Courier (or nearest equivalent).
Market research shows that manuscripts that are made to look as close to traditional typed text as possible are more likely to be picked up by a publisher. That's the end of that one. Easy.
Font size: 11 or 12 pt double spaced
Doesn't really matter a huge amount which one, some think 12pt is easier to read, some prefer the slimmer feel of a manuscript with slightly fewer pages. You'll choose it when you sit down first time and won't change it. Ever.
Page layout: A4 or Letter, whichever you normally use, 1" margins
The only size of paper you'd ever consider
Special effects in the text
Underline for emphasis. Anything else is generally accepted to be offputting to editors.
Chapter headers, etc
Start a new page. Underline them if you feel like it. It doesn't really matter anyway, they'll be reformatted when the book gets published.
Headers and footers
Your name, book title, page number.
And that's pretty much everything you need to know. It'll take, what, about 2 minutes to set up if you know the application, about 10 minutes if you don't.
Oh, and how do I print my vi output in the right format (paginated with the right margins, headers and footers, any necessary sections underlined, double spaced)? I'm sure there's a nice little Unix utility to do it, but it'd probably take me about 10 minutes with man to find it and work out how to use it.
I'll stick with OpenOffice for my novel writing requirements, thanks.
Counter to the counter: Car companies could have made much better and more profitable cars if they switched away from gasoline a decade ago.
No they couldn't. The car market was (is) resistant to change. Even now, LPG fuelled vehicles are more efficient, cleaner and cheaper to run than traditional petroleum spirit vehicles, and have little if any performance difference, but does anybody buy them?
(or who want to do a lot of work on ).
e > but I forgot to quote the start and end, so it got stripped out as an invalid html tag.
Err, that was meant to read "or who want to do a lot of work on <your-favourite-distributed-computing-project-her
Note to self: use Preview.
java + XML = demand for 4+ghz CPUs
Err.. OK.
1. Java runs perfectly adequately for me on my 400 MHz machine. Typical application startup times are ~1 second which is generally acceptable, and once the application is running there's not normally a noticeable difference between it and a 'native' application (whatever that might mean for you...). (Note the distinction between noticeable and measurable, also please bear in mind that I'm not talking about AWT/Swing apps here, those really are slow, but that's the library not the language that's responsible, IMHO).
2. XML might be a little slower to process than other similarly expressive data formats (eg s-expressions, ASN.1 and similar). Maybe by a factor of 10, even. However, the data formats I am comparing it to were considered acceptable for use on 4 MHz processors, and even then the I/O time was a lot more significant than processor time for such operations. Processor speed growth has substantially outpaced IO speed growth over that period.
AFAICT the only people "demanding 4 GHz CPUS" are the "I've got a better PC than you" crowd, serious gamers, and people who are doing really demanging applications, like video editing or scientific applications (or who want to do a lot of work on ).
Actually, most of my equipment here has a flat side at the top, except for Microsoft mice which seem to have a ridge on the round barrel of their connector pointing towards the top, which isn't as easy to use but works OK. Different suppliers, I guess, using different cheap OEM manufacturers end up with different results... wonder what the ratio is?
Oh, I see what you mean. Yeah, you can't put em in upside down. I thought you meant they're keyed differently to one another so you can't put the keyboard in the mouse socket or vice versa, which would be a smart addition...
So any "technical effect" on the user, such as saving mouse clicks by using cookies when shopping online, for example, can be patented.
Yes. It only covers you for performing data format conversions (like say decoding or encoding GIF images or any other patent encumbered format that you might need to use for interoperability's sake) or network protocols to allow two different types of system to communicate (eg CIFS or anything else MS reckons they have the right to stop you making your own implementation of...).
For example, PS2 connections for keyboards and mice are keyed to prevent being plugged in the wrong way.
Umm, no they aren't. At least not on any of my keyboards, mice, or motherboards.
They *should* be, cause it'd save an awfully large amount of annoyance...
By adding to the language, you've allowed them to do things in ways we pure C guys object to.
I can write (and in fact have written) object oriented programs in C.
C++ makes it easier to write object oriented programs, but just because it makes something you don't like easier doesn't mean it has to be bad. It means that when somebody does write an object oriented program in it, you can probably at least understand what its doing.
last time I checked, there weren't very many web pages being written in C++.
Oooh, Oooh, I've done that.
Not going to do it again though. 'twas nasty.
For reference: I needed a CGI system that could run be compiled and dumped onto a server on a variety of OS's without the hassle of installing a script interpreter, such as perl, on those that don't have them. That's when you write a web site in C++.
Another thing: the first part of the project is making a suitable template expander. Any other way is just daft.
Or maybe its just been slashdotted? Geocities pages never last long...
Are the moderators all 14 years old? Informative? It was obviously a joke guys.
You expect better? Bullshit articles that don't have a fragment of truth in them are generally mod'd 5 Informative. 'I for one welcome our new Sith overlords' will be rated 5 Funny. Even 'In soviet russia light saber own you' will get 3 points.
This is slashdot, after all...
I heard about that one too. Only the way I heard it, the problem was that the training set with tanks was taken on a sunny day, and the training set without them was done on a cloudy day. The neural net that was doing the processing obviously learnt the easiest difference it could find between the two sets, and they therefore ended up with the worlds most sophisticated sunny-day-in-a-forest detector.
Jeez MS! Why not get the bugs out of Windows first THEN start all these kinds of projects?! The simple fact is - you don't have time for this AND trustworthy computing.
Nice sentiment, but probably impossible. If they didn't do this kind of research, they wouldn't be able to attract top class employees. These people probably couldn't work on fixing the security issues in other software, because (a) they don't know that software (b) they aren't security programmers, they're research programmers, (c) there are already lots of people working on the other software and the old metaphor of "too many cooks spoil the broth" applies particularly well to software engineering.
(2) The "news" story titles are misleading and the stories are frequently repeated over the course of a week;
Now where have I seen this before? Hmmm...