@Razetime Well, you're always welcome to contribute for free, but for the paid work, I'll soon send out a small selected set of materials for all to review as a trial.
@Adám Where can I find the limit of Ride inbound buffer?
With multiline editor it would be nice to input a bit larger amount of data at the same time from a Jupyter Notebook. I'm using a dynamic function as a variable for a sql script and json.
@Adám Is there any plans that variables would be a bit different format as those are right now in ]link? That's the reason that I use dynamic functions.
Variables are saved as .apla and the format is not usable for example minify/prettily in external editors. []UCS13 in text file as hard coded sn't the best way to format file.
@kimmolinna However, in the general case, the format is considered close to final (do you have suggestions for improving it?). Of course, the system can become better at generating nicer-looking notation (less parens, better whitespace).
@Adám BQN lives just fine with no just-array-files and proper scripts. For this problem I'd just store the data in whatever format makes sense and parse it manually
@rak1507 Right, and that's what we were thinking people would do, but a few people have used the convenience of Link handling all that, only to end up with ugly files.
@dzaima really the problem here is when you try to mix interactive and script-based programming. The way link does it makes sense if you never intend to interact with APL outside the interpreter
@rak1507 Say I have a character constant that stores some UI text or some constant used in producing some output. I notice an issue with the text as the program runs. Hit interrupt, edit the variable, continue thread. Boom, file updated.
@JeffZeitlin Nothing has ever changed there: Try it online!
@dzaima Well, if you update the file, and have full dual-direction Link active, then the next time the application reaches a state where the variable's value is used, it will use the new value.
I like to the present state but apla should be a plain text file. Now it looks lik 'CREATE TABLE dyalog(',(⎕UCS 13),' it,',(⎕UCS 13),' can''t,',(⎕UCS 13),' be,',(⎕UCS 13),' like,',(⎕UCS 13),' this)',(⎕UCS 13)
@kimmolinna If the user saves two text that are almost identical, one using 13s and one using 10s, one without a final newline and one with a final newline, how would the files differ?
@Adám git has options for being sane with line endings. And code should work with either line ending type anyway. And I doubt the person creating the multiline string carefully chose the line separator characters.
@Adám well, you've already have a havoc. Git normalizing things would improve things :)
@rak1507 I have no clue what are the default settings, but I do know that if they're set to something you didn't expect, things get real annoying to diagnose
I suspect we'll end up encoding the structure in the file name; either as additional extensions, or as a kind of tag before the extension, e.g. myarray.1310.apla
@Adám if anyone does anything semi-automatic with the common-type-files, things will quickly fall apart & crash & break if someone manages to include ⎕ucs 10 and ⎕ucs 13 in a file
@dzaima In unrelated news: CTO watched my demo of your IDE, and now it looks like we'll start making Android builds so you can get a native interpreter to play with for it.
And earlier today I had problems with JupyterLab and Visual studio code due to different eols so I had to add the following line to settings of Code: "files.eol": "\n". So sometimes user has to know what to do. But sometimes it's really nice to trust working tools like ]link.create.
@kimmolinna Are you sure it is the right thing to use :abc syntax for these extensions? Wouldn't it make more sense to call tham ]multiline and ]vega-lite?