ked01@ccc.amdahl.com (Kim DeVaughn) (07/01/90)
In article <12940@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes: > > > I initially asked: > > Anyone know what the implementation of environment variables will be in > > the final version of 2.0? Still the 1.3 "files" implementation, or will > > env: be a real device as it was to become "eventually"? > > How things are implemented is less of a concern than how they work. There > is more than one place in the system where we could change the implementation > because the function interface is well defined. That may be true in theory Peter, but I am working on some code *now* that requires an env var or two. And since I currently have to roll my own fn() (since it was not provided by CBM in 1.3), I would like to know whether I'll need to change it under 2.0. Eventually (read: when the 2.0 Native Developer Package, or whatever is available), I'll change the code to use the official library call, assuming there is one in this release, but it'd be nice to know ahead of time if there will be problems due to a change in the implementation. So I ask again, will the 2.0 implementation be of the "files" variety, or will env: be a real device (as your "BTW" below would seem to imply)? > BTW, another big difference is your application can be automatically > notified when an environment variable changes. Sounds like a very useful enhancement. How's this accomplished? Thanks ...! /kim -- UUCP: kim@uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
peter@cbmvax.commodore.com (Peter Cherna) (07/03/90)
In article <9aR.02=i01Kp01@JUTS.ccc.amdahl.com> ked01@ccc.amdahl.com (Kim DeVaughn) writes: >In article <12940@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes: >So I ask again, will the 2.0 implementation be of the "files" variety, or will >env: be a real device (as your "BTW" below would seem to imply)? I think I didn't say "yes" because several other people on the net said so already. Yes, environment variables are files in ENV: under 2.0. >> BTW, another big difference is your application can be automatically >> notified when an environment variable changes. > >Sounds like a very useful enhancement. How's this accomplished? You may request notification when a file changes. DOS has a couple of calls (StartNotify() and EndNotify()) through which you can arrange to learn when a file changes. For example, IPrefs waits on notification from a bunch of files including ENV:sys/pointer.ilbm. Try saving a 4-color brush from DPaint to that name. IPrefs will pick up the change and make it your new pointer! Notification is very useful for Preferences and dynamic data linking. >/kim Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.cbm.commodore.com My opinions do not necessarily represent the opinions of my employer. "If you insist on spending $10000 on a 68030 technology, may we humbly suggest you buy three Amiga 3000's."
andy@cbmvax.commodore.com (Andy Finkel) (07/03/90)
In article <44hU02Ktb2DQ01@amdahl.uts.amdahl.com> kim@uts.amdahl.com (Kim DeVaughn) writes: > >Anyone know what the implementation of environment variables will be in >the final version of 2.0? Still the 1.3 "files" implementation, or will >env: be a real device as it was to become "eventually"? > >/kim Under 2.0 we have process (local) variables and global environment variables, There are now AmigaDOS calls to set, unset, and read the variables. ENV: is still an assign, generally to ram:env. We looked at the features that a seperate env: handler would want (notification, packing of small files into a single data block) and decided that RAM: would probably enjoy having them as well.... andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. ""Of course it's the murder weapon. Who would frame someone with a fake?" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
ked01@ccc.amdahl.com (Kim DeVaughn) (07/05/90)
In article <13000@cbmvax.commodore.com>, peter@cbmvax.commodore.com (Peter Cherna) writes: > In article <9aR.02=i01Kp01@JUTS.ccc.amdahl.com> ked01@ccc.amdahl.com (Kim DeVaughn) writes: > > >So I ask again, will the 2.0 implementation be of the "files" variety, or will > >env: be a real device (as your "BTW" below would seem to imply)? > > I think I didn't say "yes" because several other people on the net said > so already. Yes, environment variables are files in ENV: under 2.0. Thanks Peter (and in a subsequent posting, Andy) for the confirmation. I did see postings from other folks (thanks also), but with all of the various beta, gamma, and "diga" :-) levels of "2.0" floating about, it was unclear if that was to be the finalized implementation. Sorry if I sounded a bit "testy" ... I was just trying to emphasize that I really did need to know what the real implementation method is/was to be. > >> BTW, another big difference is your application can be automatically > >> notified when an environment variable changes. > > > >Sounds like a very useful enhancement. How's this accomplished? > > You may request notification when a file changes. DOS has a couple of > calls (StartNotify() and EndNotify()) through which you can arrange > to learn when a file changes. For example, IPrefs waits on notification > from a bunch of files including ENV:sys/pointer.ilbm. Try saving a > 4-color brush from DPaint to that name. IPrefs will pick up the change > and make it your new pointer! > > Notification is very useful for Preferences and dynamic data linking. I like it! Very nice enhancement, and sounds like a nice, simple implemen- tation. Without much thinking, I can see lots of uses for this ... thanks! BTW, congratulations on being this year's winner of the Boing! award. Well deserved! And have fun carrying the "Intuition Torch" ... I suspect you'll be in for a busy year or two ... /kim -- UUCP: kim@uts.amdahl.com -OR- ked01@juts.ccc.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25
koren@hpfelg.HP.COM (Steve Koren) (07/06/90)
> > You may request notification when a file changes. DOS has a couple of > > calls (StartNotify() and EndNotify()) through which you can arrange > > to learn when a file changes. For example, IPrefs waits on notification > I like it! Very nice enhancement, and sounds like a nice, simple implemen- Cool! I like it too. Question: are these calls implemented by polling or by some other method? In other words, is there any overhead incurred by having maybe 50 of them going on at the same time? AmigaDos has been very good about that kind of thing in the past, so I suspect polling is not used. - steve
jesup@cbmvax.commodore.com (Randell Jesup) (07/10/90)
In article <13920071@hpfelg.HP.COM> koren@hpfelg.HP.COM (Steve Koren) writes: >> > You may request notification when a file changes. DOS has a couple of >> > calls (StartNotify() and EndNotify()) through which you can arrange >> > to learn when a file changes. For example, IPrefs waits on notification >Cool! I like it too. Question: are these calls implemented by polling >or by some other method? In other words, is there any overhead >incurred by having maybe 50 of them going on at the same time? >AmigaDos has been very good about that kind of thing in the past, so >I suspect polling is not used. Correct. No evil polling is used, you are sent a message by the filesystem when the file changes. There is some amount of overhead involved, but under normal circumstances this overhead is fairly minimal. The Atlanta Devcon notes have explanations and discussion of this, and some of the neat "hot link"-like things that can be with them. Under the current 2.0 (for the A3000 and developers) notification only works in the ramdisk. The disk FS will support it RSN (it accepts the packets, but never actually tells you anything changed). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"