Macro Msi
Linh Swanick
I currently have a macro which works if I test it directly via assertMacroExpansion(), but if I try to actually use it simply gives the error "error: failed to receive result from plugin (from macro 'Foo ')" and no further information other than pointing at the line of code being expanded. Is there some way to debug this and attempt to determine what is going wrong, or do I just need to change things at random and hope it starts working?
I think it failed because your macro's expansion() method crashed somehow. You could try copying the compiler command line invocation from the build log in Xcode, and execute it in the Terminal to see if something is emitted to the stderr from the plugin.
if you use the package layout of macro (swift package init --type macro) you can debug the invocation of the macro in the tests; which makes tracking those types of things down considerably easier. Plus writing those gives you some neat unit tests for your macro .
This specific bug was in a conformance macro which currently isn't supported by macro tests (see [Macros] Implement expansion of conformance macros by DougGregor Pull Request #1773 apple/swift-syntax GitHub).
So far assertMacroExpansion() does not seem like a viable way to write or test macros. It simply doesn't do the same thing as the compiler does, and a test passing is no guarantee that the macro will do the same thing when invoked on the exact same code by the compiler.
Perhaps you should switch to those, or you change the start-up macro of the Paintbrush Tool as proposed by Jerome Mutterer:
-do-I-set-Pencil-Width-Brush-Width-or-Eraser-Width-from-within-a-Java-Plug-in-tp3682608.html
One of the first steps of my macro is saving a video as image sequence.
Using the Recorder and selecting that I want the names of the image sequence to be from the original file name (RGB.tif), I got this line:
So when the macro is ran and when i check the job inspector to see the contents of macro, it is not showing full content of macro instead it is showing some content and skipping 23145 lines in between.(may be because macro has macro inside it).
i had only one macro which has long query inside it, due to this, i was facing "Request URI too long error", hence i have used another macro inside a macro, to reduce the query length. But now i cannot able to see the expanded query when the macro has ran. In job inspector some lines are skipped.
I've been excited to use macros in Swift and started by looking at the examples repo. I used @MyOptionSet as a baseline because it adds conformance to a protocol and @CustomCodable to learn how to find properties decorated with another macro.
With this information I created CustomHashable/CustomHashable.swift at main JosephDuffy/CustomHashable GitHub. Running swift test -Xswiftc -Xfrontend -Xswiftc -dump-macro-expansions shows it outputting the generated code I would expect:
This seems to be improving. With recent snapshots, e.g. swift-DEVELOPMENT-SNAPSHOT-2023-05-14-a, I have been able to use hashValue when Hashable conformance and the hash(into:) function are added by a macro.
With the release of the Xcode 15 beta I have also created an issue on the Swift repo for this: `==` implementation added in a macro is not considered when checking for `Equatable` conformance Issue #66348 apple/swift GitHub
The idea would be that for macros which evaluate an expression in an unsafe block, the unsafe keyword would only be applied to the code inside the macro itself, and not to any code passed in as an expression.
I believe that requiring both places to add unsafe blocks more accurately describes that there is unsafe code used both inside the macro, and inside the expression for this single invocation of the macro.
I think this is already the desirable behavior anyway, because of your first bullet point: Either the unsafe keyword belongs inside the macro, or it belongs outside the macro, based on whose job it is to uphold whatever the uncheckable invariants are. The crate whose job it is to uphold the invariants ought to be the one that gets flagged by tools like cargo geiger, so if geiger "blames the wrong crate" then the macro probably needs changing.
Imho, if someone wanted to create such macro (e.g. unsafe_identity!), then another "metavariable type" than $...:expr should be used; thus allowing to forbid the above code (since the transmute... expression would not have been valid if it weren't for the macro), as a safety guard to prevent code like the one in the OP. Maybe creating a new "metavariable type", e.g. $...:unsafe_expr ?
We have macro hygiene for identifers, meaning names declared inside the macro don't leak into code that is passed in at the macro use site. We should have the same for unsafey, ideally: To decide whether code is considered to be in an unsafe block, we should be aware of macros, so that in your identity example, transmute is not considered to be written inside an unsafe block -- because the code was written outside the macro body but the unsafe block was declared inside the macro body.
If genuine unsafe hygiene is a long ways off, maybe we could have a clippy lint against using potentially complex matchers like $item, $expr and $tt inside an unsafe block? A macro with $ident in unsafe seems much harder to abuse.
Byt ideally, we should still allow some way to circumvent it (the problem is accidentally wrapping a user-provided expression inside an unsafe context before it gets evaluated; but we should still allow macro creators to do that on purpose, hence my "special metavar type" suggestion).
There can be a lifetime related issue regarding temporary variables within the expression, so the ::std::dbg! macro uses the match with a single irrefutable pattern trick to get around that. I thus think using the match instead of the let should give the macro a slightly better usability.
the suggestions for preventing this (matching the expression, or assigning the expression to a temporary variable) are error prone (easy to forget when writing or refactoring macros), and are not aesthetically pleasing.
The compiler already has support for this. We'd just need to emit it at the appropriate sites, but that would cause a breaking change. I think the idea solution is to create an unstable safe block feature that the macro expansion code can wrap around all expression arguments passed to a macro. Instead of erroring with a hard error, we'd emit a future incompatibility lint.
I have the 35 and as mentioned, you have to be really close for the built in ring light to be effective. It is, however, a very good lens. Most of my macro work is done with the EF 100mm f'/2.8 L IS USM. It is a bit pricey, but reasonable if macro is your thing, and being an L, it is built like a tank and weather sealed. Your T6 isn't, but you still get some protection where the lens attaches.
I like the 100mm focal length better than 35mm. Canon makes a non-l 100mm macro, so give that one a look, too. I don't know if the EF-S 60mm is still available, anymore. You're better off with the Canon EF 100mm f/2.8 Macro USM then either the Sigma or the Tamron, IMHO. It does lack image stabilization, though.
So, in that light and IMO, you will need more than just a macro lens (if macro at all) to do this kind of work. Most of these shots, in reference to the snails, were more than likely staged, probably in a special terrarium. It's a very popular technique amongst pro shooters of this type. This is NOT to detract from the imagery and work he does, I just want to point out how I think he does this. Not knowing him personally, I can only base what I'm seeing on years of experience and knowing others who do this kind of work. Some of the shots, well, look a little manipulated in post, so add PS to your list of needs
He may have indeed used a "macro" lens of some sort as most macro lense work well for other uses, but since the EXIF data has been removed from the samples I looked at, there is no solid way of telling. I can say that most of these shots could be taken without one, and possibly were. He, or the person captioning the shots, throw the word "macro" around quite a bit, but macro isn't what comes to my mind when I look at his work, but there were a few exceptions.
** To be clear, macro means different things to different people. In the strictest term, it simply means "close up", but to most who have been doing it for years, it means 1:1 or smaller, i.e., 2:1-5:1 at your lenses closest focus plane, not the end of the lens, but to the sensor. Look on top of your camera and you will see a circle with a line through it that marks the location of your sensor, so, if your lens will focus to 1 foot, that is where you measure from. Your 50, which will focus to 1.1x feet, and IIRC, its ratio is 1:1.2. The ratio I am refering to is also sometimes debated because, from as far back as I can remember, was coined in reference to 35mm film, but now we have smaller sensors and image editing programs to muddy the waters. In 35mm, 1:1 means the subject, at your lenses closest focal plane, is lifesize on that sensor or film.
thanks for your reply. here's another photographer, Vyacheslav Mishchenko, who uses natural settings and not staged. i ight have actually gotten him mixed up with the first one i mentioned. -mishchenko-macro-snails/
yes, i know what macro means. and i am wanting actual macro photos.here are a couple non macro lens photos i took. the first is made using my canon powershot. the second is made with my canon rebel with a nifty fifty lens. while both are relatively descent photos, i'm wanting to improve my photos with much more detailed macro photos.
df19127ead