Howdy Hi,
I found and was playing with menushel.src/bin menushell.js and menuedit.js. Very cool concept, but whole the generated menu/shell navigates menus fine, and will execute externals just fine, any internal commands throw an Error of:
Error: 'BBS' instance: No Private Data or Class Mismatch
This looks to be related to how commands are being called in menu-commands.js, but I don't see any reason offhand it shouldn't be working. Is this a known issue? Am I missing an include somewhere? Any other documentation related to any of it exist?
I found and was playing with menushel.src/bin menushell.js and menuedit.js.
Error: 'BBS' instance: No Private Data or Class Mismatch
This looks to be related to how commands are being called in menu-commands.js, but I don't see any
reason offhand it shouldn't be working. Is this a known issue? Am I missing an include somewhere?
Any other documentation related to any of it exist?
I found and was playing with menushel.src/bin menushell.js and
menuedit.js.
This was an experiment / proof of concept, and I highly recommend against using it. The code is a disaster.
Treat the entire thing as "shouldn't be working". There are probably a lot of other problems lurking than just this error. These scripts would need a lot of rehab or rewrite before I would recommend that anyone use them.
That reminds me, I was curious if you plan to update menuedit.js, or do you no longer have much
interest in it?
That reminds me, I was curious if you plan to update menuedit.js, or
do you no longer have much interest in it?
I have no use for it myself, so "interest" is sort of meh. I'd rewrite it as a public service if it's something that people (mostly new sysops) want.
The core idea was to create something that generates a menu spec (an INI or JSON file) which can be read and handled by any number of command shell templates. (I think I made a basic hotkey shell and a lightbar one.)
It worked, but I wasn't thrilled with it and never really recommended its use. I imagine I could do a better job today.
Treat the entire thing as "shouldn't be working". There are probably a lot of other problems lurking than just this error. These scripts would need a lot of rehab or rewrite before I would recommend that anyone use them.
I imagine new Synchronet sysops might find something like that useful. When I started using Synchronet, I think one of the most different things about Synchronet I noticed was that it uses command shells for its menu system and doesn't have a menu editor like many other BBS packages do.
Re: Menushell.js
By: Nightfox to echicken on Sun Aug 23 2020 10:22 am
I imagine new Synchronet sysops might find something like that
useful. When I started using Synchronet, I think one of the most
different things about Synchronet I noticed was that it uses command
shells for its menu system and doesn't have a menu editor like many
other BBS packages do.
And that's probably a component as to why 80% of synchronet installs are all the default shell and menu structure. Synchronet is wonderfully powerfull for customization, but the learning curve to doing so is somewhat steep.
I imagine new Synchronet sysops might find something like that
useful. When I started using Synchronet, I think one of the most
different things about Synchronet I noticed was that it uses command
shells for its menu system and doesn't have a menu editor like many
other BBS packages do.
And that's probably a component as to why 80% of synchronet installs are all the default shell and menu structure. Synchronet is wonderfully powerfull for customization, but the learning curve to doing so is somewhat steep.
if you're using baja its pretty easy
cmdkey x
[command]
end_cmd
that's all you gotta do is look up the docs, see what commands do what and
And that's probably a component as to why 80% of synchronet
installs are all the default shell and menu structure. Synchronet
is wonderfully powerfull for customization, but the learning curve
to doing so is somewhat steep.
if you're using baja its pretty easy
cmdkey x
[command]
end_cmd
that's all you gotta do is look up the docs, see what commands do what and put it in there and compile.
i suggest getting the renegade clone and changing the commands and screens. pretty easy to do. then you can add more as you need it.
i can understand how .js scares people away because it seems like a lot more code and it's all indented and and it overloads the average joe. ---
I find JS easier than Baja.. And some things in JS actually require fewer lines of code than Baja - For instance, you don't need an "end_cmd" type of thing in JS. You can use curly braces in JS, but if there's just one
matching), and it's fairly easy to do string searches, splitting, etc. with JS. I'm not sure how easy that kind of thing would be in Baja. It's been a long time since I've done Baja, so I may have forgotten.
I find JS easier than Baja.. And some things in JS actually require fewer lines of code than Baja - For instance, you don't need an "end_cmd" type of thing in JS. You can use curly braces in JS, but if there's just one line of code in the block, you don't need curly braces.. But I suppose I naturally find JavaScript easier since I was already a software developer.
Re: Menushell.js
By: Nightfox to MRO on Sun Aug 23 2020 05:35 pm
I find JS easier than Baja.. And some things in JS actually require fewer lines of code than Baja - For instance, you don't need an "end_cmd" type of thing in JS. You can use curly braces in JS, but if there's just one line of code in the block, you don't need curly braces.. But I suppose I naturally find JavaScript easier since I was already a software developer.
That entirely depends on what *Kind* of development you're doing as a developer; some of us don't use a whole lot of JS in our daily work. That said JS is reasonably quick to pick up for anyone who has dealt with similar languages, and I'm quite happy to have the available flexibility that it offers, but I think for someone just getting some customization started who isn't overly familiar that BAJA may be a little quicker to pick up. The possibility exists that I'm dead wrong on that though.
as "emergent", not really designed ahead of time. The result is kind of a cross between BASIC, assembler and some C. Baja shouldn't be familiar to anyone, really, and it stopped improving or evolving around 2001 when
with zero-control from the Baja module. I still have all that available in the JS object model (the 'bbs' object methods), but we also have fine-grained functionality. The language is *way* better than Baja and the number of functions/methods and properties available to the script-writer blows Baja away.
So... yeah, JS > Baja. :-)
Oh, undoubtedly. I was just trying to suggest that if someone were coming in new with no previous programming experience, Baja seems to me like it might feel more accessible. :) --- Underminer
I appreciate what you are saying Underminer. The coders want to argue which is better Baja or JS. As
SysOp I would love to see a menu editor built in to Synchronet like so many other BBS packages. But
that's never going to happen.
The Synchronet coders are going to claim how easy it is to write Baja
and Javascript.
That entirely depends on what *Kind* of development you're doing as a developer; some of us don't use a whole lot of JS in our daily work. That said JS is reasonably quick to pick up for anyone who has dealt with similar languages, and I'm quite happy to have the available flexibility that it offers, but I think for someone just getting some customization started who isn't overly familiar that BAJA may be a little quicker to pick up. The possibility exists that I'm dead wrong on that though. ---
HusTler wrote to Underminer <=-
Oh, undoubtedly. I was just trying to suggest that if someone were coming in new with no previous programming experience, Baja seems to me like it might feel more accessible. :) --- Underminer
I appreciate what you are saying Underminer. The coders want to
argue which is better Baja or JS. As a BBS Sysop I am interested
in Customizing the looks of the BBS. The cosmetics so to speak. I
also want to do this without crashing the damn thing because I'm
messing with internal code. As a dumb SysOp I would love to see a
menu editor built in to Synchronet like so many other BBS
packages. But that's never going to happen. The Synchronet coders
are going to claim how easy it is to write Baja and Javascript.
I've never really used JavaScript much in my work. I had just used it a little bit here and there, so I was somewhat familiar with it already, so it wasn't too difficult for me to pick up. So I'm mostly familiar with JS now due to my use of JS with Synchronet. But JS with Synchronet is different from its typical use as a web language though.. I'm still not too experienced with interacting with a web page DOM using JS. However I have embedded JS into a couple of C++ projects at one of my previous jobs, which was interesting.
I find JS easier than Baja.. And some things in JS actually require fewer lines of code than Baja - For instance, you don't need an "end_cmd" type of thing in JS. You can use curly braces in JS, but if there's just one line of code in the block, you don't need curly braces.. But I suppose I naturally find JavaScript easier since I was already a software developer.
Also I've found that text parsing (and sometimes text splicing) is something I've had to do fairly often with my Synchronet mods. For instance, reading a configuration file and parsing the settings into variables to be used in the JS script. JS has things that make it really easy to work with strings, such as regular expressions (for text matching), and it's fairly easy to do string searches, splitting, etc. with JS. I'm not sure how easy that kind of thing would be in Baja. It's been a long time since I've done Baja, so I may have forgotten.
I've never really used JavaScript much in my work. I had just used it a little bit here and there, so I was somewhat familiar with it already, so it wasn't too difficult for me to pick up. So I'm mostly familiar with JS now due to my use of JS with Synchronet. But JS with Synchronet is different from its typical use as a web language though.. I'm still not too experienced with interacting with a web page DOM using JS. However I have embedded JS into a couple of C++ projects at one of my previous jobs, which was interesting.
You don't need a menu editor to have custom menus. I know
virtually nothing about either JS or Baja, and pretty much every
single menu / disply file on my system is custom. Make an ANSI
menu with something like TheDraw (or Moebius or Pablodraw), and
then convert it (with the utilities included with SBBS) into an
ASC or MSG file. Done.
Also, I have made some fairly minor changes to the default.src
menu shell file, and recompiled it with Baja. Extremely simple to
do (instructions on the Wiki), and no programming skill required.
It's just a text file and it's very obvious how to edit it for
minor changes.
Get out of the box and learn something.
Oh, undoubtedly. I was just trying to suggest that if someone were coming in new with no previous programming experience, Baja seems to me like it might feel more accessible. :)
SysOp I would love to see a menu editor built in to Synchronet like so many other BBS packages. But that's never going to happen. The Synchronet coders are going to claim how easy it is to write Baja and Javascript.
experienced with interacting with a web page DOM using JS. However I have embedded JS into a couple of C++ projects at one of my previous jobs, which was interesting.
experienced with interacting with a web page DOM using JS. However I
have embedded JS into a couple of C++ projects at one of my previous
jobs, which was interesting.
Cool - which JS engine/library did you/they use?
Re: Menushell.js
By: Digital Man to Nightfox on Mon Aug 24 2020 04:08 pm
experienced with interacting with a web page DOM using JS. However I
have embedded JS into a couple of C++ projects at one of my previous
jobs, which was interesting.
Cool - which JS engine/library did you/they use?
It was the Mozilla JavaScript engine. Initially I tried using Google's JS engine, but it seemed a bit complicated to embed. Then I looked at Mozilla's JS engine (I was inspired to use it due to Synchronet), and I was able to embed Mozilla's JS engine into a couple of C++ test applications.
We also had a version of that project supporting iOS and Mac OS X, and we found that Apple's XCode included an embedded JS engine, so we used Apple's included JS engine for that stuff. I don't remember if that JS engine was made by Apple or if they had included another JS engine. It may have been Google's JS engine or Mozilla, but I don't remember for sure.
Tracker1 wrote to Gamgee <=-
You don't need a menu editor to have custom menus. I know
virtually nothing about either JS or Baja, and pretty much every
single menu / disply file on my system is custom. Make an ANSI
menu with something like TheDraw (or Moebius or Pablodraw), and
then convert it (with the utilities included with SBBS) into an
ASC or MSG file. Done.
Depending on the source ansi, I tend to favor a separate
(simpler) file for .asc/msg menu displays.
It was the Mozilla JavaScript engine. Initially I tried using
Google's JS engine, but it seemed a bit complicated to embed. Then I
looked at Mozilla's JS engine (I was inspired to use it due to
Synchronet), and I was able to embed Mozilla's JS engine into a couple
of C++ test applications.
Cool. What version of SpiderMonkey, if you remember?
I embedded SpiderMonkey into a set-top box test application (at work) with a web UI back in the early 2000's, about the same time I chose it for Synchronet's FTP server and eventually everything else.
Ah, cool. I might take a look at v8 again, but I'm planning to update to the latest SpiderMonkey at some point, which is expected to be painful.
I can see that you're a hard-talkin' straight-shootin' old-school sysop who likes to get shit done. If you have some thoughts about features you'd like see in a menu editor, please share.
You don't need a menu editor to have custom menus. I know
virtually nothing about either JS or Baja, and pretty much every
Also, I have made some fairly minor changes to the default.src
menu shell file, and recompiled it with Baja. Extremely simple to
do (instructions on the Wiki), and no programming skill required.
It's just a text file and it's very obvious how to edit it for
minor changes.
Get out of the box and learn something.
I think the main appeal of Google's V8 engine was that it was supposed to be very fast. But for something that's embedded into the apps we were using, I think Mozilla's JS engine was plenty fast. What benefit do you think there would be to using Google's V8 JS engine over Mozilla's JS engine with Synchronet?
Depending on the source ansi, I tend to favor a separate
(simpler) file for .asc/msg menu displays.
I'm not really sure what you mean by that.
Ah, cool. I might take a look at v8 again, but I'm planning to update to the latest SpiderMonkey at some point, which is expected to be painful.
I appreciate what you are saying Underminer. The coders want to
argue which is better Baja or JS. As
There's nothing to argue. Except for the learning curve, JS is better. If you find Baja easier to learn and can accomplish your goal within its limitations, it's a viable option. That pretty much covers it.
SysOp I would love to see a menu editor built in to Synchronet like
so many other BBS packages. But that's never going to happen.
We're in a thread about how I wrote a menu editor, it used to work, now it doesn't, and we're discussing the merits of revisiting the idea. That's hardly a "never going to happen" scenario. It happened before, it can happen again.
Re: Menushell.js
By: echicken to HusTler on Mon Aug 24 2020 11:00 am
I can see that you're a hard-talkin' straight-shootin' old-school
sysop who likes to get shit done. If you have some thoughts about
features you'd like see in a menu editor, please share.
Nah. I can't compete with you guys. DM, Nightfox and MRO and You Mr.Echicken. I've ran and hacked at just about every BBS package that's ever been developed. Today I'm just happy running one (Synchronet) that works. ;-)
i dont really think a decent menu editor can be made.
if he wants something where it shows him the lists of commands you can do and then assign a key and then it puts that into code and makes an ansi menu, i've done that like 11 years ago.
i just think something like that is limiting and editing your own command shell really allows you to tweak what you want to do and stack commands.
i dont really think a decent menu editor can be made.
if he wants something where it shows him the lists of commands you can do and then assign a key and
then it puts that into code and makes an ansi menu, i've done that like 11 years ago.
i just think something like that is limiting and editing your own command shell really allows you to
tweak what you want to do and stack commands.
Ah, cool. I might take a look at v8 again, but I'm planning to update to
the latest SpiderMonkey at some point, which is expected to be painful.
I think the main appeal of Google's V8 engine was that it was supposed to be very fast. But for something that's embedded into the apps we were using, I think Mozilla's JS engine was plenty fast. What benefit do you think there would be to using Google's V8 JS engine over Mozilla's JS engine with Synchronet?
I don't think the performance difference between V8 and SpiderMonkey is really significant these days. I'd only use V8 if it was easier/better for integrating into Synchronet. We'll see...From some experience, V8 would be significantly more difficult to
Nah. I can't compete with you guys. DM, Nightfox and MRO and You
i switched to synchronet because of the stability. i come from the netmodem days. the bad one.
if there's something you want to do with your bbs, i can probably show you h to do it easily. i'm very rusty but it comes back with some practice.
Thanks for the offer. I just wanted to convey my thoughts on a menu editor. I
understand the "Syncronet Way" of doing things. It's a bit archaic but I can
get by. When I paid for BBS package back in the day I looked for customization and support. I'm not
archaic but I can get by. When I paid for BBS package back in the day I looked for customization and support. I'm not going to see these things with free software. I can deal with that. I still think a menu editor would be nice to have for new SysOps.
Re: Menushell.js
By: HusTler to MRO on Thu Aug 27 2020 09:53:16
Thanks for the offer. I just wanted to convey my thoughts on a menu
editor. I
understand the "Syncronet Way" of doing things. It's a bit archaic
but I can
get by. When I paid for BBS package back in the day I looked for
customization and support. I'm not
It's funny how we all perceive these things differently. I feel like using a menu editor is, if not "archaic" ("oldschool", perhaps), a bit clunky and cumbersome. Meanwhile, to me, a scripted menuing system allows for far more "modern" features and is extremely flexible.
Just wanted to put that out there; it's a matter of different paradi
a menu editor is so so so extremely limiting.
i have all kinds of custom stuff in my menus. a menu editor couldnt accomplish that.
when you are used to using bbs softwares with menu editors that's what you expect from synchronet. maybe we can have both some day.
i totally understand how these guys feel because i ran renegade and iniquity and other bbs softwares before switching to synchronet.
in my old RA setup, i had menu options that dropped you through other menu files that you never saw any output from but those menu files executed commands that would flip user flags and set security levels and drop you out the other side looking at another menu on screen... just because it is a menu file doesn't mean that it has to display one menu screen and handle the options for it...
the best part about it was the dynamic display generation... there might be three "write mail" options but you only see one because of the access permissions to the others... at some point, more than one of those may be active... instead of drawing a static screen with all three showing, the system would draw a screen with only those available to you on it...
we also had codes we could put in the screens we drew that could execute menu commands so while you are viewing this nice ansi being drawn, your security level is being updated and your access flags set... getting one's head wrapped around it all was not easy but the finished product could be quite seamless...
Thanks for the offer. I just wanted to convey my thoughts on a menu
editor. I understand the "Syncronet Way" of doing things. It's a bit
archaic but I can get by. When I paid for BBS package back in the day
I looked for customization and support. I'm not going to see these
things with free software. I can deal with that. I still think a menu
editor would be nice to have for new SysOps.
It's funny how we all perceive these things differently. I feel like using a menu editor is, if not "archaic" ("oldschool", perhaps), a bit clunky and cumbersome. Meanwhile, to me, a scripted menuing system allows for far more "modern" features and is extremely flexible.
Just wanted to put that out there; it's a matter of different paradigms rather than one concept being older than the other.
replace any built in functionality you like. The hardest part for me,
is I've spent about a decade now using Node style build tooling, modules and npm; so dealing with Synchronet's load/require interfaces is a bit alien in practice. That and not having the autocomplete/tooling that VS Code gives you isn't very fun as well.
do various work for the BBS, but I'm not sure how many BBS sysops would feel about learning a more fully-fledged programming language to write a command shell. I suppose even Baja might seem intimidating to some new Synchronet sysops. Every so often, I've seen questions from new Synchronet sysops posted on Dove-Net asking how to change menu behavior etc., and some seem a little apprehensive or confused at first about Baja/JS command shells.
Nightfox
most people that i've encountered that run mystic and other softwares say they dont touch synchronet because you have to be a programmer to run it.
most people that i've encountered that run mystic and other softwares say they dont touch synchronet because you have to be a programmer to run it.
| Sysop: | Kurt Hamm |
|---|---|
| Location: | Columbia, SC |
| Users: | 7 |
| Nodes: | 20 (0 / 20) |
| Uptime: | 229:45:35 |
| Calls: | 2,774 |
| Calls today: | 2 |
| Files: | 64 |
| Messages: | 848,221 |