History mechanism in ucblogo? 
Author Message
 History mechanism in ucblogo?

Hi,

I've just downloaded and installed ucblogo 5.3, and have experimented with
it under RedHat linux.  It works very nicely.

One thing that seems to be lacking is any sort of history mechanism, by
which you can scroll through previously entered commands and edit them
slightly.  Is there any way of obtaining this behaviour?

cheers,
Alasdair

--
For personal replies, remove "not" from email address.



Sat, 30 Jul 2005 13:11:46 GMT  
 History mechanism in ucblogo?

Quote:

> Hi,

> I've just downloaded and installed ucblogo 5.3, and have experimented with
> it under RedHat linux.  It works very nicely.

> One thing that seems to be lacking is any sort of history mechanism, by
> which you can scroll through previously entered commands and edit them
> slightly.  Is there any way of obtaining this behaviour?

That's strange. You probably did not read the installation README file to the
end, where it deals with Emacs logo-mode initialization. To quote:

+-----------------------------------------------------------------------------+
| Each user who wants to use the Emacs logo-mode IDE must first run the shell |
| command "install-logo-mode".  Thereafter, whenever the user opens a Logo    |
| source file (filename.lg) with Emacs, logo-mode will automatically start.   |
+-----------------------------------------------------------------------------+

Do this logged as an ordinary user (the account where you actually do the Logo
programming), and logo-mode IDE will be enabled for your account (it just
fixes your ~/.emacs file). This will take you through a quick check-up
routine, and will also tell you how to start logo-mode tutorial.

In case you missed the point, to be able to use UCBLogo IDE you *must* use
Emacs. If you are one of these that prefer eVIl :-), you're out of luck :-)



Sat, 30 Jul 2005 15:32:22 GMT  
 History mechanism in ucblogo?

Quote:

>One thing that seems to be lacking is any sort of history mechanism, by
>which you can scroll through previously entered commands and edit them
>slightly.  Is there any way of obtaining this behaviour?

Nope.  It's on my list to stick the Gnu readline library in UCBLogo,
but I haven't done it yet.

Meanwhile, you could implement something yourself.  Here's a quick and
dirty version.  To start it, you type HIST.  This changes the prompt
from ? to ?? so you know it's running.  You type commands as usual.
If you want to back up the history list, type the command H.  This will
show the most recent command you gave.  Keep typing space (just the
space character, no return after it) until you see the one you want to
edit, then type any nonspace character.  This will start Logo's editor,
whichever one your EDIT command uses, on a one-line file containing the
chosen command.  Edit it and return to Logo.  The edited command will
be run and added to the history.  Errors in your commands are caught
and reported but don't stop the history program.  To stop the history
program and return to regular Logo, give the EXIT command.

--------------------------------------------

to hist
localmake "history.list []
forever [hist.run]
end

to hist.run
type "|?? |
localmake "this.command readword
if equalp :this.command "exit [throw "toplevel]
make "history.list fput :this.command :history.list
ignore error
catch "error parse :this.command
localmake "error error
if not emptyp :error [err.print :error]
end

to h
make "history.list butfirst :history.list
localmake "cmd h.loop :history.list
openwrite "history.temp
setwrite "history.temp
print :cmd
setwrite []
close "history.temp
ignore error
catch "error [editfile "history.temp]
localmake "error error
if not emptyp :error [err.print :error]
openread "history.temp
setread "history.temp
make "history.list fput readword :history.list
setread []
close "history.temp
erasefile "history.temp
end

to h.loop :cmds
type first :cmds
localmake "reply readchar
repeat 80 [type (word char 8 "| | char 8)]
if not equalp :reply "| | [output first :cmds]
output h.loop butfirst :cmds
end

to err.print :error
type item 2 :error
if equalp item 3 :error "hist.run [print []  stop]
if not emptyp item 3 :error [type "|  in |  type item 3 :error]
print []
if not emptyp item 4 :error [print item 4 :error]
end



Sun, 31 Jul 2005 01:19:22 GMT  
 History mechanism in ucblogo?

Quote:

> Emacs logo-mode

Oops, in my reply I missed the part saying he was running under Linux.
My bad.  That's a much better solution than my hack history command!
But mine will work for people using inferior operating systems.  :-)


Sun, 31 Jul 2005 01:26:12 GMT  
 History mechanism in ucblogo?

Quote:

> But mine will work for people using inferior operating systems.  :-)

Or those e_VI_l people :-)


Sun, 31 Jul 2005 01:56:12 GMT  
 History mechanism in ucblogo?

Quote:


> >One thing that seems to be lacking is any sort of history mechanism, by
> >which you can scroll through previously entered commands and edit them
> >slightly.  Is there any way of obtaining this behaviour?

> Nope.  It's on my list to stick the Gnu readline library in UCBLogo,
> but I haven't done it yet.

GNU Readline will be great for fast testing on the interpreter,
thanks!

Now that we talk about it, is there (or is someone working on) a ViM
Logo mode (Berkley Logo, or any other dialect of the language? With a
barebones implementation, hacking it to suit usclogo own dialect would
be easy, starting one from scratch is not very fun...)

Emacs users can think whatever they want, but vi(m) is a great
programmers editor, and a syntax file for Logo would be just great...

Thanks!
david



Sat, 06 Aug 2005 10:03:20 GMT  
 History mechanism in ucblogo?

Quote:

> Now that we talk about it, is there (or is someone working on) a ViM
> Logo mode (Berkley Logo, or any other dialect of the language? With a
> barebones implementation, hacking it to suit usclogo own dialect would
> be easy, starting one from scratch is not very fun...)

> Emacs users can think whatever they want, but vi(m) is a great
> programmers editor, and a syntax file for Logo would be just great...

:-) :-) Looks like I hit the jackpot with "e_VI_l" :-) :-)

But OK, enough joking. I do not wish do argue whether writing/editing text is
easier, more natural, or whatever anybody wants to call it, in VI or Emacs.
That is obviously a religious issue.

I do not even want to argue the statement that vi(m) is a great programmers
editor, but I will insist on a distinction here:

Both VI and Emacs are equally good (I'm giving in here :-) -- just could not
resist this :-), in editing source code for batch mode languages (command mode
languages). Therefore writing C, or Java, or ... code in either VI or Emacs
*is* just a matter of what one is used to. However when it comes to writing
code for Lisp variants (of which Logo is a member), or indeed for any
functional language (ML, Ocaml, Haskell, Cl, Scheme, Mozart ...), for a true
hacker, there is no real choice between VI and Emacs.

You want proof; OK. Just visit web sites of something like 50 different Scheme
implementations, or Cls or Mls or Haskells -- even Mozart. You will notice
that some are distributed with very elaborately written Emacs modes for just
that implementation (just like UCBLogo -- gee, did I just call logo-mode
"elaborately written" :-), while all the others distribute generic Emacs mode
with language tarballs. You *must* notice that VI mode is missing from all
those language web sites. Why do you think that is so?

BTW: I do know that for most of these languages some sort of VI mode exists,
it is just *not* distributed with the language, nor by the language implementors.

Here is a brief explanation why, that I will base on UCBLogo:

Say, if VI(m) logo-mode existed, you would use it like this:

Open xterm, run Logo in xterm, then from Logo command line issue a command
`edit "something'. Now VI would popup, you would write your code, save it, and
close VI, and then continue on Logo command line in xterm, issuing commands to
test your newly written code. If you want to add/change anything, the cycle
starts again with popping VI again ... Really not much difference from working
with a batch mode languages like C or Java. Logo's REP loop is severely
crippled using it this way.

Compare this with running UCBLogo in Emacs logo-mode:
Open Logo source file in Emacs. Open Logo window in emacs. Now you have both,
the editor with your source opened, and Logo command line running at the same
time (in two different windows) with smooth communication between the two. You
never have to issue the "edit", or "load" command from Logo, nor do you ever
have to close the edit window, so your source is always visible. Any
changes/additions in edit window, you simply send to Logo with a key-stroke.

Therefore, binding UNIX version of UCBLogo with GNU readline library, is
really not that important, because whatever readline gives you, is nowhere
near the functionality that running Logo in Emacs buffer has.



Sat, 06 Aug 2005 17:39:30 GMT  
 History mechanism in ucblogo?

Quote:
> Here is a brief explanation why, that I will base on UCBLogo:
> Say, if VI(m) logo-mode existed, you would use it like this:
> Open xterm, run Logo in xterm, then from Logo command line
> issue a command `edit "something'. Now VI would popup, you
> would write your code, save it, and close VI, and then
> continue on Logo command line in xterm, issuing commands to
> test your newly written code. If you want to add/change
> anything, the cycle starts again with popping VI again ...

I use vim() to work with logo, and it is nothing like that
hard or painful.

0) open ucblogo
1) guess a name for your workspace: myws will do
2) create a brief command to load from that workspace, maybe:
   to reload
     load "someLongComplicatedPathTo/myws
   end
3) in _another window_:
   vim myws

4) edit some logo stuff in vim(), save it
5) in ucblogo
   ? reload
6) test code

repeat 4,5,6 as necessary.

Why on earth would you _exit_ _vim_ between ucblogo twiddles?

And if you like to do some of the changes in the ucblogo editor,
you add

7) in ucblogo, something like
   save "myws
   {or whatever, I forget the syntax offhand, and I'm too lazy to look}
8) in vim(), reload the file:
   :e!

and you are editing the changed code in vim().

It is really meaningless for anyone but a _power user_ of
_both_ editors to make editor war comparisions; evaluations
based on what you don't know how to do as well in the editor
you don't like the most are pointless.  Once one becomes a
power user of both, of course, different conclusions can be
had, such as the below expert opinion.

xanthian. [heh]

                   ===== sample archival quote =====

                       I use Vim. Vim kicks butt.

                          Don't get me wrong:
                   Emacs is a great operating system
                                  ---
                    it lacks a good editor, though.

                                 -- Thomer M. Gil, "Vi Lovers Home Page"
                                        http://www.thomer.com/vi/vi.html



Sun, 07 Aug 2005 07:05:57 GMT  
 History mechanism in ucblogo?

Quote:


>>Here is a brief explanation why, that I will base on UCBLogo:

>>Say, if VI(m) logo-mode existed, you would use it like this:

>>Open xterm, run Logo in xterm, then from Logo command line
>>issue a command `edit "something'. Now VI would popup, you
>>would write your code, save it, and close VI, and then
>>continue on Logo command line in xterm, issuing commands to
>>test your newly written code. If you want to add/change
>>anything, the cycle starts again with popping VI again ...

> I use vim() to work with logo, and it is nothing like that
> hard or painful.

> 0) open ucblogo
> 1) guess a name for your workspace: myws will do
> 2) create a brief command to load from that workspace, maybe:
>    to reload
>      load "someLongComplicatedPathTo/myws
>    end
> 3) in _another window_:
>    vim myws

> 4) edit some logo stuff in vim(), save it
> 5) in ucblogo
>    ? reload
> 6) test code

> repeat 4,5,6 as necessary.

> Why on earth would you _exit_ _vim_ between ucblogo twiddles?

> And if you like to do some of the changes in the ucblogo editor,
> you add

> 7) in ucblogo, something like
>    save "myws
>    {or whatever, I forget the syntax offhand, and I'm too lazy to look}
> 8) in vim(), reload the file:
>    :e!

> and you are editing the changed code in vim().

> It is really meaningless for anyone but a _power user_ of
> _both_ editors to make editor war comparisions; evaluations
> based on what you don't know how to do as well in the editor
> you don't like the most are pointless.  Once one becomes a
> power user of both, of course, different conclusions can be
> had, such as the below expert opinion.

Firstly, I thought I made it abundantly clear that I'm not waging an editor war.

Secondly, I will admit that I'm not a VIm power user, although I do use it
regularly. My description of Logo - Vi interaction was based on brief
experience with UCBLogo and  VI, before Emacs logo-mode existed. I will grant
that you do not have to close VI between editing sessions (simply because you
are not using Logo "edit" command). But let's count your steps -- my, it's 9 +
some manual tweaking of Logo to make it work.

If you count Emacs logo-mode steps, you come up with only 2; open one Logo
source file, and click on the menu-bar -> Start Logo. That's it.

Apart from this, there is one other distinction that I made in first post. I
made a clear distinction between the two types of languages one is using. For
batch type it does not make any difference (apart from personal preference),
what type of editor you use. If you are running a Lisp type (or any other
functional type) it *does* make a huge difference! You should ask yourself,
why is it that all the implementors of those languages ship with Emacs modes
and *not* with VI modes. Is it because none of them are VI _power users_, or
is it something else? Even the premier commercial version of Cl (Allegro Cl)
ships with a proprietary version of Emacs-mode.

What is the big difference? VI typically has only the editor side, that is
only the indenting and syntax coloring functionality.
With Emacs the story is different; editor side -- indenting, syntax coloring,
..., is only one part of the language mode, and a smaller one at that. The
inferior process mode (the mode where the interpreter is actually running) is
much larger, and much more complicated. With logo-mode, edit-mode is about
50K, and inferior-logo-mode is about 100K.

For the end, even your _power user_ description of UCBLogo / VI interaction
capabilities, is, to put it mildly, covering (and very crudely) about 5% of
Emacs logo-mode capabilities.



Sun, 07 Aug 2005 08:04:54 GMT  
 History mechanism in ucblogo?
Hello!

Quote:

> :-) :-) Looks like I hit the jackpot with "e_VI_l" :-) :-)

nah, I just want a logo syntax file for vim :-)

Quote:
> But OK, enough joking. I do not wish do argue whether writing/editing text is
> easier, more natural, or whatever anybody wants to call it, in VI or Emacs.
> That is obviously a religious issue.

Indeed.

Quote:
> [...] However when it comes to writing
> code for Lisp variants (of which Logo is a member), or indeed for any
> functional language (ML, Ocaml, Haskell, Cl, Scheme, Mozart ...), for a true
> hacker, there is no real choice between VI and Emacs.

Mmm... not yet (term inclusion is on the TODO for vim 7, if I recall
well :-)

Quote:
> Here is a brief explanation why, that I will base on UCBLogo:

> Say, if VI(m) logo-mode existed, you would use it like this:

> Open xterm, run Logo in xterm, then from Logo command line issue a command
> `edit "something'. Now VI would popup, you would write your code, save it, and
> close VI, and then continue on Logo command line in xterm, issuing commands to
> test your newly written code. If you want to add/change anything, the cycle
> starts again with popping VI again ... Really not much difference from working
> with a batch mode languages like C or Java. Logo's REP loop is severely
> crippled using it this way.

Agreed. It's the first time I have read a comprehensive, realistic
defense for the emacsen flavor of functional programming languages
distros. Thanks!

However, changing ucblogo so that it detaches the $EDITOR into a new
window, but keeps in sync with its contents by issuing a, dunno, :make
or :go cannot be *that* difficult. And believe it or not, I don't have
room enough to install emacs in this machine (while vim is pretty
small in comparison).

Quote:
> Therefore, binding UNIX version of UCBLogo with GNU readline library, is
> really not that important, because whatever readline gives you, is nowhere
> near the functionality that running Logo in Emacs buffer has.

True. But readline is shipped with my linux distro, and is about 185Kb
big. Emacs is great, but sometimes it is out of the game; I need
solutions for those cases, and readline (and offline writing of logo
in vim, and then firing the whole thing up, like you would develop in
perl, is pretty fast itself, much faster that C or Java). You see,
sometimes good enough is enough :-)

but thank you for your explanation, I have been reading ucblogo mode
for emacs and it is an impressive piece of software (reading a mode
that needs unwind-protect is impressive enough ;-), and your
explanation has gotten me curious, I'll get sure to give it a try at
my big home linux box...

best regards,
david



Sun, 07 Aug 2005 20:29:45 GMT  
 History mechanism in ucblogo?

Quote:

> but thank you for your explanation, I have been reading ucblogo mode
> for emacs and it is an impressive piece of software (reading a mode
> that needs unwind-protect is impressive enough ;-), and your
> explanation has gotten me curious, I'll get sure to give it a try at
> my big home linux box...

If you find a bug in it, that would be even better. There have not been a bug
reported since ... never really. So lest you start thinking it is just a
*perfect* piece of software, I would rather assume that nobody has been using
it :-).

Hrvoje



Mon, 08 Aug 2005 00:44:20 GMT  
 History mechanism in ucblogo?
Greetings,

Quote:

> What is the big difference? VI typically has only the editor side, that is
> only the indenting and syntax coloring functionality.
> With Emacs the story is different; editor side -- indenting, syntax coloring,
> ..., is only one part of the language mode, and a smaller one at that. The
> inferior process mode (the mode where the interpreter is actually running) is
> much larger, and much more complicated. With logo-mode, edit-mode is about
> 50K, and inferior-logo-mode is about 100K.

> For the end, even your _power user_ description of UCBLogo / VI interaction
> capabilities, is, to put it mildly, covering (and very crudely) about 5% of
> Emacs logo-mode capabilities.

You are right, I have tested Logo mode in Emacs, it's vastly more
powerful than any syntax file for vim could ever been. However, this
is due to the differing philosofies running behind the scenes. Making
a vim macros script that added a lot (maybe not the whole 100%, but
quite a lot) of the available functionality for the emacs mode
wouldn't be that difficult (or you could do so in perl, ruby, python
or tcl, compilation options needed to support them), it would just
take quite some time. VI users are used to work with the OS (unix)
through :ex commands and :!shell escapes, while emacs provides a whole
layer below you (in Lisp, nothing else!).

Lisp mode for Emacs makes a great IDE for UCBLogo, that's true, but as
I commented in another message, sometimes you don't need, cannot
afford the power or price of running Emacs. VI (and clonics like Vim)
run fast and are basically powerful enough.

It's like those people that say Logo is not powerful enough. Enough
for what? Logo is almost as powerful as Lisp itself (BTW, when will we
have lambda (or similar) in Logo??? Why doesn't the TO special form
allow me to do something like this? eg:

to foo :arg1 :arg2 ... :argN
blah
bleh
ot to :arg3 ... :argN (bluh :arg1 bluh bluh :arg2 ...) end
;; or maybe -> ot to.lambda :arg3 ... etc
end

to foo.curried ;; or make "foo.curried (both make sense, in a way,
               ;; maybe that's why it isn't allowed
foo 1 2
end

show foo.curried 3 ... N

;; ok, enough rambling... but it would be waaaaaay cool :o)

i still think readline and vim syntax file would still be cool (if so,
they give you the possibility to choose), but admit that Emacs (+VIper
<eg>, almost the best of both worlds :-) [if at least I'd managed to
get the folding mode working with VIper on!]) with the Logo modes is
indeed an extremely powerful IDE (specially if you also know eLisp!).

well, thanks for all the help,

best regards,
david



Mon, 08 Aug 2005 00:57:22 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. History mechanism for MIT Scheme

2. history mechanism (kbd) ??

3. GOTO in UCBlogo;MSWLogo

4. Fwd: [LogoForum] GOTO in UCBlogo;MSWLogo

5. Please re-download Unix UCBLogo

6. UCBLogo 5.2 bugs fixed

7. directories and chdir in UCBLogo

8. oops (error in UCBLogo 4.2)

9. Label for UCBLogo?

10. UCBLogo under linux

11. Procedures names in UCBLogo, MSWLogo, TKTSLogo

12. Translations solicited for UCBLogo Messages file

 

 
Powered by phpBB® Forum Software