http://blog.gmane.org/gmane.comp.lang.concurrency.pop.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/47 <pre> Hi all, One of my final-year project students has been working on a visual design tool (IDE) for occam-pi programs. It's now moderately [1] functional and ready to be broken by the masses! If you (or indeed, your students) fancy having a go, you can find instructions, links for download and a follow-up survey here: http://projects.cs.kent.ac.uk/projects/co620_occblocks/trac/wiki/FeedbackSurvey [1] it works enough to get a feeling for what a complete system/interface could do; documentation is somewhat limited, but we're just trying to get an impression of what people think of the general idea/interface/approach. Cheers, </pre> Fred Barnes 2012-03-06T17:43:51 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/46 <pre> Dear all, There is an opportunity for a 2-year KTP (Knowledge Transfer Partnership) associate position working in the areas of concurrency and embedded systems, specifically to develop Erlang runtimes, libraries and development tools for ARM (and potentially other) based embedded systems. Closing date for applications is the 25th July. Details here: http://tinyurl.com/ktp2486 Please feel free to pass this on to anyone whom you think might be interested. The employer is the University of Kent, but the job will be based primarily in London. Salary up to 29k, with extra top-up available for exceptional candidates. Cheers, Fred </pre> Fred Barnes 2011-07-18T16:01:03 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/45 <pre>An article in the Economist discussing multicore, etc. Doesn't really say much that we do not already know, but interesting to see it discussed at a wider level. Kevin -----Original Message----- From: sicsa-cse-semantics-bounces-snw4NNm4RhuGOBePZluPAvXRex20P6io&lt; at &gt;public.gmane.org [mailto:sicsa-cse-semantics-bounces-snw4NNm4RhuGOBePZluPAvXRex20P6io&lt; at &gt;public.gmane.org] On Behalf Of Jeremy Singer Sent: 13 June 2011 18:54 To: sicsa-cse-semantics-snw4NNm4RhuGOBePZluPAvXRex20P6io&lt; at &gt;public.gmane.org Subject: [SICSA-CSE-semantics] Economist article Hi all, Here is a link to an article about multicore. It's interesting to think how the parallel programming problem is becoming mainstream. Fancy the Economist running an article about Haskell!? http://www.economist.com/node/18750706?frsc=dg%7Ca Cheers, Jeremy The University of Glasgow, charity number SC004401 _______________________________________________ SICSA-CSE-semantics mailing list SICSA-CSE-semantics-snw4NNm4RhuGOBePZluPAvXRex20P6io&lt; at &gt;public.gmane.org https://list-serve.hw.ac.uk/mailman/listinfo/sicsa-cse-semantics Edinburgh Napier University is Edinburgh's top university for graduate employability (HESA 2010), and proud winner of the Queen's Anniversary Prize for Higher and Further Education 2009, awarded for innovative housing construction for environmental benefit and quality of life. This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Edinburgh Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University. Edinburgh Napier University is a registered Scottish charity. Registration number SC018373 </pre> Chalmers, Kevin 2011-06-14T12:43:08 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/44 <pre> Dear Delegates and Potential Delegates, The final programme and joining instructions for CPA 2011 are available at: http://www.wotug.org/cpa2011/programme.shtml The original call for delegates is copied below. If you haven't yet decided to come, it's not too late! All with interests in concurrency and computer science (and, these days, that means all with interests in computer science) will find stimulating, interesting and exciting presentations and papers and lots of opportunity to talk with each other. We'd love to see you in Limerick! Many thanks, Peter Welch. ======================================================================== Communicating Process Architectures 2011 (19-22 June, Limerick, Ireland) - Programme announced - Call for Delegates *********************** - Student Bursaries * wotug.org/cpa2011 * - Keynote Presentation *********************** - Summary of themes from Accepted Papers - Call for Fringe Presentations ======================================================================== Communicating Process Architectures (CPA) 2011 takes place at the University of Limerick, Ireland, 19-22 June, 2011. CPA themes are concurrency at all levels of software and hardware granularity: its ambitions are to present and stimulate discussion on the latest research and development in concurrency theory, practice, education and application. This year, CPA is hosted by Lero, the Irish Software Engineering Research Centre, and co-located with FM 2011 (the 17th International Symposium on Formal Methods), SEW-34 (the 34th Annual IEEE Software Engineering Workshop) and several specialist workshops and tutorials. The provisional programme schedule - complete with all paper titles, authors and abstracts - is now available on the CPA 2011 website: http://www.wotug.org/cpa2011/programme.shtml This is the *CALL FOR DELEGATES*, :). For registration (US$ 460) and booking accommodation (EURO 52 per night, on-campus appartment rooms ensuite with shower and toilet, includes breakfast), please visit: http://www.wotug.org/cpa2011/registration.shtml This page also gives details for applying for WoTUG Student Bursaries (GBP 100) to support attendance by students not in receipt of full-time salaries. Registration and accommodation fees cover all meals (including the conference dinner and two evening receptions) apart from two light meals advised before attending the receptions (where there will be 'finger-food' only, but very tasty!), entry to CPA sessions and one copy of the CPA 2011 proceedings (383 pages). We are very pleased this year to welcome Gavin Lowe, Professor of Computer Science at the University of Oxford Computing Laboratory, as our Keynote speaker. His research over the past two decades has made significant contributions to the field of concurrency, with special emphasis on CSP and the formal modelling of computer security. His paper addresses a long-standing and crucial issue for this community: the verified implementation of CSP external choice, with no restrictions. The accepted papers contain the results from rich seams of research covering many of the key issues in modern computer science, which all seem to concern concurrency in one form or another these days. There are papers on concurrency models and their theory, concurrency pragmatics (the effective use of multicores), language ideas and implementation (for mobile processes, generalised forms of choice), tools to assist verification and performance, applications (large scale simulation, robotics, web servers), benchmarks (for scientific and distributed computing) and, perhaps most importantly, education. They reflect the increasing relevance of concurrency both to express and manage complex problems as well as to exploit readily available parallel hardware. An important feature of CPA conferences are the evening Fringe sessions. This year, because of the evening receptions and dinners, they will be scheduled during the main conference sessions. These sessions are very informal, highly interactive, and sometimes slightly controversial. Any conference delegate is invited to give a Fringe presentation on any topic that they think may be of interest to the conference. A Fringe presentation may last 5-15 minutes. Details of how to offer Fringe talks are on: http://www.wotug.org/cpa2011/fringe.shtml Many thanks and we hope to see you in Limerick, Peter Welch (on behalf of the CPA 2011 Editorial Board). </pre> P.H.Welch 2011-06-13T15:07:52 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/43 <pre> Dear Potential Delegates, Ooops ... there was a mistake in one of the URLs in the Call just made: That takes you to registration for CPA 2009, for which it is a bit late now to attend! The URL should have been: http://www.wotug.org/cpa2011/registration.shtml Many apologies, Peter Welch. </pre> P.H.Welch 2011-05-17T17:39:17 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/42 <pre> Dear Potential Delegates, ======================================================================== Communicating Process Architectures 2011 (19-22 June, Limerick, Ireland) - Programme announced - Call for Delegates *********************** - Student Bursaries * wotug.org/cpa2011 * - Keynote Presentation *********************** - Summary of themes from Accepted Papers - Call for Fringe Presentations ======================================================================== Communicating Process Architectures (CPA) 2011 takes place at the University of Limerick, Ireland, 19-22 June, 2011. CPA themes are concurrency at all levels of software and hardware granularity: its ambitions are to present and stimulate discussion on the latest research and development in concurrency theory, practice, education and application. This year, CPA is hosted by Lero, the Irish Software Engineering Research Centre, and co-located with FM 2011 (the 17th International Symposium on Formal Methods), SEW-34 (the 34th Annual IEEE Software Engineering Workshop) and several specialist workshops and tutorials. The provisional programme schedule - complete with all paper titles, authors and abstracts - is now available on the CPA 2011 website: http://www.wotug.org/cpa2011/programme.shtml This is the *CALL FOR DELEGATES*, :). For registration (US$ 460) and booking accommodation (EURO 52 per night, on-campus appartment rooms ensuite with shower and toilet, includes breakfast), please visit: http://www.wotug.org/cpa2009/registration.shtml This page also gives details for applying for WoTUG Student Bursaries (GBP 100) to support attendance by students not in receipt of full-time salaries. Registration and accommodation fees cover all meals (including the conference dinner and two evening receptions) apart from two light meals advised before attending the receptions (where there will be 'finger-food' only, but very tasty!), entry to CPA sessions and one copy of the CPA 2011 proceedings (383 pages). We are very pleased this year to welcome Gavin Lowe, Professor of Computer Science at the University of Oxford Computing Laboratory, as our Keynote speaker. His research over the past two decades has made significant contributions to the field of concurrency, with special emphasis on CSP and the formal modelling of computer security. His paper addresses a long-standing and crucial issue for this community: the verified implementation of CSP external choice, with no restrictions. The accepted papers contain the results from rich seams of research covering many of the key issues in modern computer science, which all seem to concern concurrency in one form or another these days. There are papers on concurrency models and their theory, concurrency pragmatics (the effective use of multicores), language ideas and implementation (for mobile processes, generalised forms of choice), tools to assist verification and performance, applications (large scale simulation, robotics, web servers), benchmarks (for scientific and distributed computing) and, perhaps most importantly, education. They reflect the increasing relevance of concurrency both to express and manage complex problems as well as to exploit readily available parallel hardware. An important feature of CPA conferences are the evening Fringe sessions. This year, because of the evening receptions and dinners, they will be scheduled during the main conference sessions. These sessions are very informal, highly interactive, and sometimes slightly controversial. Any conference delegate is invited to give a Fringe presentation on any topic that they think may be of interest to the conference. A Fringe presentation may last 5-15 minutes. Details of how to offer Fringe talks are on: http://www.wotug.org/cpa2011/fringe.shtml Many thanks and we hope to see you in Limerick, Peter Welch (on behalf of the CPA 2011 Editorial Board). </pre> P.H.Welch 2011-05-17T17:18:40 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/41 <pre>Hi, RESIZE.MOBILE.ARRAY.1D is a compiler instrinsic, a function built-in to the compiler. It's actually implemented in the mobile type part of the runtime, where it efficiently resizes the mobile. Where efficient means it may do any space reallocation. As RESIZE.MOBILE.ARRAY.1D can act on any mobile type, it has an parameter of type MOBILE.ANY. Again, this is a special type for use inside the compiler, so you can't initialise a mobile of this type. I wanted to create a PROC RESIZE.MOBILE.ARRAY.2D from scratch, but A 2D version of the process would need to be implemented in the compiler and runtime; however, at present multi-dimensional mobile types are not supported. As per our mails off list, the present solution is to flatten multi-dimensional types to single-dimensional arrays. Cheers, Carl </pre> Carl Ritson 2010-10-27T08:41:38 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/40 <pre>Hello Could anyone please spell out how MOBILE.ANY works and especially RESIZE.MOBILE.ARRAY.1D? I wanted to create a PROC RESIZE.MOBILE.ARRAY.2D from scratch, but instantiating MOBILE.ANY is not possible (and supporting documentation is equally hard to find). Or course, problem solved by using RESIZE.MOBILE.ARRAY.1D, but still the mystery remains :). Thanks, Teodor </pre> Teodor Ghetiu 2010-10-26T14:47:15 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/39 <pre>Pavan, I will not -- and cannot in good conscience -- write code for you. I don't know what this project is for, I don't know who is involved with it, and I don't know to what standards you're being held. All of this makes me very hesitant to give more advice than we already have. I have a good bit of work to get done myself in the coming days, but I've scanned you code. That's about all I'm willing to do right now. From what I've seen, you're misusing Replicated Sequences and you're not being terribly careful with you indentations. The later is simply syntax that you should remain aware of, and that the compiler will catch. The Replicated Sequences are a bit different than the C-like loops you seem familiar with, and pretty much every Occam reference will touch on those differences. https://www.cs.kent.ac.uk/research/groups/plas/wiki/OccamPiReference#head-7ce0f0ecb0216fcb426a839783b03e034edd7b55 There's a link to the Occam-pi reference guide, to the section that talks about how replicated structures work. If you let us -- the user's mailing list -- know the specific errors your code is throwing or what you don't understand from the documentation and references we've linked for you, we'll gladly help you with that. Good luck, -Drew On Tue, Jul 20, 2010 at 9:33 AM, kvn pavan kumar &lt;kvn.pavankumar-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;wrote: </pre> Michael Pirrone-Brusse 2010-07-21T00:27:36 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/38 <pre>Hey Pavan, That looks like a pretty complicated project you're taken on to get done in a week. It could be a lot of fun, but that's a very ambitious time-frame you have. Occam does require correct indentation in code to properly compile, so I'm guessing there's something a little off in the code you've been writing. Just glancing at the website Adam linked last week -- http://pop-users.org/wiki/occam-pi/LearningResources -- it looks like his style guide might be something you want to read; https://www.cs.kent.ac.uk/research/groups/plas/wiki/OccamPiStyleGuide. I can't say I know what you mean when you say 'usage of instructions', and I'm pretty sure part of that's because I've no idea what you're code is, or what the specific error that you're getting is. Like a few of us have already said, if you'd be more specific with what your problems are, what your code is supposed to be doing, and what errors you're getting, it'd make it possible for us to point you in the right direction. Best, -Drew On Mon, Jul 19, 2010 at 10:12 AM, kvn pavan kumar &lt;kvn.pavankumar-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt;wrote: </pre> Michael Pirrone-Brusse 2010-07-19T15:22:16 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/37 <pre> This'll depend on what you're trying to do -- what sort of programs do you want to write, and for what sort of platform? This page collects resources that should be useful for people who're new to the language -- it's probably a good starting point for you: http://pop-users.org/wiki/occam-pi/LearningResources Hope this helps, </pre> Adam Sampson 2010-07-13T08:44:11 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/36 <pre> Well, if you want to actually get help you need to be a bit more specific about what you are seeking. JA </pre> Joël-Alexis Bialkiewicz 2010-07-13T08:04:09 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/35 <pre>Hi, I need some help in writing programs in Occam Language. </pre> Pavan 2010-07-13T02:57:34 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/34 <pre> Out of tree builds work fine, no configuration is left in the source tree. The automatic building of packages for Mac and Windows does out of tree builds to build for multiple archs (Mac/Windows and AVR). Even though there are perhaps a few places in the build system that could do with a bit of love, out of tree builds do work, and perhaps it would be good to update the documentation to indicate that. Am I right in thinking your troubles might have arisen from starting out using the 'build' script? I personally never use use that script and run ../configure from an appropriate out of source tree. I think that script made sense in the past before the build system was given a seeing to by Adam, I'm not sure it is that helpful anymore. Really people should be able to follow the 'configure, make, make install' instructions that they'd have to perform on any other automake/autoconf package and if they can't do that, perhaps they should just use the binary distributions we are working hard on getting working. Cheers, Christian </pre> Christian Jacobsen 2010-07-08T15:44:06 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/33 <pre> It is only recently that we've seen an influx of people willing to throw in and help out. We have, as a core group, never "planned" on new people showing up willing to dive in. I did the work you see in the tree on SCons because I find it more understandable than autotools. That is, I preferred the fact that it is "just a Python program" to the (for me) more confusing set of macros and expressions in... whatever the languages are called that make up the autotools suite. My willingness to explore it came from my earlier (several years back) exploration of SCons, where I found it "just worked" on Windows in a way that I struggled to get the autotools working. Part of me says "implement it, and we'll add it." However, the other part of me says "as a team (including the new contributor), we'd need to agree that it would be supported." The build system has, in the last two years, been identified as a *critical* part of the project -- inglorious, but essential. Adam did the hard work on making the build system, and currently understands it better than anyone else. This summer, I finally sat down and started reading through makefiles and the like, and picked up a book on Make just for good measure. Point being... we have a system now that handles a reasonably large project, and we cannot "switch" unless the new build system does everything the current build system does, plus does it "better" in one or more dimensions. (Eg. It is easier to build on Windows because of how environments are handled, or it is smaller and simpler to understand, or it handles multiple architectures (host and/or target) better, or ...) My concern this month is OSCON, and after OSCON my concern will be the 2011-2012 academic year. At no point until next summer will I likely have any time to focus on build systems. Without enumerating, I can say most of the core team is busy for a few months, and our most pressing target (a large conference where we want to announce the release of binary installers) is pressing. I don't know a lot about the differences, and cannot tell you why one is "better" than the other. What I can say, though, is that changing build systems would mean a fundamental change in the project and a new kind of maintenance concern. No one in the current (core) group is well versed in SCons, and you would have to help us (and, specifically, the primary author of the current build system, Adam) understand why we should switch. If there is only one primary problem right now -- out-of-tree builds in the same filesystem -- then perhaps we should ticket that, and see if we can't fix it... either through documentation or by other means. (Or, perhaps it can't be fixed, and that's the problem.) Regardless, discussion of needs and possible fixes, as opposed to build-system-preference-discussion, is probably the way to go. Our documentation reflects the size, and relatively static nature for some time, of the core group. Part of our reason for automating build processes (past "configure ; make ; make install") is that the build system is already complex, and it will only become moreso as we support more targets on more hosts. It has not, until recently, been "worthwhile" to have ample documentation for developers -- because it wasn't possible to have any. (CS Projects is only... two years old? Three? Point being, the source wasn't even casually available a few years ago.) So it does need to be improved. Automation is part of that -- the packaging scripts become a resource unto themselves. Better documentation in the wiki is another. I don't think you'll get any disagreement there. That was longer than I expected, but it might be somewhat clear. I'm off to a meeting, and will check back in later today. Cheers, Matt </pre> Matt Jadud 2010-07-07T11:30:52 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/32 <pre>Adam, On Tue, 2010-07-06 at 11:54 +0100, Adam Sampson wrote: Clearly you have had a bad experience with SCons, I have not -- likewise many others out there. Perhaps by diktat SCons is not an option for KRoC, but I think some line of reasoning would be appropriate? I too have had poor experience with CMake, I think the specification language is clumsy and restrictive -- at least when I last looked at it a while back. I think they would have been much better just using Lisp as the underlying engine for their DSL. CMake works a lot better cross platform than Make or Autotools, but I agree with you there are serious barriers. Perhaps they have fixed them recently but I suspect not. My reason for even contemplating it is that it is possible to use CMake in the workflow where there is one central source and multiple targets needing to be built. Autotools, Make and Waf are nigh on impossible to work with in this sort of context. They have a built-in assumption that there is one target for any given build context. CMake and SCons get round this problem quite sanely. I think Waf is an excellent replacement for Autotools. Waf however retains the Autotools "mindset", you download on your one and only machine, and install for that machine. Fine if that is the only workflow. Dreadful where you have multiple architectures sharing a filestore. Most large projects are complicated to build. It is that Autotools is a (very sophisticated, and well crafted) hack over Make and there are better tools that would make the complexity of the build easier to work with. Your resource management argument implies fixed resources. What about the case where new effort is available. Is your position that the current build is the only one that will be even in that context? If so then I think it would be appropriate to remove all the SCons stuff since it implies that there is work on an alternative tot he Autotools build. In which case the standard instructions need amending as by following them I got an horrendous in-tree mess. I will investigate further given the pointer, and report back. My worry though is that even with out-of-tree builds there is still the potential issue that a source tree is configured for a given target and switching from one target to another is a real pain. </pre> Russel Winder 2010-07-07T07:58:48 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/31 <pre> Speaking as someone who's spent a *lot* of time over the last few years packaging third-party software for Unix systems, SCons is a royal pain in the neck from the point of view of end users, sysadmins and packagers. Using it for KRoC is not an option. I don't think it's really accurate to call CMake "works everywhere", since it's necessary to write completely different configuration tests in your CMakeLists for Windows and Unix-like platforms -- and I have been extremely unimpressed with the quality of CMake's provided tests. waf, on the other hand, is the best of the automake replacements that I've experimented with. It seems to have identified and fixed most the problems with other systems while not throwing away the stuff from automake that works well; many of the projects I package that were previously using SCons (generally audio-related) have migrated to waf. If we were looking for a future build system for KRoC, I'd certainly look at waf first. It's worth bearing in mind that KRoC is inherently complicated to build for a number of reasons, though -- it's not going to be a *lot* simpler in any other system than it is in automake. I think it's difficult to justify the effort necessary to move to a new build system at this point unless we have a good idea of where we want the project to go in the future. Erm -- out-of-tree builds are a standard feature of automake, and they work perfectly well for KRoC. The cross-building instructions on the KRoC wiki use an out-of-tree build, the buildbot tests both ways, and I always use them for KRoC development myself since I'm usually testing my changes on three architectures. Thanks, </pre> Adam Sampson 2010-07-06T10:54:55 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/30 <pre>[ . . . ] A Carl did indeed chip in. Thanks to both of you for reacting speedily to my query. No longer being in academia, I am no longer constrained by the publish or perish treadmill. But then I don't have a steady income either. As with all things some people find some things interesting: I find build interesting, even if it is not on your "interesting" list ;-) Regarding platforms, SCons, Waf, and indeed CMake, thrash Autotools in the "works everywhere, including Windows" department. So if Windows is an issue then Autotools is a problem. Though for me the real issue is "in tree" builds, all build should be out of tree: I find the fact that KRoC builds in tree irritating. The real irritant is though that it is not possible to quickly and easily build for multiple targets platforms from the same shared source -- I build for Mac OS X, Ubuntu, Debian and Solaris from an NFS mount. This is tricky to do with Waf, but fundamentally easy with SCons and indeed CMake. Wish spells that actually work, and work correctly, also come in handy. </pre> Russel Winder 2010-07-06T07:16:27 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/29 <pre>[ . . . ] This implies that KRoC detects the number of processors and uses a managed thread pool. Is there some way of accessing the number of processors detected? Thanks for the pointer. Google had failed to lead me to this one -- most material indexed appears to be from the 2000--5 period and so probably seriously out of date. All the material I have been able to find via Google is focused on academic research: there seems little technology transfer material trying to reinvigorate occam as a programming language for today. Though I suspect Go will now supplant occam as the process-based imperative language of choice. Thanks for this, I have emailed separately off-list -- protection against my occam code being stupidly awful! Using Ubuntu Lucid with KRoC Trunk, the two programs execute extremely sequentially on on my twin Xeon (effectively 8-core, but at the cache level it is more complicated than that!) workstation. Ditto using Ubuntu Lucid and Debian Testing on my single processor two-core laptop. Any help getting this occam code running really in parallel before I leave for EuroPython 2010 (where I want to use the code as an example) would be gratefully received. BTW the kroc command always uses a dynamic linking to libraries approach. Is there a way of getting a statically linked executable? I tries --cc-opts=-static but this just gave me link errors mostly associated with dlopen. Thanks. </pre> Russel Winder 2010-07-06T06:48:32 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/28 <pre>Hi Russell, On 2010/07/05, at 19:58, Russel Winder wrote: occam-pi processes are multiplexed at runtime across a set of kernel threads (one per core). A mapping of one process to one thread would be inefficient for very large numbers of threads. The following paper provides details of the scheduling involved: http://www.cs.kent.ac.uk/pubs/2009/2928/index.html There are some cases where processes are not executed in parallel. In particular certain types of pipeline suffer due to algorithms designed to enhance cache locality. Optimising these cases is part of my ongoing research. It might be possible to work around these, by tweaking your occam sources, if they are indeed causing your code to execute sequentially. I'd be happy to look at your code, on or off list. Cheers, Carl </pre> Carl Ritson 2010-07-05T19:51:26 http://permalink.gmane.org/gmane.comp.lang.concurrency.pop.user/27 <pre> It shouldn't come to that. It's just that I'm in GMT-5, but most of my efforts focus on embedded platforms. Carl or Adam will likely chime in when they see this thread, and give you the Right Answer. We're close to having a scripted solution for building installers for all platforms (Mac, Win, Linux). Once we get there, we could consider this... particularly if it made building on Windows simpler by an order or two of magnitude. If it doesn't, then touching the build system will likely remain a low priority (in lieu of more interesting/publishable work). There are differing opinions in the core group w.r.t. build systems. Personally, I'd like them all to go away, and be replaced with a magic wand... Cheers, Matt </pre> Matt Jadud 2010-07-05T19:48:31 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.concurrency.pop.user