Conference hydra::amiga_v1

Paul, I just took a look at the code. I have an internal character translation
buffer that is sized to 20. That's why you only get 20 chars when you SNAP
something into SEDT. Normally you couldn't type that fast :-).

I put a fix into the code that should fix the problem (no, I didn't just
increase the size of the buffer, cause how big is big enough !).

I'll have to compile a new version and upload it if your interested.

Frank,
aka Amiga SEDT dude.

    
    Yes .. that would be great. Thanks Frank.

Could you also investigate the ENFORCER hit it causes? Almost every 2 or 3
edits causes an enforcer output, indicating an improper memory access somewhere.
(It would also cause a GOMF when I ran under 1.3, but since I don'tr use GOMF
under 2.0 I don't have any further information).

BTW -- great program! Still my main Amiga editor.


P.S. Yes, my stack is at 25000; well above minimum requirements
:-)

>>    I started using PowerSnap V1.0 on my Amiga (I had been using SNAP
>>    V1.62).

Which is best?  I've been using SNAP for quite a while, and am quite happy with
it.  Is PowerSnap better?

    One problem with SNAP is that if your mouse accidently slides "up"
    the text rather than "down" (assuming you wanted to go down), there
    no way to recover other than resnapping the text. Powersnap does not
    have this problem. Snap's author plans to fix it in a future release.
    

    One of the options with SNAP will set a delay between pasted
    characters.  You could probably avoid the buffer overrun problem
    by giving SEDT a bit more time to process the input.

    
    Powersnap has no such option.

    I have not been able to solve the SEDT buffer limit by setting the
    delay longer (maybe I didn't set it long enough).  
    
    I would also be interested in a version of SEDT that let me do long
    pastes (I use SNAP).
    
    (If I know I am going to be pasting something long, I use a different 
    editor)
    
    Yours
    Erg

I have fixed that SNAPing problem with SEDT. I tested it with some rather large
SNAPs and it didn't miss a byte. However, it ain't real fast, so if you snap
in the text it may take a few seconds till you see the text appear. SEDT is
just not real efficient processing input.

I also fixed one minor problem that the compiler just started complaining
about. An uninitialized autovariable. I don't know if this might be what was
causing the enforcer hits or not.

Since this version seems to be pretty stable, and I don't know when if ever
I will get 4.0 to work, I am removing the distribution restrictions that I
had on it. I still consider it field test however. You may give it to whom
ever you wish, but I would prefer that it not make it into public BBS's and
such yet.

You can find the new version at:

CANIS::C$USR1:[AMIGA.SEDT]SEDTFT5B.LZH

Frank Ries

    Me too. 

Oops, and I thought that I had everything right before putting in the note :-).

Well, it should be ok now, however its on a different disk. It is now:

CANIS::C$AMIGA:[AMIGA.SEDT]

Sorry for the confusion!

Frank

>READMEFT5A.;2            17/18
>READMEFT5B.;2            19/21
>SEDTDOC.LZH;1           134/135
>SEDTFT5A.LZH;1          195/195
>SEDTFT5B.LZH;1          324/324

I assume I don't need the *FT5A.* stuff, right?

SEDTFT5B.LZH contains everything you need to run SEDT FT5B.
SEDTDOC.LZH contains the documentation case you need it.
READMEFT5B. is the readme file (install info etc) which is also in SEDTFT5B.LZH

Frank

    I have found a bug in the last version that I have finally isolated over
    the last few days. SEDT doesn't appear to be freeing chip memory
    properly. If I do repeated edit/exit/edits eventually (after a dozen or
    so) I am unable to open any new windows and have to reboot. This
    happens most frequently when I am also using PPage.
    
    I am going to try the 5b version tonight.
    
    great product - my vote for more mouse support etc
    
    regards
    kevin
    
    
    
    PS I also remember someone recently saying that PPage 2.0a has had an
    update, what is it up to now.

    PPage is at V2.01. It will be sent automatically to registered V2.0
    users. I've been using V2.01 beta for several months now, and have not
    encountered any problems (although I don't recommend using the SAVE
    option. I actually deleted that from the menu to force me to use the
    SAVE AS option).
    
    The Amiga doesn't seem to accept assigns like SEDT$DIR: DH0:SEDT
    It seems to barf on the dollar sign. I replaced the $ with _ in the
    source, and it works okay now. Comments?
    

    If you escape the "$" it will work.  There was something on this in a
    previous SEDT note.  I know my assign is "SEDT$DIR & SEDT$TMP:".  I
    think to escape it in ADOS (help me folks, I cannot remember) you must
    type:  "ASSIGN SEDT*$DIR: dev:path".
    
    mark
    

    re: -.1
    
    I must confess I have no idea what you guys are talking about;
    
    ASSIGN SEDT$TMP: DEC:		(DEC: is my logical for the path)
    
    works fine for me; no "$" troubles. Unless you are perhaps talking
    about a conflict in the script usage of ENV variables?
    
    
    
    I AM, HOWEVER, HAVING A FEW OTHER PROBLEMS.
    
    No matter where I make the SEDT$TMP logical point, SEDT produces a
    very fast "Can't open journal file" error and does not journal (still
    allows the editing though). I've
    even tried pointing SEDT$TMP to SEDT$DIR, and to the same directory
    that the file I'm editing is in, AND I tried the "*$" suggestion in the
    assign statement -- no dice. I have no special CNF
    entries, and the problem happens on both SEDT executables.  BTW - this
    problem does NOT exist with the previous 5A version.
    
    Also, the README states that F5 is mapped to performing SYSTEM
    commands, but all I get is an unmapped key error.
    
    Time for a Version 5C?  :-)
    
    
    I'm running under V2.04 WB on a 3000, and am using the A2 keymap in
    INTERLACED mode.

It seems to happen the least often if you are creating a new file, or editing
a small file in your  local directory. Editing a large file (like the
SEDT.manual), or specifying a path, always results in a journal failure on my
system with the new version.

Could this be in the changes you made for faster I/O?

The change that I made so that you can snap large sections of text was very
minor. It only had to do with console input. The only other difference
between FT5A and FT5B was the version of Lattice/SAS C that was used to
compile it. I have run into bugs in the past with the compiler that caused
me to have to put various workarounds in the code. Sigh :-(. I imagine that
that is whats going on here. I will have to check it out and I'll report
back here.

Frank

I'd feel a lot more comfortable if I wasn't alone;
Has anyone else experienced this problem with the new version?

    RE: .21
    
    Well I am not having the problem you describe. I just looked in my
    SEDT_TMP: directory, and there was the journal file for the work I was
    in. The message that appears at startup appears for me too, but only
    when I am starting on a file without a journal file - like a new file.
    
    Regarding the SEDT$DIR: vs SEDT_DIR:, I wonder if the $ doesn't work
    for me because I am using the ARP ASSIGN command?
    

    Oh, btw Frank, I am using the 68030 version on an A2620.

    It's a strange problem; I suspect it has something to do with the
    file open statement itself. If I try the new program, the error will
    occur. Without changing a thing, if I try the old program it works
    fine. The error is easiest for me to cause when editing a large file.
    
    This happens with both the 68000 and 68030 versions.
    

    This is what I have for my assign(s):  "Sedt*$Tmp:" and "Sedt*$Dir:"
    and they work fine.  I use ARP.
    
    mark
    

	The ARP assign does funny things with the "$", so if you use ARP,
	you must preceed the "$"  with the "*" as shown in the previous 
	reply.

	While I'm thinking of it, although this isn't exactly the "Mouse 
	support" previously mentioned, I did create an Icon driven script
	file for calling SEDT from the workbench.  It couples the ARP file
	requestor to SEDT, then allows for the optional creation of a .DOC icon 
	for the file created.  The script file also allows you to invoke SEDT
	from ParM (or MyMenu, AMenu, CLI) with the file requestor. Comes in 
	real handy for folks like me who can't remember exactly how they 
	named their files!

	If I recall this stuff (SEDiT.lzh)is still in the upload directory 
	on EOT.

	mt
	

	

Well, there is yet another new version of SEDT available. This one removes the
field test mumble and fixes (I hope) all the journal file problems.

The cannot create journal file error ocurred when a device and/or path was
specified on the file to be edited/created. Strange I never tested that!
ie: SEDT FOO.BAR worked whereas SEDT DH0:FOO.BAR did not. Anyway, that
and a few other journal file glitches (nothing major) have been fixed.
However, I have changed where the journal file is kept. I used to create
it where the logical SEDT$TMP points, but I now create it in the directory
where the source file is. I only put it in SEDT$TMP cause that was supposed
to always point to a disk device, not a RAM disk. This way if you were
editing a file on a RAM disk and the system crashed, you would have your
journal file on disk. This created a number of problems however, and was
really not where you would expect the file to be. So, it is now in the
directory where the source file is. If this is a RAM disk and the system
crashes, you are out of luck!

The new version can be found at:

CANIS::C$AMIGA:[AMIGA.SEDT]SEDT-247C.LZH		Sedt files
CANIS::C$AMIGA:[AMIGA.SEDT]SEDTDOC.LZH			DOC files

The doc files have not changed.

Frank

    Thanks! I really appreciate the support you've been providing. I'll
    download it tonight and let you know if I find any problems.
    
    (I assume the journal/path problem was because the filename's path
    got tacked onto the sedt$tmp logical and created an illegal result.
    Should be possible to strip out the path specification from the file
    name and still get sedt$tmp to work the way you originally desired).
    
    Keith

    Another note of thanks.  Also, the 030 version (f.t. b) runs nicely on
    my 020 (remember those?  They were fast, once...).  I also very much 
    appreciate the work you've put into this.
    
    Yours
    Eben Gay

re: .-2

Your right, the problem was SEDT$TMP: being tacked onto the specified path
resulting in an illegal spec.

I decided not to "fix" this, and just put the journal file in the same
directory as the source file for a couple of reasons. Doing it the way
I was doing it, was different than all other versions of SEDT (not a real
good reason for not doing it, but), and you would run into problems if
you ran two or more SEDT sessions and tried to edit two files with the
same name. Since all the journal files went into the same directory, you
would have a file conflict. The way it works now, there is no problem
unless of course you create two new files in the same directory with the
same name which is rather tough! Besides, you really shouldn't be doing
any major editing of files in a RAM disk. SEDT$TMP: is still used by
SEDT for creating its cache files, which are only needed if it runs out
of RAM. This is the reason I say to assign SEDT$TMP to a disk. If SEDT
cannot get RAM for its buffers and needs to go to a cache file, if that
file would go on the RAM disk .... well you get the idea.

There were a couple of other problems mentioned in this series of notes
which I was unable to reproduce. One was that SEDT was eating CHIP RAM,
and the other about the "new" key assignments for performing O/S commands.
I went in/out of SEDT many times and checked the free CHIP RAM via the
AVAIL command and it was always the same. The O/S command keys worked
fine for me, but I did notice that I did not add them to the on-line
help, so I added them.

Let me know if this version seems to work properly. Also, whomever said
that SEDT was giving them enforcer hits, let me know if this version
still does that.

Frank

Re: -.1

I tried out the new version and the journaling problem seems to be gone.
The problem with the function key is also gone; I suspect it was because
the wrong A2key file was included in that FT release, but I have no way of
validating that.

I'll try enforcer next chance I get.


Keith


P.S. Since SEDT$TMP no longer is used in creating journal files, is it
better to point this logical to RAM: or a directory?

    I'd like to see the next SEDT release maintain the file protection
    codes and the filenote across edits.
    
    [Note: No one answered my question in -.1 about the TMP logical]
    

You didn't read .30 very well did you. Yes, SEDT$TMP: is still needed for
cache files.


Frank

PS:

SEDT needs lots of work if I ever get the time. I looks awful under 2.04
in my opinion.

Re: -.1


No, I meant that since the changes removed the journaling restriction, is it
considered good or bad to have SEDT$TMP point to ram instead of disk? The old
way, you created journal files in SEDT$TMP, so it was dangerous to have that
point to RAM:. Now that the journal files are created on the same disk as
the edited file, does it become a good idea to point SEDT$TMP to RAM:?

You don't want to point SEDT$TMP to ram, because this logical is used to point
to where it will create its cache files if it runs out of ram. It only starts
to cache if it runs out of ram, if it uses up all of ram and needs to cache,
there won't be any free memory for the ram disk to expand. Unless of course
you are using rad: or something like it. However, that will not give you
very much caching space. It's best to point SEDT$TMP to a disk that will
have a reasonable amount of free space on it, like a hard disk.

Sorry if I didn't make this clear before.

Frank