Menu
▾
▴
orcc-devel — Orcc development mailing list
This list is closed, nobody may subscribe to it.
| 2011 |
Jan
|
Feb
(3) |
Mar
(3) |
Apr
(9) |
May
|
Jun
(6) |
Jul
(16) |
Aug
|
Sep
(8) |
Oct
(8) |
Nov
(4) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(14) |
Feb
(20) |
Mar
(34) |
Apr
(36) |
May
(23) |
Jun
(25) |
Jul
(2) |
Aug
|
Sep
(6) |
Oct
(8) |
Nov
(11) |
Dec
|
| 2013 |
Jan
(10) |
Feb
|
Mar
(5) |
Apr
(1) |
May
(2) |
Jun
(10) |
Jul
|
Aug
(2) |
Sep
(1) |
Oct
(6) |
Nov
(4) |
Dec
(1) |
| 2014 |
Jan
(10) |
Feb
(2) |
Mar
(12) |
Apr
(5) |
May
(3) |
Jun
|
Jul
(4) |
Aug
|
Sep
(18) |
Oct
(7) |
Nov
(1) |
Dec
(1) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(6) |
Jul
(16) |
Aug
|
Sep
|
Oct
(5) |
Nov
(5) |
Dec
(1) |
| 2016 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
(2) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Simone C. B. <sim...@ep...> - 2017-01-24 16:04:23
|
Dear Eduardo, thank you for your feedback. _@all: will be nice if you can send me the improvements you made over the current release so I'll point it out on the release tag description._ Thank you for your collaboration, Cheers Simone On 01/24/2017 04:08 PM, Eduardo Juarez Martinez wrote: > Hi Simone, > > From our side is ok. The new release would updgrade papify. > > Cheers, > Edu > > On 24-01-2017 12:18, Simone Casale Brunet wrote: >> Hi Rob, >> >> thank you for your feedback. >> >> No problem, we can update end of February and define a deadline to >> freeze a release. >> >> Cheers, >> >> Simone >> >> On 01/24/2017 12:06 PM, Rob Stewart wrote: >> >>> Hi Simone, >>> >>> A new release is a good idea. Will you give me a few weeks to pull >>> out the experimental transformations implementation into a separate >>> plugin that, for now, won't be part of the 2.4.0 release. I want to be >>> more sure that the transformations of program-preserving, and I'm >>> working towards verification tooling now and for the next few months. >>> >>> I've a deadline of the 14 February, but should be able to get round >>> to it by the end of February. If that's acceptable, I'll email you >>> offline once I've factored out my code into its own plugin. >>> >>> As it happens, issue #143 was raised by one of 5 Masters students >>> working with me on CAL application code. In the interim, thanks for >>> updating the nightly build to help him out. >>> >>> -- >>> Rob >>> >>> On Tue, 24 Jan 2017 at 09:22 Simone Casale Brunet >>> <sim...@ep...> wrote: >>> >>>> Dear Developers, >>>> >>>> the latest version of Orcc dates back the 3rd Dec. 2014. As >>>> recently pointed out by a user (see issue #143) this version has some >>>> troubles with Eclipse Neon. However, the nightly build works fine. >>>> >>>> If there are no disagreement, I will prepare the 2.4.0 release and >>>> update the orcc eclipse repository site. >>>> >>>> Cheers, >>>> >>>> Simone >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>>> [1]_______________________________________________ >>>> Orcc-devel mailing list >>>> Orc...@li... >>>> https://lists.sourceforge.net/lists/listinfo/orcc-devel [2] >> >> >> Links: >> ------ >> [1] http://sdm.link/slashdot >> [2] https://lists.sourceforge.net/lists/listinfo/orcc-devel >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> >> _______________________________________________ >> Orcc-devel mailing list >> Orc...@li... >> https://lists.sourceforge.net/lists/listinfo/orcc-devel > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Orcc-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orcc-devel |
|
From: Eduardo J. M. <ej...@se...> - 2017-01-24 15:25:11
|
Hi Simone, From our side is ok. The new release would updgrade papify. Cheers, Edu On 24-01-2017 12:18, Simone Casale Brunet wrote: > Hi Rob, > > thank you for your feedback. > > No problem, we can update end of February and define a deadline to > freeze a release. > > Cheers, > > Simone > > On 01/24/2017 12:06 PM, Rob Stewart wrote: > >> Hi Simone, >> >> A new release is a good idea. Will you give me a few weeks to pull >> out the experimental transformations implementation into a separate >> plugin that, for now, won't be part of the 2.4.0 release. I want to be >> more sure that the transformations of program-preserving, and I'm >> working towards verification tooling now and for the next few months. >> >> I've a deadline of the 14 February, but should be able to get round >> to it by the end of February. If that's acceptable, I'll email you >> offline once I've factored out my code into its own plugin. >> >> As it happens, issue #143 was raised by one of 5 Masters students >> working with me on CAL application code. In the interim, thanks for >> updating the nightly build to help him out. >> >> -- >> Rob >> >> On Tue, 24 Jan 2017 at 09:22 Simone Casale Brunet >> <sim...@ep...> wrote: >> >>> Dear Developers, >>> >>> the latest version of Orcc dates back the 3rd Dec. 2014. As >>> recently pointed out by a user (see issue #143) this version has some >>> troubles with Eclipse Neon. However, the nightly build works fine. >>> >>> If there are no disagreement, I will prepare the 2.4.0 release and >>> update the orcc eclipse repository site. >>> >>> Cheers, >>> >>> Simone >>> >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> [1]_______________________________________________ >>> Orcc-devel mailing list >>> Orc...@li... >>> https://lists.sourceforge.net/lists/listinfo/orcc-devel [2] > > > > Links: > ------ > [1] http://sdm.link/slashdot > [2] https://lists.sourceforge.net/lists/listinfo/orcc-devel > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > > _______________________________________________ > Orcc-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orcc-devel |
|
From: Simone C. B. <sim...@ep...> - 2017-01-24 11:19:07
|
Hi Rob, thank you for your feedback. No problem, we can update end of February and define a deadline to freeze a release. Cheers, Simone On 01/24/2017 12:06 PM, Rob Stewart wrote: > Hi Simone, > > A new release is a good idea. Will you give me a few weeks to pull out > the experimental transformations implementation into a separate plugin > that, for now, won't be part of the 2.4.0 release. I want to be more > sure that the transformations of program-preserving, and I'm working > towards verification tooling now and for the next few months. > > I've a deadline of the 14 February, but should be able to get round to > it by the end of February. If that's acceptable, I'll email you > offline once I've factored out my code into its own plugin. > > As it happens, issue #143 was raised by one of 5 Masters students > working with me on CAL application code. In the interim, thanks for > updating the nightly build to help him out. > > -- > Rob > > > On Tue, 24 Jan 2017 at 09:22 Simone Casale Brunet > <sim...@ep... <mailto:sim...@ep...>> wrote: > > Dear Developers, > > the latest version of Orcc dates back the 3rd Dec. 2014. As > recently pointed out by a user (see issue #143) this version has > some troubles with Eclipse Neon. However, the nightly build works > fine. > > If there are no disagreement, I will prepare the 2.4.0 release and > update the orcc eclipse repository site. Cheers, Simone > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! > http://sdm.link/slashdot_______________________________________________ > Orcc-devel mailing list > Orc...@li... > <mailto:Orc...@li...> > https://lists.sourceforge.net/lists/listinfo/orcc-devel > |
|
From: Rob S. <rob...@gm...> - 2017-01-24 11:06:44
|
Hi Simone, A new release is a good idea. Will you give me a few weeks to pull out the experimental transformations implementation into a separate plugin that, for now, won't be part of the 2.4.0 release. I want to be more sure that the transformations of program-preserving, and I'm working towards verification tooling now and for the next few months. I've a deadline of the 14 February, but should be able to get round to it by the end of February. If that's acceptable, I'll email you offline once I've factored out my code into its own plugin. As it happens, issue #143 was raised by one of 5 Masters students working with me on CAL application code. In the interim, thanks for updating the nightly build to help him out. -- Rob On Tue, 24 Jan 2017 at 09:22 Simone Casale Brunet < sim...@ep...> wrote: > Dear Developers, > > the latest version of Orcc dates back the 3rd Dec. 2014. As recently pointed out by a user (see issue #143) this version has some troubles with Eclipse Neon. However, the nightly build works fine. > > If there are no disagreement, I will prepare the 2.4.0 release and update the orcc eclipse repository site. > > > > Cheers, > > > > Simone > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Orcc-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orcc-devel > |
|
From: Simone C. B. <sim...@ep...> - 2017-01-24 09:22:50
|
Dear Developers, the latest version of Orcc dates back the 3rd Dec. 2014. As recently pointed out by a user (see issue #143) this version has some troubles with Eclipse Neon. However, the nightly build works fine. If there are no disagreement, I will prepare the 2.4.0 release and update the orcc eclipse repository site. Cheers, Simone |
|
From: Rob S. <rob...@gm...> - 2016-05-21 15:25:02
|
Hi, We've added a math library of functions to the orc-apps repository. It supports addition, subtraction, multiplication and division of floating point numbers using only 32bit integers that host binary string representations of IEEE floating point numbers. This library could be useful for CAL programmers who require floating point numeric precision whilst compiling CAL to a processor architecture that does not include a floating point unit in hardware. About the module: Floating point numbers are represented with 32 bits using the IEEE754 floating point representation, specified in "IEEE Standard for Binary Floating-Point Arithmetic", Institute of Electrical and Electronics Engineers, 1985. This CAL implementation is based on SoftFLoat, a C library for floating point arithmetic using 32bit binary strings, see "Berkeley SoftFloat Release 3: Library Interface", University of California, Berkeley, February 2015. The implementations of the arithmetic operators involve separating binary strings to sign, mantissa and biased exponent components, applying comparison, shift and integer based operations on these parts, before reconstructing a new binary string result. The floating point implementations of division and square root following the Goldschmidt algorithm, specified in "Applications of Division by Convergence", MIT, June 1964. The function API is: Add (uint(size=32) a, uint(size=32) b) --> uint(size=32) Sub (uint(size=32) a, uint(size=32) b) --> uint(size=32) Mul (uint(size=32) a, uint(size=32) b) --> uint(size=32) Div (uint(size=32) a, uint(size=32) b) --> uint(size=32) The top level functions: https://github.com/orcc/orc-apps/blob/master/System/src/std/util/MathFloatingPoint.cal The internal implementation: https://github.com/orcc/orc-apps/blob/master/System/src/std/util/internal/MathFloatingPointInternal.cal Consider this library experimental. -- Rob |
|
From: Alexande S. <Ale...@in...> - 2016-03-24 13:50:28
|
Le 23/03/2016 20:13, Mickaël Raulet a écrit : > I am forwarding your email to orcc's mailing list. I hope they can > support you. > > I hope this helps you. > > Mickael > > Sent by my iPhone > > Le 23 mars 2016 à 15:04, <w....@ut... > <mailto:w....@ut...>> <w....@ut... > <mailto:w....@ut...>> a écrit : > >> Dear Mickaël, >> >> I am a PhD Student in the University of Twente, Netherlands. I worked >> on generating the energy-optimal schedules of dataflow graphs. Now, I >> am interested in validating the generated schedules on a FPGA-based >> platform. For this purpose, I need a C code of any SDF use-case. >> >> Recently, I came across your paper “SYNTHESIZING HARDWARE FROM >> DATAFLOWPROGRAMS: AN MPEG-4 SIMPLE PROFILE DECODER CASE STUDY”, where >> you generated C and HDL files for an MPEG-4 decoder. Is it possible, >> if you can provide me with the C file? Or if you can guide me to the >> right direction? >> >> Looking forward to hear from you soon. >> >> Thank you in advance. >> >> Regards, >> >> -- >> >> Waheed Ahmad >> >> FMT/University of Twente, Netherlands >> >> Ph: +31 53 489 5498 >> >> http://wwwhome.ewi.utwente.nl/~ahmadw/ >> <http://wwwhome.ewi.utwente.nl/%7Eahmadw/> >> > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 > > > _______________________________________________ > Orcc-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orcc-devel Dear Waheed, you can find a tutorial to generate/use a HEVC decoder from a dataflow description with Orcc : http://orcc.sourceforge.net/tutorials/make-an-hevc-decoder/ Please read the informations you can find under "Getting Started", "Getting involved" and "Tutorials" sections : http://orcc.sourceforge.net/ You should be able to do the same with the MPEG4-SP application present in the RVC package. At the begining, please use the C Backend of Orcc. For the HDL/FPGA things I'm not sure what is the best option for you. Best Regards. -- Alexandre Sanchez INSA de Rennes - Département EII IETR - Groupe Image Bureau 216 - Bat. 10 20, Avenue des Buttes de Coësmes CS 70839 35708 Rennes Cedex 7 Tel: (+33)2 23 23 88 17 |
|
From: Mickaël R. <Mic...@in...> - 2016-03-23 19:13:43
|
I am forwarding your email to orcc's mailing list. I hope they can support you. I hope this helps you. Mickael Sent by my iPhone > Le 23 mars 2016 à 15:04, <w....@ut...> <w....@ut...> a écrit : > > Dear Mickaël, > > I am a PhD Student in the University of Twente, Netherlands. I worked on generating the energy-optimal schedules of dataflow graphs. Now, I am interested in validating the generated schedules on a FPGA-based platform. For this purpose, I need a C code of any SDF use-case. > > Recently, I came across your paper “SYNTHESIZING HARDWARE FROM DATAFLOWPROGRAMS: AN MPEG-4 SIMPLE PROFILE DECODER CASE STUDY”, where you generated C and HDL files for an MPEG-4 decoder. Is it possible, if you can provide me with the C file? Or if you can guide me to the right direction? > > Looking forward to hear from you soon. > > Thank you in advance. > > Regards, > -- > Waheed Ahmad > FMT/University of Twente, Netherlands > Ph: +31 53 489 5498 > http://wwwhome.ewi.utwente.nl/~ahmadw/ > |
|
From: Marco M. <mar...@ep...> - 2015-12-01 15:01:36
|
Lionel, yes you have raised several interesting questions to which Rob has already given some answers. Before giving mine, I would like to better understand your problems/questions. In particular your question: "This is also related to the question of multi-dimensional arrays in rvc-cal. I know you cannot declare FIFOs manipulating multi-dim tokens. I also am aware of the possibility to restructure a 1D input data stream into a local 2D data structure, and _then_ write loop nests on those local arrays. I think this is cumbersome and I fear this to be relatively inefficient if used frequently (lots of data duplication typically). So a question related to the previous one is: does anyone feel the need for multi-dimensional FIFOs. As anybody been working on integrating this to CAL? If yes what were the outcomes? If no, why?" What kind of problems or algorithms are you thinking of when you want to use multidimensional arrays? Do you use them as read-only to generate other data? Or do you access them randomly or selectively? Which level of parallelism do you want to achieve? In fact depending on the nature of data usage/generation (read-only, write only) or access (only part of data, all data, by regular or irregular accesses) you can use CAL actors and network in different ways and apply different optimization strategies for implementations (also depending on the architecture of the processing system you want to use). In fact in our "video" experience the Decoded Picture Buffer (that can be seen as a 3D array) is handled differently (processed as internal variable, streamed to different actors via FIFOs etc etc .... depending on the type of processing applied and on the level of parallelism that we want to achieve ........ More details are available if you need and maybe a skype call would be more efficient to better understand each others .... In fact it is not clear to me if you think to multidimensional FIFO as a potential solution for writing more compact dataflow code/networks or as a representation for deriving implementation optimizations. Cheers. Marco On 27.11.2015 22:44, Rob Stewart wrote: > Hi Lionel, > > Interesting questions about loop analysis and loop optimisation > techniques, and their applicability in the dataflow setting. It's > something we at Heriot-Watt University have been thinking about > recently, too. > > First, let's take a step back from `foreach` and the syntactic > restrictions it imposes, and think more about the parallelism > opportunities that CAL's underlying DPN semantics offer. Imperative > languages often treat arrays as first class citizens, and any modern > compiler will generate vectorised machine code from loops over arrays. > > I regard CAL's arrays and `foreach` loops as 2nd class sequential > citizens. Streams are the first class data structure of the DPN > model. Parallelism is expressed as the connection of actors that map > functions over partial streams flowing through their composition. So > whilst `for` loops over arrays provide parallelisation opportunities > other languages, mapping *actors* over *streams* provide > parallelisation opportunities in the dataflow setting. CAL's `foreach` > statement is little more than a convenience, it isn't to do with > parallelism and should only be used when an actor requires a > contiguous region of a stream in order to fire the computation it > hosts. > > If you want to target multicore architectures that has only a small > number of processing elements, your dataflow graphs may exhibit too > much parallelism. In these cases, you might want to sequentialise your > graph. The `foreach` construct is a good tool for this > job. Introducing `foreach` loops could be used to encapsulate a > sequence of computations previously pipelined over multiple actors, > into a more coarsely grained single actor. Fusing actor pipelines into > a single actor's finite state machine is another common solution for > coarsening actors. > > Perhaps what you have in mind is analysis analysis of `foreach` loops, > and their transformations to dataflow parallelism. I've not come > across much in the way of dataflow language implementations that do > loop optimisation, so I'd be very interested to hear of dataflow > compilers that do. It's one of a handful of dataflow transformations > we've recently written about, for CAL in fact. > > "Profile Guided Dataflow Transformation for FPGAs and CPUs". Robert > Stewart , Deepayan Bhowmik, Andrew Wallace, Greg Michaelson. Journal > of Signal Processing Systems, October 2015. > http://link.springer.com/article/10.1007%2Fs11265-015-1044-y > > Alternatively, rather than analysing loops, another approach is to > abstract from the dataflow setting altogether, to a higher level > language with no loops or explicit expression of parallelism. We're > experimenting with that idea, in the design and implementation of our > RIPL language based on algorithmic skeletons, which we compile down to > parallel dataflow graphs expressed with CAL. Here's an abstract > describing that work: > > "RIPL: An Efficient Image Processing DSL for FPGAs". Robert Stewart , > Deepayan Bhowmik, Andrew Wallace, Greg Michaelson. FPGAs for Software > Programmers at FPL. London, 2015. > http://www.macs.hw.ac.uk/~rs46/papers/fsp2015/fsp-2015.pdf > <http://www.macs.hw.ac.uk/%7Ers46/papers/fsp2015/fsp-2015.pdf> > > The Orcc compiler has a transformations framework, which could be used > for experimenting with implementations of loop analysis and loop > transformations. Happy to talk in more detail if that's something > you'd like to explore! > > Orcc veterans: please do contend any contentious points I've written! > > -- > Rob Stewart > Computer Science, Heriot Watt University > W: http://www.macs.hw.ac.uk/~rs46/ <http://www.macs.hw.ac.uk/%7Ers46/> > > > On 27 November 2015 at 08:47, Lionel Morel <lio...@in... > <mailto:lio...@in...>> wrote: > > Dear all, > I’m prospecting for a potential research project on the > applicability of loop-optimization techniques to the efficient > compilation of dataflow programs. > The advantages I see in considering these questions at the cal > level instead of the C code generated are: > - cal uses a foreach syntax that’s way nicer to handle by loop > optimization tools (typically the polyhedral models) than the > while implementation we find in the C generated > - doing this at the C level would lead us towards pointer analysis > techniques that one should avoid when possible. > - Most importantly, in the long term, we're interested in looking > at the interaction between loop optimizations applied at the > sequential code level (inside actors) and the possibilities for > re-structuring the dataflow graph (actor splitting, merging, etc). > > So my question is really addressed to people writing actual > decoders in rvc-cal: > could you tell me if you use loop nests inside the actors’ code > and what are the usual sizes of those loop nets when they are > used. I have seen such foreach loops in the code of some actors. > But I’m not familiar enough with what actors actually do to make a > proper sense out of those and decide if they are costly operations > that would benefit from further optimizations or not. In > particular, determining the size of these loops is tricky as some > depend on input tokens which may have “runtime properties” that > typically limit their range. > > This is also related to the question of multi-dimensional arrays > in rvc-cal. I know you cannot declare FIFOs manipulating multi-dim > tokens. I also am aware of the possibility to restructure a 1D > input data stream into a local 2D data structure, and _then_ write > loop nests on those local arrays. I think this is cumbersome and I > fear this to be relatively inefficient if used frequently (lots of > data duplication typically). So a question related to the previous > one is: does anyone feel the need for multi-dimensional FIFOs. As > anybody been working on integrating this to CAL? If yes what were > the outcomes? If no, why? > > If this rings any bell to someone on the list, I’d be happy to > discuss this further. > Best regards. > Lionel > > > -- > Lionel Morel > MCF INSA Lyon / Laboratoire CITI-INRIA > Équipe Socrate > > > ------------------------------------------------------------------------------ > _______________________________________________ > Orcc-list mailing list > Orc...@li... > <mailto:Orc...@li...> > https://lists.sourceforge.net/lists/listinfo/orcc-list > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Orcc-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orcc-devel |
|
From: Hervé Y. <hyv...@gm...> - 2015-11-27 22:46:48
|
Hi Lionel, Rob, Quick answer from my point of view: Video coding application does not offer you loops deep enough to do any optimization. Other image applications could feet with your needs but they are mostly static and then CAL is probably not the best choice. Cheers, Hervé > Le 27 nov. 2015 à 19:44, Rob Stewart <rob...@gm...> a écrit : > > Hi Lionel, > > Interesting questions about loop analysis and loop optimisation > techniques, and their applicability in the dataflow setting. It's > something we at Heriot-Watt University have been thinking about > recently, too. > > First, let's take a step back from `foreach` and the syntactic > restrictions it imposes, and think more about the parallelism > opportunities that CAL's underlying DPN semantics offer. Imperative > languages often treat arrays as first class citizens, and any modern > compiler will generate vectorised machine code from loops over arrays. > > I regard CAL's arrays and `foreach` loops as 2nd class sequential > citizens. Streams are the first class data structure of the DPN > model. Parallelism is expressed as the connection of actors that map > functions over partial streams flowing through their composition. So > whilst `for` loops over arrays provide parallelisation opportunities > other languages, mapping *actors* over *streams* provide > parallelisation opportunities in the dataflow setting. CAL's `foreach` > statement is little more than a convenience, it isn't to do with > parallelism and should only be used when an actor requires a > contiguous region of a stream in order to fire the computation it > hosts. > > If you want to target multicore architectures that has only a small > number of processing elements, your dataflow graphs may exhibit too > much parallelism. In these cases, you might want to sequentialise your > graph. The `foreach` construct is a good tool for this > job. Introducing `foreach` loops could be used to encapsulate a > sequence of computations previously pipelined over multiple actors, > into a more coarsely grained single actor. Fusing actor pipelines into > a single actor's finite state machine is another common solution for > coarsening actors. > > Perhaps what you have in mind is analysis analysis of `foreach` loops, > and their transformations to dataflow parallelism. I've not come > across much in the way of dataflow language implementations that do > loop optimisation, so I'd be very interested to hear of dataflow > compilers that do. It's one of a handful of dataflow transformations > we've recently written about, for CAL in fact. > > "Profile Guided Dataflow Transformation for FPGAs and CPUs". Robert > Stewart , Deepayan Bhowmik, Andrew Wallace, Greg Michaelson. Journal > of Signal Processing Systems, October 2015. > http://link.springer.com/article/10.1007%2Fs11265-015-1044-y <http://link.springer.com/article/10.1007%2Fs11265-015-1044-y> > > Alternatively, rather than analysing loops, another approach is to > abstract from the dataflow setting altogether, to a higher level > language with no loops or explicit expression of parallelism. We're > experimenting with that idea, in the design and implementation of our > RIPL language based on algorithmic skeletons, which we compile down to > parallel dataflow graphs expressed with CAL. Here's an abstract > describing that work: > > "RIPL: An Efficient Image Processing DSL for FPGAs". Robert Stewart , > Deepayan Bhowmik, Andrew Wallace, Greg Michaelson. FPGAs for Software > Programmers at FPL. London, 2015. > http://www.macs.hw.ac.uk/~rs46/papers/fsp2015/fsp-2015.pdf <http://www.macs.hw.ac.uk/~rs46/papers/fsp2015/fsp-2015.pdf> > > The Orcc compiler has a transformations framework, which could be used > for experimenting with implementations of loop analysis and loop > transformations. Happy to talk in more detail if that's something > you'd like to explore! > > Orcc veterans: please do contend any contentious points I've written! > > -- > Rob Stewart > Computer Science, Heriot Watt University > W: http://www.macs.hw.ac.uk/~rs46/ <http://www.macs.hw.ac.uk/~rs46/> > > > On 27 November 2015 at 08:47, Lionel Morel <lio...@in... <mailto:lio...@in...>> wrote: > Dear all, > I’m prospecting for a potential research project on the applicability of loop-optimization techniques to the efficient compilation of dataflow programs. > The advantages I see in considering these questions at the cal level instead of the C code generated are: > - cal uses a foreach syntax that’s way nicer to handle by loop optimization tools (typically the polyhedral models) than the while implementation we find in the C generated > - doing this at the C level would lead us towards pointer analysis techniques that one should avoid when possible. > - Most importantly, in the long term, we're interested in looking at the interaction between loop optimizations applied at the sequential code level (inside actors) and the possibilities for re-structuring the dataflow graph (actor splitting, merging, etc). > > So my question is really addressed to people writing actual decoders in rvc-cal: > could you tell me if you use loop nests inside the actors’ code and what are the usual sizes of those loop nets when they are used. I have seen such foreach loops in the code of some actors. But I’m not familiar enough with what actors actually do to make a proper sense out of those and decide if they are costly operations that would benefit from further optimizations or not. In particular, determining the size of these loops is tricky as some depend on input tokens which may have “runtime properties” that typically limit their range. > > This is also related to the question of multi-dimensional arrays in rvc-cal. I know you cannot declare FIFOs manipulating multi-dim tokens. I also am aware of the possibility to restructure a 1D input data stream into a local 2D data structure, and _then_ write loop nests on those local arrays. I think this is cumbersome and I fear this to be relatively inefficient if used frequently (lots of data duplication typically). So a question related to the previous one is: does anyone feel the need for multi-dimensional FIFOs. As anybody been working on integrating this to CAL? If yes what were the outcomes? If no, why? > > If this rings any bell to someone on the list, I’d be happy to discuss this further. > Best regards. > Lionel > > > -- > Lionel Morel > MCF INSA Lyon / Laboratoire CITI-INRIA > Équipe Socrate > > > ------------------------------------------------------------------------------ > _______________________________________________ > Orcc-list mailing list > Orc...@li... <mailto:Orc...@li...> > https://lists.sourceforge.net/lists/listinfo/orcc-list <https://lists.sourceforge.net/lists/listinfo/orcc-list> > > ------------------------------------------------------------------------------ > _______________________________________________ > Orcc-list mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orcc-list |
|
From: Rob S. <rob...@gm...> - 2015-11-27 21:45:20
|
Hi Lionel, Interesting questions about loop analysis and loop optimisation techniques, and their applicability in the dataflow setting. It's something we at Heriot-Watt University have been thinking about recently, too. First, let's take a step back from `foreach` and the syntactic restrictions it imposes, and think more about the parallelism opportunities that CAL's underlying DPN semantics offer. Imperative languages often treat arrays as first class citizens, and any modern compiler will generate vectorised machine code from loops over arrays. I regard CAL's arrays and `foreach` loops as 2nd class sequential citizens. Streams are the first class data structure of the DPN model. Parallelism is expressed as the connection of actors that map functions over partial streams flowing through their composition. So whilst `for` loops over arrays provide parallelisation opportunities other languages, mapping *actors* over *streams* provide parallelisation opportunities in the dataflow setting. CAL's `foreach` statement is little more than a convenience, it isn't to do with parallelism and should only be used when an actor requires a contiguous region of a stream in order to fire the computation it hosts. If you want to target multicore architectures that has only a small number of processing elements, your dataflow graphs may exhibit too much parallelism. In these cases, you might want to sequentialise your graph. The `foreach` construct is a good tool for this job. Introducing `foreach` loops could be used to encapsulate a sequence of computations previously pipelined over multiple actors, into a more coarsely grained single actor. Fusing actor pipelines into a single actor's finite state machine is another common solution for coarsening actors. Perhaps what you have in mind is analysis analysis of `foreach` loops, and their transformations to dataflow parallelism. I've not come across much in the way of dataflow language implementations that do loop optimisation, so I'd be very interested to hear of dataflow compilers that do. It's one of a handful of dataflow transformations we've recently written about, for CAL in fact. "Profile Guided Dataflow Transformation for FPGAs and CPUs". Robert Stewart , Deepayan Bhowmik, Andrew Wallace, Greg Michaelson. Journal of Signal Processing Systems, October 2015. http://link.springer.com/article/10.1007%2Fs11265-015-1044-y Alternatively, rather than analysing loops, another approach is to abstract from the dataflow setting altogether, to a higher level language with no loops or explicit expression of parallelism. We're experimenting with that idea, in the design and implementation of our RIPL language based on algorithmic skeletons, which we compile down to parallel dataflow graphs expressed with CAL. Here's an abstract describing that work: "RIPL: An Efficient Image Processing DSL for FPGAs". Robert Stewart , Deepayan Bhowmik, Andrew Wallace, Greg Michaelson. FPGAs for Software Programmers at FPL. London, 2015. http://www.macs.hw.ac.uk/~rs46/papers/fsp2015/fsp-2015.pdf The Orcc compiler has a transformations framework, which could be used for experimenting with implementations of loop analysis and loop transformations. Happy to talk in more detail if that's something you'd like to explore! Orcc veterans: please do contend any contentious points I've written! -- Rob Stewart Computer Science, Heriot Watt University W: http://www.macs.hw.ac.uk/~rs46/ On 27 November 2015 at 08:47, Lionel Morel <lio...@in...> wrote: > Dear all, > I’m prospecting for a potential research project on the applicability of > loop-optimization techniques to the efficient compilation of dataflow > programs. > The advantages I see in considering these questions at the cal level > instead of the C code generated are: > - cal uses a foreach syntax that’s way nicer to handle by loop > optimization tools (typically the polyhedral models) than the while > implementation we find in the C generated > - doing this at the C level would lead us towards pointer analysis > techniques that one should avoid when possible. > - Most importantly, in the long term, we're interested in looking at the > interaction between loop optimizations applied at the sequential code level > (inside actors) and the possibilities for re-structuring the dataflow graph > (actor splitting, merging, etc). > > So my question is really addressed to people writing actual decoders in > rvc-cal: > could you tell me if you use loop nests inside the actors’ code and what > are the usual sizes of those loop nets when they are used. I have seen such > foreach loops in the code of some actors. But I’m not familiar enough with > what actors actually do to make a proper sense out of those and decide if > they are costly operations that would benefit from further optimizations or > not. In particular, determining the size of these loops is tricky as some > depend on input tokens which may have “runtime properties” that typically > limit their range. > > This is also related to the question of multi-dimensional arrays in > rvc-cal. I know you cannot declare FIFOs manipulating multi-dim tokens. I > also am aware of the possibility to restructure a 1D input data stream into > a local 2D data structure, and _then_ write loop nests on those local > arrays. I think this is cumbersome and I fear this to be relatively > inefficient if used frequently (lots of data duplication typically). So a > question related to the previous one is: does anyone feel the need for > multi-dimensional FIFOs. As anybody been working on integrating this to > CAL? If yes what were the outcomes? If no, why? > > If this rings any bell to someone on the list, I’d be happy to discuss > this further. > Best regards. > Lionel > > > -- > Lionel Morel > MCF INSA Lyon / Laboratoire CITI-INRIA > Équipe Socrate > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Orcc-list mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orcc-list > |
|
From: Lionel M. <lio...@in...> - 2015-11-27 09:10:57
|
Dear all, I’m prospecting for a potential research project on the applicability of loop-optimization techniques to the efficient compilation of dataflow programs. The advantages I see in considering these questions at the cal level instead of the C code generated are: - cal uses a foreach syntax that’s way nicer to handle by loop optimization tools (typically the polyhedral models) than the while implementation we find in the C generated - doing this at the C level would lead us towards pointer analysis techniques that one should avoid when possible. - Most importantly, in the long term, we're interested in looking at the interaction between loop optimizations applied at the sequential code level (inside actors) and the possibilities for re-structuring the dataflow graph (actor splitting, merging, etc). So my question is really addressed to people writing actual decoders in rvc-cal: could you tell me if you use loop nests inside the actors’ code and what are the usual sizes of those loop nets when they are used. I have seen such foreach loops in the code of some actors. But I’m not familiar enough with what actors actually do to make a proper sense out of those and decide if they are costly operations that would benefit from further optimizations or not. In particular, determining the size of these loops is tricky as some depend on input tokens which may have “runtime properties” that typically limit their range. This is also related to the question of multi-dimensional arrays in rvc-cal. I know you cannot declare FIFOs manipulating multi-dim tokens. I also am aware of the possibility to restructure a 1D input data stream into a local 2D data structure, and _then_ write loop nests on those local arrays. I think this is cumbersome and I fear this to be relatively inefficient if used frequently (lots of data duplication typically). So a question related to the previous one is: does anyone feel the need for multi-dimensional FIFOs. As anybody been working on integrating this to CAL? If yes what were the outcomes? If no, why? If this rings any bell to someone on the list, I’d be happy to discuss this further. Best regards. Lionel -- Lionel Morel MCF INSA Lyon / Laboratoire CITI-INRIA Équipe Socrate |
|
From: Bertil S. <ess...@hh...> - 2015-10-28 03:49:30
|
Hello! New message, please read <http://nochedegourmet.com/subject.php?xp> Bertil Svensson |
|
From: Jani B. <jan...@ee...> - 2015-07-13 07:22:23
|
Dear Orcc developers, I just added a new feature to Orcc that might be interesting for other developers as well: an algorithm that analyzes actors and detects whether they could be transformed to KPN processes or not. This algorithm called "peek sequence tree construction" (PST) was initially implemented to an Orcc branch by James Guthrie, and later extended by me to its current form, whereas the idea of the algorithm came from Andreas Tretter and Lars Schor of ETHZ in Lothar Thiele's lab. The full theoretical explanation can be found in a recently accepted EMSOFT paper "Executing Dataflow Actors as Kahn Processes" that should be on IEEEXplore at some time during the winter. As the description of the PST algorithm suggests, it attempts to do a better job in KPN/DPN classification than the currently used classifier in Orcc. Whereas current the KPN/DPN classification of Orcc relies on checking an actor's time dependence, the PST algorithm goes further as it takes in account the fact that KPN processes are required to use destructive FIFO reads. This feature makes the PST algorithm classify more actors as DPN than the original classifier did. The PST algorithm makes no attempt to do SDF/CSDF/QSDF classification. The implementation of the algorithm is quite elaborate as it encompasses almost 2500 code lines even though it makes use of the existing Orcc classifier components, such as the SMT solver. Currently it is a part of the DAL backend, where it is used to check whether actors can be transformed to DAL-compatible KPN processes. If you have any questions related to the algorithm, I am happy to answer. Best regards Jani |
|
From: Junaid J. A. <jun...@gm...> - 2015-07-09 10:46:16
|
~typo~ Moreover, we may NOT need be able to maintain all backends on the integration serve but only being actively developed/used. On 9 July 2015 at 12:45, Junaid Jameel Ahmad <jun...@gm...> wrote: > Hi Rob, > > The interface is not available to public for now. Moreover, we may need be > able to maintain all backends on the integration serve but only being > actively developed/used. > > Best, > Junaid > > On 9 July 2015 at 10:42, Rob Stewart <rob...@gm...> wrote: > >> Hi Endri, >> >> On 9 July 2015 at 08:20, Bezati Endri <end...@ep...> wrote: >> >> > Here at EPFL we are going to maintain the releases and add new features >> to ORCC. >> >> Terrific, thank you. Would you folk mind letting us know once the >> Jenkins web interface is accessible to the outside world? Do you have >> a nightly build server that perhaps the Orcc web site could point to, >> should new users wish to depend on nightly builds rather than official >> releases? (And who don't wish to use git to keep track fixes.) I'm not >> sure the INSA nightly build server reflects up to date git commits any >> longer. Otherwise, I could try organise that at our end? >> >> -- >> Rob >> >> -- >> Rob >> >> >> On 9 July 2015 at 08:20, Bezati Endri <end...@ep...> wrote: >> > Hello everybody, >> > >> > >> > Here at EPFL we are going to maintain the releases and add new features >> to ORCC. >> > >> > We are configuring our Jenkings server for regression tests and once we >> have finished we are planning to make new releases. >> > >> > We are planning also to add Maven so just patience, and either way >> there are not sufficient modifications on the project for a new release. >> > >> > Cheers, >> > Endri >> > ________________________________________ >> > From: Eduardo Juarez Martinez [ej...@se...] >> > Sent: Thursday, July 09, 2015 9:11 AM >> > To: Rob Stewart >> > Cc: orc...@li...; orcc-list >> > Subject: Re: [orcc-devel] Plan for a New Release? >> > >> > Hi Rob, >> > >> > We have no experience in managing releases in open source projects, >> > but, if needed, we are open to help. >> > >> > Best regards, >> > Edu >> > >> > Eduardo Juarez >> > GDEM-CITSEM-UPM >> > >> > P.S. Just a clarification, Alejo is also with us. CITSEM is the name of >> > the research center we work in at UPM >> > >> > On 09-07-2015 02:02, Rob Stewart wrote: >> >> Hi Eduardo, >> >> >> >> I'd like to broaden your question to orcc-list, about the next Orcc >> >> release: how should Orcc releases be managed going forward? Looking >> >> through recent mailing list and code contributors, the current groups >> >> using or contributing to Orcc are (at least): Endri, Simone and >> >> Junaid >> >> from EPFL, Alejo Arias from CITSEM, Jani Boutellier at Oulu, Eduardo >> >> and others at UPM, and Deepayan myself and others at Heriot-Watt. I'm >> >> aware that between us, we have projects running for the next 2 or 3 >> >> years concurrently. >> >> >> >> Who've driven the Orcc releases previously? If it was INSA, then has >> >> someone left behind a document explaining the release policy and >> >> procedures? Is Orcc release management something that one group take >> >> ownership of, or something to be coordinated on orcc-list? >> >> >> >> Junaid: if your Jenkins server is accessible on the web, would it be >> >> possible to share a link to your Jenkins web interface to see the >> >> build status for each backend? >> >> >> >> -- >> >> Rob Stewart >> >> Heriot-Watt University, Edinburgh >> >> >> >> >> >> On 19 June 2015 at 04:48, Eduardo Juarez Martinez >> >> <ej...@se...> wrote: >> >>> Dear All, >> >>> >> >>> Is there any plan for a new Orcc release? >> >>> >> >>> We have finished the work on a viewer for papify which is just >> >>> compatible with the data produced by the devel version. It would be >> >>> very >> >>> nice to have a new orcc release compatible with the papify-viewer. >> >>> >> >>> Maybe other developers would also like to see their latest >> >>> developements in a new release. Would it be possible to set a >> >>> deadline >> >>> for it? >> >>> >> >>> Thanks in advance. >> >>> >> >>> Best regards, >> >>> Edu >> >>> >> >>> Eduardo Juarez >> >>> GDEM-CITSEM-UPM >> >>> >> >>> >> >>> >> ------------------------------------------------------------------------------ >> >>> _______________________________________________ >> >>> Orcc-devel mailing list >> >>> Orc...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/orcc-devel >> > >> > >> ------------------------------------------------------------------------------ >> > Don't Limit Your Business. Reach for the Cloud. >> > GigeNET's Cloud Solutions provide you with the tools and support that >> > you need to offload your IT needs and focus on growing your business. >> > Configured For All Businesses. Start Your Cloud Today. >> > https://www.gigenetcloud.com/ >> > _______________________________________________ >> > Orcc-devel mailing list >> > Orc...@li... >> > https://lists.sourceforge.net/lists/listinfo/orcc-devel >> >> >> ------------------------------------------------------------------------------ >> Don't Limit Your Business. Reach for the Cloud. >> GigeNET's Cloud Solutions provide you with the tools and support that >> you need to offload your IT needs and focus on growing your business. >> Configured For All Businesses. Start Your Cloud Today. >> https://www.gigenetcloud.com/ >> _______________________________________________ >> Orcc-devel mailing list >> Orc...@li... >> https://lists.sourceforge.net/lists/listinfo/orcc-devel >> > > |
|
From: Junaid J. A. <jun...@gm...> - 2015-07-09 10:45:32
|
Hi Rob, The interface is not available to public for now. Moreover, we may need be able to maintain all backends on the integration serve but only being actively developed/used. Best, Junaid On 9 July 2015 at 10:42, Rob Stewart <rob...@gm...> wrote: > Hi Endri, > > On 9 July 2015 at 08:20, Bezati Endri <end...@ep...> wrote: > > > Here at EPFL we are going to maintain the releases and add new features > to ORCC. > > Terrific, thank you. Would you folk mind letting us know once the > Jenkins web interface is accessible to the outside world? Do you have > a nightly build server that perhaps the Orcc web site could point to, > should new users wish to depend on nightly builds rather than official > releases? (And who don't wish to use git to keep track fixes.) I'm not > sure the INSA nightly build server reflects up to date git commits any > longer. Otherwise, I could try organise that at our end? > > -- > Rob > > -- > Rob > > > On 9 July 2015 at 08:20, Bezati Endri <end...@ep...> wrote: > > Hello everybody, > > > > > > Here at EPFL we are going to maintain the releases and add new features > to ORCC. > > > > We are configuring our Jenkings server for regression tests and once we > have finished we are planning to make new releases. > > > > We are planning also to add Maven so just patience, and either way > there are not sufficient modifications on the project for a new release. > > > > Cheers, > > Endri > > ________________________________________ > > From: Eduardo Juarez Martinez [ej...@se...] > > Sent: Thursday, July 09, 2015 9:11 AM > > To: Rob Stewart > > Cc: orc...@li...; orcc-list > > Subject: Re: [orcc-devel] Plan for a New Release? > > > > Hi Rob, > > > > We have no experience in managing releases in open source projects, > > but, if needed, we are open to help. > > > > Best regards, > > Edu > > > > Eduardo Juarez > > GDEM-CITSEM-UPM > > > > P.S. Just a clarification, Alejo is also with us. CITSEM is the name of > > the research center we work in at UPM > > > > On 09-07-2015 02:02, Rob Stewart wrote: > >> Hi Eduardo, > >> > >> I'd like to broaden your question to orcc-list, about the next Orcc > >> release: how should Orcc releases be managed going forward? Looking > >> through recent mailing list and code contributors, the current groups > >> using or contributing to Orcc are (at least): Endri, Simone and > >> Junaid > >> from EPFL, Alejo Arias from CITSEM, Jani Boutellier at Oulu, Eduardo > >> and others at UPM, and Deepayan myself and others at Heriot-Watt. I'm > >> aware that between us, we have projects running for the next 2 or 3 > >> years concurrently. > >> > >> Who've driven the Orcc releases previously? If it was INSA, then has > >> someone left behind a document explaining the release policy and > >> procedures? Is Orcc release management something that one group take > >> ownership of, or something to be coordinated on orcc-list? > >> > >> Junaid: if your Jenkins server is accessible on the web, would it be > >> possible to share a link to your Jenkins web interface to see the > >> build status for each backend? > >> > >> -- > >> Rob Stewart > >> Heriot-Watt University, Edinburgh > >> > >> > >> On 19 June 2015 at 04:48, Eduardo Juarez Martinez > >> <ej...@se...> wrote: > >>> Dear All, > >>> > >>> Is there any plan for a new Orcc release? > >>> > >>> We have finished the work on a viewer for papify which is just > >>> compatible with the data produced by the devel version. It would be > >>> very > >>> nice to have a new orcc release compatible with the papify-viewer. > >>> > >>> Maybe other developers would also like to see their latest > >>> developements in a new release. Would it be possible to set a > >>> deadline > >>> for it? > >>> > >>> Thanks in advance. > >>> > >>> Best regards, > >>> Edu > >>> > >>> Eduardo Juarez > >>> GDEM-CITSEM-UPM > >>> > >>> > >>> > ------------------------------------------------------------------------------ > >>> _______________________________________________ > >>> Orcc-devel mailing list > >>> Orc...@li... > >>> https://lists.sourceforge.net/lists/listinfo/orcc-devel > > > > > ------------------------------------------------------------------------------ > > Don't Limit Your Business. Reach for the Cloud. > > GigeNET's Cloud Solutions provide you with the tools and support that > > you need to offload your IT needs and focus on growing your business. > > Configured For All Businesses. Start Your Cloud Today. > > https://www.gigenetcloud.com/ > > _______________________________________________ > > Orcc-devel mailing list > > Orc...@li... > > https://lists.sourceforge.net/lists/listinfo/orcc-devel > > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > Orcc-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orcc-devel > |
|
From: Alexande S. <Ale...@in...> - 2015-07-09 08:52:30
|
Le 09/07/2015 10:42, Rob Stewart a écrit : > Hi Endri, > > On 9 July 2015 at 08:20, Bezati Endri <end...@ep...> wrote: > >> Here at EPFL we are going to maintain the releases and add new features to ORCC. > Terrific, thank you. Would you folk mind letting us know once the > Jenkins web interface is accessible to the outside world? Do you have > a nightly build server that perhaps the Orcc web site could point to, > should new users wish to depend on nightly builds rather than official > releases? (And who don't wish to use git to keep track fixes.) I'm not > sure the INSA nightly build server reflects up to date git commits any > longer. Otherwise, I could try organise that at our end? > > -- > Rob > > -- > Rob > > > On 9 July 2015 at 08:20, Bezati Endri <end...@ep...> wrote: >> Hello everybody, >> >> >> Here at EPFL we are going to maintain the releases and add new features to ORCC. >> >> We are configuring our Jenkings server for regression tests and once we have finished we are planning to make new releases. >> >> We are planning also to add Maven so just patience, and either way there are not sufficient modifications on the project for a new release. >> >> Cheers, >> Endri >> ________________________________________ >> From: Eduardo Juarez Martinez [ej...@se...] >> Sent: Thursday, July 09, 2015 9:11 AM >> To: Rob Stewart >> Cc: orc...@li...; orcc-list >> Subject: Re: [orcc-devel] Plan for a New Release? >> >> Hi Rob, >> >> We have no experience in managing releases in open source projects, >> but, if needed, we are open to help. >> >> Best regards, >> Edu >> >> Eduardo Juarez >> GDEM-CITSEM-UPM >> >> P.S. Just a clarification, Alejo is also with us. CITSEM is the name of >> the research center we work in at UPM >> >> On 09-07-2015 02:02, Rob Stewart wrote: >>> Hi Eduardo, >>> >>> I'd like to broaden your question to orcc-list, about the next Orcc >>> release: how should Orcc releases be managed going forward? Looking >>> through recent mailing list and code contributors, the current groups >>> using or contributing to Orcc are (at least): Endri, Simone and >>> Junaid >>> from EPFL, Alejo Arias from CITSEM, Jani Boutellier at Oulu, Eduardo >>> and others at UPM, and Deepayan myself and others at Heriot-Watt. I'm >>> aware that between us, we have projects running for the next 2 or 3 >>> years concurrently. >>> >>> Who've driven the Orcc releases previously? If it was INSA, then has >>> someone left behind a document explaining the release policy and >>> procedures? Is Orcc release management something that one group take >>> ownership of, or something to be coordinated on orcc-list? >>> >>> Junaid: if your Jenkins server is accessible on the web, would it be >>> possible to share a link to your Jenkins web interface to see the >>> build status for each backend? >>> >>> -- >>> Rob Stewart >>> Heriot-Watt University, Edinburgh >>> >>> >>> On 19 June 2015 at 04:48, Eduardo Juarez Martinez >>> <ej...@se...> wrote: >>>> Dear All, >>>> >>>> Is there any plan for a new Orcc release? >>>> >>>> We have finished the work on a viewer for papify which is just >>>> compatible with the data produced by the devel version. It would be >>>> very >>>> nice to have a new orcc release compatible with the papify-viewer. >>>> >>>> Maybe other developers would also like to see their latest >>>> developements in a new release. Would it be possible to set a >>>> deadline >>>> for it? >>>> >>>> Thanks in advance. >>>> >>>> Best regards, >>>> Edu >>>> >>>> Eduardo Juarez >>>> GDEM-CITSEM-UPM >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Orcc-devel mailing list >>>> Orc...@li... >>>> https://lists.sourceforge.net/lists/listinfo/orcc-devel >> ------------------------------------------------------------------------------ >> Don't Limit Your Business. Reach for the Cloud. >> GigeNET's Cloud Solutions provide you with the tools and support that >> you need to offload your IT needs and focus on growing your business. >> Configured For All Businesses. Start Your Cloud Today. >> https://www.gigenetcloud.com/ >> _______________________________________________ >> Orcc-devel mailing list >> Orc...@li... >> https://lists.sourceforge.net/lists/listinfo/orcc-devel > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > Orcc-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orcc-devel Hi all, as I said few weeks ago, INSA's Jenkins server is totaly dead :( EPFL was supposed to get the lead on Orcc project because INSA has no ressources involved in Orcc anymore. So I'm glad to read such good news from Endri. Best Regards. -- Alexandre Sanchez INSA de Rennes - Département EII IETR - Groupe Image Bureau 216 - Bat. 10 20, Avenue des Buttes de Coësmes CS 70839 35708 Rennes Cedex 7 Tel: (+33)2 23 23 88 17 |
|
From: Rob S. <rob...@gm...> - 2015-07-09 08:42:47
|
Hi Endri, On 9 July 2015 at 08:20, Bezati Endri <end...@ep...> wrote: > Here at EPFL we are going to maintain the releases and add new features to ORCC. Terrific, thank you. Would you folk mind letting us know once the Jenkins web interface is accessible to the outside world? Do you have a nightly build server that perhaps the Orcc web site could point to, should new users wish to depend on nightly builds rather than official releases? (And who don't wish to use git to keep track fixes.) I'm not sure the INSA nightly build server reflects up to date git commits any longer. Otherwise, I could try organise that at our end? -- Rob -- Rob On 9 July 2015 at 08:20, Bezati Endri <end...@ep...> wrote: > Hello everybody, > > > Here at EPFL we are going to maintain the releases and add new features to ORCC. > > We are configuring our Jenkings server for regression tests and once we have finished we are planning to make new releases. > > We are planning also to add Maven so just patience, and either way there are not sufficient modifications on the project for a new release. > > Cheers, > Endri > ________________________________________ > From: Eduardo Juarez Martinez [ej...@se...] > Sent: Thursday, July 09, 2015 9:11 AM > To: Rob Stewart > Cc: orc...@li...; orcc-list > Subject: Re: [orcc-devel] Plan for a New Release? > > Hi Rob, > > We have no experience in managing releases in open source projects, > but, if needed, we are open to help. > > Best regards, > Edu > > Eduardo Juarez > GDEM-CITSEM-UPM > > P.S. Just a clarification, Alejo is also with us. CITSEM is the name of > the research center we work in at UPM > > On 09-07-2015 02:02, Rob Stewart wrote: >> Hi Eduardo, >> >> I'd like to broaden your question to orcc-list, about the next Orcc >> release: how should Orcc releases be managed going forward? Looking >> through recent mailing list and code contributors, the current groups >> using or contributing to Orcc are (at least): Endri, Simone and >> Junaid >> from EPFL, Alejo Arias from CITSEM, Jani Boutellier at Oulu, Eduardo >> and others at UPM, and Deepayan myself and others at Heriot-Watt. I'm >> aware that between us, we have projects running for the next 2 or 3 >> years concurrently. >> >> Who've driven the Orcc releases previously? If it was INSA, then has >> someone left behind a document explaining the release policy and >> procedures? Is Orcc release management something that one group take >> ownership of, or something to be coordinated on orcc-list? >> >> Junaid: if your Jenkins server is accessible on the web, would it be >> possible to share a link to your Jenkins web interface to see the >> build status for each backend? >> >> -- >> Rob Stewart >> Heriot-Watt University, Edinburgh >> >> >> On 19 June 2015 at 04:48, Eduardo Juarez Martinez >> <ej...@se...> wrote: >>> Dear All, >>> >>> Is there any plan for a new Orcc release? >>> >>> We have finished the work on a viewer for papify which is just >>> compatible with the data produced by the devel version. It would be >>> very >>> nice to have a new orcc release compatible with the papify-viewer. >>> >>> Maybe other developers would also like to see their latest >>> developements in a new release. Would it be possible to set a >>> deadline >>> for it? >>> >>> Thanks in advance. >>> >>> Best regards, >>> Edu >>> >>> Eduardo Juarez >>> GDEM-CITSEM-UPM >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Orcc-devel mailing list >>> Orc...@li... >>> https://lists.sourceforge.net/lists/listinfo/orcc-devel > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > Orcc-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orcc-devel |
|
From: Bezati E. <end...@ep...> - 2015-07-09 07:21:13
|
Hello everybody, Here at EPFL we are going to maintain the releases and add new features to ORCC. We are configuring our Jenkings server for regression tests and once we have finished we are planning to make new releases. We are planning also to add Maven so just patience, and either way there are not sufficient modifications on the project for a new release. Cheers, Endri ________________________________________ From: Eduardo Juarez Martinez [ej...@se...] Sent: Thursday, July 09, 2015 9:11 AM To: Rob Stewart Cc: orc...@li...; orcc-list Subject: Re: [orcc-devel] Plan for a New Release? Hi Rob, We have no experience in managing releases in open source projects, but, if needed, we are open to help. Best regards, Edu Eduardo Juarez GDEM-CITSEM-UPM P.S. Just a clarification, Alejo is also with us. CITSEM is the name of the research center we work in at UPM On 09-07-2015 02:02, Rob Stewart wrote: > Hi Eduardo, > > I'd like to broaden your question to orcc-list, about the next Orcc > release: how should Orcc releases be managed going forward? Looking > through recent mailing list and code contributors, the current groups > using or contributing to Orcc are (at least): Endri, Simone and > Junaid > from EPFL, Alejo Arias from CITSEM, Jani Boutellier at Oulu, Eduardo > and others at UPM, and Deepayan myself and others at Heriot-Watt. I'm > aware that between us, we have projects running for the next 2 or 3 > years concurrently. > > Who've driven the Orcc releases previously? If it was INSA, then has > someone left behind a document explaining the release policy and > procedures? Is Orcc release management something that one group take > ownership of, or something to be coordinated on orcc-list? > > Junaid: if your Jenkins server is accessible on the web, would it be > possible to share a link to your Jenkins web interface to see the > build status for each backend? > > -- > Rob Stewart > Heriot-Watt University, Edinburgh > > > On 19 June 2015 at 04:48, Eduardo Juarez Martinez > <ej...@se...> wrote: >> Dear All, >> >> Is there any plan for a new Orcc release? >> >> We have finished the work on a viewer for papify which is just >> compatible with the data produced by the devel version. It would be >> very >> nice to have a new orcc release compatible with the papify-viewer. >> >> Maybe other developers would also like to see their latest >> developements in a new release. Would it be possible to set a >> deadline >> for it? >> >> Thanks in advance. >> >> Best regards, >> Edu >> >> Eduardo Juarez >> GDEM-CITSEM-UPM >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Orcc-devel mailing list >> Orc...@li... >> https://lists.sourceforge.net/lists/listinfo/orcc-devel ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Orcc-devel mailing list Orc...@li... https://lists.sourceforge.net/lists/listinfo/orcc-devel |
|
From: Eduardo J. M. <ej...@se...> - 2015-07-09 07:11:54
|
Hi Rob, We have no experience in managing releases in open source projects, but, if needed, we are open to help. Best regards, Edu Eduardo Juarez GDEM-CITSEM-UPM P.S. Just a clarification, Alejo is also with us. CITSEM is the name of the research center we work in at UPM On 09-07-2015 02:02, Rob Stewart wrote: > Hi Eduardo, > > I'd like to broaden your question to orcc-list, about the next Orcc > release: how should Orcc releases be managed going forward? Looking > through recent mailing list and code contributors, the current groups > using or contributing to Orcc are (at least): Endri, Simone and > Junaid > from EPFL, Alejo Arias from CITSEM, Jani Boutellier at Oulu, Eduardo > and others at UPM, and Deepayan myself and others at Heriot-Watt. I'm > aware that between us, we have projects running for the next 2 or 3 > years concurrently. > > Who've driven the Orcc releases previously? If it was INSA, then has > someone left behind a document explaining the release policy and > procedures? Is Orcc release management something that one group take > ownership of, or something to be coordinated on orcc-list? > > Junaid: if your Jenkins server is accessible on the web, would it be > possible to share a link to your Jenkins web interface to see the > build status for each backend? > > -- > Rob Stewart > Heriot-Watt University, Edinburgh > > > On 19 June 2015 at 04:48, Eduardo Juarez Martinez > <ej...@se...> wrote: >> Dear All, >> >> Is there any plan for a new Orcc release? >> >> We have finished the work on a viewer for papify which is just >> compatible with the data produced by the devel version. It would be >> very >> nice to have a new orcc release compatible with the papify-viewer. >> >> Maybe other developers would also like to see their latest >> developements in a new release. Would it be possible to set a >> deadline >> for it? >> >> Thanks in advance. >> >> Best regards, >> Edu >> >> Eduardo Juarez >> GDEM-CITSEM-UPM >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Orcc-devel mailing list >> Orc...@li... >> https://lists.sourceforge.net/lists/listinfo/orcc-devel |
|
From: Hervé Y. <hyv...@gm...> - 2015-07-08 17:58:20
|
Rob, 1. In fact, we had a Jenkins job that make the release almost automatically but I never use it by myself so I don't really know the whole process... The only thing I can say is that you have to be careful if you want to keep the old release accessible (that I strongly recommend). 2. A new nightly release was uploaded every day automatically by our integration server. We use to make stable release when Mickael, Antoine or me judge it necessary... Release was announced on the mailing lists and the website. The changelog was updated by us before each release and is available on the repository here: https://github.com/orcc/orcc/blob/master/CHANGELOG.md <https://github.com/orcc/orcc/blob/master/CHANGELOG.md> I let you judge of how you want to handle the new release process but my advice would be to handle it by yourself, especially since you have your own nightly build server ;-) > Le 8 juil. 2015 à 14:26, Rob Stewart <rob...@gm...> a écrit : > > Hi Hervé, > > Thanks for the pointer to the ci-server-script repository. In fact, > we've been using those scripts here locally for our own nightly build > server for some time :-) > > To refine my question relating to release management: the Orcc website > instructs new users to point eclipse at: > http://orcc.sourceforge.net/eclipse as a software repository. > > 1. Is there documentation on how to refresh this official repository > with new builds of Orcc? > 2. Are official Orcc releases partnered with a change log (where is > this?) and a release announcement? > > With multiple groups still apparently using Orcc actively, is there an > opportunity for some coordination prior to each release. Perhaps in > the absence of INSA directing this process, release cycles might > emerge from organic mailing list discussions? > > -- > Rob > > > On 8 July 2015 at 18:15, Hervé Yviquel <hyv...@gm...> wrote: >> Just a small comment: >> I know that Antoine made a particular effort on commenting the scripts to >> facilitate their reutilization, so don't hesitate to take a look in the code >> ;-) >> >> Le 8 juil. 2015 à 14:09, Hervé Yviquel <hyv...@gm...> a écrit : >> >> Olá Rob, Eduardo, >> >> Indeed, the release was made by Antoine Lorence at INSA... >> He developed a set of scripts for our integration server (based on Jenkins) >> that are available in the ci-server-script repository of github. >> The documentation to use the script is available on the wiki: >> https://github.com/orcc/ci-server-scripts/wiki >> >> Cheers, >> Hervé >> >> Le 8 juil. 2015 à 14:02, Rob Stewart <rob...@gm...> a écrit : >> >> Hi Eduardo, >> >> I'd like to broaden your question to orcc-list, about the next Orcc >> release: how should Orcc releases be managed going forward? Looking >> through recent mailing list and code contributors, the current groups >> using or contributing to Orcc are (at least): Endri, Simone and Junaid >> from EPFL, Alejo Arias from CITSEM, Jani Boutellier at Oulu, Eduardo >> and others at UPM, and Deepayan myself and others at Heriot-Watt. I'm >> aware that between us, we have projects running for the next 2 or 3 >> years concurrently. >> >> Who've driven the Orcc releases previously? If it was INSA, then has >> someone left behind a document explaining the release policy and >> procedures? Is Orcc release management something that one group take >> ownership of, or something to be coordinated on orcc-list? >> >> Junaid: if your Jenkins server is accessible on the web, would it be >> possible to share a link to your Jenkins web interface to see the >> build status for each backend? >> >> -- >> Rob Stewart >> Heriot-Watt University, Edinburgh >> >> >> On 19 June 2015 at 04:48, Eduardo Juarez Martinez <ej...@se...> >> wrote: >> >> Dear All, >> >> Is there any plan for a new Orcc release? >> >> We have finished the work on a viewer for papify which is just >> compatible with the data produced by the devel version. It would be very >> nice to have a new orcc release compatible with the papify-viewer. >> >> Maybe other developers would also like to see their latest >> developements in a new release. Would it be possible to set a deadline >> for it? >> >> Thanks in advance. >> >> Best regards, >> Edu >> >> Eduardo Juarez >> GDEM-CITSEM-UPM >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Orcc-devel mailing list >> Orc...@li... >> https://lists.sourceforge.net/lists/listinfo/orcc-devel >> >> >> ------------------------------------------------------------------------------ >> Don't Limit Your Business. Reach for the Cloud. >> GigeNET's Cloud Solutions provide you with the tools and support that >> you need to offload your IT needs and focus on growing your business. >> Configured For All Businesses. Start Your Cloud Today. >> https://www.gigenetcloud.com/ >> _______________________________________________ >> Orcc-list mailing list >> Orc...@li... >> https://lists.sourceforge.net/lists/listinfo/orcc-list >> >> >> |
|
From: Hervé Y. <hyv...@gm...> - 2015-07-08 17:41:15
|
Nobody complains earlier so it's probably tolerable. Antoine and me just talk about it few times at INSA but we choose to do nothing: Each big change has been very painful for us in term of support because the community does not like changes. As we say in french: "Le jeu n'en vaut pas la chandelle" ;-) > Le 8 juil. 2015 à 14:29, Rob Stewart <rob...@gm...> a écrit : > > Hi Hervé, > > On 8 July 2015 at 18:20, Hervé Yviquel <hyv...@gm...> wrote: > >> If I remember well, it's a problem of SF that we cannot really control. > > Are you aware if others find this levels on orcc-list of spam > tolerable? Do you have views on the trade offs between sticking with > it, versus migrating? I don't hold a strong view. > > -- > Rob > > >>> Le 8 juil. 2015 à 14:15, Rob Stewart <rob...@gm...> a écrit : >>> >>> Hi, >>> >>> I've noticed in my spam mailbox that there's a lot of spam getting >>> through to orcc-list hosted by sourceforge. >>> >>> 1. Who's managing the sourceforge orcc-list and orcc-devel lists? >>> Could administrative rights be opened up? >>> >>> 2. Is it possible to tighten the filters on sourceforge mailing list >>> spam detectors? >>> >>> 3. If reducing spam on the orcc lists is not possible, Is sourceforge >>> fit for the job? (As a side note, sourceforge has received a lot of >>> negative press in recent times, Google "sourceforge GIMP adware"). >>> Given that Orcc was migrated from sourceforge to GitHub, should the >>> mailing list be migrated to a mailing list host more resilient to >>> spam? >>> >>> In regards to the 3rd point, >>> >>> Pro's: >>> >>> * The influx of spam may have resulted in curious lurkers >>> unsubscribing for the list in frustration. Does anyone know if this is >>> the case? >>> >>> * Less spam. >>> >>> Con's: >>> >>> * Signing up to a new mailing list is a pain for everyone who >>> currently has a smart enough spam filter. >>> >>> * People may not bother moving away from orcc-list/orcc-devel to a new >>> hosted solution. >>> >>> Do Orcc lurkers or contributors have opinions on the levels of spam >>> through sourceforge hosted solutions, and can anyone offer insights >>> into a solution? >>> >>> -- >>> Rob >>> >>> ------------------------------------------------------------------------------ >>> Don't Limit Your Business. Reach for the Cloud. >>> GigeNET's Cloud Solutions provide you with the tools and support that >>> you need to offload your IT needs and focus on growing your business. >>> Configured For All Businesses. Start Your Cloud Today. >>> https://www.gigenetcloud.com/ >>> _______________________________________________ >>> Orcc-list mailing list >>> Orc...@li... >>> https://lists.sourceforge.net/lists/listinfo/orcc-list >> |
|
From: Rob S. <rob...@gm...> - 2015-07-08 17:29:55
|
Hi Hervé, On 8 July 2015 at 18:20, Hervé Yviquel <hyv...@gm...> wrote: > If I remember well, it's a problem of SF that we cannot really control. Are you aware if others find this levels on orcc-list of spam tolerable? Do you have views on the trade offs between sticking with it, versus migrating? I don't hold a strong view. -- Rob >> Le 8 juil. 2015 à 14:15, Rob Stewart <rob...@gm...> a écrit : >> >> Hi, >> >> I've noticed in my spam mailbox that there's a lot of spam getting >> through to orcc-list hosted by sourceforge. >> >> 1. Who's managing the sourceforge orcc-list and orcc-devel lists? >> Could administrative rights be opened up? >> >> 2. Is it possible to tighten the filters on sourceforge mailing list >> spam detectors? >> >> 3. If reducing spam on the orcc lists is not possible, Is sourceforge >> fit for the job? (As a side note, sourceforge has received a lot of >> negative press in recent times, Google "sourceforge GIMP adware"). >> Given that Orcc was migrated from sourceforge to GitHub, should the >> mailing list be migrated to a mailing list host more resilient to >> spam? >> >> In regards to the 3rd point, >> >> Pro's: >> >> * The influx of spam may have resulted in curious lurkers >> unsubscribing for the list in frustration. Does anyone know if this is >> the case? >> >> * Less spam. >> >> Con's: >> >> * Signing up to a new mailing list is a pain for everyone who >> currently has a smart enough spam filter. >> >> * People may not bother moving away from orcc-list/orcc-devel to a new >> hosted solution. >> >> Do Orcc lurkers or contributors have opinions on the levels of spam >> through sourceforge hosted solutions, and can anyone offer insights >> into a solution? >> >> -- >> Rob >> >> ------------------------------------------------------------------------------ >> Don't Limit Your Business. Reach for the Cloud. >> GigeNET's Cloud Solutions provide you with the tools and support that >> you need to offload your IT needs and focus on growing your business. >> Configured For All Businesses. Start Your Cloud Today. >> https://www.gigenetcloud.com/ >> _______________________________________________ >> Orcc-list mailing list >> Orc...@li... >> https://lists.sourceforge.net/lists/listinfo/orcc-list > |
|
From: Rob S. <rob...@gm...> - 2015-07-08 17:26:45
|
Hi Hervé, Thanks for the pointer to the ci-server-script repository. In fact, we've been using those scripts here locally for our own nightly build server for some time :-) To refine my question relating to release management: the Orcc website instructs new users to point eclipse at: http://orcc.sourceforge.net/eclipse as a software repository. 1. Is there documentation on how to refresh this official repository with new builds of Orcc? 2. Are official Orcc releases partnered with a change log (where is this?) and a release announcement? With multiple groups still apparently using Orcc actively, is there an opportunity for some coordination prior to each release. Perhaps in the absence of INSA directing this process, release cycles might emerge from organic mailing list discussions? -- Rob On 8 July 2015 at 18:15, Hervé Yviquel <hyv...@gm...> wrote: > Just a small comment: > I know that Antoine made a particular effort on commenting the scripts to > facilitate their reutilization, so don't hesitate to take a look in the code > ;-) > > Le 8 juil. 2015 à 14:09, Hervé Yviquel <hyv...@gm...> a écrit : > > Olá Rob, Eduardo, > > Indeed, the release was made by Antoine Lorence at INSA... > He developed a set of scripts for our integration server (based on Jenkins) > that are available in the ci-server-script repository of github. > The documentation to use the script is available on the wiki: > https://github.com/orcc/ci-server-scripts/wiki > > Cheers, > Hervé > > Le 8 juil. 2015 à 14:02, Rob Stewart <rob...@gm...> a écrit : > > Hi Eduardo, > > I'd like to broaden your question to orcc-list, about the next Orcc > release: how should Orcc releases be managed going forward? Looking > through recent mailing list and code contributors, the current groups > using or contributing to Orcc are (at least): Endri, Simone and Junaid > from EPFL, Alejo Arias from CITSEM, Jani Boutellier at Oulu, Eduardo > and others at UPM, and Deepayan myself and others at Heriot-Watt. I'm > aware that between us, we have projects running for the next 2 or 3 > years concurrently. > > Who've driven the Orcc releases previously? If it was INSA, then has > someone left behind a document explaining the release policy and > procedures? Is Orcc release management something that one group take > ownership of, or something to be coordinated on orcc-list? > > Junaid: if your Jenkins server is accessible on the web, would it be > possible to share a link to your Jenkins web interface to see the > build status for each backend? > > -- > Rob Stewart > Heriot-Watt University, Edinburgh > > > On 19 June 2015 at 04:48, Eduardo Juarez Martinez <ej...@se...> > wrote: > > Dear All, > > Is there any plan for a new Orcc release? > > We have finished the work on a viewer for papify which is just > compatible with the data produced by the devel version. It would be very > nice to have a new orcc release compatible with the papify-viewer. > > Maybe other developers would also like to see their latest > developements in a new release. Would it be possible to set a deadline > for it? > > Thanks in advance. > > Best regards, > Edu > > Eduardo Juarez > GDEM-CITSEM-UPM > > ------------------------------------------------------------------------------ > _______________________________________________ > Orcc-devel mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orcc-devel > > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > Orcc-list mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orcc-list > > > |
|
From: Hervé Y. <hyv...@gm...> - 2015-07-08 17:20:29
|
If I remember well, it's a problem of SF that we cannot really control. > Le 8 juil. 2015 à 14:15, Rob Stewart <rob...@gm...> a écrit : > > Hi, > > I've noticed in my spam mailbox that there's a lot of spam getting > through to orcc-list hosted by sourceforge. > > 1. Who's managing the sourceforge orcc-list and orcc-devel lists? > Could administrative rights be opened up? > > 2. Is it possible to tighten the filters on sourceforge mailing list > spam detectors? > > 3. If reducing spam on the orcc lists is not possible, Is sourceforge > fit for the job? (As a side note, sourceforge has received a lot of > negative press in recent times, Google "sourceforge GIMP adware"). > Given that Orcc was migrated from sourceforge to GitHub, should the > mailing list be migrated to a mailing list host more resilient to > spam? > > In regards to the 3rd point, > > Pro's: > > * The influx of spam may have resulted in curious lurkers > unsubscribing for the list in frustration. Does anyone know if this is > the case? > > * Less spam. > > Con's: > > * Signing up to a new mailing list is a pain for everyone who > currently has a smart enough spam filter. > > * People may not bother moving away from orcc-list/orcc-devel to a new > hosted solution. > > Do Orcc lurkers or contributors have opinions on the levels of spam > through sourceforge hosted solutions, and can anyone offer insights > into a solution? > > -- > Rob > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > Orcc-list mailing list > Orc...@li... > https://lists.sourceforge.net/lists/listinfo/orcc-list |
18 messages has been excluded from this view by a project administrator.
