Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Xpost3 strategy
44 views
Skip to first unread message
luser- -droog
Mar 13, 2013, 11:29:25 PM3/13/13
to
I'm starting to think hard about rebooting the Xpost project using the real open-source tools on code.google.com. In the short-term, that will involve working up just the virtual-memory module that's the foundation of everything. I think the execloop problem will solve itself once I get there, as it's been developing in my subconscious for several months now. For speed, there's nothing better than a separate function for each pattern of types to check on the stack. Whether to write these in straight C or some wild X-macros is still in the air.
But I just had a crazy idea that maybe I should skip Cairo and build Xpost completely differently. After VM comes the basic composite types: arrays, strings and dicts, then probably math. But then, I think, while it's simple, that's the ideal point to get the garbage collector working. Before there's even an interpreter loop. Because I think if I want it to work well at the end, it needs to be around from the beginning. Then save/restore.
Then, I want to work up a multiprocessing scheduler. I think `setjmp` and `longjmp` will do the job. This will follow the way NeWS worked.
Then I want to add networking operators and build the graphics within postscript acting as an X11 client. That should actually simplify working with X because I'd only need volume 0.
Building all the graphics code may be slow and painful, but it won't leave me in the same situation that Xpost2 did. At `definefont`. Up the creek, in the fog, no paddle, no compass.
But I just had a crazy idea that maybe I should skip Cairo and build Xpost completely differently. After VM comes the basic composite types: arrays, strings and dicts, then probably math. But then, I think, while it's simple, that's the ideal point to get the garbage collector working. Before there's even an interpreter loop. Because I think if I want it to work well at the end, it needs to be around from the beginning. Then save/restore.
Then, I want to work up a multiprocessing scheduler. I think `setjmp` and `longjmp` will do the job. This will follow the way NeWS worked.
Then I want to add networking operators and build the graphics within postscript acting as an X11 client. That should actually simplify working with X because I'd only need volume 0.
Building all the graphics code may be slow and painful, but it won't leave me in the same situation that Xpost2 did. At `definefont`. Up the creek, in the fog, no paddle, no compass.
sjprou...@gmail.com
Mar 14, 2013, 3:02:49 PM3/14/13
to
If you want to start from the ground up, maybe consider doing it in Factor (http://factorcode.org/). I had a passing thought of doing that (just a passing thought, mind you, since I have neither the courage or skill to actually do it). Note that there is some lineage from PostScript to Joy to Factor that may be an advantage.
luser- -droog
Mar 15, 2013, 4:58:00 AM3/15/13
to
On Thursday, March 14, 2013 2:02:49 PM UTC-5, sjprou...@gmail.com wrote:
> If you want to start from the ground up, maybe consider doing it in Factor (http://factorcode.org/). I had a passing thought of doing that (just a passing thought, mind you, since I have neither the courage or skill to actually do it). Note that there is some lineage from PostScript to Joy to Factor that may be an advantage.
I'll definitely take a look at it. Thanks. But I'm not too keen on learning a new language to do build this. C still seems like the best choice for me, for now. But every language I read about seems to have something I can steal from. :)
> If you want to start from the ground up, maybe consider doing it in Factor (http://factorcode.org/). I had a passing thought of doing that (just a passing thought, mind you, since I have neither the courage or skill to actually do it). Note that there is some lineage from PostScript to Joy to Factor that may be an advantage.
0 new messages