And since V5.2 had to rebuild all my stuff again and again because they indroduced all the image processing which we already had. Everything clashed, etc.
I'm interested, but I'm busy, and when I'm busy I become lazy with everything that I have to do. But I also don't do other stuff because I should be doing what I have to
Anyway, I have no practice or big background but get the idea of the image processing ordinary functions, but I have no clue about the "morphological" functions
It's a hard one to earn, because some users like to sit on their questions for months before accepting an answer, thus narrowing/eliminating any advantage there was
The undocumented System`Dump`showStringDiff function neatly does the diff and highlights it for you. The simplest usage is:
System`Dump`showStringDiff[text1, text2]
You can choose custom colours for the highlights with the Styles option. You can also change the background, font weight, add a...
@Rojo Yes, it is. As long as you keep in mind that image proc is hard math when it comes down to the facts, then this is maybe the best introduction there is.
But you can always study the detailed math later, after having some fun.
@Rojo Hehe... this is the answer (note that the OP drastically changed scope afterwards, hence the difference between the two answers). Daniel needs 2 and I need 2
Rojo wants to know "some programatic way of knowing some style's settings". I know. It's even documented! See the 6th bullet point in the CurrentValue documentation.
@JohnFultz We were discussing the following: Especially you leak from time to time very, very usefull undocumented functions. If this does not conflict with your Wolfram NDA, wouldn't it be possible to give us some hints whether there is a way to, let's call it explore undocumented stuff ourselves?
@halirutan, well working for WRI for 19 years comes with some privileges. :) But there are some real issues with some of the undocumented stuff. My biggest concern is that some of it isn't very well designed. Either we might replace it later with something much better designed, or it might be functionality which is prone to crashing because it doesn't have very good error-handling.
For example, right now, we're looking at shipping some functionality in v9 which will enable background images in notebooks (which would answer one of the unanswered SE questions, I noticed last night). Enough functionality is turned on to use in slide shows, and it'll be really neat. The problem is, it was introduced late enough that the design was not vetted, and I already know the design is not up to usual Wolfram standards. So, what to do?
We could not ship the slideshow functionality. We could lock ourselves into a bad design. We could delay v9 to fix up the design. Or we could go ahead and use it internally now, but knowing that users will really want to do this themselves, we'll plan to fix up the design in the future. From my perspective (yours may differ), the last option looks good.
yes, I see the point. But in the case of the tokenizer for Input-cells I tried every possible thing.. Especially to keep the non-semantic whitespaces and then BOOM, you come and solve everything with one answer.
Of course, some of the undocumented functionality just never becomes interesting enough for more than just a few users. So it languishes and never gets designed or exposed in the System` context.
Concerning the UndocumentedTestFEParser packet, that was actually added for QA purposes. It makes adding a test harness easier. I guess I wasn't imaginative enough to consider that real-world users would be seriously interested in this. My bad.
@JohnFultz And basically, I'm aware that those things maybe introduce bugs but it's better than having nothing. And as I said to @Rojo, it's not that I want to write long-lasting software I want to sell..
@JohnFultz We had to hack the tokenizer for this site from scratch by guessing and there is still no highlighted LaTeX-export of code snips from Mma. UndocumentedTestFEParser really saved my day.
And as you might have seen Leonid started a code formatter project.
Thanks a lot, let's see :). Also there's one old question that I believe you might know something very simple that would help a huge lot. It's about programatically getting some current counter value at the place where it is executed. mathematica.stackexchange.com/q/6073/109
But, something you should understand about packets. You can really mess up a front end if you send bad stuff through to the packets. The bar for input validation isn't as high, and in the worst case scenario, it's not too difficult to crash the FE or to mess up the MathLink connection between FE and kernel.
BTW, I saw on the chat session yesterday some confusion about stuff in the FrontEnd` context. As some have guessed, the FrontEnd` context is generally (can't remember if it's exclusively) used as an inert context. So, for example, look at EvaluationNotebook:
The FE packet has the same name as the kernel symbol. But we can't have it evaluating out from underneath us, and it's stupid to give it a different name. So the FrontEnd` context is a totally inert version in the kernel.
In fact, the FE doesn't really care whether the packet has Global` or System` or FrontEnd`, but it makes it much better when writing kernel code to use FrontEnd`.
@halirutan, the crazy thing is that you must be like the 20th person or so to have done this. At one point, I suggested that we release a YACC grammar for CDF (which would be a significant subset of the Mathematica grammar), but the idea wasn't well received by various parties.
Internally, I can think of at least six notebook parsers running around (I wrote three of them!). :) And then the full Mathematica grammar is implemented, separately, in both FE and kernel, as well as various syntax coloring engines (yours is far from the first, but I think it's the only contemporary one besides the one in Workbench).
@JohnFultz I assumed something like that. Is there anything we or I can do (someone to ask beside the support) to maybe make Wolfram release some form of grammar?
Because the tokenizer is of course only one step. What really would be nice is an annotated abstract syntax tree which connects the parsed full form to the input string.
The funny thing is, we already have something like that!
TreeForm gives the structure of the code while the tooltips show exactly on which portion of the input-code you are looking ;-)
@halirutan I think there are two issues here. One is the level of effort required. Constructing and maintaining an AST is non-zero effort on our part. And the grammar as implemented in the FE and kernel are tightly integrated...very difficult to extract. Fortunately, we're at least documenting precedences, so most of it could be reconstructed, but painfully, I'm sure.
Second is the concern about whether we're giving something away that could reduce our competitive advantage. I personally don't think too hard about the second issue, but other people do (and, yeah, it'd be kind of irksome if some open-source competitor adopted code we produced purely for purposes of making their product look better when compared to ours).
But the good news is that, as announced at the WTC, we're now beginning to put stuff on GitHub (first project, HadoopLink). When time permits, I should ping folks again about this sort of activity.
BTW, I saw some talk on here about sniffing traffic between the FE and kernel. Are you folks using LinkSnooper? Or do you even know such a thing exists? We use it all the time internally, but I'm not sure how much it's been discussed externally.
@Rojo, what I did yesterday was that I started a MathKernel and used this one to evaluate things from the front end. All the traffic was printed. This all is described in the book of Wagner.
@halirutan You mean a question about the packet list or something else? Well, free reputation is always nice. I've left a lot of it lying on the floor, I think. :)
@halirutan I work on all the FEs. But my attention is certainly less on the Linux FE, market realities being what they are. That having been said, we use the Linux FE on the Wolfram|Alpha servers.