But you can only be an operator if you join an empty room. If the operator leaves, it'll be operator-less until the room clears, which is pretty much impossible unless the server has split.
@RomillyCocking Personally, I tend not to use scripted namespaces, but use Link to map the code in a namespace to a folder, so that I have one file per function. If I do think a single script will work well, I create it in the editor. But then the Dyalog editor is still my primary editor, VS Code is still playing second fiddle.
@RomillyCocking we are still on a long journey towards Dyalog APL considering file based source as the primary mechanism. New users expect it, but the vast majority of existing users still haven't learned to love it and prefer workspaces or home made source code management systems.
@Adam I normally just type stuff in the session, and do not use the editor (unless I really need to). In than case, my understanding is that ]link does not know about my code. Am I mistaken?
@RomillyCocking Link will pick you your code (not tacit stuff, though) when you create the initial link. After that, you have to tell it to add things using ]add
This will also allow you to run without a file system watcher, and catch things that the file system watcher might have missed (they can overflow and lose stuff)
Clear help would be better than now, but the installation requirement would still annoying. Once I know I had to install 3.1, it took me about 30 mins to find out how to install the right version for the distros I use (Linux Mint 18.3 and Rasberry Pi OS)
DotNet is one of the things that keeps the Dyalog CTO awake at night. On the one hand, a cross-platform library enables the writing of portable software. On the other hand, this only works if there is widespread adoption or at least no resistance.
@RomillyCocking Oh, I misread that as you using 30 mins to find out which version of Link to install. But that would have been "2.1" not "3.1". My bad.
@MortenKromberg One of the things that SAAS vendors have learned is that there is a very clear and very strong inverse relationship between friction and adoption.
@MortenKromberg Most of the Linux users that I know are still strongly resistant to .Net
@ngn It's the ability to spot changes in the file system (not to save), and of course there are Linux APIs that do that. So you're right, it's not necessary, but it would require Dyalog to maintain a second version of the code to service a market segment that is currently not significant.
That's a commercial decision, and it depends on the estimated discounted lifetime value of future customers. That's not easy to calculate with any confidence.
I don't see it so much as a commercial decision as a search for cross platform tools. What would you think of as an alternative to .NET if you want the same APIs available on Windows, mac or Linux? Or is that simply too much to hope for. As a Windows users accustomed to having a single set of APIs, I find Linux intensely frustrating, because there are so many bewildering options that seem to be in a constant state of churn.
If you are a software engineer, you may find that exciting. But if you just want to [make it possible for your users to] solve problems with a computer, it is intensely frustrating.
@MortenKromberg My point is that there is no zero-install cross-platform solution, so you have to chose between what you do now or have the developers maintain two versions. (Maybe three - I don't know if the Unix API solves the problem on the Mac).
@RomillyCocking Not zero install, but that isn't a big deal if the installation is easy. I'm surprised you had problems with .NET, I have just clicked on the button and had it work first time under both Linux and Mac.
@MortenKromberg What button? (I.e. what URL got you to a page with a button)
@MortenKromberg It is a big deal even if the installation is easy. SAAS experience I've seen is that requiring users to install something results in losing ~80% of would-be users.
I can't even remember. Did a Google, clicked a link, started APL, used .NET (in my case it was a bit trickier because it was a pre-pre-pre-release of APL and it had bugs in it, but all the problems were on our side)
@RomillyCocking I understand that, but having no easy-to-use APIs available means you have no application to install
@MortenKromberg I think it would take days, rather than weeks, of development time for someone with the right skills to get ]link working using the Linux API when running. Only you can tell if that would be worth the delay to whatever else they'd be working on.
@MortenKromberg Most of the people here would either not want to try or find the pain tolerable, This audience is not typical of your non-served market.
@RomillyCocking afaik, the Linux and Mac alternatives are very limited compared to the .NET service. E.g. we'd have to set up monitoring of every subdirectory separately rather than one central monitor for an entire directory tree, and quickly set up a new monitor when a new subdir was created, etc.
In essence, we'd have to duplicate the work done for .NET already.
From my limited knowledge of inotify I believe it makes it easy to add sub-directories to the watch list when they are created. I know nothing about the Mac.
@RomillyCocking if all I was looking for was a File System Watcher, we would not have used .NET. But we are trying to make cryptography, file compression, etc etc trivially available to our users who want to write portable applications.
@RomillyCocking First I hear of it. Hence my question. I briefly looked at the docs for it, but it seems to be a package of all kinds of stuff, including "optional linux inotify support". I can't find mention of an enhancement over inotify.
@Bubbler I work with financial companies (mostly banks), and I only ever see .net at small banks with low levels of investment in their infrastructure.
It seems to me it's the cheap simple solution when they don't want to pay for developers.
@MortenKromberg In other words, you are looking for a low-develpment (for Dyalog) solution at the expense of user experience. That's a commercial decision rather than a a technical one, and I accept that you have mich more data and much more relvenat experience to make that decision that I do.
@EliasMårtenson I do more development in Python than APL, and I expect that to continue. For most of the things I do, Python is a more efficient tool for me. For what I am doing in AI, APL is much better.
@RomillyCocking No, I'm looking for a truly cross platform solution that delivers many APIs to our customers in forms that are easy to use. For Dyalog to cover a variety of constantly changing libraries with wrappers that make them easy to use for APL users would not just be expensive, it would be impossible.
@Adám as for monitoring a directory tree with inotify, it isn't very hard. You just have to manage the handlers per directory, but it's not much code.
I don't think openssl or libz have had any incompatible changes to their API's for the last 20 decades. The last change I know of was when openssl went from 0.9 to 1.0.
As far as I know, there have been significant changes to openssl in the area of supporting certificate stores etc. But of course cost is an issue here. Either Dyalog has to monitor all the APIs that anyone would want to use and keep the nice APL wrappers up-to-date, or we interface to a self-describing framework like .NET and everything it can do is instantly available to all users of APL.
@MortenKromberg I'm terribly sorry for disagreeing with you here, but .net is not a monolithic thing. It also changes API's. The fact that all of these separate API's are baked into a single thing doesn't make manging it any easier. You're going to have to deal with the same issues, regardless of whether the TLS incompatibility is introduced by .net or openssl. The same goes for other libraries.
I'd even go as far as arguing that things like libz, openssl, etc are so deeply rooted that they are less likely to change than .net
@EliasMårtenson I'm not saying the CONTENT of .NET is necessarily good, only that users of small languages like APL benefit enormously from the fact that the framework is self-describing and therefore we can call anything in it from APL. For all other solutions, we have to hand make a solution for each individual library that we want to make available to our non-technical APL users.
@EliasMårtenson We had an experimental java bridge, but it was never rolled out due to a lack of client interest. In the last few years we have not thought much more about it as the perception is Java is fading away.
I am about to start work on a Link tutorial. Anyone keen on playing with Link is welcome to play with the new Link and complain or ask me direct questions about it. To get hold of the new Link, which will be shipped with Dyalog 18.1... git clone the dyalog/link repo to /some/folder set DYALOGSTARTUPSE=/some/folder/Link/StartupSession before starting APL replace the file SALT/Spice/Link.dyalog (which defines the Link user commands) in your Dyalog installation with /some/folder/SALT/SPICE/Link.dyalog
Do the last thing first, you may also need to do a ]ureset after replacing Link.dyalog to make sure the UCMD system has picked up the new user command definitions.
@RomillyCocking Fortunately, the new version of the Link user command cover now gets all the information it needs from the installed version of Link, so that extra step should not be required again. In the past, the user command was separate from Link itself.
@RGS Can you be more specific? I believe they should be more or less the same as the section titled "Standard Installation", except with v18.0 and later you no longer need to update startup.dyalog.
That would only be required for earlier versions than 18.0.
@RGS ah, sorry, moving a bit too fast as usual. I think the instructions tell you to overwrite Link inside the Dyalog installation, while I am thinking all you cool kids will want to clone the repo outside the Dyalog installation and therefore need DYALOGSTARTUPSE to redirect to that.
right, but it relies on non IO independent code as a way of generating stuff so I don't like it very much
I should've put that in the cmc
@ngn half of the time in ngn/k I can't tell if something's a weird output or an error! would it kill you to put the word 'error' in your error messages lol
> The GNU project has numerous jokes around ed hosted on its website. In addition, an error code called ED is defined in glibc: when asked to print out its description (errorstr), the library returns a single question mark. The documentation is simply "the experienced user will know what is wrong."[10]
@ngn that's only a 100:1 ratio between ngn/k which does approximately nothing, vs salt which has a ton of contents. I expected at least 1000 if not a couple magnitudes more
@rak1507 KAP only saves princesses as their fathers start searching for them in their chambers. before that, only a thunk can be heard from behind the closed doors
