Birds fly, sun shines, and TheBloke always delivers.
Though I can't figure out that prompt and with LLama2's template it's... weird. Responds half in Korean and does unnecessary numbering of paragraphs.
Just one big sigh towards those supposed efforts on prompt template standardization. Every single model just has to do something unique that breaks all compatibility but has never resulted in any performance gain.
Ah, I remember seeing this a long time ago. It seemed like something CL fans would enjoy, but to me it felt verbose. I guess this is my Clojure preference showing.
Regarding runtime macro-expansion - since Dak is written in JavaScript, it comes for free.
Nice! My goal in Dak is to reach a point where macros can allow transforming hiccup like syntax to hyperapp or React like function calls, or original hiccup style optimized string concat, or lit-html style template string generation. I know I could use all these for different use cases.
My fear taking this path is around performance. I've not done any profiling yet, and I'm hoping I don't regret taking this path when I get around to it.
I'm a huge fan of Clojure and have had a lot of fun building things with it. CLJS on the other hand has felt heavy to me, from a browser performance and dev tooling perspective. Clojure startup time always affected me more so with CLJS projects. I hope these two projects alter the landscape for the better!
Besides those aspects, Dak is different than these two specifically in that it tries to provide something closer to a minimal 1-to-1 language feature mapping to JavaScript as the base, with a goal of having essentially no runtime.
The clean room implementation has downsides - Squint and Cherry can reuse Clojure tooling like clj-kondo etc, which Dak cannot. On the other hand Dak is small, the transpiler is under 2k lines as I write this. It can run on virtually any modern JavaScript runtime (all browsers, node, deno, bun etc).
Safety for me is confidence to use the thing. For me in my own code, but also others on my team that may work on this code.
I mostly have experience building things in GC languages. But with Rust I managed to safely use [1]:
- stack references in threads
- kept mmap references alive until threads finish work
- zero copy xml parsing (from mmaped data!)
- SSE/AVX enabled searching
The Rust language empowered me to do these things with a high degree of confidence. Not one segfault or core dump, just lots of compiler errors.
I played with Zig. Admittedly, the small ecosystem aspect is something all languages go thru, and it would be a better experience with a Zig specific libraries. But Zig doesn't empower library authors to make a large category of bugs impossible, and leaves it to documentation. This is like C, I don't have enough confidence in myself to use it.
Brilliant people are building powerful, safe-ish, reusable libraries in Rust. For mere mortals like me, this is Awesome.
Namely, there is no guarantee that the bytes between `<page>` and `</page>` will be valid UTF-8. It may be the case that you only run this program with UTF-8 input, in which case, UB is never triggered. But it's worth pointing out here since there is nothing actually stopping your program from hitting UB.
Also, as long as you're bringing in the twoway crate, you might as well use it on lines 43 and 48 since you're just searching for a single needle.
Ah gotya. Yeah, I haven't added reverse searching to aho-corasick yet. Ran out of steam.
Either way, my point here is to be a counter-balance. To be fair, you did say, "But with Rust I managed to safely use." But the code you posted is technically unsound. It's not a huge deal if you know you'll always be feeding the program valid UTF-8. But it is worth mentioning here in this HN thread that is specifically comparing the safety properties of competing programming languages. :-)
Chrome sends X-Client-Data headers to DoubleClick and other Google-owned properties, which can be used for tracking purposes. There's no way to disable this behavior.
The header contains a "low entropy" random ID generated by Chrome upon installation. Coupled with other data, this can be used to track users even after clearing cookies and in private mode.
I use the GDPR definition for what “other data” means in an online data collection context. Even then, legal hoop-jumping causes those definitions to be gamed, to the detriment of user privacy, and to the boon of site operators and advertisers.
Damian George, Kento Reutimann, Aurelia Tamò-Larrieux, GDPR bypass by design? Transient processing of data under the GDPR, International Data Privacy Law, Volume 9, Issue 4, November 2019, Pages 285–298, https://doi.org/10.1093/idpl/ipz017
Michael Veale, Reuben Binns, Jef Ausloos, When data protection by design and data subject rights clash, International Data Privacy Law, Volume 8, Issue 2, May 2018, Pages 105–123, https://doi.org/10.1093/idpl/ipy002
Frederik J. Zuiderveen Borgesius, Singling out people without knowing their names – Behavioural targeting, pseudonymous data, and the new Data Protection Regulation, Computer Law & Security Review, Volume 32, Issue 2, 2016, Pages 256-271, https://doi.org/10.1016/j.clsr.2015.12.013
You can disable most of the telemetry with command line switches like --disable-background-networking and --disable-sync, but some things like field trials and doubleclick fingerprinting cannot be excluded in regular Chrome/Chromium AFAIK.
Even basic things like auto-suggestions in the URL bar can't be turned off any more. A while ago there used to be an option for it but it was removed. So when you enter an URL it's automatically sent to Google as you type.
At some point the new tab page stopped being replaceable something less distracting/compulsive like your own custom url. Your homepage can only apply at startup. It isn't something that should have to be an extension.
Anyone have experience with making this work? I tried starting it on the server I have WireGuard running on and it fails to start because it also wants to bind to the UDP port WireGuard uses (even in server mode).
UDPTunnel is designed to tunnel RTP-style traffic, in which applications send and receive UDP packets to and from the same port (or pair of ports). It does not support request/response-style traffic, in which a client request is sent from a transient port X to a well-known port Y, and the server's response is returned from port Y to port X.
Which from what I understand is exactly what WireGuard does.
One aspect is that upgrading Go only requires upgrading it on the build infrastructure rather than a deployment of a new JVM. The "next build" will simply be a binary built with a new compiler version.
https://github.com/ggerganov/llama.cpp/pull/3362
https://huggingface.co/TheBloke/Mistral-7B-v0.1-GGUF/tree/ma...