« first day (1639 days earlier)      last day (1020 days later) » 

3:37 AM
@Adám btw, can i start on adding to APLcart now?
 
 
5 hours later…
8:26 AM
@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.
 
9:00 AM
cool, cool
 
 
8 hours later…
4:58 PM
@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.
 
@kimmolinna I don't know; I suggest opening an issue on the RIDE repo.
 
Thanks for info.Using multiline editor is much faster than using ]dinput.
 
5:31 PM
@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.
 
@kimmolinna Not sure what you're asking. Can you try to explain a bit more?
 
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.
 
6:04 PM
@kimmolinna Ah yes, it is a logged issue.
@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).
 
6:23 PM
@Adám UTF-8 text file would be nice. ;) So basically it's okay like that without those ,⎕ucs 13, tags.
 
@kimmolinna It is UTF-8 text files.
Problem is, how do we distinguish between ⎕UCS 65 13 66 and ⎕UCS 65 10 66 and ⎕UCS 65 13 10 66 and ⎕UCS 65 10 66 10?
And what about vectors of text vectors?
And matrices?
One possibility would be to store that info in the file name.
 
please no
 
Do you have a better idea?
 
no, I don't have any input other than making the structure of files linked to the name sounds like a terrible idea
 
The name already affects the name of the variable it represents. Why not the structure too?
 
6:30 PM
@Adám yes, the name affects the name, not the type/anything else about the variable
 
We've been pondering this issue for a while.
 
two files with different names shouldn't represent different things
 
But the file extension does make such a difference.
Acre uses additional file extensions.
But even that can only handle a single type of simple vectors.
 
maybe the solution is to abandon link altogether and use scripts instead
 
We'd need 8 new extensions to cover everything.
@rak1507 That doesn't solve the problem of storing arrays in files.
And surely, you wouldn't want every application to consist of one giant script.
 
6:32 PM
why not? you store the APL code that generates an array, and that works just fine
@Adám obviously not, but that's not true in any language
 
@rak1507 How is that any better than the current situation where we store the APL code that generates an array, but in a separate file?
@rak1507 So your suggestion isn't serious.
 
it isn't, does it need to be better?
@Adám yes it is
 
@rak1507 Yes, because "plain text" variables are currently ugly, rather than being represented as plain text files.
 
no one's stopping someone from storing text in a file and reading it
 
@rak1507 So you're seriously suggesting that replacing the current situation with an equivalent situation is an improvement‽
 
6:35 PM
@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.
 
@Adám it's not really an equivalent, if it was an equivalent, considering the script version is so easy, this wouldn't be a problem in the first place
 
@dzaima ^^
 
@Adám well, that's why rak is suggesting abandoning link?
 
@Adám yes, because link is not an equivalent of actually storing code in scripts, like, everyone else
 
6:36 PM
@rak1507 OK, how would you store a "plain text array" in a script?
 
@Adám plaintext ← 'foobar'?
 
@rak1507 And if the text has multiple lines?
 
or plaintext←⊃⎕NGET'foobar.txt'
 
@rak1507 Right, but that's already possible.
 
@Adám but link doesn't make it doable once on load
 
6:38 PM
However, then you can't edit the text variable from inside APL.
 
if it's possible what's the problem atm?
 
@dzaima It kind of does.
@rak1507 I just said!
 
you can't edit the text variable? in which case, it's not already possible then
 
People take the shortcut of using plain variables instead of writing the little code that loads it, and then they end up with ugly files.
 
@Adám you wouldn't edit things from APL with scripts
 
6:39 PM
@rak1507 Well, you can edit it, but the change won't be reflected in the source file.
 
now I'm just confused
 
@dzaima Wrong. You wouldn't!
 
@Adám no, that's just how one does scripts.
 
just write a←⊃⎕NGET'foo.txt' in a script, easy peasy
want to update it? ⎕NPUT
 
if you still edit your proper script files from the interpreter, you're doing scripts wrong, period.
 
6:40 PM
@dzaima Not if one enjoys interactive programming, as many APLers (but obviously not you!) do.
 
@Adám well, those can suffer with link :)
 
/me was under the impression that APL was intended to be an interactive language...
 
@dzaima And they do, but they keep complaining that they want Link to create nicer-looking files for text variables.
 
I don't get how interactive programming and editing variables or something (??) have anything to do with each other
repls are great, in any language, I can also write scripts in nearly any language
 
@Adám well, that's just what you get for using interactive programming
 
6:41 PM
the two go together
 
Although I gotta admit I miss the del line editor. :)
 
@rak1507 Right, but people won't use ⎕NGET/⎕NPUT when there's a way to simply edit the text and magically have it stored. They've always done that.
 
@dzaima (and then wanting to edit the raw text file!!)
 
@JeffZeitlin It is still there.
 
Really? The last time I tried it in Dyalog, it put me into a screen editor...
 
6:43 PM
@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
 
@JeffZeitlin Some APLs do that. Not Dyalog.
 
That may have been a version or three back, though.
 
@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!
 
@Adám but if any part of that file was stored anywhere, you get a very wrong/inconsistent/broken state
 
@dzaima "part of that file"‽
 
6:45 PM
just update the file/variable as well I suppose
 
@Adám but that doesn't involve viewing the variable in an external editor from the file system
 
@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)
 
Problem is that if you use an external editor to modify the file, it has to be in a friendly format.
 
@Adám Exactly. I use VisualStudio Code to minify/prettify JSON.
 
6:48 PM
@kimmolinna But how would we store in the plain text file the fact that the text uses ⎕UCS 13 and includes a trailing one?
 
maybe the solution is to add backslash escapes or something... I'm not sure what the problem with that layout is anyway
looks fine to me
 
@Adám custom type files and bi-directional linking to a running interpreter are just things that do not mix.
 
@dzaima Uh, seems to work fine though.
 
@Adám Just save everything with UCS 13 and user can use external editor to delete extras.
 
(unless you go down the include-type-in-name)
 
6:50 PM
@rak1507 No, that's horrible!
 
@Adám uh, no? isn't that not working well what started this conversation?
 
@Adám "foo\rbar" vs 'foo',(⎕UCS 13),'bar'
 
@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?
@dzaima No, not at all.
 
JupyterLab and Visual Studio Code has exactly to same problem. I think JupyterLab uses just UCS 13 and in Visual Studio Code you can choose.
 
@rak1507 No editor would display those \rs as line breaks though. It'd be very unpleasant to edit.
 
6:52 PM
@Adám "the format is not usable for example minify/prettily in external editors" sounds to me like not working well
 
@Adám wouldn't be that bad
 
@dzaima That was a red herring. Of course the APL array notation doesn't work well with a JSON minifier/prettifier.
@rak1507 Yes it would, A multi-paragraph text would end up being a solid blob.
 
@Adám but it's still not working optimally for external editing.
 
@dzaima What isn't working optimally?
 
I'm pretty confused, what's the issue with storing strings as the raw representation?
 
6:54 PM
@Adám editing the file in an external editor.............................
 
@dzaima Works just dandy.
 
??!?!!? ! ? ?! ? !? !
 
@Adám you literally have a person complaining here
 
Not that the system isn't working, only that the file contents is ugly.
 
@Adám I said "not working well", not "broken"
not working well for the purpose of external editing
 
6:56 PM
@rak1507 Two problems: 1) Text files cannot be relied on to preserve exact bytes. 2) There is no raw representation of a vector of vectors.
 
@Adám 1) wat
 
@dzaima The only thing missing is a way to store the meta-info.
 
But I can always do it like this: fun←{
CREATE TABLE dyalog(
it,
can't,
be,
like,
this)
}
 
@Adám 1) why not? cosmic rays? 2) store shape information in the first line or something
 
@dzaima If you write 65 13 10 66 to a file, you might well get 65 10 66 10 back after a roundtrip through e.g. Git or an editor.
 
6:57 PM
actually no, that's a terrible idea, just use escape chars and that solves it
 
@Adám that's git being annoying & stupid
 
it's basically the only way to do good human readable vectors of arbitrary data
 
@rak1507 No it really doesn't. Besides for the ugliness, how would "escape" a vector of vectors?
 
(multiline strings should obviously exist in this context too)
@Adám "vector1","vector2" or something
 
if you want to roundtrip git, you must escape. But noone does that.
 
6:58 PM
@dzaima Agreed, but we can't fix Git.
@rak1507 That's basically what we do, but then people complain that they want their vectors of character vectors to be nice normal plain text files.
@dzaima It is unacceptable for an APL array to change just because it is roundtripped through a text file and Git.
 
how can someone reasonably expect that to work
 
@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.
 
@rak1507 Irrelevant. They do.
 
@Adám it's unacceptable for a file to change when subjected to a tool that changes files?
@Adám well, too bad
can't expect the impossible
 
@rak1507 No. It is unacceptable for the value that the file represents to change.
 
7:01 PM
@Adám it won't
the value a file represents will always be the same
 
Imagine if a roundtrip through Git would change the value a .json file represented!
 
@rak1507 git can (and sometimes does) actually change stored line endings
 
@Adám If you're doing a merge, that happens all the time
 
@rak1507 OK, how?
 
@Adám the value represented will be the same, the file may change
@dzaima I know, that's not a problem
 
7:02 PM
@user C'mon, that's not what we're discussing.
 
that's true for any file
if you don't want git to change the file, use it properly
 
Yes, but JSON and C and Python don't care about line endings.
 
or use \n or whatever and then it'll work fine
 
@rak1507 it kind of can if you were expecting 1 ≡ ≢⎕ucs 10
 
@dzaima sure, you could expect that in any language
 
7:03 PM
And just imagine the havoc if you mix a vector of vectors, and some 10s have become 13 10s!
 
that's not something that the language has a duty to fix
 
@rak1507 But that "solution" gives files that are almost as ugly as what we have now!
 
if you have a time machine, please go back and change it, but otherwise everyone just has to deal with it right
 
@rak1507 Change what? Git?
 
@rak1507 so you're fine with a←⎕ucs 10 ⋄ 1≡≢a giving 0 if you stored to git in the middle of the two lines?
 
7:04 PM
no, different line endings being used
@dzaima with improper settings that modify files? sure
 
And the various decisions to cause various OSs to use various line ending conventions?
 
@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 :(
that seems like the worst solution
 
worst only.
 
7:06 PM
how does that make editing the file easier?
it makes it harder
 
@Adám how does that work with mixed line endings?
 
@rak1507 That'll allow you to pleasantly edit the file with any text editor.
 
you can already do that!
 
@dzaima It wouldn't. For anything but the 8 supported formats, we'd fall back to full array notation.
 
@Adám well that's just weird
 
7:07 PM
@dzaima Not really. That's like JSON falling back to escapes for strings that cannot be represented literally.
 
@Adám yes! use escapes! yes!
 
But we don't want to escape everything.
 
@Adám it's more like JSON falling back to XML when it can't escape things
 
lmao
@Adám don't then
 
@dzaima Yeah, well, more like JSON falling back to XML when it can't represent things.
@rak1507 ???
People want nice looking text files for the most common cases.
 
7:09 PM
if they want nice looking files, make them, and then read them and parse accordingly
 
I'm sure nobody will be upset your file gets ugly if you try to store ⎕UCS 65 10 66 13 10
 
there's just literally no way to make a good file format capable of storing arbitrary vectors or nested vectors
 
@rak1507 That is exactly what we did. But here we are; people are complaining!
 
that also looks nice
@Adám tell them to deal with it
 
my solution would be to gzip/base64 array files so people just don't mess with them.
 
7:10 PM
@rak1507 We have the policy of trying to cater to the needs of our customers.
@dzaima We could certainly do that, but then they will complain that they can't edit the files using external editors.
 
Your customers can't make you defy the laws of physics, similarly they can't make you invent some incredible file format that can't logically exist
 
@Adám so make it nice & easy to bind proper plain files with custom parsing with ⎕nget or something
 
@rak1507 Correct. But with multiple file types, we can store the most common texts in a nice-looking way. That's what Acre already does.
@dzaima Yup, that's already in Link. :-)
 
@Adám with the "nice & easy" part?
 
Yes.
But of course, some want it to "just work", without having to configure additional file types.
 
7:14 PM
@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 No, then we just fall back to the general, no-so-nice-but-still-readable format.
 
(or, worse, less quickly & quietly)
@Adám but a JSON prettifier will scream about your ',(⎕UCS 10),' not being JSON
 
@dzaima JSON prettifiers probably don't like plain-text files either.
In fact, JSON prettifiers generally only work for JSON (and maybe JSON5 or JS).
 
@Adám a plain text file containing {"abc":12,"def":34} is very much a thing a JSON prettifier will like
 
@dzaima That's not what I meant by "plain-text files."
I meant a normal document, with human text on lines.
 
7:18 PM
well, that's not the only thing people will store in variables
 
Hold on, we're only talking about variables that have "plain text" in them.
All other arrays use APLAN.
 
@Adám config←'{"abc":12,"def":34}' is a variable with plain text, no?
 
@dzaima Yes, but 1) why in the world would you throw the file at a JSON prettifier? 2) even if you do, ⎕JSON wouldn't care.
 
and a person just expecting that config.10.apln will always contain the config will be extremely unhappy when it won't
 
Why wouldn't it?
Anyway, gotta go.
 
7:21 PM
@Adám if some person edits it on a system with CRLF endings in the interpreter, and the file moves to config.1013.apln
it's just a recipe for disaster to have a pretty plain-text file that sometimes changes name, or moves to a completely different format
imagine if one day your dyalog.dcfg file happened to convert to using XML just because people from two OSes added lines, leading to mixed line endings
 
@dzaima The interpreter doesn't do that.
 
@Adám well, that's fun. If a string has mixed line endings, editing it within the interpreter collapses all to ⎕ucs 10s
well, all it means is that it's harder to run into problems, which means that when you do, there's a lot more to break
 
7:39 PM
@dzaima imo the editor should refuse to edit mixed-lineending strings, just like it refuses vectors of mixtures of vectors and scalars.
 
@Adám yeah, that'd make sense
 
@Adám And It should be easily possible to fix those.
 
8:10 PM
@kimmolinna Right.
@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.
6
 
8:32 PM
I just got implemented :multiline feature to dyalog-jupyter-kernel. It's just 35 times faster than you ]dinput.
It uses Dyalog's LineEditor Mode.
 
8:44 PM
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.
 
9:07 PM
@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?
 
9:34 PM
Actually, ]vegalite to follow our naming conventions.
 

« first day (1639 days earlier)      last day (1020 days later) »