portal VS chatgpt-shell

Tracing debuggers give you the best of both worlds. I've recently started using Flow-storm [0], by @jpmonettas), and it's been quite transformative. You can still easily see the values flowing through your system (better than just "prints"), and it can handle multi-threaded / async scenarios quite nicely. You don't need to manually step through code, you can just "see" your data flow, and when you have loops or some other form of iteration, you can see the data for each pass. Coupling this with a good data visualization tool (such as Portal [1]) really feels like magic. I've been doing Clojure for quite a few years now, and was very happy with my plain REPL-driven workflow, but this is way better.

[0] https://github.com/jpmonettas/flow-storm-debugger

[1] https://github.com/djblue/portal

In this meeting, Lukas Domagala of the Calva team and Chris Badahdah, Portal's creator, presented Calva Notebooks, their integration with Portal, and other Portal updates.

Also my dot-clojure and vscode-calva-setup repos have some interesting stuff in for using/customizing Portal for use with VS Code: * https://github.com/seancorfield/dot-clojure * https://github.com/seancorfield/vscode-calva-setup * https://github.com/djblue/portal

One thing that really helps with debugging is learning to use tap>. Even after a decade of using Clojure, I found it game changing. I personally use it with djblue/portal, which has a lot of bells and whistles, but isn't too hard to get going with the basics. You don't need an UI for tap>, though, if you don't want it.

You may want to try using tap> for debugging, which avoids this problem and is generally more convenient in my experience. I use it to log values with either an atom or Portal.

Portal makes deving so much easier! Having your tapped data available to inspect and transform in the Portal UI is much easier, cleaner, and faster than in the REPL/output window.

Clay is an attempt to create compatibility across data science notebook plugin scripts. Today, Clojure's data viz tools (e.g. Clerk, djbue/Portal) offer similar abstractions for scientists to 1) create notebook documents and 2) enable dynamic exploration of data. These tools all work by attaching rendering metadata to values. But the render code is not portable across tools, which means a script written for one tool is not compatible with all the others, and this inhibits scientific work and makes the toolchain inaccessible to scientists who don't know Clojure.

tag / stick into something like https://github.com/djblue/portal makes this problem instantly go away, and I get a whole bunch extra stuff at the same time: https://www.youtube.com/watch?v=gIoadGfm5T8 If you MUST have it codified somewhere, probably the next highest leverage point is to use specs. Typically we do this when you've a single set of data structures that are widely reused (as opposed to, say, a map that's only used between a single SPA component and an API call). I've tried both clojure.spec and Malli. Clojure's spec is satisfactory. Malli's ergonomics and performance are fantastic. https://github.com/metosin/malli

;; :main-opts ["-m" "cognitect.rebl"]}

Into your '~/.clojure/deps.edn'.

From there I can just add 'rebl' as a profile to my Intellj when you start a REPL it starts automatically.

There are also alternative tools like Portal to do the same things: https://github.com/djblue/portal

Or: https://vlaaad.github.io/reveal/

I think it is a tooling issue. It is in no way obvious how use LLM's effectively, especially for really good writing results. Tweaking and tinkering can be time consuming indeed, but i use lately the chatgpt-shell [1] and it lends well to an iterative approach. One needs to cycle through some styles first, and then decide how to most effectively prompt for better results.

[1]https://github.com/xenodium/chatgpt-shell/blob/bf2d12ed2ed60...

- https://xenodium.com/an-ios-journaling-app-powered-by-org-pl... - Lately, I'm having a go at building a privacy-focused plain-text-based iOS journaling app. I starte building it for someone important in my life but now using it myself.

- https://flathabits.com - After reading Atomic Habits, I wanted a habit tracker but most had more friction than I wanted, required accounts, had distractions, lock-in etc. so I built a privacy-focused app, with little friction and no-lockin (saves to plain text).

- https://plainorg.com - There are a gazillion markdown apps on the App Store, but hardly any supporting org markup, so I built one.

- https://xenodium.com/scratch-a-minimal-scratch-area - I wanted a surface where I could just dump text with as few taps as possible.

- https://github.com/xenodium/macosrec - I wanted to take either screenshots or videos of macOS apps from the command line, so I could integrate anywhere.

- https://github.com/xenodium/chatgpt-shell - I'm far down the Emacs rabbit hole, so I prefer Emacs-integrated tools. Built a ChatGPT Emacs shell to see what the hype was all about ;) tl;dr it really does help.

- https://github.com/xenodium/dwim-shell-command - A way to manage and easily apply the gazillion one-liners (and more complex scripts) I've come across. I got close to 100 utils check-in now https://github.com/xenodium/dwim-shell-command#my-toolbox

- https://github.com/xenodium/ob-swiftui - Play around with SwiftUI layouts from the comfort of my preferd editor.

- https://github.com/xenodium/company-org-block - Org block completion.

- https://xenodium.com - I tend to scratch own itches and post my solutions here.

Every so often I scratch an itch to improve my workflow and write it up https://xenodium.com.

With lsp, the gap between IDEs vs text editors is narrowing. While I still prefer Emacs, I’m pragmatic enough to jump on to whatever tool does a better job for a specific task. At times, that is Xcode.

Was also sceptical about ChatGPT and changed my mind like OP. I was less pragmatic on this one and brought ChatGPT over to Emacs https://github.com/xenodium/chatgpt-shell. Pretty happy with the result so far.

There are a handful of chatgpt Emacs packages. I happen to have authored chatgpt-shell. For making a synchronous request, can use chatgpt-shell-post-prompt. For async, use chatgpt-shell-send-to-buffer with a handler.

https://xenodium.com will hit 10 years in November. It started as a single org file for personal notes (programming, cooking, Emacs, bookmarks, iOS dev, travel). One day, I decided to export it to HTML and make it accessible to me from anywhere. Sorta just became both notes and blog over time…

While the tone of the posts may have evolved a bit, the blog still serves as personal notes/reference of sorts. The tech behind it hasn’t changed a whole lot. It remains a single org file (https://raw.githubusercontent.com/xenodium/xenodium.github.i...) with my own ugly elisp hacks, but hey does the job ;-)

u/xenodium's chatgpt-shell deserves a mention. It uses an intuitive Comint-shell based interaction and includes support for executable code blocks (in the comint-shell) and for org-babel. It's very polished -- I believe it also includes support for saving and restoring sessions, which gptel is yet to add.

Yep. Turn some of them into posts https://xenodium.com

For certain concepts that I don't understand fully, I'm using chatgpt-shell. It is beyond fantastic and almost impossible to describe in a single post. This is, for example, just one of my use cases: When I'm writing a comment or a message to my colleague (and of course, yes, I edit just about any text in Emacs), I can select a paragraph and ask chatgpt-shell to improve it. It does, but it also shows me the diff of the changes, that is how I set it up.

Mine (https://xenodium.com) will hit 10 years in November. It started as a single org file for personal notes. One day I decided to export it to HTML as my accesible notes from anywhere. Sorta just became both notes and blog over time… While the tone of the posts may have evolved over time, they still serve as a notes/reference of sorts. The tech behind it hasn’t changed a whole lot. It remains is a single org file (https://raw.githubusercontent.com/xenodium/xenodium.github.i...).