[9fans] acme design (long)

[9fans] acme design (long)

[cej]

DEBATE CONTINUES ;-)

++pac:
> 
> Now ETHZ is ending new core of Aos. It becomes real-time.
> That's great news!
> 
what does it mean "real-time" ? I heard it many times but still dont know...

> > nevertheless, shared libs are not true objects. I'm not the proper
> > person to discuss pros and cons of OO paradigm. I was 
> pursuaded I can
> > live w/o objects :-)
> 
> Oh, no! It's just a mirage! I can assure you 101% :o) I can't
> live w/o 
> objects! Nobody can! :o) Unix was so successful because of it was 
> defined one very useful and common OBJECT - "FILE"... :o)))) 

yes...

> And I wont
> speak about graphical library. May be you can't inherit from 
> library's 
> object but the ideology ot those libraries is object.
> 


++pac:
> is it really just a GUI to complete  Bluebottle functionality?? So I 
> can get rid of all those colourful windows and buttons?

Hmmm... Of Course I can understand first reaction of a man who went from 
Unix world! :o))) But I can say: You have CLI anywhere you want! :o) May be it is just a case of a habit?


Wlad:
> What is it CLI? Commandline interface?
> Do I have "Command.command ^ selected arguments~ middleclick" in BB, 
> too? Anywhere?

Yes. Where you want and where it is compfirtable for you.

Module.Procedure ^ - take "arguments" in the last selection (in any 
window, not just from the same window)

Module.Procedure * - take marked object (may be whole window as a 
"parameter", more friquent it is used for compilation for example. For 
instance we can mark (by pressing F1) window with program source text 
and type "Builder.Compile /s *"...)

Module.Procedure arg1 arg2 arg3 ... argN ~ - just simple command with 
its arguments. "~" means the end of argument list. Any command doesn't 
require it.

> We have similar "text-command-in-one-place arguments-elsewhere 
> middleclick-leftclick" in p9, however in AcmeUI only.

No-no. IN OBERON YOU CAN INPUT COMMANDS ANYWHERE YOU WANT!

> In an alternative, but concurrent, Rio (terminal) window you can only 
> select command together with its arguments and "send" it (via menu) to 
> execute...

"Menu items" in Oberon are just "carriers" of links to "commands". It 
has been done just for convenience.

> we have basically two GUIs in p9, that can run concurrently: one is 
> normal windowing environment, Rio, with a terminal window for each 
> process, capable of displaying text and graphics, and driven by menu, 
> and an AcmeUI, which is much like old Oberon UI, but runing within a 
> Rio window like frames, or panes, and driven via text commands 
> (pre)written anywhere.

Its just the question of you wish. You can open "desktops" with usual 
overlapped windows. But they remain "oberonish" window where you can do 
the same things as at tiled window GUI.

> Well, most importantly, do I have scripting in BB? With "if" and 
> loops? which languege, Oberon?

The main biuty is due to architecture of Oberon system you don't have 
separate languges for different goals. You just create modules. You even 
do not differentiate "sustem" and "user" modules. You just expand system 
functionality by adding new developed modules or change it by replacing 
its default modules with yours.

Re: [9fans] acme design (long)

[Russ Cox]

You're not arguing about Acme vs. Oberon.
You're arguing about Plan 9 vs. Oberon.

As Rob said a few days ago, no one sat down and
said "let's build a system that's not like Unix", and
similarly no one set out to build a "non-Oberon".

Plan 9 and Oberon are both clean systems built
around simple (but different) models of how computing
resources should be presented.  They each have
their advantages and disadvantages.

Once you accept that, it's easy to see that Acme is,
as Rob said in the paper, inspired by the Oberon
look and feel but adapted to the Plan 9 model instead
of the Oberon one:

    Acme is a new program, a combined window system,
    editor, and shell, that applies some of the ideas 
    distilled by Oberon.  Where Oberon uses objects
    and modules within a programming language (also
    called Oberon), Acme uses files and commands
    within an existing operating system (Plan 9).

There's not much point in answering any of the
specifics of your "debate" emails.  You're arguing
about the relative merits of apples and oranges.
Good luck.

Russ

Re: [9fans] acme design (long)

[bs]

>     Acme is a new program, a combined window system,
>     editor, and shell...
> 
This reminds me of a product from the 70's called
CANDE (Command AND Edit language) in the Burroughs/A-Series platforms.
(It did not do graphical windows though)

Re: [9fans] wiki

[Russ Cox]

http://plan9.bell-labs.com/wiki/plan9/1/index.html

looks fine to me.  The wiki is program-generated
so it's possible that a web proxy between you and
the server is not liking it.

Russ

[9fans] wiki

[vdharani]

hi,

there must be something really wrong with wiki. i am not able to access
it. i have had this problem earlier also.

how come i am able to access other pages of plan9 site but not wiki pages?
what is different between wiki pages and others? i am behind a proxy
server. is that a problem?

i use wiki pages for quick reference. things become tough when i am not
able to access it.

any clues?

thanks
dharani

[9fans] acme design (long)

[cej]

    >Where Oberon uses objects
    >and modules within a programming language (also
    >called Oberon), Acme uses files and commands
    >within an existing operating system (Plan 9).

Now I see. I didn't read thoroughly, sigh.
Sorry for that,
++pac.