John
I have been playing around with bioinformatics and squeak. So far I have a class heirarchy for dna, protein, and coding sequences with lots of useful methods, mostly things like correction formulae, codon usage, base frequencies, etc. In addition, I have a class that parses the Genbank flat file format and can produce sequences from a menu of the documented features. I have used this a bit for my own research, but am now planning to teach a computational genetics course to our biology undergrads using Squeak...so the pressure is on to turn all this into something useful and fun. Right now I can drop sequence morphs onto a playfield and produce things like dot matrix plots and phylogenetic trees, but visually it ain't much. The speed issue hasn't been a problem because I'm not trying to do anything very ambitious. I ported this stuff from my lisp code, where I used calls to C routines (like clustal) to do hard calculations. Perhaps something similar will solve the speed problem with squeak.
If any of this sounds useful, I could package it up in its current state.
John Gillespie jhgillespie@ucdavis.edu
"John Tobler" squeaker@diganet.com wrote:
The last thing I personally need right now is to tangle with a major non-paying project, so I have decided to start on the design and development of a Biosqueak initiative. It rubs me the wrong way to see Bioeveryotherlanguage.org and not to see our beloved Squeak represented. I would appreciate any and all comments, signs of interest, etc. I will probably get rolling with implementing some of the simpler bioinformatics routines, following models already available in Biopython, Bioperl, and Bioruby. Anyone else who is interested in applying Squeak to bioinformatics problems is most welcome to join in.
I am guessing that we will face some formidable obstacles. As Heiko Schaefer pointed out in a recent post, "... little emphasis has been given so far on numerical work with squeak." Will someone please correct me if this assessment is unfair? It looks like some related work is underway by the Numerics group at the Camp Smalltalk connected with the ESUG conference in Essen. Hopefully, something approaching the capability of Numeric Python (NumPy) will magically appear just before we need it for Biosqueak. I am also sure that bioinformatics processing will fully test Squeak's mettle on text searching and pattern recognition. Where do we find support for regular expressions and the like? I anticipate that trying to solve such real world problems as sequence searching, sequence allignment, and protein structure prediction will point out areas where we can improve Squeak's reach and performance. There should be a challenge or two here to keep hardy pioneers and somewhat unstable test pilots interested.
Anyway, I intend to get started. This is just a "heads up" that Biosqueak is out there somewhere on the vast horizon.
More later,
John Tobler squeaker@diganet.com johntobler@earthlink.net
"jhgillespie" == jhgillespie jhgillespie@ucdavis.edu writes:
jhgillespie> I have been playing around with bioinformatics and jhgillespie> squeak. So far I have a class heirarchy for dna, jhgillespie> protein, and coding sequences with lots of useful jhgillespie> methods, mostly things like correction formulae, codon jhgillespie> usage, base frequencies, etc. In addition, I have a jhgillespie> class that parses the Genbank flat file format and can jhgillespie> produce sequences from a menu of the documented features. jhgillespie> I have used this a bit for my own research, but am now jhgillespie> planning to teach a computational genetics course to our jhgillespie> biology undergrads using Squeak...so the pressure is on jhgillespie> to turn all this into something useful and fun. Right jhgillespie> now I can drop sequence morphs onto a playfield and jhgillespie> produce things like dot matrix plots and phylogenetic jhgillespie> trees, but visually it ain't much. The speed issue jhgillespie> hasn't been a problem because I'm not trying to do jhgillespie> anything very ambitious. I ported this stuff from my jhgillespie> lisp code, where I used calls to C routines (like jhgillespie> clustal) to do hard calculations. Perhaps something jhgillespie> similar will solve the speed problem with squeak.
I recently presented a Perl-related keynote at a gene conference in Cambridge (UK). The audience was intently listening and interested, because as I was listening to them talk, it was all "perl perl perl" on the back end, "C C C" for number crunching, and "java java java" on the front end for fancy interfaces and visualization.
I think Squeak can (and should) take over the "java" portion of this arena. But I don't think Squeak is the right mix for the Perl portions (glue) or "C" portions (crunching). All three portions have their place, so don't offend a bioinformaticist by telling them that Squeak will do it all. But clearly creating the right Morphs would let the tech-heads create better interface building blocks so that the bio-scientist non-programmers could get the job done. Especially if it ran in the browser.
Just a thought.
p.s. bioinformatics is getting BIG funding, while dotcoms are shrinking. Good people are needed. Consider a career shift. :)
I'm not sure I fully understand people's interests here & I'm not sure I'm knowledgeable enough to form my questions well. --Concerning speed: I'd expect the direction here needs to be more architectural than language specific. C on the fastest machines available next few years is not close the speed need for many problems. --Where does the modeling take place? If Bioinformatics is just a code word for sequencing & genomics, the modeling may all be done & reflecting it with good visualization may be a great step. But proteomics, cell simulation, inter-cell communication, etc. may be at a different stage & have different requirements. [I notice that BioJava is moving toward a richer model than many of us might have predicted.] Does intensive string processing suggest the right abstractions for all Bioinformatics? --What is the role of 'glue'? Is it always part of the picture, or does the need for it represent a weak architecture? --Are 'number crunching', 'glue', and 'visualization' and adequate parts list? Are repositories like Bimolecular Interaction Network Database (BIND) part of the mix? What are the implications of the FDA's move to electronic submission for clinical trials? The supply chain work might not excite the Squeak community, but I wonder about the ability of Squeak to make clinical trials understandable to lay people & suspect this may be properly part of Bioinformatics.
I'd hate to see the Squeak community limit its view of Bioinformatics to providing visualizations of the current work inspired by the genome project, valuable as that work might be. Smalltalk's strong simulation and modeling history and Squeak's particular potential for learning and education suggest a broader direction and this may be where John G. is headed.
Whether or not biologist in 2011 and 2021 will work as they do now may be worth thinking about.
-b
"Randal L. Schwartz" wrote:
"jhgillespie" == jhgillespie jhgillespie@ucdavis.edu writes:
jhgillespie> I have been playing around with bioinformatics and jhgillespie> squeak. So far I have a class heirarchy for dna, jhgillespie> protein, and coding sequences {snip} jhgillespie> {snip} I ported this stuff from my jhgillespie> lisp code, where I used calls to C routines (like jhgillespie> clustal) to do hard calculations. Perhaps something jhgillespie> similar will solve the speed problem with squeak.
{snip} it was all "perl perl perl" on the back end, "C C C" for number crunching, and "java java java" on the front end for fancy interfaces and visualization.{snip}
"Randal L. Schwartz" wrote:
"jhgillespie" == jhgillespie jhgillespie@ucdavis.edu writes:
jhgillespie> I have been playing around with bioinformatics and jhgillespie> squeak. So far I have a class heirarchy for dna, jhgillespie> protein, and coding sequences with lots of useful jhgillespie> methods, mostly things like correction formulae, codon jhgillespie> usage, base frequencies, etc. In addition, I have a jhgillespie> class that parses the Genbank flat file format and can jhgillespie> produce sequences from a menu of the documented features. jhgillespie> I have used this a bit for my own research, but am now jhgillespie> planning to teach a computational genetics course to our jhgillespie> biology undergrads using Squeak...so the pressure is on jhgillespie> to turn all this into something useful and fun. Right jhgillespie> now I can drop sequence morphs onto a playfield and jhgillespie> produce things like dot matrix plots and phylogenetic jhgillespie> trees, but visually it ain't much. The speed issue jhgillespie> hasn't been a problem because I'm not trying to do jhgillespie> anything very ambitious. I ported this stuff from my jhgillespie> lisp code, where I used calls to C routines (like jhgillespie> clustal) to do hard calculations. Perhaps something jhgillespie> similar will solve the speed problem with squeak.
I recently presented a Perl-related keynote at a gene conference in Cambridge (UK). The audience was intently listening and interested, because as I was listening to them talk, it was all "perl perl perl" on the back end, "C C C" for number crunching, and "java java java" on the front end for fancy interfaces and visualization.
I think Squeak can (and should) take over the "java" portion of this arena. But I don't think Squeak is the right mix for the Perl portions (glue) or "C" portions (crunching). All three portions have their place, so don't offend a bioinformaticist by telling them that Squeak will do it all. But clearly creating the right Morphs would let the tech-heads create better interface building blocks so that the bio-scientist non-programmers could get the job done. Especially if it ran in the browser.
Just a thought.
p.s. bioinformatics is getting BIG funding, while dotcoms are shrinking. Good people are needed. Consider a career shift. :)
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
At 09:42 PM 8/30/2001 +0100, you wrote:
I'm not sure I fully understand people's interests here & I'm not sure I'm knowledgeable enough to form my questions well. --Concerning speed: I'd expect the direction here needs to be more architectural than language specific. C on the fastest machines available next few years is not close the speed need for many problems.
Couldn't the Squeak CCodeGenerator be leveraged? Smalltalk's been used for distributed processing before. I'm thinking about using Squeak to model a processing architecture, then using it to generate custom low-level processing code, then using it to coordinate the distribution of data and processing across a farm of machines, where the low-level processing occurs in custom-generated C accessed from a Squeak supervisor.
I _don't_ think this is the place to start, but I think it's a strategy that can be used down the line to provide support for large-scale problems.
-dms
"David M. Siegel" wrote:
At 09:42 PM 8/30/2001 +0100, you wrote:
I'm not sure I fully understand people's interests here & I'm not sure I'm knowledgeable enough to form my questions well. --Concerning speed: I'd expect the direction here needs to be more architectural than language specific. C on the fastest machines available next few years is not close the speed need for many problems.
Couldn't the Squeak CCodeGenerator be leveraged? Smalltalk's been used for distributed processing before. I'm thinking about using Squeak to model a processing architecture, then using it to generate custom low-level processing code, then using it to coordinate the distribution of data and processing across a farm of machines, where the low-level processing occurs in custom-generated C accessed from a Squeak supervisor.
I _don't_ think this is the place to start, but I think it's a strategy that can be used down the line to provide support for large-scale problems.
Just a thought, before the baby gets chucked out with the bathwater. Has anyone tried Squeak on a Beowulf cluster? On a Cray? On a mainframe? How does it scale?
David Buck's article in Smalltalk Chronicles seeks to lay to rest the idea that Smalltalk can't do serious number-crunching: "Have you heard that Smalltalk is inappropriate for real-time applications? Have you heard that it can't handle math-intensive applications? If so, you should look at ElastoLab."
Mind you, if we're talking of stuff as intensive as the Human Genome, we're talking of very serious number crunching. But one person I know that's working in part of this field is using an application developed in Delphi running on a P4!
Cheers
John
Mind you, if we're talking of stuff as intensive as the Human Genome, we're talking of very serious number crunching.
A friend of mine (who is quite into Bioinformatics) and I (who knows almost nothing about Bioinformatics) had a discussion a few weeks ago. It seemed like the thought was that many of the algorithms would be more efficient if fancy pattern matching logic was used instead of brute force compute power. For example, a multiple parallel state machine pattern search (i.e. a parser) might beat a bunch of passes with simple pattern match searches. It also seems possible the intersection of the bioinformatics wizards with the advanced parser wizards is almost an empty set.
Smalltalk is just super good at implementing fancy algorithms. I guess a question to ask: is it REALLY a very serious number cruncher problem, or is that just what current algorithms end up being.
Jan Bottorff wrote:
Mind you, if we're talking of stuff as intensive as the Human Genome, we're talking of very serious number crunching.
A friend of mine (who is quite into Bioinformatics) and I (who knows almost nothing about Bioinformatics) had a discussion a few weeks ago. It seemed like the thought was that many of the algorithms would be more efficient if fancy pattern matching logic was used instead of brute force compute power. For example, a multiple parallel state machine pattern search (i.e. a parser) might beat a bunch of passes with simple pattern match searches. It also seems possible the intersection of the bioinformatics wizards with the advanced parser wizards is almost an empty set.
Smalltalk is just super good at implementing fancy algorithms. I guess a question to ask: is it REALLY a very serious number cruncher problem, or is that just what current algorithms end up being.
Yes, it's a good question. It's so very easy to merrily jog down the old path (especially if the prevailing culture is C or Lisp -- not that I've got anything against either of them) without stopping to see if there is another way of doing it.
Cheers
John (who knows very little about either algorithms or Bioinformatics)
At 00:05 01.09.2001 -0700, Jan Bottorf wrote:
For example, a multiple parallel state machine pattern search (i.e. a parser) might beat a bunch of passes with simple pattern match searches.
It certainly does! I use it at work. :-)
It also seems possible the intersection of the bioinformatics wizards with the advanced parser wizards is almost an empty set.
I know it was just an example, but for this specific example (simultaneous exact pattern search), see if you can locate the paper by SMITH, R.: "A finite state machine algorithm for finding restriction sites and other pattern matching applications"; in: CABIOS Computer Applications in the Biosciences, vol. 4 (1988), #4, pp. 459-465. (I seem to have lost my copy -- IIRC, he built one DFA from the pattern list.)
Also, the Dr. Dobb's article on the implementation of fgrep was circulating in labs, sometime in the early 80s. And I sure have encountered the Dragon Book in some unexpected places.
Smalltalk is just super good at implementing fancy algorithms.
And rewarding, too: I fondly recall my Smalltalk/V implementation of the above algorithms running rings around "compiled" simplistic site finders.
[...] a question to ask: is it REALLY a very serious number cruncher problem, or is that just what current algorithms end up being.
Well, profile searching (i.e. for fuzzy and gapped patterns) is still an active research area. Fun, fame, fortune, etc. ;-)
Cheers, Helge
Sometimes you just gotta save the world. I really wish I didn't have to save the world but it seems It's up to me. =\
I tried to send this message yesterday but windows 3.11 crashed to DOS while I had turned to watch TV for a few minutes. On my old 486, windows 3.11 was so bad that it wouldn't boot while I sat at the console, I would litrally have to get up and run out of the room after hitting the command. Inexplicably, only this procedure would alow the thing to load without resetting to BIOS. =P
I am kinda inunndated by trafik on this list, There should be a focused list for hacking the VM into a full modern OS, and for creating the objects and modules for OS services...
I really like the opportunities Squeak's VM offers. It lets me do OS develing work without having to deal with the x86 nightmare. =)
The best thing about squeak people is that they've already proven themselves clueful enough to look beyond the buzzwords and find a solution that works for them. =)
To get started I should get a working squeak system... I have a very old spare machine with a 520 mb drive, and my main machine which also has BeOS on it. Unfortunately I am unable to compile the latest GCC on it. =\ (It seems to work but there are errors...)
I also would like ISBN #s, and URLs for the current Smalltalk/Squeak manuals and refferance materaial... I prefer hardcopy, I am also looking at the website. There is a lot of stuff there, much of it is probably redundant, superficial, or too specialized.. What I need is a shopping list that will give me the COMPLETE picture without redundancy...
Once I learn enough about it, I will start specifying an implementation of Sphere for Squeak. =)
My goal here is to build a system that's strong enough to force Microsoft to play fairly. =P
I am kinda inunndated by trafik on this list, There should be a focused list for hacking the VM into a full modern OS, and for creating the objects and modules for OS services...
Been there, done that, got the layoff letter. Not worth the time; plenty of other people are playing with OS's (although it does seem they are mostly just repeating stuff from thirty years ago, badly) so just make use of any good results. There are better uses of ones time.
To get started I should get a working squeak system...
That would certainly help.
I also would like ISBN #s, and URLs for the current Smalltalk/Squeak manuals and refferance materaial... I prefer hardcopy, I am also looking at the website. There is a lot of stuff there, much of it is probably redundant, superficial, or too specialized.. What I need is a shopping list that will give me the COMPLETE picture without redundancy...
Ain't no such thing. There is plently of doc around, most of it referenced from the squeak.org site and/or the swiki. Much of it only exists in virtual form. There are two books on Squeak (search amazon.com or you favourite booksite for 'Squeak and guzdial') and several on Smalltalk. Even ignoring the completely implausible request for no redundancy, there simply isn't any such thing as 'complete'. We keep changing things!
My goal here is to build a system that's strong enough to force Microsoft to play fairly. =P
Been there, done that (twice), got _both_ layoff letters. Oh, I'm being redundant again.
tim
[Mailing List and OS services]
plenty of other people are playing with OS's (although it does seem they are mostly just repeating stuff from thirty years ago, badly) so just make use of any good results.
=\ Why not work the other way around? Think about what computers will be like 30 years IN THE FUTURE, and start planning an OS that will remain viable then...
There are better uses of ones time.
YES!! But circumstances dictate that I devodte efforts to this...
Even ignoring the completely implausible request for no redundancy, there simply isn't any such thing as 'complete'. We keep changing things!
=\ That's a problem...
My goal here is to build a system that's strong enough to force Microsoft to play fairly. =P
Been there, done that (twice), got _both_ layoff letters. Oh, I'm being redundant again.
My turn then. ;)
Tim Rowledge wrote:
To get started I should get a working squeak system...
That would certainly help.
Yeah, I went and downloaded all 8M of the win 95 version hoping that I could compile it with B TC++ 4.5 under Win 3.11... No deal. =\
Ain't no such thing. There is plently of doc around, most of it referenced from the squeak.org site and/or the swiki. Much of it only exists in virtual form. There are two books on Squeak (search amazon.com or you favourite booksite for 'Squeak and guzdial') and several on Smalltalk. Even ignoring the completely implausible request for no redundancy, there simply isn't any such thing as 'complete'. We keep changing things!
Are you aware of a process called "configuration managment"? For Squeak to be a viable commercial alternative (never mind the performance issue), it must be clearly documented and well controlled.
Otherwise companies cannot rely on it enough to use it...
On Sunday 02 September 2001 04:24 pm, Alan Grimes wrote:
Are you aware of a process called "configuration managment"? For Squeak to be a viable commercial alternative (never mind the performance issue), it must be clearly documented and well controlled.
Otherwise companies cannot rely on it enough to use it...
We're taking the first steps here on the list, making a module system that will help to ease the problems of distribution. Configuration management would benefit greatly by such a system.
And anyway, who said that it was the goal of the entire Squeak community to make Squeak a "viable commercial alternative"? Squeak isn't commercial, and so far hasn't been focused on making traditional applications (not that there aren't some people who want to do this, but it hasn't been the main focus).
I'd hate to see Squeak thought of as being yet another database front end product, like some of the other Smalltalks are seen by some people.
Alan, as much as the world may need saving, Squeak will not do it.
The people here are brilliant scientists, some of them are responsible for many key innovations that made present-day interactive computation and software engineering possible. As scientists they do not care about the preocupations of organisations that use computation as industrial infrastructure.
The resulting creation, Squeak is thus a spectacularly effective prototyping tool which demonstrates all the abilities of the exceptional collection of people who create it and maintain it. Squeak is also encumbered by extreme NIH, and as a work in progress will predictably break the existing application codebase. Forget about non-regression testing.
It is a privilege to be able to watch the people on this list thrash around design ideas, and evolve their language at breakneck speed. But acrobatic monoplanes do not an airtransport industry make :)
Edmund
On Sun, 2 Sep 2001, Ned Konz wrote:
On Sunday 02 September 2001 04:24 pm, Alan Grimes wrote:
Are you aware of a process called "configuration managment"? For Squeak to be a viable commercial alternative (never mind the performance issue), it must be clearly documented and well controlled.
Otherwise companies cannot rely on it enough to use it...
We're taking the first steps here on the list, making a module system that will help to ease the problems of distribution. Configuration management would benefit greatly by such a system.
And anyway, who said that it was the goal of the entire Squeak community to make Squeak a "viable commercial alternative"? Squeak isn't commercial, and so far hasn't been focused on making traditional applications (not that there aren't some people who want to do this, but it hasn't been the main focus).
I'd hate to see Squeak thought of as being yet another database front end product, like some of the other Smalltalks are seen by some people.
The resulting creation, Squeak is thus a spectacularly effective prototyping tool which demonstrates all the abilities of the exceptional collection of people who create it and maintain it.
Yep. That's why I'm here. I need to prototype my OS design. =)
The problem is making a prototype good enough to impress investors...
Alan Grimes alangrimes@starpower.net is widely believed to have written:
Are you aware of a process called "configuration managment"? For Squeak to be a viable commercial alternative (never mind the performance issue), it must be clearly documented and well controlled.
Hmm, let's see... yup, I think I might have dealt with that in the twenty years or so I've been making a living from softare. You're making a common mistake though. Squeak is not aimed at being a commercial alternative. It is aimed at being a vehicle for the journey towards an exquisite personal computing system. There are several commercial Smalltalks already. Mind you, Squeak _is_ used commercially in several places, where the complete openness and rapid development, community etc is valued even more than the qualities of those commercial versions.
Tim Rowledge tim@sumeru.stanford.edu said:
You're making a common mistake though. Squeak is not aimed at being a commercial alternative.
Says who? I really would hope that people will want to use Squeak for commercial purposes and adapt if for their needs - at the end of the day, it'll only get better for it. It's extremely dangerous with open source software to start saying "X is not meant for Y" - let the community decide and just make sure that Z (which is whatever you want) isn't left out.
Otherwise, Linux would still be a Finnish CS student's spare time hack (after all, it was not *aimed* at being a commercial alternative to ...).
On Monday, September 3, 2001, at 03:00 AM, Cees de Groot wrote:
Otherwise, Linux would still be a Finnish CS student's spare time hack (after all, it was not *aimed* at being a commercial alternative to ...).
Are you suggesting that it is a "commercial alternative to" the elipsis? Perhaps in the arena of servers (although FreeBSD seems a far better device for that), but where, exactly are we seeing alternative uses?
I agree, of course, with Mr. de Groot that the community will decide for what Squeak is. However, let us take Tim's remarks in context:
Are you aware of a process called "configuration managment"? For Squeak to be a viable commercial alternative (never mind the performance issue), it must be clearly documented and well controlled.
Hmm, let's see... yup, I think I might have dealt with that in the twenty years or so I've been making a living from softare. You're making a common mistake though. Squeak is not aimed at being a commercial alternative. It is aimed at being a vehicle for the journey towards an exquisite personal computing system. There are several commercial Smalltalks already. Mind you, Squeak _is_ used commercially in several places, where the complete openness and rapid development, community etc is valued even more than the qualities of those commercial versions.
In this context, I think his point was well-placed. Squeak, while the community may intend it for commercial or non-commercial purposes, is CLEARLY intended to be an open source communal project. As such, it is unlikely EVER to be "well controlled."
So far as adapting to various constraints to make it more "commercially viable," that will be the work of the community -- but only those in the community who actual do the doing. If the community believes it needs documentation, there will be documentation. If it needs modules, there will be modules, and so forth.
But it won't ever happen from the suggestion that some feature, trait or methodology is required to make Squeak a "commercial alternative."
On Mon, 3 Sep 2001, Andrew C. Greenberg wrote:
While not a commercial alternative to the garbage referred to by the elipsis, Linux has definitely got a following in the enterprise market, and embedded market these days. And almost all university CS departments use it. Do you remember the days when computers were mainly found at universities ? Well, Linux has saturated that market, which actually correponds to the initial Un#x design goal.
And, frankly, people who use ... are like people who use C++. They get what they ask for.
Edmund
On Monday, September 3, 2001, at 03:00 AM, Cees de Groot wrote:
Otherwise, Linux would still be a Finnish CS student's spare time hack (after all, it was not *aimed* at being a commercial alternative to ...).
Are you suggesting that it is a "commercial alternative to" the elipsis? Perhaps in the arena of servers (although FreeBSD seems a far better device for that), but where, exactly are we seeing alternative uses?
Edmund Ronald eronald@rome.polytechnique.fr said:
Do you remember the days when computers were mainly found at universities ? Well, Linux has saturated that market, which actually correponds to the initial Un#x design goal.
Small correction: AFAIK, the original Unix design goal was to run telco switches, and it did that a lot for a long time in big numbers. I don't know why exactly it became popular at universities (probable a combination between a port to the popular PDP machine, source availability, and the fact that Unix had the 'by hackers, for hackers' feel), but I'm quite sure it was not the design goal.
On Tue, Sep 04, 2001 at 02:50:45PM +0200, Cees de Groot wrote:
Edmund Ronald eronald@rome.polytechnique.fr said:
Do you remember the days when computers were mainly found at universities ? Well, Linux has saturated that market, which actually correponds to the initial Un#x design goal.
Small correction: AFAIK, the original Unix design goal was to run telco switches, and it did that a lot for a long time in big numbers. I don't know why exactly it became popular at universities (probable a combination between a port to the popular PDP machine, source availability, and the fact that Unix had the 'by hackers, for hackers' feel), but I'm quite sure it was not the design goal.
"Perhaps paradoxically, the success of the Unix system is largely due to the fact that it was not designed to meet any predefined objectives." - "The UNIX Time-Sharing System", by D. M. Ritchie and K. Thompson
It most certainly was not designed with any thought or intention of supporting universities or running telco switches.
See http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html. If you only ever read one thing about Unix, read this. It's very short, and contains practically everything worth knowing about Unix. It also has a nice "Back to the Future" flavor to it now that a few decades have passed.
Dave
"Andrew C. Greenberg" wrote:
On Monday, September 3, 2001, at 03:00 AM, Cees de Groot wrote:
Otherwise, Linux would still be a Finnish CS student's spare time hack (after all, it was not *aimed* at being a commercial alternative to ...).
Are you suggesting that it is a "commercial alternative to" the elipsis? Perhaps in the arena of servers (although FreeBSD seems a far better device for that), but where, exactly are we seeing alternative uses?
Well, I don't want to suggest that Linux (or any *nix) is perfect (I like the sound of Lex's "objects instead of files", but have problems visualising it) and providing people use some kind of *nix (preferably an Open Source *nix) they won't hear any complaints from me. But I've seen recent benchmark figures (in Sysadmin) in which Linux beat the living daylights (under heavy use) out of Solaris, elipsis 2000 and BSD (and in that order). I know of one German bank, one UK supermarket, the administration of one city in Florida and many universities which are using Linux. At some level, these may all claim to be commercial institutions. Of course, the US government (in the form of NASA and the NSA) both continue to contribute to Linux at the development level. Sun (of all people) are issuing their service staff handheld devices which run Linux! Even Squeakland (all power to them!)run Linux.
Cheers
John
Hello Squeakers,
Has anyone implemented the SMTP AUTH extensions for Celeste?
Thanks, Bob
I think I like Cees De Groot's concept. It's quite clear people have their own pies to bake around here with SC the key support. I'm sure if Alan Grimes could implement his project it would be well received.
Regards, Gary
----- Original Message ----- From: "Cees de Groot" cg@cdegroot.com Newsgroups: lists.squeak To: squeak-dev@lists.squeakfoundation.org Sent: Monday, September 03, 2001 8:00 AM Subject: Re: Saving The World.
Tim Rowledge tim@sumeru.stanford.edu said:
You're making a common mistake though. Squeak is not aimed at being a commercial alternative.
Says who? I really would hope that people will want to use Squeak for commercial purposes and adapt if for their needs - at the end of the day, it'll only get better for it. It's extremely dangerous with open source software to start saying "X is not meant for Y" - let the community decide
and
just make sure that Z (which is whatever you want) isn't left out.
Otherwise, Linux would still be a Finnish CS student's spare time hack
(after
all, it was not *aimed* at being a commercial alternative to ...).
-- Cees de Groot http://www.cdegroot.com cg@cdegroot.com GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B Building software is like quantum mechanics: you can predict what it will do, or when it will be ready -- but not both.
Alan,
Are you aware of a process called "configuration managment"?
Yes. So what?
For Squeak to be a viable commercial alternative (never mind the performance issue)
A viable commercial alternative to what? On your advice, I'll ignore the performance issues, whatever that means. I'm pretty sure that the UN council on racism is discussing it this week. I'm assuming that the performance issues you speak of must have something to do with the racist attitudes of the civilized world against the mighty tyranical oppressors.We'll stop those fascists !!!
it must be clearly documented and well controlled.
When somebody tells me "something *must* be ... " in the software arena, I know I'll be much happier just ignoring them. Well controlled? Who is supposed to be doing this controlling? I like free range software, thank you very much. Dude, you just downloaded Squeak, you might be polite enough to:
a) ignore it and hope it goes away b) learn a little bit about it, what it is, and how to use it or c) make it do what you want
If you're trying to rewrite a minimalist DOS like operating system on a ten year old Windows 3.11 based machine, I'll save you a lot of time and trouble. Squeak is not an appropriate vehicle. You should be coding in assembler, or you should look into something like Charles Moore's ColorForth which can run your entire OS from a floppy. From what you've written so far to the list, you might be better served to just write straight to binary. That way, your code will be as fast and space efficient as you can possible make it, and you want have to worry about those pesky optimizing assemblers attacking your code.
Jim
Alan Grimes wrote:
Yeah, I went and downloaded all 8M of the win 95 version hoping that I could compile it with B TC++ 4.5 under Win 3.11... No deal. =\
Well, I'm not surprised! Sounds like "I'll rebuild the engine of that ME109 using the toolkit for the Camaro, and I'll use the hydraulic fluid out of that scrap 707 as oil. That should do it!"
I wouldn't say that building a 3.11 port of Squeak was impossible, but it's probably the wrong place to start. Just pop the Linux, Mac or Windows version onto the right operating system. (Or you could have another go with the BeOS version and let people know where the build is falling over.) Then we'll have something to talk about.
Cheers
John
Alan,
Yeah, I went and downloaded all 8M of the win 95 version hoping that I could compile it with B TC++ 4.5 under Win 3.11... No deal. =\
Nope. You'll have an *extremely* hard time making this work. Squeak really wants a 32bit flat address space and you won't get this unless you're using the worst of all Win32 flavours - I had been using Win32s before I ran into Squeak and realizing the pain associated with it I decided not even to try porting Squeak to any Win 3.1 versions. AFAIK, there has never been a working version of Squeak on any Windows prior Win95 (there's a DOS version still out there running on some extender - you may want to look into this).
Cheers, - Andreas
Tim Rowledge tim@sumeru.stanford.edu wrote:
I am kinda inunndated by trafik on this list, There should be a focused list for hacking the VM into a full modern OS, and for creating the objects and modules for OS services...
Been there, done that, got the layoff letter. Not worth the time; plenty of other people are playing with OS's (although it does seem they are mostly just repeating stuff from thirty years ago, badly) so just make use of any good results. There are better uses of ones time.
There are two senses of OS floating around. On the part about talking to device drivers, I agree with Tim: it's cool, but it won't be better than what's already there. However, there's another sense of OS: the fundamental organization of the software on a computer. That is, the OS as viewed from above by a user, instead of as viewed from below by a device.
On that angle, there is *plenty* of room to improve, and I can hardly imagine a better way to spend one's time. I don't care if XWindows is sitting underneath Squeak to handle the device drivers, but I really care that the fundamamental organization approach on my system is still files instead of objects.
-Lex
"Lex Spoon" lex@cc.gatech.edu is widely believed to have written:
There are two senses of OS floating around. On the part about talking to device drivers, I agree with Tim:
[snip] I agree with Lex. In the sense of using an already built lower layer and then considering doing everything else in (Squeak/VW/perl/Ruby/Shakespeare/SNOBOL/whatever) then yes, you can make a better world. However, the track record is not good. No current UI is worth the pixels it's written on. Morphic, thankfully, show promise functionally, but the architecture could do with being architected. (Oh yuck, I'm falling into americanisms)
We could probably do a decent job in the manner the SqueakNOS gang are working, using something like OSKit etc. We could finish the Interval Translator to help with VM & prim generation. We could use J{x} for bytecode translation. We could design our own hardware, like Jecel.
BUT unless somebody can some up with >1$b, forget taking on M$. I already tried it with a promise of 1/2$b and that wasn't enough to protect us. And don't for a moment think that producing something better will be more than 1% of the job.
BUT unless somebody can some up with >1$b, forget taking on M$. I already tried it with a promise of 1/2$b and that wasn't enough to protect us. And don't for a moment think that producing something better will be more than 1% of the job.
I was going to try to take a shot with $100M... That would cover development of an initial product line and the beginnings of hardware production. My business plan needs quite a bit of work. =\ Getting that much investment while retaining enough freedom to deliver the product you want is another challenge...
1B is an awfuly big pile of venture... You would have to be VERY familiar with the market to get that much...
Hi Gang, I need to understand the performance tradeoffs between modularized implementations of a system versus optimized, monolithic implementations that are tailored to specific application domains (as applied to Squeak). While modularity usually gains a certain amount of flexibility, the price paid is a big hit in performance. Although I'm not sure about this, is not the Linux kernel monolithic as opposed to various Mach-based implementations of UNIX? Could the folks advocating a modular Squeak explain how the resulting system will be useful in supporting high-performance applications? Computations? Numerically intensive computations such as that described below? I don't expect Moore's Law to continue to solve all of our performance issues, but maybe I'm wrong. Cheers, Roger.....
jhgillespie@ucdavis.edu wrote:
John
I have been playing around with bioinformatics and squeak. So far I have a class heirarchy for dna, protein, and coding sequences with lots of useful methods, mostly things like correction formulae, codon usage, base frequencies, etc. In addition, I have a class that parses the Genbank flat file format and can produce sequences from a menu of the documented features. I have used this a bit for my own research, but am now planning to teach a computational genetics course to our biology undergrads using Squeak...so the pressure is on to turn all this into something useful and fun. Right now I can drop sequence morphs onto a playfield and produce things like dot matrix plots and phylogenetic trees, but visually it ain't much. The speed issue hasn't been a problem because I'm not trying to do anything very ambitious. I ported this stuff from my lisp code, where I used calls to C routines (like clustal) to do hard calculations. Perhaps something similar will solve the speed problem with squeak.
If any of this sounds useful, I could package it up in its current state.
John Gillespie jhgillespie@ucdavis.edu
[snip]
Roger Vossler rvossler@qwest.net said:
While modularity usually gains a certain amount of flexibility, the price paid is a big hit in performance. Although I'm not sure about this, is not the Linux kernel monolithic as opposed to various Mach-based implementations of UNIX?
Nes (or Yo, whatever). The Linux *core* kernel is a tiny little blazingly fast monolithic beast. But then you can attach all sorts of goodies to it, called modules - device drivers, network protocols, system watchdogs, graphics interfaces, whatever. I think it's a best-of-both-worlds solution, because the core is still statically configurable - read recompile - for special purposes (so you can still take stuff away for really small machines) while the run-of-the-mill Linux kernel will work for 95% of the uses because it will be adorned with modules to shape it for the particular task at hand.
To me, sounds like a perfect model for the Squeak VM. Dynamically loaded objects aren't any slower than statically linked librarys on the OSes I know, and on the Smalltalk level the issue is non-existant anyway.
Mach is the far end of the spectrum monolithic<->microkernel. As happens so often, it's an interesting theoretical idea, but in practice more conventional approaches turn out to work at least just as well. There's an interesting discussion on this topic between Linus Torvalds and Andrew Tanenbaum (http://www.oreilly.com/catalog/opensources/book/appa.html). Despite Tanenbaums' outstanding credentials, most people think that then-still-undergrad Torvalds won :-). Those where the days...
(actually, I think there was even a 'farther end', Amoeba - an object-oriented research OS developed at the Free University of Amsterdam in the '80s)
"Roger Vossler" rvossler@qwest.net is widely believed to have written:
While modularity usually gains a certain amount of flexibility, theprice paid is a big hit in performance.
What gives you this idea?
In the particular case of Squeak plugins, the lookup when an external prim is first called might involve finding a file loading it, doing an OS binding/search etc, but that only happens once. On susequent uses, the cost is rather small - an extra couple of indirections perhaps.
In the case of Smalltalk code modules of the sort we have been discussing recently, I imagine that any sensible mechanism will effectively be as fast as any other method lookup.
What cases of a modularity cost have you seen?
tim
Hi Tim, Having recently retired from 27 years in the aerospace business as a systems engineer and computer engineer, I have worked (and done research concerning) a number of high-performance, numerically intensive, mission-critical sensor data processing applications. While modularity, reuse, and components, et al have been attractive selling points for such systems, hard performance requirements dictate otherwise. CORBA, Java, and COM would definitely not be my first choice. Squeak in its present form would most definitely not make the cut. We have used professional Smalltalk systems and watched them hopelessly fail under load. Back in the early days, we used operating systems and any number of tools for development purposes only. The final application was built directly into the hardware. While the hardware has improved by orders of magnitude since then, so have the performance requirements. IMNSHO, these issues are why we still don't have a functioning Dynabook after 32 years. Sure, I can load an episode of Star Trek into my VCR and watch folks carrying around tablets that communicate with humans, each other, and the onboard computers built into the Enterprise. But back here in the 21st Century, all I can do is load Squeak into a Titanium PowerBook and dream, dream, dream..... :-) Someday, my dreams will come true (hopefully, before the 23rd Century). Cheers, Roger.....
Tim Rowledge wrote:
"Roger Vossler" rvossler@qwest.net is widely believed to have written:
While modularity usually gains a certain amount of flexibility, theprice paid is a big hit in performance.
What gives you this idea?
In the particular case of Squeak plugins, the lookup when an external prim is first called might involve finding a file loading it, doing an OS binding/search etc, but that only happens once. On susequent uses, the cost is rather small - an extra couple of indirections perhaps.
In the case of Smalltalk code modules of the sort we have been discussing recently, I imagine that any sensible mechanism will effectively be as fast as any other method lookup.
What cases of a modularity cost have you seen?
tim
Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful Latin Phrases:- Furnulum pani nolo = I don't want a toaster.
"Roger Vossler" rvossler@qwest.net is widely believed to have written:
Having recently retired from 27 years in the aerospace businessas a systems engineer and computer engineer, I have worked (and done research concerning) a number of high-performance, numerically intensive, mission-critical sensor data processing applications.
Yup, those are indeed good examples of where I can see there being an actual, real cost. AIUI much of this sort of software has to run on much slower hardware than a typical desktop because of the need for a certified processor; which takes time. IIRC the 386 is about the latest cpu certified for manned space flight use, although I know somebody using ARMs for a satellite (actually at one time ages ago the Brit military were testing silicon-on-saphire ARMs for hard radiation environments as well). Mind you, I think I'd consider the absolute we-know-what-code-will-run safety of the monolithic approach more important when _I'm_ on a plane. I'm nervous enough as it is, having worked on designing RB211's etc many years ago. Never watch sausages being made....
tim
Hi Tim, I hear you! <big grin> Some people pray to God when the fly, I just pray that the engineers at Boeing (et al) had their sit together when they designed and built the turkey I'm flying in. Thanks for yoour comments. Cheers, Roger.....
Tim Rowledge wrote:
[snip]
Mind you, I think I'd consider the absolute we-know-what-code-will-run safety of the monolithic approach more important when _I'm_ on a plane. I'm nervous enough as it is, having worked on designing RB211's etc many years ago. Never watch sausages being made....
tim
squeak-dev@lists.squeakfoundation.org
-
Alan Grimes -
Andreas Raab -
Andrew C. Greenberg -
Blaine Wishart -
Bob Hartwig -
cg＠cdegroot.com -
David M. Siegel -
David T. Lewis -
Edmund Ronald -
Gary McGovern -
Helge Horch -
Jan Bottorff -
jhgillespie＠ucdavis.edu -
Jim Benson -
John Hinsley -
Lex Spoon -
merlyn＠stonehenge.com -
Ned Konz -
Roger Vossler -
Tim Rowledge