Oberon – The Overlooked Jewel [pdf](ics.uci.edu)
ics.uci.edu
Oberon – The Overlooked Jewel [pdf]
https://www.ics.uci.edu/~franz/Site/pubs-pdf/BC03.pdf
This article presents selected facets of Project Oberon, the latter of [Pascal creator Niklaus] Wirth’s two large system-level design efforts. The leitmotiv of this project was a quote from Einstein, “make it as simple as possible, but not simpler”. And if any further evidence was still needed, Oberon provided the conclusive proof for Wirth’s mastery of The Art of Simplicity.
16 comments
I tried Oberon once and have to say that it was way ahead of its time. Not only did the author (of the linked paper) invent one of the first JIT compiled systems, but also the ability to execute code with a mouse click (similar to Rob Pike's ACME editor) is---for a systems programming language---still not available today.
There were several novel research ideas tried for the Oberon system. I remember there was some paper called "Active Text" that allowed putting videos into code comments. (Probably that could have been done in Smalltalk, too.)
Finally, all of the books explaining details are heartily recommended. Wirth's compiler book (referred to at HN several times) is a classic easy-going introduction (the Oberon-0 grammar fits on only two pages IIRC! [1]), his algorithm book (also available for download, also referred to multiple times at HN) has some of the nicest descriptions that I did not find anywhere else (showing a divide-and-conquer approach to computing the median [near the Quicksort treatment]; plus polyphase sort, which might be useful again in data centers), and finally the Project Oberon book contains some unique treatment on system software that is not easily found anywhere else. For example, it contains the details on what's called PieceLinkText, which is the (at least AFAIK) best data structure to implement a text editor and it's operations. (Predating rope-strings by a fair amount of time, too.)
edit:
[1]: just checked my own copy; Oberon-0's grammar actually fits on one page, the full Oberon grammar fits on two pages!
[2]: URLs:
- Compiler book: http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf
- Algorithm book: http://www.inf.ethz.ch/personal/wirth/books/AlgorithmE1/AD20...
- Project Oberon: http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pd...
There were several novel research ideas tried for the Oberon system. I remember there was some paper called "Active Text" that allowed putting videos into code comments. (Probably that could have been done in Smalltalk, too.)
Finally, all of the books explaining details are heartily recommended. Wirth's compiler book (referred to at HN several times) is a classic easy-going introduction (the Oberon-0 grammar fits on only two pages IIRC! [1]), his algorithm book (also available for download, also referred to multiple times at HN) has some of the nicest descriptions that I did not find anywhere else (showing a divide-and-conquer approach to computing the median [near the Quicksort treatment]; plus polyphase sort, which might be useful again in data centers), and finally the Project Oberon book contains some unique treatment on system software that is not easily found anywhere else. For example, it contains the details on what's called PieceLinkText, which is the (at least AFAIK) best data structure to implement a text editor and it's operations. (Predating rope-strings by a fair amount of time, too.)
edit:
[1]: just checked my own copy; Oberon-0's grammar actually fits on one page, the full Oberon grammar fits on two pages!
[2]: URLs:
- Compiler book: http://www.ethoberon.ethz.ch/WirthPubl/CBEAll.pdf
- Algorithm book: http://www.inf.ethz.ch/personal/wirth/books/AlgorithmE1/AD20...
- Project Oberon: http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pd...
The book "Project Oberon: The Design of an Operating System and Compiler" http://www.amazon.com/Project-Oberon-Design-Operating-Compil... contains a detailed explanation of the design for the Oberon compiler and operating system. Not only it is well written with clear explanations, but it also includes the full source code for the compiler and operating system in less than 550 pages!
I learned some interesting compiler techniques from reading that book.
I learned some interesting compiler techniques from reading that book.
Pascal was the first "real" language I learned (BASIC doesn't count) with a compiler that ran on the IBM mainframe at work. From then it was an easy transition to a Pascal compiler from Motorola that produced code for the 68000. Tellingly, the Motorola compiler had a bunch of extensions that made programming a lot easier and mirrored the features Wirth introduced in Modula-2. In some ways, learning C was a step backwards, although in terms of my marketability it was absolutely necessary.
The 68000 was a wonderful CPU, and the last one that I genuinely enjoyed writing assembler for. A sane number of registers, a very orthogonal instruction set, good performance, non-segmented RAM, and high-level. If we had to have a 1980s CISC chip be The One True ISA, I really wish that 68000, not x86, could've been it.
Burroughs B5000.
Stack based instruction set designed from scratch for programmers (and implementing high level languages). tagged architecture. Single cycle context switching. It was also a secure architecture directly on hardware, tasks couldn't even generate addresses to munge another tasks data if they wanted to.
Wish someone would bring that back.
https://en.wikipedia.org/wiki/Burroughs_large_systems
Stack based instruction set designed from scratch for programmers (and implementing high level languages). tagged architecture. Single cycle context switching. It was also a secure architecture directly on hardware, tasks couldn't even generate addresses to munge another tasks data if they wanted to.
Wish someone would bring that back.
https://en.wikipedia.org/wiki/Burroughs_large_systems
Yes, yes, yes! C was a HUGE step backward. And also how I paid the rent in the 90s. ANSI C had the advantage of being portable, though. Even if C, and especially C++, tended to be somewhat deadly.
Turbo Pascal was about 90% of the speed of C with 30 to 50% of the bugs. And yes, I could use pointers and pointer arithmetic in TP if I wanted to bypass array bounds checking, but I had the choice when I needed to do so. Memory management is a lot easier with Pascal functions (and I assume Module/Oberon) than C as well, since the caller allocates the return value. Alternately, you can pass (always non null) values by reference instead of having to use (maybe null) pointers.
Turbo Pascal was about 90% of the speed of C with 30 to 50% of the bugs. And yes, I could use pointers and pointer arithmetic in TP if I wanted to bypass array bounds checking, but I had the choice when I needed to do so. Memory management is a lot easier with Pascal functions (and I assume Module/Oberon) than C as well, since the caller allocates the return value. Alternately, you can pass (always non null) values by reference instead of having to use (maybe null) pointers.
The article feels incomplete, as are many articles that praise systems of the past.
Why did Oberon become obsolete? I suspect we could learn a lot from an answer to this question.
Why did Oberon become obsolete? I suspect we could learn a lot from an answer to this question.
That is simple. Oberon was a full-stack environment. Where full-stack means it typically provides OS-like and filesystem-like elements. Where as a mainstream language such as Python molds itself to the existing OSes, Oberon tries to take on the whole thing.
These have a history of failing. Not because they are poor at some aspects of being an operating system. But because they force a programmer to give up all their tools. You can't typically use your favorite source control or text editor. (This is getting better as VM interoperability improves.)
So Oberon shares the same fate as other full-stack languages like Smalltalk and Forth. (I'm sure you can think of a few.) Awesome at what they do, but never gains traction.
These have a history of failing. Not because they are poor at some aspects of being an operating system. But because they force a programmer to give up all their tools. You can't typically use your favorite source control or text editor. (This is getting better as VM interoperability improves.)
So Oberon shares the same fate as other full-stack languages like Smalltalk and Forth. (I'm sure you can think of a few.) Awesome at what they do, but never gains traction.
> Where as a mainstream language like ... molds itself to the existing OSes ...
Oberon the system was an environment; Oberon the language was a language.
The problem is that the C environment is so dominant that we don't usually think of C in the same terms, or remember that systems languages like Oberon are intended to be used for writing OS-like and filesystem-like elements.
Oberon the system was an environment; Oberon the language was a language.
The problem is that the C environment is so dominant that we don't usually think of C in the same terms, or remember that systems languages like Oberon are intended to be used for writing OS-like and filesystem-like elements.
Interesting! So a language might be a failure if it is only for writing OSes/FSes/drivers? That if it is not good for applications, it will never be used by application programmers and the language will never be popular?
Come to think of it, even a "systems" language like Go is still used primarly for writing applications.
How useful is Oberon (the language) for working with filesystem-likes outside of Oberon (the system)?
Come to think of it, even a "systems" language like Go is still used primarly for writing applications.
How useful is Oberon (the language) for working with filesystem-likes outside of Oberon (the system)?
Go isn't a systems language by that definition of systems language: https://news.ycombinator.com/item?id=1697443
And all systems langauges will be used heavily for writing applications because there is typically a huge benefit of developing in the same language as the underlying OS.
And all systems langauges will be used heavily for writing applications because there is typically a huge benefit of developing in the same language as the underlying OS.
> So a language might be a failure if it is only for...
And that niche is already occupied by the one true programming language.
> working with filesystem-likes
If you mean developing applications, there was „BlackBox Component Builder“
http://www.oberon.ch/blackbox.html
And that niche is already occupied by the one true programming language.
> working with filesystem-likes
If you mean developing applications, there was „BlackBox Component Builder“
http://www.oberon.ch/blackbox.html
Forth isn't suitable for large systems or large teams. And Smalltalk has a "image" problem.
Bash is not suitable for large systems/teams. MySQL depends on image blobs.
However both of these are wildly popular. They slot into existing systems, making them easy to pick up and use.
However both of these are wildly popular. They slot into existing systems, making them easy to pick up and use.
The Smalltalk image problem is basically the same as the Oberon full-system problem. They have the same undesirable consequences.
Have you used Smalltalk?
Yes, and I like it.
In that case, please say specifically what you mean by "the same undesirable consequences".
What we're all talking about here is that Oberon, Smalltalk, Forth, etc. all live in obscurity. Having an image seems to spell doom for wide adoption. People like to integrate systems with their other tools. Smalltalk can examine the outside system, but (except for oddities like GNU Smalltalk) the outside system gets a completely opaque box it can't do anything with. One could argue that ZODB had the same consequences.
I don't think there is a technical problem with images (which I think is what you're hoping to pounce on and debate ad nauseum), they just demand the rest of the ecosystem be built around them. This seems to be a trick you can get away with once per computing industry. Lots of people have come up with better image structures/concepts than hierarchical blobs of binary data, but they never seem to get significant traction because they are closed.
I don't think there is a technical problem with images (which I think is what you're hoping to pounce on and debate ad nauseum), they just demand the rest of the ecosystem be built around them. This seems to be a trick you can get away with once per computing industry. Lots of people have come up with better image structures/concepts than hierarchical blobs of binary data, but they never seem to get significant traction because they are closed.
> what you're hoping to pounce on
I'm just trying to untangle the different things you might be talking about - whether you're talking about development tools or run-time monitoring tools?
I'm just trying to untangle the different things you might be talking about - whether you're talking about development tools or run-time monitoring tools?
afaict Smalltalk did not have an "image" problem with programmers who actually used Smalltalk images.
However, FORTH became quite flexible, spawned a family of Forths, and they're quite common these days. You just don't realize it. Chuck Moore was very responsible for this; he claims that there is no single canonical FORTH, but merely the Forth that you build today for the task that you must handle right now. (He is not a big fan of ANS FORTH.)
>>Why did Oberon become obsolete?<<
2nd paragraph -- "In his modest Swiss Engineer’s manner, and quite untypical for a celebrated academic, Wirth consistently avoided exploiting the initially high-speeding Pascal bandwagon for the purpose of “marketing” his subsequent ideas. Indeed, he even refrained from giving his later programming-language creations names such as “Pascal-2”, “Pascal Plus”, or “Pascal-2000” but instead opted first for “Modula”, and then “Oberon”. Both of these languages would probably have been considerably more successful if the connection to the Pascal legacy had been made in their name, but this would have run counter to Wirth’s view that a marketer he is not."
Also see "Pascal and its Successors" http://www.swissdelphicenter.ch/en/niklauswirth.php
2nd paragraph -- "In his modest Swiss Engineer’s manner, and quite untypical for a celebrated academic, Wirth consistently avoided exploiting the initially high-speeding Pascal bandwagon for the purpose of “marketing” his subsequent ideas. Indeed, he even refrained from giving his later programming-language creations names such as “Pascal-2”, “Pascal Plus”, or “Pascal-2000” but instead opted first for “Modula”, and then “Oberon”. Both of these languages would probably have been considerably more successful if the connection to the Pascal legacy had been made in their name, but this would have run counter to Wirth’s view that a marketer he is not."
Also see "Pascal and its Successors" http://www.swissdelphicenter.ch/en/niklauswirth.php
My guess is that it was a non-US based, non-commercial project that was too ahead of it's time. Think of a Canon Cat on steroids crazy. By this time C had already "won" as the system programming language for large systems.
Plus when my buddies and I were interested in it, there was no hardware in the States to run it on. It did get one of our number into the PC532 scene and I came up a semi-interesting idea to turn graphics chips into encryption engines based on the NS32GX32 instruction set.
Plus when my buddies and I were interested in it, there was no hardware in the States to run it on. It did get one of our number into the PC532 scene and I came up a semi-interesting idea to turn graphics chips into encryption engines based on the NS32GX32 instruction set.
Yeah, in high school in the early 00s I was a big Oberon fan. I had booted the system from diskette on my windows computer. I also had Blackbox and built some really basic things. Overall it was a huge amount of fun, and I have fond memories of the Object Inspector and connecting references together on forms and stuff. It was really Brett Victor's "tangled" before Brett Victor came along with these ideas. Actually, it was a lot like hypercard, based on what I've read of hypercard. LayLa was a cool layout system kind of like flexbox. They had a lot of cool applications. The flat filesystem was weird (no directories), but it was certainly simple.
Over time it was so disappointing, though, that the system never went anywhere. My biggest takeaway was to not be such a programming language purist. Now I'm a javascript fan. It's not pure or perfect, but it's simple and it nails the important things. Plus for the foreseeable future it's the most widely supported computer language in existence. Simplicity and pragmatism are really key.
Over time it was so disappointing, though, that the system never went anywhere. My biggest takeaway was to not be such a programming language purist. Now I'm a javascript fan. It's not pure or perfect, but it's simple and it nails the important things. Plus for the foreseeable future it's the most widely supported computer language in existence. Simplicity and pragmatism are really key.
So, let's say I wanted to take a spin in Oberon today. Is that even still feasible, or is it just dead? I can't tell what I'd download to get started from the ETH Oberon page, nor do I have any idea what the library and development community would look like at this point.
A2 (nee Bluebottle) is the successor to Oberon, but remains
compatible in the sense that you can run the classic Oberon
System 3 as an application within Bluebottle.
http://bluebottle.ethz.ch/download.html
(My Eyes! The goggles do nothing!)
You could probably boot the ISO image in a virtual machine (VMWare or such).
There's a version of Bluebottle that runs as an application on Windows. Here (A2.r4701.zip):
http://www.ocp.inf.ethz.ch/wiki/OCP/WinAos
A few things to note:
(1) unpack the zip file (2) Open a2\WinAos\Aos.EXE
Note that Aos.EXE will run full screen. There's no obvious way to minimize or hide it, but you can Ctrl-TAB back to another program.
The system log is displayed by default near the upper left corner of the screen. You'll want to close this as Oberon and Aos can not both be managing it at the same time.
(3) Close the System log by clicking the red button in the upper right corner of the System log window.
You'll see a palette of buttons in the lower left corner of the screen. We'll be using that to start Oberon.
There are two ways to start the hosted Oberon: full screen or within an Aos window. Since we're here for Oberon, we'll start it full screen.
(4) Click "Deveop" in the top row of buttons. (5) Click "Oberon FullScreen" which is revealed as the left-most bottom-most button.
To exit Oberon click "Quit" in Popups.Tool and choose "Shutdown".
To exit Aos click "System" and then "Shutdown" on the button palette in the bottom left of the screen.
Happy exploring!
http://bluebottle.ethz.ch/download.html
(My Eyes! The goggles do nothing!)
You could probably boot the ISO image in a virtual machine (VMWare or such).
There's a version of Bluebottle that runs as an application on Windows. Here (A2.r4701.zip):
http://www.ocp.inf.ethz.ch/wiki/OCP/WinAos
A few things to note:
(1) unpack the zip file (2) Open a2\WinAos\Aos.EXE
Note that Aos.EXE will run full screen. There's no obvious way to minimize or hide it, but you can Ctrl-TAB back to another program.
The system log is displayed by default near the upper left corner of the screen. You'll want to close this as Oberon and Aos can not both be managing it at the same time.
(3) Close the System log by clicking the red button in the upper right corner of the System log window.
You'll see a palette of buttons in the lower left corner of the screen. We'll be using that to start Oberon.
There are two ways to start the hosted Oberon: full screen or within an Aos window. Since we're here for Oberon, we'll start it full screen.
(4) Click "Deveop" in the top row of buttons. (5) Click "Oberon FullScreen" which is revealed as the left-most bottom-most button.
To exit Oberon click "Quit" in Popups.Tool and choose "Shutdown".
To exit Aos click "System" and then "Shutdown" on the button palette in the bottom left of the screen.
Happy exploring!
Thanks! Perfect. That's enough of a tutorial I can poke around.
Oberon used to be taught (possibly still is?) as a second language at Oxford (after Haskell).
As far as I'm aware, the Oxford Oberon compiler is still alive and has versions available for all platforms.
It is available here: http://spivey.oriel.ox.ac.uk/corner/Oxford_Oberon-2_compiler
Just in case, we used to sell a standalone Oberon-2/Modula-2 development system for Windows and Linux. It is now available under a freeware license:
http://www.excelsior-usa.com/xds.html
http://www.excelsior-usa.com/xds.html
There seem to be ISOs and VMWare images available here: http://www.ocp.inf.ethz.ch/wiki/OCP/Downloads
Note that I haven't tried this myself.
Note that I haven't tried this myself.
From what I've read, there's "Active Oberon", which I think compiles to .NET bytecode (I might be having a blond moment, but it wasn't clear from their site what the relationship between Active Oberon and .NET was).
http://www.ethoberon.ethz.ch/oberon.net/
[edit] oops, that project has been dead for 10 years as well. Sorry about that
http://www.ethoberon.ethz.ch/oberon.net/
[edit] oops, that project has been dead for 10 years as well. Sorry about that
http://www.ocp.inf.ethz.ch/wiki/OCP/Downloads
I haven't tried running the system in a few years, so your mileage may vary.
I haven't tried running the system in a few years, so your mileage may vary.
[deleted]
Check out Bluebottle OS: http://en.wikipedia.org/wiki/Bluebottle_OS
Oberon/F was used as a teaching language during my first semesters of CS. At the suggestion of Sun's marketing department, Oberon and it's accompanying textbook were replaced by Java™ 1.0. For me that's what happened to programming in Oberon. Fortunately, Blackbox is very well documented and even without a command of its language you can still appreciate many of the elegant gems it Guards just by reading Blackbox in Blackbox . I really enjoyed the article especially learning the bit about how Wirth measured a compiler's quality.
For an open source version of Oberon which will run on Windows, and with Darwine on OS X, see http://oberon.ch/blackbox.html
we were taught oberon at varsity. twas fun.
I had to write a compiler for a subset of Oberon in second year. I wasn't terribly impressed with the language itself.
Thx, very interesting!
I remember the the weeks I spent reading Wirth's book and learning about the OS and language. Would be nice if Oberon had become a competing system language to C, but it, the OS and the NS32K series of chips have faded into memories of us original alternative OS geeks.
You might consider Limbo or Go as alternative system languages. Limbo is bundled with the Inferno VM OS, which provides Acme, which is roughly a text-only take on the Oberon UI. Go isn't the main systems language of any OS (yet), but is more recent than Limbo.
Limbo/Inferno/Plan-9 look to be almost as dead as Modula and Oberon. :(
Which is a shame, because the Imp of the Perverse programer in my dreams always wanted to do low level coding in some other language besides assembly, C or Forth...
Which is a shame, because the Imp of the Perverse programer in my dreams always wanted to do low level coding in some other language besides assembly, C or Forth...
I assure you, its total lack of movement is due to it bein' tired and shagged out following a prolonged squawk.
Seriously, I use Inferno every day, but my job is building software, so I mostly use it to write shell scripts and execute shell commands. It interfaces well with its host (I can thread calls to host commands in Inferno-sh pipelines), and runs over top of Windows, Linux, and MacOSX.
One advantage of using Limbo to play around with systems programming in Inferno is that since it's a VM, you can muck it up as much as you like without affecting your host. Also, with the clean, spare implementation, there's less cruft to learn to work with the OS (also the userland).
To start, there's a few blogs and Google code projects on programming in Inferno, as well as a book.
http://www.ueber.net/who/mjl/inferno/getting-started.html
http://doc.cat-v.org/inferno/books/inferno_programming_with_...
Limbo is also a good way to learn some of the ideas in Go, which also has modules, strong types, IPC over typed channels, automatic garbage collection, and simple abstract data types. (I'd love to see Inferno updated and re-implemented in Go.)
Seriously, I use Inferno every day, but my job is building software, so I mostly use it to write shell scripts and execute shell commands. It interfaces well with its host (I can thread calls to host commands in Inferno-sh pipelines), and runs over top of Windows, Linux, and MacOSX.
One advantage of using Limbo to play around with systems programming in Inferno is that since it's a VM, you can muck it up as much as you like without affecting your host. Also, with the clean, spare implementation, there's less cruft to learn to work with the OS (also the userland).
To start, there's a few blogs and Google code projects on programming in Inferno, as well as a book.
http://www.ueber.net/who/mjl/inferno/getting-started.html
http://doc.cat-v.org/inferno/books/inferno_programming_with_...
Limbo is also a good way to learn some of the ideas in Go, which also has modules, strong types, IPC over typed channels, automatic garbage collection, and simple abstract data types. (I'd love to see Inferno updated and re-implemented in Go.)
If you just want to do low-level coding in a language other than those, the Free Pascal project (http://www.freepascal.org/) is very much alive, and very much none of the above. It's a nice, low-level language that also has a very nice, .NET-like object system if you want to reach for it. (In fact, the object system it has, modeled on Delphi's, was the inspiration for .NET's system.)
(Note that both the Free Pascal project and its sister project, Lazarus, have horrid websites that are not reflective of the activity or quality of either product. In fact, the top post on the Lazarus website right now is about how they need to fix the website.)
(Note that both the Free Pascal project and its sister project, Lazarus, have horrid websites that are not reflective of the activity or quality of either product. In fact, the top post on the Lazarus website right now is about how they need to fix the website.)
It's a shame Google could not have used FreePascal as the basis for Go, instead of thinking that C-like structure had to be forced into the syntax somehow "because it's familiar", even though Go clearly wants to be an extension of Modula, and often must break away from C practices that just don't work.
Given that the language was created by ex-Bell-Labs researchers (Ken Thompson, Robe Pike, Russ Cox and perhaps others), it is not surprising that the language was modeled after C.
Overall the current popularity of C (in systems software) gives an advantage to any language with similar syntax and semantics.
Overall the current popularity of C (in systems software) gives an advantage to any language with similar syntax and semantics.
Yeah, they ganged up on the Swiss (U of Zurich) guy in the group, I guess (the guy that worked on the JIT at Sun who also worked on Go).
God I wish K&R layout would just up and die already, at least in terms of having function headers that span multiple screen widths. Personally, I like having "end" keywords, and a bit more freedom in the layout. (mostly, I like to be able to write one formal parameter per line in a function heading, and to use "Whitesmiths" layout vs K&R)
Go feels much more like Pascal semantically than it does like C. I wonder if there is any research to back up the decision to make Go look sorta, kinda, like C, or if it was all ego and/or inertia.
God I wish K&R layout would just up and die already, at least in terms of having function headers that span multiple screen widths. Personally, I like having "end" keywords, and a bit more freedom in the layout. (mostly, I like to be able to write one formal parameter per line in a function heading, and to use "Whitesmiths" layout vs K&R)
Go feels much more like Pascal semantically than it does like C. I wonder if there is any research to back up the decision to make Go look sorta, kinda, like C, or if it was all ego and/or inertia.
The same (or a very similar) article can be found in the really, really great book "The School of Niklaus Wirth: The Art of Simplicity", which is a collection of high quality, highly entertaining essays about hardware, software and general CS concepts.
If you are from Michigan like I am you probably thought this was about beer before clicking.
http://beeradvocate.com/beer/profile/287/1094
http://beeradvocate.com/beer/profile/287/1094
One of my former coworkers took a job as CIO and inherited a huge application written in Oberon. It is maintained by two brothers who charge exorbitant amounts but since talent is very thin on the ground and they did a good enough job there was not really anything anyone could do about it.
I really hoped this would happen to me when I started with rails but the the whole WHOOPS video happened.
Any chance that huge application has to do with video processing or something similar?
But is it really that good today when we have Ruby, Scala, Go, Clojure and stuff? What are selling points today? Or is it a purely historic thing?
Read the article or the Wirth's original book. Wirth and his colleage had some original ideas about programming languages, operating systems and user interfaces that were revolutionary for the day. They even built their own workstations from scratch to run them on.