the-carlisle-group / acre-desktop Goto Github PK

Just a thought...

]clonerepository https://github.com/the-carlisle-group/Acre-Desktop c:\temp\myprojects

I'm just in the process of planning the SwedAPL '18 user meeting in Malmö. I've spoken to Morten and he is happy to talk about their plans for a package manager for APL. I'm sure this topic is something you all have been thinking about, but I wonder if you have thoughts on how something like that would fit in with Acre-Desktop.

If I create a project containing date utilities and name it "Dates". Would I also create a distribution version in the form of a .dws file for other developers to consume or would they have to use Acre-Desktop and open/load the source code version?

How do you envisage handling dependency issues?
Example:
ProjectA depends on ProjectX-version1
ProjectB depends on ProjectX-version2
ProjectC depends on ProjectA and ProjectB

Should ProjectC list all its dependencies (direct and indirect)?

@PhilLast acre readme.txt file should be part of the project. Right now I don't upload it. I think this will cause a name conflict with the default ReadMe.md for git projects.

In issue #4 Phil stated that the existence of .acre, APLCode and acreconfig.text in folder constitute a project.

That must mean that CreateProject is creating them but it only creates .acre.

Without SetChange Fire cannot tell acre what it has changed.

We can use this to track progress of features.

When only one project is open, the project folder is not displayed:

        ]aCRE.Projects
#.CarlisleGroup.FlipDB
        ]aCRE.Openproject c:\APLProjects\dfnnotes 
Opening  from c:/APLProjects/dfnnotes/
 into #.notes
327 items loaded  from c:/APLProjects/dfnnotes/.acre/codefile
#.notes
         ]projects
 #.CarlisleGroup.FlipDB  c:/APLProjects/FlipDB/   
 #.notes                 c:/APLProjects/dfnnotes/ 
 

Fixed

Please see the wiki page named "Item Name and File Names".

We could get rid of "OpenProject" by introducing a flag like

]acre.LoadProject -monitor=0

which of course defaults to 1, or something similar like -nomonitor when -no would suffice.

In old versions of acre, a list of the fully qualified names of functions loaded from change files would spill into the session on opening. This doesn't happen now, and that is good.

However, it is extremely useful to have a way to get a list of items recently worked on. This is how I know what the heck I was doing on Friday when I arrive at work Monday morning. I suggest something like:

      ]Acre. Changes projectspace
#.CarlisleGroup.FlipDB.Foo1
#.CarlisleGroup.FlipDB.Foo2
...etc.

In fact, perhaps this should be combined with ]History, we could use the same command for both; GIve it a project space and you get a list of recent changed items, give it an item and you get the most recent versions of the item - everything always with most recent at the top.

I would have thought that CreateProject would leave me with an open project, but I am forced to explicitly open it after creating it. Any reason it shouldn't just be open on creation?

Editing an item in the OS, and then attempting to open the project, fails.:

       ]aCRE.Openproject c:\APLProjects\dfnNotes   
Opening  from c:/APLProjects/dfnNotes/
 into #.notes
327 items loaded  from c:/APLProjects/dfnNotes/.acre/codefile
1 update imported  from c:/APLProjects/dfnNotes/APLSource/
* Command Execution Failed: FILE NAME ERROR

The PurgeHistory command displays as follows in the session:

            ]aCRE.purgehistory #.FlipDB
      Opening  from c:/APLProjects/FlipDB/
       into #.FlipDB
      Creating Code folder
      #.FlipDB

I understand that under the covers it is deleting the .acre folder and then re-opening the project, but that is an implementation detail, and the message is rather confusing. I think it should just say some thing like "Local history purged".

Things are so fast right now, or so it appears to me, that we might not even need the code file in the future, and all purge history would do is delete the change files....

Sometimes I fail to understand how it possible to write any working piece of software at all:

Yesterday night I worked on Fire. When I run the test cases one of them failed that exercised acre's ]erase command. The interesting bit is that it should have failed all the time, on all versions of acre, but it didn't.

The test case creates a small project with some stuff in it. Now the interesting bit is that one object is a scripted namespace (say Foo) which contains two functions (say Hello_1 and Hello_2) of which one - Hello_1 shall be deleted.

The naive approach ]erase Foo.Hello_1 does not work: although acre is creating a DEL file in the changes folder the script remains unchanged, meaning that despite the DEL file the function will appear again when the project is re-opened. The script in the APLSource folder does not change at all, so the text file and the DEL file are sort of out of sync.

One could argue that this is in line with the behaviour of ⎕EX and ⎕FIX which both seem to work on scripted namespaces but don't. (They delete/fix but don't change the script anyway, meaning that the script and what is actually available in the workspace are out of sync. According to Dyalog this is be design) But even if that is confirmed acre must not create the DEL file in the changes folder then.

BTW, Fire is checking when it does a delete on an object. If it realizes that it's an object within a scripted namespace it modifies the scripts. I can now either call ]erase or putChange.

I am concerned about introducing :CharList or :Text to distinguish text files. Text files are likely to contain stuff like MarkDown, HTML, CSS, JavaScript, stuff that other apps are likely to want to read and write. It is going to be annoying at best and a showstopper at worst to have :Text and :End wrapping a markdown file, when collaborating with other people and other software.

What about revisiting Norbert’s suggestion of using extensions to determine the item type? So .txt would be used for vectors of text vectors. We might also consider .array or better yet, .aplan for general APL arrays and namespaces. We could introduce as many extensions as necessary, but I think these two are probably enough to get started.

Thus .dyalog would be reserved for things that Dyalog knows how to fix. Of course in the future that might include arrays, but that should be easy to switch over to if desired.

So .array is the most general, and then we have things like .txt and potentially .charmat, .string, etc., – though I don’t know if these are really needed. One thing that would occur is that if you manually created a .aplan file in the op sys, and then edited it in the session, Acre might write it out with a different extension – demoting the type if you will. I think this is OK.

We could also allow .json, though Acre would not write this out – it would be one-way. I think this is OK to.

As I write this, it occurs to me that any extension not recognized as something else should be treated as a txt file and brought in as a vector of vectors.

I intended to create a namespace script but chose the wrong indicator for )Ed and ended up with a class.

I then opened it again in the editor and change it from :Class Foo to :Namespace Foo. By then I already asked myself what acre would do.

Turns out that I had two scripts in the APLSource folder afterwards: Foo-1.script and Foo-1.class. The contents of the changes\ folder is consistent with this.

When I re-open the project the class wins.

I think that this behaviour is not what it should be. acre should complain - or give a warning - about the name conflict either when the type change occurs or when the project is re-opened.

When a namespace foo contains a class goo and a sub namespace foo.boo contains a reference pointing to goo then CreateProject creates two files for the same thing.

That is clearly wrong but it is not even clear to me how that can be fixed. After all the two are the same thing.

Also, what happens when the user edits one of them?

I made a typo when specifying a function call on "StartUp" in acreconfig.txt.

Acre does not tell; it should.

If the folder already exists, and it looks like a project folder (that is, it contains an APLSource sub folder), then we get:

       ]aCRE.Createproject 'c:\APLProjects\VarTest'
The folder already contains a project - use OpenProject

The folder IS the project, so I think this error message error message should be more like "Project already exists."

If the folder exists but is empty or contains random stuff then Acre goes ahead and converts the folder into a project folder. How do we feel about this?

I'm leaning towards saying that CreateProject should insist that the project folder does not exist.

Opening a dependent project ref'd in "Open" config parameter above the main project is possible and obviously shouldn't be.

Something for me to sort out tomorrow.

I think the landing page should mention minimum Dyalog APL requirements. @PhilLast do we know how far back Acre Desktop is compatible or is this a V16 clean slate start?

@PhilLast

]erase #.CAS.LBQUERY.*
]erase #.CAS.LBQUERY

is not erasing anything. Am I missing something?

]erase on a full item path works as expected.

The ReadMe.txt talks about acre 3.

Here are the current contenders.

I like the first one the most.

What is the output supposed to be from ]acre.stats?

]openproject c:\github\acre-desktop
Opening from c:/github/acre-desktop/
into #.acre
397 items loaded from c:/github/acre-desktop/.acre/codefile
#.acre
]stats
Project not open

The result is from Acre-Desktop 4.0.4

I think we are going to need some info on the local change history reported in ]stats.

Perhaps something like:

Change History: 35mb in 250 files.

This might even be useful as an additional column in the result of ]projects, or spilling into the session when you open the project.

What is, or should be, the minimum requirement for Acre Desktop to recognize a folder to be a project folder? I would like creating a project from scratch in the opsys to be as simple as possible.

It could be any folder whatsoever, and Acre Desktop just does its thing. If there is no APLSource sub-folder, it assumes there is simply no code to fix. The config file parameters all default, and Acre creates the .acre internals.

But it might be better to have at least one requirement, the existence of the APLSource folder, even if empty, for example. This is still trivial to create by hand.

The good news is that I was able to install acre 4 on a Mac and create a project from the Dfns WS.

However, when I issue )CLEAR I get

Cannot perform operation with connection to external object in session namespace

I have asked Dyalog for advice how to find out; ⎕DMX does not give any useful information on this.

I closed the APL session, restarted a new one and was able to open the project as well.

When I issue ]acre.projects in a CLEAR WS straight away after having fired up Dyalog I already get this error message.

It seems that everything works fine except )CLEAR

This acreconfig.txt has no effect:

:Namespace
    ...
    StartUp←'#.WORKS←1'
:EndNamespace

It neither creates the variable nor throws an error.

As I write the documentation for the commands, I wonder why we need the formal concept of a project name. Obviously people will name their projects, and usually will name their folders and namespaces for them. But currently we do not allow two projects with the same name to be open at the same time. I think we are going to regret this, and I don't see what it accomplishes, other than complicating the documentation.

There are only two commands that currently require the project name : ]consolidate and ]Stats. No doubt there will be more in the future. But why won't the projectspace work as a replacement? By definition, it will be unique. So there is no issue of opening /CarlisleGroup/Utilities and /APLTeam/Utilities. at the same time. Furthermore, the projectspace actually exists so autocomplete will work in the session, and I think user commands know your current namespace, so you can use a short name if you are already in the right spot. Thus if I am in #.CarliseGroup I can do:

]Stats Utilities

or from anywhere I can do the more verbose:

]Stats #.CarlisleGroup.Utilities

I propose we get rid of the concept of project name.

It is possible to check whether the result of a user command is assigned to a variable (##.RIU is then 1 rather than 0). If that's the case then acre 4 should not write anything to the session but return it as a result.

That would make test cases more efficient and prevent them cluttering the session.

What exactly is the role of the wiki? Fully-fledged documentation or rather a kind of overview for the most important features?

That affects whether the run function should go into the wiki at all. Same for the messages stuff I've added today. For an overview this is too detailed I guess.

When a project comprehends a namespace script then CreateProject creates a file for every single fns/opr within that namespace script plus a file for the script as such.

In this case it must not write the fns/opr specific text files.

The same when a namespace scripts gets changed.

It appears that Windows does not like to compress folders that contain file names with APL chars like ∆ (delta). It is pretty common to use delta and delta-underbar, and I don't think it will do that we won't be able to compress a project with at least those two chars, and perhaps others. Can we encode them? What is the list of chars that are valid in an APL name, but invalid in a compressed folder?

The .acre folder all that it implies is fundamentally incompatible with Git. More specifically, .acre folder and branching in Git are incompatible. It would work ok if you never branched in Git, but I don't think it is worth the distinction.

The .Acre folder does two things: performance, and local change files. Both need to be sacrificed if Git is in play. The performance sacrifice is I think minimal. The local changes are nice, but local Git commits are somewhat analogous. Regardless, I think any attempt to combine the functionality is going to be very complicated, error prone, and not worth it.

Thus we need the following enhancement:

If an Acre project has a .git folder inside it, it is considered to be an acre [Git] repository . In this case, when Acre opens the projects, the .acre folder, if it exists, is deleted. The project is fixed from the APLSource folder. No change or delete files are written. On any change in the session, acre just writes out to the APLSource folder. Nothing else. Any call to ]undo ]redo or ]restore or ]purgehistory results in a "Not applicable to Git repository" message.

This is one a project by project basis. Thus is is entirely reasonable to have some projects open that are git repositories and some that are not, all at the same time.

New projects should be created with .gitignore file, for safety, This is because if you create a project, and then "convert" it to git, you don't want the .acre folder getting into Git, even though you will be deleting it the next time you open the project.

I am unhappy with the name of the consolidate command, and its short description. Neither seem to indicate exactly what the command does from the users point of view. It is sort of an internal clean up thingy in a way. From the users perspective it does one thing only I think: it deletes local change history. Is there a better name and description? Can the concept be eliminated or automated behind the scenes?

Since by definition, Acre Desktop is local, perhaps a more apt name is PurgeChangeHistory, and description would be "Permanently delete local change history"?

I specified

]Openproject "C:\...\Dfns" #.Dfns [message←'#.Global']

but when I tried to restore the default with

]Openproject "C:\...\Dfns" #.Dfns [message←'on']

it keeps writing to the global vars.

Can open a project with only APLsource or only acreconfig.txt. But if only the former or the latter has missing or null ProjectSpace then must supply target as second item in arg.
]OpenProject path target

]acre.openproject C:\T\Acre-4\Carlisle\AcreDesktop_Testcases
Acre 4.0.3 2018-01-16
Opening from C:/T/Acre-4/Carlisle/AcreDesktop_Testcases/
into #.AcreDesktop_Testcases
Creating Source folder
FILE NAME ERROR: Invalid directory name ("The system cannot find the file specified.")
folderObj[2] p t s d←0 1 2 3 ⎕NINFO⍠1⊢dir,'*'
∧
dir
C:/T/Acre-4/Carlisle/AcreDesktop_Testcases/.acre/changes/

That does not exist indeed.

I seem to recall this issue being raised by Kai some time ago, but SALT user command directory is a colon separated list on macOS.

I might be doing something wrong here, but I have created ProjectA and ProjectB and put htem as siblings in a folder:
E:\projects\ProjectA
E:\projects\ProjectB

In ProjectB I configure it to load ProjectA:

:Namespace
    CaseCode←'On'
    Load←'../ProjectA'
    Open←''
    ProjectSpace←'#.ProjectB'
    StartUp←''
:EndNamespace

I start Dyalog and then:
]acre.openproject E:\projects\ProjectB

It loads ProjectB, but not ProjectA. What am I missing?

Also, in the Wiki it says I can provide a pair of folder and space names for Open or Load. In the case I want to load ProjectA as space PA, what is the correct form (do you need to nest it appropriately I mean)?

{
      "ProjectName": "MyProject"
      "ProjectSpace": "#.MyProject"
      "Open": ["ProjectA", "PA"] or  "Open": [["ProjectA", "PA"]]
      "Load": ""
      "StartUp": ""
}

When creating a new Acre-Desktop project, we need to create the text file named .gitignore, contiining the 6 character string:

        .acre/

and place it in the root of the project folder.

I think we need:

]Acre.History item

that lists the source of the local versions going back in time:

Version9
Version8
Version7
etc.

CreateProject appears to work when only a project folder is specified. What exactly is the default value for the project space? It does not appear to be #.

I think we should require two arguments.

The notes in the DFNS workspace are written out as .array. They are stored in the ws as simple strings with linefeeds (UCS 10's).

Since they are not stored as vectors of character vectors, I realize they cannot be written to .charlist.

Obviously these are candidates to be nice and readable in a text file, but they currently are not.

Should we have a .text extension or some similar name? Or Should we just encourage vectors of vectors?

I just tried running this command and it seems to be missing.

acreconfig.txt should have an (optional?) MinVersion parameter that will give a warning when LoadProject or OpenProject in earlier versions of APL. This should be down to the build id.

Kai has requested a way to open projects by a short name rather than having to enter the full path. This is stuff we had in past, when the location of projects on disk was controlled by Acre.

How would this work, be implemented, in Acre Desktop?

I suppose we would need a new acre command to associate a short name with a long path?

Should this just be left up to the user to configure his own session with short cuts and PFKeys, etc?