Re: [9fans] Intel NUCs and Plan 9?
Raspberry pi isn't what I want. I want to be able to compile / do serious development and being able to run Linux would also help. I'm not comfortable moving outside of Intel architecture and I want the horsepower I can get out of a Haswell or Broadwell. Thanks, Arnold Shingo Onobori onoborishi...@gmail.com wrote: Is the Raspberry Pi2 bad choice? http://www.plan9.bell-labs.com/wiki/plan9/download/ On 2015/07/09 21:18, arn...@skeeve.com wrote: Does anyone have experience using Intel NUCs with Plan 9? I'm looking at http://www.amazon.com/Intel-Next-Unit-Computing-NUC5i3RYK/dp/B00S1ISFOQ/ref=sr_1_9?s=pcie=UTF8qid=1436443454sr=1-9keywords=intel+nuc which is a Broadwell Core i3. Other recommendations for low-cost, small form factor boxes to run Plan 9 would be welcome, preferably with links (:-). Thanks, Arnold
[9fans] origins of configure
So, the history is more than this. Larry Wall's Configure (capital C) for rn and Perl was the first step at a shell script to examine system features and generate a config.h. It was inspirational for autoconf, but autoconf doesn't use any of its code, as far as I know. Autoconf was designed to solve real portability problems. In the late 80s and early 90s there was a huge variety of Unix systems and it was really hard to know what was available and what wasn't based on simple ifdefs. The variations were bigger than Erik makes out. Today, the scale of the problem is reduced, since we have POSIX and also fewer systems out there. Much of the bloat in the Autotools is from legacy. But there are still very real portability issues, especially among some of the fringe *BSD systems. MirBSD in particular is one of the worst, but that's another rant. If one were to start over today, one could likely arrive at a simpler system, but portability problems remain, and they are real. Arnold erik quanstrom quans...@quanstro.net wrote: confirmed. it's existence is due to early gnu programs fighting with small variations in unix and compilers. byron's rc used a small script to the same effect. but for the most part, this all could be avoided with careful planning and not using esoteric functions. gcc also had its own configuration step. the header rewriting is a vestage of this system. - erik On Jul 9, 2015 05:31, Jeff Sickel j...@corpus-callosum.com wrote: On Jul 9, 2015, at 5:19 AM, Steve Simon st...@quintile.net wrote: FWIW: fgb did a stirling script called config which sets up some environment and runs configure under ape. It doesn't always work but often gets close to generating a config.h as linux intended. Configure predates Linux. That, or my memory of using it to bang my head against the perl wall in the 1980s damaged the register. -jas … at least you’re not using Xenix From 9fans-boun...@9fans.net Thu Jul 9 07:52:09 2015 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on frenzy.freefriends.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.1 X-Envelope-From: 9fans-boun...@9fans.net Return-Path: 9fans-boun...@9fans.net X-Virus-Scanned: by MailRoute Date: Thu, 09 Jul 2015 06:50:06 -0700 X-Android-Message-ID: 8f71c132-1b4d-4d0c-a741-d0738945f...@email.android.com From: erik quanstrom quans...@quanstro.net To: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net Content-Type: text/plain; charset=utf-8 Subject: Re: [9fans] Gawk in 9front-ports X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs 9fans@9fans.net List-Id: Fans of the OS Plan 9 from Bell Labs 9fans.9fans.net List-Unsubscribe: http://mail.9fans.net/options/9fans, mailto:9fans-requ...@9fans.net?subject=unsubscribe List-Archive: http://mail.9fans.net/private/9fans List-Post: mailto:9fans@9fans.net List-Help: mailto:9fans-requ...@9fans.net?subject=help List-Subscribe: http://mail.9fans.net/listinfo/9fans, mailto:9fans-requ...@9fans.net?subject=subscribe Sender: 9fans-boun...@9fans.net Errors-To: 9fans-boun...@9fans.net X-MIME-Autoconverted: from base64 to 8bit by freefriends.org id t69Dq5Ri006148 Status: R confirmed. it's existence is due to early gnu programs fighting with small variations in unix and compilers. byron's rc used a small script to the same effect. but for the most part, this all could be avoided with careful planning and not using esoteric functions. gcc also had its own configuration step. the header rewriting is a vestage of this system. - erik On Jul 9, 2015 05:31, Jeff Sickel j...@corpus-callosum.com wrote: On Jul 9, 2015, at 5:19 AM, Steve Simon st...@quintile.net wrote: FWIW: fgb did a stirling script called config which sets up some environment and runs configure under ape. It doesn't always work but often gets close to generating a config.h as linux intended. Configure predates Linux. That, or my memory of using it to bang my head against the perl wall in the 1980s damaged the register. -jas … at least you’re not using Xenix
Re: [9fans] Porting 9fans.net/go/draw to Plan 9
I mean 9fans.net/go/draw Sorry for the wrong subject line Am 09.07.2015 um 16:52 schrieb Friedrich Psiorz: Hi! I'm currently writing a graphical application in Go that I would like to be able to run both in Unix and Plan 9. Currently the 9fans.net/go/draw library only works in Unix, by connecting to p9p devdraw. Does one of the maintainers of that repository read this list? I have the following questions: - Is anyone still maintaining the repo or is it dead? Who can I contact directly? - Do you even want a native Plan 9 port? - Is there still interest in finishing the parts of that library that are missing? I know that there is also mischief's draw9 library which is basically a port of the same repo, but only for Plan 9, not Plan 9 Port. I would like to run in both and I would prefer not starting a third incompatible clone. Cheers Fritz
Re: [9fans] Gawk in 9front-ports
confirmed. it's existence is due to early gnu programs fighting with small variations in unix and compilers. byron's rc used a small script to the same effect. but for the most part, this all could be avoided with careful planning and not using esoteric functions. gcc also had its own configuration step. the header rewriting is a vestage of this system. - erik On Jul 9, 2015 05:31, Jeff Sickel j...@corpus-callosum.com wrote: On Jul 9, 2015, at 5:19 AM, Steve Simon st...@quintile.net wrote: FWIW: fgb did a stirling script called config which sets up some environment and runs configure under ape. It doesn't always work but often gets close to generating a config.h as linux intended. Configure predates Linux. That, or my memory of using it to bang my head against the perl wall in the 1980s damaged the register. -jas … at least you’re not using Xenix
Re: [9fans] Intel NUCs and Plan 9?
Is the Raspberry Pi2 bad choice? http://www.plan9.bell-labs.com/wiki/plan9/download/ On 2015/07/09 21:18, arn...@skeeve.com wrote: Does anyone have experience using Intel NUCs with Plan 9? I'm looking at http://www.amazon.com/Intel-Next-Unit-Computing-NUC5i3RYK/dp/B00S1ISFOQ/ref=sr_1_9?s=pcie=UTF8qid=1436443454sr=1-9keywords=intel+nuc which is a Broadwell Core i3. Other recommendations for low-cost, small form factor boxes to run Plan 9 would be welcome, preferably with links (:-). Thanks, Arnold
[9fans] Porting 9front.net/go/draw to Plan 9
Hi! I'm currently writing a graphical application in Go that I would like to be able to run both in Unix and Plan 9. Currently the 9fans.net/go/draw library only works in Unix, by connecting to p9p devdraw. Does one of the maintainers of that repository read this list? I have the following questions: - Is anyone still maintaining the repo or is it dead? Who can I contact directly? - Do you even want a native Plan 9 port? - Is there still interest in finishing the parts of that library that are missing? I know that there is also mischief's draw9 library which is basically a port of the same repo, but only for Plan 9, not Plan 9 Port. I would like to run in both and I would prefer not starting a third incompatible clone. Cheers Fritz
Re: [9fans] Porting 9fans.net/go/draw to Plan 9
- Is anyone still maintaining the repo or is it dead? Who can I contact directly? Russ Cox is maintaining the draw package. - Do you even want a native Plan 9 port? Nick Owens did a Plan 9 port (based on a slightly older version). https://bitbucket.org/mischief/draw9 - Is there still interest in finishing the parts of that library that are missing? Yes. One nice thing would be to share a common API on both Unix and Plan 9. -- David du Colombier
Re: [9fans] rsc's libtask on embedded
I really like rsc's libtask and have managed to hide it in a few products. As for your question: What architecture? Any runtime available? Personally, I've used libtask on ARM/x86 under Linux/OSX... hardly bare metal though. The current implementation depends mostly on the ucontext API + berkeley sockets for net stuff. There's another project called http://libmill.org/ that is (was?) based on setjmp/etc that might be easier to port. Do keep me posted on your travels... I'm interested in this kind of stuff too. ...or maybe we should just all help Charles updating/minimizing Inferno... -joe On Thu, Jul 9, 2015 at 4:38 AM, Steve Simon st...@quintile.net wrote: Anyone stripped rsc's libtask for use on a bare metal embedded system, I'am about to do it but if somone already has I could steal it. -Steve
Re: [9fans] rsc's libtask on embedded
Russ implemented his own setmcontext and getmcontext functions to work on systems that doesn't properly support ucontext. So I don't think you really need ucontext support in your libc. By the way, I maintain an updated version of libtask: https://github.com/0intro/libtask I've used it on quite a few places over the years, but I only on POSIX systems so far. -- David du Colombier
Re: [9fans] rsc's libtask on embedded
David, it's good to hear you're keeping libtask updated... I'll check it out for sure! On Thu, Jul 9, 2015 at 11:09 AM, David du Colombier 0in...@gmail.com wrote: Russ implemented his own setmcontext and getmcontext functions to work on systems that doesn't properly support ucontext. So I don't think you really need ucontext support in your libc. By the way, I maintain an updated version of libtask: https://github.com/0intro/libtask I've used it on quite a few places over the years, but I only on POSIX systems so far. -- David du Colombier
Re: [9fans] rsc's libtask on embedded
Your use is different and simple enough that I would suggest doing this from scratch in pure C. Or start from an existing setjmp based implementation. It should really be a couple pages of code at most. On Jul 9, 2015, at 9:12 AM, st...@quintile.net st...@quintile.net wrote: co routines plus channels is exactly what I want.
Re: [9fans] origins of configure
On Thu, Jul 09, 2015 at 09:24:57AM -0600, arn...@skeeve.com wrote: So, the history is more than this. Larry Wall's Configure (capital C) for rn and Perl was the first step at a shell script to examine system features and generate a config.h. Using a shell script to generate commands to compile on diverging Unices was, by the date, already used in G.R.A.S.S. from C.E.R.L. and this predates Perl and so on. I guess it is not the only example. [...] Autoconf was designed to solve real portability problems. There are two problems with the autotools stuff: 1) Features are fixed for OSes, but the configuring is done other and other again for every program. What a system offers shall be known; and what the developers require shall be known too. Autotools was designed in a world where neither the OS nor the developers exactly know what they use; 2) Cross-compilation was not in mind, with some features tested by compiling and running programs. The result is that the majority of software built with autotools needs to be compiled natively (even installed on an equal system since the layout is searched on the building node); 3) To try to understand what's going on with several steps and huge configs is out of reach. Rule: when it takes less time to build a solution from scratch than to try to understand how to _use_ an existing solution (not to mention understand), this solution has to be safely stored in /dev/null. Note: I have put my money where my mouth is : I have built such a solution: the one publicly used with kerTeX---but it is a side effect, it was not meant to be released. And it solves the 1) and 2) and solves too the space problem: when an object is not any longer necessary, it can be automatically removed, limiting the space needed to compile to the bare minimum. -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] rsc's libtask on embedded
BTW, somewhere I wired in TADNS (http://adns.sourceforge.net/) so libtask's network lookups didn't block. Let me know if you have any interest in me cleaning it up for use. -joe On Thu, Jul 9, 2015 at 11:09 AM, David du Colombier 0in...@gmail.com wrote: Russ implemented his own setmcontext and getmcontext functions to work on systems that doesn't properly support ucontext. So I don't think you really need ucontext support in your libc. By the way, I maintain an updated version of libtask: https://github.com/0intro/libtask I've used it on quite a few places over the years, but I only on POSIX systems so far. -- David du Colombier
Re: [9fans] Intel NUCs and Plan 9?
I have been very very impressed with the performance of the pi2, really quite a usable machine - though it is still a terminal. -Steve
Re: [9fans] rsc's libtask on embedded
Sounds like all you want are coroutines (with create, destroy switch-to calls) and wait queues (with create, destroy, signal wait calls). With these you can build channels easily. With a bit more work you can even implement pre-emption but then you need mutexes. Setjmp/longjmp is fine (that was I did in my first version ages ago!). On Jul 9, 2015, at 7:50 AM, Steve Simon st...@quintile.net wrote: The system I am trying to add libtask to has no runtime other than libc. Corrently it is an even based system that uses a min main loop and a twisty maze of nested state machines that all look the same. Hence my desire to add co-routines + channels (i.e. exactly what libtask is) to it. I have no need for the file or network modules but those are easily removed. I don't have the context calls but I do have setjmp/longjmp so that is what I am trying to use. I will shout if it works out. -Steve
Re: [9fans] rsc's libtask on embedded
One other thing that I've looked at but never used is Adam Dunkels' protothreads (http://dunkels.com/adam/pt/) although you'd still need to roll your own channel library. On Thu, Jul 9, 2015 at 10:50 AM, Steve Simon st...@quintile.net wrote: The system I am trying to add libtask to has no runtime other than libc. Corrently it is an even based system that uses a min main loop and a twisty maze of nested state machines that all look the same. Hence my desire to add co-routines + channels (i.e. exactly what libtask is) to it. I have no need for the file or network modules but those are easily removed. I don't have the context calls but I do have setjmp/longjmp so that is what I am trying to use. I will shout if it works out. -Steve
Re: [9fans] origins of configure
I don't intend to engage in yet another 9fans flame war. I do not argue with your analysis or proposal. However, it's based on considerable hindsight and experience that wasn't available when autotools started. Additionally, systems in that time period were changing continually. So it was not always true that what any given system provides is known in advance. The autotools (and especially gnulib) are bloated. A better design is possible. But it's unfair to say that at the time they could have done a lot better; I don't think that's true. Hindsight is always 20/20. That's all I'll say on the topic. Arnold tlaro...@polynum.com wrote: On Thu, Jul 09, 2015 at 09:24:57AM -0600, arn...@skeeve.com wrote: So, the history is more than this. Larry Wall's Configure (capital C) for rn and Perl was the first step at a shell script to examine system features and generate a config.h. Using a shell script to generate commands to compile on diverging Unices was, by the date, already used in G.R.A.S.S. from C.E.R.L. and this predates Perl and so on. I guess it is not the only example. [...] Autoconf was designed to solve real portability problems. There are two problems with the autotools stuff: 1) Features are fixed for OSes, but the configuring is done other and other again for every program. What a system offers shall be known; and what the developers require shall be known too. Autotools was designed in a world where neither the OS nor the developers exactly know what they use; 2) Cross-compilation was not in mind, with some features tested by compiling and running programs. The result is that the majority of software built with autotools needs to be compiled natively (even installed on an equal system since the layout is searched on the building node); 3) To try to understand what's going on with several steps and huge configs is out of reach. Rule: when it takes less time to build a solution from scratch than to try to understand how to _use_ an existing solution (not to mention understand), this solution has to be safely stored in /dev/null. Note: I have put my money where my mouth is : I have built such a solution: the one publicly used with kerTeX---but it is a side effect, it was not meant to be released. And it solves the 1) and 2) and solves too the space problem: when an object is not any longer necessary, it can be automatically removed, limiting the space needed to compile to the bare minimum. -- Thierry Laronde tlaronde +AT+ polynum +dot+ com http://www.kergis.com/ http://www.arts-po.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
Re: [9fans] rsc's libtask on embedded
all process-like implementations except if they give up on per-cpu multiprogramming are setjmp based at heart. - erik On Jul 9, 2015 09:31, Bakul Shah ba...@bitblocks.com wrote: Your use is different and simple enough that I would suggest doing this from scratch in pure C. Or start from an existing setjmp based implementation. It should really be a couple pages of code at most. On Jul 9, 2015, at 9:12 AM, st...@quintile.net st...@quintile.net wrote: co routines plus channels is exactly what I want.
Re: [9fans] Gawk in 9front-ports
Hi Hugo. I'm not sure who you're addressing. Jens did the port. I maintain gawk. Removing bloat unfortunately isn't going to happen in the mainline code base since there are backward compatibility issues. However, I'm happy to incorporate portability changes to make porting to Plan 9 easier, if they're reasonable. HTH, Arnold Hugo Rivera uai...@gmail.com wrote: Let me understand. Are you going to modify the current gawk version according to your needs (perhaps removing some of the bloat you mention)? or are you going to port gawk as it is? 2015-07-08 2:22 GMT-04:00 arn...@skeeve.com: Hugo Rivera uai...@gmail.com wrote: Why do you want gawk on plan9? I appreciate knowing about portability issues. :-) I use awk a lot (on plan9 and elsewhere) and I wonder what reasons do you have to use gawk over plan9's awk. Many features and extensions over standard awk. Different people will assign different levels of value to said features and extensions. A partial list: - The previously discussed dynamic plug-in facility - And awk-level debugger - A statement count profiler (and a pretty printer) - True arrays of arrays - Many more built-in functions and variables. In retrospect, some of these are just bloat and I'd have been better off without them. Arnold -- Hugo
Re: [9fans] plan9 web site Object not found
I don't know this page. Thanks! On 2015/07/09 0:45, David du Colombier wrote: I tried to download plan9 image, but I cannot access to plan9 website. http://plan9.bell-labs.com/plan9/ Would you tell me anything about this? (server maintainance? or server down?) You can download Plan 9 on https://9p.io/plan9
Re: [9fans] plan9 web site Object not found
To David adrian I can see the plan9 web page. Thank you. On 2015/07/09 6:05, David du Colombier wrote: Interestingly, I had the same problem. But now it seems to work, I can access everything as normal. Maybe it was just a test to find out how quickly we would realise that the site was down. The website was down for ten days, then it went back two hours ago.
[9fans] Intel NUCs and Plan 9?
Does anyone have experience using Intel NUCs with Plan 9? I'm looking at http://www.amazon.com/Intel-Next-Unit-Computing-NUC5i3RYK/dp/B00S1ISFOQ/ref=sr_1_9?s=pcie=UTF8qid=1436443454sr=1-9keywords=intel+nuc which is a Broadwell Core i3. Other recommendations for low-cost, small form factor boxes to run Plan 9 would be welcome, preferably with links (:-). Thanks, Arnold
Re: [9fans] Gawk in 9front-ports
Arnold, I am not sure who I am addressing either :-) Just wanted to know where this gawk port was heading. The thing is that I use a slightly modified version of Plan 9's awk. In this version, I added all the math functions from C and replaced the random number generator by the Mersenne twister. As a comment, from my experience gawk is generally faster than Plan 9's awk, but I believe the latter is more reliable (it crashes less often than gawk). Please, let me (us) know about the future of awk in 9front. 2015-07-09 4:49 GMT-04:00 arn...@skeeve.com: Hi Hugo. I'm not sure who you're addressing. Jens did the port. I maintain gawk. Removing bloat unfortunately isn't going to happen in the mainline code base since there are backward compatibility issues. However, I'm happy to incorporate portability changes to make porting to Plan 9 easier, if they're reasonable. HTH, Arnold Hugo Rivera uai...@gmail.com wrote: Let me understand. Are you going to modify the current gawk version according to your needs (perhaps removing some of the bloat you mention)? or are you going to port gawk as it is? 2015-07-08 2:22 GMT-04:00 arn...@skeeve.com: Hugo Rivera uai...@gmail.com wrote: Why do you want gawk on plan9? I appreciate knowing about portability issues. :-) I use awk a lot (on plan9 and elsewhere) and I wonder what reasons do you have to use gawk over plan9's awk. Many features and extensions over standard awk. Different people will assign different levels of value to said features and extensions. A partial list: - The previously discussed dynamic plug-in facility - And awk-level debugger - A statement count profiler (and a pretty printer) - True arrays of arrays - Many more built-in functions and variables. In retrospect, some of these are just bloat and I'd have been better off without them. Arnold -- Hugo -- Hugo
[9fans] rsc's libtask on embedded
Anyone stripped rsc's libtask for use on a bare metal embedded system, I'am about to do it but if somone already has I could steal it. -Steve
Re: [9fans] Gawk in 9front-ports
On Thursday 09 July 2015 02:49:53 arn...@skeeve.com wrote: However, I'm happy to incorporate portability changes to make porting to Plan 9 easier, if they're reasonable. For portability changes, I think not much is needed. There was an issue with a duplciate case in posix/gawkmisc.c ,(S_IFSOCK S_IFIFO, S_IFIFO is defined as S_IFSOCK in APE). I also did a hack patch to builtin.c because it somehow forgot the definition of uint32_t and I could not figure out why. Other than that, most of the work was manual generation of config.h, mkfile which are things that also should work with configure/make (but I have not tried it). I added inttypes.h and sys/time.h in config.h because some source files assumed that those headers would be pulled in via other headers. That hack would probably be better to put in custom.h. As external dependency, we need some extra gnulib functions (wchar related stuff). If we can get the dlopen thing to work by using this libdynld (apparently from inferno origin, but once ported to nix-os), that would be very cool. As a porter, my prime aim is to stay as true as possible to the intent of the developer and the expectations of the users. Basically, I do porting as a simple mental task to relax (like puzzles, cross word or soduko). For most of you real programmers the stuff I do most likely seems menial and pointless. My process 1. can the porting be done? 2. does it work as expected? 3. (bonus) does anyone find it useful?
Re: [9fans] Gawk in 9front-ports
FWIW: fgb did a stirling script called config which sets up some environment and runs configure under ape. It doesn't always work but often gets close to generating a config.h as linux intended. -Steve
Re: [9fans] Gawk in 9front-ports
On Jul 9, 2015, at 5:19 AM, Steve Simon st...@quintile.net wrote: FWIW: fgb did a stirling script called config which sets up some environment and runs configure under ape. It doesn't always work but often gets close to generating a config.h as linux intended. Configure predates Linux. That, or my memory of using it to bang my head against the perl wall in the 1980s damaged the register. -jas … at least you’re not using Xenix
Re: [9fans] Gawk in 9front-ports
On Thursday 09 July 2015 11:19:33 Steve Simon wrote: FWIW: fgb did a stirling script called config which sets up some environment and runs configure under ape. It doesn't always work but often gets close to generating a config.h as linux intended. part of that script is already fixed since I managed to get -plan9* ' added to the list of OSes in config.sub upstream some years ago.
Re: [9fans] Intel NUCs and Plan 9?
Last night my gateway machine fans making final dying for real sounds and I need a replacement. It's a T42 which was already half dead when I repurposed it to this duty and it has worked for four years. I have RPi2, Beaglebone black etc. But in the end I decided to buy a used T60 for $100. On Jul 9, 2015, at 8:16 AM, arn...@skeeve.com wrote: Raspberry pi isn't what I want. I want to be able to compile / do serious development and being able to run Linux would also help. I'm not comfortable moving outside of Intel architecture and I want the horsepower I can get out of a Haswell or Broadwell. Thanks, Arnold Shingo Onobori onoborishi...@gmail.com wrote: Is the Raspberry Pi2 bad choice? http://www.plan9.bell-labs.com/wiki/plan9/download/ On 2015/07/09 21:18, arn...@skeeve.com wrote: Does anyone have experience using Intel NUCs with Plan 9? I'm looking at http://www.amazon.com/Intel-Next-Unit-Computing-NUC5i3RYK/dp/B00S1ISFOQ/ref=sr_1_9?s=pcie=UTF8qid=1436443454sr=1-9keywords=intel+nuc which is a Broadwell Core i3. Other recommendations for low-cost, small form factor boxes to run Plan 9 would be welcome, preferably with links (:-). Thanks, Arnold
Re: [9fans] rsc's libtask on embedded
I looked at proto, they are just state machines pretending to be threads (imho) - not my style. libtask for me, I hope I can slice it a little and put the non-bear-metal bits in seperate files so I can offer the changes back. co routines plus channels is exactly what I want. -Steve On 9 Jul 2015, at 16:58, Joseph Stewart joseph.stew...@gmail.com wrote: One other thing that I've looked at but never used is Adam Dunkels' protothreads (http://dunkels.com/adam/pt/) although you'd still need to roll your own channel library. On Thu, Jul 9, 2015 at 10:50 AM, Steve Simon st...@quintile.net wrote: The system I am trying to add libtask to has no runtime other than libc. Corrently it is an even based system that uses a min main loop and a twisty maze of nested state machines that all look the same. Hence my desire to add co-routines + channels (i.e. exactly what libtask is) to it. I have no need for the file or network modules but those are easily removed. I don't have the context calls but I do have setjmp/longjmp so that is what I am trying to use. I will shout if it works out. -Steve
Re: [9fans] rsc's libtask on embedded
The system I am trying to add libtask to has no runtime other than libc. Corrently it is an even based system that uses a min main loop and a twisty maze of nested state machines that all look the same. Hence my desire to add co-routines + channels (i.e. exactly what libtask is) to it. I have no need for the file or network modules but those are easily removed. I don't have the context calls but I do have setjmp/longjmp so that is what I am trying to use. I will shout if it works out. -Steve
