The open source programming language Perseus - Wanna join the project?

[karraksc]

Most of what I was suggesting, you have already got figured. I have used NppExec on a couple other projects.

[minxomat]

I've secured some short-term gigs and won't be in the country for the next week or so. My apologies, but it will take a little longer. Job goes first

[minxomat]

@rjframe You did that on purpose, didn't you?

[rjframe]

@rjframe You did that on purpose, didn't you?

I just wanted to be sure you were paying attention...

[Surya]

I Am too with you TheDcoder 

[TheDcoder]

@Surya Do you want to join the Doc team ? If yes, ask @minxomat, he is our leader

[minxomat]

I Am too with you TheDcoder 

I have no idea what this is supposed to mean. 

[TheDcoder]

@minxomat neither me

[guinness]

You can ignore this if you want, but over time your code base will become quite difficult to maintain if you're using a lot of global variables. My advice would be to prefix with $g_, so you can tell what is global and not. It also helps those who jump on board and submit PR, which I guess is what you want? There is also git related remarks left over in DLLImports e.g. <<<<<< HEAD as well as unresolved sections. I was in the process of creating a PR, but realised it's better if @minxomat resolves the conflict(s).

I know you're porting over the code, but don't write AutoIt code like you're writing VB.NET, as AutoIt != VB.NET.

Edit: The reason I wrote this post now, is because code with multiple team members shouldn't look like it's written by multiple team members and from what I can see, this is where it's headed. You have variables which are a mixture of pascal-case or AutoIt-like Hungarian notation, functions that are pascal case and camel-case and not very many comments. Therefore it's best at this early stage of the game to have a style guide and plan what is the best way of structuring this project. How should internal functions be named? What is the correct approach for commenting? What's the threshold for the number of lines a function can contain? 

Edited August 24, 2015 by guinness

[minxomat]

Porting is about creating a exact copy. Then there is cleanup. I'm already writing shorter methods, but the basics need to be sorted out first. If you fix something along porting, or rewrite it, there will be errors when the port is complete that are impossible to debug, because differences between the languages are buried deep down in abstraction. It may seem messy now, but it is a very secure system. But as I said, once the port is complete and verified, there will be a huge cleanup.

but don't write AutoIt code like you're writing VB.NET

Yes. You can only spot misunderstandings in comparison.

But I already posted this here: https://www.autoitscript.com/forum/topic/174143-so-you-want-to-port-code-from-one-language-to-another-huh/ 

There is also git related remarks left over in DLLImports e.g. <<<<<< HEAD as well as unresolved sections. 

I don't have time to look over the code right now, but I will do and of course fix the issues. If you found something that is fixed easily (like this), create an issue report on the port tracker and I'll look over it.   

Edited August 24, 2015 by minxomat

[guinness]

I dunno if you saw my edit above. It explains a little further as to why I posted. I am not going to submit a PR, for reasons I explained above.

[rjframe]

Porting is about creating a exact copy. Then there is cleanup. I'm already writing shorter methods, but the basics need to be sorted out first. If you fix something along porting, or rewrite it, there will be errors when the port is complete that are impossible to debug, because differences between the languages are buried deep down in abstraction. It may seem messy now, but it is a very secure system. But as I said, once the port is complete and verified, there will be a huge cleanup.

@minxomat: This is correct; but @guinness is right that we should be developing coding standards, and it makes more sense to begin the discussion now than wait; if we wait until the port is complete, we'll have to make a full stop in development while we fight to the pain about where to put our periods. My current assumption has been that our guidelines will be similar to the AutoIT UDF guidelines.

We can also be documenting the language specification as well as future goals (I've seen you post a couple of times "we're going to do that", but that information needs to be in more than just one person's head). There seem to be certain reserved keywords (e.g., "class") that are never used in the examples. It would be nice (in my opinion) if we can use an intentional and methodical process in designing the standard library, rather than throwing things together as they are deemed necessary (or at least, let's throw things together but declare the API unstable until we like it).

At minimum, can we agree to use tabs? Scite in wine keeps switching between tabs and spaces (it seems most of the time to be a tab, then spaces), so I'm going back to vim. But some of my files have whitespace issues because I'm a terrible person and didn't fix it prior to pushing my code.

 

You can ignore this if you want, but over time your code base will become quite difficult to maintain if you're using a lot of global variables. My advice would be to prefix with $g_, so you can tell what is global and not. It also helps those who jump on board and submit PR, which I guess is what you want? There is also git related remarks left over in DLLImports e.g. <<<<<< HEAD as well as unresolved sections.

1) Agreed about marking globals.

2) The merge issue is my fault; I thought I got everything, but obviously not.

[minxomat]

My current assumption has been that our guidelines will be similar to the AutoIT UDF guidelines.

Yes, they are - or will. 

but that information needs to be in more than just one person's head)

That is why I've mentioned that I'm away right now (before @guinness posted). I typed up some guidelines already, but I don't have the time to finish them right now. Best would be to not merge into master before I'm ready  .

 At minimum, can we agree to use tabs? Scite in wine keeps switching between tabs and spaces (it seems most of the time to be a tab, then spaces), so I'm going back to vim.

Yes, tabs. You can manually invoke Tidy before pushing, though. It will clean up whitespace issues  .

Additionally to UDF guidelines, I think it would be best to follow some Google-like CC:

• Mark todo points as ; TODO(username): Add this ...
• If there is a code-block longer than 3 lines, put an empty line above and under it:

• Func foo()
      Local $n
      
      If 1 = 3 Then
          bar()
          bar()
          bar()
      Else
          foo()
          foo()
          foo()
      EndIf
      
      If 4 = False Then some()
      Return 5
  EndFunc

   

And what @rjframe already does: Leave the original code above the ported method.

I have to disagree with marking globals for now. There must not be any new variables in the port. The namespace is clean in the VB code. We (or I) will restructure the code away from globals after that.

[rjframe]

 

• Mark todo points as ; TODO(username): Add this ...
• If there is a code-block longer than 3 lines, put an empty line above and under it:

I like those ideas.

 

• Func foo()
      Local $n
      
      If 1 = 3 Then
          bar()
          bar()
          bar()
      Else
          foo()
          foo()
          foo()
      EndIf
      
      If 4 = False Then some()
      Return 5
  EndFunc

Stack overflow. 

[minxomat]

I was reviewing some code an github on my flight and noticed something in your code @rjframe. On numerous occasions you replaced a loop exit with a hard return. This causes illegal code paths. For Example, in your port of the DLLImports module, take a look at the original code block in line 55 following. This particular code is used for scanning through the import table and identifying dead imports. If the scan is finished, the code should skip to the end of the parent for loop, not exit the function. Use ExitLoop instead of Return. There is code after this loop that uses the import table.

I'll review the code in detail when I'm back home.

[minxomat]

@rjframe You also made the typical porting mistake when it comes to VBNET. The return value variable can be manipulated but is returned at the end of the function:

Function foobar()
    foobar = 1
    Dim k as Long
    
    For k = 1 to 5
        If k = 6 Then Return 6
        foobar += 1
    Next k
End Function

Still returns on every code path (in this case it always returns 6). In AutoIt this is very confusing, but in VBNET there are Subs and Functions. Functions always return, no matter wether or not they actually have a return statement.

Feel free to fix this in your fork, but I see that I have to hurry with the guidelines .

[minxomat]

@rjframe and I had a discussion about a better way of reviewing additions to the port. We agreed upon managing the code/peer review entirely through pull-reqs. Because the code is designed to run as one file, (for the time being), additions must be made to this file. After everything is done, we will proceed to cleanup. Sounds complicated? It really isn't  . 

The next post will be a complete visual guide for making contributing to the port. If you are not directly contributing, please contribute by reviewing (aka. approving) pull reqs from other users (Step 7).

Edit: Please keep your forks single branched.

Edited September 12, 2015 by minxomat

[minxomat]

[minxomat]

Ported about 1,5k, please review: https://github.com/Perseus-Dev/Perseus-Portbase/pull/9/files

[minxomat]

License Change

All parts of the Perseus Code (including ports and examples) are now licensed under the conditions of the Artistic License 2.0. In short, this means that

It is required to

• Include a license and copyright notice, and
• state all changes you made should you choose to republish (parts) of the project.

It is permitted to 

• Use the project commercially,
• distribute it anywhere,
• make any kind of modification (except to the license),
• use it privately, and
• sublicense.

It is forbidden to 

• Hold any of the developers liable for anything, and
• use trademarks elsewhere or for derivative works.

You can view the license in full text at https://github.com/Perseus-Dev/Perseus-6/blob/master/LICENSE.TXT.