samuell
Joined 13 years ago
Karma
2,571
Submissions
964
Member since
May 13
Recent submissions
Comment · 10 days ago
> it's not like there's a lack of groups out there trying.
Indeed. And those who knows how to implement this, might also be the ones with capabilities to deploy it on a large scale (via bot nets or whatever).
What about state actors, suddenly getting a possibility to plant backdoors in millions of websites, etc.
You don't have to be too imaginative to see the "economics" of this.
Comment · 11 days ago
I switched to ProcessWire [1] a couple of years ago, and haven't been happier.
It succeeded to do what Drupal tried but never managed to do:
It is both extremely stable and extremely flexible at the same time.
By having an extremely generic and small core, combined with an extremely powerful programmatic API (basically jquery for data from the CMS, but better), you don't need fiftyeleven modules to achieve some basic tasks.
[1] https://processwire.com (don't get put off by the .com. It is open source).
Comment · 15 days ago
The Objective-Smalltalk paper looks super interesting also, from my brief skim in Zotero! Will have to dig into it more properly next week.
Comment · 15 days ago
Yea, I think I kind of know this in theory, but tend to mix them up sometimes as a non-native English speaker. Good to try to iron out those common mistakes though for sure.
Comment · 15 days ago
Interesting advice, gotta look into that, thank you!
Comment · 15 days ago
Nailed it
Comment · 15 days ago
I think you are right, and I should have done a search on that before. Found now that FBP inventor cites someone Weinberg from 1975 about them (though FBP is supposed to be from around 69-70, so might be a somewhat parallel discovery):
> Now what are "IN" and "OUT" that our pseudocode receives IPs from and sends them to? They are not the names of connections, as this would tie a component's code to one place in the network, but are things called "ports". "Portae" means "gates" in Latin, and ports (like seaports) can be thought of as specific places in a wall or boundary where things or people go in or out. Weinberg (1975) describes a port as
"... a special place on the boundary through which input and output flow... Only within the location of the port can the dangerous processes of input and output take place, and by so localizing these processes, special mechanisms may be brought to bear on the special problems of input and output."
https://www.jpaulmorrison.com/fbp/concepts_book.shtml
Still, I'm amazed at how it took so long before they became mainstream in data flow oriented libraries and DSLs.
And it seems J.P. Morrison was also highlighting Named ports as particularly useful, which is also perhaps what I should have highlighted in my initial comment above.
It's gotten better lately it seems, but a lot of tools skipped that part, which now requires tons of specialized syntax just for routing of multiple parallel streams.
---
Thank you for kind words!
Comment · 15 days ago
Thanks for sharing! I would love for some go to source for this type of insider info from the people who actually have tried. (The best I've found so far are some guys on Twitter/X like Alex Fateev (https://x.com/superalesha) and AJ (https://x.com/ItsmeAjayKV))
I'm personally sitting on an extremely limited Geforce GTX 1660 6GB, and would like to see how far one could go even with such a crappy card.
At least it was quite amazing to see the difference between CPU-based and even this crappy GPU-based inference when trying out some tiny models in jan.ai. It's still like orders of magnitude faster at least.
Comment · 15 days ago
I like that the code example seems to indicate they took the concept of "ports" from flow-based programming, which might be one of it's absolute strongest points:
player2.reveal -> player1.observe
player1.reveal -> player2.observe
Wrote about it in the context of workflow systems way back (https://livingsystems.cc/posts/workflows-dataflow-not-task-d...)
---
Edit 11:12 CET: I realize that “named ports” better captures what I had in mind here, as elaborated in a comment below.
Comment · 26 days ago
Looks like a really cool project, especially for quick no-setup use cases.
If you prefer to keep things local and open source, and your agents' notes do fit in issues, you might want to check out Epiq too, which is a local but distributable issue board synced via an event log mechanism to ensure consistency when syncing across repos:
Comment · 1 month ago
Seems they might have discoveref the language of G*d:
"[...] he has given a law to which they must conform."
- Psalms 148:6 (CJB)
:)
Comment · 1 month ago
Now do the combinations of them.
Comment · 1 month ago
I hope @jolaflow can chime in here eventually, but from a brief look, my impression, besides the fact that Epiq is based on git as opposed to beads where it is optional, is that Epiq seems to be much more optimized for interactive collaboration between the user and the agents.
The graph visualization in beads surely is a neat thing for showing things, but the replay feature in Epiq should provide a similar understanding of what happened.
But again, it seems to me Epiq is the tool that better allow the user to jump right in and collaborate with the agents on the board.
(Again, this is from a brief look, so I could be missing things).
Comment · 1 month ago
Sorry, I might not have been clear, but the tool and blog is by @jolaflow (my brother) and I'm so far mostly involved as a reviewer and early adopter, but glad you like it. I might be biased, but I think the tool provides something really useful for agentic coding and hoping it can grow into a thriving open source project.
Comment · 1 month ago
Yeah, I think as a general direction we need to allow a useful collaboration with the agents on the issue board.
This is btw why Epiq was developed, to keep the board as code, git-backed, distributed (via an event log mechanism), and with the ability to replay the board, to see what agents actually did:
R&D: https://livingsystems.cc Deep think: https://livingsystems.substack.com
Married. Dad. Sinner saved by grace.