@triciaho asks: Is there a paste into in Illustrator CS4 ?

admin — Wed, 20 Jan 2010 01:15:14 +0000

@triciaho asks “this is a super noob qn. in indesign, there’s a “paste into” function, is there something similar in Illy CS4?” Well this one required a video response, and we think we have come up with a fantastic answer. Of course we did, we are the best there is. Using Illustrator CS4, Masks and LAyers and Nerd boy stuns Mr. Crayons when he knows an Illustrator shortcut. command 7 who would’ve thunk it!

Duration : 0:4:19

[youtube 6yG1OqvQ7Cs]

p6apclps #44 Perl 6 Apocalypse

admin — Fri, 18 Sep 2009 18:39:17 +0000

http://www.perlfoundation.org/perl6 – - return?* I lean towards just the message, with a different method for more info. But this is somewhat dependent on which representational methods we define for all Objects. And that has not been entirely thunk through. RFC: Mixed Flow Control *Some of the reference texts, when discussing exception handling, refer to the matter that it may be difficult to implement a “go to” across an unwinding semantics block, as in: * try { open F, $f } catch { next; } *This matter will have to be referred to the internals experts. It’s ok if this functionality is not possible, it can always be simulated with lexical state variables instead.* *However, the authors would very much prefer that “goto”s across unwinding boundaries would dwim. If that is not possible, hopefully some sort of compile-time warning could be produced.* We can do this with special control exceptions that aren’t caught until it makes sense to catch them. (Where exactly control exceptions fit in the class hierarchy is still open to debate.) In any event, there’s no problem throwing a control exception from a “CATCH”, since any exception thrown in a “CATCH” or “POST” would propagate outside the current try block in any event. Ordinary “goto” should work as long as it’s leaving the current try scope. Reentering the try somewhere in the middle via “goto” is likely not possible, or even desirable. A failed try should be re-entered from the top, once things have been cleared up. (If the try is a loop block, going to the next iteration out of its “CATCH” will probably be considered safe, just as if there had been an explicit “try” block within the loop. But I could be wrong on that.) RFC: Use “%@” for Errors from Builtins RFC 151 proposes a mechanism for consolidating the information provided by of $@, $!, $?, and $^E. In the opinion of the author of RFC 88, merging $@ and $! should not be undertaken, because $@ should *only* be set if an exception is raised. The RFC appears to give no justification for this last assertion. If we unify the error variables, “die” with no arguments can simply raise the current value of $!, and we stay object oriented all the way down. Then $! indicates the current error whether or not it’s being thrown. It keeps track of its own state, as to whether it is currently in an “unclean” state, and refuses to throw away information unless it’s clean. “%@” *should be used to hold this fault-hash, based on the following arguments for symmetry.* $@ current exception @@ current exception stack %@ current core fault information $@[0] same as $@ $@{type} “IO::File::NotFound” $@{message} “can’t find file” $@{param} “/foo/bar/baz.dat” $@{child} $? $@{errno} $! $@{os_err} $^E $@{chunk} That chunk thingy in some msgs. $@{file} Source file name of caller. $@{line} Source line number of caller. “%@” *should not contain a severity or fatality classification.* *Every call to a core API function should clear “%@” if it returns successfully.* *Internally, Perl can use a simple structured data type to hold the whole canonical “%@”. The code that handles reading from “%@” will construct it out of the internal data on the fly.* *If “use fatal;” is in scope, then just before returning, each core API function should do something like: “%@ and internal_die %@;”* *The “internal_ die” becomes the one place where a canonical “Exception” can be generated to encapsulate “%@” just before raising an exception, whether or not the use of such canonical “Exception”s is controlled by a pragma such as* “use exceptions;”. This “%@” proposal just looks like a bunch of unnecessary complication to me. A proto-exception object with methods can be just as easily (and lazily) constructed, and will map straight into a real exception, unlike this hash. And an object can always be used as a hash to access parameterless methods such as instance variable accessors. RFC: eval *The semantics of “eval” are, “clear $@ and don’t unwind unless the user re-dies after the “eval”". The semantics of “try” are “unwind after “try”, unless any raised exception was cleanly and completely handled, in which case clear $@”.* *In the author’s opinion, both “eval” and “try” should exist in Perl

Duration : 0:6:33

[youtube 940LkjBU7Xw]

Who'da think it » thunk function

@triciaho asks: Is there a paste into in Illustrator CS4 ?

p6apclps #44 Perl 6 Apocalypse