• load() search paths...

    From Deuce@VERT/SYNCNIX to All on Wednesday, August 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:

    - 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!)
  • From Tracker1@VERT/TRN to Deuce on Wednesday, August 05, 2009 20:59:01
    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
  • From Mindless Automaton@VERT/ELDRITCH to Deuce on Thursday, August 06, 2009 11:58:49
    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
  • From Digital Man@VERT to Deuce on Thursday, August 06, 2009 16:01:04
    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
  • From Access Denied@VERT/PHARCYDE to Deuce on Thursday, August 06, 2009 22:10:43
    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)
  • From Access Denied@VERT/PHARCYDE to Tracker1 on Thursday, August 06, 2009 22:15:46
    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)
  • From Deuce@VERT/SYNCNIX to Tracker1 on Friday, August 07, 2009 10:26:49
    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!)
  • From Deuce@VERT/SYNCNIX to Digital Man on Friday, August 07, 2009 10:34:52
    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!)
  • From Deuce@VERT/SYNCNIX to Access Denied on Friday, August 07, 2009 10:40:34
    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!)
  • From Deuce@VERT/SYNCNIX to Access Denied on Friday, August 07, 2009 10:43:00
    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!)
  • From Access Denied@VERT/PHARCYDE to Deuce on Friday, August 07, 2009 21:16:33
    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)
  • From Access Denied@VERT/PHARCYDE to Deuce on Friday, August 07, 2009 21:18:48
    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)
  • From Ragnarok@VERT/DOCKSUD to Deuce on Saturday, August 08, 2009 11:49:45
    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
  • From Tracker1@VERT/TRN to Deuce on Sunday, August 09, 2009 20:33:41
    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
  • From Jas Hud@VERT to Tracker1 on Monday, August 10, 2009 05:55:39
    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
  • From Jas Hud@VERT to Ragnarok on Monday, August 10, 2009 06:00:00
    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
  • From MCMLXXIX@VERT/MDJ to Deuce on Monday, August 10, 2009 11:36:33
    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)
  • From Deuce@VERT/SYNCNIX to Tracker1 on Monday, August 10, 2009 22:39:44
    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!)
  • From Digital Man@VERT to Deuce on Wednesday, August 12, 2009 17:31:54
    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
  • From Angus McLeod@VERT/ANJO to Deuce on Wednesday, August 12, 2009 23:24:00
    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
  • From Angus McLeod@VERT/ANJO to Deuce on Wednesday, August 12, 2009 23:26:00
    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
  • From MCMLXXIX@VERT/MDJ to Angus McLeod on Thursday, August 13, 2009 10:37:24
    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)
  • From Digital Man@VERT to Angus McLeod on Thursday, August 13, 2009 14:51:15
    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
  • From Deuce@VERT/SYNCNIX to Angus McLeod on Thursday, August 13, 2009 18:10:00
    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!)
  • From Deuce@VERT/SYNCNIX to Angus McLeod on Thursday, August 13, 2009 18:11:04
    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!)
  • From Corey@VERT/TSGC to Digital Man on Thursday, August 13, 2009 15:16:47
    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
  • From Angus McLeod@VERT/ANJO to Deuce on Tuesday, September 01, 2009 18:50:00
    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