rg20+@andrew.cmu.edu (Rick Francis Golembiewski) (03/03/89)
How about using the unix wildcard * instead of #? (or at least have a 1 character wild card). [Better yet switch to ARP commands! get RID of the BCPL once and for all] Have WB actually take advantage of multi tasking (ie have a task that takes care of drawing icons etc. so that you don't have to wait for all the icons to come up...) AUX: has some major problems too, for instance what happens when you get a requestor while using aux:? Well you just go and click with the mouse... fine IF you happen to be at the amiga, but then why would you be using AUX:? Also I belive that if you try opening two cli's to AUX: you get strange results (I did with a beta version and haven't tried it with real 1.3 yet...) Humm... it would be nice if con: was replaced with newcon: and shell was started automatically, so that you wouldn't have to mount open etc. every reboot. It would also make resident commands work ALL the time (since they only work under shell), also it will cut down on overhead for the 2 types of cli's (for instance, instead of having seperate commands & handlers for shell and cli there would only be one). Humm... that's about all I can think of for now... I'm sure that there is lots of things I've missed... +----------------------------------------------------------------------------+ | Disclaimer: Me? Post That, impossible I never post anything... | | TypetoYouLater(Everyone); --> "functional Good bye".... | | Rick Golembiewski [ Pronunciation is half the Battle, spelling the other] | +----------------------------------------------------------------------------+
andy@cbmvax.UUCP (Andy Finkel) (03/03/89)
In article <4Y3LOgy00WB7NFUmZh@andrew.cmu.edu> rg20+@andrew.cmu.edu (Rick Francis Golembiewski) writes: >AUX: has some major problems too, for instance what happens when you get >a requestor while using aux:? Well you just go and click with the mouse... >fine IF you happen to be at the amiga, but then why would you be using AUX:? >Also I belive that if you try opening two cli's to AUX: you get strange >results (I did with a beta version and haven't tried it with real 1.3 yet...) The requester coming up on the window is a feature, not a problem...its a message to the system operator that the remote terminal wants to change a disk or use the printer or something :-) That kind of operation would be difficult from a remote terminal. Seriously, you can write a simple program (in C, assembler, possibly in BASIC) to set the pr_WindowPtr of your process structure to -1, causing all system requesters to not appear; instead an error message is returned to the calling program. AUX: opens (intentionally) the serial.device in shared mode. This is occasionally very useful. If, for some reason, you forget, and open 2 CLIs to AUX: just type eennddccllii (each shell is taking every other character) -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Question of the Day : When will we get a device independent graphics standard that is fast enough to actually be useful ?" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
deven@pawl.rpi.edu (Deven Corzine) (03/04/89)
In article <6132@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: >AUX: opens (intentionally) the serial.device in shared mode. This >is occasionally very useful. If, for some reason, you forget, >and open 2 CLIs to AUX: just type > >eennddccllii > >(each shell is taking every other character) Probably so in that instance, but it is NOT a consistent phenomena. It is a race condition, and by no means is it nice clean rotation between the processes competing for the input. I managed (once) to get dnet started and initialized while the bbs which was running on the amiga was resetting, dropping DTR (and hence closing the device) while dnet started. Since both happen to open the serial port in shared mode, they both had it open and were competing for the input stream. the output from each to the modem seemed not to be affected. So, using dnet, I logged into itsgw.rpi.edu, and about 1/3 of the characters (randomly) from the login banner appeared in the dnet window, while the bbs caught the rest. However, dnet managed to get the entire "login:" prompt. Just goes to show there's no telling for sure in that sort of situation... Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
paolucci@snll-arpagw.UUCP (Sam Paolucci) (03/04/89)
I would like to see AmigaDOS grow up into a full blown command language which supports looping, testing (and I don't just mean WARN and all that crap), branching (like a goto (god forbid) so you can go back up in a script), variables, etc. I think AmigaDOS is a very weak part of the Amiga. Because of its very severe limitations you have to perform all kinds of contortions in order to accomplish something simple. Or worse still, you have to write a program. All you have to do is look at the ASK command. You can only use it for YES/NO questions, and even then you cannot even just test for YES/NO, you have to test for error condition flags. Can anybody tell me what YES/NO has anything to do with error levels? This is a bunch of crap and it makes reading and writing scripts harder than it needs to be. Mind you this is only one example among many. And ASK was not even available until 1.3 (I know, some people got it between 1.2 and 1.3). And there is a lot more that simply cannot be done by writing a simple AmigaDOS script because AmigaDOS is very weak. Well, that's my two cents. -- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
hugh@censor.UUCP (Hugh D. Gamble) (03/06/89)
If there's still a possibility that AREXX could be bundled with 1.4
that would take care of most scripting limitations.
What would $xx have to be to make it worth making everyone buy
AREXX with AmigaDOS whether they wanted to use it or not?
--
Hugh D. Gamble (416) 581-4354 {lsuc, utzoo}!censor!hugh (Std. Disclaimers)
I don't want to live in a beer commercial,
I just want to play with some of the girls from one. :^)rap@ardent.UUCP (Rob Peck) (03/07/89)
In article <61@snll-arpagw.UUCP>, paolucci@snll-arpagw.UUCP (Sam Paolucci) writes: > I would like to see AmigaDOS grow up into a full blown command > language which supports looping, testing (and I don't just mean WARN > and all that crap), branching (like a goto (god forbid) so you can go > back up in a script), variables, etc. > > write a program. All you have to do is look at the ASK command. You > can only use it for YES/NO questions, and even then you cannot even > just test for YES/NO, you have to test for error condition flags. Can I believe that some of Sam's objections have already been addressed in 1.3 (I just finished a very thorough examination of the released docs for an update to the Amiga Companion and found a lot to smile about). Regarding looping, take a look at the SKIP <label> BACK which does indeed let you form a loop. And the ENDSKIP command, when used, forms what might be called the "default:" part of a case statement wherein the execute-script-function does not fall off the end just because it never found the label you asked it to skip to. Related to the above, and handy because of it is the ability to answer ANY question, not just YES/NO ... from an example by Andy Finkel, and paraphrased: LAB BEGIN ECHO "TELL ME WHAT TO DO NEXT" ECHO "Commands may be abbreviated to one letter if you wish" ECHO "YOUR OPTIONS ARE 'LIST', 'DIR', and 'QUIT'" NOLINE SKIP >NIL: ? LAB LIST LAB L LIST SKIP BEGIN BACK LAB DIR LAB D DIR SKIP BEGIN BACK LAB QUIT [do what you wish here, then cause the script to exit... ] ENDSKIP ; now comes the default, if nothing was recognized ECHO "YOU MUST CHOOSE ONE OF THE AVAILABLE COMMANDS" SKIP BEGIN BACK So AmigaDOS HAS looping, and recognition of defaults, and more than just YES/NO built into it. About VARIABLES, well, there ARE environment variables recognized by the IF command, and ways to do things uniquely based on which CLI process is doing it (the <$$> option that substitutes the current CLI process to form variable names that are unique to the running process. Sam - to help me make the Amiga Companion a better book in this area, maybe you'd be willing to tell me what else you think AmigaDOS is missing, that might just be vague in someone's documentation. Yes, there are plenty of things that CSH and WSHELL address that are not in the DOS, but it seems that there are things that ARE there that some folks may not yet be aware of. Please use my email address, I am interested in getting to know what you "miss having" about AmigaDOS... I might not be able to influence CBM to add them, but as shown above, SOME of what you asked already seems to be there, with not much pain to access it. What else, please? I'll post to the net with answers if I can solve similar problems. (The first edition of the Amiga Companion does cover this topic in more detail, and includes descriptions of many if not all of the 1.3 options in command-scripts). Second edition will be even better, I believe. More examples, including explaining the startup-sequence in English, and a lucid description of the EVAL command example in the Enhancer docs. Kinda neat example, actually. Just needed some explaining. Rob Peck { <anywhere>... !uunet!ardent!rap }
rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) (03/14/89)
My list of wishes for 1.4 never has and end, does it? Yes, when 1.4 is out.
This is for us poor programmers.
Repeating gadgets: A gadgetype that would fire intuition messages as long as
it is selected. This could be similarily to INTUITICKS
in that no new messages are sent unless the previous
message has bee Reply()'ed. Ok. Not a gadget type but
a flag for all gadget types for which this is meaningful.
Gadget release: A message that the user released the button even if the
pointer wasn't positioned over the select box when he/she
did so.
Neither of these should be too hard to pack into the new ROMs.
----
Name: Robin Rosenberg, ]bo Akademi, FINLAND
work: ]bo Akademi, Computer Science, Lemmink{inengatan 14, 20520 ]BO, FINLAND
home: Studentbyn 40A3, 20510 ]BO, FINLAND
or Finn|, 22340 Geta, ]LAND - FINLAND
internet: <rosenbergr@finabo.abo.fi>
Translation: ']' is an 'A' with a ring on top, '|' is an 'o' with two dots.
'{' is an 'a' with two dots.jimm@amiga.UUCP (Jim Mackraz) (03/21/89)
In article <6269@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) writes:
)My list of wishes for 1.4 never has and end, does it? Yes, when 1.4 is out.
You'd be surprised. Wishing for Overscan in V1.2 never stopped ...
)Repeating gadgets:
Too easy. Just use Intuiticks. You don't want me to maintain ALL the
state information, do you?
)Gadget release: A message that the user released the button even if the
) pointer wasn't positioned over the select box when he/she
) did so.
SELECTUP is sent (Class MOUSEBUTTONS, Code SELECTUP). Again, you
have to maintain the state.
)Neither of these should be too hard to pack into the new ROMs.
...pack your mama in the new ...
Ahh, I'll put 'em on the list of easy things to use up the extra
space with ...
)Name: Robin Rosenberg, ]bo Akademi, FINLAND
)Translation: ']' is an 'A' with a ring on top, '|' is an 'o' with two dots.
) '{' is an 'a' with two dots.
Thanks for the suggestions.
jimm
--
Jim Mackraz, I and I Computing "Like you said when we crawled down
{cbmvax,well,oliveb}!amiga!jimm from the trees: We're in transition."
- Gang of Four
Opinions are my own. Comments are not to be taken as Commodore official policy.darin@nova.laic.uucp (Darin Johnson) (03/22/89)
In article <6269@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) writes: >Repeating gadgets: A gadgetype that would fire intuition messages as long as > it is selected. This could be similarily to INTUITICKS > in that no new messages are sent unless the previous > message has bee Reply()'ed. Ok. Not a gadget type but > a flag for all gadget types for which this is meaningful. A useful addition, I agree (good for scroll bars). It can be done without this addition though. For example, when the scroll bar arrow is selected (gadgetdown), set a flag. Then everytime you see an intuiticks message, check the flag. If it was set, pretend the user clicked again. You can also modify things so that it only works 1ce per second, etc. However, this doesn't fit 'cleanly' into a wait/get/process loop. >Gadget release: A message that the user released the button even if the > pointer wasn't positioned over the select box when he/she > did so. Similarly, you could check for a mouse up event, and then check to see what the last select down was. I can't think of much of a use for it, except that it matches menunull. Perhaps, if you had a "reset and clear all data" gadget, then if the user selected it, and then moved the mouse outside and released it, you could pop up a requester that said "You chicken!". I think the 1.4 designers will have to decide what features are 'necessary' based on how much coding, code space, etc it will save vs. how much work, library space is used adding these features. Right now, Intuition is a nice "medium level" interface. X is low level, SunTools is high level. Widgets in X move higher up the scale, without changing the base interface. Perhaps a new toolkit library (link or share) could be used, letting Intuition handle the important stuff, with the toolkit adding pop-up menus, automatic scrollbars, file requesters, etc. As a shared library, it has drawbacks, since everyone will want to put something in and there'll never be a stable version. More useful would be set of routines in C, assembler, etc. that do these things (although it would be an imposition to have Commodore be the clearing house for this). I haven't thought too long on this, but another useful library would be something to allow you to define your own functions, attach them as handler, and then the library would preprocess the intuimessages, possibly returning a user defined message. Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) Can you "Spot the Looney"?
scott@applix.UUCP (Scott Evernden) (03/23/89)
In article <485@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes: <In article <6269@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) writes: <>Repeating gadgets: A gadgetype that would fire intuition messages as long as <> it is selected. This could be similarily to INTUITICKS <> in that no new messages are sent unless the previous <> message has bee Reply()'ed. Ok. Not a gadget type but <> a flag for all gadget types for which this is meaningful. < <A useful addition, I agree (good for scroll bars). It can be done without <this addition though. For example, when the scroll bar arrow is selected <(gadgetdown), set a flag. Then everytime you see an intuiticks message, <check the flag. If it was set, pretend the user clicked again. Wouldn't it be more system-friendly to ModifyIDCMP() adding INTUITICKS at GADGETDOWN and removing INTUITICKS on GADGETUP? This strikes me as cleaner than having Intuition constantly firing off messages. As you say, this is all you need to do to implement the original request. -scott