« first day (1647 days earlier)      last day (1533 days later) » 

12:00 AM
RELOAD!
[rubberduck-vba/ReleaseCleaner] 4 commits. 523 additions. 84 deletions.
[rubberduck-vba/Rubberduck] 7 commits. 2 opened issues. 2 closed issues. 5 issue comments. 230 additions. 122 deletions.
 
12:58 AM
@Hosch250 I thought about that but wanted to get it up for review. Crap code up for review IMO is better than crap code that can’t be reviewed.
 
1:53 AM
I just wrote an editor with Avalon Edit.
:P
It opens files and edits them and saves them.
And it converts tabs to spaces.
Next step: let it take a valid C# file and execute it and show the console output.
 
 
3 hours later…
4:26 AM
> Whoa @retailcoder, I keep thinking that this software can't get any better and then I watched that video. Rubberduck handling references like that is a **killer** feature. Seriously, great work!

Adulations aside, Code Inspection will (still) report a warning if a class module contains a `@PredeclaredId` annotation when it's `VB_PredeclaredId` attribute is `False`. While I realize it's only a one-way check (I weep for the loss of annotations/attributes synchronizations), my colleagues and I
 
5:19 AM
> Yes, this should be easy to update and a good first issue. Being a built in template, the source is stored in [this resource](https://github.com/rubberduck-vba/Rubberduck/blob/next/Rubberduck.Resources/Templates.resx). I am not certain if the annotation and the inspection needs any additional updates, however.

There is one more consideration not covered with the template. If you change the code in resource, how do you ensure that the file that was previously generated is updated? Though it
 
 
2 hours later…
7:26 AM
[rubberduck-vba/Rubberduck] build for commit 9bc9d809 on unknown branch: AppVeyor build succeeded
 
 
6 hours later…
1:01 PM
hmm, just pulled from upstream, seem to get quite a few exceptions and binding failures in the Output window when starting RD now. Just me?
oh i see, it's just enhanced logging, now emits handled stuff where before it didn't
 
 
4 hours later…
4:47 PM
omfg... I don't even ...
argh
Consider the following MCVE
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Echoing arguments one by one");
            foreach (var arg in args)
            {
                Console.WriteLine(arg);
            }
        }
    }
invoking this via dotnet cli kills expectations about argument cohesion:
 dotnet run --project MCVE -- "quoted arg"
Echoing arguments one by one
quoted
arg
^^ THIS IS BOLLOCKS!
escaping the double quotes only results in them being passed into the arguments
the behaviour is persistent between zsh, bash and sh
 
Can someone take a look at the following MVCE and see if I'm missing something obvious?
<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="*"/>
        <RowDefinition Height="*"/>
    </Grid.RowDefinitions>

    <TextBox Grid.Row="0" Text="{Binding Input, UpdateSourceTrigger=PropertyChanged, Mode=OneWayToSource}" TextChanged="TextBox_TextChanged" Name="Input" />
    <TextBox Grid.Row="1" IsReadOnly="True" Text="{Binding Output, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" Name="Output" />
</Grid>
public class ViewModel : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;
    private void OnPropertyChanged(string name)
    {
        PropertyChanged?.Invoke(null, new PropertyChangedEventArgs(name));
    }

    private string _input;
    public string Input
    {
        get => _input;
        set
        {
            _input = value;
            Output = value;
            OnPropertyChanged(nameof(Input));
        }
    }

    private string _output;
    public string Output
The TwoWay thing should be OneWay, I guess. I was just testing to make sure that wasn't the issue.
And the TextChanged event is just a breakpoint to see if the value is being updated--the VM is being updated correctly, the UI is not.
It's like the UI is entirely ignoring the OnPropertyChanged(nameof(Output));.
TextBlock and TextBox` are both doing this.
 
5:06 PM
could it be suppressed because you're updating from within Input?
 
NAFAIK.
I'll get rid of Output entirely just to be sure.
Binding to Input doesn't make a difference.
Pretty sure it's something I'm doing wrong, because no text control is updating, even though the VM is.
I just tried Label too.
New MVCE:
<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="*"/>
        <RowDefinition Height="*"/>
        <RowDefinition Height="*"/>
    </Grid.RowDefinitions>

    <Label Grid.Row="0" Content="{Binding Input, UpdateSourceTrigger=PropertyChanged, Mode=OneWay}"></Label>
    <TextBox Grid.Row="1" Text="{Binding Input, UpdateSourceTrigger=PropertyChanged, Mode=TwoWay}" Name="Input" />
    <TextBox Grid.Row="2" IsReadOnly="True" Text="{Binding Input, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" Name="Output" />
public class ViewModel : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;
    public void OnPropertyChanged(string name)
    {
        PropertyChanged?.Invoke(null, new PropertyChangedEventArgs(name));
    }

    private string _input;
    public string Input
    {
        get => _input;
        set
        {
            _input = value;
            OnPropertyChanged(nameof(Input));
        }
    }
}
Nothing is updating, even though the VM is.
The Output window doesn't show any errors.
I'm trying to re-learn WPF so I have a chance in interviews when I try to get out of the web business.
 
have you tried dropping the UpdateSourceTrigger, just for giggles?
 
Yes.
I've tried making everything TwoWay.
I've tried dropping the trigger (lost focus is the default).
I've tried making everything public (usually I keep some things private).
Normally in this case, I'd just go through the UI:
<TextBox Grid.Row="2" IsReadOnly="True" Text="{Binding ElementName=Input, Path=Text, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" Name="Output" />
But, for the real purpose, it's coming from the VM, not the UI.
So, that ^^ works.
I checked the DataContext on that control. It's the view model.
So, it's bound correctly :(
 
hrmm...
I'm coming up empty, but it seems like something that makes a good SO question, TBH
 
I'm getting close.
But I won't ask on Sunday because it's dead and gets buried by other stuff.
The WPF section, I mean.
I've read dozens of places that just say "Fire the PropertyChanged event".
And one place that says there's a bug in the .NET Framework, where the textbox Text element actually gets updated, but it doesn't make it to the UI. That's not the case here, because the Text element isn't getting updated, and the get on the VM is never being called.
So, something's not triggering the control to even update.
It seems weird, because if I set the Input to a specific value, it displays that value, but still doesn't apply any updates.
 
5:31 PM
sigh... why is the buid process for dotnet cli so uncooperative?
 
Afraid I can't really help you there. Is there any particular reason you are using the CLI?
 
writing a small console app to automate deleting orphaned releases from GH
my MCVE is right above yours
and the dotnet cli is basically the only thing I can run on my Linux box anyways.
 
@Vogel612 Isn't that because the Console basically runs on its own thread?
 
nah, it's actually a regression ...
 
Oh snap.
 
5:35 PM
yea. exactly
 
Is that only the console, or is it any standard output?
 
@Comintern huh?
stdout doesn't have that much to do with it.
the point is that the arguments from the program invocation aren't parsed correctly
 
This is why I should read the entire issue...
 
FWIW, I ran into a similar problem when I wrote my little own console program
I ended up using a OSS library --- I think this is the one: github.com/commandlineparser/commandline
 
ya... I don't want to have a verb-style interface, though...
 
5:47 PM
Ok, but at least it makes it a bit more testable. I found the string[] args to be just as useless in .NET fx just as it apparently is in .NET core
 
6:04 PM
ugh
> /opt/dotnet/sdk/2.2.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependen‌​cyResolution.targets(208,5): message NETSDK1062: Unable to use package assets cache due to I/O error. This can occur when the same project is built more than once in parallel. Performance may be degraded, but the build result will not be impacted. [/home/vogel612/coding/OSS/dotnet/cli/build_projects/dotnet-cli-build/dotnet-cli‌​-build.csproj]
 
TBH, that reads like "yo, this ain't my problem, bro. Deal with it, homeboy."
 
yea... that's what you get from building from source
"Just run build.sh they said. It's fine they said"
FFS
 
6:21 PM
eurgh. fuck it
I'm done..
I've been building from three different tags now and it fails regularly.
that build-process is a damn nightmare
 
6:37 PM
why in the world are they trying to install dotnet-core version 1.1.2 in their build process, but not expose it on their mirrors?
 
6:48 PM
> Originally from the discussion:

https://github.com/rubberduck-vba/Rubberduck/pull/4601#discussion_r240046688

It seems that with upcoming PR #4601, we will need metadata about host applications in multiple places in different projects.

Though we already have a `IHostApplication`, this is a SCW, and we don't really need one just to get the file name, the allowable list of extensions and other stringified metadata that should be kept uniform for all potential consumers. Thus, the idea i
[rubberduck-vba/Rubberduck] bclothier is bored so why not move a project card
> On the one hand, we already have the procedure separator to tell us which procedure we are in. Thus a `@Description` in a `(Declarations)` should be obviously a module level description. We can pass this off as a user-training issue; they need to actually use the separators to guide them to how they should place the annotations.

The above assumes that it is not possible to have that applied to any other elements in the declarations... right? If that assumption is incorrect then the only sen
 
 
1 hour later…
7:57 PM
> The more I think about it, the more a `@ModuleDescription` annotation makes sense and simplifies telling it apart from valid and legitimate annotations that would describe public fields, for example.

So, let's leave it the way it is and treat `@Description` as illegal for a module-level docstring, and let's introduce a `@ModuleDescription` annotation when we're ready to make the corresponding `VB_Description` attribute synchronize for module-level (along with `@PredeclaredId`).
 
8:21 PM
> Let me clarify a few things. We no longer consider the anything from the VBE API to determine the scope of an annotation. All annotations above a member are scoped to the member until the is a line without a member annotation. Moreover, because not applying module annotations present in these sections was perceived as unintuitive, we apply all module annotations above the first member to the module.

Furthermore, the description for module variables has to be different because the attribute
 
 
2 hours later…
9:51 PM
> The release notes page is not working for me (404).
 
10:12 PM
> Why remove this inspection instead of implementing the quickfix?
 
10:39 PM
@Duga @MathieuGuindon We should have everything in place required to implement the quickfix.
 
> I think the inspection can reasonably be reinstated for module-level annotations, but for a bugfix release I'd leave it out. Right?
 
Why only for module attributes?
Moreover, why remove it for the hotfix release?
 
@Duga kk, it's a core only link. bit of a pain ...
 
The results are no bugs and you can actually do something about it, just not via Rubberduck.
 
> The release notes are recorded in a draft release. Because the branch moved after the notes were initially created, the URL to these notes also changed. Could you check [this link](https://github.com/rubberduck-vba/Rubberduck/releases/edit/untagged-b5925ae561a9bfd0ea0f) for me?

If it doesn't work, I'll move the notes to a Discussion visible to all Members of the Rubberduck org
 
10:56 PM
Hey @MathieuGuindon are we releasing tonight?
If yes, is there something you want to include in addition to the current PRs?
If no: when?
 
Personally, I would vote for releasing what is merged now. We have fixed the crashes and really annoying new bugs already.
There will always be more small things we want to get in.
 
same. I still want mat to give a thumbs up to doing that
fwiw we've already bumped the AV version, so it's going to be kinda stupid to keep merging PRs.
 
> @rkapka The release notes are recorded in a draft release. Because the branch moved after the notes were initially created, the URL to these notes also changed. Could you check [this link](https://github.com/rubberduck-vba/Rubberduck/releases/edit/untagged-b5925ae561a9bfd0ea0f) for me?

If it doesn't work, I'll move the notes to a Discussion visible to all Members of the Rubberduck org
 
11:13 PM
@Vogel612 yeah. I didn't have a chance to dig further into the bug I was investigating yesterday though.. If I can slip a fix for that one reasonably fast enough after kids are in bed, I'll do it - otherwise I'll just hit the merge button and upload the hotfix release build to the website, and the bugfix will go for 2.4
 
11:32 PM
If you want me to help with the release tonight, drop me a note in the next hour or so
 
11:45 PM
@Vogel612 thanks!
 
I assume that's a yes?
 
@MathieuGuindon If you mean the false positive for ObjectVariableNotSet, you probably just have to add a (DeclatarionType == DeclatationType.PropertyLet || DeclarationType == DeclarationType.PropertySet) && to the second part of the conditional in the implementation of IsObjetct in PropertyDeclaration.
For those cases that part makes sense; for property get it is simply wrong.
 

« first day (1647 days earlier)      last day (1533 days later) »