I've been absolutely loving the Hy REPL. However it would speed up my workflow immensely if I could have a set of default imports at startup. Clojure has a way of configuring startup imports via leiningen config. Currently I load the repl this way:
path/bin/hy --repl-output-fn=hy.contrib.hy-repr.hy-repr
Similarly is there a way I can reset all imported modules from the REPL namespace without having to restart the REPL ?
Proper initialization scripts are not yet implemented. In the meantime, you can do things like
hy -i '(import math re pandas)'
or
hy -i '(import [my-init-package [*]])'
to run some code of your choice before starting the REPL.
Related
I'm trying to use the lightning fast swc compiler in tsc-watch, but it does not seem to parse it properly. I've tried various locations in #swc/cli and #swc/core, but to no avail.
I've also tried using ts-node, which has a configuration option for swc, but this also doesn't appear to work.
Here's the script I'm trying to run:
When running this, it prints the command and then stops.
Before start describing how I'm getting this error, here is some important information:
It is essential the usage of the module-info.java in my project since jpackage won't work without using it.
I'm using SDK 14.0.2 (this is the minimum version that enables the usage of package)
Every comment will be appreciated; although, if you're going to comment something related to using a specific VM argument, I ask you to press ctrl+F to check if I'm already using the argument you're going to suggest -since there's a bunch of VM arguments in my build.gradle-
Ok, let's take a look about my issue:
First, focus on the VM argument below:
"--add-opens=java.base/java.lang.reflect=com.jfoenix",
If I don't use this argument, the following error pops up when the program runs:
java.lang.reflect.InaccessibleObjectException: Unable to make boolean java.lang.reflect.AccessibleObject.setAccessible0(boolean)
accessible: module java.base does not "opens java.lang.reflect" to module com.jfoenix
IMPORTANT -> This is how my view shows without using the mentioned VM argument (let's call it image 1):
https://snipboard.io/QJ5Fdc.jpg
"Ok, so why don't you just use the VM argument?"
Great question! Alright, let's add it to my VM arguments and run the program once again.
After doing so, this is how my view looks like right now (let's call it image 2): https://snipboard.io/fbhGxw.jpg
Great! This is exactly how my view should be (note that considering it worked as expected, I've got no errors this time).
So, with everything working, I can finally move on and run my jpackage gradle task. After doing so, things stop making sense, since after executing my program through a .exe (generated by jpackage) my view looks like the "image 1" view, regardless the fact that my project is working properly when I run it with the "run" gradle task.
Any thoughts on why is this happening? (My guess is that my module-info.java is the key to solve it, since every time I remove an "opens" statement, e.g.: "opens my.package.name to javafx.fxml", the program gets me almost the equal error).
Let me know whether any code samples will be needed. All assistance will be appreciated. Thanks!
edit: related GitHub issue: enter link description here
I don't know how the jpackage gradle task works, I use the jpackage tool inside the jdk via console and I used this arguments when creating the package
--java-options "--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker=javafx.fxml --add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.colorpicker=javafx.fxml"
In there I opened the PaintPicker from scene builder kit to javafx.fxml
As you can see I had to open two packages (they were really five but its too much to put in here) and you have to specify --add-opens for each package to open
I'm putting the code y used to package the application using jpackage
jpackage.exe
--module-path
.;D:\builds\ikonlibrowser\target\ikonlibrowser.jar;
D:\builds\ikonlibrowser\libs\icons\ikonli-antdesignicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-bootstrapicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-boxicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-bpmn-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-captainicon-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-carbonicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-codicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-coreui-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-dashicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-devicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-elusive-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-entypo-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-evaicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-feather-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fileicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fluentui-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fontawesome-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fontawesome5-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-fontelico-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-foundation-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-hawcons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-icomoon-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-ionicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-ionicons4-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-jamicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-ligaturesymbols-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-lineawesome-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-linecons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-maki-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-maki2-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-mapicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-material-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-material2-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-materialdesign-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-materialdesign2-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-medicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-metrizeicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-microns-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-ociicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-octicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-openiconic-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-paymentfont-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-prestashopicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-remixicon-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-runestroicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-simpleicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-simplelineicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-subway-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-themify-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-typicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-unicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-weathericons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-websymbols-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-whhg-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-win10-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\icons\ikonli-zondicons-pack-12.2.0.jar
D:\builds\ikonlibrowser\libs\scenebuilder-kit-16.0.0.jar;
D:\builds\ikonlibrowser\libs\jfoenix-9.0.10.jar
D:\builds\ikonlibrowser\libs\ikonli-core-12.2.0.jar;
D:\builds\ikonlibrowser\libs\ikonli-javafx-12.2.0.jar
--module jcc.app.ikonlibrowser/jcc.app.ikonlibrowser.Main
--name "Ikonli Browser" -d D:\builds\ikonlibrowser
--win-dir-chooser
--input D:\builds\ikonlibrowser\app
--vendor jCC
--app-version "1.0.0"
--java-options
"--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker=javafx.fxml
--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.colorpicker=javafx.fxml
--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.rotator=javafx.fxml
--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.slider=javafx.fxml
--add-opens com.gluonhq.scenebuilder.kit/com.oracle.javafx.scenebuilder.kit.util.control.paintpicker.gradientpicker=javafx.fxml"
Of course this is only one line.
Now i'll explain it step by step:
--module-path This argument is used to specify the path for all the modules your app uses. Including the application .jar
--module This argument specifies the main class of the application. Putting first the module name and then the class full name.
--name This is to specify the app name.
-d Specifies the output path.
--win-dir-chooser Gives the option to select the installation path when installing the packaged app
--input Specifies a folder containing the external resources for your app
--vendor The vendor's name. Maybe your name
--app-version The version of your application
--java-options The jvm options
I hope it works for you, sorry for the delay.
I have an autotools project which successfully builds and tests an app (https://github.com/goglecm/AutoBrightnessCam). The app is installed in the bin directory (preceded by any prefix the user specifies). That's pretty straightforward. I now need to make a systemd service to start it at boot time. I've created the service file and ran it manually and it works fine.
The last bit is to tell configure.ac and Makefile.am to patch a *.service.in file with the correct path for the app (just like config.h is created from config.h.in).
Will using AC_CONFIG_HEADERS be appropriate to patch *.service.in into *.service? Is there another macro used for "non-headers" perhaps?
Also, how do I specify that the service file should land (i.e. installed) in /etc/systemd/system?
Is there perhaps a better way of starting this app at boot time without systemd?
How do I specify that the service file should land (i.e. installed) in /etc/systemd/system?
According to Systemd's daemon man page:
<BEGINQUOTE>
Installing systemd Service Files
At the build installation time (e.g. make install during package build), packages are recommended to install their systemd unit files in the directory returned by pkg-config systemd --variable=systemdsystemunitdir (for system services) or pkg-config systemd --variable=systemduserunitdir (for user services). This will make the services available in the system on explicit request but not activate them automatically during boot. Optionally, during package installation (e.g. rpm -i by the administrator), symlinks should be created in the systemd configuration directories via the enable command of the systemctl(1) tool to activate them automatically on boot.
Packages using autoconf(1) are recommended to use a configure script excerpt like the following to determine the unit installation path during source configuration:
PKG_PROG_PKG_CONFIG
AC_ARG_WITH([systemdsystemunitdir],
[AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files])],,
[with_systemdsystemunitdir=auto])
AS_IF([test "x$with_systemdsystemunitdir" = "xyes" -o "x$with_systemdsystemunitdir" = "xauto"], [
def_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)
AS_IF([test "x$def_systemdsystemunitdir" = "x"],
[AS_IF([test "x$with_systemdsystemunitdir" = "xyes"],
[AC_MSG_ERROR([systemd support requested but pkg-config unable to query systemd package])])
with_systemdsystemunitdir=no],
[with_systemdsystemunitdir="$def_systemdsystemunitdir"])])
AS_IF([test "x$with_systemdsystemunitdir" != "xno"],
[AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])])
AM_CONDITIONAL([HAVE_SYSTEMD], [test "x$with_systemdsystemunitdir" != "xno"])
This snippet allows automatic installation of the unit files on systemd machines, and optionally allows their installation even on machines lacking systemd. (Modification of this snippet for the user unit directory is left as an exercise for the reader.)
Additionally, to ensure that make distcheck continues to work, it is recommended to add the following to the top-level Makefile.am file in automake(1)-based projects:
AM_DISTCHECK_CONFIGURE_FLAGS = \
--with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)
Finally, unit files should be installed in the system with an automake excerpt like the following:
if HAVE_SYSTEMD
systemdsystemunit_DATA = \
foobar.socket \
foobar.service
endif
...
</ENDQUOTE>
So it appears you should use systemdsystemunitdir and systemduserunitdir. How well Autotools supports it, well...
A quick grep on Fedora 31 using grep systemdsystemunitdir /bin/autoconf and grep -IR systemdsystemunitdir /usr/share shows no Autotools support yet. 7 years and counting...
Is there perhaps a better way of starting this app at boot time without systemd?
Systemd should be OK to start your app. Simply use systemctl(1) to enable and start them as you normally would.
Based on your GitHub and autobrightnesscam.service.in, I would not dick around with Autotools for this. You can waste copious amounts of time working around Autotols short comings (speaking from experience).
My configure.ac script (which is just a shell script) would copy autobrightnesscam.service.in to autobrightnesscam.service, and then use sed to copy-in the correct directories and files. Then, I would copy the updated autobrightnesscam.service to its proper location in AC_CONFIG_COMMANDS_POST. Maybe something like:
SERVICE_FILE=autobrightnesscam.service
SYSTEMD_DIR=`pkg-config systemd --variable=systemdsystemunitdir`
# Use default if SYSTEMD_DIR is empty
if test x"$SYSTEMD_DIR" = "x"; then
SYSTEMD_DIR=/etc/systemd/system
fi
AC_CONFIG_COMMANDS_POST([cp "$SERVICE_FILE" "$SYSTEMD_DIR"])
AC_CONFIG_COMMANDS_POST([systemctl enable "$SYSTEMD_DIR/$SERVICE_FILE"])
AC_CONFIG_COMMANDS_POST([systemctl start "$SERVICE_FILE"])
Will using AC_CONFIG_HEADERS be appropriate to patch *.service.in into *.service? Is there another macro used for "non-headers" perhaps?
No. AC_CONFIG_HEADERS is for setting up configuration headers to support your build. It is rarely used for anything other than building a config.h recording the results of certain tests that Autoconf performs, and it is not as flexible as other options in this area.
If you have additional files that you want Autoconf to build from templates then you should tell Autoconf about them via AC_CONFIG_FILES. Example:
AC_CONFIG_FILES([Makefile AutoBrightnessCam.service])
But if some of the data with which you are filling that template are installation directories then Autoconf is probably not the right place to do this at all, because it makes provision for the installation prefix to be changed by arguments to make. You would at least need to work around that, but the best thing to do is to roll with it instead, and build the .service file under make's control. It's not that hard, and there are several technical advantages, some applying even if there aren't any installation directory substitutions to worry about.
You can do it the same way that configure does, by running the very same template you're already using through sed, with an appropriate script. Something like this would appear in your Makefile.am:
SERVICE_SUBS = \
s,[#]VARIABLE_NAME[#],$(VARIABLE_NAME),g; \
s,[#]OTHER_VARIABLE[#],$(OTHER_VARIABLE),g
AutoBrightnessCam.service: AutoBrightnessCam.service.in
$(SED) -e '$(SERVICE_SUBS)' < $< > $#
Also, how do I specify that the service file should land (i.e.
installed) in /etc/systemd/system?
You use Automake's standard mechanism for specifying custom installation locations. Maybe something like this:
sytemdsysdir = $(sysconfdir)/systemd/system
systemdsys_DATA = AutoBrightnessCam.service
Is there perhaps a better way of
starting this app at boot time without systemd?
On a systemd-based machine, systemd is in control of what starts at boot. If you want the machine to start your application automatically at boot, then I think your options are limited to
Configuring systemd to start it
Configuring something in a chain of programs ultimately started by systemd to start it
Hacking the bootloader or kernel to start it
There is room for diverging opinions here, but I think the first of those is cleanest and most future-proof, and I cannot recommend the last.
The Julia docs are pretty clear on how to enable debugging messages from #debug macros, i.e. run export JULIA_DEBUG=mymodule or export JULIA_DEBUG=all on the command line before starting Julia. However, is there an easy way to enable debugging from within the Juno, or, more generally, while Julia is running?
I tried fiddling with Base.CoreLogging.disable_logging , Base.CoreLogging.BelowMinLevel and Base.CoreLogging._min_enabled_level without success.
I know I can set env variables for Julia in the Juno settings. But that's kind of annoying to work with as it requires restarting Julia. I really want to have the following workflow while working interactively:
Enter a line in the REPL
Stumble upon a bug from your own code that you didn't see coming.
Enable debugging.
Run that line again.
See the debug logs.
Fix your code.
Disable debug logging again.
Which I think is nicer than the common practice of commenting and un-commenting printf everywhere.
Enable #debug everywhere (this will only affect code loaded after running the following expression):
julia>ENV["JULIA_DEBUG"] = "all"
Enable #debug in file foo.jl (according to docs, haven't tested this):
julia>ENV["JULIA_DEBUG"] = "foo"
Disable #debug:
ENV["JULIA_DEBUG"] = ""
important note: macros are evaluated when code is loaded. So the tricks above will only have effect on code that is loaded after changing the value of JULIA_DEBUG. So after setting it to e.g. all, nothing will have changed. Reload the modules you want to #debug.
To enable #debug messages logging in your julia script:
# ... script ...
ENV["JULIA_DEBUG"]="all"
# debug messages are now enabled.
# ... Rest of the script...
The addition of ENV["JULIA_DEBUG"]="all" will enable #debug messages when running the script in Juno or running it with Julia from your terminal.
I installed phantomjs and casperjs, created a new project with lein new mies casper-ghost and added the [ghost "0.1.0-alpha1] dependency to project.clj.
I then copied over the example code from https://github.com/casperjs/ghost to the core.cljs file and successfully compiled it, with ./scripts/build.
When I try to run it with casperjs out/casper_ghost.js it gives me the error:
ClojureScript could not load :main, did you forget to specify :asset-path?
ReferenceError: Can't find variable: goog
file:///usr/lib/node_modules/casperjs/bin/bootstrap.js:1 in global code
I tried creating a custom build script as follows:
(require 'cljs.build.api)
(cljs.build.api/build "src"
{:main 'hello-world.core
:output-to "out/main.js"})
And ran that successfully with lein -m clojure.main build.clj, but running out/main.js with casperjs would cause the same error.
Can someone point me in the right direction how to run the ghost scripts from the linux terminal?
Making the Google closure compiler write everything into a single file by using :optimizations "simple" to the build options did the trick.