Wolfram Mathematica

Welcome! This is the main Mathematica chat room for mathematic...
Oct 14, 2018 2:06 AM
@b3m2a1 Definitely not 2018. Beyond that, I just don't have enough information to commit to any timeline, yet.
Oct 12, 2018 5:50 PM
(referencing conversations happening about two days prior to this post)
Oct 12, 2018 5:50 PM
Re open source/future of the language concerns...just FYI that I've been pushing for work on a proper package repository, and some of the things that such a repository would depend on, like better namespace handling, better documentation tools, standards/tools for assembling/deploying packages, etc. Not going to see much from this this year, but it will happen. If anybody wants to chat me up...here or at the conference or wherever, I'd love to do so.
11
Apr 24, 2018 1:40 PM
@halirutan Even for thousands of symbols, I'm not convinced it should be taking any noticeable time. An appropriate fix may make your request unnecessary. But we'll see.
Apr 24, 2018 1:37 PM
@Szabolcs if you're referring to Code cells and manual indentation, I'm well aware that this could be made much better. If you're referring to the auto-indentation provided by Input cells, I don't think I've seen what you're talking about, and a better explanation would help.
Apr 24, 2018 1:32 PM
@Mathe172 I've seen this myself and it doesn't make me very happy. I'll look into it.
Apr 19, 2018 8:55 PM
I thought about echoing my thoughts on Twitter, but as has been mentioned, Twitter is just a terrible place for civil or useful discussion. Obviously, I have a much higher opinion of this chat room. There...off my chest, and now back to work. :) Feel free to call me out on any place where you think I'm out of line, here or elsewhere.
Apr 19, 2018 8:53 PM
But being accused of introducing a bug "so bad that someone must have worked at making it bad" as an accomplice to "an intentional, hidden part of Wolfram’s strategy"? That hits home a bit. In my life, I've been wrong, I've been stupid (there seems to be no end of that!), but I try very hard to be honest.
5
Apr 19, 2018 8:52 PM
Re the Romer post, I think the open source/commercial debate is a fine debate. I do both, and I certainly see upsides each way. But I have to put some personal pronouns in Romer's post because he discusses a bug in my area. I find the notion of being called a "Vandal" and contributing to "objective truth [perishing] from the Earth" to be amusingly hyperbolic. The notion that I "hide behind corporate evasion"...well, I leave that to the judgment of this community.
Apr 19, 2018 8:36 PM
@Szabolcs, what do you mean by "cell type"? Certainly, you could modify the Input and Output styles. You could also modify the StandardForm style, which would catch several sorts of things (including, e.g., Message and Print cells).
Apr 16, 2018 10:54 PM
That's a slightly abstract explanation...I don't know, maybe confusing. I know how I intend for this to work in the future, but I haven't really written it up well, yet.
Apr 16, 2018 10:52 PM
I think of this as kind of being the "y axis of stylesheets", where the x axis follows normal inheritance rules, but the y axis defines an orthogonal inheritance that you can use to cut across stylesheets in whatever way you choose. I believe old Java programmers would refer to this kind of cross-inheritance cutting as an "aspect".
Apr 16, 2018 10:51 PM
All of these styles could have inherited from a common "CodeParent" style, but then you'd have to edit the stylesheet to change it. Whereas now, with StyleHints, you can make it be a global setting that's easily changed from one user's preferences to the next.
Apr 16, 2018 10:50 PM
A clearer example would be with the "CodeFont" setting. Where you want "code-ish" styles to use the "CodeFont", while other styles maybe should have no opinion at all about fonts (like the "TraditionalForm" style), and should definitely not be inheriting some global setting of, e.g., FontFamily->"Source Code Pro".
Apr 16, 2018 10:50 PM
E.g., think about the times when you might have wanted to change something, but what you really wanted to do was to get 20 styles to obey your global setting while not messing up hundreds of styles you definitely didn't want to touch.
Apr 16, 2018 10:48 PM
@Kuba, the reason for using the StyleHints mechanism is that cell group openers is a place where stylesheets have definite opinions, and we don't want to subvert those opinions. OTOH asking people to edit stylesheets in place of using a preferences dialog isn't very friendly. So the StyleHints mechanism is a way of taking a global opinion about how things should be done and importing it into selective places in the stylesheet.
Apr 16, 2018 10:43 PM
@Kuba, an inline closer is coming in the next version per popular request. The thinking was that it might be ugly/annoying to have closers everywhere, but the current plan is to only show closers on groups where you opened them with the openers. That plan may or may not survive the fire of testing.
Apr 16, 2018 10:02 PM
@Kuba, yeah I just independently realized you might still have a prerelease installed. Re `StyleHints`, try something like `CurrentValue[$FrontEndSession, {StyleHints,
"GroupOpener"}] = "OutsideFrame"`. This is what the preferences dialog does (except on `$FrontEnd` rather than `$FrontEndSession`). I've been a bit loathe to advertise this because there are some inheritance issues that aren't 100% worked out, yet (but don't really cause problems at the current level of usage).
Apr 16, 2018 9:15 PM
@Kuba, I'm not seeing the updated docs in 11.2, but they're not in 11.3 and should have been. Oops...this is my oversight. Fixing it now.
Dec 19, 2016 2:20 AM
@MikeHoneychurch ...which is why you probably won't see that version of the answer from TS. I think somebody else relayed a version to TS a bit closer to what you were looking for.
Dec 19, 2016 2:14 AM
@MikeHoneychurch I did catch this question and I said there wasn't a way...but I just looked again, and it looks like AutoScroll->Top works for NotebookFind. Or you can use NotebookLocate on a cell tag. These don't lock to the very top, but top-ish (assuming the scrollbar can be moved that far, of course).
Dec 19, 2016 2:06 AM
@Kuba let's try that reply again..
Dec 19, 2016 1:59 AM
:34149329, the MessagesWindow style is hard-coded to be used for the messages window. But you can, of course, set private or public stylesheets with settings for the Notebook prototype style on any notebook you like. So, I'm confused by your question.
Dec 16, 2016 2:17 AM
@Kuba There is a style called "MessagesWindow". It is like the notebook prototype style in that you can attach some options which are typically only relevant at the notebook level, and they will be used. Like, in this case, DockedCells.
Dec 13, 2016 5:38 AM
Bah. My inability to do anything useful in chat makes me feel considerably less clever.
Dec 13, 2016 5:30 AM
Tech support forwarded a question from an individual hoping to add timestamps to messages.  I came up with an interesting technique which amuses me, in part because thinking of it made me feel clever, and in part because it relies on one of the most hated options in the system.  Paste the following cell into a private stylesheet for a given notebook, then start creating messages...
Cell[StyleData["Message"], CellFrameLabels->{{Cell[BoxData[FormBox[DynamicBox[ToBoxes[DateString[First[Flatten[CurrentValue[ParentCell[EvaluationCell[]], CellChangeTimes]]], TimeZone -> 2 $TimeZone], StandardForm
3
Oct 27, 2016 3:26 PM
@Szabolcs see this example (Github) in GitLink for how to hint completions for filenames (and directory names is equally easy...the codes are documented in that file). It's not pretty, and it's not documented, but it will continue to work because we have a lot of internal stuff that relies on this.
Oct 26, 2016 7:39 PM
@Szabolcs In general, Kuba's got the right approach, and I wouldn't dispute it. Re maintainability, I would encapsulate this functionality in an inner Dynamic, which would allow the entire implementation to be rewritten at a later time with perhaps improved capabilities in a future version. Which is the sort of thing Lou covers in his talk.
Oct 26, 2016 7:18 PM
@Szabolcs Yes, it should have been 10.4 and later. The code did the right thing...I just wrote it incorrectly in the docs. Now fixed.
Oct 26, 2016 7:11 PM
@halirutan , I hope so, but I'm honestly not sure which talks were videoed and which weren't.
Oct 25, 2016 7:06 PM
My favorite talk at the Tech Conference was Lou D'Andria's "Building Maintainable Dynamic Interfaces". Unfortunately, I didn't have time to attend a lot of talks, but Lou's talk directly hit some of the questions occasionally raised here about how to develop sophisticated and robust controls.
2
May 28, 2016 12:10 AM
Hello, @Mr.Wizard. I had to resist adding an "aw shucks" response to your last comment in my direction. :)
Jul 7, 2014 1:25 AM
@halirutan To be honest, I haven't had to solve that problem. The FE has to do a faithful parse of Mathematica syntax to expressions, and it has a mini-evaluator which knows how to evaluate a subset of those expressions. But the FE completely passes on the issue of handling DownValues assignments. The one place where you might think this would happen in the FE, in DynamicModuleBox instead relies exclusively on synchronization with the kernel. So, sorry...out of my expertise.
Apr 30, 2014 3:07 PM
@halirutan I hadn't tried the plugin...was just reading your chat text above (which I now assume was a typo based on your screenshot).
Apr 30, 2014 3:03 PM
@halirutan And this may have just been a typo on your part, but we don't consider variables in Rule localized. Inside of RuleDelayed, yes, but not Rule. E.g., see syntax coloring on a_:>a as opposed to b_->b.
Apr 30, 2014 3:01 PM
@halirutan The FE has all of this, too...that's how syntax coloring works. It is enough info that, in principle, implementing renaming of localized variables would be straightforward. We just haven't done so, yet. But if I have my way (which is no guarantee), we're going to push very hard into making the FE a much more posh programming environment down the road.
2
Apr 30, 2014 2:52 PM
@halirutan But from what I see on the web page, it looks pretty impressive. So congratulations on that.
Apr 30, 2014 2:52 PM
@halirutan The editor there is doing much less work overall. It's not an entirely fair comparison. That's not to say the FE shouldn't be faster/better. And that's not to say that all of the FE's features have a value exceeding their performance cost in large cells. Those are subjective questions, and I'm not going to argue those merits (or lack thereof). But it is objectively true that this editor is just doing a lot less than the FE does.
Apr 30, 2014 2:44 PM
But I have been pushing very hard to make the computation of the popups not slow down typing. I admit this was not in very good shape in 9.0.0, but it was in considerably better shape in 9.0.1, and hopefully even more in 10. Predictions, on the other hand, don't slow things down that much. No computational effort (of any significance) goes into predictions until immediately after evaluation has completed.
Apr 30, 2014 2:42 PM
I'm not sure that trying to move line-breaking out to a different thread than typing would be fundamentally helpful. I think there are better strategies there (principally, don't globally optimize line-breaks in a cell). But the completion and assistance popups would definitely be handier in a separate thread.
Apr 30, 2014 2:40 PM
For example, in v10 I rewrote our crazy Unicode font system designed when almost nobody was doing Unicode fonts. One would think this would have been easy since every operating system does this today, but replacing stuff without breaking functionality had wide-spread consequences, including the necessity to completely rewrite our PDF and SVG exporters.
Apr 30, 2014 2:40 PM
@halirutan Yes, what you're talking about would be a fairly fundamental rewrite. The advantage of 20 years of legacy is that it solves a lot of user problems very well. The disadvantage is inertia. We're making progress on inertia issues, but it can be pretty painful.
Apr 30, 2014 2:17 PM
@halirutan Okay, I don't know exactly what's causing the slowness. But perhaps you'll be happy to know it is much more responsive in v10 than v9.
Apr 30, 2014 2:15 PM
@halirutan you're referring to the slowness in the resolving of the Mouseovers?
Apr 30, 2014 2:13 PM
Also, I found that one thing that potentially slowed down editing was the setting of InputAutoReplacements. The FE spends a lot more time than it should resolving the ParentList value of that option. On every keystroke. In certain inputs I discovered, this was the dominant slowness, at least in v10...I assume it would be in v9, as well. That issue is fixed in v10.
Apr 30, 2014 2:11 PM
@halirutan LineBreakWithin->False
Apr 30, 2014 2:07 PM
@halirutan You could turn off line-wrapping completely. Or do you still want line-wrapping, but dumber/less automatic? There's nothing like that.
Apr 30, 2014 2:06 PM
Folks may be interested to know that I've spent a decent amount of time over the last month working to speed up typing in large cells in v10. I'm not going to claim to have fixed all problems. And I certainly have not fixed slowness which stems from the large systemic issues (the two big ones being the global line-breaking algorithm and slowness from reparsing the entire cell with every keystroke). But there were several individual things that piled on and were easy to fix, once identified.
Apr 29, 2014 3:54 AM
@JacobAkkerboom Concerning your statement a couple of days ago about whether I thought combining Dynamics and ScheduledTasks were a good idea...it's something we do internally and not something I have a fundamental problem with. I'd advise caution, simply because the combination can give you more rope to hang yourself, but used well the combination could be powerful.
Sep 12, 2013 6:41 AM
@Kuba, Added (see comment to Rolf's answer). I really don't like to post that kind of stuff in an answer, though. It just seems capricious to give an answer that says it's a fixed bug, but no sorry, you can't actually get the version it's fixed in because it's in beta.