So, after looking at the vast (and increasing) number of *.js files in the execãdirectory which are not intended to be executed but are instead intended to beãload()ed by some other script, I've started thinking about a library system forãthe JS load() method. My initial thoughts are something like the following:ãã- There be some array of search paths for load() which can be added to by aã script. Additions can be at either end of the array, and these paths can beã either absolute or relative.ã- If the path is absolute, only a single directory will be searched.ã- If the path is relative, two directories will be searched, a "mods"ã style directory and a stock directory. The question of if these belongã under a shared parent directory (ie: jslibs) or under the exec/modsã directory is an open question.ã- Some way of specifying an initial list (in the ini file)ããYou would end up then with something like this:ãjslibs/ã std/ã sbbs/ã ars_defs.jsã nodedefs.jsã sbbsdefs.jsã sockdefs.jsã uifcdefs.jsã irc/ã irc-default.jsã irclib.jsã ircd/ã ircd_channel.jsã ircd_server.jsã ircd_unreg.jsã ircd_user.jsã mods/ã irc/ã irc-cyan.jsãEtc.ããThis change would impact all JS files, but with reasonable defaults, the impactãcould be mitigated.ããComments?ãã--- ãSynchronet - Jump on the Web 0.2 bandwagon!ãã---ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã

On 8/5/2009 4:22 PM, Deuce wrote:ã> So, after looking at the vast (and increasing) number of *.js files in the execã> directory which are not intended to be executed but are instead intended to beã> load()ed by some other script, I've started thinking about a library system forã> the JS load() method. My initial thoughts are something like the following:ã> ...ã> ã> This change would impact all JS files, but with reasonable defaults, the impactã> could be mitigated.ã> ã> Comments?ããI would think having an ../scripts/ directory along side of exec would be ãappropriate, perhaps modify/remove the scfg setting for a mods dir... as a ãbase script path, where relative script paths are loaded from as a base, ãfollowed by a search list as you suggested...ãã ../scripts/{input}ã ../scripts/mods/{input}ã ../mods/{input}ã ../scripts/std/{input}ã ../exec/{input}ããetc..ãã-- ãMichael J. Ryan - http://tracker1.info/ãã... Children are the only form of immortality that we can be sure of.ãã---ã þ Synchronet þ Roughneck BBS - telnet://roughneckbbs.com - www.roughneckbbs.comã

Deuce wrote:ã> Etc.ã> ã> This change would impact all JS files, but with reasonable defaults, the impactã> could be mitigated.ã> ã> Comments?ã> ããSeems reasonable to me. Anything to delineate the clutter seems good.ããThanks!ããMindless Automatonã---ã þ Synchronet þ Eldritch Clockwork BBS - eldritch.darktech.orgã

Re: load() search paths...ã By: Deuce to All on Wed Aug 05 2009 04:22 pmãã > So, after looking at the vast (and increasing) number of *.js files in theã > exec directory which are not intended to be executed but are insteadã > intended to be load()ed by some other script, I've started thinking about aã > library system for the JS load() method. My initial thoughts are somethingã > like the following:ã >ã > - There be some array of search paths for load() which can be added to by aã > script. Additions can be at either end of the array, and these paths canã > beã > either absolute or relative.ã > - If the path is absolute, only a single directory will be searched.ã > - If the path is relative, two directories will be searched, a "mods"ã > style directory and a stock directory. The question of if these belongã > under a shared parent directory (ie: jslibs) or under the exec/modsã > directory is an open question.ã > - Some way of specifying an initial list (in the ini file)ã >ã > You would end up then with something like this:ã > jslibs/ã > std/ã > sbbs/ã > ars_defs.jsã > nodedefs.jsã > sbbsdefs.jsã > sockdefs.jsã > uifcdefs.jsã > irc/ã > irc-default.jsã > irclib.jsã > ircd/ã > ircd_channel.jsã > ircd_server.jsã > ircd_unreg.jsã > ircd_user.jsã > mods/ã > irc/ã > irc-cyan.jsã > Etc.ã >ã > This change would impact all JS files, but with reasonable defaults, theã > impact could be mitigated.ã >ã > Comments?ããI like the idea of the dynamic search-path appendage ability, allowing 3rdãparty scripts (e.g. games, add-ons) to (easily) store all their files in someãdirectory other than 'exec'.ããI think the default directory for most scripts should still be mods & exec.ãWhat do you think of:ããexec/ã login.jsã logon.jsã listserver.jsã nntpservice.jsã etc.ãexec/includeã *defs.jsã *lib.jsã *util.jsããwhere 'exec' can be replaced with 'mods' (and is searched first), as is theãcurrent scheme.ããYou could use 'libs' instead of 'include' (the name isn't that important), butãI would just add one new default directory and move the lib/include type filesãthere. I wouldn't really call it a 'library system', as libraries historically,ãare collections (e.g. archives) of modules with callable functions. That's notãexactly describing the contents of the *defs.js, *util.js, and *lib.js files weãhave.ãã digital manããSnapple "Real Fact" #83:ãGoogol is a number (1 followed by 100 zeros).ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã

Re: load() search paths...ã By: Deuce to All on Wed Aug 05 2009 04:22 pmãã > This change would impact all JS files, but with reasonable defaults, theã > impact could be mitigated.ã >ã > Comments?ããIf you're talking about trying to make things more "findable" then I'm all forãit, though how would that affect the few of us who have searched through theãmess finding things to modify currently.. and have these things modified toãquite an extent?ããaxisdããã---ã þ Synchronet þ thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)ã

Re: Re: load() search paths...ã By: Tracker1 to Deuce on Wed Aug 05 2009 08:59 pmãã > I would think having an ../scripts/ directory along side of exec would beã > appropriate, perhaps modify/remove the scfg setting for a mods dir... as aã > base script path, where relative script paths are loaded from as a base,ã > followed by a search list as you suggested...ã >ã > ../scripts/{input}ã > ../scripts/mods/{input}ã > ../mods/{input}ã > ../scripts/std/{input}ã > ../exec/{input}ã >ã > etc..ããDon't listen to this guy. Have you seen his mods? Do you really need to go toã/home/sbbs/mods/roughnecks/user/find/this/program/if/you/dare/haha/I/got/you/duãmmy/ ?ããYou can do it so much easier with way less directories/subdirectories. You andãIspy just have a wierd fetish. :)ããI actually like it the way it is, except the fact that there's a few thingsãthat aren't moddable via text.dat that are only in the source code, but they'reãSTRINGS that should be able to be modified and saved, and not hopefully lost byãthe next update from CVS.ããI for one don't need a thousand directories and subdirectories.ããaxisdããã---ã þ Synchronet þ thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)ã

Re: Re: load() search paths...ã By: Tracker1 to Deuce on Wed Aug 05 2009 08:59 pmãã > I would think having an ../scripts/ directory along side of exec would beã > appropriate, perhaps modify/remove the scfg setting for a mods dir... as aã > base script path, where relative script paths are loaded from as a base,ã > followed by a search list as you suggested...ã >ã > ../scripts/{input}ã > ../scripts/mods/{input}ã > ../mods/{input}ã > ../scripts/std/{input}ã > ../exec/{input}ããThe question then becomes when it's appropriate to place a file in scripts andãwhen it belongs in exec. My outline was basically that load() would check aãset of directories in order, but exec() and friends would *only* look in modsãand exec.ãã--- ãSynchronet - Jump on the Web 0.2 bandwagon!ãã---ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã

Re: load() search paths...ã By: Digital Man to Deuce on Thu Aug 06 2009 04:01 pmãã > exec/ã > login.jsã > logon.jsã > listserver.jsã > nntpservice.jsã > etc.ã > exec/includeã > *defs.jsã > *lib.jsã > *util.jsã >ã > where 'exec' can be replaced with 'mods' (and is searched first), as is theã > current scheme.ããYeah, but I like the idea of allowing it to be deeper. As for include/lib, I'mãnot overly fond of either one to be honest... exec/load perhaps?ããI'm also very fond of the idea of adding a directory under the exec/mods dir toãgroup related files together... while I expect 3rd party scripts to be added toãthe mods directory rather than exec, a bit of grouping may help. The questionãof course is how to group everything.ãã--- ãSynchronet - Jump on the Web 0.2 bandwagon!ãã---ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã

Re: load() search paths...ã By: Access Denied to Deuce on Thu Aug 06 2009 10:10 pmãã > If you're talking about trying to make things more "findable" then I'm allã > for it, though how would that affect the few of us who have searchedã > through the mess finding things to modify currently.. and have these thingsã > modified to quite an extent?ããWell, for that, you would want to either modify the default search path set orãmove them to the newly appropriate place.ããI would expect that when you moved to the new exec directory and did NOT moveãyour modified scripts to match the new layout that the file from exec/load/*ãwould be loaded instead of the modified one. Once the modified one was placedãin the correct spot, everything would woprk once more.ããThe easiest thing though would be to modify the default set of search paths toãplace the mods directoy *first*. This would fix all the issues, but leave yourãmods dir cluttered.ããActually, maybe mods first would be part of the default...ãã--- ãSynchronet - Jump on the Web 0.2 bandwagon!ãã---ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã

Re: Re: load() search paths...ã By: Access Denied to Tracker1 on Thu Aug 06 2009 10:15 pmãã > I actually like it the way it is, except the fact that there's a few thingsã > that aren't moddable via text.dat that are only in the source code, butã > they're STRINGS that should be able to be modified and saved, and notã > hopefully lost by the next update from CVS.ããPart of the problem is that when I want to have different files load()ed asãpart of a script outside of the exec directory (such as with TradeWars), I needãto create the absolute path to the file on every load. Rather than saying:ãload("users.js");ããI need to say:ãload(path_to_door+"/users.js");ããWhich is kind of silly.ãã--- ãSynchronet - Jump on the Web 0.2 bandwagon!ãã---ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã

Re: load() search paths...ã By: Deuce to Access Denied on Fri Aug 07 2009 10:40 amãã > The easiest thing though would be to modify the default set of search pathsã > to place the mods directoy *first*. This would fix all the issues, butã > leave your mods dir cluttered.ã >ã > Actually, maybe mods first would be part of the default...ããI think it already checks the mods directory before exec, as that's where I putãall my stuff so when I upgrade, my exec dir can get manipulated however it hasãto be, and it won't affect the work I've done. I like that.ããaxisdããã---ã þ Synchronet þ thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)ã

Re: Re: load() search paths...ã By: Deuce to Access Denied on Fri Aug 07 2009 10:43 amãã > Part of the problem is that when I want to have different files load()ed asã > part of a script outside of the exec directory (such as with TradeWars), Iã > need to create the absolute path to the file on every load. Rather thanã > saying: load("users.js");ã >ã > I need to say:ã > load(path_to_door+"/users.js");ã >ã > Which is kind of silly.ããI see what you're saying. That would get kind of annoying. :)ããaxisdããã---ã þ Synchronet þ thePharcyde_ >> telnet://bbs.pharcyde.org (Wisconsin)ã

Deuce escribió:ã> So, after looking at the vast (and increasing) number of *.js files in the execã> directory which are not intended to be executed but are instead intended to beã> load()ed by some other script, I've started thinking about a library system forã> the JS load() method. My initial thoughts are something like the following:ã> ã> - There be some array of search paths for load() which can be added to by aã> script. Additions can be at either end of the array, and these paths can beã> either absolute or relative.ã> - If the path is absolute, only a single directory will be searched.ã> - If the path is relative, two directories will be searched, a "mods"ã> style directory and a stock directory. The question of if these belongã> under a shared parent directory (ie: jslibs) or under the exec/modsã> directory is an open question.ã> - Some way of specifying an initial list (in the ini file)ã> ã> You would end up then with something like this:ã> jslibs/ã> std/ã> sbbs/ã> ars_defs.jsã> nodedefs.jsã> sbbsdefs.jsã> sockdefs.jsã> uifcdefs.jsã> irc/ã> irc-default.jsã> irclib.jsã> ircd/ã> ircd_channel.jsã> ircd_server.jsã> ircd_unreg.jsã> ircd_user.jsã> mods/ã> irc/ã> irc-cyan.jsã> Etc.ã> ã> This change would impact all JS files, but with reasonable defaults, the impactã> could be mitigated.ã> ã> Comments?ã> ã> --- ã> Synchronet - Jump on the Web 0.2 bandwagon!ã> ã> ---ã> þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ãi think that the problem is the absolute pathããi want to load("pepe.js") and this will earch in the actual path not ãfrom exec directoryãbut, yes,, i agree to better order to the exec directoryãã---ã þ Synchronet þ Dock Sud BBS TLD 24 HS - http://www.docksud.com.ar - telnet://bbs.docksud.com.arã

On 8/7/2009 10:40 AM, Deuce wrote:ã> The easiest thing though would be to modify the default set of search paths toã> place the mods directoy *first*. This would fix all the issues, but leave yourã> mods dir cluttered.ã> ã> Actually, maybe mods first would be part of the default...ããwhat about a few shortcut sequences for paths?ãã "!/myfile.js" becomes /sbbs/exec/myfile.jsã "~/myfile.js" becomes /sbbs/mods/myfile.jsããif /sbbs/xtrn/tw/main.js calls "@/myinclude.js"ãit references /sbbs/xtrn/tw/myinclude.jsãã...ããAlso, per my suggestion befor, I think that ../scripts/std/ or ã../scripts/std/libs/ vs. ../scripts/mods/ and ../scripts/mods/ may be better ãthan the split of exec and mods currently... I think ../exec is a bit polluted ãhere.ãã-- ãMichael J. Ryan - http://tracker1.info/ãã... The only thing wrong with immortality is that it tends to go on forever.ãã---ã þ Synchronet þ Roughneck BBS - telnet://roughneckbbs.com - www.roughneckbbs.comã

Tracker1 wrote:ã> On 8/7/2009 10:40 AM, Deuce wrote:ã>> The easiest thing though would be to modify the default set of search ã>> paths toã>> place the mods directoy *first*. This would fix all the issues, but ã>> leave yourã>> mods dir cluttered.ãã> ã> Also, per my suggestion befor, I think that ../scripts/std/ or ã> ../scripts/std/libs/ vs. ../scripts/mods/ and ../scripts/mods/ may be ã> better than the split of exec and mods currently... I think ../exec is a ã> bit polluted here.ã> ããi dont think the exec\ dir is polluted. i think everything in the exec ãdir by default is perfectly applicable.ããthis is a bit of a difference of opinion but i think one should raise ãcaution regarding going too anal with this.ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã

Ragnarok wrote:ã> Deuce escribió:ãã>> jslibs/ã>> std/ã>> sbbs/ã>> ars_defs.jsã>> nodedefs.jsã>> sbbsdefs.jsã>> sockdefs.jsã>> uifcdefs.jsã>> irc/ã>> irc-default.jsã>> irclib.jsã>> ircd/ã>> ircd_channel.jsã>> ircd_server.jsã>> ircd_unreg.jsã>> ircd_user.jsã>> mods/ã>> irc/ã>> irc-cyan.jsã>> Etc.ã>>ã>> This change would impact all JS files, but with reasonable defaults, ã>> the impactã>> could be mitigated.ã>>ã>> Comments?ã>>ã>> --- Synchronet - Jump on the Web 0.2 bandwagon!ã>>ã>> ---ã>> þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã> i think that the problem is the absolute pathã> ã> i want to load("pepe.js") and this will earch in the actual path not ã> from exec directoryã> but, yes,, i agree to better order to the exec directoryã> ãããi disagree with the 'better order' mentality.ããi think making another dir for a handful of scripts will, in the long ãrun just pollute the synchronet dir with an overabundance of directories.ããi see no reason who throwing foo* into foo/ is any better than just ãhaving a sensible naming scheme for scripts.ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã

Re: load() search paths...ã By: Deuce to All on Wed Aug 05 2009 16:22:34ãã > So, after looking at the vast (and increasing) number of *.js files in theã > exec directory which are not intended to be executed but are insteadã > intended to be load()ed by some other script, I've started thinking about aã > library system for the JS load() method. My initial thoughts are somethingã > like the following:ã > ..ããWell I'm sure I've contributed to the mess in ..\exec\ãJust as I'm sure I'll contribute more in the futureããSo I agree there should be a better place to put scripts that are meant to beãfunction/object libraries, as almost everything I've put into ..\exec\ doesn'tãreally belong there, but has no better home at the moment.ããã---ã þ Synchronet þ The BRoKEN BuBBLE (MDJ.ATH.CX)ã

Re: Re: load() search paths...ã By: Tracker1 to Deuce on Sun Aug 09 2009 08:33 pmãã > what about a few shortcut sequences for paths?ã >ã > "!/myfile.js" becomes /sbbs/exec/myfile.jsã > "~/myfile.js" becomes /sbbs/mods/myfile.jsããYuck! No way. :-)ããMagical wildcards are icky.ãã--- ãSynchronet - Jump on the Web 0.2 bandwagon!ãã---ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã

Re: load() search paths...ã By: Deuce to Digital Man on Fri Aug 07 2009 10:34 amãã > Re: load() search paths...ã > By: Digital Man to Deuce on Thu Aug 06 2009 04:01 pmã >ã > > exec/ã > > login.jsã > > logon.jsã > > listserver.jsã > > nntpservice.jsã > > etc.ã > > exec/includeã > > *defs.jsã > > *lib.jsã > > *util.jsã > >ã > > where 'exec' can be replaced with 'mods' (and is searched first), as isã > > the current scheme.ã >ã > Yeah, but I like the idea of allowing it to be deeper. As for include/lib,ã > I'm not overly fond of either one to be honest... exec/load perhaps?ããYeah, I like exec/load (and by extension, mods/load).ãã > I'm also very fond of the idea of adding a directory under the exec/modsã > dir to group related files together... while I expect 3rd party scripts toã > be added to the mods directory rather than exec, a bit of grouping mayã > help. The question of course is how to group everything.ããWouldn't that be up to the 3rd party developers? I don't know how we couldãenforce a grouping.ãã digital manããSnapple "Real Fact" #57:ãYou blink over 10,000,000 times a year.ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã

Re: load() search paths...ã By: Deuce to Digital Man on Fri Aug 07 2009 10:34:00ãã > I'm also very fond of the idea of adding a directory under the exec/mods dirã > group related files together... while I expect 3rd party scripts to be addedã > the mods directory rather than exec, a bit of grouping may help. The questiã > of course is how to group everything.ããUsed to be that 3rd party add-ons (doors, etc) were put in their own ãdirectories under the /SBBS/XTRN directory. With JS now offering another ãoption for development of 3rd party add-ons, is it apropriate to install ãsuch add-ons under /SBBS/XTRN still? And if so, should any change to the ãJS load() method cater to add-ons in that location?ããã---ã þ Synchronet þ Making sure Jason works OK at The ANJO BBSã

Re: Re: load() search paths..ã By: Deuce to Tracker1 on Mon Aug 10 2009 22:39:00ãã > Magical wildcards are icky.ããUnless speaking Perl!ããã---ã þ Synchronet þ Making sure Jason works OK at The ANJO BBSã

Re: load() search paths...ã By: Angus McLeod to Deuce on Wed Aug 12 2009 23:24:00ãã > Used to be that 3rd party add-ons (doors, etc) were put in their ownã > directories under the /SBBS/XTRN directory. With JS now offering anotherã > option for development of 3rd party add-ons, is it apropriate to installã > such add-ons under /SBBS/XTRN still? And if so, should any change to theã > JS load() method cater to add-ons in that location?ã >ããI would have put everything in /sbbs/xtrn...... but the problem is that nearlyãall of my programs share a lot of the same functions and scripts, so i wouldãeither have to put everything in a /sbbs/xtrn/lib folder (which means I wouldãthen have to load everything from the same) or put it in /sbbs/exec orã/sbbs/modsããthe /sbbs/xtrn folder isn't really ideal (in my opinion) because it is alreadyãcluttered up with game directoriesããã---ã þ Synchronet þ The BRoKEN BuBBLE (MDJ.ATH.CX)ã

Re: load() search paths...ã By: Angus McLeod to Deuce on Wed Aug 12 2009 11:24 pmãã > Re: load() search paths...ã > By: Deuce to Digital Man on Fri Aug 07 2009 10:34:00ã >ã > > I'm also very fond of the idea of adding a directory under the exec/modsã > > dir group related files together... while I expect 3rd party scripts toã > > be added the mods directory rather than exec, a bit of grouping mayã > > help. The questi of course is how to group everything.ã >ã > Used to be that 3rd party add-ons (doors, etc) were put in their ownã > directories under the /SBBS/XTRN directory. With JS now offering anotherã > option for development of 3rd party add-ons, is it apropriate to installã > such add-ons under /SBBS/XTRN still?ããIt is appropriate for stand-alone JS add-ons, particulary door-type programsã(e.g. games).ãã > And if so, should any change to theã > JS load() method cater to add-ons in that location?ããYes, I think Deuce's propsal would do that.ããThe load() method can already load/execute full (absolute) paths, but thatãrequires knows the fullpath to the directory where the file was installed.ãRelative paths are assumed to be relative to the "mods" or "exec" directoryã(the current working directory is not relavent). The tricky part is specifyingãthe correct path for every load() statement and being able to dynamically addãpaths to the load() search is a good idea, I think.ãã digital manããSnapple "Real Fact" #152:ãIn 1985, the fastest bicyclist was clocked at 154 mph. ã---ã þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.netã

Re: load() search paths...ã By: Angus McLeod to Deuce on Wed Aug 12 2009 11:24 pmãã > Used to be that 3rd party add-ons (doors, etc) were put in their ownã > directories under the /SBBS/XTRN directory. With JS now offering anotherã > option for development of 3rd party add-ons, is it apropriate to installã > such add-ons under /SBBS/XTRN still? And if so, should any change to theã > JS load() method cater to add-ons in that location?ããI've been putting my JS stuff in xtrn, not sure if it's appropriate or not.ã:-)ããHowever, there are groups of functions and objects which are usefull in aãgeneral way, but aren't used by Synchronet proper. I've been dumping theseãthings into exec for now, but exec/load/doorkit would be my preference.ããAlso, I expect to add the directory that a scrip is loaded from to theãbeginning of the search path.ãã--- ãSynchronet - Jump on the Web 0.2 bandwagon!ãã---ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã

Re: Re: load() search paths..ã By: Angus McLeod to Deuce on Wed Aug 12 2009 11:26 pmãã > > Magical wildcards are icky.ã >ã > Unless speaking Perl!ããEven then! Perl doesn't have any additional wildcards that I'm aware of... itãuses csh wildcard syntax last I looked.ãã--- ãSynchronet - Jump on the Web 0.2 bandwagon!ãã---ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã

Re: load() search paths...ã By: Digital Man to Angus McLeod on Thu Aug 13 2009 02:51 pmãã > Re: load() search paths...ã > By: Angus McLeod to Deuce on Wed Aug 12 2009 11:24 pmã > ã > > Re: load() search paths...ã > > By: Deuce to Digital Man on Fri Aug 07 2009 10:34:00ã > >ã > > > I'm also very fond of the idea of adding a directory under the exec/moã > > > dir group related files together... while I expect 3rd party scripts tã > > > be added the mods directory rather than exec, a bit of grouping mayã > > > help. The questi of course is how to group everything.ã > >ã > > Used to be that 3rd party add-ons (doors, etc) were put in their ownã > > directories under the /SBBS/XTRN directory. With JS now offering anotherã > > option for development of 3rd party add-ons, is it apropriate to installã > > such add-ons under /SBBS/XTRN still?ã > ã > It is appropriate for stand-alone JS add-ons, particulary door-type programsã > (e.g. games).ã > ã > > And if so, should any change to theã > > JS load() method cater to add-ons in that location?ã > ã > Yes, I think Deuce's propsal would do that.ã > ã > The load() method can already load/execute full (absolute) paths, but thatã > requires knows the fullpath to the directory where the file was installed.ã > Relative paths are assumed to be relative to the "mods" or "exec" directoryã > (the current working directory is not relavent). The tricky part is specifyiã > the correct path for every load() statement and being able to dynamically adã > paths to the load() search is a good idea, I think.ã > ã > digital manã > ã > Snapple "Real Fact" #152:ã > In 1985, the fastest bicyclist was clocked at 154 mph.ã > ããgeez what a load.ããCaput meum major podice meo.ãThis message has ended, go in peace...ãã---ã þ Synchronet þ Three Stooges Gentlemens Club - Las Vegas, Nvã

Re: Re: load() search paths..ã By: Deuce to Angus McLeod on Thu Aug 13 2009 18:11:00ãã > > > Magical wildcards are icky.ã > >ã > > Unless speaking Perl!ã > ã > Even then! Perl doesn't have any additional wildcards that I'm aware of... ã > uses csh wildcard syntax last I looked.ããPerl REs are the de facto standard by which other REs are measured. Not ãusing csh, I couldn't say if it is equivilent to Perl REs or not. But are ãyou referring to csh file globbing? That isn't exactly the same as Perl ãpattern matching.ããI guess it depends on the word 'wildcard' which might be the same as the ãterm 'metacharacter' in a Perl RE, or might *specifically* imply file ãglobbing. ããã---ã þ Synchronet þ Making sure Jason works OK at The ANJO BBSã