http://permalink.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://</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 </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 </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 s</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,</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. C</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,</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 buil</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 inherentl</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,</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</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