Jump to content

Search the Community

Showing results for tags 'debugger'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Alfred 3
  • Make the Most of Alfred
    • Discussion & Help
    • Bug Reports
    • Alfred Feature Suggestions
    • Themes
  • Alfred Workflows
    • Share your Workflows
    • Workflow Help & Questions
    • Advanced Tips & Tricks
  • Alfred v2 Themes
  • Alfred Remote for iOS
    • Alfred Remote Discussion & Help
    • Remote Connection Troubleshooting

Categories

  • Articles
    • Forum Integration
    • Frontpage
  • Pages
  • Miscellaneous
    • Databases
    • Templates
    • Media

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Twitter


Website URL


Jabber


Location


Interests

Found 5 results

  1. It would be nice to have a few shortcuts for the debugging in the Workflow. Notably to expose the debugging panel as well as to clear the output. As I use VSCode all the time and my memory muscle always wants to use cmd J to toggle hide and show the debug area and cmd K to clear the output screen. I figure a lot of people would do the same thing
  2. Hi guys and girls, I have a couple of questions related to workflows. I want to do a workflow which should be able to distinguish between types of selected objects - text, folders and files. Based on type it should perform different actions. How does a argv object internally looks like? Does it even provide a mime-type information or converts everything to text? How can I properly debug workflows? With built-in debug I get only the output in the console. Is it possible to have a look into the argv object structure or set breakpoints in scripts?
  3. Alfred v3.4 [843] Selecting "All information" in the debugger doesn't show the input passed to Script Filters.
  4. As best as I can tell, any output to STDERR will cause Alfred to prefix the output with [ERROR: alfred.workflow.input.scriptfilter] in the debugger. While more experienced users/developers will recognise that [ERROR: alfred.workflow.input.scriptfilter] Code 0: (especially if Alfred also show results) means that there wasn't actually an error, this behaviour is misleading for less expert users because Alfred's debugger says there was an ERROR when there actually was none. Alfred should not automatically prefix output to STDERR with ERROR. ERROR should only be printed if the exit code is non-zero and/or the returned XML was invalid. Otherwise it's misleading and causes users to report errors that aren't errors. There may well actually be something wrong, but as Alfred's default behaviour is the same in the case of zero results and an actual error (i.e. show fallback searches), it can easily result in users reporting an "error" when they're just getting an empty result set. I'm posting this in Bug Reports because it's logically wrong to report ERROR when there isn't actually one.
  5. The new debugger is an extremely welcome addition, as Alfred's previous utter silence in the face of errors was very frustrating when trying to debug errors not obviously located within the workflow itself. However, I'd love to see its scope expanded somewhat to make it a useful workflow debugger as well as an Alfred one, so it's no longer necessary to also implement logging/debugging within workflows themselves (which is busywork that distracts from the important, fun and value-adding business of creating workflow functionality). Because Alfred currently only displays the workflow output if the workflow exits improperly, it's no help debugging non-fatal errors (mistakes in logic; exceptions logged but caught; incorrect, but still well-formed XML), so workflow authors will still need to bake their own logging solution to track down and squash such errors. If Alfred always displayed workflow output to stderr, regardless of exit status, this would save workflow developers a fair bit of coding busywork and/or time hand-holding less technically-inclined users through the somewhat arcane process of digging a log file out of ~/Library or running the workflow from Terminal. Showing the received XML in the case of an XML Parse Error would also be very helpful: the row and col numbers aren't particularly helpful without it.
×
×
  • Create New...