« first day (1724 days earlier)      last day (1456 days later) » 

Duga
Duga
00:01
RELOAD!
[rubberduck-vba/Rubberduck] 2 issue comments.
[SimonForsberg/minesweeper-api] 1 commit.
[SimonForsberg/minesweeper-server] 33 commits.
[SimonForsberg/minesweeperflagsgdx] 5 commits.
[Zomis/minesweeper-flags-client] 5 commits.
 
1 hour later…
this
this
01:16
@ScottDennison This is belated and others already replied but just to share an idea - I would look at the compiler directives as essentially generating two separate file. Therefore a module that contains a single #If ... #Else ... #End If should have 2 resulting parse trees. Currently, Rubberduck isn't set up to handle multiple parse trees but if we were going to solve that, that is how it would be done, I think.
@Comintern Also belated but - I'm more inclined to keep the derived types in the same file with the generic definition of the converter. That way, it's obvious.
In fact I might put it at the top so that I have to read down to the implementation and that aids the readability, I think.
Duga
Duga
[rubberduck-vba/Rubberduck] bclothier synchronized pull request #4820: Implement ThunderCode inspections
Duga
Duga
01:42
[rubberduck-vba/Rubberduck] build for commit c22ae5ea on unknown branch: AppVeyor build succeeded
[rubberduck-vba/Rubberduck] bclothier opened issue #4821: Designer code generation & csproj layout
> I noticed that the resource files weren't updating the designer. I furthermore noticed this:
![image](https://user-images.githubusercontent.com/2367644/53293827-24e8a700-37a1-11e9-8e0b-dc10ddccec3b.png)

Changed the dropdown to `Public`, and the designer got updated. Furthermore, the `csproj` file got altered as shown:

https://github.com/rubberduck-vba/Rubberduck/blob/c22ae5eafb0c9ecde111e53146e76acc24b5fe57/Rubberduck.Resources/Rubberduck.Resources.csproj#L24-L45

Though in theory, gl
[rubberduck-vba/Rubberduck] bclothier added label discussion to issue #4821: Designer code generation & csproj layout
[rubberduck-vba/Rubberduck] bclothier added label development-issue to issue #4821: Designer code generation & csproj layout
 
5 hours later…
Vogel612
Vogel612
06:53
@Duga ~sigh oh, visual studio, why isn't it ever simple with you?
 
6 hours later…
Scott Dennison
Scott Dennison
13:07
@this That makes sense. However, it also complicates my plans at little :(
As part of a current piece of work I'm assigned at work, I'm needing to automatically modify VB6 code by injecting new code based on certain patterns (E.G: Add a method call below the start of every method entry), which I was doing via a series of visitors over the parse tree. Once the modifications are complete, I call getText() on the top level rule to get a string containing the complete source file with all modifications.
Having just done a scan through all currently used VB6 code in my company's repositories, I can see no #if precompiler directives in the code as it currently stands.
I'm tempted to do a precompiler grammar pass, and upon detecting any #if precompiler directives, reject the file.
M.Doerner
M.Doerner
13:26
If your injections would differ based on different constants being set, that would pose a problem for recombination, indeed.
However, if you just hide the non-active code from the parser by moving the tokens to another channel, you can still get the entire code from the ITokenStream. (The top level rule only gets what the parser saw, AFAIR.)
 
2 hours later…
Duga
Duga
15:12
[rubberduck-vba/Rubberduck] ScottDennison created comment on pull request #4815: Reduce target language dependence of grammar
> I had a little of look and I couldn't see what the procedure was for completely replacinng a grammar, as opposed to just making small changes of it.
I know if I was using the old grammar, I would be annoyed if it got replaced with the new out of warning.
Any ideas?

Also, which grammars would be pushed. Just the core grammar or the precompiler grammar as well?

It might be better for someone more knowledgeable than me to do that pull request.
[rubberduck-vba/Rubberduck] ScottDennison edited comment on pull request #4815: Reduce target language dependence of grammar
> @Vogel612 I had a little of look and I couldn't see what the procedure was for completely replacinng a grammar, as opposed to just making small changes of it.
I know if I was using the old grammar, I would be annoyed if it got replaced with the new out of warning.
Any ideas?

Also, which grammars would be pushed. Just the core grammar or the precompiler grammar as well?

It might be better for someone more knowledgeable than me to do that pull request.
Scott Dennison
Scott Dennison
15:36
@M.Doerner If the function name would differ between branches like in the earlier example, then it would screw it up. Probably just easier to leave it as a known future expansion and reject such files.
 
2 hours later…
Hosch250
Hosch250
17:25
user image
Which one do I use??
Dair
Dair
All of them.
which one has more stars on github?
BCrypt-Official has the most downloads... I would go with that unless I have a particular reason to use another one.
this
this
so, this code is legal and compiles (but won't parse): 
Public Sub Test()
    GoTo -1

    Debug.Print "don't print me, bro!"

-1:

    Debug.Print "done"
End Sub
Dair
Dair
@this Sounds like a feature to me.
Hosch250
Hosch250
@Dair BCrypt-Official is a port of Damien Miller's implementation.
But BCrypt.Net-Next.StrongName has Damien's name on it, says it's an updated version, and has a lot of downloads too.
this
this
The relevant grammar are: numberLiteral : HEXLITERAL | OCTLITERAL | FLOATLITERAL | INTEGERLITERAL; and INTEGERLITERAL : DECIMALLITERAL INTEGERTYPESUFFIX?;, fragment DECIMALLITERAL : DIGIT+;, and fragment DIGIT : [0-9];
Note that none of those allows for a - sign. Is there a particular why it won't recognize a negative sign as part of number? I assume to handle the unary operator.
Dair
Dair
17:33
@Hosch250 I would go with the updated version.
this
this
@Dair except, that isn't very "What you type is what you get"
I suppose to avoid screwing up the grammar around the actual numeric literals in the code, the line numbers could be given a couldBeNegativeNumberLiteral rule. #FunTimes
Dair
Dair
@this I'm kidding haha, although it seems like a somewhat questionable way to code...
this
this
I sincerely hope there is no production version of VB* code out there that uses this.... "feature".
thinking about it, it might be more useful for malicious intentions.
Dair
Dair
is it really a bug if nobody produces it? hmmmmmm
this
this
well, ThunderFrame produced it, so it's a bug now.
Dair
Dair
17:39
Maybe ThunderFrame is the real bug.
:P
(Of course, I'm just kidding in case it wasn't obvious)
Duga
Duga
18:34
[rubberduck-vba/Battleship] vbamagician forked us into vbamagician/Battleship
Duga
Duga
19:07
[rubberduck-vba/Rubberduck] D3vlin forked us into D3vlin/Rubberduck
2
 
2 hours later…
Duga
Duga
21:06
[rubberduck-vba/Rubberduck] bclothier synchronized pull request #4820: Implement ThunderCode inspections
[rubberduck-vba/Rubberduck] bclothier created comment on pull request #4820: Implement ThunderCode inspections
> Please note that the grammar has been updated to handle the bogus "negative" line number to allow it to be inspected and warned. With that, we now have a total of 5 ThunderCode™ inspections.
Duga
Duga
21:25
[rubberduck-vba/Rubberduck] build for commit d32e89d5 on unknown branch: AppVeyor build succeeded
Duga
Duga
21:45
[rubberduck-vba/Rubberduck] bclothier commented on Rubberduck.Resources/Inspections/InspectionInfo.resx of pull request #4820: Implement ThunderCode inspections
 
1 hour later…
IvenBach
IvenBach
23:00
@Comintern can have the icon say TO DO on two lines in the sticker if it fits.
Comintern
Comintern
23:40
@Duga @this Do we care that line numbers and labels are not semantically equivalent?
> Executing a <statement-label-definition> has no observable effect.
...or does it....
When you step through with the debugger, it treats -1: as a numbered line with an empty statement. Compiler is doing something messed up there.
And, my new favorite line in the spec:
> The name value of the <IDENTIFIER> in <identifier-statement-label> may not be "Randomize".
this
this
@Comintern My assumption was that it is used internally unsigned
Comintern
Comintern
That was my assumption too.
this
this
Therefore what we "see" as -1 is in fact int32.MaxValue
oops, uint32
Comintern
Comintern
> If <statement-label> is an <INTEGER>, it data value must be in the inclusive range 0 to
2,147,483,647.
Uhuh.
this
this
someone didn't check this when writing the specs, apparently
@Comintern do you have an example where it matters?
Comintern
Comintern
23:53
I'm not sure. I mainly thought it was odd how the compiler handled it.
I'd say Erl, but that's borked anyway.
this
this
TBH I struggle to conceive how you would create a label using digitts
Normally one would quote it but I doubt it works like that
Comintern
Comintern
Interesting. It overflows Erl: 
Public Sub Test()
    On Error Resume Next
-1:
    Debug.Print 1 / 0
    Debug.Print Erl
End Sub
Outputs 65535
this
this
there's also other part in the MS-VBAL that's wrong about the range for the error number...
Comintern
Comintern
Or rather it doesn't overflow. 
Public Sub Test()
    On Error Resume Next
12345678
    Debug.Print 1 / 0
    Debug.Print Erl
End Sub
This is also wrong:
> The label value of a <line-number-label> is the data value of its constituent <INTEGER>
element.

« first day (1724 days earlier)      last day (1456 days later) »