The meaning of a program should be clear and unambiguous to the reader, and not require you to do a lot of pattern matching and apply a bunch of rules and heuristics to understand what it means. Most copies of the K&R C manual fall open to the same page: the table of operator precedence. That shows that the skyscraper of precedence rules was a mistake in the design of the language, but Perl takes that idea and runs with it, in many different directions!
That example of how Perl 6 is fucked is that "print (1+2)+3" will not be the same as "print(1+2) + 3". That's MUCH more confusing and unexpected than Python or almost any other language! The white space that Python requires simply makes the program clearer and easier to read, but Perl's astonishingly arbitrary parsing heuristics make it extremely difficult to understand, and horribly easy to make dreadful mistakes.
Yet you leap to defend Perl 6's bizarre and unexpected interpretation of white space as if it were a benefit??! With a spin like that, you should apply for Scott McClellan's job. Are you just one of those slackers who loves Perl because of its deep flaws, due to the job security it gives you? That's a BAD long term plan.
PS: In case you're like one of the people working on Parrot who take jokes much too seriously and can't detect sarcasm, my previous message about C++ Generalized White Space Overloading was a joke, and the publication date of that Generalized Overloading for C++2000 proposal (which was really written by Bjarne Stroustrup), was April 1.
With an attitude like that, I'll bet C++ would really appeal to you, too -- you should definitely check it out! Why wait for Perl 6 when you can start learning C++ today!!! C++ has just as many cool buzzwords as Perl, and it tries to go down even more dead-end paths at once! You'll just love operator overloading and templates, and you'll want to use all its advanced features at once in every program you write! But if you don't have time to learn C++, then why not adapt its best ideas to Perl?
You'll really be amazed by Bjarne Stroustrup's brilliant extension to C++: "Generalized Overloading for C++2000", and I'm sure you'll want to delay the release of Perl 6 some more until all these cool features can be appropriated and hacked into the Parrot VM.
Here are some of the most amazing features of Generalized Overloading in C++2000, that you will never be able to live without, once you've tried them:
With the acceptance of the ISO C++ standard, the time has come to consider new directions for the C++
language and to revise the facilities already provided to make them more complete and consistent.
A good example of a current facility that can be generalized into something much more powerful and
useful is overloading. The aim of overloading is to accurately reflect the notations used in application
areas. For example, overloading of + and * allows us to use the conventional notation for arithmetic
operations for a variety of data types such as integers, floating point numbers (for built-in types), complex
numbers, and infinite precision numbers (user-defined types). This existing C++ facility can be
generalized to handle user-defined operators and overloaded whitespace.
[...] Here, I describe the more innovative and powerful mechanism for overloading whitespace. Consider x*y.
In programming languages (e.g. Fortran, Pascal, and C++), this is the conventional notation for
multiplying two values. However, mathematicians and physicists traditionally do not use the operator *.
Instead they use simple juxtaposition to indicate multiplication. That is, for variables x and y of suitable
types,
x y
means multiply x by y.
[...] Overloading Separate Forms of Whitespace
There are of course several forms of whitespace, such as space, tab,// comments, and/* */ comments. A
comment is considered a single whitespace character. For example,
/* this comment is considered a single character
for overloading purposes
*/
It was soon discovered that it was essential to be able to overload the different forms of whitespace
differently. For example, several heavy users of whitespace overloading found overloading of newline
('\n'), tab ('\t'), and comments as the same arithmetic operator is counterintuitive and error prone.
Consider:
double z1 = x y;// obvious
double z2 = x
y;// obscure
double z3 = x/* asking for trouble */ y;
In addition, different overloading of different whitespace characters can be used to mirror conventional
two-dimensional layout of computations (see below).
Stavtrup claimed that it was important to distinguish between different number of adjacent whitespace
characters, but we did not find that mechanism useful. In fact, we determined it to be error-prone and
omitted for Standard C++.
Overloading Missing Whitespace
After some experimentation, it was discovered that the overloading mechanism described so far did not go
far enough. When using the mechanism, the physicists tended to omit the space character and write
xy
rather than
x y
This problem persisted even after the overloading rules had been clearly and repeatedly explained. What
was needed wasn't just the ability to overload explicit use of whitespace, but also implicit application. This
is easily ach
Of course it's easy to compare Perl to a lame language like PHP, but how is Perl any better than real languages like Python, Ruby or Lisp, which make it much easier to learn, maintain, read and reuse code written by other people?
Ian Bicking weighs in on the relative relative power of Ruby and Python, and makes some interesting observations about "Parrot":
I think Ruby on the Parrot VM works better than Python. But, AFAIK, no real language runs on Parrot at this point (even Perl, for which Parrot was written), it's all experiments. I honestly want Parrot to succede; it's currently the only real effort at a community-driven VM, and the only VM written specifically for dynamic languages. But for some reason they can't get their act together.
I would love if Parrot created an environment where Python, Ruby, Perl, PHP, and other open source languages happily coexisted and shared a basic infrastructure. It doesn't have to mean 100% transparency between languages for it to be useful and successful. But at this point it's hard for me to believe Parrot will catch up to other competing runtime environments.
Parrot was a joke, and still is. If the Parrot developers really understood what they were doing, then they wouldn't be trying to do it that way. It's just a sophmoric exercise in mental masturbation. So it's no wonder that the Parrot project is dead in the water, pushing up daisies!
Osty, you have poor reading comprehension. You're attacking exactly the opposite of what I was saying. Go back and read my message you're replying to more carefully, and while you're at it, read the article and watch the video so you'll be more qualified to participate in the discussion.
My point is that SQLObject does insulate you from SQL injection attacks and database dependencies, in ways that Ruby's ActiveRecord does not.
Of course you're ignoring the problem of database portability, because the hammer you want to attack all problems with seems to be stored procedures. If the goals are database portability and database application programming with a scripting language like Python or Ruby, then your hammer breaks the original goals, so it's the wrong hammer. I want to integrate my existing Python code with the database, not rewrite it all as stored procedures -- that would make no sense whatsoever. If I wanted somebody to tell me to write database dependent code, lock myself into the biggest database with the most features, and give up my scripting language of choice, then I'd call Oracle, bend over, and do exactly what they told me. But I'm not that massochistic.
Here is a typical snippet of Ruby/ActiveRecord code, and you can clearly see that it has SQL code written in as quoted strings (sorry about the indentation -- slashdot is now ignoring nbsp's as well as pre's, which makes it hard to discuss code):
def self.authenticate(login, pass)
find_first(["login = ? AND password = ?", login, sha1(pass)])
end
Here is the equivalent Python/SQLObject code, which you can see uses Python syntax to accomplish the same thing, without quoting any SQL code at all:
This is accomplished with the "SQLBuilder" utility, that lets you write python expressions like "AND(person.q.first_name == 'John', person.q.last_name == 'Doe')" instead of raw SQL expressions like "(person.first_name = 'John' AND person.last_name = 'Doe')".
SQLObject also supports methods called "startswith()" and "endswith()" and a function called "LIKE", which insulate you from the differences between SQL "LIKE" syntaxes, so you can portably write "User.q.firstName.startswith('X')" instead of "User.firstName LIKE 'X%'".
Of course the 15 minute Ruby on Rails demo didn't get deep enough into programming a complex web application, that they had to show you any of the SQL dependencies and other warts of Ruby on Rails. They're evangelizing, not airing dirty laundry -- what do you expect?
SQLObject and ActiveRecord are based on a lot of the same ideas (Martin Fowler's Active Record model), but SQLObject is also different than ActiveRecord in many ways. Ben Bangert's compares SQLObject and ActiveRecord in his talk, "Presentation on SQLObject & FormEncode", that he gave at the Bay Area Python users group.
SQLObject is a pure ORM (Object-Relational Mapper), while ActiveRecord is a full fledged Model (as in MVC). Both SQLObject and ActiveRecord let you automatically read in an existing database schema. But SQLObject also lets you define the schema in Python and automatically generates the tables (for any database) from the Python declarations -- it works either way! SQLObject also supports runtime column changes, so it can be used to implement dynamic database schema editors.
One of the nicest features of SQLObject is that it insulates you from the peculiararities of the database's SQL syntax, so you don't need to put any SQL code directly into the Python code (but you can if you need to for efficiency or if you're willing to write non-portable code).
The SQL database abstraction layer is an important feature of SQLObject, that Ruby on Rails doesn't currently support -- you have to write database dependent SQL code mixed in with your Ruby code.
SQLObject lets you write generic SQL queries with normal Pythonic expressions and operators, which are automatically translated into the database dependent SQL syntax by the database driver. So you don't have to change any of your Python code to port it to a different database, and you don't have to mix together two different notations, or quote a bunch of SQL strings in your Python code. It's a much more "pythonic" way of database programming than raw SQL.
The great thing is that it's so convenient and the syntax is so simple, that you can use the interactive Python shell to browse and test out and edit your database. It's trivial enough to type in some Python code on the keyboard that loops over the results of a query, performs some complex logic, and validates and edits a bunch of rows in the database. Much more powerful and easier to use than anything you can do with raw SQL.
The idea of a garbage collector for C has been around for a lot longer than 11 years.
Hans-Juergen Boehm and Mark Weiser, "Garbage collection in an uncooperative environment", Software Practice and Experience, 18, 807-820 (1988).
"Weiser experimented with a special version of the collector for
tracing storage leaks; typically, the collector does a better job than
programmers."
Here's an even earlier reference from 1984 to a garbage collector for C, in a paper by Bjarne Stroustrup.
Newsgroups: net.lang.c
From: mark@umcp-cs.UUCP
Date: Sat, 2-Jun-84 21:37:41 EDT
Local: Sat, Jun 2 1984 6:37 pm
Subject: garbage collection in C
A footnote on page 11 of the AT&T Bell Labs Memo 109 entitled
Data Abstraction in C, by Bjarne Stroustrup, says that a garbage
collector version of the malloc function exists. Any one else
ever heard of this? Know where I can get one?
--
Spoken: Mark Weiser ARPA: mark@maryland
CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!mark
Pandora uses about 400 different qualities to categorize music, so it's inaccurate to characterize it as "very high level song characteristics such as genre".
How many dimensions does Memotrax use to classify music? Do they just dump all the music into the computer and let it classify it automatically without any people listening to it, or do they actually pay people to listen to the music and classify it manually, like Pandora does?
Memotrax web site says "We combine leading research in artificial intelligence, music information retrieval, and machine learning to transform your collection of music so that it can dynamically reorder itself and automatically play music according to your preferences."
Sounds like a pure AI play to me, and I don't think AI is advanced enough to do as good a job at classifying music, as people can do.
The next step would be to come up with intelligent software (and package it in a nicely designed piece of plastic hardware) that could automatically listen to and enjoy all the music being automatically generated and classified by other computers!
Hook it up with the Wolfram Tones cellular automata music generator, and you'd have an infinite supply of original, categorized digital music, seamlessly integrated with a receptive digital audience! All it needs is an automatic applause generator that feeds back to the synthetic musicians, and you could carry a completely functional simulated music industry in your pocket! Then you could listen to millions of songs at once, in blissful silence.
The Digital Music Listener could be packaged up like a black iPod, that jacked into a white iPod, and they would silently play music to each other.
You're right! Why stop at parody? It should also be able to search for irony, stupidity, metaphores, cultural references, popular misinterpretations of lyrics, and sarcasm!
Seriously: Sure, I'd like a talking pony too, but the point (and the reason it works) is that Pandora is based on well defined musical simlarities, not subjective interpretation of the lyrics.
Try typing in the title of a Weird Al song, an see if it eventually comes up with the original song that it's a parody of!
Except that Dr. Steve doesn't pay a staff of trained musicians to listen to each of the 1.0e+42 machine generated ring tones and score each of them on 400 characteristics, like Pandora does. Just the opposite. When you generate a piece of Wolframic cellular automata music, the odds are astronomically likely that you're the first person in the universe to ever hear that tune.
Pandora works in a completely different way than Amazon recommendations. Amazon is based on the buying patterns of Amazon customers, while Pandora is actually based on the qualities of the music itself, not the behaviors of the people who buy it.
Language design is like the opposite to mountain climbing:
Q: Why design a new language?
A: Because it isn't there yet.
We wouldn't have Python if people took your "why design a new language" argument seriously. Language design would have stopped years ago, with that parochial attitude.
Peaker, carefully read what "sickofthisshit" wrote about Lisp macros -- he hit the nail on the head: they're extremely important and Python suffers from not supporting them.
You are dead wrong about there being few cases where domain specific languages are useful.
I love Python and I write a lot of code in it, but the one big thing it's missing is macros. You can't just strap a decent macro system onto Python (or Java), because of Python's non-lisp-like syntax. Sure, Python has a parse tree api, but seriously, have you ever actually taken a look at it?!? It's *HORRIBLY* low level and totally inappropriate to implement a macro system with.
Lisp's parenthesis are just as easy to get used to as Python's indentation.
There's nothing unreadable about Lisp syntax, unless you simply don't know the language, in which case you're not qualified to criticize it.
Sure, Python is great for whacking off web servers, but as you point out, it's not compiled, it's interpreted by its very design (which is why you seem to think that evaluating strings is as powerful as macros). You don't seem to get how important it is that Lisp code can be efficiently compiled, and that the programmer can deeply extend the compiler and tailor the language with macros.
How ironic that they released the LispM sources under a BSD-like license instead of GPL.
Here is an essay written a while ago (1986 or so) by Richard M Stallman (RMS), telling his side of the story about the MIT AI Lab, and the Lisp Machine Wars.
Many other sides of the story, less extreme than from RMS's viewpoint, are covered here and here and here and here and of course here.
There is still an institution named the MIT Artificial Intelligence Lab, and I still work there, but its old virtues are gone. It was dealt a murderous blow by a spin-off company, and this has changed its nature fundamentally and (I believe) permanently.
For years only we at the AI lab, and a few other labs, appreciated the best in software. When we spoke of the virtues of Lisp, other programmers laughed at us, though with little knowledge of what they were talking about. We ignored them and went on with our work. They said we were in an ivory tower.
Then parts of the "real world" realized that we had been right all along about Lisp. Great commercial interest in Lisp appeared. This was the beginning of the end.
The AI lab had just developed a computer called the Lisp machine, a personal computer with a large virtual address space so that it could run very large Lisp programs. Now people wanted the machine to be produced commercially so that everyone else could have them. The inventor of the Lisp machine, arch-hacker Richard Greenblatt, made plans for an unconventional "hacker company" which would grow slowly but steadily, not use hype, and be less gluttonous and ruthless than your standard American corporation. His goal was to provide an alternative way of supporting hackers and hacking, and to provide the world with Lisp machines and good software, rather than simply to maximize profits. This meant doing without most outside investment, since investors would insist on conventional methods. This company is Lisp Machines, Incorporated, generally called LMI.
Other people on the Lisp machine project believed this would not work, and criticized Greenblatt's lack of business experience. In response, Greenblatt brought in his friend Noftsker, who had left the lab for industry some years before. Noftsker was considered experienced in business. He quickly demonstrated the correctness of this impression with a most businesslike stab in the back: he and the other hackers dropped Greenblatt to form another company. Their plan was to seek large amounts of investment, grow as rapidly as possible, make a big splash, and the devil take anybody or anything drowned in it. Though the hackers would only get a small fraction of the fortunes the company planned to make, even that much would make them rich! They didn't even have to work any harder. They just had to stop cooperating with others as they had used to.
This resulted in two competing Lisp machine companies, Greenblatt's LMI and Noftsker's Symbolics (generally called "Slime" or "Bolix" around the AI lab). All the hackers of the AI lab were associated with one or the other, except me, because even LMI involved moral compromises I didn't want to make. For example, Greenblatt is against proprietary operating system software but approves of proprietary applications software; I don't want to refuse to share either kind of program.
HyperTIES is an early hypermedia browser developed under the direction of Dr. Ben Shneiderman at the University of Maryland Human Computer Interaction Lab.
HyperTIES supported browsing interactive hypermedia including formatted text and scalable PostScript graphics, including interactive software components like applets, pie menus, embedded graphical menus, text and graphics editors, etc, written in the NeWS object oriented dialect of PostScript.
The HyperTIES hypermedia browser was also integrated with an authoring tool, based on the Unipress Emacs text editor, which could remotely control the browser (so Emacs could navigate the browser and display the content you're editing), and the browser could remotely control Emacs (so you could create hypermedia interfaces with text links and graphical menus that drove Emacs).
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.
Since browsing hypertext can present a formidable cognitive challenge, user interface design plays a major role in determining acceptability. In the Unix workstation version of Hyperties, a research-oriented prototype, we focussed on design features that facilitate browsing. We first give a general overview of Hyperties and its markup language. Customizable documents can be generated by the conditional text feature that enables dynamic and selective display of text and graphics. In addition we present:
an innovative solution to link identification: pop-out graphical buttons of arbitrary shape.
application of pie menus to permit low cognitive load actions that reduce the distraction of common actions, such as page turning or window selection.
multiple window selection strategies that reduce clutter and housekeeping effort. We preferred piles-of-tiles, in which standard-sized windows were arranged in a consistent pattern on the display and actions could be done rapidly, allowing users to concentrate on the contents.
[...]
Since storyboards are text files, they can be created and edited in any text editor as well as be manipulated by UNIX facilities (spelling checkers, sort, grep, etc...). On our SUN version Unipress Emacs provides a multiple windows, menus and programming environment to author a database. Graphics tools are launched from Emacs to create or edit the graphic components and target tools are available to mark the shape of each selectable graphic element. The authoring tool checks the links and verifies the syntax of the article markup. It also allows the author to preview the database by easily following links from Emacs buffer to buffer. Author and browser can also be run concurrently for final editing.
[...] Implications of Graphics in Hypertext
Hyperties incorporates graphics while preserving the embedded menu approach used for textonly documents. A displayed page can mix text and graphics while allowing arbitrarily-shaped regions to be designated as targets, which provide links to other articles. The addition of graphics provides significant advantages (14). Information that is structured in the form of charts, graphs, maps, and images may be explored with the same facility as text. But the use of graphics in hypertext requires more work on the part of the author to produce comprehensible documents. There is no simple technique for emphasizing the targets that is acceptable in all cases, and the author
The NeWS window system was "Ajaxian" back in the 90's, but it used PostScript instead of JavaScript, PostScript instead of HTML, and PostScript instead of XML. In other words, it was PostScript based, with a much more consistent architecture than AJAX, but it used the same essential techniques like downloadable code, local interaction, asynchronous network communication, etc.
Under the direction of Ben Shneiderman, we developed the HyperTIES hypermedia browser in NeWS, which downloaded PostScript programs and data into the NeWS window system, that implemented the HyperTIES user interface and rendered the interactive hypermedia content.
As well as supporting fully scalable PostScript graphics and text, you could also embed "applets" written in PostScript on the HyperTIES page, like pie menus, text and graphics editors, and other kinds of locally interactive user interfaces that communicate asynchronously with the HyperTIES engine and Emacs based authoring tool.
Since browsing hypertext can present a formidable cognitive challenge, user interface design plays a major role in determining acceptability. In the Unix workstation version of Hyperties, a research-oriented prototype, we focussed on design features that facilitate browsing. We first give a general overview of Hyperties and its markup language. Customizable documents can be generated by the conditional text feature that enables dynamic and selective display of text and graphics. In addition we present:
an innovative solution to link identification: pop-out graphical buttons of arbitrary shape.
application of pie menus to permit low cognitive load actions that reduce the distraction of common actions, such as page turning or window selection.
multiple window selection strategies that reduce clutter and housekeeping effort. We preferred piles-of-tiles, in which standard-sized windows were arranged in a consistent pattern on the display and actions could be done rapidly, allowing users to concentrate on the contents.
Noksagt, you are wrong, and spreading some common misconceptions, which you should stop repeating.
XPCOM extensions for Firefox are compiled binary machine language files, which have just as much access to your system as ActiveX controls do. Firefox XPCOM extensions are no more secure than ActiveX controls. Binary ActiveX and XPCOM controls are useful for situations where you need to do things that JavaScript doesn't support, like shaping the window of a pie menu (an open source ActiveX component, that you can download the source code if you like).
Internet Explorer has something similar to the way you can write Firefox extensions in JavaScript and UIL. But that's a totally different thing than binary ActiveX controls and behaviors, and it severly restricts what you can do.
You can script trustable ActiveX controls for Internet Explorer called "Dynamic HTML Behavior Components", using JavaScript (or any other ActiveX compatible scripting languages), XML and DHTML.
No, Mozilla extensions are NOT inherently open source, nor are they more secure than ActiveX. We're discussing XPCOM extensions, which are compiled binaries, not JavaScript.
Yes, there is a double standard about downloading ActiveX controls and XPCOM controls.
XPCOM controls are at least as unsafe as ActiveX controls. At least ActiveX supports code signing, which XPCOM doesn't.
Open source has to do with the rights you have to use the code, not just that you can read the source code. It's certainly possible to write a browser extension or anything else in JavaScript that's not open source -- you just say in the comments "Copyright (C) 2005 by . All rights reserved." You don't even need to say that -- it's it copyright by default, but not open source by default.
Even if your point about being able to read XPCOM extension source code was factually correct, only an infintesimally small percentage of people actually even bother to read the code they download before they run it. And even if you can read it, it might be quite obfuscated and contain thousands of lines of code -- in fact the authors themselves might not even know that the code has security holes.
Take a look at the JavaScript source code to google maps, for example. Oh you haven't already read over every line of that code looking for security holes? That's exactly what I mean.
Please don't make the Raymondesque argument that open source code doesn't have security holes because everyone can read it, unless you personally read all the code you download before you run it yourself. Including the configure scripts!
Pie menus address many of the
complaints of this article, and they've been around a long time.
I'll start by comparing screen corners to pie menus:
To quote
Tog on Fitts'
Law: "The time to acquire a target is a function of the distance
to and size of the target." He points
out that "the screen edge is, for all practical purposes,
infinitely deep."
But the advantage of "screen corners" is just an indirect and wasteful
application of Fitts' Law, which pie menus exploit much more directly,
efficiently and flexibly than "screen corners". Tog's "screen corner"
argument is just an ex post facto
application of Fitts' Law: an after-the-fact rationalization, not the
reason they originally designed the menu bar that way.
If Fitts' Law was really the reason Apple designed their menu bar that way,
then why aren't there four menu bars, one at each edge of the screen?
Apple never mentioned Fitts' Law in their infamous menu bar patent.
Pie menus "slices" are better than "screen corners" or "menu
bars" because:
Screen corners and edges are static and fixed in number, so they only
enable a small fixed number of global commands at once.
Pie menus are dynamic and context sensitive, so each pie menu can have
multiple slices, with a different set of functions associated with
each, including submenus. The screen only has four corners and four
edges, but pie menus are extremely reliable with eight items, and can
support up to 12 items reliably.
Pie menus also support submenus, so you can have an infinite
combination of pie menu items, depending on the context you click on,
instead of just four screen corners or four menu bars.
Each pie menu item is easier to hit than any screen corner,
because every pie slice target area starts directly adjacent to the cursor and
extends all the way out to the screen edge, and beyond!
Screen corners and menu bars flaunt Fitts' Law by requiring you to
physically move the mouse a large distance, and they usually leave the
cursor far away from the object you're manipulating.
Pie menu target area "slices" extend all the way out to the edge of
the screen and beyond, so their area is quite large, but you don't
have to actually move all the way to the screen edge to select
them. You simply move the cursor outside of the small inactive area in
the pie menu center. Each "slice" target area starts out directly
adjacent to the cursor, in a different direction, and occupies a large
area extending out to the edge of the screen.
Fitts' Law relates the target seek time and error rate to the target
area and distance from the cursor. The bigger the target and the
closer the target, the faster the seletion and fewer errors. Pie menus
maximize the target area and minimize the target distance, so
consequently they minimize both the speed and error rate, as Fitts'
Law predicts.
Screen corners are worse than pie menus, because they actually
have smaller target areas than pie menu slices, and actually maximize
the distance from the cursor by putting the target as far away from
the cursor as possible.
Tog claims the screen edge target area is "infinitely deep", but in
practice you never move the cursor an infinite distanc
Yes they do need SEED. No they are not going to switch the entire country of Korea over to SSL and reissue millions of certificates this afternoon because some Firefox evangelist who still lives with his mom thinks they should.
The very idea of building a SOAP bridge or an AJAX service to talk to an encryption library is INSANE! Next you kids are going to want to invent a way to use/dev/null via NFS!
The whole point of using a native ActiveX or XPCOM DLL is so you don't have to send your password over the network unencrypted. So why would you use an unencrypted SOAP network service to encrypt data you didn't want to send over the net? What bank in their right mind would do that?
The AJAXian alternative would be to implement the SEED encryption algorithm in JavaScript, and run it in the browser. That's certainly possible, but quite impractical.
If Firefox supported ActiveX as a user option, then there would be no need for a special XPCOM plug-in, and Korean users would have been able to do their banking in Firefox using the ActiveX control that has existed for years now.
ActiveX is just as secure as XPCOM, so why doesn't Firefox support it too? Seems like there's a double standard here.
Menlo Park, CA. 10 January 2001 -- The Open Group has just released COMsource version 1.1, an enhanced version of the existing version, COMsource 1.0. COMsource is an open systems implementation of Microsoft's Component Object Model (COM) middleware developed for the Windows TM platform that extends the COM middleware infrastructure to UNIX TM. COMsource also allows independent software vendors to easily port their COM applications to non-Microsoft platforms. COMsource 1.0, released in September 1999, provides an object-based, distributed programming model that allows two or more applications, or application components, to easily interact and interoperate. COMsource 1.1 has a number of added features and benefits, including:
Updated to run on Solaris 2.6
Added support for the latest versions of NT and Windows 2000. COMsource is now compatible with NT 4.0 Service Packs 4, 5 and 6 and Windows 2000
Maintenance updates for build and runtime issues; enhancements to error handling to enable passing of rich error information between servers and clients on various platforms
The reference implementations include source code, an interoperability test suite and the reference documentation set. COMsource 1.1 also now has a Support & Maintenance Service offering, which consists of:
Consultation on using, building, installing and porting COMsource
Problem isolation and tracking
Critical problem escalation
Development of code fixes or workarounds for defects
For more information on COMsource 1.1, please visit www.opengroup.org/comsource
Slashdot Mirror
Bad job avoiding the point. Read the post by Ian Bicking discussing how Guile relates to Parrot.
Those who ignore history are bla bla bla...
-Don
The Gnu kernel is being actively developed, and has bla bla bla...
Why aren't you just extending Guile, which has been declared the official GNU scripting langauge by none other than RMS himself.
Tom Lord discusses the history of Guile, in the context of the great TCL war, which happened just before Java came onto the scene.
Ian Bicking discusses some of the reasons why Guile failed to gain any traction.
-Don
The meaning of a program should be clear and unambiguous to the reader, and not require you to do a lot of pattern matching and apply a bunch of rules and heuristics to understand what it means. Most copies of the K&R C manual fall open to the same page: the table of operator precedence. That shows that the skyscraper of precedence rules was a mistake in the design of the language, but Perl takes that idea and runs with it, in many different directions!
That example of how Perl 6 is fucked is that "print (1+2)+3" will not be the same as "print(1+2) + 3". That's MUCH more confusing and unexpected than Python or almost any other language! The white space that Python requires simply makes the program clearer and easier to read, but Perl's astonishingly arbitrary parsing heuristics make it extremely difficult to understand, and horribly easy to make dreadful mistakes.
Yet you leap to defend Perl 6's bizarre and unexpected interpretation of white space as if it were a benefit??! With a spin like that, you should apply for Scott McClellan's job. Are you just one of those slackers who loves Perl because of its deep flaws, due to the job security it gives you? That's a BAD long term plan.
PS: In case you're like one of the people working on Parrot who take jokes much too seriously and can't detect sarcasm, my previous message about C++ Generalized White Space Overloading was a joke, and the publication date of that Generalized Overloading for C++2000 proposal (which was really written by Bjarne Stroustrup), was April 1.
-Don
With an attitude like that, I'll bet C++ would really appeal to you, too -- you should definitely check it out! Why wait for Perl 6 when you can start learning C++ today!!! C++ has just as many cool buzzwords as Perl, and it tries to go down even more dead-end paths at once! You'll just love operator overloading and templates, and you'll want to use all its advanced features at once in every program you write! But if you don't have time to learn C++, then why not adapt its best ideas to Perl?
You'll really be amazed by Bjarne Stroustrup's brilliant extension to C++: "Generalized Overloading for C++2000", and I'm sure you'll want to delay the release of Perl 6 some more until all these cool features can be appropriated and hacked into the Parrot VM.
Here are some of the most amazing features of Generalized Overloading in C++2000, that you will never be able to live without, once you've tried them:
Of course it's easy to compare Perl to a lame language like PHP, but how is Perl any better than real languages like Python, Ruby or Lisp, which make it much easier to learn, maintain, read and reuse code written by other people?
It's easy to do all that you require in Python by integrating existing modules: imaplib IMAP4 protocol client module, Integrating Python and MS Excel, pyExcelerator library for generating and importing Excel files, Python Midi Package for handling MIDI input and output.
-Don
CPAN is a turd wrapped in aluminum foil, not a silver bullet.
-Don
Ian Bicking weighs in on the relative relative power of Ruby and Python, and makes some interesting observations about "Parrot":
Parrot was a joke, and still is. If the Parrot developers really understood what they were doing, then they wouldn't be trying to do it that way. It's just a sophmoric exercise in mental masturbation. So it's no wonder that the Parrot project is dead in the water, pushing up daisies!
-Don
Osty, you have poor reading comprehension. You're attacking exactly the opposite of what I was saying. Go back and read my message you're replying to more carefully, and while you're at it, read the article and watch the video so you'll be more qualified to participate in the discussion.
My point is that SQLObject does insulate you from SQL injection attacks and database dependencies, in ways that Ruby's ActiveRecord does not.
Of course you're ignoring the problem of database portability, because the hammer you want to attack all problems with seems to be stored procedures. If the goals are database portability and database application programming with a scripting language like Python or Ruby, then your hammer breaks the original goals, so it's the wrong hammer. I want to integrate my existing Python code with the database, not rewrite it all as stored procedures -- that would make no sense whatsoever. If I wanted somebody to tell me to write database dependent code, lock myself into the biggest database with the most features, and give up my scripting language of choice, then I'd call Oracle, bend over, and do exactly what they told me. But I'm not that massochistic.
Here is a typical snippet of Ruby/ActiveRecord code, and you can clearly see that it has SQL code written in as quoted strings (sorry about the indentation -- slashdot is now ignoring nbsp's as well as pre's, which makes it hard to discuss code):
def self.authenticate(login, pass)
find_first(["login = ? AND password = ?", login, sha1(pass)])
end
Here is the equivalent Python/SQLObject code, which you can see uses Python syntax to accomplish the same thing, without quoting any SQL code at all:
def authenticate(self, login, pass):
return User.select(AND(User.q.login == login, User.q.password == sha1(pass)))[0]
This is accomplished with the "SQLBuilder" utility, that lets you write python expressions like "AND(person.q.first_name == 'John', person.q.last_name == 'Doe')" instead of raw SQL expressions like "(person.first_name = 'John' AND person.last_name = 'Doe')".
SQLObject also supports methods called "startswith()" and "endswith()" and a function called "LIKE", which insulate you from the differences between SQL "LIKE" syntaxes, so you can portably write "User.q.firstName.startswith('X')" instead of "User.firstName LIKE 'X%'".
Of course the 15 minute Ruby on Rails demo didn't get deep enough into programming a complex web application, that they had to show you any of the SQL dependencies and other warts of Ruby on Rails. They're evangelizing, not airing dirty laundry -- what do you expect?
SQLObject and ActiveRecord are based on a lot of the same ideas (Martin Fowler's Active Record model), but SQLObject is also different than ActiveRecord in many ways. Ben Bangert's compares SQLObject and ActiveRecord in his talk, "Presentation on SQLObject & FormEncode", that he gave at the Bay Area Python users group.
SQLObject is a pure ORM (Object-Relational Mapper), while ActiveRecord is a full fledged Model (as in MVC). Both SQLObject and ActiveRecord let you automatically read in an existing database schema. But SQLObject also lets you define the schema in Python and automatically generates the tables (for any database) from the Python declarations -- it works either way! SQLObject also supports runtime column changes, so it can be used to implement dynamic database schema editors.
-Don
One of the nicest features of SQLObject is that it insulates you from the peculiararities of the database's SQL syntax, so you don't need to put any SQL code directly into the Python code (but you can if you need to for efficiency or if you're willing to write non-portable code).
The SQL database abstraction layer is an important feature of SQLObject, that Ruby on Rails doesn't currently support -- you have to write database dependent SQL code mixed in with your Ruby code.
SQLObject lets you write generic SQL queries with normal Pythonic expressions and operators, which are automatically translated into the database dependent SQL syntax by the database driver. So you don't have to change any of your Python code to port it to a different database, and you don't have to mix together two different notations, or quote a bunch of SQL strings in your Python code. It's a much more "pythonic" way of database programming than raw SQL.
The great thing is that it's so convenient and the syntax is so simple, that you can use the interactive Python shell to browse and test out and edit your database. It's trivial enough to type in some Python code on the keyboard that loops over the results of a query, performs some complex logic, and validates and edits a bunch of rows in the database. Much more powerful and easier to use than anything you can do with raw SQL.
-Don
The idea of a garbage collector for C has been around for a lot longer than 11 years.
Hans-Juergen Boehm and Mark Weiser, "Garbage collection in an uncooperative environment", Software Practice and Experience, 18, 807-820 (1988).
"Weiser experimented with a special version of the collector for tracing storage leaks; typically, the collector does a better job than programmers."
Here's an even earlier reference from 1984 to a garbage collector for C, in a paper by Bjarne Stroustrup.
Newsgroups: net.lang.c
From: mark@umcp-cs.UUCP
Date: Sat, 2-Jun-84 21:37:41 EDT
Local: Sat, Jun 2 1984 6:37 pm
Subject: garbage collection in C
A footnote on page 11 of the AT&T Bell Labs Memo 109 entitled Data Abstraction in C, by Bjarne Stroustrup, says that a garbage collector version of the malloc function exists. Any one else ever heard of this? Know where I can get one?
--
Spoken: Mark Weiser ARPA: mark@maryland
CSNet: mark@umcp-cs UUCP: {seismo,allegra}!umcp-cs!mark
-Don
How many dimensions does Memotrax use to classify music? Do they just dump all the music into the computer and let it classify it automatically without any people listening to it, or do they actually pay people to listen to the music and classify it manually, like Pandora does?
Memotrax web site says "We combine leading research in artificial intelligence, music information retrieval, and machine learning to transform your collection of music so that it can dynamically reorder itself and automatically play music according to your preferences."
Sounds like a pure AI play to me, and I don't think AI is advanced enough to do as good a job at classifying music, as people can do.
-Don
Hook it up with the Wolfram Tones cellular automata music generator, and you'd have an infinite supply of original, categorized digital music, seamlessly integrated with a receptive digital audience! All it needs is an automatic applause generator that feeds back to the synthetic musicians, and you could carry a completely functional simulated music industry in your pocket! Then you could listen to millions of songs at once, in blissful silence.
The Digital Music Listener could be packaged up like a black iPod, that jacked into a white iPod, and they would silently play music to each other.
-Don
Seriously: Sure, I'd like a talking pony too, but the point (and the reason it works) is that Pandora is based on well defined musical simlarities, not subjective interpretation of the lyrics.
Try typing in the title of a Weird Al song, an see if it eventually comes up with the original song that it's a parody of!
-Don
-Don
-Don
Language design is like the opposite to mountain climbing:
Q: Why design a new language?
A: Because it isn't there yet.
We wouldn't have Python if people took your "why design a new language" argument seriously. Language design would have stopped years ago, with that parochial attitude.
Peaker, carefully read what "sickofthisshit" wrote about Lisp macros -- he hit the nail on the head: they're extremely important and Python suffers from not supporting them.
You are dead wrong about there being few cases where domain specific languages are useful.
I love Python and I write a lot of code in it, but the one big thing it's missing is macros. You can't just strap a decent macro system onto Python (or Java), because of Python's non-lisp-like syntax. Sure, Python has a parse tree api, but seriously, have you ever actually taken a look at it?!? It's *HORRIBLY* low level and totally inappropriate to implement a macro system with.
Lisp's parenthesis are just as easy to get used to as Python's indentation. There's nothing unreadable about Lisp syntax, unless you simply don't know the language, in which case you're not qualified to criticize it.
Sure, Python is great for whacking off web servers, but as you point out, it's not compiled, it's interpreted by its very design (which is why you seem to think that evaluating strings is as powerful as macros). You don't seem to get how important it is that Lisp code can be efficiently compiled, and that the programmer can deeply extend the compiler and tailor the language with macros.
-Don
How ironic that they released the LispM sources under a BSD-like license instead of GPL.
Here is an essay written a while ago (1986 or so) by Richard M Stallman (RMS), telling his side of the story about the MIT AI Lab, and the Lisp Machine Wars.
Many other sides of the story, less extreme than from RMS's viewpoint, are covered here and here and here and here and of course here.
Machine Room Folk Dance, Thursday at 8pm. Come Celebrate the Joy of Programming, with the World's Most Unbureaucratic Computers. (There were only five of us dancing, but we had a good time.)
[...] The Lab Betrayed
There is still an institution named the MIT Artificial Intelligence Lab, and I still work there, but its old virtues are gone. It was dealt a murderous blow by a spin-off company, and this has changed its nature fundamentally and (I believe) permanently.
For years only we at the AI lab, and a few other labs, appreciated the best in software. When we spoke of the virtues of Lisp, other programmers laughed at us, though with little knowledge of what they were talking about. We ignored them and went on with our work. They said we were in an ivory tower.
Then parts of the "real world" realized that we had been right all along about Lisp. Great commercial interest in Lisp appeared. This was the beginning of the end.
The AI lab had just developed a computer called the Lisp machine, a personal computer with a large virtual address space so that it could run very large Lisp programs. Now people wanted the machine to be produced commercially so that everyone else could have them. The inventor of the Lisp machine, arch-hacker Richard Greenblatt, made plans for an unconventional "hacker company" which would grow slowly but steadily, not use hype, and be less gluttonous and ruthless than your standard American corporation. His goal was to provide an alternative way of supporting hackers and hacking, and to provide the world with Lisp machines and good software, rather than simply to maximize profits. This meant doing without most outside investment, since investors would insist on conventional methods. This company is Lisp Machines, Incorporated, generally called LMI.
Other people on the Lisp machine project believed this would not work, and criticized Greenblatt's lack of business experience. In response, Greenblatt brought in his friend Noftsker, who had left the lab for industry some years before. Noftsker was considered experienced in business. He quickly demonstrated the correctness of this impression with a most businesslike stab in the back: he and the other hackers dropped Greenblatt to form another company. Their plan was to seek large amounts of investment, grow as rapidly as possible, make a big splash, and the devil take anybody or anything drowned in it. Though the hackers would only get a small fraction of the fortunes the company planned to make, even that much would make them rich! They didn't even have to work any harder. They just had to stop cooperating with others as they had used to.
This resulted in two competing Lisp machine companies, Greenblatt's LMI and Noftsker's Symbolics (generally called "Slime" or "Bolix" around the AI lab). All the hackers of the AI lab were associated with one or the other, except me, because even LMI involved moral compromises I didn't want to make. For example, Greenblatt is against proprietary operating system software but approves of proprietary applications software; I don't want to refuse to share either kind of program.
I strongly suspect that the destruct
HyperTIES is an early hypermedia browser developed under the direction of Dr. Ben Shneiderman at the University of Maryland Human Computer Interaction Lab.
HyperTIES supported browsing interactive hypermedia including formatted text and scalable PostScript graphics, including interactive software components like applets, pie menus, embedded graphical menus, text and graphics editors, etc, written in the NeWS object oriented dialect of PostScript.
The HyperTIES hypermedia browser was also integrated with an authoring tool, based on the Unipress Emacs text editor, which could remotely control the browser (so Emacs could navigate the browser and display the content you're editing), and the browser could remotely control Emacs (so you could create hypermedia interfaces with text links and graphical menus that drove Emacs).
Illustration: HyperTIES Browser (right) and UniPress Emacs Multi Window Text Editor Authoring Tool (left), tab windows and pie menus, running under the NeWS Window System.
Illustration: HyperTIES Browser NeWS Client/Server Software Architecture.
Paper: Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.
Since browsing hypertext can present a formidable cognitive challenge, user interface design plays a major role in determining acceptability. In the Unix workstation version of Hyperties, a research-oriented prototype, we focussed on design features that facilitate browsing. We first give a general overview of Hyperties and its markup language. Customizable documents can be generated by the conditional text feature that enables dynamic and selective display of text and graphics. In addition we present:
[...] Since storyboards are text files, they can be created and edited in any text editor as well as be manipulated by UNIX facilities (spelling checkers, sort, grep, etc...). On our SUN version Unipress Emacs provides a multiple windows, menus and programming environment to author a database. Graphics tools are launched from Emacs to create or edit the graphic components and target tools are available to mark the shape of each selectable graphic element. The authoring tool checks the links and verifies the syntax of the article markup. It also allows the author to preview the database by easily following links from Emacs buffer to buffer. Author and browser can also be run concurrently for final editing.
[...] Implications of Graphics in Hypertext
Hyperties incorporates graphics while preserving the embedded menu approach used for textonly documents. A displayed page can mix text and graphics while allowing arbitrarily-shaped regions to be designated as targets, which provide links to other articles. The addition of graphics provides significant advantages (14). Information that is structured in the form of charts, graphs, maps, and images may be explored with the same facility as text. But the use of graphics in hypertext requires more work on the part of the author to produce comprehensible documents. There is no simple technique for emphasizing the targets that is acceptable in all cases, and the author
The NeWS window system was "Ajaxian" back in the 90's, but it used PostScript instead of JavaScript, PostScript instead of HTML, and PostScript instead of XML. In other words, it was PostScript based, with a much more consistent architecture than AJAX, but it used the same essential techniques like downloadable code, local interaction, asynchronous network communication, etc.
Under the direction of Ben Shneiderman, we developed the HyperTIES hypermedia browser in NeWS, which downloaded PostScript programs and data into the NeWS window system, that implemented the HyperTIES user interface and rendered the interactive hypermedia content.
As well as supporting fully scalable PostScript graphics and text, you could also embed "applets" written in PostScript on the HyperTIES page, like pie menus, text and graphics editors, and other kinds of locally interactive user interfaces that communicate asynchronously with the HyperTIES engine and Emacs based authoring tool.
HyperTIES is described in the paper "Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser, by Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland.
-DonXPCOM extensions for Firefox are compiled binary machine language files, which have just as much access to your system as ActiveX controls do. Firefox XPCOM extensions are no more secure than ActiveX controls. Binary ActiveX and XPCOM controls are useful for situations where you need to do things that JavaScript doesn't support, like shaping the window of a pie menu (an open source ActiveX component, that you can download the source code if you like).
Internet Explorer has something similar to the way you can write Firefox extensions in JavaScript and UIL. But that's a totally different thing than binary ActiveX controls and behaviors, and it severly restricts what you can do.
You can script trustable ActiveX controls for Internet Explorer called "Dynamic HTML Behavior Components", using JavaScript (or any other ActiveX compatible scripting languages), XML and DHTML.
For example, user interface components like JavaScript Pie Menus for Internet Explorer or the Run On Sentence dynamic text animation style run with the same restrictions as JavaScript in the browser, so they can't access files or shape popup windows. (Also open source).
-Don
Yes, there is a double standard about downloading ActiveX controls and XPCOM controls. XPCOM controls are at least as unsafe as ActiveX controls. At least ActiveX supports code signing, which XPCOM doesn't.
Open source has to do with the rights you have to use the code, not just that you can read the source code. It's certainly possible to write a browser extension or anything else in JavaScript that's not open source -- you just say in the comments "Copyright (C) 2005 by . All rights reserved." You don't even need to say that -- it's it copyright by default, but not open source by default.
Even if your point about being able to read XPCOM extension source code was factually correct, only an infintesimally small percentage of people actually even bother to read the code they download before they run it. And even if you can read it, it might be quite obfuscated and contain thousands of lines of code -- in fact the authors themselves might not even know that the code has security holes.
Take a look at the JavaScript source code to google maps, for example. Oh you haven't already read over every line of that code looking for security holes? That's exactly what I mean.
Please don't make the Raymondesque argument that open source code doesn't have security holes because everyone can read it, unless you personally read all the code you download before you run it yourself. Including the configure scripts!
-Don
I'll start by comparing screen corners to pie menus:
To quote Tog on Fitts' Law: "The time to acquire a target is a function of the distance to and size of the target." He points out that "the screen edge is, for all practical purposes, infinitely deep."
But the advantage of "screen corners" is just an indirect and wasteful application of Fitts' Law, which pie menus exploit much more directly, efficiently and flexibly than "screen corners". Tog's "screen corner" argument is just an ex post facto application of Fitts' Law: an after-the-fact rationalization, not the reason they originally designed the menu bar that way. If Fitts' Law was really the reason Apple designed their menu bar that way, then why aren't there four menu bars, one at each edge of the screen? Apple never mentioned Fitts' Law in their infamous menu bar patent.
Pie menus "slices" are better than "screen corners" or "menu bars" because:
Screen corners and edges are static and fixed in number, so they only enable a small fixed number of global commands at once.
Pie menus are dynamic and context sensitive, so each pie menu can have multiple slices, with a different set of functions associated with each, including submenus. The screen only has four corners and four edges, but pie menus are extremely reliable with eight items, and can support up to 12 items reliably.
Pie menus also support submenus, so you can have an infinite combination of pie menu items, depending on the context you click on, instead of just four screen corners or four menu bars.
Each pie menu item is easier to hit than any screen corner, because every pie slice target area starts directly adjacent to the cursor and extends all the way out to the screen edge, and beyond!
Screen corners and menu bars flaunt Fitts' Law by requiring you to physically move the mouse a large distance, and they usually leave the cursor far away from the object you're manipulating.
Pie menu target area "slices" extend all the way out to the edge of the screen and beyond, so their area is quite large, but you don't have to actually move all the way to the screen edge to select them. You simply move the cursor outside of the small inactive area in the pie menu center. Each "slice" target area starts out directly adjacent to the cursor, in a different direction, and occupies a large area extending out to the edge of the screen.
Fitts' Law relates the target seek time and error rate to the target area and distance from the cursor. The bigger the target and the closer the target, the faster the seletion and fewer errors. Pie menus maximize the target area and minimize the target distance, so consequently they minimize both the speed and error rate, as Fitts' Law predicts.
Pie menus have been empirically proven to be 20% faster than the linear menus, and about half the error rate ("A Comparative Analysis of Pie Menu Performance"; by Jack Callahan, Don Hopkins, Mark Weiser, and Ben Shneiderman; Proc. CHI'88 conference, Washington D.C.)
Screen corners are worse than pie menus, because they actually have smaller target areas than pie menu slices, and actually maximize the distance from the cursor by putting the target as far away from the cursor as possible.
Tog claims the screen edge target area is "infinitely deep", but in practice you never move the cursor an infinite distanc
Yes they do need SEED. No they are not going to switch the entire country of Korea over to SSL and reissue millions of certificates this afternoon because some Firefox evangelist who still lives with his mom thinks they should.
Yes you have certainly missed some obvious facts.
-Don
The whole point of using a native ActiveX or XPCOM DLL is so you don't have to send your password over the network unencrypted. So why would you use an unencrypted SOAP network service to encrypt data you didn't want to send over the net? What bank in their right mind would do that?
The AJAXian alternative would be to implement the SEED encryption algorithm in JavaScript, and run it in the browser. That's certainly possible, but quite impractical.
If Firefox supported ActiveX as a user option, then there would be no need for a special XPCOM plug-in, and Korean users would have been able to do their banking in Firefox using the ActiveX control that has existed for years now.
ActiveX is just as secure as XPCOM, so why doesn't Firefox support it too? Seems like there's a double standard here.
-Don
-Don
The Open Group Releases COMsource 1.1
Menlo Park, CA. 10 January 2001 -- The Open Group has just released COMsource version 1.1, an enhanced version of the existing version, COMsource 1.0. COMsource is an open systems implementation of Microsoft's Component Object Model (COM) middleware developed for the Windows TM platform that extends the COM middleware infrastructure to UNIX TM. COMsource also allows independent software vendors to easily port their COM applications to non-Microsoft platforms. COMsource 1.0, released in September 1999, provides an object-based, distributed programming model that allows two or more applications, or application components, to easily interact and interoperate. COMsource 1.1 has a number of added features and benefits, including:
Updated to run on Solaris 2.6
Added support for the latest versions of NT and Windows 2000. COMsource is now compatible with NT 4.0 Service Packs 4, 5 and 6 and Windows 2000
Maintenance updates for build and runtime issues; enhancements to error handling to enable passing of rich error information between servers and clients on various platforms
The reference implementations include source code, an interoperability test suite and the reference documentation set. COMsource 1.1 also now has a Support & Maintenance Service offering, which consists of:
Consultation on using, building, installing and porting COMsource
Problem isolation and tracking
Critical problem escalation
Development of code fixes or workarounds for defects
For more information on COMsource 1.1, please visit www.opengroup.org/comsource