« first day (2789 days earlier)      last day (391 days later) » 

12:00 AM
REFRESH!
[Minesweeper] 81 Games Played. 45 Bombs Used. 11083 Moves Performed. 10 New Users
 
 
2 hours later…
1:54 AM
 
 
1 hour later…
3:16 AM
[rubberduck-vba/Rubberduck] build for commit 0836aee2 on next: AppVeyor build cancelled
BUILD FAILURE!
 
build pipeline restored, and actually authorized from the org account now.. not sure what it was before
 
3:43 AM
[rubberduck-vba/Rubberduck] build for commit 0836aee2 on next: AppVeyor build failed
BUILD FAILURE!
 
4:04 AM
Merge pull request #5938 from rubberduck-vba/releasebot-patch-appveyor-token

Update appveyor.yml
[rubberduck-vba/Rubberduck] build for commit de86e8d9 on next: 97.58% (target 0.00%)
 
4:27 AM
[rubberduck-vba/Rubberduck] build for commit 723fe314 on next: AppVeyor build succeeded
[rubberduck-vba/Rubberduck] build for commit 723fe314 on next: 97.58% (target 0.00%)
Acknowledge that module constants can have attributes

This required adding the corresponding contexts in the context listener and actually attaching them to the ValuedDeclaration.

Since only module constants can have attributes, a further level has been added in the grammar to reflect the distinction.
Merge pull request #5934 from MDoerner/FixVarDescOnConstant

Acknowledge that module constants can have attributes
 
4:53 AM
[rubberduck-vba/Rubberduck] build for commit 70e54795 on next: AppVeyor build failed
BUILD FAILURE!
[rubberduck-vba/Rubberduck] web-flow pushed commit e701c160 to next: Update MissingAttributeInspectionTests.cs
 
6:19 AM
awesome, feature description markdown preview works.. bed time!
 
 
6 hours later…
12:13 PM
@Duga you're not starting to have senile moments, are you?
 
12:24 PM
@FreeMan probably because it was closed without comment, but still generated a comment webhook delivery
or something along those lines
 
Whew! I was startin' to worry about the ol' gal. ;)
 
not the first time she did that
 
1:26 PM
@Vogel612 I know! That's why I was starting to worry. ;)
 
1:37 PM
> Nothing big, but I think this sounds better...
 
good fucking lord, Django why must you be such a nuisance?
> collect static files using collectstatic. But if you use runserver I will not actually serve those files, UNLESS you set DEBUG to True, which will enable various bits of code, including one that has a memory leak.
flipping BS is what it is
 
2:22 PM
> To add to this discussion and maybe help others who wonder why when they are clearly using 64bit Office they're getting memory issues:
I use 64bit Access (Office), and was getting consistent "out of memory" errors with my file sitting around 1GB, give or take. Originally thinking that 64bit is LAA, I didn't try the fix.

But on a whim, I ran the LAA tool on `VBE7.DLL`, `VBEUI.DLL`, `MSACCESS.EXE`, and the RD DLLs (specifically `RubberDuck.DLL`)

I may run it on the rest of the RD DLLs (p
 
2:56 PM
@Duga That's weird.
 
> That is totally unexpected. However, I'd also add that we should also revert the files as to prove that the memory errors re-appear and thus is not a fluke that was just coincidental to you running the LAA tool.
 
3:13 PM
> To confirm, you want me to revert the files (even though the tool didn't do anything)? Revert to not LAA, or just reinstall RD?
> Either would work, yes. If it was really the LAA tool (even though it reported it did nothing) then reverting should bring back the memory errors and re-running it should then make it go away again, which would be more stronger proof that there's something afoot with the LAA thingee.
> Alright, I'll give this a go and let you know; one moment, digs around in computer for files
 
3:39 PM
> Alright. I did it. Was not able to change the flag; got a write error, in fact.

1. I unloaded and ran the tool to clear the value.
2. Restarted Access. RD ran slower and parsing took a while, and memory stayed around the 1GB mark.
3. Closed Access, ran the tool to set LAA flag.
4. Indicated no change (again).
5. Started Access, RD parses faster.

I cannot explain it. But, it clearly did something. RD info:
Version 2.5.2.5994
OS: Microsoft Windows NT 10.0.19042.0, x64
Host Produ
> Alright. I did it. Was not able to change the flag; got a write error, in fact.

1. I unloaded and ran the tool to clear the value.
2. Restarted Access. RD ran slower and parsing took a while, and memory stayed around the 1GB mark. I was not able to induce the memory error, but the memory in use stayed below 1GB; but I did notice a performance degradation.
3. Closed Access, ran the tool to set LAA flag.
4. Indicated no change (again).
5. Started Access, RD parses faster.

I cannot e
 
TBH, that is weird but I have a working theory....
Given that LARGEADDRESSAWARE is enabled by default for 64-bit build, and it was necessary to create a build task to make 32-bit executable LAA, and given that RD is building with Any CPU, it might be that the effect of Any CPU cause it to not be LAA.
To test that theory, we'd need to build RD with x64 instead of Any CPU and see what happens.
 
@this is exciting news! Finally, something that looks like actual progress on a big bug that's plagued the Duck for a long time and, unfortunately, lost us several users because they couldn't get around it. If this ends up leading to a solution, we'll definitely need to list hecon5 as a contributor in the About box!
2
 
3:54 PM
> Sure thing!

Direct link to DL: [modLargeAddressAware.zip](https://codekabinett.com/download/modLargeAddressAware.zip)
Page source: [The /LARGEADDRESSAWARE (LAA) flag demystified](https://codekabinett.com/rdumps.php?Lang=2&targetDoc=largeaddressaware-msaccess-exe)
> Sure thing! I ran this via Excel (because you can't run this in the same Application you're trying to set), if that helps any.

Direct link to DL: [modLargeAddressAware.zip](https://codekabinett.com/download/modLargeAddressAware.zip)
Page source: [The /LARGEADDRESSAWARE (LAA) flag demystified](https://codekabinett.com/rdumps.php?Lang=2&targetDoc=largeaddressaware-msaccess-exe)
 
4:21 PM
I... uh... wat
this makes no sense whatsoever
 
> Thanks, reading the source code, it makes less sense because it really does nothing beyond reading the LAA flag from the file. I had surmised that maybe it was reporting "doing nothing" but in actuality doing something. That doesn't seems to be the case, so I'm not able to explain why just running the LAA tool affects it so. If it was simply because the LAA tool was reading the flag, then clearing the value (and failing) should have not have made it run slower again.
 
@Vogel612 No I don't. And it doesn't, either.
 
4:34 PM
> I agree, I am also flummoxed. But in my anecdotal test size of 1, it seemed to work.

I'll keep an eye on memory use for a bit and see if anything changes, but, other than my machine was placebo satisfied, I've got nothing.
 
Coming to a duck near you soon, a turbo button?
 
♫Na-na-na-na-na-na... Turbo!!!♪
 
5:10 PM
> Try editbin from Visual Studio, I use this to set the flags on my software.
And compare the files between before and after editing it.
 
5:24 PM
> I used `dumpbin.exe` to check for the LAA flag on all DLL files in the RD directory. Then I listed only those not LAA aware to get a shorter list.

Here is what I get:

```
EasyHook32.dll is NOT LAA aware
EasyLoad32.dll is NOT LAA aware
ICSharpCode.AvalonEdit.dll is NOT LAA aware
Microsoft.Expression.Interactions.dll is NOT LAA aware
office.dll is NOT LAA aware
stdole.dll is NOT LAA aware
System.Windows.Interactivity.dll is NOT LAA aware
```

NOTE: All the main RD DLL files appea
 
 
3 hours later…
8:26 PM
 
8:45 PM
> **Rubberduck version information**
The info below can be copy-paste-completed from the first lines of Rubberduck's log or the About box:

2022-01-24 15:41:24.2324;TRACE-2.5.2.5906;Rubberduck.Common.LogLevelHelper;
Rubberduck version 2.5.2.5906 loading:
Operating System: Microsoft Windows NT 10.0.19043.0 x64
Host Product: Microsoft Office x64
Host Version: 16.0.14729.20260
Host Executable: EXCEL.EXE;


**Description**
When opening a specific file i get a parse error. The VBA co
> As a FYI - I did the same thing and it did not make any difference in the performance.
 
9:19 PM
> I mean, I expect nearly no one else will have the same experience. I personally figured it would be another road to nowhere. But, if it was a fluke or not,... I swear it did do something. I haven't had an out of memory error since I did, and I was getting them left and right.
 
9:41 PM
> That is very interesting. The parser seems to fail on `Option Explicit` when expecting an `<EOF>`. This suggests that you have declared the Option explicit later than the parser expects.

Since this is the latest green release it's impossible for the recent changes to the grammar to be responsible for this issue, which implies that this has been an issue for a bit longer than I'd like... Could you check whether (and how) moving the `Option Explicit` in the module `ThisWorkbook` affects this
> I think the host has to be LAA aware. All office apps are except Access, which is supposed to get LAA this September. If you have patched your MSACCESS.EXE then it would load all extensions as LAA, ready or not.
> That's what I thought, except 64bit MSACCESS.EXE IS LAA already, and I was getting out of memory errors around 1GB in size. It's ... flummoxing to be sure.
> That's what I thought, except 64bit MSACCESS.EXE IS LAA already, and I was getting out of memory errors around 1GB in size. It's ... flummoxing to be sure.
 
 
2 hours later…
11:45 PM
[rubberduck-vba/Rubberduck] 1505 stars vs. [decalage2/oletools] 1892 stars
 

« first day (2789 days earlier)      last day (391 days later) »