My personal advantage is that I get subscription fees regularly. It's a very tiny portion compared to my main income, but let's say I would do this for a living. With the subscription model, I can constantly push bug-fixes or new features as soon as I have them. I don't need to work towards a major version where I need to think about bundling all the things I worked on to make it worth a major version.
The advantages for users are obvious:
- you can always use the latest version of the plugin
- you can test features from early on and we can find bugs fairly fast. Compare this to Mathematica, where we had horrible bugs in the past with a new version that staid there for half a year or more.
- you pay a small fee each month and can cancel the subscription at any time
DirectedEdges is completed as a function, not as a symbol. I'm not sure why.
Compare
Normalized which is completed without showing [] at the end:
Strangely,
Normalized does not show a context, even though it should be System context.
This is true for anything that's not treated as a function
$RecursionLimit also does not show a context.
It's pretty bright here today so I can't see well with Darcula. I'll switch back after sunset. I really wish for an automatic theme switcher :)
In[303]:= Options[DirectedEdges]
Out[303]= {"ArrowheadsSize" -> Automatic}
That must be a bug!
I'll ask Kyle
Then I need to re-check all the symbols, usage messages, contexts, etc..
@halirutan Hi, thanks for taking the time to answer, I guess I will make an exception and subscribe in spite of how much I hate subcription monetisation models, partly because I wanna say thanks for all the unpaid work so far.
But I really realy don't want them, if, in the future, it becomes unaffordable to me, I might be locked out of a significant investment in terms of learning how to learn the plugin
But I really realy don't want them, if, in the future, it becomes unaffordable to me, I might be locked out of a significant investment in terms of learning how to learn the plugin
The Gitter desktop app is not working at all for me today. Generally, Gitter has been unrealiable recently and it stopped sending me emails a long time ago. Anyone else having problems?
In any case, you can always write me in our Mathematica Slack in the plugin channel. I just invited you.
@eduardoofthehour Have you seen this here: https://plugins.jetbrains.com/docs/marketplace/licensing-schemes.html
Yearly/monthly subscription with a fallback license
That basically means that each version you used for a whole year (speak, you paid for it a whole year) will be used as a fallback. However, I don't if this is already available for plugins.
@oscu0 Here is how it's done in a few seconds: https://wlplugin.halirutan.de/docs/installation/#using-eap-beta-releases
@adamhill One major point for going to Slack is not that Gitter is bad. It's that I'll go crazy otherwise with all the different chats :)
Just to give you an impression: (1) The Wolfram chat and my workchat is RocketChat, (2) Jetbrains developers; our own Mathematica chat; Kotlin; and a few more are on Slack, (3) JabRef, Rubi, and currently this is on Gitter, (4) all StackExchange things are on the StackExchange chat..
Just to give you an impression: (1) The Wolfram chat and my workchat is RocketChat, (2) Jetbrains developers; our own Mathematica chat; Kotlin; and a few more are on Slack, (3) JabRef, Rubi, and currently this is on Gitter, (4) all StackExchange things are on the StackExchange chat..
So to be clear: I'm not abandoning this Gitter channel completely, but I don't check it daily. Since @szhorvat, my main tester and fellow sufferer of Wolfram bugs, is also on Slack we moved the discussions for the upcoming 2020 release there since my Slack client is running anyway.
We use Slack really as a chat and everything that needs to be preserved is properly documented. The nice thing with our Wolfram Language Slack is that it's a general chat and the IntelliJ plugin is only one part of it. You'll find a lot of experts there like Anton Antonov (recent WRI streams about statistic), Axel (developer of Symja), Cory Walker (developer of Expreduce), Robert Jacobson (expert on Wolfram Language syntax, who works on the Wolfram Language Spec), and Szabolcs Horvat (developer of LTemplate and IGraphM). Just to name a few.
@szhorvat Hi Szabolcs ... Thanks for the message on LinkedIn .. I do not have your email address so please contact me on sydgeraghty@mac.com Cheers ... Syd Geraghty
Hi @halirutan, first of all thanks for the great product. I'd like to add a run configuration for my .wls file in Idea, but it doesn't offer anything wolfram-related in the run configuration templates. Or do I need to add the SDK first (which I did not succeed in, maybe because of #184?)
@ullika Hey. Sorry for the long response time, but I don't visit Gitter that often anymore. We moved to Slack and you can find the link for that at the very bottom of https://wlplugin.halirutan.de/
You're correct that we don't have dedicated run configurations for Mathematica and one of the main problems here is that Wolfram never documented how to interact with the front end like it is done in the "Wolfram Workbench". I asked over 4 years ago if Wolfram would consider open-sourcing the Workbench so that we can look at the implementation. No definite answer so far and I've lost hope, to be honest.
However, you are dealing with a Wolfram Script that has a shebang (
#!/usr/bin/env wolframscript) and can be started from the console by typeing e.g. ./myscript.wsl. So it behaves like a normal shell script and IDEA has a run config for that. Have you tried creating a new run config and choosing "Shell Script"?
If you run into problems, I could create a small demo because I'm pretty sure that should work.
Here is the run config
Hi everybody! We're currently having a kind of conversation with @szhorvat about support for "new-style" packages at https://mathematica.stackexchange.com/questions/256545/does-workbench-support-new-package-format?noredirect=1#comment639688_256545
Thanks to @szhorvat I now know how to make navigation work in multi-file packages (add some information like fun::usage="....")
But new-style contains enough info to get without this. Is it possible to use PackageExport/PackageScope tags instead?
Probably @halirutan could answer