prb28 / vscode-amiga-assembly

Amiga Assembly extension for Visual Studio Code
GNU General Public License v3.0
179 stars 12 forks source link

IntelliSense for commodore libraries #63

Closed mithrendal closed 5 years ago

mithrendal commented 5 years ago

Hi prb28,

I can't really express in words how great this visual studio code extension already is. I really want to express my heartful thanks and admiration for your work.

Now I will come to the thing which might be a cool enhancement. I have a .i file with all the offsets


* Important Exec Library Offsets
AbortIO            equ -480
AddHead            equ -240
AddIntServer       equ -168
AddTail            equ -246
Alert              equ -108
AllocMem           equ -198
...

and this file I do include in my .s files. I had to install the extension "All Autocomplete" to get the constants of the .i file recognized when I edit the .s file. This leads my to a further question:

How can I extend IntelliSense in VSCode on library calls. When the mouse is over a lets say

jsr AllocMem(a6)

I would like to see a hint like this

NAME
    AllocMem -- allocate memory given certain requirements

SYNOPSIS
    memoryBlock = AllocMem(byteSize, attributes)
    D0                     D0        D1
...

Is that maybe easy possible to add to Amiga-Assembly ?

with best regards

mithrendal commented 5 years ago

Point4: accompli πŸ€“

execV9.zip

prb28 commented 5 years ago

Wunderbar! amiga-assembly-0.17.0.vsix.zip I think it's great like that!

mithrendal commented 5 years ago

references to other libs should work now correctly. I did the dos lib for testing.

exec/AddTask()-> amiga.lib/CreateTask()->dos.library/CreateProc() is translated to exec/AddTask.md->_OQTA.md->../dos/CreateProc

dosV9.zip graphicsV9.zip

prb28 commented 5 years ago

Once again the links in the popup (hover) acts weird, it does not seems to accept the '.'. In exec/AddTask: That's ok: amigalib/CreateTask This one does not work: amiga.lib/NewList (The two work when the documentation is opened in the markdown preview) amiga-assembly-0.17.0.vsix.zip

mithrendal commented 5 years ago

Hmm, VisualStudioCode does not let me test the link.

At exec/AddTask.md: NewList link in the middle of the text works but when I want to move the mouse icon over the amiga.lib/NewList link at the bottom of the popup (which you mentioned is defective) then it popup closes automatically. Do you see this too ? Maybe we should add multiple newlines at the end of the *.md files ? Clearly VisualStudio Code thinks we want to navigate out of the popup and therefore closes it, ... but a little bit too eagerly πŸ™„.

EDIT: wait now it works!!! Strange. Now it lets me click the link.πŸ˜€ But it does not work as you said.

The amiga.lib/NewList link is the last thing in the md file. Can you add a newline after the amiga.lib/NewList link and test if it works ? If so we just append an extra newline to each md file.

mithrendal commented 5 years ago

Tu as deja cette fichier ? I do work with it ... πŸ€— liboffsets.i.zip

prb28 commented 5 years ago

The amiga.lib/NewList link is the last thing in the md file. Can you add a newline after the amiga.lib/NewList link and test if it works ? If so we just append an extra newline to each md file. I've edited the amigalib/CreateTask, before it was amiga.lib/CreateTask, that's why it works. There is no problem with the fact that it's the last line, there is already an extra line at the end of the file. Replacing amiga.lib/NewList by amiga_lib/NewList works too.

If you want to try it easily, I think you can change the plugin directory contents in you vscode installation. (I've never tried)

Thanks for the liboffsets.i it's pretty straightforward, actually I use a bunch of standard '.i' files from commodore with macros. I try to stick with something that other people will get from internet. I'm transforming my example workspace to have the name of functions to demonstrate the feature.

mithrendal commented 5 years ago

Now I understand. πŸ™ƒ V10 replaces the . char from the text of the link with _

execV10.zip

prb28 commented 5 years ago

Great, the '.' replace by '_' works! But, I'm sorry! I did you work for nothing, it was my fault, I did a bad parsing on the links with '.'. It works now with the two syntaxes.

I've a question in exec/AddTask there is the link: [dos/CreateProc](_ORXE), shouldn't it be [dos/CreateProc](../dos/CreateProc)?

I own you a beer for the shitty parser :-)

mithrendal commented 5 years ago

d'accord moi je removed the replacement of the . and went back to v9 πŸ˜„. Ici je te donner deux biere 🍺🍺 pour ton traveaux fantastic.

Why is dos/CreatePro outputted as [dos/CreateProc](_ORXE) and not [dos/CreateProc](../dos/CreateProc)?

The short answer is: The text is not assumed as a call to a different lib, because it has not the syntax dos.library/CreateProc().

The detailed answer is: The python generator analyses the link and has currently three possible decisions

  1. it is a link to the current lib -> create a link to the name
  2. it is a link to an function entry in a different lib ->create a relative link ../name_of_the_lib/link_text_without_brackets
  3. it is neither 1 nor 2 and must be a 2nd level document -> open/follow the link, make an .md file with the technical id

here is the corresponding code fragment of the python program πŸ‘ˆπŸ˜„

    #if the link points to an lib entry then use its name as url
    if(mapLibentriesURLsToName.has_key(lurl_orig)):
        lurl=mapLibentriesURLsToName[lurl_orig]
    #if it is a link to an external lib
    elif re.match(".*?[.]library/.*", lname_without_brackets):
        lurl= re.sub("(.*?)[.]library/(.*)",r"../\1/\2",lname_without_brackets)
    #otherwise use the technical document id
    else:
        lurl=encodelink(lurl_orig)

When we want to get rid of the somewhat redundant created md files (_ORXE.md), then we have as a first action in the python program to read all libentries of all different libs that we plan to generate. Then the python program can optimise its decision taking, because it has not to guess if dos/CreateProc() is really an existing entry in ../dos/CreateProc by syntax. It will know it because it collected all URLs the lib entry points beforehand and therefore can then make the decision by looking up the URL instead of guessing about the link text syntax (which varies between dos/CreateProc() and dos.library/CreateProc() in the original document source and here with a different syntax ).

Currently the python program only processes one library at the time. But it should not be too much work to read all libentries of the "participating" libraries into a dictionary at startup. Also to tweak the decision code is quite easy. Do you think we should do it ? It would reduce the amount of created md files a bit. It is also a bit cleaner/precise that way. But in effect for the user of Amiga Assembly maybe not much difference.

prb28 commented 5 years ago

Ok I understand and agree It can be tricky for only some extra files. So we can keep it like that. One last question, are some files missing? _OSOV.md, _ORDT.md, _ORXD.md
If it's a problem of the conversion 1234.md->OABC.md, you can remove this conversion too, this was needed because of my parsing bug.

amiga-assembly-0.17.0.vsix.zip with V9 docs

mithrendal commented 5 years ago

I have thought about it and came to the conclusion that the current way of only doing one lib at a time without knowing the technical link ids of the others leads to a problem: Missing files on the 3rd doc level -> _OSOV.md 😱

You yourself also discovered the same problem _OSOV is missing !!!Who the f*** is OSOV ? πŸ˜‰

Why are there missing files ? Because we don't follow the links to the 3rd level. The files you mentioned are all 3rd level docs.

But instead of generating copies of the 3rd level docs (which would solve the problem for 3rd level only (maybe there are 4th level still ??)), we better do the concept of optimized decision making which I described in the post above. With the relative links we do not need these docs at all, which are basically copies of already existing doc files.

Who is OSOV ? _OSOV.md is equal with /dos/UnLoadSeg.md

En effet I am just reworking the python program. 😌

mithrendal commented 5 years ago

+new optimised link decision +numbers instead of alphas in 2nd level docs

execV11.zip

The 2nd level doc file _028E.md is the file which in V9 linked to _OSOV now in V11 with optimized link decision it should link correctly to ../dos/UnLoadSeg

Also your other problem I've a question in exec/AddTask there is the link: [dos/CreateProc](_ORXE), shouldn't it be [dos/CreateProc](../dos/CreateProc)? should be solved by this.

Hope I did not break to much 😬.

prb28 commented 5 years ago

That's great! Everything seems to ok. Now it's my time to work ;-). I'm thinking to add some code completion and maybe a summary to view the doc contents. Do you see other things to add ? amiga-assembly-0.17.0.vsix.zip

mithrendal commented 5 years ago

I think it is really great !!! I really do love that exension !!!

hover your mouse over an jsr OldOpenLibrary(a6) popup comes visible then click on Libary it takes you to _009C.md.

In _009C.md I still see some html entities for example" and < which are not rendered by Visual Studio Code.

&#034 is a " and &#060; is a <

I bet it does not render because it is in the code block right ? Should I replace html entities to it corresponing ascii when inside the codeblocks for you ? Or can you teach VisualStudioCode to render it even if it is in code bloc ?

prb28 commented 5 years ago

Yes it's because of the code block. To do it in my side, I'll have to implement a custom markdown renderer, and it may be tricky. If you can, the best is to clean it up in the code blocks. Apparently in the markdown (outside the codeblocs) they are replaced.

mithrendal commented 5 years ago

Yes it was a better decision to do it on my side. Now I think we can let the other libs have their prime time πŸ˜„ what do you think ? I have generated now the most important libs. Then maybe later if everything is ok we can also do the other less important ones.

V12_diskfont.zip V12_dos.zip V12_exec.zip V12_graphics.zip V12_intuition.zip

prb28 commented 5 years ago

Thanks! Here is the new version, with some completion (work in progress...). amiga-assembly-0.17.0.vsix.zip

mithrendal commented 5 years ago

Looks good πŸ‘Œ

prb28 commented 5 years ago

I've just watch the interview of Mike Battilana. As I understand the commodore documentation is still copyrighted (as the logo, name, etc.), I will send him a email, to get his agreement on this use.

mithrendal commented 5 years ago

Ah cool. 😎Did you sent the question on his website contact formular? I think it is this https://www.amigaforever.com/contact/

Maybe he is even on EAB? Elowar , the one who hosts the source from which we got the docs is at EAB. His name there is also EAB Elowar. Email is omega@elowar.com. But I think it is not Mike Battilana ???

prb28 commented 5 years ago

I sent it to mike at amiga dot com seems to be his direct address.

mithrendal commented 5 years ago

Cool. 😏 mike at commodore dot com is maybe also working ... πŸ˜‚

mithrendal commented 5 years ago

Hi @prb28 something completely offtopic:

do you you know the vAmiga project? Maybe interesting and funny for you to look at ? ;-) https://github.com/dirkwhoffmann/vAmiga/issues/9

prb28 commented 5 years ago

Thanks, yes it's really interesting! (I'll keep a eye on it!) Daniel Collin is working on a new emulator too: https://github.com/theblacklotus/magia.

C64HexCoder commented 2 years ago

How do i install the library extension in Amiga Assembler visual studio?

prb28 commented 2 years ago

@C64HexCoder You'll get this feature with the extension. Although all the libraries are not documented.