planckforth
cycle-cloud
planckforth | cycle-cloud | |
---|---|---|
12 | 6 | |
271 | 9 | |
- | - | |
0.0 | 1.8 | |
over 1 year ago | over 2 years ago | |
Forth | Gherkin | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
planckforth
-
Forth as an intermediate language
This reminds me a bit of how planck is implemented with planckforth. I can't tell you if there are pitfalls or not, but I can understand how it could be an interesting approach.
- PlanckForth - Bootstrapping a Forth interpreter from hand-written tiny ELF binary. Just for fun.
-
Hacker News top posts: Dec 6, 2021
Show HN: PlanckForth – Bootstrapping an interpreter from handwritten 1kb binary\ (14 comments)
-
Show HN: PlanckForth: Bootstrapping an Interpreter from Handwritten 1KB Binary
bootstrap.fs is a thing of beauty
https://github.com/nineties/planckforth/blob/main/bootstrap....
It starts off looking like line noise (the very simple interpreter defined in hex) and gradually turns into the forth we know and love.
Fantastic!
-
Bootstrapping a Forth Interpreter from Handwritten 1KB Binary
interpreter is designed to be very simple. Every built-in word is single-letter and the interpreter just repeats that reads a character, looks it up from the dictionary and executes it. Also there is no error checking.
This is the actual code for the first interpreter, which is a 136-byte implementation of the interpreter followed by a built-in dictionary of 888 bytes.
https://github.com/nineties/planckforth/blob/main/planck.xxd
The first interpreter and language is so esoteric that, for example, the Hello World looks like this.
$ ./planck
- PlanckForth: Bootstrapping an Interpreter from Handwritten 1KB Binary
-
Fitting a FORTH in 512 bytes
Seems painful. I like this approach:
https://github.com/nineties/planckforth
You start with a very tiny address or bytecode interpreter, much smaller than 512 bytes. Then you load several levels of bootstrap interpreters into it until you have a fairly featureful Forth. So that occupies ram but not program space on the target computer. You would load the non-initial stuff from a remote computer that didn't have tiny memory constraints.
- Bootstrapping an Interpreter from Handwritten 1KB Binary
cycle-cloud
- Cycle Labs – Testing software after it gets deployed to production
-
Hacker News top posts: Dec 6, 2021
Show HN: Cycle Labs – Testing software after it gets deployed to production\ (0 comments)
- Show HN: Cloud-Based Behavior-Driven Automation Born from the Supply Chain
-
Cycle Labs – Free, Cloud-Based Behavior-Driven Test Automation
Hey all, Josh here, Co-founder and CEO at Cycle Labs (https://cyclelabs.io/). In 2009 I co-founded a supply chain consulting firm which I grew to >85 people globally. In 2014 we started building our own products to solve some challenges in our space and one of those products eventually became Cycle, which I spun out of that consulting firm along with 25 employees in July of this year (2021) to form Cycle Labs. I traded my equity in a very successful consulting firm for the fun and excitement of building a product company :)
The supply chain space, as you can imagine, is riddled with legacy software solutions driving critical business processes that power many businesses which are household names. Our assessment was that these legacy systems exist in large part because of the fear of change and not because of the lack of desire to improve. Projects implementing new software in this space are big, and complicated. Oftentimes issues were not software bugs in the general sense but just undiscovered requirements, miscommunications and misalignment between the business users and the deployment teams tasked with putting these systems into production.
We felt like drastically improved quality measures could change this. Our challenge though is that the implementation and deployment teams aren't developers. They are certainly technically inclined but they aren't developers in the true sense of the word and so the well-known test automation solutions wouldn't make sense. And furthermore, our context is different. These teams aren't really developing software from the ground up but are deploying existing solutions and integrating with existing complex business systems forming large, complex software systems that are going largely untested. And related, often these critical business processes aren't using modern technology and usually span many technologies and teams. We knew if we wanted to solve these problems we needed to build something of our own - a different context required a different solution and approach.
And so in 2014 we built Cycle as a continuous testing platform targeted at the enterprise software deployment space. We've grown a really exciting enterprise customer-base with the 2nd generation of the Cycle platform which is largely deployed on-premise in our customer's networks as these companies haven't yet begun to trust their critical systems to cloud-hosted providers. In recent years however, the software OEMS are starting to make the shift to Saas/Cloud-native solutions (like everyone else in the software world) and we are happy to finally begin migrating Cycle to the cloud as well.
The existing on-prem Cycle platform (2.0) works across web, native, java, api, database and OS interactions. Recently we've launched a cloud-native version of Cycle (https://app.cyclelabs.io/) which is free for use. We've attempted to be iterative in our approach and so this MVP is web-only for right now -- and admittedly it's rough around the edges but we'd like to get feedback in realtime and iterate -- which is the message we have been preaching to our clients for years.
We want Cycle to be a cloud-native, behavior-focused automation platform that puts emphasis on process-discovery through natural language Feature files. We need the platform to come with pre-built Steps because the majority of our users aren't developers but they can write test cases in Cycle. And now, we're wondering if a transition to cloud will allow us to branch outside of the supply chain space and into the broader testing community. We believe end-to-end process testing can benefit any organization focused on streamlining solutions into production.
You can try our application out here (https://zurl.co/H3ZQ) and we've provided some example Feature files (tests) here: https://github.com/CycleLabsCloud/cycle-cloud.
I would appreciate your kind thoughts, feedback and guidance as we navigate this transition.
What are some alternatives?
miniforth - A bootsector FORTH
principia - The Principia Rewrite
Transformer-in-Transformer - An Implementation of Transformer in Transformer in TensorFlow for image classification, attention inside local patches
planck - This project aims to develop a Compiler Infrastructure which have advanced memory safety and concurrency features.
factor - Factor programming language