« first day (2131 days earlier)      last day (50 days later) » 

12:00 AM
RELOAD!
[banane-io/pdb-frontend] 6 commits. 1510 additions. 848 deletions.
[Minesweeper] New Users: 41, Games Played: 171, Bombs Used: 103, Moves Performed: 20260
 
 
14 hours later…
1:32 PM
user image
4
 
@MathieuGuindon That's encouraging!
hopes he's not using Excel as the database. :D
 
1:45 PM
Past experience tells me it’s likely.
 
argh....
why can angular not just WORK??
 
^ where's the fun of that?
 
2:00 PM
@Vogel612 Angular isn't a framework. It's a language, you know?
 
no it's a hot effing mess
modern JS is such a travesty to the whole field of computer science
 
Would be nice if it turned out that JS came about in response to question "can we do worse than C++?"
Nice in the sense that it'd make so much more sense why they designed JS like that.
 
C++ was actually doing pretty okay until they tried to jam everything at once into it
but JS is a scripting language that's generally transpiled without debug symbols so it unifies the worst of both worlds
it doesn't help that the web is a hot mess of stapled together garbage that works just well enough for most people to not notice something's wrong
 
That sounds like a lot of what comes out of America.
Im in a foul mood because of an upset stomach. Ima try and sleep it off...
 
2:27 PM
@Vogel612 been working on testing the company's websites lately (outsourced, PHP)... I hear ya =)
 
PHP => "gee, JS isn't the worst we can do. Let's do even worse than that."
and you should be worried that people are building commercial solutions on a language originally named "Personal Home Page" ...
 
 
1 hour later…
3:40 PM
That’s the original name of PHP?
 
yeah
Reassuring isn't it?
 
Not at all.
 
I'm only a bit disappointed they didn't call it Cowboys
 
As reassuring as the Pineapple in chiefs ability to rationally lead a country.
 
then we could talk about cowboys circling the wagon running on an apache server.
 
4:20 PM
I like that one!
 
5:12 PM
just curious on others' take on this... I use apps hungarian to indicate if the parameter will be passed as Ref or Out since VBA does not really help with the distinction.
Public Function Validate(OutMessage As String) As Boolean
End Function

Public Sub UseIt()
  Dim Message As String
  If Not Validate(Message) Then

  End If
End Sub
Question: would you change the code Dim Message As String to Dim OutMessage As String to make it more explicit? Or would you just use OutMessage:=Message ?
 
Silly follow-up question by me, but if they wanted to know, wouldn't they just look at the intellisense?
That's what I would do anyway, use the Intellisense pop-up to see if it's byref or not.
 
what, you expect me to put my cursor there, press ctrl + I?!?! UUUUUGGGGHHHH
:D
But yes, the intellisense would make it obvious; just not from eyeballing alone.
 
Then in that case I'd probably do the latter of your two options :D
 
which is mouthful, unfortunately.
VBA does not make it easy to win.
 
No it doesn't.
May I ask you a C# question?
 
5:18 PM
Shoot.
 
Similar to what I asked last week. I did lots more homework following my conversation with you and @HackSlash.
So this is what I have now:
                Task.Run(
                    () => Parallel.For(
                        files.GetLowerBound(0), files.Length, i =>
                        {
                            _837Fixer.ProcessSingleFile(files[i], viewModel);
                        }
                    )
                ).Wait();
And here's the steps of the problem I'm having:
* .Wait() clogs the UI thread and the ProgressBar can't update.
* I async/await it instead, and follow the viral spread upward.
* When I make Main() async, it complains that WPF requires STAThread for UI components even though Main() is already marked as STAThread, because that gets overridden/ignored by async.
 
Yeah, no, you don't want Wait() there
rather you need a WaitForAll()
 
* When I make a new thread for main and set its ApartmentState to STA, it says I need to make my lambda expression async to be able to await inside of the thread's task.
I stopped there because I worried I was going completely off the rails.
@this Why do I want a WaitForAll() for one containing task, and would WaitForAll() offload from the UI thread? From my homework this weekend, I'm of the impression that any kind of wait on the UI thread keeps it busy.
Won't the containing task only be marked completed when all the Parallel.For is done? Or did I misunderstand?
 
Maybe this will help:
the idea is that you want to start each task off async. Then you use WaitAll() to get all tasks result before you continue.
the thread that WaitAll has to be non-UI thread, too; you probably want to disable the Run button (or whatever it is), and enable it only when the WaitAll() has returned.
 
Okay, I'll look at that. I do understand what WaitAll() does, but maybe by looking at that code I'll be able to answer my own questions about why I'd need WaitAll instead for what seems to be a single task.
 
5:29 PM
But the thread that starts other tasks itself needs to be non-UI thread so you end up with one task that basically acts as the synchronizer for all tasks in parallel.
 
Thanks for answering about the UI thread.
I don't have any buttons to disable or anything, but I'll look at my design again and try to figure out where the offloading needs to happen.
Maybe a night's sleep has helped.
 
Right. You don't want your UI thread to be busy, even if you have no button. It should just be idle, listening for events from all tasks, including the task doing the synchronization.
 
I'll keep working on that.
@this Okay, listening for events from all tasks in the form of await, right?
If so, then are you confirming I need to have an async main and to kick things off with with a new thread marked STA with an async lambda expression? Or did I miss an exit on the highway to Crazytown before that?
    class Entry
    {
        [STAThread]
        static void Main()
        {
            try
            {
                var programCompleted = false;

                var landing = new Landing();

                while (!programCompleted)
                {
                    landing.ShowDialog();

                    if (!landing.GoToNextWindow) { return; }

                    while (landing.GoToNextWindow)
                    {
                        switch (landing.ChosenUtility)
                        {
 
5:55 PM
@puzzlepiece87 well, after you await, you'd fire a dispatch to the UI to update the progress bar, yeah.
 
Okay, I'll see what I can do.
 
The code above isn't enough for me to go on. I assume that within the ShowDialog(), you are going to spawn new tasks
and within that dialog, it should not proceed further until all tasks has returned.
 
@this Oh, no, nothing like that.
And I understand why that's not enough to go on.
For all of my windows, they show up, the user clicks something, and then they close and work continues (on the UI thread because I'm still struggling to get if off) or another window is put up in response.
So on that landing window, they are just picking which tool they want to use, and landing quickly saves their choice to a property and marks whether they hit exit or not and goes from there.
 
Alright the thing is that i don't actually see a dispatcher anywhere and you need one if you want to avoid clogging up the UI thread
 
6:17 PM
Back from a mandated restart and you are correct, I don't have any dispatchers in my code. If I understood Mat correctly, I won't need them as long as my UI updates are data-bound.
(The UI does display the correct update after the program is over)
 
6:30 PM
@puzzlepiece87 from the UI thread, don't do any waiting or awaiting. You would do something like this:

Task.Run(()=> ParallelProcessFiles());
Where that Parallel.For now lives in it's own Async procedure, outside of the UI code. Preferably in a different module where all of your action code lives.
The UI just goes back to normal. If you need some action to happen at the end it needs to be called from the end of your ParallelProcessFiles procedure, not the UI thread. You would raise a signal to the UI thread that the process is done.
 
Hence why you need a dispatcher
since you would have to invoke into your UI thread to update the UI
 
That's the next level that I don't know about. I'm likely doing something the hard way when there is this built in tool....
 
@HackSlash Okay, I'll try that again. In my memory, if I don't wait/await for the tasks to be done, the program finishes execution. I'm a little unclear how to keep it listening as you two are describing.
In my memory, when I kicked off the ParallelFileProcessing without awaiting, it gave control back to the caller, Main() basically, and the program ended.
Because there were no other steps left in Main() to execute
 
7:17 PM
> Entire sections of code he was thought to have programmed were actually just copy-pasted wholesale from the internet.
That is disaster waiting to happen.
 
that thread is great
 
Just add some more duct tape. It'll hold.
 
Duct take: Once more into the breach ...
 
7:50 PM
Are you playing that game from the giant bundle?
 
8:01 PM
@IvenBach Holy crap! You can't just run code from the internet like that! You first have to run it through RubberDuck and fix the issues.
 
8:17 PM
@puzzlepiece87 ok, now I'm confused. You said "UI Thread" before but now you are describing the behavior of a console application. The program flow is going to be different depending on if you are making a windows forms application or a console application. So which is it?
 
8:45 PM
@HackSlash I'm using WPF with a Console-like starting point.
@HackSlash xD
I think Mat favors the same approach himself.
Manually controlling window instances from the code rather than letting WPF guide from one window to the next.
 
9:44 PM
I've never done that. Normally, there is an idle loop that is handled by a WinForms application. From a Console application I'm not sure if you can pass off to the form or if you have to manually create your own idle loop. Sounds like a bad idea. There is a thread here that is full of bad ideas: stackoverflow.com/questions/277771/…
Why are you doing this?
 
I learned it from VBA, mostly.
Seemed like it was an appropriate fit because most of the stuff my program does is CPU-bound text file editing
 
Note: I have made Forms/WPF applications that can be invoked from the command line and produce output to the console window. They are still defined as GUI applications and they don't have the problems you are experiencing.
 
The graphics are just for user configuration and progress display
I just finished taking command line stuff out actually
I can't maintain it as a sole developer, too little use so far
@HackSlash I'm almost certainly doing something really dumb.
Like misunderstanding the basics of offloading or something.
I'll get it eventually.
Right now I'm trying to follow up on what you two told me today by finding the very first command after the GUI is done (except the progress bar) and Tasking out from there instead.
(In between juggling my other requests)
 
10:19 PM
Read your thread, misspoke in calling my program a console app because I don't use a console. What I actually meant is that all the work is being done largely independently of any kind of graphical interaction.
 
 
1 hour later…
11:23 PM
@puzzlepiece87 Why do you have to wait for a task to finish?
And how exactly do you invoke the tasks?
 

« first day (2131 days earlier)      last day (50 days later) »