Self-interest November 2000

self-interest@lists.selflanguage.org

13 participants
13 discussions

Blocks: Summary
by Dru Nelson 12 Jan '01

12 Jan '01

Thanks Jecel for the great Summary. The trick I was looking for was the read barrier when using blocks. Whenever they are about to be used as an argument for a message send, the 'push' instruction will bind a newly cloned block proto to the current method context (activation record). I was looking for something less expensive :) Dru Nelson San Mateo, California

8 26

Patterns in Self [was Re: delegation (was: prototypical analysis and design) ]
by cramakrishnan＠acm.org 02 Dec '00

02 Dec '00

Is it just me, or has anyone else experienced semiotic overload following the recent discussion? ;) David Ungar writes: > I actually did go through all the patterns in the GOF book, in > preparation for my recent panel. > In particular, only one of the object-creation patterns seemed legit to me. What do you think about double dispach? That's one of the GOF patterns, right... i can't remember anymore. I think it is still relevant in Self, since Self doesn't have multi-methods. Plus, i noticed that traits bigInt>>+ uses it. :) Bharat writes: > Unfortunately, I don't have access to a Sun computer anymore so I > can't run Self :-( Do you have access to a Macintosh? As far as all this patterns stuff goes, i've always thought Charlie Parker's comment on music theory is equally applicable to design patterns: "Learn that stuff, then forget it and just play [hack]". - sekhar -- C. Ramakrishnan cramakrishnan(a)acm.org

5 5

Re: [self-interest] Self on Solaris for Intel?
by tb＠mit.edu 01 Dec '00

01 Dec '00

Jecel Assumpcao Jr <jecel(a)merlintec.com> writes: > Gordon Cichon started rewriting the compilers to generate code for the > PC (on Linux, but it would be even simpler to make it work on Intel > Solaris) and I have looked into continuing this. Gordon's work was > released under the GPL (since he borrowed from "gas", there wasn't any > choice) and I was wondering what the people in this list think of > having the PC version of Self under a more restrictive license than the > Sparc and Mac versions (which is BSD-like). I think it would be absolutely horrible, and utterly useless to me. Join the Linux crowd, please.

5 7

Self on Solaris for Intel?
by Mike Daren 30 Nov '00

30 Nov '00

I was wondering, since what I would like is to be able to use Self on a PC, does anyone know much about Solaris for Intel vs. Solaris for Sun? Has anyone tried to compile the Sun Self source on Solaris for Intel? If not, does anyone have any opinion of the likelihood of it working? Mike Daren

3 2

Access to Sun systems
by Scott Spencer 30 Nov '00

30 Nov '00

I have seen some past posts on this board regarding some people not having access to Sun workstations.I have used Sun hardware available. Complete systems as well as upgrades.Any developers in need,send me an email at scott(a)recurrent.com and I'll help you out.

1 0

previous related work to delegation???
by Albertina Lourenci 28 Nov '00

28 Nov '00

Hi Selfers: > Then I fell in love with Self and abandoned programming in Beta. Perhaps you should reconsider this since Günther is wrong about his language being the first static one to implement delegation. It seems to me that Beta's "part-object inheritance" is exactly that. -- I think Jecel pointed out something intriguing. I abandoned Beta because it was not possible to implement the main model of my ecodesign model. I mean the one that deals with the architectonic object and the environment. But I tried first to be advised by Bent Bruun Kristensen from Aalborg University and also "author" of the Beta language. He was introducing important abstract mechanisms to model complex concepts. However he recognized that to extend Beta with these mechanisms was not priority because it would be too expensive. Complex Associations: abstractions in object-oriented modeling from OOPSLA' 94 is more similar to delegation than "part-object inheritance". However it is too charged with the notion of hierarchy due to the class mentality and it loses the free flavour of delegation. However his diagrams are pretty good and they are not flat and loose like those from Günther. However the next abstraction mechanism created by Kristensen Activities: abstractions for collective behavior from ECOOP" 96 in LNCS 1098 enabled me better to build a bridge between my ecodesign model and the class-based languages. Kristensen and May even compared the activity abstraction to design patterns, especially the Mediator in an implementation project/In both papers Kristensen offers a list of related work. So I ask is this related work a previous attempt to introduce the gist of delegation into class based languages? Are they of different nature? Why Kristensen has never related this to delegation? Cheers Albertina .----------------------------------------------------------. | Albertina Lourenci | | PhD in Architecture and Urbanism | | post-doctorate researcher | | Laboratory of Integrated Systems University of Sao Paulo | | Avenida Professor Luciano Gualberto, 158 Travessa 3 | | CEP: 05508-900 | | Sao Paulo Sao Paulo State Brazil | | Voice: +55 011 818 5254 | | Fax: +55 11 211 4574 | .----------------------------------------------------------.

1 0

delegation versus design patterns
by Albertina Lourenci 27 Nov '00

27 Nov '00

Hello, all: Take a look at the Darwin project. It is an extension of Java supporting a form of delegation, so you get both classes and delegation. http://javalab.cs.uni-bonn.de/research/darwin/darwin_eng.html In Gúnther Kniesel's Ph.. thesis, page 165 he states: These are no problems of the deisgn patterns themselves, but of the underlying object model, which provides no suitable means to implement the patterns. He says to look at the book of the GOF page 309 where he states dynamic inheritance would be a desirable implementation for the state pattern. This was found in an earlier version of Self! The granularity of language support for design patterns is subject to debate. Some authors insist that every pattern needs its specific language support, others point out that this would be overwhelming and argue that the common needs of many different patterns should be identificied and supported by generic mechanisms. Günther thinks that delegation is such a generic mechanism.In page 28 he states Different sharing mechanisms are required not just by different types of software development processes but, more importantly, by different types of applications. Each type of sharing that is intrinsic to an application should easily be expressible. All types of sharing must be supported equally well by widespread production programming languages and conceptual modelling techniques. The functionality that motivated the synthesis: modelling of behaviour evolution. A model of object-oriented languages that support both behaviour evolution and unanticipated extension would be a highly desirable tool for every analyst, designer and programmer. Prototype and delegation-based languages can directly express changes of structure and behaviour but do not provide safety guarantees like static typing and guaranteed uniform structure of groups of objects, which are widely considered indispensable for production programming.. Well, when I started in 1988 to be concerned with programming languages of course I was fascinated with this story of types. I was afraid of Lisp because it is atyped. Besides the fact it doesn't feet my needs. Then in 1996 I read a paper written by Ole Agesen and published at ECOOP'95 where I realized that only in appearance Self is not typed for the user. The types are all included in the compiler. Sorry I do not have the paper with me here. So can you explain to me how this story works? Then I fell in love with Self and abandoned programming in Beta. Moreover Günther states Class-based languages essentially model object specific properties and their dynamic change by trying to mimic delegation.(page 39) The class-based variants of the two basic scenarios for modelling anticipated and unanticipated change by simulating delegation are illustrated in Figure 3.1 and 3.2. These scenarios can be regarded as meta-patterns that distill the technical essence common to varios design patterns The scenario illustrated in Fig.1 is characteristic for the flyweight, state and strategy pattern. The scenario in fig. 2 is characteristic for the bridge, decorator, chain of responsibility and proxy pattern. The first deals with anticipated property addition, deletion and update and the other deals with unanticipated property addition, deletion and update. Then in section 3.6 he proceeds examining how the operational details of delegation are simulated. (page 40-48). Honestly this kind of analysis I cannot even read. What's wrong here? I do not know because I am able to follow detailed papers like those written by Luca Cardelli or the above written by Ole Agesen. so In page 50 he concludes stating that the most promising approach to unanticipated behaviour evolution is the integration of delegation into statically typed class-based models. Can someone explain to me in a way that enables a right-sided thinker to understand this? I abandoned Beta because the Beta group showed in the book about the Mjolner environment the disadvantages of the environment concerned with a typed language. Then they build a bridge for me to understand an exploratory programming environment. I do not know much about Java but I know enough to be aware it is not superior to Self . Cheers Albertina -- .----------------------------------------------------------. | Albertina Lourenci | | PhD in Architecture and Urbanism | | post-doctorate researcher | | Laboratory of Integrated Systems University of Sao Paulo | | Avenida Professor Luciano Gualberto, 158 Travessa 3 | | CEP: 05508-900 | | Sao Paulo Sao Paulo State Brazil | | Voice: +55 011 818 5254 | | Fax: +55 11 211 4574 | .----------------------------------------------------------.

2 2

The nature of music was Re: [Fwd: prototypical analysis and design]
by Albertina Lourenci 24 Nov '00

24 Nov '00

Günter Kniesel wrote: Hi Gïnther: Well if you are not worried in saving Mother Earth, I am. I need OOP to build sustainable cities. I know most computer scientists prefer to build interplanetary stations when life on earth will not be possible anymore. Please don't take this as aggressive, but all my life orbits around this concern. Otherwise, the brightest computer scientists seem eager to see the take-off of the prototype paradigm. And gracefully you made public electronically all you do. I am asking for a grant to have facilities that will enable me to make all that I do available at the Internet. And above all I am an artist. I have just finished writing something about hermeneutics. Music is the most hermeneutic art. So for me a discussion like the one I am proposing is like mimicking a symphony. Why can't we play together? In real music, specially contemporary music dissonances are welcome. So why to get worried? Musicians say that dissonances are more difficult consonances. I read through your response fast. I have to go swimming now as part of my health recovery. All the information is my head is fuzzy, so I cannot agree or disagree if you said delegation is better or not than patterns. As far as I know I have to read at least your whole chapter 8 Applications (165-178) and many more papers about design patterns to conclude something. You would help my poor brain to stay fit if you agreed in cooperating. Please be gentle. There is no better way to learn than discussing and making errors. Randy Smith made a good contribution to this through his Distributed tutored video instruction. I loved it and it emphasized the musical nature of Self. As soon as I can, I will dialogue with you all about Günther's statements. Best wishes Albertina > Dear all, > > > Bharat Bedia wrote: > > > > > Firstly my apologies if people find > > > this thread off topic. If they can point me to an appropriate place > > > then I'll glad take the conversation elsewhere. > > My appologies too, to anyone not interested in this discussion. > However, since I've been cited in a way that lends itself > to being misinterpreted I have to make a few statements > for the people who read the previous mails. > > Any followup message will be sent just to those who > participat(ed) in this discussion. > > By the way, Albertina, there was no point in asking the whole > world what I could have possibly meant with a certain passage > of my PhD thesis. Just send ME your questions, I'll be happy to > answer them. > You can still make your conclusions public if you feel the need. > > Guenter > > ----------------------------------------------------------------------- > Albertina Lourenci wrote: > > > > Günther Kniesel seems to be making a good job in his Ph.D Thesis > > (Take a look at the Darwin project. It is an extension of Java > > supporting a > > form of delegation, so you get both classes and delegation. > > > > http://javalab.cs.uni-bonn.de/research/darwin/darwin_eng.html > > > > ... snip ... > > > > And what is best he argues that the complexity of many patterns > > is not intrinsic, it can often be seen as resulting from poor language > > support. (Kniesel, Ph.D thesis page 165 at the bottom). > > So I invite him to join our discussion and show to us how > > delegation implements the design patterns better. > > Well, the GOF itself mentions several times the problems involved > in implementing patterns like strategy, state, etc and > refer to Self as an elegant alternative. In my phd thesis you can > compare the code in the implementation chapter to the code in the > applications chapter. > > If you have delegation you can implement an "overriding decorator" > which provides behaviour that will take effect in the > context of the "decorated" object by essentially one keyword: > > class Decorator extends Whatever { > > protected final delegatee Decorated _decorated; > ^^^^^^^^^ > Decorator( Decorated d) { _decorated = d } > > // ... any methods > > } > > Decorator will automatically be a subtype of Decorated, > locally unimplemented messages will automatically be delegated > to objects referenced by _decorated and > methods in Decorator will override methods from Decorated. > This works even if there are no hard-coded hooks in Decorated > to enable such an extension. *Unanticipated* extension is > not possible with patterns. > > If you do not have delegation as a first class language feature > you have to anticipate the extension and hand-code anything that > is described in the "implementation" chapter. > And that is substantially more than what is discussed in most > "delegation-like" patterns. For instance, the problem of direct > access to public variables is usually ignored. > > I'd say that the step > - from "many, many lines of code all over your application" to > "one keyword" and > - from "imposible" to "possible" in the unanticipated extension > case > is a significant simplification ;) > > > Jan Bosch wrote an interesting article "Design Patterns as Language > > Constructs" in Journal of Object Oriented Programming May 1998 > > > > He identifies four problems associated with their implementation > > using conventional object-oriented languages. First, the traceability > > of a design pattern in the implementation is often insufficient; the > > design pattern is lost. Second, because several patterns require an > > object to forward messages to other objects to increase flexibility, > > the self problem often occurs. Third, because the pattern > > implementatin is mixed with the domain class, the reusability > > of pattern implementations is often limited. Finally, > > implementing design patterns may present significant > > implementation overhead for the software engineer. > > I use to call patterns like state, strategy, decorator, flyweight, > etc "split object patterns". They share the basic idea of splitting > one conceptual object into (at least) two implementation objects > that should act like one. For split object patterns, delegation > is the natural implementation technique. It eliminates all the > shortcommings addressed by Jan Bosch. > > > > > At the right moment based on Günther Kniesel's PHD thesis > > > > I am trying to figure out why he argues that delegation is > > > > far better than design patterns. > > I did not say that delegation is better than (any) design patterns. > Obviously delegation is completely unrelated to tons of patterns > (e.g. singleton, template method, factory method, etc). > > What I say and mean is that delegation is the best way to implement > split object patterns. Put differently, it is not an alternative to > the patterns themselves, because it preserves their essential ideas, > but it simplifies their implementation up to the point where it > becomes trivial. > > With delegation the implementation of many different patterns > is so similar (because all the "simulation noise" vanishes) > that it becomes obvious that all split object patterns > are essantially instances of two basic cases: > - unanticipated, identity-changing extension (decorator-like) > - anticipated, identitiy-preserving splitting (strategy-like) > (See the "Applicatons" chapter of my thesis). > > ------------------------------------------------------------------- > Albertina Lourenci wrote: > > > > > > > > Hi Thomas: > > Well I am overstressed and I may be coopting what I read to tune with > > what I expect but let us examine this passage from Günther's PhD > > thesis (page 49-50) > > > > Thus the application of design > > patterns for simulating BEHAVIOUR EVOLUTION CAN > > IMPEDE REUSE (OF EXISTING CODE AND DESIGNS) > > AND COMPLICATE PROGRAM MAINTENANCE, achieveing > > \the opposite of what is widely regarded as a main benefit of OOP. > > Therefore, extension of traditional class-based object models > > by a mechanism for unanticipated behaviour evolution is > > ultimately required. > > > > I invite Günther to throw light in this passage. But I interpreted > > as delegation is better than design patterns. > > Just shift the stress in your citation an you'll get it: > > > Thus the application of > > DESIGN PATTERNS FOR SIMULATING BEHAVIOUR EVOLUTION > > can impede reuse ... > > That's it: I do not refer to patterns in general but > to PATTERNS FOR SIMULATING BEHAVIOUR EVOLUTION. > Or, more general, to "split object patterns". > > ------------------------------------------------------------------- > > Thomas Kuehne <kuehne(a)informatik.uni-kl.de> wrote: > > > > Hi Albertina, > > > > as far as I know Günther (I know him) does not claim that > > delegation is better than design patterns. > > I reckon he says that with delegation most design patterns > > are easier to implement. > > Thanks Thomas. That is just what I meant. > > Regards > Guenter > > ----------------------------------------------------------------------- > Guenter Kniesel e-mail: gk(a)cs.uni-bonn.de > Computer Science Department III Phone: (+49-228) 73-4511 > University of Bonn Fax: (+49-228) 73-4382 > Roemerstr. 164 > D-53117 Bonn Office: A118 > ----------------- http://www.cs.uni-bonn.de/~gk/ ------------------ -- .----------------------------------------------------------. | Albertina Lourenci | | PhD in Architecture and Urbanism | | post-doctorate researcher | | Laboratory of Integrated Systems University of Sao Paulo | | Avenida Professor Luciano Gualberto, 158 Travessa 3 | | CEP: 05508-900 | | Sao Paulo Sao Paulo State Brazil | | Voice: +55 011 818 5254 | | Fax: +55 11 211 4574 | .----------------------------------------------------------.

2 4

prototypical analysis and design
by Albertina Lourenci 24 Nov '00

24 Nov '00

Subject: [self-interest] Prototypical analysis and design From: "Bharat Bedia" <bharat(a)lickbau.demon.co.uk> To: self-interest(a)egroups.com Date: Wed, 15 Nov 2000 01:45:16 -0000 Dear Bharat: I am also interested in showing the superiority of the prototype paradigm to express complex concepts. There are many people dealing with prototypes or delegation. But no language has reached the level of development of the Self language. At the right moment based on Günther Kniesel's PHD thesis I am trying to figure out why he argues that delegation is far better than design patterns. Since I am an architect and I was expected to unfold my PHD under the advising of Christopher Alexander, the author of the A Pattern Language, I would not deny the importance of this trend. My contact with Alexander began in 1990 and lasted until 1992. Exactly at this time computer scientists showed interest in mimicking in computer science what he did in architecture. I have unfolded my own ecodesign model - or the domain dependent model entitled THe model of Primary, Secondary and Tertiary Waves to plan and design sustainable cities. It is an appplication of catastrophe theory, graph theory, semiotics, symmetry groups of the plane and the dotless plane. Its hermeneutic nature tunes well with the hermeneutic (really musical) Self nature. I am trying to unfold a tutorial in Self and so the core of the tutorial necessarily must deal with your concerns, because it is very complex to implement concepts about sustainable cities. Alexander agrees it is far more complex and complete than his A Pattern Language. What I object to A Pattern Language is that Chris had not developed a correspondent geometric modeling (even less a computational modeling). Likewise the Gang of the Four has not focused on developing language constructs that would correspond straightforwardly to the design patterns. I am reading an interesting paper from Jan Bosch that shows how to do this. Unfortunately he does not use delegation. Kniesel in his thesis wants to show the superiority of delegation but I am still reading through his thesis and the papers I gathered and I have no conclusion. But I would be happy if the researchers joined us in this important discussion. I've read through the book "Prototype-Based Programming: Concepts, Languags and Applications" which provided lots of useful background material. Like OO analysis & design, I'm interested in analysis, modelling & application design techniques for the object-based prototypical paradigm. The implementation would be done in an object-based language like Self. Can anyone point to any online research material or book reference ? I am exhausted now and recovering...But I hope we can trigger off a discussion and I promise to give the references gladly. Best wishes Albertina Thanks in advance, Bharat --------------------------------------Bharat@ -- .----------------------------------------------------------. | Albertina Lourenci | | PhD in Architecture and Urbanism | | post-doctorate researcher | | Laboratory of Integrated Systems University of Sao Paulo | | Avenida Professor Luciano Gualberto, 158 Travessa 3 | | CEP: 05508-900 | | Sao Paulo Sao Paulo State Brazil | | Voice: +55 011 818 5254 | | Fax: +55 11 211 4574 | .----------------------------------------------------------.

4 10

[Fwd: [self-interest] prototypical analysis and design]
by Albertina Lourenci 22 Nov '00

22 Nov '00

Hi Thomas: Well I am overstressed and I may be coopting what I read to tune with what I expect but let us examine this passage from Günther's PhD thesis (page 49-50) Class-based systems. Traditional class-based systems do not effectively support behaviour evolution. The class-based model cannot easily express changes in the structure or behaviour of an object. Required behaviour evolution has to be hard-coded into application programs. As seen in the previous section, manually coded behaviour evolution is a possible workaround for the limitations of the class-based model but not a satisfactory solution. The essence of various design patterns suggested in this context are more or less faithful simulations of delegation. These simulations do not achieve the full functionality of delegation (3.6.3) Because the functionality missing from the language is simulated by a set of cooperating classes, these classes tend to be tightly dependent on each other in ways that are not grounded in the application but just in the technical details of the pattern. Such additional dependencies and assumptions built into the design require consistent changes in a complete hierarchy of classes even for small unanticipated changes int he application logic, e.g. addition of a method to a class of addition of a new class (see 3.6.2.3 and 3.6.3). Thus the application of design patterns for simulating BEHAVIOUR EVOLUTION CAN IMPEDE REUSE (OF EXISTING CODE AND DESIGNS) AND COMPLICATE PROGRAM MAINTENANCE, achieveing \the opposite of what is widely regarded as a main benefit of OOP. Therefore, extension of traditional class-based object models by a mechanism for unanticipated behaviour evolution is ultimately required. I invite Günther to throw light in this passage. But I interpreted as delegation is better than design patterns. And I put forward that both Christopher Alexander and I recognize the failure of "A pattern language" to grasp the essence of the nature of architecture and urban design. The granularity of the patterns is too coarse. The granularity of my ecodesign model is fine. I would say it will be very hard to build a finer ecodesign model. It grasps the macro as well as the micro aspects involved in the design process. I mean it deals with modeling geoengineering and climate as well as with comfort zone and the ergonomics of the behavior of the human being. If architecture is not translated into forms it is not architecture And there is no geometric modelling in A Pattern language. My geometric modelling consists of the theory of tilings, (based on the graphical artist Maurits C. Escher , I extended the theory of tilings with the notion of prototiles, tiles of different formats - so I can reproduce through this concept exactly what an organic designer would do. I mean I can layout the behavior of the human being around the furniture and crystalize it with this concept), symmetry groups of the plane and the dotless plane. Similarity and conformal symmetry groups are fractals!!!The two most importants models to model phenomena are catastrophe theory and chaos theory (as far as I know fractals are within chaos theory context). Through the relationship of the subgroups of the crystallographic groups of the plane as well as the notion of metamorphosis so well grasped by Escher in his xylogravures I arrived at the essence of the free plan. I mean I am building a knowledge based system in a seamless process. The domain dependent model follows the geometric modeling and I hope through delegation I can achieve a computation model that is "isomorphic" to the previous two. I love Alexander's work although I have read his book only after I had finished my master's dissertation in 1988. And I was already involved with Lionel March the head of the Graduate School of Architecture and Urban Planning at UCLA. Lionel was Alexander's colleague at Cambridge. He introduced in his PHD thesis in the sixties the notion 'that architects since Leonardo da Vinci have applied symmmetry groups of the plane to architecture. In this century Frank Lloyd Wright, the greatest formmaker of this century as well as Le Corbusier applied symmetry groups to their designs. However they applied the traditional notion of tilings. The outcome of their work is not a free plan, a fundamental paradigm of the Modern Movement with respect to the inner layout of an apartment. Let's feel how Alexander is: I sleep in a room that has windows in two sides. It is simply gorgeous. My house is located in a villa that was built in 1903. So let's see what Alexander writes on page 745. prepare to knit the inside of the building to the outside, by treating the edge between the two as a place in its own righ, and making human details there: 159. light on two sides of every room 160. building edge 161. sunny place 162. north face 163.outdoor room 164.street windows 165. opening to the street 166.gallery surround 167. six-foot balcony 168.connection to the earth one reads on page 747 ...once the building's major rooms are in position, we have to fix its actual shape: and this we do essentially with the position of the edge. The edge has got its rough position already from the overall form of the building - Wings of Light (107), positivive outdoor space (106) Long Thin House (109), Cascade of roofs (116).This pattern now completes the work of Wings of Light (107), by placing each individual room exactly where it needs to be to get the light. It forms the exact line of the building edge, according to the positin of these individual rooms. The next pattern starts to shape the edge. Well The two projects I designed to illustrate my design model curiously if they don't have windows in both sides light falls from the top of the roof, so one can see the moon, the sun, the flowers with different colours all around the year. I love windows at the corners. And I love to let light fall from the sky. I also designed a project for a small church. When I applied the formula to see if I had calculated the right amount of area necessary for daylight illumination and natural ventilation they fit the needs perfectly well. Indeed Alexander and I were anxious to work together. However Berkeley was not a center of OOP in 1990 -1992. The only interesting researcher was STephen Omohundro the author of the Sather Language, an optimization of the Eiffel language from International Computer Science Institute and so the Brazilian agencies made up their minds not to send me to Berkeley., Lionel March and the CAD group finally recognized I was an expensive student and UCLA could not cope with my needs, not only in terms of facilities as well as human resources. Cheers Albertina Hi Albertina, as far as I know Günther (I know him) does not claim that delegation is better than design patterns. I reckon he says that with delegation most design patterns are easier to implement. > Kniesel in his thesis wants to show the superiority of delegation but > I am still reading through his thesis and the papers I gathered and I > have no conclusion. I'd be very interested in the list of papers you gathered for this topic and maybe even your opinion on them. I am currently looking at delegation as a means to modeling as opposed to class based modeling how it is usually done. I am be happy to share my findings with you and the list but at the moment I am trying to get a handle on prototyping, i.e., find out when you would prefer it when modeling. Cheers, Thomas -- Dr. Thomas Kuehne 0178 4314387, http://www-agce.informatik.uni-kl.de/~kuehne The difficulty in doing research is to find the right questions so that all the answers come easily. -- TK -- .----------------------------------------------------------. | Albertina Lourenci | | PhD in Architecture and Urbanism | | post-doctorate researcher | | Laboratory of Integrated Systems University of Sao Paulo | | Avenida Professor Luciano Gualberto, 158 Travessa 3 | | CEP: 05508-900 | | Sao Paulo Sao Paulo State Brazil | | Voice: +55 011 818 5254 | | Fax: +55 11 211 4574 | .----------------------------------------------------------.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest November 2000