Re:Paul, are you well? Update the errata!
on
MySQL Cookbook
·
· Score: 1
PatPending,
Thanks for collecting the errata. Could you post it to the errata page? That way, it will go through "the system" (we'll forward it to Paul, he's say yea or nay, and the changes will make their way into a future reprint).
What kind of monsters are these researchers, anyhow?!
Whether speeding down a virtual street in Sony's Gran Turismo or slaying Spyro the Dragon, researchers hope games such as these will improve the lives of those with attention-deficit hyperactivity disorder, commonly known as ADHD, or cognitive-processing difficulties.
> If you want to do real open source, > do not look at the poison.
Eben Moglen, General Counsel to the Free Software Foundation, told the DotGNU project that programmers will not be tainted by reading the source, so long as they don't copy any of the code.
Exactly - in C#, you can't compile anything unsafe until you enclose the code in an unsafe{} block and flip the/unsafe compiler switch.
Plus, the runtime won't even let you run unsafe mobile code. Here's what happens when I try to run foo.exe (compiled with/unsafe) from a network share:
Unhandled Exception:
System.Security.Policy.PolicyException: Required
permissions cannot be acquired.
Have a look at tinySQL - it's open source (LGPL), and 100% Java. It is an extensible SQL engine that has a JDBC driver. It started out life as a quick hack, but it's improved significantly thanks to the contributions of others. The most recent version is usually available in CVS, but there is a fairly recent tarball and jar file up there.
Enjoy,
Brian
Re:.NET may signal the demise of Linux
on
Perl and .NET
·
· Score: 1
Jon Udell's December 18th column addresses the issue you raised, questioning whether it is in Sun's best interest to keep the language and the JVM tightly coupled. The column includes a survey of some of the people who have implemented languages for the JVM.
Of course in Perl, XML::Writer and XML::Path don't share any data -- visibilty in package namespaces doesn't work that way, so they can't share data just by virtue of having the same first element in their package name.
Thanks for clarifying that - if I had thought more about what I was writing in my original post, I would have realized I was blowing swamp gas... I guess I had trouble making the context switch from Java to Perl (and back again?).
CPAN, the Comprehensive Perl Archive Network, was modeled after CTAN (the Comprehensive TeX Archive Network), and is highly successful. I think that CPAN is one of the primary reasons that Perl itself is so successful. It would be a good thing for Java to have something that is modeled after CPAN.
One of CPAN's key features is that its structure encourages collaboration - there is a group that ensures new modules are put into appropriate namespaces, so if a bunch of people want to work on stuff about XML, this group will make sure they choose an appropriate namespace (probably XML::something).
Java, on the other hand, has a naming convention that I feel discourages cooperation. For example, on CPAN, take two modules such as XML::XPath and XML::Writer. It's clear that these packages were meant to work together, and in theory, they could share some package-specific data (maybe they do, maybe they don't - the point is, they could, if it was necessary to fulfill the mission of the XML:: package).
If these same authors had written these modules for Java, and if they had followed the Java naming conventions, the modules would be called org.sergeant.xml.XPath and com.megginson.xml.Writer. This makes it difficult for them to share package-scoped data, and also makes it less clear that they are meant to work together.
This is the second time to my knowledge that Microsoft has committed resources to Perl development.
As I remember it, some of the folks at ActiveState worked at Hip Communications, the company that did a lot of the original Perl for Win32 work. Guess who provided some of the initial investment to jump-start that port of Perl 5 to Win32? Microsoft.
The last time Microsoft was involved with Perl, the Perl for Win32 port was not in the core Perl distribution. It would have been easy to morph it into WinPerl or VisualPerl or who knows what.
But the truth is, Microsoft didn't hijack it back then. Even if they had intentions to do so now, I think it would very difficult given that ActiveState's distribution is based on the core Perl source tree. ActiveState and many other people put a lot of time into merging the core Perl and Win32 branches, and I doubt they are going to allow a split to occur!
Slashdot Mirror
PatPending,
Thanks for collecting the errata. Could you post it to the errata page? That way, it will go through "the system" (we'll forward it to Paul, he's say yea or nay, and the changes will make their way into a future reprint).
Poor Spyro...
How are you going to explain this to Uncle Owen?
Eben Moglen, general counsel to the FSF, gave the DotGNU project his opinion on the Shared Source license and tainting.
- Brian
> If you want to do real open source,
> do not look at the poison.
Eben Moglen, General Counsel to the Free Software Foundation, told the DotGNU project that programmers will not be tainted by reading the source, so long as they don't copy any of the code.
- Brian
- An Architectural Tour of Rotor
- Get Your Rotor Running
- Microsoft's Shared Source Record
- BrianPlus, the runtime won't even let you run unsafe mobile code. Here's what happens when I try to run foo.exe (compiled with /unsafe) from a network share:
Unhandled Exception:
System.Security.Policy.PolicyException: Required
permissions cannot be acquired.
Have a look at tinySQL - it's open source (LGPL), and 100% Java. It is an extensible SQL engine that has a JDBC driver. It started out life as a quick hack, but it's improved significantly thanks to the contributions of others. The most recent version is usually available in CVS, but there is a fairly recent tarball and jar file up there.
Enjoy,
Brian
The IL (is this different from MSIL?) instruction set seems to be documented in Part 3 of the C# and Common Language Infrastructure draft standard .
:-)
At first glance, it looks pretty detailed - I guess we won't know if it's detailed enough to implement the CLR on Linux until someone tries it
Jon Udell's December 18th column addresses the issue you raised, questioning whether it is in Sun's best interest to keep the language and the JVM tightly coupled. The column includes a survey of some of the people who have implemented languages for the JVM.
--
Brian Jepson
sohp wrote:
Thanks for clarifying that - if I had thought more about what I was writing in my original post, I would have realized I was blowing swamp gas... I guess I had trouble making the context switch from Java to Perl (and back again?).
CPAN, the Comprehensive Perl Archive Network, was modeled after CTAN (the Comprehensive TeX Archive Network), and is highly successful. I think that CPAN is one of the primary reasons that Perl itself is so successful. It would be a good thing for Java to have something that is modeled after CPAN.
One of CPAN's key features is that its structure encourages collaboration - there is a group that ensures new modules are put into appropriate namespaces, so if a bunch of people want to work on stuff about XML, this group will make sure they choose an appropriate namespace (probably XML::something).
Java, on the other hand, has a naming convention that I feel discourages cooperation. For example, on CPAN, take two modules such as XML::XPath and XML::Writer. It's clear that these packages were meant to work together, and in theory, they could share some package-specific data (maybe they do, maybe they don't - the point is, they could, if it was necessary to fulfill the mission of the XML:: package).
If these same authors had written these modules for Java, and if they had followed the Java naming conventions, the modules would be called org.sergeant.xml.XPath and com.megginson.xml.Writer. This makes it difficult for them to share package-scoped data, and also makes it less clear that they are meant to work together.
As I remember it, some of the folks at ActiveState worked at Hip Communications, the company that did a lot of the original Perl for Win32 work. Guess who provided some of the initial investment to jump-start that port of Perl 5 to Win32? Microsoft.
The last time Microsoft was involved with Perl, the Perl for Win32 port was not in the core Perl distribution. It would have been easy to morph it into WinPerl or VisualPerl or who knows what.
But the truth is, Microsoft didn't hijack it back then. Even if they had intentions to do so now, I think it would very difficult given that ActiveState's distribution is based on the core Perl source tree. ActiveState and many other people put a lot of time into merging the core Perl and Win32 branches, and I doubt they are going to allow a split to occur!