| #include <sys/types.h> | |
| #include <sys/ioctl.h> | |
| #include <sys/socket.h> | |
| #include <sys/sys_domain.h> | |
| #include <sys/kern_control.h> | |
| #include <net/if_utun.h> | |
| #include <errno.h> | |
| #include <stdio.h> | |
| #include <string.h> | |
| #include <syslog.h> |
| using System; | |
| namespace LibNative | |
| { | |
| using System.Runtime.InteropServices; | |
| public static partial class libnative | |
| { | |
| /// <summary> | |
| /// |
| ''' Jeremy's test script - 28 Mar 2020. | |
| It creates two threads and waits for both to finish before presenting the results. | |
| Each thread generates random data, but data that is similar to what is expected from the sensor devices. | |
| The results are added to the queue, removed, then presented to the user. | |
| Not completed: writing to ''' | |
| import queue, threading, time, random, math, numpy, sys |
Since the recent release of Catalina, macOS has shipped with the ability to allow iOS/iPAD apps to run on macOS without any modification via a featureset known as Project Catalyst.
This is exciting, as writing React Native + Clojurescript apps as a target for the desktop is much more compelling than a pure Electron app (imo).
| [Unit] | |
| Description=IPv4 DHCP server on %i | |
| After=network.target network-online.target | |
| Wants=network-online.target | |
| [Service] | |
| Type=forking | |
| ExecStartPre=/usr/bin/touch /var/lib/dhcp/dhcpd@%i.leases | |
| ExecStart=/usr/bin/dhcpd -4 -q -cf /etc/dhcpd.conf.d/%i.conf -pf /run/dhcpd4/dhcpd@%i.pid -lf /var/lib/dhcp/dhcpd@%i.leases %i | |
| RuntimeDirectory=dhcpd4 |
| vector_clj/core$i256_add.invoke(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; [0x000000011f8acdc0, 0x000000011f8ad058] 664 bytes | |
| [Entry Point] | |
| [Constants] | |
| # {method} {0x000000013253d3b8} 'invoke' '(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;' in 'vector_clj/core$i256_add' | |
| # this: rsi:rsi = 'vector_clj/core$i256_add' | |
| # parm0: rdx:rdx = 'java/lang/Object' | |
| # parm1: rcx:rcx = 'java/lang/Object' | |
| # [sp+0x30] (sp of caller) | |
| ..... | |
| 0x000000011f8acec3: prefetchw BYTE PTR [r10+0x180] |
| #include <sys/types.h> | |
| #include <sys/ioctl.h> | |
| #include <sys/socket.h> | |
| #include <sys/sys_domain.h> | |
| #include <sys/kern_control.h> | |
| #include <net/if_utun.h> | |
| #include <errno.h> | |
| #include <stdio.h> | |
| #include <string.h> | |
| #include <syslog.h> |
ClojureScript master now has cljs.core/eval. This delegates to cljs.core/*eval* which, by default throws, but you can bind it to any implementation that can compile and evaluate ClojureScript forms.
If you require the cljs.js namespace (which is the main support namespace for self-hosted ClojureScript), then cljs.core/*eval* is set to an implementation that uses self-hosted ClojureScript for this capability. This means that all self-hosted ClojureScript environments will now have a first-class eval implementation that just works. For example, Planck master:
$ planck -q
cljs.user=> (eval '(+ 2 3))
5
Using JavaScript libraries from ClojureScript involves two distinct concerns:
Right now, the only single tool that solves these probems reliably, optimally, and with minimal configuration is shadow-cljs, and so that is what I favor. In paricular, shadow-cljs lets you install npm modules using npm or yarn and uses the resulting package.json to bundle external dependencies. Below I describe why, what alternatives there are, and what solutions I disfavor at this time.
| ;;;; Fressian dependency used in these examples | |
| ;; [org.clojure/data.fressian "0.2.1"] | |
| ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; | |
| ;;;; Using only `org.clojure/data.fressian` | |
| (require '[clojure.data.fressian :as fres]) | |
| (defn serde-obj |