meik.michalke at uni-duesseldorf.de
Fri May 12 22:35:44 UTC 2017
Am Freitag, 12. Mai 2017, 18:37:44 CEST schrieb René J.V. Bertin:
> But you mention students ... shouldn't they rather be using the commandline
> or script files, you know, to get hands-on experience with what's going on
> behind those fancy dialogs? ;)
the concept of RKWard is that you can always see all the R code that will be
run if you submit the dialog; there's a code window below the actual dialog,
and the R code you see changes instantly when you change settings in the
dialog. this gives people with no experience in programming a feeling for it.
its not about hiding complexity, but to build a bridge for new users.
i think we also found an amazing way for more advanced users to extend
RKWard's functionality. i wrote an R package called rkwarddev which lets you
write new GUI dialogs in form of an R script and package the result as a
simple R package to share with others. thomas did a great job designing RKWard
as being plugin-based from the start (all shipped dialogs are actually plugins
that are pre-installed).
> > everything from 5.6 onward should do -- says the webpage ;-)
> I forgot, there's also a Qt56 port, if the LTS release is good enough for
downgrading to stock Qt 5.6 was the key! which means the instructions should
either not just say "Qt >= 5.6" but rather "Qt == 5.6", or the configuration
should check more carefully, given that Qt 5.8 obviously is no longer downward
compatible with Qt 5.6.
but kate compiled fine and works well!
> As I said, I don't know if an installer package created with MacPorts will
> mess up an existing MacPorts install.
yet, it will. it will overwrite everything in its way without MacPorts
noticing it. the policy to not make installers write to the standard MacPorts
directory is explicitly demanded so in the MacPorts docs. it wasn't something
we came up with ourselves ;-)
> > but the thing is, MacPorts puts literally everything into the bundle that
> > is a dependency of dependencies, that's how we end up with >>1GB for an
> > installed
> That's because the package is created to allow installing from scratch.
> Somewhere down the line a dependency claims a dependency on ffmpeg (that
> could well be libVLC or else phonon-backend-gstreamer), and there you go.
yes, i absolutely understand process behind it.
> You can do `port rdeps foo` to get a recursive tree of all dependencies,
> that allows you to figure out where the big unexpected (non-)dependencies
> come from. Sometimes you can get rid of them by installing their dependent
> with a variant.
i think the bundling mechanism in MacPorts doesn't really care so much about
variants, it just creates a collection of the defaults.
> > package. for just using RKWard, clearly only a fraction of that is needed,
> > and i've actually already removed ports from the bundle semi-manually to
> > make it smaller. e.g., we're pretty confident we don't need ffmpeg for
> > statistics...
> No (unless you want to be able to input audio or video data, maybe? 8-))
> Isn't there a way to build a package that contains only a specific port?
> You'd need to figure out how to create the required packages, and a script
> that installs them in the right order, but that's largely something you
> only have to do once.
i would like to explore the craft way an see where it leads. i'd rather only
consider a script-driven workaround if that doesnt' work out.
viele grüße :: m.eik
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at d-40204 d"usseldorf
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: This is a digitally signed message part.
More information about the kde-mac