A pre-built binary for Linux x64 is available on Codeberg, too.
The app is very simple, just downloads your statuses (meaning, your own posts) from your instance and let's you search through them after it finished. A double-click opens the post in the browser.
It should work with any Mastodon™️ compatible server.
In case any #LispWorks users with DV licenses for Win/MacOS/FreeBSD, let me know if you can deliver it.
@louis I’m always conflicted about #LispWorks. They have some fantastic affordances but the Hobbyist license fees are higher than most “professional” tools. Certainly more than I can justify for my scale of projects just to not have them time out. And multiply by not running the same platform on my laptop as on the server in my closet.
To be clear, I’m not saying it’s /wrong/ per se; the economics are what they are. Just sad that it prices me out.
I'm attempting to use the Remote Debugging capabilities of #lispworks but I never manage to connect. Does anyone have any experience with this?
I have a very simple application based on the examples/delivery/hello example. In the delivery script I (require "remote-debugging-client") and then run (dbg:start-client-remote-debugging-server). Once it's running (and I know it has started), I run (dbg:ide-connect-remote-debugging "localhost"), but it times out after a while with Failed to get remote version for connection "localhost" - 6 [Maybe the other side is not a Remote Debugging Client]
Just checkin in. After a multiday outdoor training last week and a 8-hour long night #firefighter op (5 houses burned down) Saturday night, I was kind of tired and had to catch up with work. I promise hacking on #GNV will commence very soon @screwtape.
On the bright side, I finally moved all my Go dev work to #Emacs, but replaced Eglot with lsp-mode. It seems to be more stable and has better integrations with flycheck and other packages.
On another bright side, I do now have the possibility to deliver#CommonLisp binaries on Linux x64 with #Lispworks, so if anyone needs a tester due to lack of a DV license, don't hesitate to ping me.
Love LispWorks and CAPI. In just several hours implemented a simple browser of the collection of FB2 books extracting data from database with simple queries (db is sqlite db created separately but within the same project).
CAPI is rather limited in its functionality but if you just stick to what it has it still allows you to do simple and efficient interfaces.
One of my favorite commands in Emacs is helm-git-grep-at-point. I use it to navigate project all the time.
A similar simple command would enhance the LispWorks editor experience a lot, so I just wrote a simple function to simulate it using build-in "Search Files..." tool.
I assume the project is a git repo, and therefore just need to get the topmost directory where the .git directory is located an assume it as a project root. Using Editor sources (included in paid licenses for LW) one could find a way to call "Search files" tool.
So here you go, a couple of functions to do exactly that
@lapingvino I think I can only name about 5 #lispworks users. I lodged in the libre side of things, so I am only tenuously connected to the various high profile proprietary compilers (of whom, the same people also contributed open source as it developed in the software world). @louis keeps up on lispworks. @pkw
@dekkzz76 Adding some more notes: the project I've migrated from Go to Common Lisp resulted in 50% less code (not using any macros!).
Also, since I've developed it entirely in LispWorks, I did some tests with other implementations and it worked in SBCL and ECL out of the box (CLISP didn't work because bordeaux-threads doesn't support it).
Here are the runtimes:
SBCL:
Evaluation took:
9.755 seconds of real time 1.033166 seconds of total run time (0.968865 user, 0.064301 system)
[ Real times consist of 0.019 seconds GC time, and 9.736 seconds non-GC time. ]
[ Run times consist of 0.019 seconds GC time, and 1.015 seconds non-GC time. ]
10.59% CPU
144 lambdas converted
1 page fault 100,349,712 bytes consed
ECL:
real time : 83.908 secs
run time : 29.092 secs
gc count : 4 times
consed : 662005840 bytes
(sort of disappointing)
LispWorks: User time = 2.220
System time = 0.118
Elapsed time = 9.028
Allocation = 60406728 bytes
1620 Page faults
GC time = 0.009
It seems LispWorks is the clear winner in terms of runtime/memory usage.
Is working with multiple Lisps normal in the Lisp programmer's world? Like writing some applications in SBCL, but maybe some others in <lisp 2>, <lisp 3> etc? I would imagine the want to use the same Lisp implementation everywhere
@louis@offset___cyan Any reason why you don't use #LispWorks for the server? I've been evaluating LispWorks for the past couple of weeks, particularly because of the ability to output tree-shaken compiled self-contained builds (I had a lot of problems with save-lisp-and-die in SBCL, particularly because the GLIB version and SBCL version have to match exactly). Do you usually just recompile when you deploy to the server?
Although now that I think about it, maybe with #nix that is something that I can solve.
Last night I was dreaming that #LispWorks went bankrupt and my coffee machine stopped working because of that. My #twoHoursLispPerDay clearly went too far yesterday. Which ended btw. spending another two hours tracking down a bug in the JZON ➡️ CLOSER-MOP ➡️ LispWorks universe.
It's just so much fun to play around with CAPI from LispWorks while watching StrangeNewWorlds. I'm making my first steps - but it's just so rediculously well thought trough and documented! I'm planning a little math game for my kids where they have to solve challenges and can collect nuts (points). Can't wait to showcase it here, at some time in the near future 🙂
For anyone interested in #LispWorks#CommonLisp, I've just found a full archive of the lispworks-hug mailing list dating back until 2002 to today on the #NNTP server "news.gwene.org". The newsgroup is "gmane.lisp.lispworks.general".
The newsgroup can be easily accessed and searched with this GNUS setup (no auth required):
Article includes mention of the Fediverse, Activity Pub, and forthcoming Meta's Instagram joining the Fediverse stunting hype about Bluesky.
♲ karab.in/m/Twitter/t/8087
Twitter will stay the dominant media-fed and media-driven social platform at least in the US.
Bluesky won't make it. Investors will soon realize that it is a scam, nothing else.
The Fediverse will grow slowly and organically. More from Europe than other parts of the world.
#Mastodon will blow up because all its major instances will be hit by a simultaneous multi-day spam bot attack leading to Amazon #AWS blocking all traffic to&from Mastodon instances and there is nothing they can do about it because Eugen was busy implementing #Twitter UX into Mastodon Mobile Apps
The Emacs.ch instance will move to a self-developed #CommonLisp fork of Mastodon (with a Non-Mastodon logo due to a trademark feud) that employs AI algorithms from the PAIP book, get's rid of all #JavaScript (because it is non-free) and is mainly used by users of the #mastodonEL#Emacs package
Its operator will launch a second donations page begging for money to be able to buy two expensive #LispWorks HobbyistDV licenses because lispm from Reddit told him that this unparalleled, magical Lisp productivity is only gained with a superior IDE
There will be heated discussions between factions of the Common Lisp and the Emacs Elisp community about their Lisp being the better, faster and "most free" one
@amszmidt will chime in and do another "Emacs Lisp is not a Lisp - Bite me" post which generates so much traffic that the Emacs.ch instance will blow up in flames and its operator will eventually convert to a #Microsoft fanboy running an ancient fork of #FidoNet written in Omicron Pascal (but converted to #Delphi), hosted on a WinXP machine with IIS and #SQLServer2008.
The nodgui package for #commonlisp is getting better an better :lispalien:. It's a "No Drama GUI" toolkit based on #Tk. Very extensive! Also has a great demo app included. It could easily compete with #Lispworks CAPI.