Closed mithrendal closed 5 years ago
Point4: accompli π€
Wunderbar! amiga-assembly-0.17.0.vsix.zip I think it's great like that!
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
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
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.
Tu as deja cette fichier ? I do work with it ... π€ liboffsets.i.zip
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.
Now I understand. π V10 replaces the . char from the text of the link with _
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 :-)
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
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.
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.
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. π
+new optimised link decision +numbers instead of alphas in 2nd level docs
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 π¬.
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
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.
"
is a " and <
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 ?
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.
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
Thanks! Here is the new version, with some completion (work in progress...). amiga-assembly-0.17.0.vsix.zip
Looks good π
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.
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 ???
I sent it to mike at amiga dot com seems to be his direct address.
Cool. π mike at commodore dot com is maybe also working ... π
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
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.
How do i install the library extension in Amiga Assembler visual studio?
@C64HexCoder You'll get this feature with the extension. Although all the libraries are not documented.
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
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
Is that maybe easy possible to add to Amiga-Assembly ?
with best regards