jwil1@cs.aukuni.ac.nz (JasonCarlyle Williams ) (04/10/91)
OK, guys... You have recently been discussiong the idea of invoking editors
(Edit, Draw, etc.) from within another App. along the lines that the editor
will pass you back the file when finished with it...
It's actually nigh on impossible to do this with current app.s (i.e. Edit
would probably have to be re-written to handle this special case)
How about a sort of RAM filing system for this?
When you want to do a transfer, you "save" your file to the RAMFS, which
automatically (dynamically) 'creates' a disc just for that one file.
This has several dinky features:
Wimp$Scrap could automatically be channelled through this dynamic RAMdisc
(though not a RAMdisc that pleb users can 'see' on the desktop) if enough
RAM exists for the transfer. Then, Wimp$Scraps will be equivalent to RAM
transfers when the RAM is available.
Extra twiddly bits could be given to the FS when you save a file to it:
e.g. *SAVE file to RAMFS
*Run file (to invoke !Edit on it)
(And set 'twiddly bit' "return the file to me")
Then when user clicks 'save' in Edit, it saves back to this RAMFS and
the RAMFS sends you a DataLoad request or similar to get you to re-load the
file for your own useage again.
This could work, and it would also work with any application regardless
of whether it actually had been written with this system in mind.
(That should give you something to think about/winge about/ignore, anyway)
The Master of the Arcane
(P.S. Howcum this stupid nn puts this silly message at the end of my posts...?)
--
New administrater uofa.Julian.Wright@comp.vuw.ac.nz (John Julian Wright) (04/10/91)
In article <jwil1.671240542@cs7.cs.aukuni.ac.nz>, jwil1@cs.aukuni.ac.nz (JasonCarlyle Williams ) writes: |> It's actually nigh on impossible to do this with current app.s (i.e. |> Edit |> would probably have to be re-written to handle this special case) Certainly it would need a couple of things added to it, but it wouldn't need to be completely re-written. The Save option on the menu changed to a simple 'non-iconic' option, for example, and the adding of a couple of messages... |> How about a sort of RAM filing system for this? |> When you want to do a transfer, you "save" your file to the RAMFS, which |> automatically (dynamically) 'creates' a disc just for that one file. I LIKE this idea. At present only files which are *SAVEd (or equiv.) can be RAMTransferred. Not files which are saved by opening, bputting, and closing. |> Wimp$Scrap could automatically be channelled through this dynamic RAMdisc |> (though not a RAMdisc that pleb users can 'see' on the desktop) if enough Sounds like you are asking for a 'pipe' facility. This would be quite handy too. |> RAM exists for the transfer. Then, Wimp$Scraps will be equivalent to RAM |> transfers when the RAM is available. Not to mention there would be no point trying to support "real" RAM transfers, as the wimp$scrap method was just as good. |> Then when user clicks 'save' in Edit, it saves back to this RAMFS and |> the RAMFS sends you a DataLoad request or similar to get you to re-load the |> file for your own useage again. |> |> This could work, and it would also work with any application regardless |> of whether it actually had been written with this system in mind. Yes but it's not quite as flexible as a specific message pair for editors. While we are talking about RAMdiscs, how about the ability to create more than one at a time, and the ability to resize them on the fly? The current RAMdisc can be named, but there's not much point... Cheers, Julian. -- ;`````````````````````````````````````````````````````````````````````````````; ; I would if I could but I can't so I won't but I might if I find I can later ; ;,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,; jwright@comp.vuw.ac.nz julian@sideways.gen.ac.nz
nbvs@cl.cam.ac.uk (Nicko van Someren) (04/11/91)
In article <jwil1.671240542@cs7.cs.aukuni.ac.nz> jwil1@cs.aukuni.ac.nz (JasonCarlyle Williams ) writes: >OK, guys... You have recently been discussion the idea of invoking editors >(Edit, Draw, etc.) from within another App. along the lines that the editor >will pass you back the file when finished with it... >It's actually nigh on impossible to do this with current app.s (i.e. Edit >would probably have to be re-written to handle this special case) Complete rot! It would need very little change indeed. In fact I have implemented most of what needs doing by use of the txtedit library in C release 3. It is very simple. >How about a sort of RAM filing system for this? >When you want to do a transfer, you "save" your file to the RAMFS, which >automatically (dynamically) 'creates' a disc just for that one file. I think this will need much more work. The existing filing systems know nothing of the WIMP ( as this would require) - and why should they? >This has several dinky features: > >Wimp$Scrap could automatically be channeled through this dynamic RAMdisc >(though not a RAMdisc that pleb users can 'see' on the desktop) if enough >RAM exists for the transfer. Then, Wimp$Scraps will be equivalent to RAM >transfers when the RAM is available. Sounds like you want a pipe. I guess that would be handy. >Extra twiddly bits could be given to the FS when you save a file to it: >e.g. *SAVE file to RAMFS > *Run file (to invoke !Edit on it) > (And set 'twiddly bit' "return the file to me") The last one needs contact with the WIMP. Further more the second one will create a NEW COPY of edit. A message would use the existing copy. >Then when user clicks 'save' in Edit, it saves back to this RAMFS and >the RAMFS sends you a DataLoad request or similar to get you to re-load the >file for your own usage again. This is either cumbersome (you have to go menu, dialogue, OK) or need as much rewrite as before. >This could work, Any reason for the conditional there ? > and it would also work with any application regardless >of whether it actually had been written with this system in mind. A fair point... >(That should give you something to think about/winge about/ignore, anyway) >The Master of the Arcane Use messages, that is what they are there for! Nicko +-----------------------------------------------------------------------------+ | Nicko van Someren, nbvs@cl.cam.ac.uk, (44) 223 358707 or (44) 860 498903 | +-----------------------------------------------------------------------------+
S_JEKUTSCH@iravcl.ira.uka.de (|S| Sebastian Jek) (04/12/91)
In <jwil1.671240542@cs7.cs.aukuni.ac.nz> jwil1@cs.aukuni.ac.nz writes: > Extra twiddly bits could be given to the FS when you save a file to it: > e.g. *SAVE file to RAMFS > *Run file (to invoke !Edit on it) > (And set 'twiddly bit' "return the file to me") I think if you *Run a Textfile, !Edit will be installed a second (third...) time, because the RunType for &fff-Files is something like: *Run adfs::!Edit *%0 seba
Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) (04/12/91)
Rather than transfer a file
- how about allowing the editor to access the memory
of the calling application and passing pointers.
- This would make for more efficient use of RAM for large files
especially with multiple applications in use.
Problem: this appears to conflict with the philosophy of giving
each application its own "self_contained" address space. Maybe a mechanism
similar to the one used by "C" could be used (here the original application
is copied to the end of the application space and the new one loaded at
the beginning - hohum, this would seem to defeat the object of avoiding
multiple copies in RAM...).
Essentially I am against having multiple copies of anything in RAM,
as a matter of principle (suitable exceptions allowed).
-Gavin.
--
The main "user" of well brought up, and educated, children is the community
at large. So if you really believe in "user pays", charge the correct users
- stop overloading parents with financial penalties.
******* These comments have no known correlation with dept. policy! *******maumg@warwick.ac.uk (Pop Mobility Freak) (04/12/91)
In article <1991Apr11.215337.18049@comp.vuw.ac.nz> gavin@comp.vuw.ac.nz (Gavin Flower) writes: > >Rather than transfer a file > > - how about allowing the editor to access the memory > of the calling application and passing pointers. > > - This would make for more efficient use of RAM for large files > especially with multiple applications in use. > This sounds fine in practice but is impossible in reality due to the paging performed by the MEMC. When in the desktop an application can only access its workspace and no other applications' workspace. This is a sensible idea as it prevents nasty things happening to other programs if the current one should crash. Also if you allow some other program to edit your workspace directly any information you store about your workspace (such as a pointer to the end of the memory used by data) will become incorrect. And what will happen if the editor wants to make the file bigger? Where would the extra data be put without any chance of overwriting information needed by the host application? What would be even harder than these impossible problems (sounds like mathematics to me, degrees of impossiblity??) would be what happens when a new page is needed to be allocated to the host application to store the data as a task cannot allocate more memory to another task. PMF