On 18-May-06, at 12:26 PM, Bryce Kampjes wrote: > > I could do something interesting with Exupery for a mere 100K Euros or > so. Anything less isn't enough to give up the day job for a year or > so. More money would of course buy more features and a larger > team. ;-) Of course, if someone gave me E1m you would get the 100k to be part of the team, like several others. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Mind like a steel sieve. |
In reply to this post by Bryce Kampjes
> Hans-Martin Mosner writes: >> Doable, but not really a good way to implement Smalltalk. >> You'd lose the binary portability and in turn gain a lot of weight, >> since bytecodes are so much more compact than machine language. >> IIRC, Peter Deutsch stated that dynamic compilation of bytecodes to >> machine language is actually faster than paging pre-compiled machine >> code into memory. This is one of those things that varies over time as the relative performance of disk, main memory, cpu and cache (and its size of course) develop. In the 84-90 timeframe when LPD was doing this work discs were sloooooo oooow ww and caches were tiny and main memory wasn't hugely slower than cache. These days, caches are huge but still grossly inadequate to cope with the bloated obscenities that are claimed to be 'modern operating systems', cpus are massively faster than main memory and even more so if actual random access of data is considered. Set against that, we tend to have our little silicon servants doing many more things at once and so if compiled code were being paged in whilst some other useful work gets done it might seem like the total system is better. How aggressively one compiles will affect the equation as well; PS & HPS do fairly simplistic optimisation because the aim is to get a usable answer *right now*. Exupery is being more painstaking AIUI. On a machine with multiple cpus available (including a cluster of machines of course) one could imagine having a somewhat Spoon-like arrangement where a separate image running somewhere else does the careful optimised compile and provides the result to clients, rather than simply passing the method back. You'd need to make it work asynchronously to some extent I guess rather than blocking. Hell, extend Spoon a bit and have a compiler service for fee! tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim My computer NEVER cras |
In reply to this post by Ron Teitelbaum
Well, this function actually defines all of LISP, so literally, this
is "one function to do everything". It's a kernel even smaller than Smalltalk's (and preceding it by decades). - Bert - Am 18.05.2006 um 01:48 schrieb Ron Teitelbaum: > Andreas, > > Ok now it's my turn to byte. So while I'm sitting here looking up > the Lisp > 1.5 manual I'm thinking to myself I hope this joke is better then > mine. > When I got there this is what I found: > > evalquote is defined by using two main functions, called eval and > apply. > apply > handles a function and its arguments, while eval handles forms. > Each of > these functions > also has another argument that is used as an association list for > storing > the values > of bound variables and f unction names. > where > apply [fn;x; a] = > [atom[fn] - [ e q [ f n ; ~ ~ ~ ] - caar[x]; > e q [ f n ; ~ ~ ~ ] -- cdar[x]; > eq[fn; CONS] -- cons[car[x]; cadr[x]]; > e q [ f n ; ~ ~ ~ ~ ] -- atom[car[x]]; > eq[fn; EQ] - eq[car[x]; cadr[x]]; > T - apply[eval[fn;a];x;a]]; > eq[car[fn]; LAMBDA] -- eval[caddr [fn]; pairlis[cadr[fn];x;a]]; > eq[car [fn]; LABEL] - apply [caddr [fn]; x; cons [cons[cadr [fn]; > c addr [f n]]; a]]] > eval[e;a] = [atom[e] - cdr[assoc[e;a]]; > atom[car[e]] - > [eq[car QUOTE] - cadr [el; > eq[car[e]; COND] - evcon[cdr [el; a]; > T -- apply[car [el; evlis[cdr [el; a]; a]]; > T - apply[car [el; evlis [cdr [el; a]; a]] > pairlis and assoc have been previously defined. > evcon[c; a] = [eval[caar [c]; a] -- eval[cadar [c]; a]; > T -- evcon[cdr [c];a]] > and > evlis[m;a] = [null[m] - NIL; > T - cons [eval[car [m];a];evlis[cdr [m];a]]] > > So other then an offhanded joke about Elvis I have to admit I don't > get it! > > :^D > > Ron > >> -----Original Message----- >> From: [hidden email] [mailto:squeak- >> dev- >> [hidden email]] On Behalf Of Andreas Raab >> Sent: Wednesday, May 17, 2006 5:25 PM >> To: The general-purpose Squeak developers list >> Subject: Re: A Lisper asks, "Am I supposed to like Smalltalk?" >> >> Stéphane Rollandin wrote: >>> Ron Teitelbaum wrote: >>>> If you really love functions you can have one class and one >>>> method do >>>> everything! :) >>> >>> hmmm... that's a puzzle ? >>> >>> ok I give up ! what method ? >> >> It's right there on the bottom of page 13 of the Lisp 1.5 manual. >> >> Cheers, >> - Andreas >> >> > > > |
Thanks Bert!
Ron > -----Original Message----- > From: Bert Freudenberg [mailto:[hidden email]] > Sent: Thursday, May 18, 2006 4:09 PM > To: The general-purpose Squeak developers list > Cc: [hidden email] > Subject: Re: A Lisper asks, "Am I supposed to like Smalltalk?" > > Well, this function actually defines all of LISP, so literally, this > is "one function to do everything". It's a kernel even smaller than > Smalltalk's (and preceding it by decades). > > - Bert - > > Am 18.05.2006 um 01:48 schrieb Ron Teitelbaum: > > > Andreas, > > > > Ok now it's my turn to byte. So while I'm sitting here looking up > > the Lisp > > 1.5 manual I'm thinking to myself I hope this joke is better then > > mine. > > When I got there this is what I found: > > > > evalquote is defined by using two main functions, called eval and > > apply. > > apply > > handles a function and its arguments, while eval handles forms. > > Each of > > these functions > > also has another argument that is used as an association list for > > storing > > the values > > of bound variables and f unction names. > > where > > apply [fn;x; a] = > > [atom[fn] - [ e q [ f n ; ~ ~ ~ ] - caar[x]; > > e q [ f n ; ~ ~ ~ ] -- cdar[x]; > > eq[fn; CONS] -- cons[car[x]; cadr[x]]; > > e q [ f n ; ~ ~ ~ ~ ] -- atom[car[x]]; > > eq[fn; EQ] - eq[car[x]; cadr[x]]; > > T - apply[eval[fn;a];x;a]]; > > eq[car[fn]; LAMBDA] -- eval[caddr [fn]; pairlis[cadr[fn];x;a]]; > > eq[car [fn]; LABEL] - apply [caddr [fn]; x; cons [cons[cadr [fn]; > > c addr [f n]]; a]]] > > eval[e;a] = [atom[e] - cdr[assoc[e;a]]; > > atom[car[e]] - > > [eq[car QUOTE] - cadr [el; > > eq[car[e]; COND] - evcon[cdr [el; a]; > > T -- apply[car [el; evlis[cdr [el; a]; a]]; > > T - apply[car [el; evlis [cdr [el; a]; a]] > > pairlis and assoc have been previously defined. > > evcon[c; a] = [eval[caar [c]; a] -- eval[cadar [c]; a]; > > T -- evcon[cdr [c];a]] > > and > > evlis[m;a] = [null[m] - NIL; > > T - cons [eval[car [m];a];evlis[cdr [m];a]]] > > > > So other then an offhanded joke about Elvis I have to admit I don't > > get it! > > > > :^D > > > > Ron > > > >> -----Original Message----- > >> From: [hidden email] [mailto:squeak- > >> dev- > >> [hidden email]] On Behalf Of Andreas Raab > >> Sent: Wednesday, May 17, 2006 5:25 PM > >> To: The general-purpose Squeak developers list > >> Subject: Re: A Lisper asks, "Am I supposed to like Smalltalk?" > >> > >> Stéphane Rollandin wrote: > >>> Ron Teitelbaum wrote: > >>>> If you really love functions you can have one class and one > >>>> method do > >>>> everything! :) > >>> > >>> hmmm... that's a puzzle ? > >>> > >>> ok I give up ! what method ? > >> > >> It's right there on the bottom of page 13 of the Lisp 1.5 manual. > >> > >> Cheers, > >> - Andreas > >> > >> > > > > > > > |
In reply to this post by Bryce Kampjes
[...
> I could do something interesting with Exupery for a mere 100K > Euros or so. Anything less isn't enough to give up the day > job for a year or so. More money would of course buy more > features and a larger team. ;-) > > Bryce > It gives to me arround 300 euros from 300 investors. I don't think is too much money for an heatly organization (even non profit). If the volunteers can hold the organization of the event (nothing that smalltalk can do for them) the people will come. That will be a transparent way to get that ammount of money that the organization could invest on is main object of interest. A big event with that finality could certainly do that. Get together key people, key persons who can give some light on this regard, the consecuences of the project and today's interesting subjects. Their reunion in a positive/constructive environment will certainly atract interest. The model could be 3 days (Friday, Saturday and Sunday) in some hotel with acceptable structure in an attactive city (Tip: change in southamerica makes more easy to find a good hotel by less $$ and there is a lot of cultural attractive cities). The event could have laboratories, seminars, panels and other expositions wich represent the investigations and foundings from people of this comunity. The key for the success of an event like that will be the volunteers's hard work. Cheers, Sebastian PD: "If you build it, he will come..." (http://www.imdb.com/title/tt0097351/) |
"Sebastián Sastre" wrote:
> [... > > I could do something interesting with Exupery for a mere 100K > > Euros or so. Anything less isn't enough to give up the day > > job for a year or so. More money would of course buy more > > features and a larger team. ;-) > > > > Bryce > > > > It gives to me arround 300 euros from 300 investors. I don't think is too > much money for an heatly organization (even non profit). If the volunteers > can hold the organization of the event (nothing that smalltalk can do for > them) the people will come. That will be a transparent way to get that > ammount of money that the organization could invest on is main object of > interest. > > A big event with that finality could certainly do that. Get together key > people, key persons who can give some light on this regard, the > of the project and today's interesting subjects. Their reunion in a > positive/constructive environment will certainly atract interest. The model > could be 3 days (Friday, Saturday and Sunday) in some hotel with acceptable > structure in an attactive city (Tip: change in southamerica makes more easy > to find a good hotel by less $$ and there is a lot of cultural attractive > cities). The event could have laboratories, seminars, panels and other > expositions wich represent the investigations and foundings from people of > this comunity. > > The key for the success of an event like that will be the volunteers's hard > work. > This is an excellent idea. The fine print is that all participants must pay all expenses. (Unless The Squeak Foundation decides to spend few million Euros for the event ;-) The good news is that, I think, the expenses is not more than $50. Some don't even have to pay this $50, because they already had it, the webcam. Cheers, PhiHo |
In reply to this post by Bert Freudenberg-3
On 18-May-06, at 1:08 PM, Bert Freudenberg wrote: > Well, this function actually defines all of LISP, so literally, > this is "one function to do everything". It's a kernel even smaller > than Smalltalk's (and preceding it by decades). It's also a startling example of the wisdom of the old saying "simplify as much as possible - and no further". tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: SDR: Shift Disk Right |
In reply to this post by Hans-Martin Mosner
Hans-Martin Mosner puso en su mail :
> It's the VisualWorks VM. I'm running it on a PPC Mac with Debian Linux, > but MacOS is also supported :-) > You can have it with the VisualWorks noncommercial download, however, > the VM source code is not included (as a commercial customer you can > have that, too). > > Cheers, > Hans-Martin Very thanks, Hans I have it , but never know the fact >>HPS compiles Smalltalk to bytecodes and then the VM converts those to >>quite well optimised machine code at need; it was a JIT many years >>before the javanauts made the term popular. On this VM. ___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar |
In reply to this post by Alan L. Lovejoy
I've used Smalltalk extensively for 20 years, after 10 earlier
years where I used it sporadically. I was introduced to
Smalltalk as a graduate student doing my research at Xerox PARC
1975-78. My main language in those days was Interlisp, and I was
the first user of Interlisp-D -- it's display version -- as Warren
Teitelman developed it.
When I returned East I worked in both Interlisp-D and Symbolics
Lisp Machine Lisp. The paradigm of the former is like
Smalltalk's: edit in the image then, for secondary purpoes,
occasionally file out to text (or to a code repository such as ENVY).
(It is no accident that Interlisp-D was developed in the same time and
place as Smalltalk.) The paradigm of the latter was the usual
edit an external textual representation and occasionally load the file
into the image. So, the distinction between the two
approaches is not actually between Smalltalk and other languages
(Lisp or Java or C++), but rather the working style encouraged
(better supported) by the development environment. You
can work in either style in either kind of environment -- you can edit
a fileout and file it back in in Smalltalk or Interlisp-D, and you can
edit and redefine individual functions in Emacs and other file-based
environments. In fact, there is a GNU
implementation of Smalltalk that is independent of any
development environment. (By the way, it has some very
intriguing features for interacting with the external modern world --
I recommend that ou take a quick look at the Table
of Contents of the GNU Smalltalk User's Guide to get an idea of
what this is all about.)
I came to refer to this distinction as West Coast vs. East Coast
style. I discovered a similar distinctions in Continental approaches
to software development -- Algol/Pascal/Modula, Simula, Prolog, etc.,
and a rigorous mathematical style of software construction that rarely
said anything at all about development environments. I have
encountered fundamentally different Continental, East Coast, and West
Coast styles in many things I've been involved in, even
recreational activities. For instance, in the days of wood
tennis racquets there were even three grips called, yes,
Continental, Eastern, and Western. Bidding systems in Bridge
exhibit a similar division. And so on. There are, of course,
many facets of this, and these are extremes in a space of
possibilities in which specific approaches are located, but very
loosely speaking I would categorize Continental as abstract,
Eastern as technological, and Western as cognitive, terms which
correspond to broad sociological stereotypes in many ways.
These approaches affect a lot more than the development
environment, but though that is where their differences are most
obvious. (The effects of the differences often extend to
applications GUI developers tend to provide their users with
interfaces that are a lot like those in their development environment,
in part -- to be fair -- because it is easier to reuse the various
frameworks and components used for the development environment than to
build something from scratch or using an external GUI package.)
There are many profound differences in between, for instance,
Interlisp-D's tools and those in Lisp Machine Lisp, most having to do
with the theme of lots of windows with easily accessible menu actions
vs. relatively few windows with elaborate menu structures.
(Typically a Lisp Machine user would have one Emacs window open in
which to do all editing, one File Browser, etc.) I remember
hearing many jeers from Lisp Machine folks about all the stupid
support facilities in Interlisp -- things like spelling correction and
history list -- coming largely from the macho
real-hackers-don't-use-tools attitude, revealed by comments such as
"By the time the DWIM facility figures out an alternative, asks
me to confirm it, and waits for my response, I could have just retyped
the input myself.".
For the past 20+ years I have been teaching, mentoring, and
providing technical support to students and developers in object
technologies (among other activities). As someone who came to
technical maturity in Interlisp-D and Smalltalk -- West Coast software
development -- but ended up working with students and developers
accustomed to more traditional East Coast approaches to software
development it took me a very long time to get past an arrogant
disbelief that people just didn't see the Light when introduced to the
fabulous new world of West Coast tool-based software development, as
embodied in Interlisp-D and Smalltalk.
I have also worked extensively in Pascal, C, C++, Objective-C,
Java, Perl, Python, JavaScript (which actually is a very cool
instance-based object-oriented language much like self), and
undoubtedly a few I'm forgetting at the moment. I have used
different implementations of Lisp and Smalltalk and their development
environments. I have worked on just about every kind of
platform, except for embedded systems: card-punch batch mainframes,
teletype and glass-tty timesharing systems, intelligent terminals on
Unix systems, Lisp workstations, Unix workstations, Macs (which are
currently the best Unix machines around, by the way), and even Windows
(when I absolutely can't avoid it). I have worked with a wide variety
of development environments, and I even still use Emacs extensively.
I have gleaned ideas, tricks, techniques, inspiration, etc. from all
of these. Much of my arrogance has been tempered by all this
cross-cultural travel -- it has morphed into condescension ;-) .
I believe I have acquired a deep understanding of many social,
psychological, and cognitive factors that cause people to resist
change in general and to feel more comfortable with the more concrete
nature of text files even though they work less efficiently and
creatively than is possible in more "enlightened"
environments. Some people I work with still use vi instead of
Emacs, which in some ways is a similar difference. This all gets
very, very complicated. It is affected by institutional
requirements (as some have pointed out in this thread), by shared
technological cultures, by substantial variations in personality and
cognitive stle, and (as has also been discussed in this thread) how we
teach people about the wonderful New World to which we migrated (or
for those less encrusted with age than I, perhaps even born
in!).
I still grumble, rant, and rave when working outside of Lisp,
Smalltalk, or Python (which is really Smalltalk with a different, and
cognitively effective, syntax -- try it, you'll love it -- it's to
Perl what Smalltalk is to C++). I'm still frustrated with more
mundane development environments. I am still astounded at the
obtuseness and resistance of all the techie types I work with.
However, I long ago came to terms with the less enlightened, people,
languages, and environments -- I pretty much just write Lisp or
Smalltalk style code no matter what procedural language I'm working
in ;-).
(I'm certainly not alone in my insistence on a
Lisp/Smalltalk/Python style of development and coding. Perhaps
the most extreme example I've encountered was a project I consulted to
at an enormous Boston-based financial institution. It was
developing a very cool workstation-based trading system in Smalltalk
when the company decided to standardize on C++. Told that they
couldn't deliver a Smalltalk application, they just shrugged and a
compiler wizard who happened to be working on the project wrote a C++
code generator that processed their Smalltalk code, while they
continued to happily work in VisualWorks.)
I also spend a lot of time extending and customizing environments
(especially Emacs) that don't provide the facilities I require.
(Emacs isn't too bad because it is so strongly Lisp oriented in both
its implementation and its tools, and it is so entirely flexible given
its Lisp extension language and rich array of programmable
functionality.) Of course given a choice I'd still rather work
in Smalltalk, Lisp, or Python. (There is an excellent development
environment for Python that I am happy using.) And I have
hopes that rapidly multiplying and evolving Open Source development
tools and environments for traditional languages (which I mean to
include C++ and Java) will ultimately provide their users with
something very much like the Smalltalk development environment.
Incidentally, the distinction between source code edited in the
image and source code edited externally is a lot like that of the
so-called "compiled" vs. "interpreted" language
distinction. Languages by themselves are neither compiled nor
interpreted. Instead, it is a question of environment -- are
you working with a compiler that forces you to into a coarse-grained
edit-compile-execute cycle or are you working with an interpreter that
allows you not only to make fine-grained changes that take effect
immediately -- even within executing code -- but also to enter and
execute arbitrary bits of code. (And what exactly are you doing
inside an interactive debugger in a traditional sort of environment in
which programs are externally executed then compiled and loaded?)
Besides, the byte-code world that Smalltalk popularized has made that
distinction moot. Witness Java and Python or, more
interestingly, Jython which is a Java engine implementation of Python
that allows Java code to call Python code and vice versa.
So there. I started this as a quick note to point out from
my unusually long and cross-cultural perspective and especially from
my extensive experience with multiple Lisp environments I can see that
the issue of internal vs. external source code editing is not one of
language but of development environment. But this is all
entangled in so many other related aspects of the difference between
what we do in Smalltalk and what people do in traditional environments
that I found I couldn't just leave it at that. I hope you found
this worth slogging through. I particularly hope you find it
useful in explaining our world to both Lispers and
traditionalists.
-- Mitchell L
Model, Ph.D. MLM
Consulting
[hidden email] 42 Oxbow Road (508) 358-805 Wayland, MA 01778 ~~ Mentoring, training, & tool building for object,
knowledge, & web technologies
~~ Representation, processing, and display of complex information & knowledge, esp. scientific ~~ Interface design, usability evaluation, & productivity enhancement ~~ Commited to effective agile software development ~~ Specializing in bioinformatics, web technologies,
knowledge representation/management, and ontologies
~~ Expert in object-oriented design, programming, & languages (Lisp, Smalltalk, Python, Java, C++, etc.) ~~ Experienced in distributed architectures (CORBA, Zope, J2EE, OODBs, socket-based, etc.) ~~ Collaboration methods and technologies (Wiki uses & customizations, eXtreme Programming, IDE's, etc.) |
In reply to this post by Zulq Alam
Hello Zulq,
ZA> Herbert König wrote: >> Really try the TracingMessagesBrowser, it needs magma base additions >> and magma exceptions (don't have an image handy for correct names), >> all on SM. this was a source of confusion. Sorry for that. To clear it up: Ma base additions and Ma exception handling are not parts of Magma. I's a single install not directly via SM but via a HTTP MC repository. Or you manually download the three files and install TMB. ZA> I second Duncan's suggestion for putting it in the default 3.9 image and ZA> if you like I can try and help but bear in mind I am still learning. And I'm not the one to offer help to. Chris Muller is the author! Sorry for the confusion! Herbert mailto:[hidden email] |
In reply to this post by Sebastián Sastre
Of course, now that Macs are based on Intel as well - this should
make the whole thing lots easier - just support intel. On May 18, 2006, at 5:50 AM, Sebastián Sastre wrote: > Dear Goran, > > I'd love to see Exupery reach it's objetives and run squeak for > Windows (as I guess other would love to see it in Mac). Is a good > project > Squeak have. I'm favorable in all means to the improvements > exupery's is > trying to bring. I think is all "profit" for us all. > > cheers, > > Sebastian > >> -----Mensaje original----- >> De: [hidden email] >> [mailto:[hidden email]] En >> nombre de [hidden email] >> Enviado el: Jueves, 18 de Mayo de 2006 05:56 >> Para: The general-purpose Squeak developers list >> Asunto: Re: Technology of the technologies (WAS: A Lisper >> asks,"Am I supposed to like Smalltalk?") >> >> Hi! >> >> Hans-Martin Mosner <[hidden email]> wrote: >>> tim Rowledge wrote: >>>> Compiling straight to machine code is certainly doable; it simply >>>> involves a lot more work since you have to develop and >> optimise and >>>> debug a *lot* more stuff. For example, you'd have to rewrite the >>>> compiler, the debugger, the InstructionStream related classes and >>>> tools, any system that expects to write out methods, etc >> etc. Send >>>> enough money and I will arrange it for you. Discussions >> could start >>>> at, ooh, One *Million* Euros. >>> >>> Doable, but not really a good way to implement Smalltalk. >> >> And so what do you guys think of Exupery? I had the distinct >> impression that Exupery is exactly this (a sophisticated >> machine code compiler for >> Smalltalk) - and as long as Exupery can mop the floor with >> the regular VM performance wise - then why would it be "not >> really a good way"? >> >> If the reader don't know what Exupery is then look at the >> movie or read the handout: >> >> http://goran.krampe.se/blog/Squeak/ExuperyTalk2006.rdoc >> >> >> regards, Göran >> > > |
On 21-May-06, at 5:36 PM, Todd Blanchard wrote: > Of course, now that Macs are based on Intel as well - this should > make the whole thing lots easier - just support intel. Sadly this is almost true and I wonder how much damage a monoculture is going to cause in the long term. I don't think there has ever been a case where catastrophe didn't follow. Sort of good news is that the remaining major architecture is ARM, which utterly dominates non-desktop systems. Last year approximately 1.6*billion* ARMs were sold. I'm fairly sure that is a good bit more than sales of x86 units. Now if only we could do a decent job of using a load of ARMs instead of one or two x86. We'd save a lot of power but we'd have to start doing a better job of using multiple cpus effectively; but then we need to do that anyway. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Looks for the "Any" key. |
> Sort of good news is that the remaining major architecture is ARM,
> which utterly dominates non-desktop systems. Last year approximately > 1.6*billion* ARMs were sold. I'm fairly sure that is a good bit more > than sales of x86 units. Now if only we could do a decent job of using > a load of ARMs instead of one or two x86. We'd save a lot of power but > we'd have to start doing a better job of using multiple cpus > effectively; but then we need to do that anyway. I want an ARM workstation. I am being lead, inextricably, towards a vast conspiracy theory regarding all RISC workstations... =( -- Don't let your schoolwork get in the way of your learning. ### NEW E-MAIL: [hidden email] ### |
In reply to this post by timrowledge
tim Rowledge puso en su mail :
> Sadly this is almost true and I wonder how much damage a monoculture > is going to cause in the long term. I don't think there has ever > been a case where catastrophe didn't follow. > > Sort of good news is that the remaining major architecture is ARM, > which utterly dominates non-desktop systems. Last year approximately > 1.6*billion* ARMs were sold. I'm fairly sure that is a good bit more > than sales of x86 units. Now if only we could do a decent job of > using a load of ARMs instead of one or two x86. We'd save a lot of > power but we'd have to start doing a better job of using multiple > cpus effectively; but then we need to do that anyway. What think about X360 chip ? Could Microsoft go to some different what X86 in a future ? Edgar _________________________________________________________ Horóscopos, Salud y belleza, Chistes, Consejos de amor: el contenido más divertido para tu celular está en Yahoo! Móvil. Obtenelo en http://movil.yahoo.com.ar |
On Mon, 22 May 2006 11:39:06 +0200, Lic. Edgar J. De Cleene
<[hidden email]> wrote: ... > What think about X360 chip ? Could Microsoft go to some different what > X86 in a future ? > > Edgar What is a x360 chip? I learned and used IBM/360 assembler in the early 70' of the previous century, does x360 have anything to do with IBM's /360 series ? <grin> ;-) /Klaus |
Klaus D. Witzel puso en su mail :
> What is a x360 chip? I learned and used IBM/360 assembler in the early 70' > of the previous century, does x360 have anything to do with IBM's /360 > series ? <grin> ;-) > > /Klaus I mean the chip what IBM build for Microsoft Xbox 360 Game Console and what have 3 cores and could be a "super PowerPC" of super power. Life is odd if Apple go Intel and Microsoft to IBM chips, don't you think ? Maybe in a while Microsoft build computers with a decent OS on this chip (or some derivative) I support Big Endian and refuse break eggs ohterwise !! :=) Edgar ____________________________________________________ Esa persona especial te espera en Yahoo! Encuentros. ¡Dejate encontrar! http://ar.encuentros.yahoo.com/ |
In reply to this post by timrowledge
On 18.05.2006 21:42, tim Rowledge wrote:
> On 18-May-06, at 12:26 PM, Bryce Kampjes wrote: >> I could do something interesting with Exupery for a mere 100K Euros or >> so. Anything less isn't enough to give up the day job for a year or >> so. More money would of course buy more features and a larger >> team. ;-) > Of course, if someone gave me E1m you would get the 100k to be part > of the team, like several others. It would be a honour to work in such a team! But there is not just the technical task to get it work: it also would have to be made mature... (to get more millions ;-) , not just a joke!) Regards, Stephan > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Useful random insult:- Mind like a steel sieve. > > > > -- Stephan Rudlof ([hidden email]) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3 |
Free forum by Nabble | Edit this page |